That's why it's called the bleeding edge. Rust dev culture is 99% bleeding edge. It is not a culture of stability. It is a culture of change and the latest and greatest. The language could be used in stable ways, but right now, it's not.
But systemd projects and Rust rewrites have this one thing in common: them being pure virtue signaling they absolutely have to be noticed. And what's a better way to get noticed if not going for something important and core?
To me, Rust rewrites look like "just stop oil" road blocks - the more people suffer, the better.
annoyingly, they don't link to the actual bug in question, just say:
> Systems with the rust-coreutils package version 0.2.2-0ubuntu2 or earlier have the bug, it is fixed in 0.2.2-0ubuntu2.1 or later.
based on the changelog [0] it seems to be:
> date: use reference file (LP: #2127970)
from there: [1]
> This is fixed upstream in 88a7fa7adfa048dabdffc99451d7aba1d9e6a9b6
which in turn leads to [2, 3]
> Display the date and time of the last modification of file, instead of the current date and time.
this is not the type of bug I was expecting, I assumed it would be something related to a subtle timezone edge case or whatever.
instead, `date -r` is supposed to print the modtime of a given file:
> date --utc -Is -r ~/.ssh/id_ed25519.pub
2025-04-29T19:25:01+00:00
> date --utc -Is
2025-10-23T21:46:47+00:00
and it seems like the Rust version just...silently ignored that expected behavior?
maybe I'm missing something? if not this seems really sloppy and not at all what I'd expect from a project aiming to replace coreutils with "safer" versions.
> But seriously. Rewriting C utilities that have been battle-tested for decades in Rust might be a good idea in the long term, but anyone could have predicted short-term hiccups.
How "long term" are we talking about that rewriting battle-tested, mission-critical C utils (which, as other posters noted, in this case often have minimal attack surfaces) actually makes sense?
>> Which is why I'm glad they're doing it! It seems like the kind of thing that one can be understandably scared to ever do, and I say this as one of the folks involved with getting some Rust in the Linux kernel.
Total zealot.
Reminder that one of the uutils devs gave a talk at FOSDEM where he used spurious benchmarks to falsely claim uutils's sort was faster, only for /g/ users to discover it was only because it was locale-unaware, and in fact was much slower:
Grifters use public projects all the time for clout and security; like other public sector work, open source seems to attract a type of personality that creates their own justifications for existence. Replacing a core utility with a rewritten version is a major bonus to an individual's portfolio, even if only altruistic reasons are used to justify the task.
So, what’s the state of the art in guided state-space exploration/fuzzing?
Seems if you have a reference implementation your fuzzer should be able to do some nice white-box validation to ensure you are behaving the same as the old implementation.
26 comments
[ 3.0 ms ] story [ 46.3 ms ] threadGood luck achieving anything of long-term value this way.
But systemd projects and Rust rewrites have this one thing in common: them being pure virtue signaling they absolutely have to be noticed. And what's a better way to get noticed if not going for something important and core?
To me, Rust rewrites look like "just stop oil" road blocks - the more people suffer, the better.
PS: Disclaimer: I love Rust. I hate fanboys.
Then blame Canonical? Quit it with the Rust hate.
They've added internal features though, like better hardware support in copying and moving files.
> Systems with the rust-coreutils package version 0.2.2-0ubuntu2 or earlier have the bug, it is fixed in 0.2.2-0ubuntu2.1 or later.
based on the changelog [0] it seems to be:
> date: use reference file (LP: #2127970)
from there: [1]
> This is fixed upstream in 88a7fa7adfa048dabdffc99451d7aba1d9e6a9b6
which in turn leads to [2, 3]
> Display the date and time of the last modification of file, instead of the current date and time.
this is not the type of bug I was expecting, I assumed it would be something related to a subtle timezone edge case or whatever.
instead, `date -r` is supposed to print the modtime of a given file:
and it seems like the Rust version just...silently ignored that expected behavior?maybe I'm missing something? if not this seems really sloppy and not at all what I'd expect from a project aiming to replace coreutils with "safer" versions.
0: https://launchpad.net/ubuntu/questing/+source/rust-coreutils...
1: https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bu...
2: https://github.com/uutils/coreutils/issues/8621
3: https://github.com/uutils/coreutils/pull/8630
How "long term" are we talking about that rewriting battle-tested, mission-critical C utils (which, as other posters noted, in this case often have minimal attack surfaces) actually makes sense?
>> Which is why I'm glad they're doing it! It seems like the kind of thing that one can be understandably scared to ever do, and I say this as one of the folks involved with getting some Rust in the Linux kernel.
Total zealot.
Reminder that one of the uutils devs gave a talk at FOSDEM where he used spurious benchmarks to falsely claim uutils's sort was faster, only for /g/ users to discover it was only because it was locale-unaware, and in fact was much slower:
https://archive.fosdem.org/2025/schedule/event/fosdem-2025-6... (~15 min)
https://desuarchive.org/g/thread/104831348/#q104831479
https://desuarchive.org/g/thread/104831348/#104831809
That was a lot of noise about not much. Locale handling was added and performance got even better:
https://www.phoronix.com/news/Rust-Coreutils-0.2
A classic
> The next Ubuntu release will be called Grateful Guinea-Pig
Seems if you have a reference implementation your fuzzer should be able to do some nice white-box validation to ensure you are behaving the same as the old implementation.