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.
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.
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.
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?