uutils is doing well, but needs to be carefully managed

Posted Oct 23, 2025 21:12 UTC (Thu) by pixelbeat (guest, #7440)
Parent article: Date bug affects Ubuntu 25.10 automatic updates

Note ubuntu 25.10 is still using GNU for the "scary" commands like cp, mv, rm, ... They should rip that band aid off sooner rather than later, so that any data corruption possibilities are identified before ubuntu 25.10 becomes more established or the next LTS release becomes imminent. Copying a file on unix has lots of edge cases multiplied by various file sytems and even kernel bugs etc.

Then there are fundamental issues with SIGPIPE handling in all the uutils https://github.com/uutils/coreutils/issues/8919

Also there are questionable interface changes being added like 12 ways to get a sha3 https://github.com/uutils/coreutils/issues/8984

I wish them well, but this needs to be carefully managed.

uutils is doing well, but needs to be carefully managed

Posted Oct 23, 2025 23:26 UTC (Thu) by csigler (subscriber, #1224) [Link]

> I wish them well, but this needs to be carefully managed.

I cannot possibly (imaginarily) upvote this comment enough.

For those familiar with the 1976 movie "Network":

"You have meddled with the primal forces of Unix, and _you_will_atone_!!!"

Clemmitt

uutils is doing well, but needs to be carefully managed

Posted Oct 24, 2025 4:04 UTC (Fri) by Keith.S.Thompson (subscriber, #133709) [Link] (10 responses)

Oddly, /usr/bin/false is a symlink to the Rust version, but /usr/bin/true is a symlink to the GNU C version.

I wonder whether that was a deliberate decision.

("true" and "false" are bash builtins, so the commands under /usr/bin probably aren't used very often.)

uutils is doing well, but needs to be carefully managed

Posted Oct 24, 2025 6:05 UTC (Fri) by mb (subscriber, #50428) [Link] (1 responses)

Rust is not the one and only truth, yet.

uutils is doing well, but needs to be carefully managed

Posted Oct 24, 2025 11:31 UTC (Fri) by makapuf (subscriber, #125557) [Link]

Yes, this will allow easy feature testing with test true == false

uutils is not doing well

Posted Oct 24, 2025 9:27 UTC (Fri) by jengelh (guest, #33263) [Link] (1 responses)

>/usr/bin/false is a symlink to the Rust version, but /usr/bin/true is a symlink to the GNU C version

uutils-md5sum was recently broken too[1], so it is only natural to make a sensitive program like /bin/true (only one very specific return value is allowed!) be based on a known-good implementation.

[1] https://www.phoronix.com/news/Ubuntu-25.10-Coreutils-Make...

uutils is not doing well

Posted Oct 24, 2025 10:18 UTC (Fri) by collinfunk (guest, #169873) [Link]

Well, GNU true returns non-zero in some cases. :)

$ /bin/true; echo $?
0
$ /bin/true --help > /dev/full; echo $?
true: write error: No space left on device
1

uutils has more overhead

Posted Oct 24, 2025 11:09 UTC (Fri) by pixelbeat (guest, #7440) [Link] (3 responses)

Interesting, I hadn't realized /bin/true was still GNU. Perhaps this is a performance consideration, as all uutils have a larger startup overhead than their GNU equivalents, due mainly to the large multicall binary being used (due to rust binaries being significantly larger). For example:

$ time seq 10000 | xargs -n1 true
real	0m8.634s
user	0m3.178s
sys	0m5.616s

$ time seq 10000 | xargs -n1 uu_true
real	0m22.137s
user	0m6.542s
sys	0m15.561s

It irks me to see mention of rust implementations being faster, when at a fundamental level like this they're slower and add significant overhead to every command run

uutils has more overhead

Posted Oct 24, 2025 13:41 UTC (Fri) by ebee_matteo (subscriber, #165284) [Link] (2 responses)

From https://github.com/uutils/coreutils:

> If you don't want to build the multicall binary and would prefer to build the utilities as individual binaries, that is also possible.

This is a decision from the distribution to take, I would say.

uutils has more overhead

Posted Oct 24, 2025 13:55 UTC (Fri) by pixelbeat (guest, #7440) [Link] (1 responses)

Yes agreed, though it's a different decision with uutils as the separate binaries are significantly larger.

Note also that GNU coreutils can be built as a multi-call binary. Testing the performance of that here shows that the overhead is not rust specific, but rather the dynamic linker overhead loading the full set of libs linked by the multi-call binaries

$ ./configure --enable-single-binary --quiet && make -n $(nproc)

$ time seq 10000 | xargs -n1 src/true

real	0m21.595s
user	0m7.437s
sys	0m14.151s

uutils has more overhead

Posted Oct 25, 2025 8:26 UTC (Sat) by ebee_matteo (subscriber, #165284) [Link]

I agree, but it should be noted that the main reason the binaries are larger is linked to compilation flags around panic behavior (abort vs. unwind), and the fact that the stdlib is built with the generic use case in mind, and as such contains verbose backtrackes and error printing which inflate the final binary size.

I still think that this is a decision for the distribution. It's a tradeoff between being able to better debug and diagnose issues, and binary size.

If I try to use a recompiled version of Rust stdlib and panic = abort, for many binaries I get comparable sizes to the GNU version (not all, this is true, but some of them also add some features).

uutils is doing well, but needs to be carefully managed

Posted Oct 24, 2025 13:31 UTC (Fri) by juliank (guest, #45896) [Link] (1 responses)

Yes, a bunch of things disabled some scripts in .d directories by creating symlinks to /bin/true in their place.

Because we dispatch by argv[0] in the multi-call binary we then did not find the binary because the tool was invoked with the symlink name.

We do have a hardlink farm now and can resolve based on hardlink where available but it's a bit messy because it requires /proc to be mounted.

uutils is doing well, but needs to be carefully managed

Posted Oct 24, 2025 14:58 UTC (Fri) by pixelbeat (guest, #7440) [Link]

Ah right. Note the default GNU coreutils setup avoids that issue by using a wrapper script rather than symlinks. That's the default behavior with ./configure --enable-single-binary in GNU coreutils. I.e. it would install a file with the following contents at /usr/bin/true

#!/usr/bin/coreutils --coreutils-prog-shebang=true