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?
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.
See other comments: all these rewrites are not using the GPL but rather permissive licenses like MIT. Bye-bye FOSS (in those ecosystems).
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.
Maybe.
Still, there are other sources of bugs beyond memory management.
And i’d rather have GPL-ed potentially unsafe C code to… closed-source Rust code.
The Rust code isn’t closed source, but I’d strongly prefer a coreutils replacement to use GPL over MIT as well.
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.