71
this post was submitted on 25 Oct 2025
71 points (98.6% liked)
Linux
10224 readers
825 users here now
A community for everything relating to the GNU/Linux operating system (except the memes!)
Also, check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
It was just a hobby project that one person started that then got a lot of people behind it. The permissive license was just because he just copied what every other project was using.
But the permissive license is why it gained traction, otherwise who would spend so much resources on something that a decade later only accomplishes 85 percent of what coreutils does?
I don't know where you are getting "a decade" from, but assuming we are using the percentage of passing tests as our metric of the percentage of "what coreutils does"--which is dubious, but it's your metric so let's go with that for the moment--we see in the very same plot that just four years ago it only did 25 percent of "what coreutils does", so clearly significantly more has happened in the last four years than did in the previous six, rather the project being worked on equally hard for the entire time.
Also, you seem to imply that it shouldn't have taken them "a decade" to get accomplish "85 percent of what coreutils does", but that raises the question: exactly how long should it have taken exactly? Can you cite evidence that it took significantly less time for coreutils to get to the point where it accomplished "85 percent of what coreutils does" today? If not, then there is no basis of comparison we can use to decide whether a decade is a long time or not to have gotten to this point.
You are fixating on the incorrect premise. I noted that it was started a decade ago as a analogy for how labor intensive the project is. A project that by design has to mirror the behaviour of coreutils.So why are people investing the time in this? What makes it worthwhile? It's the permissive license. If uutils used GPL individuals would instead try to contribute to the much more utilised coreutils, where their contributions would be guaranteed to have an impact.
Edit: Some of the earlier issues date from 2013, so it has been a decade, although it probably was very obscure at the time.
So the fact that it is written in Rust has absolutely nothing to do with it?
Being written in Rust has mixed effects. Rust is still less mainstream than C, so fewer people can contribute. However, it does attract more interest because it's different.
However, the reasons why you create/contribute to new-but-similar projects is to add functionality that the original project doesn't have. By nature a coreutils replacement has to behave like coreutils or else it will break many configurations. This severely limits the functionality you can provide. So why are people (and Canonical) contributing so much labor to something that still doesn't function as intended?
I say it's the licensing. I say this as someone who regularly gets requests to change the licensing of my software (more than any feature request). I think licensing is a big deal, and most software devs recognize that.
Yes, it's "different". That is all that it has to offer: it's "different". There is no other reason why people might be interested in it.
Why is that the only reason to motivate someone to do such a thing?
Maybe we should take them that they word that they are genuinely think that coreutils would be better if it were written in Rust? Why is that such a radical possibility?
Yes, I have noticed that you are very big on saying what others' motivations are.
"Take them at their word"
Who? Has there been a survey of contributors?
"Genuinely think that coreutils would be better if it were written in Rust"
I feel like the skill-level of the contributors is high enough that they would not be so naive.
Programs in different languages can compile to the same machine code. Any advantage would be in language constructs. But if you already have an existing C implementation what advantage do you do from a Rust implementation?
I personally write in 3 languages: Rust, C++, and Fortran ( or rarely SPARK). I don't port my code across languages, because there is no advantage. If I wanted it better, I would work on my existing codebase.
Porting really only helps if the original language was hindering development, deployment or runtime. These arguments don't really hold with C, a fast, low-dependency language that is more widely used than Rust.
I think they would argue that it would be the perceived security that rust has. But I agree with your point and wonder if it will really deliver on those goals.
Didn't know its been a whole decade.