Which makes sense because in 2025 people have grown tired of lack of improvement so that some esoteric ass compiler from the 90s still works or someones 30 year old bash script still functions.

Pros and Cons either way for better or worse depending on your perspective.

As is the norm for HN and Rust commentary - any slight criticism is met with fury and downvotes.

> Rust still has a very "Ready to make breaking changes on a whim" reputation

No it doesn't. What on earth are you talking about?

I would say that Canonical is more at fault in this case.

I'm frankly appalled that an essential feature such as system updates didn't have an automated test that would catch this issue immediately after uutils was integrated.

Nevermind the fact that this entire replacement of coreutils is done purely out of financial and political rather than technical reasons, and that they're willing to treat their users as guinea pigs. Despicable.

> deliberately introduced regression

> deliberate and wrong decision

Yeah... I hope "we" will not switch to it just because it is written in Rust. There is much more than just the damn language behind it.

It's wrong (and coreutils get it right) but I don't see why it would have to be deliberate. It could easily just not occur to someone that the code needs to be tested with invalid options, or that it needs to handle invalid options by aborting rather than ignoring. (That in turn would depend on the crate they're using for argument parsing, I imagine.)

It certainly doesn't look intentional to me- it looks like at some point someone added "-r" as a valid option, but until this surfaced as a bug, no one actually implemented anything for it (and the logic happens to fall through to using the current date).

To play devil's advocate, who knows what kind of madness people are handing off to subprocess.run(["date"]) et al. They shouldn't, but I'd bet my last dollar it's out there.

I can certainly understand it for something like sudo or for other tools where the attack surface is larger and certain security-critical interactions are happening, but in this case it really seems like a questionable tradeoff, where the benefits in this specific case are abstract (theoretically no more possibility of any memory-safety bugs) but the costs are very concrete (incompatibility issues; and possibly other, new, non-memory-safety bugs being introduced with new code).

EDIT: Just to be clear, I'm otherwise perfectly happy that these experiments are being done, and we should all be better off for it and learn something as a result. Obviously somebody has assessed that this tradeoff has at least a decent probability of being a net positive here in some timeframe, and if others are unhappy about it then I suppose they're welcome to install another implementation of coreutils, or use a different distro, or write their own, or whatever.

Untrusted input is often stored in files. Coreutils tools are often used to operate on those files.

As an obvious example, I sometimes download files from the Internet, then run coreutils sha256sum or the like on those files to verify that they're trustworthy. That means they're untrusted at the time where I use them as input to sha256sum.

If there's an RCE in sha256sum (unlikely, but this is a thought experiment to demonstrate an attack vector), then that untrusted file can just exploit that RCE directly.

If there's a bug in sha256sum which allows a malicious file to manipulate the result, then a malicious file could potentially make itself look like a trusted file and therefore get past a security barrier.

Maybe there's no bug in sha256sum, but I need to base64 decode the file before running sha256sum on it, using the base64 tool from coreutils.

If you use your imagination, I'm sure you yourself can think up plenty more use cases where you might run a program from GNU coreutils against untrusted user input. If it helps, here's a Wikipedia article which lists all commands from GNU coreutils: https://en.wikipedia.org/wiki/GNU_Core_Utilities#Commands

EDIT: To be clear, this comment is only intended to explain what the attack surface is, not to weigh in on whether rewriting the tools in Rust improves security. One could argue that it's more likely that the freshly rewritten sha256sum from uutils has a bug than that GNU sha256sum has a bug. The statement "tools from coreutils are sometimes used to operate on untrusted input and therefore have an attack surface worth exploring" is not the same as the statement "rewriting coreutils in Rust improves security". Personally, I'm excited for the uutils stuff, but not primarily because I believe it alone will directly result in significant security improvements in Ubuntu 25.10.

I reported a segfault in "tac" a number of years ago.

You don't attack coreutils. You attack the scripts. In this case it was an update script that failed because of an incompatibility. It's not too hard at all to imagine one failing in an exploitable way.

Honestly, Rust-related hilarity aside, this project was a terrible, terrible idea. Unix shell environments have always been ad hoc and poorly tested, and anything that impacts compatibility is going to break historical code that may literally be decades old.

See also the recent insanity of GNU grep suddenly tossing an error when invoked as "fgrep". You just don't do that folks.

Fair enough. My gut sense is that C functions are simpler than shell commands, with a handful of parameters rather than a dozen or more flags, and this bug supports that -- they forgot to implement a flag in "date." But I haven't tried to do either, so I could be wrong.

Folks also run into compatibility issues with musl as well. The biggest I recall was an issue with DNS breaking because musl didn’t implement some piece.

If it was only for that, they could use/improve busybox, which has the same license as the kernel (GPLv2).

Perhaps it is also so they can be used in closed source systems (I have uutils installed on my Windows system which works nicely).

If that's really the case, I wish they would just come out and say it and spare the rest of us the burden of trying to debate such a decision on its technical merits. (Of course, I am aware that they owe me nothing here.)

Assuming this theory is true then, what other GPLv3-licensed "core" software in the distro could be next on their list?

  This would let them sell to companies who want to only permit signed firmware images to run on their devices, which isn't allowed under GPLv3.

How is this not allowed under GPLv3?

There's the BSD coreutils too.

Wow. Maybe I'm missing something but it seems really weird to replace a tool with a rewrite that doesn't pass the test suite!

I mean, how long did they take to realize that the more(1) they shipped had no equivalent in GNU coreutils at all? Its from util-linux: https://github.com/uutils/coreutils/issues/8975

Doesn't look like people who do their homework

If it's not passing the test suite, then why is it even considered for inclusion in a distribution like Ubuntu?

Ubuntu is likely used by 10s of millions of servers and desktops. I'm not sure why this kind of breakage is considered acceptable. Very confusing.

FWIW, the first test in the coreutils test suite covering the `date -r` case was added... 5 hours ago: https://github.com/coreutils/coreutils/blob/master/tests/dat...

I don't know what the code coverage of coreutils' test suite is, but my guess is that it's not spectacular.

Oh, you mean specifically GPL v3 license, not any GPL license.

Yeah, broad tivoisation and patent clauses make it a problem, because making any patent litigation on unrelated grounds has potential to lose ability to ship the entire OS.