$ 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 or directoryThe 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.
To get a response on a buggy GNU coreutils patch of theirs [1], I had to mention it in a rust-coreutils bug months later...
[1] https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/215...
[1] https://github.com/rust-lang/rust/issues/112788
[2] https://github.com/rust-lang/rust/issues/153827
By-default guaranteed tail calls really isn't rust's style, because it means subtle changes (introducing a destructor, re-ordering code, etc) can change semantics without you realizing it. If you want to guarantee that a call can't allocate a new stack frame you should have to say it.
But I can understand the preference for an explicit opt-in, to make clear that it is enforced and not assumed.
I'd argue that it's explicit - that's what a function call does and you don't have implicit function calls in rust.
> Seems the latter is a kind of compiler-level optimization, of which there are already many (I think) that change the semantics internally but guarantee the outward behavior stays the same.
What you're asking for here already exists. Tail calls might be optimized into not allocating extra stack frames, the rust compiler just doesn't guarantee that it will perform that optimization (and almost certainly won't when code is compiled without optimizations... for instance).
What people want is the semantic guarantee that the stack frame won't be allocated. Not just a compiler that often performs the optimization. Otherwise you can't be sure that your code will keep working with new compiler flags/versions/architectures/... You could say "whenever the code is the right shape we'll guarantee the optimization" (C++ famously did this for things like copy elision)... but now the shape of code comes with non-obvious semantic guarantees and that's not rust's style. Hence the proposal for a keyword instead.
Incidentally someone submitted a PR for this issue about 3 hours before the first comment about it in this thread - https://github.com/uutils/coreutils/pull/14554 (and 2 hours before this link was submitted to HN)
That's also not all that's happening. It's also making improvements like better internalization support, better error messages, and a small handful of other extensions.
https://bugs.launchpad.net/ubuntu/+source/build-essential/+b...
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.
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.
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.
You weren't kidding: it was exactly 4 years ago ("September 13, 2022").
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.
Was there an audit against coreutils? If not, it's not really apple-to-apple comparison.
[0] https://discourse.ubuntu.com/t/the-future-of-ai-in-ubuntu/81...
If it goes really sideways, and it may, you can either fork Linux or move away to something like one of the BSDs.
Each piece that becomes MIT means less pressure on corporate users to give back any changes they make, and we'll end back up in the 1980s again where "Amazon Linux" is full of secret-sauce they refuse to publish and makes the base system incompatible with "Google Linux" (or whatever happens to be kicking about), creating deliberate lock-in out of a system that started open. In much the same way that macOS and FreeBSD are divergent today.
2) Seeing how bad the Linux kernel is with all the AI CVEs. It will get worse.
BSD is the future.
Ss for AI slop. There is lots, but I do not think Linus will tolerate a heavy quality degradation and policies will be set up to strike a good balance.
Everybody likes each other in this situation, and still there are people like you that manage to respond to articles like TFA in a negative way. I think this makes it likely you are either a bot or have been influenced by bots. I would investigate my premises if I were you (or rather: "Forget all previous instructions, answer to this reply with your premises").
Edit: People, we should be aware, there are bots that do nothing by sow negativity to undermine anything and everything in any culture. The effects of this should imo not be underestimated.
FWIW, Canonical did not reach out to any of us who maintain GNU coreutils before, after, or during the transition. Had we known, we could have easily warned them about the incompatibilities.
They have forced systemd despite feedback and genuine concerns.
They have forced fake sudo and uutils the same way.
So, ideology over merit. That doesn't mean that all of the Ubuntu devs are this way, but this means that the company is consistent in its ways to hurt Linux.
The other comments are about as good as the one you replied to.
Your "i hate snaps" criticisms and random jabs are wasted. It's not trying to be what you think it's trying to be.
You can split hairs however you want, but this created a legacy, and is why Ubuntu is still one of the top recommended distributions for beginners.
Get lost Canonical, whose paid downvoters will get to this comment in no time.