[flagged]
Cool aspirations but I don't think it has significant enterprise deployments compared to RHEL or SLES.
Ubuntu 26.10 completes transition to Rust-based coreutils
71–80 of 339 posts
Re: Ubuntu 26.10 completes transition to Rust-based coreutils
#72Earlier quoted context omitted.
Does this actually matter that much for some tools when the kernel is GPL?
I does. The OP says "Linux" but means "Linux distros", which are made of thousands of "commingled" pieces (i.e. the licence of one piece does not affect the other). 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…
That doesn't matter. Amazon or whoever can add as much secret sauce as they like; people can freely use the original so there's no issue.
Re: Ubuntu 26.10 completes transition to Rust-based coreutils
#73Earlier quoted context omitted.
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.
For what it's worth there's reasonably active [1] work on implementing opt-in guaranteed tail calls - but it's not particularly fast going. LLVM (the backend rust uses) needs better support for musttail (e.g. some architectures just don't support it [2]).
[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.
Re: Ubuntu 26.10 completes transition to Rust-based coreutils
#74[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 repla…
> There were forty-four against this project in just the last audit.
Was there an audit against coreutils? If not, it's not really apple-to-apple comparison.
Re: Ubuntu 26.10 completes transition to Rust-based coreutils
#75Earlier quoted context omitted.
OIC. Rust doesn't guarantee optimizing tail recursion. How unfortunate for a language that's getting widespread adoption.
For what it's worth there's reasonably active [1] work on implementing opt-in guaranteed tail calls - but it's not particularly fast going. LLVM (the backend rust uses) needs better support for musttail (e.g. some architectures just don't support it [2]). [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,…
Not so familiar with this area, but isn't the existing behavior of implicitly creating new stacks more of a problem than implicit tail-call elimination? 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.
But I can understand the preference for an explicit opt-in, to make clear that it is enforced and not assumed.
Re: Ubuntu 26.10 completes transition to Rust-based coreutils
#76You 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.
> genuine sudo
That made me curious, it sounds related to this:
Ubuntu 26.04 Ends 46 Years of Silent sudo Passwords - 5 months ago (413 comments)
Re: Ubuntu 26.10 completes transition to Rust-based coreutils
#77Earlier quoted context omitted.
For what it's worth there's reasonably active [1] work on implementing opt-in guaranteed tail calls - but it's not particularly fast going. LLVM (the backend rust uses) needs better support for musttail (e.g. some architectures just don't support it [2]). [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,…
Not so familiar with this area, but isn't the existing behavior of implicitly creating new stacks more of a problem than implicit tail-call elimination? 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. But I can understand the preference for an explicit opt-in, to make clear that…
> implicitly creating new stacks
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.
Re: Ubuntu 26.10 completes transition to Rust-based coreutils
#78Earlier quoted context omitted.
Not so familiar with this area, but isn't the existing behavior of implicitly creating new stacks more of a problem than implicit tail-call elimination? 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. But I can understand the preference for an explicit opt-in, to make clear that…
> implicitly creating new stacks 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 n…
I see it, certain algorithms need guaranteed tail-call elimination, otherwise they are too inefficient and must be manually unrolled or rewritten to avoid blowing the stack. So a compiler optimization that is "nice to have" is not good enough.
Re: Ubuntu 26.10 completes transition to Rust-based coreutils
#79Earlier quoted context omitted.
I does. The OP says "Linux" but means "Linux distros", which are made of thousands of "commingled" pieces (i.e. the licence of one piece does not affect the other). 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…
That doesn't matter. Amazon or whoever can add as much secret sauce as they like; people can freely use the original so there's no issue.
We've balkanized Linux but you're free to use the original (which we are deliberately incompatible with, as is rival #2, rival #3, rival #4, etc. and we're all mutually incompatible with each other)
Re: Ubuntu 26.10 completes transition to Rust-based coreutils
#80Earlier quoted context omitted.
Care to elaborate?
1) Corporate forced slop acceptance by e.g. Linus and Debian. 2) Seeing how bad the Linux kernel is with all the AI CVEs. It will get worse. BSD is the future.
You were down voted, odd. But this I fully agree with, the latest thing for me is Wayland being forced upon us.