Hmm, this doesn’t make sense. You simply don’t replace utilities with many decades of maturity and that “just work” with something that is not as mature. It will open all users of the distro to all sorts of subtle and not so subtle bugs. I for one don’t want to find myself staring at a mysterious segfault when I want to build the latest version of nodejs or flash a microcontroller. It’s such a pity; I have used Ubuntu for close to 23 years.
Ubuntu 26.10 completes transition to Rust-based coreutils
101–110 of 339 posts
Re: Ubuntu 26.10 completes transition to Rust-based coreutils
#102Re: Ubuntu 26.10 completes transition to Rust-based coreutils
#103Earlier 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…
8MB is the default per-thread stack size from glibc, also seems to be the default "ulimit" from pam or the kernel, I'm not sure. So for the main/default thread (or if not using threads) the process can use setrlimit() and for threads it can use pthread_attr_setstacksize() to get bigger stacks if it knows it may need them.
8MB is pretty huge though; musl libc is famous for defaulting to much smaller per-thread stack size of 128KB (to avoid over-committing lots of memory when there are many threads - the main dev is really principled/opinionated on this topic, but again there are a few ways for applications to explicitly size their stacks as large as they need). Linux kernel threads get a bit less than 16KB!
Re: Ubuntu 26.10 completes transition to Rust-based coreutils
#104Re: Ubuntu 26.10 completes transition to Rust-based coreutils
#105Hmm, this doesn’t make sense. You simply don’t replace utilities with many decades of maturity and that “just work” with something that is not as mature. It will open all users of the distro to all sorts of subtle and not so subtle bugs. I for one don’t want to find myself staring at a mysterious segfault when I want to build the latest version of nodejs or flash a microcontroller. It’s such a pity; I have used Ubunt…
then install the other tool. no one is holding a gun to your head. it isn't windows.
Re: Ubuntu 26.10 completes transition to Rust-based coreutils
#106Earlier 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,…
> because it means subtle changes (introducing a destructor, re-ordering code, etc) can change semantics without you realizing it. No, it won't change semantics - if you say @musttail or similar, it will simply fail to compile if you, say, introduce a destructor - the semantics will not subtly change.
Incorrect. `become` does change drop order - https://play.rust-lang.org/?version=nightly&mode=debug&editi....
Re: Ubuntu 26.10 completes transition to Rust-based coreutils
#107Earlier quoted context omitted.
They need to kill snap ...
Yes, please. Linux distros is better with macos approach. And making appimage first class makes a lot of sense.
I'll avoid it at this point anyway. The Rust coreutils is another reason for that. Snap, monetizing updates, telemetry, enough is enough.
Re: Ubuntu 26.10 completes transition to Rust-based coreutils
#108Earlier quoted context omitted.
[flagged]
> Ubuntu devs have been nothing but good FOSS citizens 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.
“Hurd Linux”? Maybe leave that judgement to Torvalds.
Canonical is a company they do what the CEO wants. And you are free to do what you want.
Quick question: are the fruits of your labor mostly given away for free?
Re: Ubuntu 26.10 completes transition to Rust-based coreutils
#109Everything online reminds of when Ubuntu switched to dash for init scripts or something. Good times.
Re: Ubuntu 26.10 completes transition to Rust-based coreutils
#110Earlier quoted context omitted.
> because it means subtle changes (introducing a destructor, re-ordering code, etc) can change semantics without you realizing it. No, it won't change semantics - if you say @musttail or similar, it will simply fail to compile if you, say, introduce a destructor - the semantics will not subtly change.
Incorrect. `become` does change drop order - https://play.rust-lang.org/?version=nightly&mode=debug&editi... .
That's not implementing tail calls breaks things, that's bad design of implementing tail calls breaking things.
The whole idea of "let's change semantics to make it easier" is dumb.
If you want guaranteed tail calls, change your code until it works.