Not sure if I (as an unsuspecting Ubuntu user) am really ok with this. I'm not saying they should wait until version 1.0 (currently uutils/coreutils is at 0.2.2), but at least until the green line reaches the blue line in this graph: https://github.com/uutils/coreutils?tab=readme-ov-file#gnu-t...
Of course, "exotic" bugs might happen (not sure how exotic the bug that caused this issue was), but can a software really be considered production-ready if it still fails part of the testsuite of the software it should replace? I don't think so...
That's because they added new tests to catch these cases. I recall seeing someone mention in a comment here that coreutils didn't have a test for this either.
So it is reassuring that these things actually get documented and tested.
You are ok about the core utils being replaced by a rewrite for no obvious reason and said rewrite being so broken that an allegedly stable distribution actually can’t properly update?
I have to say I'm rather more worried about the apparent lack of testing that their auto-update mechanism is actually updating anything (given how long it took them to notice that symptom), than that they're replacing some software with a not yet quite complete rewrite in their less-stable non-lts edition.
Obvious reason is to have less bugs in the long run. Temporary increase during transition is expected and is not ideal, but after that there should be less of them.
> Sudo has released a security update to address a critical vulnerability (CVE-2025-32463) in its command-line utility. This vulnerability allows an attacker to leverage sudo's -R (--chroot) option to run arbitrary commands as root, even if they are not listed in the sudoers file.
People start making sudo more secure by replacing it with sudo-rs
My expectation would be that every bug in a Rust replacement is going to receive the brightest spotlight that can be found.
If the rest of coreutils is bug free cast the first stone.
I do not think reimplementing stuff in Rust is a bad thing. Why? Because reimplementing stuff is a very good way to througly check the original. It is always good to have as many eyeballs om the code as possible.
C is a bad language in many respects, and Rust greatly improves on the situation. Replacing code written in C with code written in Rust is good in and of itself, even if there are some costs associated with the transition.
I also don't think that Rust itself is the only possible good language to use to write software - someone might invent a language in the future that is even better than Rust, and maybe at some point it will make sense to port rust-coreutils to something written in that yet-undesigned language. It would be good to design software and software deployment ecosystems in such a way that it is simply possible to do rewrites like this, rather than rely so much on the emergent behavior of one C source code collection + build process for correctness that people are afraid to change it. Indeed I would argue that one of the flaws of C, a reason to want to avoid having any code written in it at all, is precisely that the C language and build ecosystem make it unnecessarily difficult to do a rewrite.
I'm not, because while operating a fleet of systems, you assume some of the parts are so reliable that you don't look into them when problems arise.
These kinds of bugs might not bug end users much, but when it becomes a fleet-wide problem, it becomes crippling.
I'm debugging a problem on a platform since this morning. At the end of the day it turned out to be the platform is sending things to somewhere it's explicitly told not to.
Result? Everything froze, without any errors. System management is hard to begin with. It becomes really hard when the tools you think you can depend breaks.
Also, consider what would be the uproar if the programming language was something else than Rust. The developers would be crucified, burned with flamethrowers, reincarnated, and tortured again until they fed-up and leave computers and start raising chicken at an off-grid location.
rob74|4 months ago
If you look at "date" specifically on https://uutils.github.io/coreutils/docs/test_coverage.html, it looks much worse than the overall graph suggests: 2 tests passing, 3 tests skipped, 3 with errors. Not really reassuring, right?
Avamander|4 months ago
That's because they added new tests to catch these cases. I recall seeing someone mention in a comment here that coreutils didn't have a test for this either.
So it is reassuring that these things actually get documented and tested.
StopDisinfo910|4 months ago
I mean, all good then.
gpm|4 months ago
zigzag312|4 months ago
Obvious reason is to have less bugs in the long run. Temporary increase during transition is expected and is not ideal, but after that there should be less of them.
It's not like C version didn't have any bugs:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;d...
jorvi|4 months ago
People start making sudo more secure by replacing it with sudo-rs
You: "why are we rewriting old utilities?"
compiler-devel|4 months ago
atoav|4 months ago
If the rest of coreutils is bug free cast the first stone.
I do not think reimplementing stuff in Rust is a bad thing. Why? Because reimplementing stuff is a very good way to througly check the original. It is always good to have as many eyeballs om the code as possible.
perching_aix|4 months ago
One can say a lot about the reason, but that it would not be obvious, is certainly an unlikely one.
ramon156|4 months ago
JuniperMesos|4 months ago
I also don't think that Rust itself is the only possible good language to use to write software - someone might invent a language in the future that is even better than Rust, and maybe at some point it will make sense to port rust-coreutils to something written in that yet-undesigned language. It would be good to design software and software deployment ecosystems in such a way that it is simply possible to do rewrites like this, rather than rely so much on the emergent behavior of one C source code collection + build process for correctness that people are afraid to change it. Indeed I would argue that one of the flaws of C, a reason to want to avoid having any code written in it at all, is precisely that the C language and build ecosystem make it unnecessarily difficult to do a rewrite.
bayindirh|4 months ago
These kinds of bugs might not bug end users much, but when it becomes a fleet-wide problem, it becomes crippling.
I'm debugging a problem on a platform since this morning. At the end of the day it turned out to be the platform is sending things to somewhere it's explicitly told not to.
Result? Everything froze, without any errors. System management is hard to begin with. It becomes really hard when the tools you think you can depend breaks.
Also, consider what would be the uproar if the programming language was something else than Rust. The developers would be crucified, burned with flamethrowers, reincarnated, and tortured again until they fed-up and leave computers and start raising chicken at an off-grid location.
hulitu|4 months ago
at Microsoft. /s
rustdebacletime|4 months ago
[deleted]