Uutils 0.0.13 Released For GNU Coreutils Replacement In Rust

[ssokolow]

Round and round and round again ! Notice how lots of stuff is rewritten every couple of years.

Hope the same thing does not happen when Bust/Dust/Gust (The super compiler released to fix Rust memory corruption - coz some n00bs failed to learn and use the language correctly ) is released.

Uutils began as people doing a Rust rewrite because they wanted a hobby/learning project that held their interest. If distros decide the result is more to their taste than GNU coreutils, that's a completely independent decision.

[ssokolow]

Tbqh I'd assume the approaches taken by a non-C implementation of coreutils would generally outperform their C counterparts because much of the speed of text processing applications is driven by the usage of the correct data structures more than anything, and I would expect it to be less obvious and considered by a C programmer especially a 1980s C programmer than a modern developer who has readily and easily accessible hashsets, tries, and such at hand.

That said stdin/stdout is the biggest bottleneck of them all when it comes to real throughput.

You'd think that, but not necessarily. Take a look at A Little Story About the `yes` Unix Command by Matthias Endler.

[xhustler]

Round and round and round again ! Notice how lots of stuff is rewritten every couple of years.

Hope the same thing does not happen when Bust/Dust/Gust (The super compiler released to fix Rust memory corruption - coz some n00bs failed to learn and use the language correctly ) is released.

[Alliancemd]

uutils/Windows is coming. You cannot call it Windows, it's uutils/Windows.

[CommunityMember]

It might be important to some that GNU coreutils is GPLv3 licensed, but uutils is MIT licenced.

And while Apple will likely not do so (they have never been especially interested in the unix cli), being MIT licensed they might just finally update their coreutils versions to bring them into the current century.

[Luke_Wolf]

Probably not favourable for uutils. From what I remember, it began as more of a programming exercise (meaning it wouldn't have started with a lot of the performance optimizations coreutils has) and I'd imagine they're probably mostly focused on getting the test suites passing.

Tbqh I'd assume the approaches taken by a non-C implementation of coreutils would generally outperform their C counterparts because much of the speed of text processing applications is driven by the usage of the correct data structures more than anything, and I would expect it to be less obvious and considered by a C programmer especially a 1980s C programmer than a modern developer who has readily and easily accessible hashsets, tries, and such at hand.

That said stdin/stdout is the biggest bottleneck of them all when it comes to real throughput.

[sinepgib]

very true indeed, though it could very well be that those two things are parallel to eachother.

They're (more or less) independent tools on a community project, so it's very likely that some "finished" tool is being optimized while the others are still in active "make it right" development.

Many people, including the contributors don't care. Many see the MIT licence as being a Freer alternative. Some small number just don't want any GNU on their linux system (eg. by using Alpine).

Hmmm, probably many contributors do care and just prefer it that way. As you said, they see it as freer.
I personally think any license is fine provided authors has the right expectations.
If the project is supposed to be by the community for the community and you want every user that makes changes to give back, use copyleft, there's no point in crying because they didn't if you explicitly gave everyone the right not to.
If it is by the community for the community but thought as a useful gift to anyone, permissive is a good idea.
If it is a way for a commercial product to be friendly (and maybe save some bucks) and it's the core of your product, use copyleft+CLA (if your product counts as derivative, otherwise just copyleft may suffice).
If it is commercial but non critical, permissive is friendlier to everyone.

Of course, there may always be philosophical differences, e.g. all-copyleft folks probably choose that path as a way to fight back proprietary software explicitly, making it not all about who gives back but about who saves work by using your software, but I think most people care about the implications for their own project only. I more or less favor copyleft because of that, but I weight how much value it really adds to them, how easy it would be to comply (again, core utils would only be a nuisance, so I don't really see using (A)GPL as making a difference) and how much convenient it makes life for the regular folks.

Grafana had an issue not long ago where their core was permissively licensed and then the competition used it as a base without giving anything back and offered cheaper products because Grafana essentially subsidized their development. They ended up making a new AGPL core to fight back. It was their mistake for picking the wrong license for the circumstances.
In cases such as core utils permissive is really a good idea: there's no incentive not to give back because the actual product will probably not be centered around those utils, but for "just users" it doesn't come with hassles such as legal departments being weary of copyleft or having to store and link the source code publicly or what not. It won't get them out of business to do so (again, not business critical), but it's an inconvenience.

[RahulSundaram]

Another rust development hi-jacked project.

There has never been any Rust development hijacked project. A from scratch reimplementation that is entirely independent of a different project is the furthest thing away from hijacking anything.

[timofonic]

Another rust development hi-jacked project.

Resistance is futile, we'll all be assimilated.

Soon the entire world will be rewritten in Rust! Rustworld!

[Developer12]

Another rust development hi-jacked project.

The time comes for every tool to be replaced.