uutils is doing well, but needs to be carefully managed
uutils is doing well, but needs to be carefully managed
Posted Oct 24, 2025 4:04 UTC (Fri) by Keith.S.Thompson (subscriber, #133709)In reply to: uutils is doing well, but needs to be carefully managed by pixelbeat
Parent article: Date bug affects Ubuntu 25.10 automatic updates
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.)
Posted Oct 24, 2025 6:05 UTC (Fri)
by mb (subscriber, #50428)
[Link] (1 responses)
Posted Oct 24, 2025 11:31 UTC (Fri)
by makapuf (subscriber, #125557)
[Link]
/s
Posted Oct 24, 2025 9:27 UTC (Fri)
by jengelh (guest, #33263)
[Link] (1 responses)
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...
Posted Oct 24, 2025 10:18 UTC (Fri)
by collinfunk (guest, #169873)
[Link]
$ /bin/true; echo $?
Posted Oct 24, 2025 11:09 UTC (Fri)
by pixelbeat (guest, #7440)
[Link] (2 responses)
Posted Oct 24, 2025 13:41 UTC (Fri)
by ebee_matteo (subscriber, #165284)
[Link] (1 responses)
> 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.
Posted Oct 24, 2025 13:55 UTC (Fri)
by pixelbeat (guest, #7440)
[Link]
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
Posted Oct 24, 2025 13:31 UTC (Fri)
by juliank (guest, #45896)
[Link] (1 responses)
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.
Posted Oct 24, 2025 14:58 UTC (Fri)
by pixelbeat (guest, #7440)
[Link]
uutils is doing well, but needs to be carefully managed
uutils is doing well, but needs to be carefully managed
uutils is not doing well
uutils is not doing well
0
$ /bin/true --help > /dev/full; echo $?
true: write error: No space left on device
1
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:
uutils has more overhead
$ 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
Yes agreed, though it's a different decision with uutils as the separate binaries are significantly larger.
uutils has more overhead
$ ./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 is doing well, but needs to be carefully managed
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
uutils is doing well, but needs to be carefully managed
#!/usr/bin/coreutils --coreutils-prog-shebang=true