> Performance is a frequently cited rationale for “Rewrite it in Rust” projects. While performance is high on my list of priorities, it’s not the primary driver behind this change.
Is performance a frequent rationale for rewriting C applications in Rust?
Are there any security vulnerabilities in ls, chgrp, chown etc. that requires this change? Or this just more Rust evangelism?
Why oxidizer over the existing Debian alternatives system? It's designed for this exact use case and already works with many existing packages. The author's response in the comments was a basically a non-answer which doesn't exactly inspire confidence.
> Long-term, my concern would be that this may somewhat muddy the picture for which packages need substantive fixes. If it is extremely easy to just revert, what is the benefit to switching?
??? Is this not the ideal situation? It provides low friction both for moving to the new cool thing and moving back to the existing tools when you have software that hard depends on GNU coreutils. You want the changeover to be high risk because it's hard to undo? I guess that's one way to force yourself to commit but the real users on the ground won't be happy when going to the LTS is substantially more work.
This would be 3 different symlink managers in Ubuntu all used for different sets of software. The alternatives system at least has the benefit of integrating tightly with apt.
To me, this feels less about Rust and more about moving away from copyleft.
I am curious -- I asked on Discourse as well...
How this will work on CPU architectures other than x86 and Arm? Ubuntu also supports ppc64le and IBM s390. Is LLVM usefully able to built binaries from Rust code for those architectures now?
I think that all of those tools can be recompiled with Fil-C today and you get memory safety while retaining the original functionality.
While changing the core packages as a rewrite looks easy (,,just reimplement ls''), compatibility/stability may mean reproducing all the tiny but not safety critical bugs as well.
There's enough data from the Android ecosystem that it's much better to focus oxidisation on new software instead of old.
Please fix fractional scaling first. The performance is still bad.
Snaps were the first shot across the bow. This is another. Switch to Debian before this happens.
Porting of stable tools to an unstable (rapidly changing) language which can only successfully compile projects if the distro toolchain is rolling (or constantly updated outside of repos every few months, ala curl|sh, rustup, etc). Ubuntu is not a rolling distro. This is a bad match.
How about Ubuntu just sticks to their area of competency repainting Debian.
Remember when the switched they shell to dash? Not to mention, Upstart, Mir, Unity, Snap.
We can’t leave things alone
On the one hand, having less RMS and GNU software in the world is better.
On the other hand, I'd prefer for basic system tools to be provided by an established and well-funded project, and not just switch to something written in Rust because Rust is the hype these days.
I mentioned this on reddit, but AFAIK, the uutils project doesn't yet support locales: https://github.com/uutils/coreutils/issues/3997
I'm not any more a fan of POSIX locales than the next person[1], but AIUI, that seems a likely requirement for uutils to be used in a distro like Ubuntu.
I'd be curious how they plan to address this. At least from my perspective, unless uutils has already been designed to account for locales from the start (I don't know if it has), it seems likely that a significant investment of time will be required to add support for it.
[1]: https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...