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.
If you're going to rely on shell scripts, you should stick to the built-in functionality of your shell as much as possible, as external commands can differ, or even be completely overridden, in random environments for a myriad of reasons.
For example, use
${var%/*}instead of$(dirname $var). Forking out a whole OS process for such minuscule tasks is stupid anyway.This goes against la-la unix philosophy dreamy thoughts and beliefs, or portability fantasies. But it's the right thing to do in the real world. And gives you at least some level of control over expected behavior.
I would argue the entire point of shell scripts is to coordinate running external programs, that's what the shell is for, but I'm a dreamer.
If I was just going to use the built-ins I'd use Python or Ruby or something.
In this particular case I didn't write the shell script, I was just debugging it because it broke on my system when I was running something.
Also your implementation has a bug because
dirname blah.pngreturns "." 😉It wasn't meant as a 1-1 implementation, but fair enough.
I would argue that this helps my point. Because that's an ambiguity
dirnamedoesn't help with. What if "bla.png" is, or expected to be, a dir?And if you're going to
test, are you going to use shell bult-ins or thetestcommand from coreutils? And if you're callingtest, are you calling it with the full path so you don't get a shell builtin anyway or not?Using a better language is absolutely the right thing to do for anything that is not trivial.
Python is a shit choice for another reason though. They don't know what backward compatibility means. So you may find your script broken in 2-3 years anyway. I don't know about Ruby.
if they claim to be posix compliant but aren't, then it's their bug, not their users'
Parent mentioned that the supposed bug was already fixed, that's not the point.
And they target GNU compliance, not POSIX compliance. Which is hard mode, since if it was the latter, they could have just checked out the freebsd utils or whatever at will whenever they felt unsure about something.