Live data from Hacker News

Ubuntu 26.10 completes transition to Rust-based coreutils

omgubuntu.co.uk

61–70 of 270 posts

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#62
post #52

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/

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

I’m a huge proponent of Rust and generally lean a lot closer to the RIIR mentality than most, but this effort seems to be such a waste of effort and resources.

There have been a dozen CVEs reported against all of coreutils in the past twenty years. The most recent audit of uutils-coreutils turned up forty-four CVEs.

By all appearances they’re replacing battle-tested and fundamental tooling which hasn’t been a problem with extremely amateurish Rust. The threading highlighted in the linked post above seems pretty egregious.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#63

[flagged]

There have been twelve CVEs reported against coreutils in the past twenty years.

There were forty-four against this project in just the last audit.

I am all for RIIR in cases where it makes sense. This does not even remotely appear to be one of them. By all appearances the quality of the code is extremely amateurish at best. coreutils has not been a significant source of vulnerabilities in the past, and they’re replacing it with code written by amateurs that performs worse and already has a worse security track record.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#64
post #55

Earlier quoted context omitted.

It's important to remember that this is a story about Ubuntu, and not Linux, and they are two very different projects with different motivations.

It does not matter. Both (Ubuntu [0], and the Linux Kernel [1]) use, build with and in some cases promote using LLMs. [0] https://discourse.ubuntu.com/t/the-future-of-ai-in-ubuntu/81... [1] https://lwn.net/Articles/1041694/

True, and that's a bummer, but it's the decision of the maintainers of those projects to make.

If it goes really sideways, and it may, you can either fork Linux or move away to something like one of the BSDs.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#65

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?

What programmer or programming language can't iterate a loop more than 32000 times?!

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#66

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…

I mean, that should work... but you can see why that would be considered low priority right?

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#67
post #65

Earlier quoted context omitted.

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?

What programmer or programming language can't iterate a loop more than 32000 times?!

It's a stack overflow which means it's using recursion and for historical reasons that don't make sense any more, stacks are teeny tiny on 64-bit Linux - apparently only 8 MB on Linux! I'm not sure why they don't raise it to something reasonable like 4 GB. I guess because they want consistency with 32-bit? Maybe we can finally change it if/when they phase out support for 32-bit Linux. Apparently it might not be that far away:

https://lwn.net/Articles/1035727/

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#68
post #65

Earlier quoted context omitted.

What programmer or programming language can't iterate a loop more than 32000 times?!

It's a stack overflow which means it's using recursion and for historical reasons that don't make sense any more, stacks are teeny tiny on 64-bit Linux - apparently only 8 MB on Linux! I'm not sure why they don't raise it to something reasonable like 4 GB. I guess because they want consistency with 32-bit? Maybe we can finally change it if/when they phase out support for 32-bit Linux. Apparently it might not be that…

OIC. Rust doesn't guarantee optimizing tail recursion. How unfortunate for a language that's getting widespread adoption.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#69
post #62

Earlier quoted context omitted.

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

I’m a huge proponent of Rust and generally lean a lot closer to the RIIR mentality than most, but this effort seems to be such a waste of effort and resources. There have been a dozen CVEs reported against all of coreutils in the past twenty years. The most recent audit of uutils-coreutils turned up forty-four CVEs. By all appearances they’re replacing battle-tested and fundamental tooling which hasn’t been a problem…

Same here. Love Rust. Hate rust rewrites.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#70
post #65

Earlier quoted context omitted.

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?

What programmer or programming language can't iterate a loop more than 32000 times?!

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