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.
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
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.
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.
????
- 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.
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.
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 -y
akagusu•5h ago
bfrog•4h ago
f_devd•3h ago
westurner•2h ago
testdelacc1•2h ago
bitbasher•3h ago
I know which I prefer.
yjftsjthsd-h•3h ago
In Fil-C?
stefan_•3h ago
Meanwhile, the Rust version of course is vulnerable to all of those: https://ubuntu.com/security/notices/USN-7867-1
josephg•2h 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•2h 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_•1h ago
josephg•1h 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•37m ago
stefan_•23m 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•2h 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•1h ago
ottah•1h 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•1h ago
bitwize•32m 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•1h 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•1h ago
masklinn•43m ago
it would probably be a lot stronger an argument if sudo hadn’t also had a few privilege escalation CVEs recently.