I like the project but beware.
(Sure, I realize that GNUcu is old and mature enough to have been pretty thoroughly debugged by this point.)
Another commenter said "dumb cases where it's 100x slower when providing unrealistic values like parsing e9000000 which is actually because it attempts to actually parse it due to bigint support instead of clamping to i128".
sudo apt purge --autoremove --allow-remove-essential coreutils-from-uutils # reinstalls gnu coreutils
sudo update-alternatives --config sudo # can switch back to regular sudo from sudo-rs
(for Ubuntu 25.10)
also people complaining about inclusion of it in ubuntu versions, wait till you find out about the linux kernel.
If it’s not ready, they’ll roll it back.
Part of why you have to do something like this is because the test suite just isn’t comprehensive, nor should we expect it to be. Real world usage is what shakes out the long tail of bugs. You just have to have some sort of stage like this in order to get things into a good state.
Did 100% of tests pass when Ubuntu made this decision? My understanding was no.
In other words, there may be more serious bugs not in the test suite than the ones that aren’t passing that are in the suite. And you only find that out through real usage.
This standard may be justified when there is significant benefit. There is not in this case. And some projects have stricter standards.[1]
> In other words, there may be more serious bugs not in the test suite than the ones that aren’t passing that are in the suite. And you only find that out through real usage.
You should assume everyone understands how Ubuntu's decision would benefit this project. You should assume most Ubuntu users do not care. You replied to a comment which told you this before.[2]
For example, sort has an open PR on it right now.
They will absolutely not roll it back, not matter how broken they are.
The reasons to switch from coreutils to the Rust rewrite are purely political.
Check the extent to which this is true. Also are we rewriting good kernel code that works?
The fallacy here is that code is either "good code that works" or "bad code that needs to be rewritten". It doesn't work like that. "If it aint broke don't fix it" is actually terrible advice.
Rust, by itself, isn't a panacea to add formal verification but one leg on the footstool of formal verification methodologies to produce safe(r/ish) software rather than subtly buggy software that's difficult to prove correct and more expensive to maintain.
"If it aint broke don't fix it" =~= "I've never gotten into an accident until now, so airbags and seatbelts are pointless." ==> reactive methodology / failure / hubris
We want to give up good things to get better things.
What is the vision for improving these tools with rust? What user benefit are they promising?
I’ve heard nothing but nebulous arguments about memory or security purity. There is no insight into how to do them better or faster; and in most cases they have demonstrated they didn’t even understand them fully to begin with, such as missing locales.
There isn’t even subjective value for users demanding it, it’s driven by rust developers.
Does the Linux kernel ship with rather experimental features as default? When was the rule not to break user space revoked?
I know they claim it’s a clean implementation but cmon, there’s no way they aren’t peeking at the existing coreutils source.
BSD wasn’t under an open license when GNU got started, so GNU reimplemented the proprietary UNIX utilities with their own enhancements and their own GPL license.
As such, complaining about the license is rich, considering GNU basically stole it themselves from the first round. And to this day, HN complaining about macOS’s utilities is also rich considering they are actually more standard and authentically UNIX than GNU.
https://github.com/apple-oss-distributions/text_cmds https://github.com/apple-oss-distributions/system_cmds https://github.com/apple-oss-distributions/file_cmds https://github.com/apple-oss-distributions/adv_cmds https://github.com/apple-oss-distributions/shell_cmds https://github.com/apple-oss-distributions/misc_cmds
The question about whether Linux and GNU copied from the proprietary originals caused the famous SCO lawsuits. Even though this was proven false, there’s very little chance the originals weren’t used as reference in GNU.
I’m also curious about this: does that it’s in a different language make any difference here? Like I could also maybe see what you’re saying if these were also in C, but being in Rust, it’s not like they can literally copy the code, regardless. I know you’re talking about feelings and not hard and fast rules, but do you think that plays into any of the feelings at all?
My feelings stem from what I perceive as the degradation of the old school hacker ethos into a more corporate friendly environment. Especially during this time when the bigger companies are salivating at the mouth to replace SWEs with AI at the same time encouraging us to pick friendly licenses so they can take advantage of our volunteer work…
Anyway, thanks for replying. It’s always interesting to hear how people think. I personally feel differently, but I’m sure it’s nothing you haven’t heard before. :)
Also, I have major issues with dumping GPL userspace utilities, for an MIT license suite, that is known to not be feature complete, only, and literally only because it was written in Rust. This does not make sense, and this is not good for users.
Stallman comes from the era when C was good enough, because computing was not a hostile environment like it is today.
GNU is never going to "rewrite it in rust" as long as he's living, and probably for several years afterwards.
In other words, it's a social problem not a technical one.
Let new generations of Free Software orgs come along and supplant GNU with a GBIR (GNU But In Rust), but don't insist on existing, established things that are perfectly good for who and what they are to change into whatever you prefer at any given moment.
> Also, I have major issues with dumping GPL userspace utilities, for an MIT license suite, that is known to not be feature complete, only, and literally only because it was written in Rust. This does not make sense, and this is not good for users.
Thinking about it, I guess I have to agree. This allows ubuntu to avoid releasing security fixing patches if they so choose. You can't do that with GPLed code. It means they can send out binary security fixes and delay the source code release for as long as they like or indefinitely. Which is pretty convenient for a company that sells extended security support packages.
I would think that the regression tests are actually the most worthwhile targets for the new project to validate against: they represent real-world usage and logic corner cases that are evidently easy to get wrong. These are not the kind of bugs that Rust is designed to eliminate.
I believe Ubuntu simply copied and transposed a bunch of tests from gnu core utils and that's where these ultimately came from. That doesn't really mean that all these tests arose due to regressions. (for sure some probably did).
The GPL does not state that the source code for any modification must be released immediately, it doesn't even set some kind of time limit so it technically doesn't prevent indefinite delays either.
You don't think these are ever run with sudo/runas/pkexec/run0 or otherwise invoked by a program running as root?
That said I do think things like sudo, ssh, gpg, maybe systemd, http servers like nginx and apache etc. are more valuable to replace with tools written in rust (or more generally a "memory safe language"). But that doesn't mean rewriting coreutils isn't valuable.
????
And this is precisely why the worst Rust evangelists aim to rewrite it: virtue signaling with no suffering of the opposing party is not good enough.
- coreutils
- findutils
- libmagic and file
- tar and some compression libs
- grep, awk, sed
- the shell and all of its builtins
- something functionally equivalent to openssl or GnuTLS
- some ssh client and server
- curl
- a terminal-based editor
- man-db and texinfo
- some init system and bootloader
- pick a package manager, any package manager, and rewrite it in Rust
Barring all of that, maybe just busybox but written in Rust. That should give you roughly what you need for a non-graphical system. coreutils isn't nothing, but it's a pretty small part of the system, with much of it ending up implemented by the shell in most distros.
There is of course RustTLS that already exists and is already very advanced.
For package manager see for example AerynOS (or its new name that I can't remember).
There are lots of rust editors, terminal and otherwise.
And of course the complete Cosmic Desktop is written in Rust, so you don't have to go 'non-graphical' at all.
So AerynOS, with uutils and Cosmic is very close I would say.
IOW: how much does it matter?
Probably was a bit premature for Ubuntu to enable it by default. Looking at the graph uutils will be fully compatible (or as close as makes no difference) in about 2 years, so I would have waited until then.
Still, I think most of the push-back is just the usual anti-Rust luddites.
I just tried that on three very different Linux systems of mine, and all print `unknown`.
Related: Because of Redhat/Fedora's decision; CentOS Stream, Alma, and Rocky 9 & 10 Docker images use a statically-linked "multi-call" variant of coreutils that is also problematic in real-world usage. This can be fixed with the following:
sudo dnf install coreutils --allowerasing -ynobody runs Ubuntu's six-month releases in production. Like Fedora it's cutting edge in the literal sense of that term, and if you deploy Ubuntu anywhere in the business world you're on the LTS release.
That the rust coreutils aren't at full parity yet is explicitly mentioned in the release notes of 25.10, if you're installing a distribution with a lifespan of half a year it pretty much goes without saying you're a beta tester for the next LTS release. Like, even if everything was pristine and stable it makes no sense to use an operating system with six months of support in production.
akagusu•17h ago
bfrog•16h ago
f_devd•16h ago
westurner•15h ago
testdelacc1•15h ago
bfrog•12h ago
testdelacc1•11h ago
bitbasher•15h ago
I know which I prefer.
yjftsjthsd-h•15h ago
In Fil-C?
stefan_•15h ago
Meanwhile, the Rust version of course is vulnerable to all of those: https://ubuntu.com/security/notices/USN-7867-1
josephg•15h ago
As an aside, I find it weird how much negativity rewrites like this get. If someone decided to make a new web browser, C compiler or kernel people would be congratulating them. I really don’t understand the conservatism when it comes to Linux. Is the current implementation perfect? Should it be preserved in amber? The gnu runtime seems like a messy, badly specified hairball of hacky, inconsistent scripts to me. Some guys in a certain room in the 70s and 80s wrote some C programs. And now every bad idea they had lives in perpetuity in my /usr/bin directory? In the decades since, these tools have sprouted hundreds of weird features that almost nobody uses. And now what, people care what language it’s all written in? This code must never be changed?? Who cares.
wavemode•14h ago
I doubt this is true in practice. The majority of coreutils spend the majority of their time waiting for the results of IO/syscalls. (The exception would probably be, the hashing utilities like md5sum.)
stefan_•14h ago
josephg•13h ago
Is all the code being compiled with the same flags? Shasum probably benefits a lot from intrinsics that are only available on newer CPU targets.
0cf8612b2e1e•13h ago
josephg•12h ago
The Fil-C compiler is a fork of llvm. There's no way all that garbage collection code would make fil-c faster. So if its faster, its probably using different target flags. And in that case, its not a fair benchmark comparison.
stefan_•12h ago
I just think the assertion that "compute-heavy" tools like sha256sum would be especially affected by Fil-C is not true, and if that was true given the "baseline slowdown" of 4x, surely it would show up in this sloppy test.
ottah•14h ago
I just don't see what's to gain, to suffer through years of instability, waiting for a userspace suite to mature, and reach feature parity, when we have a well understood, and safe tool set know.
Maybe in five years, when coreutils is complete, I'd be okay with Ubuntu replacing user land with it. But we're not there, and it's a problem we shouldn't have to tolerate.
Also I can't stand we're leaving GPL code behind for MIT.
steveklabnik•14h ago
ottah•14h ago
The problem, and the real issue I have is that this project is being used as the default in major linux distros. Eager adoption of this project, and making it the production target does take away things from me. The interface has changed, stability is affected. Correctness is now measured against this incomplete implementation first, not the known correct, and stable GNU coreutils.
steveklabnik•14h ago
pseudalopex•12h ago
Many people call Ubuntu flavors distributions. This includes Ubuntu developers.
Ubuntu made it default. The tire kicking analogy was incorrect.
> The purpose is exactly because the GNU versions are being treated as the proper versions. Divergences from them are being fixed, so that this new version follows those. You can only do that by actually trying them out, because it’s impossible for the test suite to cover every behavior.
You should assume everyone understands how Ubuntu's decision would benefit this project. You should assume most Ubuntu users do not care.
steveklabnik•12h ago
pseudalopex•12h ago
Calling something an experiment does not make it exempt from criticism.
> It’s how you get broad enough usage to see if it’s ready.
My understanding was it was known not 100% compatible. And what did I say you should assume?
> If it isn’t by the time for LTS, then it’ll be unmade as the default.
People use non LTS releases for non experimental purposes.
steveklabnik•11h ago
All software has bugs. Plus, not every bug is in the test suite. There are open bugs in all of the software shipped by every distro. Software can be ready for use even if there are know bugs in corner cases. Regular coreutils has open bugs as well.
pseudalopex•11h ago
No one did this.
> All software has bugs. Plus, not every bug is in the test suite. There are open bugs in all of the software shipped by every distro. Software can be ready for use even if there are know bugs in corner cases. Regular coreutils has open bugs as well.
Stop speaking as if other people know nothing of software development. GNU do not break compatibility knowingly and with no user benefit.
steveklabnik•11h ago
pseudalopex•11h ago
josephg•10h ago
You seem mad that a Linux distribution (Ubuntu) is trying this software out. Why do you care so much? Do you expect some of the programs you use to break? Have they?
If you don’t want to use uutils, I have good news. You can opt out. Or use Ubuntu LTS. Or use a different distribution entirely. I suspect you’re mad for a different reason. If all the tests passed, would you still be mad? Do you feel a similar way about angry projects like alpine Linux, which ship code built on musl? All the same compatibility arguments apply there. Musl is also not 100% compatible with glibc. How about llvm? Do you wish we had fewer web browsers?
Or maybe, is it a rust thing in particular? Like, if this rewrite was in C, C++ or go would you feel the same way? Are you worried more components of Linux will be ported to rust? (And if so, why?)
Ultimately the strength (and weakness) of Linux is that you’re not locked in to anything. I don’t understand how the existence of this software could make your life worse. If anything it sounds like it might be helping to clarify your stance on OS stability. If you want to make a principled stance there, there’s plenty of stable Linux distributions which will mirror your values. (Eg debian, Ubuntu lts, etc). Or you can just opt out of this experiment.
Given all of that, the tone I’m inferring from your comments seems disproportionate. Whats going on? Or am I misreading you?
pseudalopex•5h ago
You confused blunt responses to repetitive, condescending, specious, or false statements and anger at Canonical seemingly.
I made no objection to any software existing.
I like Rust. It was unfortunate this experiment supported stereotypes of Rust fanatics promoting Rust without respect for stability.
I reject the view users should have to wait 2 years for bug fixes and features, accept silently all experiments, or switch silently to a distribution with less 3rd party support and other issues inevitably.
The opt out process I saw required --allow-remove-essential. It would be irresponsible to recommend this.
A more responsible way to conduct this experiment would have been opt in 1st. Then phased. Then opt out for everyone. And waiting until all tests passed would have been better of course.
[1] https://lkml.org/lkml/2012/12/23/75
bitwize•13h ago
One of the major problems with C, which like a lot of C's issues Rust just doesn't have, is that it's getting more difficult to find young, eager programmers willing to maintain a C codebase. The hassle of C outweighs the rewards, especially when Rust exists. So, ceteris paribus, development on the Rust version will outpace the C version, and you'll get more and smarter eyes on the code base.
Best to put the C code out to pasture, i.e. in maintenance mode only, with a deprecation plan in place.
josephg•14h ago
If you want a purely gnu userland with gpl code and strong stability guarantees, Ubuntu is almost certainly the wrong distribution for you. Plenty of Linux distributions are far more stable, and won’t replace coreutils, maybe forever. (And if this is aiming to be bug for bug compatible, they won’t ever have to.)
As for the gpl, this isn’t new. there’s been bsd/mit licensed alternatives to coreutils for decades. You know, in FreeBSD and friends. It’s only aiming for 100% Linux compatibility that’s new. And I guess, shipping it in Linux. But let’s be real, the gpl v3 is a pretty toxic license. By trying so hard to preserve user freedom, it becomes a new tyranny for developers. If you build a web based startup today hosted on top of Linux, you might be in breach of the gpl. What a waste of everyone’s time. The point of opensource to me is nobody can tell me what I’m allowed to do with my computer. And that includes RMS.
jitl•13h ago
masklinn•13h ago
it would probably be a lot stronger an argument if sudo hadn’t also had a few privilege escalation CVEs recently.