Check the extent to which this is true. Also are we rewriting good kernel code that works?
The fallacy here is that code is either "good code that works" or "bad code that needs to be rewritten". It doesn't work like that. "If it aint broke don't fix it" is actually terrible advice.
Rust, by itself, isn't a panacea to add formal verification but one leg on the footstool of formal verification methodologies to produce safe(r/ish) software rather than subtly buggy software that's difficult to prove correct and more expensive to maintain.
"If it aint broke don't fix it" =~= "I've never gotten into an accident until now, so airbags and seatbelts are pointless." ==> reactive methodology / failure / hubris
We want to give up good things to get better things.
What is the vision for improving these tools with rust? What user benefit are they promising?
I’ve heard nothing but nebulous arguments about memory or security purity. There is no insight into how to do them better or faster; and in most cases they have demonstrated they didn’t even understand them fully to begin with, such as missing locales.
There isn’t even subjective value for users demanding it, it’s driven by rust developers.
From their README, they promise better error messages, extensions when relevant (example: --progress), and Linux, macOS, Windows and other platforms support. It is my understanding that the GnuWin32 coreutils were last updated in 2017 and had some subtle differences to regular GNU coreutils, so that's one set of users for whom there's clear benefit. Faster speed could be accomplished if architectural changes are viable, but for many of these tools they are IO-bound.
Does the Linux kernel ship with rather experimental features as default? When was the rule not to break user space revoked?
If it’s not ready, they’ll roll it back.
Part of why you have to do something like this is because the test suite just isn’t comprehensive, nor should we expect it to be. Real world usage is what shakes out the long tail of bugs. You just have to have some sort of stage like this in order to get things into a good state.
Did 100% of tests pass when Ubuntu made this decision? My understanding was no.
In other words, there may be more serious bugs not in the test suite than the ones that aren’t passing that are in the suite. And you only find that out through real usage.
This standard may be justified when there is significant benefit. There is not in this case. And some projects have stricter standards.[1]
> In other words, there may be more serious bugs not in the test suite than the ones that aren’t passing that are in the suite. And you only find that out through real usage.
You should assume everyone understands how Ubuntu's decision would benefit this project. You should assume most Ubuntu users do not care. You replied to a comment which told you this before.[2]
For example, sort has an open PR on it right now.
And this project should be considered then. Not before.
This is a horrible mindset for developing software people are supposed to rely on.
Must I repeat? You should assume everyone understands how Ubuntu's decision would benefit this project. You should assume most Ubuntu users do not care.
> Nothing has been replaced yet.
Do you believe non LTS releases are not releases? Do you believe defaults do not matter? Do you believe --allow-remove-essential is safe and should be recommended to all users?
They will absolutely not roll it back, not matter how broken they are.
The reasons to switch from coreutils to the Rust rewrite are purely political.
also people complaining about inclusion of it in ubuntu versions, wait till you find out about the linux kernel.