- cross-posted to:
- linux@lemmy.ml
- cross-posted to:
- linux@lemmy.ml
You must log in or # to comment.
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.
I think that people are negative towards rust utils, not because of rust or attachment to an old software but because they are not licensed under GPL or another copyleft license. Even if they become faster and more stable in the future, this is a flaw that will not be ignored.
Tell me one time when GNU coreutils being GPL has had any effect whatsoever.
I am not sure how to answer that. Are you asking me to give you an example that the GNU coreutils were not used in a closed sourced s/w?
No, an example where a modification to coreutils was open sourced by a commercial company that might otherwise not have.
The GPL has been reasonably effective in some cases like the Linux kernel and KHTML at getting companies to release their modifications. But I don’t see that as being significant for coreutils because a) most companies would have zero need to modify them, and b) they could just use the BSD versions if they really wanted.
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
fullblockoption is an input flag (iflag=fullblock) to ensure thatddwill always read a full block’s worth of data before writing it. Its absence means thatddonly performscountreads and hence might read less thanblocksize x countworth of data. That is according to the documentation for every other implementation I could find, withuutilscurrently lacking documentation, and there is nothing to suggest thatddmight not write the data that it did read withoutfullblock.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
ddto 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
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:
- GNU Core Utilities Are Causing Failures [when copying between NFS and non-NFS filesystems with ACLs]
- GNU Core Utilities May Cause Data Corruption [with copy ranges larger than 2 GiB]
- Correctness Bugs Found in GNU Core Utilities [
tail --pidmay race with reused PIDs]
I feel like the reactions regarding
uutilsare 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
uutilsteam seems to be doing well but it makes me sad to think about any aspiring open source devs without corporate backing reading such drivel.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.
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.
