Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- I wonder about the dependency graphs of all these replacement utilities.
The vast majority of Rust projects I've seen pull in hundreds, sometimes even thousands, of external projects. If Ubuntu's rusty tools do the same, any memory safety gained would come with a greatly increased supply chain risk.
Doesn't attack surface matter?
by foresto - Was there something wrong with how they are currently written or do they just want the badge that says they converted to Rust?by hk1337
- License. GNU is copyleft and the new thing is permissive.
We might see a fracture open slowly. For me, even AGPL is not enough
- Neither. They basically see Rust as the future. They want to be able to attract young contributors and to hire young employees who are excited about Rust and who want the safety features. Bear in mind, the average age of the Linux developer is increasing. They also see technical benefits in Rust. And they are increasing test coverage of both the Rust tools and the tools written in C, IIRC.
My source is this interview with the VP of Engineering at Canonical on this topic: https://corrode.dev/podcast/s05e05-canonical/
by Flimm - We already had a problem with sudo-rs not handling all the options that previous sudo did. I am quite surprised sudo-rs is now the default even.by gramakri2
- I'm struggling to see the upside of replacing working coreutils when the replacement still has bugs that the old implementation doesn't. Rust being safer is nice, but that doesn't help much if the new rm segfaultsby 1saadcodes
- They should do like Solaris did and offer multiple different core tools in different paths, until they're up to par at least. It's not that complex of a workaround.
I don't use Ubuntu but this is huge, it's just as big as when FreeBSD switched to all BSD licensed user tools, I remember having to learn how tar worked again.
by INTPenis - 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 - 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 - You can use equivs to create a dummy coreutils-from-uutils package, as mentioned in the responses to that report.
It is frustrating that Canonical has no interest in fixing it, though. It makes it hard to take their claims seriously that you can still use GNU coreutils if you want.
by collinfunk - For now you can list dependent packages manually in apt-get install: https://packages.ubuntu.com/resolute/build-essential
But it's clear that Ubuntu will remove coreutils, genuine sudo and other tools from the future versions. It's the direction, it's ideological and thus nor merit nor our feedback will change anything here.
by egorfine - 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.by Arcuru
- Neat. I touched this code about 8 months later to avoid the per-block elapsed() call: https://github.com/uutils/coreutils/commit/cf7b90bbe7cb87099...
Mirrored the way I implemented status=progress in FreeBSD dd, though there the flag was set by a SIGALRM timer: https://freshbsd.org/freebsd/src/commit/4767c42c1146459eb751...
It would appear GNU dd 9.9 still does a call for every block. Low-hanging fruit if anyone fancies it:
dd if=/dev/zero of=/dev/null count=100000000 status=progress 51200000000 bytes transferred in 18.644004 secs (2746191200 bytes/sec) target/release/dd if=/dev/zero of=/dev/null count=100000000 status=progress 51200000000 bytes (51 GB, 48 GiB) copied, 20.8772 s, 2.5 GB/s gdd if=/dev/zero of=/dev/null count=100000000 status=progress 51200000000 bytes (51 GB, 48 GiB) copied, 23.6744 s, 2.2 GB/sby Freaky - > last I looked[1] (which was a few years ago)
You weren't kidding: it was exactly 4 years ago ("September 13, 2022").
by estebank - The reason for existence of uutils is ideological, not technical. Thus code quality is of no use for the objective.by egorfine
- 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 - Just curious, why the 'sudo tee {file} > /dev/null'?by chris_st
- 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 - MIT Licenseby monegator
- It removes a GPLv3 dependency that might stop some companies from adopting Ubuntu Core.by pantalaimon
- Canonical has been pushing its own agenda for ages, how many examples do you need?
Microsoft making Rust tier 1 is great, it means probably one day we get a VS proper support instead of VSCode only.
If you head off to Microsoft official blogs, you will find out that Microsoft already has tier 1 support for Java (ironically), Python and Go, besides the usual .NET languages and C++.
by pjmlp - >> Will this really make coreutils more secure?
In the long run yes. Sure, many logic bugs happen in Rust programs as well, but memory safety bugs are another level of hell. At least many classes of exploits will mostly be impossible. Also, Rust program failures tend to be more predictable. For example, in C/C++, if you do out of bound writes in an array or writes in a freed memory block, the behavior is undefined. The program might crash, the memory might be silently corrupted, or nothing might happen at all. In a normal (non unsafe) Rust code these kinds of issues are either prevented by static checks or become explicit runtime panics.
While the migration could be done more gradually, 26.10 is not an LTS release and is not considered stabe enough. The next LTS is 28.04, so I hope there is 1.5+ years for things to stabilize.
by senfiaj - 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 - Why are we still using dd?
Seriously, it's a weird obtuse command. Weird syntax that doesn't match anything else, and the block size shouldn't be needed 99% of the time. A modern tool should figure out a good value on its own, either by interrogating the devices at both ends, or by benchmarking, or both.
by dale_glass - How can a command which was explicitly designed to do nothing but read and write disk become CPU bound?by torginus
- 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 directoryby collinfunk - It is Year of the Linux Desktop, not Year of the Linux Cli.by tored
- It's entirely aisine and makes me avoid Ubuntu every time it is possible. And it is repeated offence, Ubuntu always tried to push the envelope in worst place and way possible
- Let them first fix Snap.by amelius
- But this is totally not a memory ownership bug! It's some other kind of bug!by nottorp