Uutils 0.0.13 Released For GNU Coreutils Replacement In Rust

[quaz0r]

honestly being a fresh rewrite of some ancient utils would be the main selling point for me. did you also need to use rust to prevent yourself from accessing an array out of bounds? i mean, thats fine i guess.

[Quackdoc]

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.

I wouldn't be so sure. last I heard, it has turned into a full blown project now and I do know that many of the uutils do have preformance gains over coreutils. I just haven't benched redox utils so I don't know how they work

[ssokolow]

Linux began as a programming exercise.

And? All I'm saying is that this seems like a situation where a smart programmer would be following "Make it work, make it right, make it fast"... and the chart documenting test suite status shows they're not past the "make it right" phase yet.

[ssokolow]

I wouldn't be so sure. last I heard, it has turned into a full blown project now and I do know that many of the uutils do have preformance gains over coreutils. I just haven't benched redox utils so I don't know how they work

If that's true, fair enough. It just feels like the smart thing to do would be to prioritize getting the tests to pass first, then optimize for performance later. No point in having a fast tool if it isn't fit for purpose.

[rogerx]

Another rust development hi-jacked project.

[Quackdoc]

If that's true, fair enough. It just feels like the smart thing to do would be to prioritize getting the tests to pass first, then optimize for performance later. No point in having a fast tool if it isn't fit for purpose.

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

[Developer12]

Another rust development hi-jacked project.

The time comes for every tool to be replaced.

[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!

[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.

[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.