Live data from Hacker News

Ubuntu 26.10 completes transition to Rust-based coreutils

omgubuntu.co.uk

251–260 of 338 posts

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#251

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 o…

yeah, this is a bug. And yes, it should be fixed. But I don't think it will affect many users, I mean who has a 32000 -evels deep directory on their system?

from a ground-up rewrite, in a memory safe language i expect at the very least

- A meaningful error

- not a segfault

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#252
post #70

Earlier quoted context omitted.

When triaging an issue you have to prioritise. Do you fix a problem that affects 2-3 people or one that may affect thousands?

By that logic, why even spend effort migrating from a known-working implementation to one which is known to have outstanding bugs that there isn't enough bandwidth to fix?

Hard to say, but there are legitimate reasons. One of which being they think Rust is growing while C is a shrinking language. Other could be safety (yes, yes the audit did surface bugs). Or even that having a single lib work seamlessly on Windows/Linux/MacOS/Redux/Web.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#253

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.

MIT License

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#254
post #142

People still use ubuntu when Debian and Mint exist?

Debian packages are ancient, unless you use "testing", which will be broken. That being said, Ubuntu is horrible too. The problem comes when you have to use proprietary software made by incompetent vendors, and that only works in Ubuntu.

> Debian packages are ancient

ever used backports? no need to go to sid. Flatpack/Appimage/Compile from source for the rest (on my debian machine it's just kicad that is not installed from APT, well and the couple of softwares that don't do deb)

Firmwares, that's another story, i have fedora on the laptop for that.

> The problem comes when you have to use proprietary software made by incompetent vendors, and that only works in Ubuntu If i want to do FPGA development, either ubuntu or a distro old enough to package JDK 11 (sigh) and X. not XWayland. Debian 11 was the last one to have JDK 11 i think (talk about ancient..)

Needless to say FPGA is done on the windows machine these days.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#255
post #222

Earlier quoted context omitted.

Nowadays the non-free-firmware repo is active by default, so the normal official debian image actually works. It used to be the case that the normal download from the homepage was often useless because it didn't support most networking hardware, but this is no longer the case now.

How long ago was that? I tried Debian about 15-20 years ago and I don’t recall encountering that issue. (The issue I do remember encountering was random kernel panics that I didn’t have with Ubuntu on the same machine.)

as soon as wifi became a widespread thing, you had to add the required package to the installer. It stopped being an issue with bookworm

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#256

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 so…

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.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#257

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

Just curious, why the 'sudo tee {file} > /dev/null'?

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#258

Earlier quoted context omitted.

The reason for existence of uutils is ideological, not technical. Thus code quality is of no use for the objective.

> The reason for existence of uutils is ideological, not technical. which ideology? Are people saying that there's an ideology of pushing rust for things without concern for quality? Sincere question, because I'm seeing that on this thread and I wasn't aware that that was a thing beyond the "re-write it in Rust" meme.

The original authors of uutils do not particularly care about licensing, and the Rust ecosystem defaults to MIT/Apache2. So they chose that.

Many people have decided that this decision supposedly specifically about licensing ideology.

You can make up your mind about which of the two you believe.

See also, for Ubuntu's take on this: https://news.ycombinator.com/item?id=49707948

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#259

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 so…

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.

I don’t know of a better tool that operates on raw blocks, maybe there is one.

`dd` is a real power user command, I’d prefer that it isn’t doing “intelligent” things, especially not by default.

Post reply on HN