Ubuntu 25.10's Move To Rust Coreutils Is Causing Major Breakage For Some Executables - Phoronix
I do not like this attitude towards uutils. phoronix makes a very click baity title, and comments shit on uutils, rust and ubuntu.
last time it was "extremely slow" (17x), and by the time most people reported it, a pull request had been made and merged which brought the sha function within 2x of gnu version. not ideal, but definitely not reporting worthy.
then it was sort function can not sort big files, which came from a artificial benchmark of a 4 gigabyte file with single line all consisting of character 'a' (not sure if it was a or 0 or something, but that is not relevant). gnu version finished in ~1 sec, and the rust version could not. you can not sort a single line, it is already sorted. so there is some check which uutils is missing, which could be easily added, but no, we must shit on uutils and rust because they are trying.
In this case, some md5 errors happen, but apparently problematic part is not md5, but dd (actual bug report - https://bugs.launchpad.net/ubuntu/+source/makeself/+bug/2125535).
I am not saying uutils is a perfect project, but gnu coreutils are nearly 4 decades old, where as uutils are less than 1 decade (yes the project did not start last year). There are bugs which need to be ironed out, and testing it in a non lts distribution is the best way to do that.
You could make the same kind of articles for the old coreutils if you really wanted to. Just creatively "rewording" the bugfixes from the recent 9.8 release:
tail --pid may race with reused PIDs] I feel like the reactions regarding uutils are a bit... off in general. There seem to be a lot of people who are pathologically negative towards open source projects for, frankly, bullshit reasons, like vague complaints about "Rust evangelism" (what?) or how permissive licensing is against the spirit of open source (WTF).
Phoronix isn't helping with these clickbait articles which border on content farming and their failure to moderate their comments of course, but these negative attitudes seems to cut across sites, also including Lemmy, Reddit and even Hackernews.
The uutils team seems to be doing well but it makes me sad to think about any aspiring open source devs without corporate backing reading such drivel.
You are right.
This is all going to backfire on the detractors when it turns out the Rust versions are fast, secure, and rock solid.
Streisand Effect.
Vague complaints about "Rust evangelism"
Just adding some clarity for anyone who comes by. Just like any other community, you have Rust, Rust devs, the Rust dev community, the Rust dev community social media pages, and then the public perception of those social media pages, typically driven by clickbait "articles" about errant Reddit posts. There was a fair bit of hype at one point for Rust, and given its similar applications as C++, hype around "converting" people. This became a meme a decade ago, which like all memes just became tired thought-terminating slop. Which is how it ended up with Phoronix, but still.
Agreed. Also, some of these “bugs” will just be differences in interpretation.
For example, the dd problem that prompted all this noise is that uutils was enforcing the full block parameter in slow pipe writes while GNU was not.
So, now uutils matches GNU and the “bug” is gone.
There will only be a limited number of these kinds of issues and they will be quickly harmonized. Mountains out of mole hills.
For example, the dd problem that prompted all this noise is that uutils was enforcing the full block parameter in slow pipe writes while GNU was not.
So, now uutils matches GNU and the “bug” is gone.
No, the issue was a genuine bug:
The fullblock option is an input flag (iflag=fullblock) to ensure that dd will always read a full block's worth of data before writing it. Its absence means that dd only performs count reads and hence might read less than blocksize x count worth of data. That is according to the documentation for every other implementation I could find, with uutils currently lacking documentation, and there is nothing to suggest that dd might not write the data that it did read without fullblock.
Until recently it was also an extension to the POSIX standard, with none of tools that I am aware of behaving like uutils, but as of POSIX.1-2024 standard the option is described as follows (source):
iflags=fullblock
\ Perform as many reads as required to reach the full input block size or end of file, rather than acting on partial reads. If this operand is in effect, then the count= operand refers to the number of full input blocks rather than reads. The behavior is unspecified if iflags=fullblock is requested alongside the sync, block, or unblock conversions.
I can also not conceive of a situation in which you would want a program like dd to silent drop data in the middle of a stream, certainly not as the default behavior, so conditioning writes on this flag didn't make any sense in the first place