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 don't understand why Canonical is replacing the existing GNU tools. Unlike many others, I don't think its "taking over GPL projects" or "license laundering" and I am also not against MIT license. My question is, why Canonical is doing this.
MIT is cancer
Yep. I hate to see it being used as a default license in the Rust ecosystem. Wonderful language, but terrible corporate culture.
It's great for libraries. Less so for applications.
For libraries MPL at least provides a little copyleft protection without making it difficult for developers to actually use them
I think if someone licenses their applications wrong, they shouldn't use my library. That's why I license them as GPL.
But there's also LGPL if you're more tolerant to having your work used for less free software than I am.
I don't think so.
Im not sure as well. A lot of popular stuff is on MIT. But if I were to guess, its one of the most permissive licenses, which is somewhat a bad thing when companies suction up solutions with AI and spit them out without attributing the coder involved.
I don't think Ai companies care about the license at all, or cannot be checked after the training. So that is not really an argument to me.
haha. Welp it only becomes an issue if your software doesn't get audited. I worked in medical and government so it might be a different world where your at. We literally cant use certain software given licenses and such. It can get a bit loony.
AI has tells they built in nowadays. If you use the newer models at least. But in addition...its pretty easy to just find the code in codebases if you end up in an audit.
Im not defending it, just saying that MIT is one of those that you can get away with a lot more than other licenses. And that might be an issue to some.
I can't speak for medical field... but a more serious topic, in example videogames. :D
I think sometimes GPL can be in the way, so it is a tradeoff. In example if you use proprietary Steam features in your game, then you cannot build the game with GPL libraries and code, because that is not compatible with proprietary code. For some that is exactly what the GPL is set to do, for others its hindering games and other software to be released on Steam with Steam features. That means, its impossible to sell GPL software on Steam, if you want to use any of those features (I think in example Achievements and online save files in example). MIT would solve this issue.
Feature, not an issue.
Do you know about the LGPL license? I think it allows you to statically link proprietary code, and the LGPL code remains open while the closed code remains closed. Modified and distributed lgpl still remain under the LGPL.
https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License
Yes, but does anyone actually use LGPL still? Anyway that is a different license and not really GPL anymore, as it does not force anything. I mean if the project is GPL licensed already, then you can't turn it into LPGL, because that is no longer compatible. So the issue for programs and games being GPL remains. If they were LGPL from the start, yes, that probably would solve it.
That does not matter. I think glibc uses it, not sure.
It forces people to give back to LGPL code. It is a weak copy left. I do not know what you mean by being GPL.
That is my point.
Ill be honest, I know of GPL but I know theres like 5 different versions of the GPL. Like AGPL is the most restrictive and has held up in court before because someone forked a project then stripped out everything, sold it again. And was deemed liable.
MIT could potentially solve it...or make it even more messy. Ill believe you on videogames.
If I were to guess, its probably moot in all cases unless it goes to court (or like my orgs not let you use software) and gets defended one way or another.
Why.
Why not?
You could understand if you used a materialist analysis.
Canonical sells products and support to corporations. The gpl is a problem for corporations because it requires that they contribute their changes back into the commons, creating additional overhead in many ways.
Canonical is funding, prioritizing and providing support for a rewrite of a gpl project in a different language with a more permissive license.
Put two and two together. Canonical is bankrolling and pushing something that materially benefits them.
But from all the things why core-utils? I don't think it is common to need changes in core-utils. Now with this MIT version it may certainly be needed, because of broken compatibility. So it feels like instead of doing nothing (because they work as is) and using GNU core-utils they switch to MIT core-utils that are slightly incompatible and because of that need work. I would assume that it will certainly provide patches for MIT core-utils, but I am sure it will just make another platform target for scripts like macOS. Some GPL projects will change their scripts to make them work with Ubuntu.
I guess corporations will corporate.
Because the kernel is the kernel, you just accept it for what it is. The vendors modules are required to run on the stupid soc made on three generations old fabs you’re targeting in your build and the only other part you need to be portable is the standard core utilities.
Getting ahead of the curve regarding potential future legislations/regulations around unsafe languages, which may introduce contract conditions, liabilities...etc (See 2:30-4:30 of this talk for an overview).
If they listened to the calls describing this move as premature, and it arguably was, they could have gotten strapped for time later.
An implementation in a good safe fast modern language that developers actually enjoy has other tangible benefits of course. But if people want the "corpo reason", the above should provide an answer.
Thanks for providing a source. I will watch it at later time and put it on Watch Later list. Until then I can't really say anything about it, just wanted to thank you.
Rust eliminates memory safety vulnerabilities. It accounts for a large percentage of bugs that need patching in live environments, like servers.
I believe Ubuntu wants to grow in iot or embedded devices so reducing patching needs gives them a competitive edge there.
Whilst that may be true, I would expect coreutils has all memory issues debugged by now.
I can understand new applications - or perhaps extended versions - to be created in Rust, rather than reinventing perfectly good wheels.
It feels like they're doing this just for the sake of it, and I expect there's probably better things that could be done with the money / labour
You'd like to think so..
https://app.opencve.io/cve/?product=coreutils&vendor=gnu
Latest cve is a heap overflow.
Interesting, thanks.
Looks like nothing has been found for 17 years until - presumably - someone pointed AI at the (entire?) suite and found 2 CVEs with a very low (<1%) chance of being exploited.
I'd guess that'll be the last 2 bugs left...