> This is not symbolic of any pointed move away from GNU components - it's literally just about replacing coreutils with a more modern equivalent. Sure, the license is different, and it's a consideration, but it's by no means a driver in the decision making.
Sorry, don't believe this one bit. I'm very thankful for everything Canonical/Ubuntu did about 20 years ago, but no thanks. This comes from someone who loves Rust and what it made possible. However, freedoms are too important to not treat anything that looks like an attack on them as such.
The uutils project has the right goals - 1:1 compatibility with GNU coreutils to the extent that any difference in functionality is a bug.
The first comment on LWN is about a bug in the more(1) from uutils. I checked out that code, found some oddities (like doing stat() on a path to check if it exists, right before open()ing it) and went to check against how GNU coreutils does it.
Turns out coreutils does not do it at all, because more(1) is from util-linux. ta-dam.
I hate to admit it, because I don't particularly like Rust, but I'm slowly coming around to the idea it should replace things.
The major change is a recent comment I made where I was musing about a future where LLMs actually write most of the code. That isn't a foregone conclusion but the recent improvements in coding LLMs suggests it isn't as far off a future as I once considered.
My thought was simple: if I am using a LLM to do the significant portion of generating code, how does that change what I think about the programming language I am using? Does the criteria I use to select the language change?
Upon reflection, Rust is probably the best candidate. It has strictness in ways that other languages do not have. And if the LLM is paying most of the cost of keeping the types and lifetimes in order, what do I care if the syntax is ugly? As long as I can read the output of the LLM and verify it (code review it) then I actually want the strictness. I want the most statically analyzable code possible since I have low trust in the LLM. The fact that Rust is also, ahem, blazingly fast, is icing on the cake.
As an aside to this aside, I was also thinking about modular kernels, like Minix. I wonder if there is a world where we take a userland like the one Ubuntu is trying and apply it to Minix. And then slowly replace the os modules with ones written in Rust. I think the modularity of something like Minix might be an advantage, but that might just be because I am completely naïve.
This is the worst kind of busy-work. Rewriting something for the sake of it is terrible practice.
There's a lot of refreshing energy amongst Rust coders eager to produce better, more modern command-line tools. That's amazing, and a real benefit to everyone. But rewriting simple, decades-old, perfectly functional tools, with the explicit goal of not improving them is just a self-absorbed hobby. And a dangerous one at that - any new code will contain bugs, and the best way to avoid that is not to write code if you don't have to.
Amazing, another reason for avoiding Ubuntu.
Many of these utilities have had logic errors in them, you can find them on GitHub issues. sudo, for example, allowed you to bypass through some way I cannot remember.
And I bet you they are not a replacement for GNU utilities, i.e. have less features, and are possibly not optimized either, and perhaps they even have different (or less) flags/options.
I have written a lot of Bash scripts, I wonder how well (if at all) would work on Ubuntu with the Rust utilities.
Canonical making light of licensing again, no surprise here.
This has ulterior motive written all over it. Best outcome: nothing happens.
I have a queston: Why do they need their utilities to be written in Rust? Most utilities do not have to face the network, and most don't need to have root privileges. Heck, most of them are one shot programs and don't even need to free memory by the programmer. They could exit and return all the memory space back to the OS.
My long hope is that some day, someone starts to replace the perl-based Debian infrastructure with Rust (or really, anything).
I did a decent bit of mod_perl, love & respect perl, but here in 2025, it's pretty terrifying to me that Debian's main dependency is a pretty sizable perl runtime. That there seems to be very little that will budge this. The whole ecosystem is built atop a language that very few people have interest in, that has much less interest & activity than other modern alternatives.
It's fine if we start switching the user env over to more popular Rust based utilities. But what I really want is for the OS itself to modernize, to start getting away from it's ancient seemingly-unshakeable legacy. Nothing against Perl, but I'd love to see this family of OSes move beyond being Perl only.
All you are doing is setting people up for more permanent bash-dash disasters. Isn't there something more useful you could be doing with your time? Say making drag&drop work in snaps (another unforced disaster)?
Has someone built Busybox in Rust yet? That would be good for embedded.
This is on brand for Canonical.
Bleeding edge beta (alpha?) software put in the core of their system
Reminds me of when they switched Gnome out for Ubuntu One, no way back if you did 'aptitude full-upgrade'.
It was a buggy leaky pos
Again, dear friends...
It looks like a corporate project with all the required hype and lingo. Ubuntu was nice around version 10, it went downhill with spyware, snap, etc.
"There are countless examples in the open source community of tools being re-engineered, and re-imagined using tools and practices that have only relatively recently become available."
Recently? You can use Ada or OCaml, which is a better Rust. You can use C with formal proofs and not constantly rewrite everything.
But that of course is the point. No rewrites, no easy money for the corporate OSS "developers".
Using Rust is a political solution to deskill a generation of coders to replace higher-cost labor with lower
The push for Rust isn't just a technical decision - it's a calculated economic strategy. By forcing rewrites of stable systems in a new language, companies effectively reset the clock on developer experience and expertise.
When a C/C++ codebase with 30 years of institutional knowledge gets rewritten in Rust, senior developers with decades of experience suddenly compete on more equal footing with juniors who just graduated. Your 15 years of C++ optimization knowledge? Now worth less than a 22-year-old's six months of Rust bootcamp training.
This isn't about memory safety - it's about labor costs. Companies call it "modernization" while quietly erasing the premium they'd otherwise pay for experience. The technical arguments serve as perfect cover for what's really happening: deliberately manufacturing a scenario where they can replace $250K senior engineers with $80K juniors.
The pattern is familiar to anyone who's watched other industries. Create artificial obsolescence of existing skills, then exploit the resulting chaos to reset salary expectations and eliminate the leverage that comes with specialized knowledge.
This is why language transitions always seem to coincide with hiring freezes and "restructuring." It's never been about technical superiority - it's about breaking labor's bargaining power.
GNU is free to adopt better tools than C/C++. I adore gnu but I refuse to support blatant and obstinant idiocy. Using the license to extort people into supporting C/C++ is just scummy behavior. What the fuck were you doing the last ten years that this wasn't a gnu project? Instead we got fucking systemd and a dozen more knockoffs of the shittiest os on earth
Rust and "memory safety" is the current form of corporate authoritarianism. It's ironic that its most vocal advocates are also likely to be the ones complaining about the authoritarianism of the current administration.
> Of course they are considered problematic in Rust. > And leaks are hard to code by accident in Rust. > ...
I enjoyed this gem and its descendants from the comments. What I see instead, commonly, even in big rust projects, is that it's easy to accidentally define something with a longer lifetime than you intend. Some of that happens accidentally (not recognizing the implications of an extra reference here and there when the language frees things based on static detections of being unused). Much more of it happens because the compiler fights against interesting data structures -- e.g., the pattern of allocating a vec as pseudo-RAM, using indices as pseudo-pointers, and never freeing anything till the container itself is unused.
There's nothing wrong with those techniques per se, but the language tends to paint you into a bit of a corner if you're not very good and very careful, so leaks are a fact of life in basically every major Rust project I've seen not written by somebody like BurntSushi, even when that same sort of project would not have a leak in a GC language.