uutils 0.0.20 Improves GNU Coreutils Compatibility For This Rust-Written Replacement

[ClosedSource]

And we are not talking about each license of each dependency. And how they can change.

I'm not referring to licensing. I'm just saying if you build your code from way too many external libraries, you risk pulling in bugs these library authors introduced.

[TheDcoder]

I contributed to this release!

od: fix parsing of hex input ending with E by @TheDcoder in #4983

Sorry, just wanted to say that because I'm so happy, this little issue got me started on the entire Rust journey

[Nth_man]

> And we are not talking about each license of each dependency. And how they can change.

I'm not referring to licensing. I'm just saying if you build your code from way too many external libraries, you risk pulling in bugs these library authors introduced.

Yes. I meant that you found all those problems without the added drawbacks of the licenses of each dependency. As lowflyer wrote:
One example: Your project "Adam" pulls in crate "Beta" which you found extremely useful because it has that "mogrify(stuff)" function that is absolutely amazing. But that "Beta" crate depends on crate "solvent" - which is not too much of a problem because it is small - but this one depends on "arbiter", "moab" and "dateconverter". Out of these three, "moab" pulls in some other licensed code...

Patent issues - that's a whole other bucket full of worms.

As kpedersen wrote: "Is it just me or is the[list of dependencies](https://github.com/uutils/coreutils/...ain/Cargo.lock) longer in terms of lines of code than the entire C implementation of Coreutils?"

[darkonix]

There's no reason to have yet another dependency debate. That's already been debunked here. https://wiki.alopex.li/LetsBeRealAboutDependencies

Rust projects cannot be compared to C projects using quantity of dependencies as a metric. There are entire classes of problems which cannot be abstracted in C because it lacks generics. Many more problems remain unsolved because C lacks the necessary tooling and infrastructure for publishing and sharing code for reuse.

The true extent of dependency usage in C is a hellish unmaintainable enigma. Many have built their software as if they live in complete isolation from each other. There is a widespread epidemic in the C world where there is large amounts of code duplication across projects. Much potential has been wasted because of this. It is a fatal flaw in C which Rust’s dependency management has exposed.

We don't measure our coffee by the quantity of grounds. We shouldn't do that with software either.

Thanks for the link, great article. More people should read it.

[darkonix]

Yes. I meant that you found all those problems without the added drawbacks of the licenses of each dependency. As lowflyer wrote:
One example: Your project "Adam" pulls in crate "Beta" which you found extremely useful because it has that "mogrify(stuff)" function that is absolutely amazing. But that "Beta" crate depends on crate "solvent" - which is not too much of a problem because it is small - but this one depends on "arbiter", "moab" and "dateconverter". Out of these three, "moab" pulls in some other licensed code...

There are cargo plugins to verify licenses in dependencies if that is a concern: https://github.com/EmbarkStudios/cargo-deny

Patent issues - that's a whole other bucket full of worms.

As kpedersen wrote: "Is it just me or is the[list of dependencies](https://github.com/uutils/coreutils/...ain/Cargo.lock) longer in terms of lines of code than the entire C implementation of Coreutils?"

And why is that a problem? Please read the post shared earlier by mmstick https://www.phoronix.com/forums/foru...92#post1398492

It is a very good analysis of runtime dependencies in C applications. A difference is that developers don't see them and they can't control them at build time.

[fitzie]

What I love of uutils is it's MIT license. Seriously, GPL sucks and should disappear from existence.

This post sent me down a rabbit hole of coreutils history. This talk from Rob (of busybox, and now toybox fame) is largely about the irrelevance of GPL. He doesn't have the full perspective, but he was a party to much of the GPL lawsuits, so it's interesting viewpoint. I came away much more pessimistic about the GPL, as he goes into the GPLv2 vs GPLv3 split and the fallout that has created.

https://youtu.be/MkJkyMuBm3g