Live data from Hacker News

Ubuntu 26.10 completes transition to Rust-based coreutils

omgubuntu.co.uk

191–200 of 339 posts

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#191
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…

Then you would have to embrace their bad decisions, such as this one, and if you do, what’s the point?

Everything just needs to run from a container with their expected runtime environment.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#192

Earlier quoted context omitted.

What's wrong with them using the coreutils tests?

If they followed the license nothing. My uninformed knowledge is that the rust based rewrite is MIT, the originals are GPL, and you can't include GPL code in a MIT licensed project without making it GPL.

> and you can't include GPL code in a MIT licensed project without making it GPL.

Why is that? The tests are not linked to the distributed binaries. You can also distribute project sources with mixed licenses.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#193

Earlier quoted context omitted.

No algorithm requires tail-call elimination in a general-purpose language with imperative mutability. It's just another way to express iteration.

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?

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#194

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…

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

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#195

Earlier quoted context omitted.

What's wrong with them using the coreutils tests?

If they followed the license nothing. My uninformed knowledge is that the rust based rewrite is MIT, the originals are GPL, and you can't include GPL code in a MIT licensed project without making it GPL.

But you should be able to use a GPL test suite on an MIT-licensed program (or even a proprietary one, without the program needing to be under the GPL.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#196
post #154
post #142

People still use ubuntu when Debian and Mint exist?

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

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

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

I know how well it has worked in practice since the Walnut Creek CDROMs were a thing.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#198

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.

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

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#199
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?

Fashion.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#200

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…

It can fail blazingly fast!
Post reply on HN