After so much terrible tech politics news, let’s focus on some nice, easy-going Linux news that’s not going to be controversial at all: Ubuntu intends to replace numerous core Linux utilities with newer Rust replacements, starting with the ubiquitous GNU Coreutils.
This package provides utilities which have become synonymous with Linux to many – the likes of
ls,cp, andmv. In recent years, there has been an effort to reimplement this suite of tools in Rust, with the goal of reaching 100% compatibility with the existing tools. Similar projects, like sudo-rs, aim to replace key security-critical utilities with more modern, memory-safe alternatives.Starting with Ubuntu 25.10, my goal is to adopt some of these modern implementations as the default. My immediate goal is to make uutils’ coreutils implementation the default in Ubuntu 25.10, and subsequently in our next Long Term Support (LTS) release, Ubuntu 26.04 LTS, if the conditions are right.
↫ Jon Seager
Obviously, this is a massive change for Ubuntu, and while performance is one of the cited reasons for undertaking this effort, the biggest reason is, of course, security. To aid in the testing effort, Seager created a tool called oxidizr, with which you can swap between the classic versions and the new Rust versions of various tools to try them out in a non-destructive way.
This is a massive vote of confidence in uutils, and I’m curious to see if it works out for Ubuntu. I doubt it’s going to take long before other prominent distributions follow suit.
Security is an extremely weird argument to make here, as none of them talk to the network. But as every rewrite, this will introduce new logic bugs – potentially some that result in you losing all your files because mv or rm behave slightly differently than a script expects (or even cp not creating the copy you expect correctly). These tools all already exist, they don’t gain many new features, the code has been battle tested over decades. Replacing it with something new and almost certainly not 100% compatible that also hasn’t been battle tested for decades is just a terrible idea and nothing else. I wonder if the true motivation here is that the person is one of the followers of the “All code needs to be rewritten in Rust, no matter whether it makes sense or not” cult and he just wants to push more Rust code into everything.
All “X but in Rust” projects I’ve seen implement just a tiny subset of what the original X does. Is Ubuntu trying to lose functionality?
Is this coming from Debian or that’s still safe?
uutils is being developed against the GNU coreutils test suite with the goal of being a set of drop-in replacements.
They explicitly distinguish themselves from various other tools like bat, exa, and ripgrep based on that.
> with the goal of being a set of drop-in replacements
Goals are fine, but are they done?
My problem with Rust is it’s using religious propaganda tactics instead of competing on technical merits, which leads me to distrust any Rust based replacement project.
I’m going to call [citation needed] on “religious propaganda tactics”. As-is, it’s just an ad hominem attack and I always lean toward interpreting bombastic language as a sign that the speaker is worthless as a source of information.
As for goals, look at their chart showing their progress on getting all of GNU Coreutils tests to pass when the uutils equivalents are swapped in. Given the interest so many people in the Rust ecosystem have on finding ways to go over and above Rust’s type system, it wouldn’t surprise me if, once they finish that, someone drops in and sets up differential fuzzing to find things the tests DON’T catch.
I will, however, say that I’m surprised Ubuntu people are experimenting with swapping them in this soon, even if the remaining test failure are supposedly esoteric niche cases or things that only apply on non-Linux platforms.
torp,
Most devs who are pushing for rust are just citing the decades of security problems that C/C++ are clearly responsible for. Unsafe languages have had their time in the spot light. We keep seeing vulnerabilities, both hidden as well as in public. Leaving memory integrity to humans is the objective failure point. Let the compiler do memory verification!
Calling this “religious” sounds like more of an attack on the person than the argument. Personally I don’t care if the solution is rust or another memory safe language. I can understand sticking with the devil you know, as js has suggested. Theoretically we might stick with C/C++ for centuries but the costs of memory unsafe languages will keep adding up.
The most pragmatic path forward is to tackle easy fruit first. Personally I don’t care what memory safe language we. Or changing C/C++ to be memory safe could be interesting. I think an issue with revamping C/C++ is that unlike languages that are designed for memory safety by default, C/C++ can’t be secure by default without breaking backwards compatibility. In any case though I’d like to see a high degree of interoperability between memory safe languages so that they work well together without having to us C interfaces to get there. IMHO the use of C as standard has really held back APIs.
It does seem odd to me.
Fans of uutils generally don’t try to argue performance or even security (they agree that GNU coreutils is pretty battle-tested on those fronts) but, rather, portability (as in “you don’t need Cygwin or WSL or a dead third-party project like GnuWin32 to get Windows builds) and reusability (as in “We’re ensuring the availability of tested MIT-licensed Rust code to perform these functions in case your project needs it”).
The main argument I’d expect to see for a switch like this is the same one Linus makes for being open to Rust4Linux… making the codebase more attractive for future generations of developers.
(And I’ll certainly agree there. Knowing I won’t have to fiddle around with autotools/CMake/etc. and all of C vagaries as part of getting familiar enough with a codebase to make a patch is a big deal for me.)
ssokolow (Hey, OSNews, U2F/WebAuthn is broken on Firefox!),
That’s a very interesting perspective. A lot of the tools used around C code bases are…really antiquated. Replacing them has nothing to do with memory safety per say. Honestly there’s a lot C cruft that I’d like to tackle. C and even C++ lacks a lot of the niceties we find in other modern languages. Include files and forward declarations suck so much! Even with modern IDEs it’s just so much overhead working around poor language languages and caveats – just let me declare things once and not have to worry about declaration order. There are many independent arguments for replacing C because other languages got to learn from C’s mistakes – it’s not just memory safety.
*nod* During my time in /r/rust/ from about 2013 to when Reddit shut down the RSS feeds, I saw a lot of people coming from languages like C and C++ citing Cargo as the best part of Rust in their eyes.
> and while performance is one of the cited reasons for undertaking this effort
If canonical cared about *performance*, they’d have gotten rid of snaps a long time ago.
Even now, snaps are such a detriment to the user experience that they negate the improvements of ssd’s. And that’s only a slight hyperbole.
Hats off to whoever named the util oxidizr.
I did not see this coming and it is totally surprising. Ubuntu is adopting the RedoxOS userland? Not only is it a radical step but I did not realize that uutils is ready. There are still missing commands and missing options in things as fundamental as ‘ls’.
https://github.com/orgs/uutils/projects/1/views/3
There goes a signature feature of SerpentOS (or AerynOS I guess).
If this catches on, it is certainly not going to be popular with the GNU crowd. Not only is it a massive blow to the idea of GNU/Linux but uutils is MIT licensed.
My only bother is making it harder to support alternative platforms on older hardware. There are many retro platforms that are kept functional and out of the landfill because C tools are very portable.
Thankfully, we still got the BSDs to hold the fort.
(I’d be happy to hear about people porting Rust to obscure platforms)
True… though it is a bit ironic when portability of a different kind (to Windows without Cygwin or WSL or some other POSIX compatibility solution) is what fans of uutils tend to cite as their reasons for liking them.
Rust portability is amazing but only to the platforms that Rust supports. Rust currently supports all the architectures supported by Ubuntu at the moment though. So they are a good fit for each other in that way.
Serious question – how often are there security vulnerabilities in GNU ls(1) or cat(1)?
Never. As for the entire coreutils suite, the issues have been with split, sort, and chroot.
https://www.cvedetails.com/product/5075/GNU-Coreutils.html?vendor_id=72
This has been where the performance gains are as well. sort, for example, is apparently about 6 times faster in uutils.
Good bye compatibility!
And of course it’s the MIT license. The undermining of the free software movement continues.
As much as I agree with that sentiment in spirit, I have to point it out:
Nobody is entitled to a customer base. If people care more about choosing Rust over C than about choosing GPL over MIT, then it’s the GPL-using developers’ fault for resting on their laurels and allowing a competitor to get out in front of them.
The same market dynamics which allowed GPLed software to catch the world of proprietary software asleep at the wheel in the 2000s is now allowing Rust developers who don’t care about licenses beyond “it’s convention to default to MIT/Apache dual-license for Rust projects” to catch the existing C-centric ecosystem asleep at the wheel.
(In essence, it’s another systemd or Flatpak situation.)
What’s wrong with MIT license ? I use it all the time, with Zlib as well.
I like rust, but I suspect a big motivation for this is escaping copyleft and the free software philosophy. Makes it easier for the megacorps to lock down products and suck more code into LLMs. 🙁 If this was around in the early 2000s we might not have had open source routers.
A fun security window opening will be exploiting the differences between tool sets. Unless the testsuite can check every possible input and output there will be differences, so you’ll now have undefined/implementation specific behavior.
I doubt it. There’s no competitive advantage to having your own proprietary coreutils and inconsistencies in the platform from vendor to vendor impeding portability were part of what caused commercial UNIX to lose out to Linux in the first place. (POSIX was a “too little, too late” measure to address the problems infamously complained about in The UNIX-HATERS Handbook.)
Existing differences between Linux and the BSDs aside, the Rust ecosystem is fond of fuzzing, so I wouldn’t be surprised if someone set up a differential fuzzing harness.