Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ubuntu 26.10 completes transition to Rust-based coreutils

omgubuntu.co.uk

Post reply on HN
Print view View original

221–230 of 339 posts

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#221

Post by LtWorf »

dwattttt wrote: post #137
collinfunk wrote: post #48

Earlier quoted context omitted.

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.

You're specifically frustrated about unbounded stack recursion exhausting the stack, triggered by multiple thousands of directories? It doesn't sound like this is about multi-thousand-deep directory structures, it sounds like it's about something else. Because even diving into it, I would agree with a prioritisation decision that puts this bug down the bottom of a priority list.

This isn't the first issue with uutils.

Canonical is just rushing the switch because they want to get rid of software with GPLv3 license, not because there is any technical merit for doing so.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#222

Post by LtWorf »

PunchyHamster wrote: post #196
pjmlp wrote: post #154

Earlier quoted context omitted.

Yes, proprietary hardware support out of the box, and pre-installed option by the few OEMs that sell GNU/Linux computers.

My nvidia GPU worked just fine. Debian has non-free repo you know...

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.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#223

Post by spider-mario »

LtWorf wrote: post #222
PunchyHamster wrote: post #196

Earlier quoted context omitted.

My nvidia GPU worked just fine. Debian has non-free repo you know...

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.)

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#224

Post by spider-mario »

clhodapp wrote: post #193
spider-mario wrote: post #188

Earlier quoted context omitted.

Sure, but mutual recursion might require `goto` for example. Or an explicit state machine.

I can see how it might require an explicit state machine (keep a mutable state number and switch over the inlined bodies of what could be functions), but I'm not seeing how it could require `goto`. Are there more-complex relationships that might require it?

I meant it more in the sense that “you need one or the other” rather than “some cases require one and some other cases require the other”.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#225

Post by throw0101a »

dark-star wrote: post #21
collinfunk wrote: post #5

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?

> But I don't think it will affect many users, I mean who has a 32000 -evels deep directory on their system?

When the GNU coreutils version doesn't have this bug and thus affects zero users, why should I bother with the Rust version?

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#227

Post by throw0101a »

egorfine wrote: post #49
Malakun wrote: post #30

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

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.

> For now you can list dependent packages manually in apt-get install: https://packages.ubuntu.com/resolute/build-essential

I'm don't quite understand what this means: you can say that you want GNU coreutils when you install build-essential? How does that work on the CLI?

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#228

Post by throw0101a »

LtWorf wrote: post #221
dwattttt wrote: post #137

Earlier quoted context omitted.

You're specifically frustrated about unbounded stack recursion exhausting the stack, triggered by multiple thousands of directories? It doesn't sound like this is about multi-thousand-deep directory structures, it sounds like it's about something else. Because even diving into it, I would agree with a prioritisation decision that puts this bug down the bottom of a priority list.

This isn't the first issue with uutils. Canonical is just rushing the switch because they want to get rid of software with GPLv3 license, not because there is any technical merit for doing so.

If they want the default to be non-GPLv3 Rust-based that's fine, but some of us don't care (and want the same behaviour everywhere, like on RH-based systems we may also have) and they should leave the GNU as an option. Potentially both could be installed at the same time (it's what update-alternatives is for after all).

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#229

Post by mhluongo »

IlikeMadison wrote: post #180
LtWorf wrote: post #126

Earlier quoted context omitted.

I think ubuntu wants to kill desktop linux. No other explaination of why they push firefox inside snap, which then proceeds to constantly crash, when firefox used normally works completely fine. I haven't tried chromium but I presume it's the same issue. At work I'm forced to use ubuntu and I placed snapd on hold and added mozilla's own apt repository to my configuration to get firefox. At least in the past few month…

sandboxing a browser makes total sense. my firefox and chromium running as snaps never crashed a single time for as long as I can remember, and I use both every day, at the same time.

Both have performance issues when installed as snaps across my 24.04 and 26.04 machines.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#230

Post by jillesvangurp »

jcarrano wrote: post #216
sehw wrote: 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.

Ubuntu is basically a packages imported/synced from debian (I think they mostly cherry pick unstable) + ubuntu specific stuff.

Debian Testing is pretty much what many Debian users use on a daily basis. They pretty much invented the notion of rolling releases. Debian stable is of course not cut that often. Ubuntu has a higher frequency of updates. But still, their LTS releases are spaced two years apart. 26.10 follows the recent LTS 26.04 release, so that gives them a good 1.5 years to work on stabilizing this. I've been using Ubuntu server LTS releases for the last ten years or so with generally no major issues. There are always some minor headaches between updates but generally nothing that worries me.

The main criticism here seems to be that these packages need a bit more work or are still lacking certain important features. Getting them out in a non LTS release like this is how they get packages to be ready for LTS releases. If you need LTS now, 26.04 is what you should be using. By 28.04, this should be rock solid.

For me what's risky here is deviating from what other distros are doing. Including Debian. Ubuntu has a history of being opinionated not everything they push through being adopted with great enthusiasm (e.g. Snap). You could make the point here that waiting for Debian to pick this up would be nicer. But you could also make the point that waiting for that is a very slow process.

Post reply on HN