- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
At first I was sceptical, but after a few thought, I came to the solution that, if uutils can do the same stuff, is/stays actively maintained and more secure/safe (like memory bugs), this is a good change.
What are your thoughts abouth this?
I personally don’t see the point.
Mainly memory safety;
split
(which is also used for other programs likesort
) had a memory heap overflow issue last year to name one. The GNU Coreutils are well tested and very well written, the entire suite of programs has a CVE only once every few years from what I can see, but they do exist and most of those would be solved with a memory and type safe language.That said, Rust also handles parallelism and concurrency much better than C ever could, though most of these programs don’t really benefit from that or not much since they already handled this quite well, especially for C programs.
I fear moving away from GPL that moving to Rust seems to bring, but Rust does fix real memory issues.
Take the recent rsync vulnerabilities for example.
https://www.cyberciti.biz/linux-news/cve-2024-12084-rsyn-security-urgent-update-needed-on-unix-bsd-systems/#more-2215
At least this one in a Rust implementation of rsync would have very likely been avoided:
So you prefer closed-source code to potentially unsafe open-source code?
Already fixed, in software that’s existed for years and is used by millions. But Oh no, memory issues, let’s rewrite that in <language of the month>! will surely result in a better outcome.