- cross-posted to:
- linux@programming.dev
- cross-posted to:
- linux@programming.dev
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?
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.
The Rust code isn’t closed source yet
FTFY
What the fuck is wrong with your brain?
To add to @ParetoOptimalDev@lemmy.today
The uutils are MIT licensed, simply put it means “do whatever you want with it, as long as you credit us”.
The coreutils are GPL, simply put “do whatever you want with it but only in other GPL works, also credit us”.
The coreutils make sure forks will also be open source.
While the uutils aren’t closed source, they do allow you to make closed source forks.
The uutils’ license is too permissive.