Live data from Hacker News

Ubuntu 26.10 completes transition to Rust-based coreutils

omgubuntu.co.uk

241–250 of 271 posts

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#241
post #119

Earlier quoted context omitted.

Yes, please. Linux distros is better with macos approach. And making appimage first class makes a lot of sense.

Appimages are bloated and unreliable. You can't guarantee that your app will run on any machine because it might depend on different system libraries. Flatpak uses shared stable runtimes that are the same everywhere and don't take up space more than once. It also comes with a native update system and sandboxing. Snap is the same thing but worse.

There's a project called "anylinux appimages" that aims to make the most compatible appimages. They also use DwarFS for faster opening and smaller file sizes.

See: https://pkgforge-dev.github.io/Anylinux-AppImages/

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#242
post #178
post #122

Earlier quoted context omitted.

Fork Ubuntu and threaten their business model, that’ll get their attention. Only half joking.

There's very little incentive to switch. When people release for Linux they almost always first/only test it works on Ubuntu - hence it's going to be the least buggy. (ex: GOG only seemingly tested games on Ubuntu) So the switching cost is buggy software. You'd need something radically different that brings enough new features to the table to make it worth it the switch and dealing with bad/non-existant support. I th…

Embrace the lock-in.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#243

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.

Rewrite it in anything that isn't GPL.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#244
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

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#245
post #142

People still use ubuntu when Debian and Mint exist?

Mint is downstream from Ubuntu still afaik. They had/have LMDE as an escape hatch, maybe they should pull the ripcord (to mix metaphors.)

Need a wider variety of people protecting Debian anyway, governance there is getting weird.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#246
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.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#247
post #122

Earlier quoted context omitted.

I did, and the original dev of the component fixed it within a few days. It was straightforward, a backwards reading of a spec, reordered. The fix is still sitting unmerged many months later. This surprised me since I thought the project was in heavy bugfix/compat mode. I won’t touch it until I see some velocity on open bugs.

Fork Ubuntu and threaten their business model, that’ll get their attention. Only half joking.

My solution was to stop using Ubuntu and move to Debian.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#248

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.

> Are people saying that there's an ideology of pushing rust for things without concern for quality?

Yes, there is. There are people who genuinely think quality does not matter as log as it is written in Rust as Rust is memory safe.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#249
Meanwhile I just booted stagex on AWS without any C code at all other than the kernel and libc.

In a dev branch we now have rust ssh, dhcp, init, job management, etc. Rust all the things. Very soon will be able to swap the kernel for Asterinas and drop the last couple libc dependencies to have a complete rust OS that is Linux binary compatible.

I wonder how many other distros will rustmax.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#250
post #120
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?

The point is that such bugs shouldn't exist in the first place. Using recursion on unbounded inputs on a programming language that doesn't support that (which are most) is an extremely classical mistake that really should be known to all programmers, especially those of low level languages that care about safety. Every time you call something recursively you should be thinking "how deep is this?".

> The point is that such bugs shouldn't exist in the first place.

That's true of every bug, but you don't have infinite time or manpower, so how do you prioritise?

Post reply on HN