Ubuntu 26.10 completes transition to Rust-based coreutils

Join the discussion

• Hacker News
• Manny comments I agree with - it's a mistake, it's a reason to leave the distro...

  I'd like to point out that Ubuntu/Canonical is now seemingly philosophically separate from the origins of GNU and Linux. If you're curious, read "Hackers" by Stephen Levy. They've lost the plot, so to speak, about the core spirit of open software and hardware, which is what gave the projects life in the first place. A philosophical understanding and unity between many, many top notch independent developers.

  Another note is how AI contributions to such libraries and programs is going to have an unknown effect on quality. It's almost like there's a business case to rip all the good FOSS written by humans out of the hands of github and apt, and curate all the best source code to ensure it remains in circulation, and extant copies are available that are not washed out by loose standards WRT AI contribs. Or if not a business case, perhaps a reasonable reaction and a good personal vendetta.

  by hermitShell
• I would be very curious about a bit more concrete and substential criticism what is bad (or good) about how the both versions, that goes beyond general arguments like:

    Just because it is Rust, it is not safe!  
    
    It worked before, don't replace it!  
    
    etc.  
    

  Not that these are not valid points of criticism, but in my opinion if we have two core utils we can (and should) pick the better one after careful continous evaluation. And if the old one is the better one on the day of the release, so be it. Having two competing solutions can have benefits for everybody looking for the best core utils they can get in the long run.

  I had to reimplement and reverse engineer old tech myself as part of my dayjob and had those engineers seen my results it probably would have improved their work as well, since I usually found oddities that they probably did not intend to be that way. This means my work on their work could be seen as another pair of eyeballs, bullet-proofing their original work, instead of seeing me as a threat. That additional pair of eyeballs is crucial to open source software.

  This is why it is sad that too much about this whole discussion feels like yet another culture war, heated on the stove of social media figures looking to convert heat into ad revenue.

  Which is why I would love to have more concrete points of technical criticism of specific bits maybe even to specific lines in the code or specific reproducable behavior.

  If we go the culture-war route nobody wins, if we discuss both solutions on their merits, we all can win.

  by atoav
• ProTip: You can switch back to Gnu coreutils on 26.04 with:

  apt install coreutils-from-gnu coreutils-from-uutils- --allow-remove-essential

  And pin it so an upgrade doesn't flip it back with:

  printf 'Package: coreutils-from-uutils\nPin: release a=*\nPin-Priority: -10\n' \ | sudo tee /etc/apt/preferences.d/uutils > /dev/null

  by linsomniac
• Has the code quality in that repo gotten to a good point then? I haven't followed it much, but last I looked[1] (which was a few years ago) almost every tool I looked at in detail had pretty bad performance or correctness issues.

  [1] https://jackson.dev/post/rust-coreutils-dd/

  by Arcuru
• You can use coreutils-from-gnu instead uutils. However since 26.04 build-essential depends on coreutils-from-uutils, it cannot be upgraded while coreutils-from-gnu is installed.

  https://bugs.launchpad.net/ubuntu/+source/build-essential/+b...

  by Malakun
• Whether you like Rust or not, it's questionable as to why Canonical would push this so much and do it in such a cavalier way.

  Will this really make coreutils more secure? I doubt it, if anything there will be a river of new bugs.

  So, again, why are they pushing Rust so much? Having Microsoft make Rust a 'Tier-1' language also doesn't bode well.

  by erminpour
• Beware that rust coreutils on 26.04 currently has really bad performance with larger block sizes. Ganeti uses "dd bs=1M" as part of a disc image transfer pipeline, and with 26.04 performance dropped from ~350MB/sec to 30MB/sec, with the dd command CPU-bounded.

  The issue seems to be that it is operating on partial buffers and then having to copy remainder of that 1M buffer around as part is consumed. Coreutils 0.11 solves that but 26.04 is at v0.8.

  I've always used "bs=32k" because decades ago I did some testing and found that seemed to be large enough that it reduced the overhead while not being so large that it caused other problems, one of the most noticeable being scheduler issues where performance went into the toilet, especially on SD or USB thumb drives. Using this also seems to work better with rust coreutils dd.

  by linsomniac
• I really don't understand why Canonical rushes this. If 'rm' can't remove all possible directory entries, that is a big issue:

    $ podman run --rm -it ubuntu:26.10
    $ apt update -y; apt upgrade -y
    $ rm --version
    rm (uutils coreutils) 0.10.0
    $ gnumkdir -p $(yes a/ | head -n $((32 * 1024)) | tr -d '\n')
    $ rm -rf a
    Segmentation fault (core dumped) rm -rf a
    $ ls a
    a
    $ gnurm -rf a
    $ ls a
    ls: cannot access 'a': No such file or directory

  by collinfunk