Who is declaring the compatibility percentage? Given that GNU coreutils is GPL and Rust Coreutils is MIT, they must implement clean room development practices.
I really don't understand the hate, it's not 1.0 and majority of unsupported cases probably haven't seen use since 1990's and especially 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.
also people complaining about inclusion of it in ubuntu versions, wait till you find out about the linux kernel.
It’s a cool project but does anyone else find the choice of MIT kinda icky/disrespectful? Like maintainers have put decades of work into the GNU coreutils under the gpl and all that entails, and then some people decide to rewrite it and just say “nah”.
I know they claim it’s a clean implementation but cmon, there’s no way they aren’t peeking at the existing coreutils source.
87.75% compatibility, as measured by a comprehensive, but incomplete test suite. They want 87.75% compatibility to be an accurate measure, but we know that in reality the real number is lower.
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.
This does not make sense to you because you are looking from a technological standpoint. The reason to rewrite coreutils (or sudo) in Rust is not technological, as there is no merit. Coreutuils are titanium rock stable tools that no one asked to rewrite.
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.
This is going to sound like a gripe and I swear it isn't, but is there a plan for a reasonably full suite of minimal userspace tools? I don't expect util-linux itself in Rust, but something like:
- 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.
systemd sort of did this to certain parts and it's the worst thing that happened to Linux. Standardizing on Rust political rewrites of tar and libmagic is going to be an epic disaster and a decade of never-ending fun for Rust evangelicals.
While I <3 Rust, rewriting major things in Rust but then taking an additional step of releasing incomplete, incompatible code as "production" like Canonical has done without day 1 full compatibility is inherently unethical, problematic, and counterproductive.
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:
What's the point of that? The C version has been around for ages, works well, and is GPL'ed. Reexamining the code carefully for a rewrite does provide the opportunity to catch some bugs, but the rewrite will most likely introduce countless new bugs. It's not clear what is gained by the Rust rewrite, it's not like Rust is faster than C, it should be very similar or perhaps slower.
Honest question. Why is a Rust rewrite of coreutils getting traction? Nobody thought it’s a good idea to rewrite coreutils with Go, Java, Python, C++, etc etc. It can’t just be memory safety.
20 comments
[ 3.1 ms ] story [ 38.9 ms ] threadI like the project but beware.
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)
why ship broken implementation prematurely?
also people complaining about inclusion of it in ubuntu versions, wait till you find out about the linux kernel.
I know they claim it’s a clean implementation but cmon, there’s no way they aren’t peeking at the existing coreutils source.
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.
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.
IOW: how much does it matter?
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: