Oboi here we go 🙄
Ubuntu has managed to do away with GNU Core Utilities in its default stack. The last three holdouts, cp, mv and rm, have moved to uutils’ coreutils; the Rust reimplementation Canonical has been feeding into the distro since 2025.
They had been held back from 26.04 LTS over flaws in the uutils versions. Everything else, from ls and cat to chmod and du, made that jump in earlier releases.
This change, while big, sits hidden away in an obscure mention in Canonical’s work-in-progress release notes for Ubuntu 26.10.
It’s been a long road
Canonical started oxidising Ubuntu last year, and Ubuntu 25.10 became the first release to ship coreutils as the default. That release also made sudo-rs the default privilege tool, replacing a command that had been in place for decades.
26.04 was the release where the plan did slow down quite a bit, as Canonical kept cp, mv, and rm on their GNU versions due to a bunch of TOCTOU issues that were blocking the full implementation.
These were caught during an audit, when Canonical commissioned Zellic for two rounds between December 2025 and March 2026, focusing on the most security-sensitive utilities first.
Across both rounds, Zellic raised 113 issues, and 44 of them were assigned CVEs. Canonical says the vast majority have been resolved.
Getting here has had its ups and downs, and the last stretch was not clean. In July, uutils cp went back into the archive and came straight out again after it broke live image builds.
The fix was quick; as the developers marked it “Critical,” the fix went upstream, and the migration landed in time for 26.10. What changes for you?
When typing commands, nothing changes for you on the surface. uutils coreutils is designed to be a drop-in replacement for essential GNU tools, and the project treats any divergence from GNU as a bug, further pointing out that some options may still be missing or behave differently.
So if you prefer staying on the GNU version, you have the option to install the coreutils-from-gnu package that houses all the required components.
The next stage
Coreutils is one piece of a broader campaign. Earlier this year, Canonical became a Gold Sponsor of the Trifecta Tech Foundation, pitching in €40,000 a year to fund memory-safe system software.
Under this, their current target is ntpd-rs, a Rust rewrite of the tools Ubuntu uses to keep its clock in sync. While work is still ongoing, it has already arrived for testing.
Its transition to being default is targeted for Ubuntu 27.04.
What Canonical is gradually building up towards is the completion of their oxidation vision for Ubuntu, and it’s not about blindly including new components. Rather, it looks like a measured approach that’s being worked out a few steps at a time.
I thought its obvious what I meant, based on the context of my entire reply. The argument is, anyone who writes and understands can make changes to the Rust code, but not on C or Python code. I can basic C coding, but wouldn’t trust me doing anything with it, but I would trust me doing something with Rust. Was it really that hard to understand? Also that means following is wrong:
The code is Rust code. Anyone who writes Python code can NOT read, adapt and make changes to it. That’s my point with C vs Rust, because not everyone writes C (or Rust) code.
Your argument
sapplies to any language. Hence why not re-write same tools in any of them, right?Because not everyone wants or can write any of them? If people like Rust and want to write and read Rust, then it makes sense to write it in Rust. Not in “any of them”. And when they see other projects written in Rust, it makes sense to review it, look into, adapt the code written in Rust. Not in any of the other languages, because the project is in Rust.
Let’s go back again to understand what my point was. I try to be clear as possible. The GNU tools are written in C. Only programmers who understand and can write in C can understand and write in C. But look… someone rewrote the GNU tools in Rust. Not in another language. In must be my lucky day, because Rust is my favorite and only language I write (that’s not true BTW, but that’s is besides). I loooove writing in Rust and immadiately open it up, look into, I can read and write in Rust. Not in another language.
Now substitute you with me, let’s say I know and like Ada (it is not true, but does not matter) and there is also “project in Ada” same as “the project is in Rust” from your comment. Then following your logic I could be positive about Canonical trying to substitute core utils with their Ada counterpart
Which I am not going to be, because to me that’s not about programming languages. Which is how we come back to my first comment: “yay, there is a <language name> re-write of some important software” is ok to think as an individual, but it is not (can not be? should not be?) a reason to be glad about what Canonical is doing
But you are talking about another issue. I am talking from the developers (users) view who likes to program in Rust. And the more programs are available in Rust, the bigger the eco system grows, the more people work on the project you care that is in Rust. You can work on the project, or just read the code to ensure its correct.
My point is comparing it to C, not any other language. Because the utilities are programmed in C and the new version are programmed in Rust. Also Canonical couldn’t even adopt the Core utils in a different language, because there is none. Rust is the only alternative version that is being developed. And there are reasons why they write it in Rust and not in Ada. Lot of reasons actually, including the future projection. Written in Ada is not the same as written in Rust.
But talking about the other languages just distract from the actual point. I am not talking about other languages (until you introduced them). From the Rust users perspective, it is nice that the tools are in Rust. Because the person (me) don’t want to write or read C (at least complex code).