The Rust Implementation Of GNU Coreutils Is Becoming Remarkably Robust

[phoronix]

Phoronix: The Rust Implementation Of GNU Coreutils Is Becoming Remarkably Robust

Coming about over the past two years has been uutils as a re-implementation of GNU Coreutils written within the Rust programming language. This Rust-based version of cp, mv, and other core utilities is reaching closer to parity with the widely-used GNU upstream and becoming capable of taking on more real-world uses...

https://www.phoronix.com/news/Rust-Coreutils-uutils-2023

[atmartens]

It's not licensed under the GPL, but MIT. While these might be technical replacements for GNU coreutils, mightn't the licensing difference make it tough to use as a drop-in replacement, e.g. for (otherwise GNU) Linux distributions? Is there a good rationale for this licensing decision?

[nadir]

Are they or do they plan to include any long sought after features like the progress bar patches for cp and mv?

Edit: Looks like cp and mv already have it included since last year: https://github.com/uutils/coreutils/issues/4128

[mmstick]

It's not licensed under the GPL, but MIT. While these might be technical replacements for GNU coreutils, mightn't the licensing difference make it tough to use as a drop-in replacement, e.g. for (otherwise GNU) Linux distributions? Is there a good rationale for this licensing decision?

How would the license make it tough to use as a drop-in replacement? The license only impacts software developers that are using code from the project, or writing code for the project. MIT is an OSI-approved open source license, and it is compatible with the GNU GPL. A lot of GPL software have source code dependencies licensed with it. What is the rationale for concern about the licensing decision? In fact, you're using a web browser that's comprised of a large number of MIT source code dependencies.

[Luke_Wolf]

It's not licensed under the GPL, but MIT. While these might be technical replacements for GNU coreutils, mightn't the licensing difference make it tough to use as a drop-in replacement, e.g. for (otherwise GNU) Linux distributions? Is there a good rationale for this licensing decision?

No lol. The MIT license is a permissive license that's more or less compatible with anything which actually makes the licensing requirements easier. However even then licenses don't tend to interact beyond the application layer, they mostly effect when you're using one piece of code as a library when we're talking open source code.

[moltonel]

It's not licensed under the GPL, but MIT. While these might be technical replacements for GNU coreutils, mightn't the licensing difference make it tough to use as a drop-in replacement, e.g. for (otherwise GNU) Linux distributions? Is there a good rationale for this licensing decision?

MIT is usable in more contexts than GPL. You can always use MIT software in a GPL environment, it's the other way around that can be problematic.

[kpedersen]

Is it just me or is the list of dependencies, longer in terms of lines of code than the entire C implementation of Coreutils?

Also, a case conversion library? What next? A library dependency just for left padding a string?

Gross. I dislike this style of development so much. Rust is great but these old "language package stores" need to disappear already.

[trapexit]

As someone who is reasonably pro-Rust and have written my own coreutils replacements a few times over the years... I really don't buy most of the arguments presented (at least in that slide.)

• Secure by default for memory mgmt: the most valuable thing on the list by far. Sure, this is better than not.
• Very portable: More than C? Not likely.
• Lots of crates: I don't follow this at all. Shouldn't "core utilities" not have external dependencies? This is a major negative to me. Not positive. Providing a core util's functionality *as* crates... great. Using other's for something as simple as coloration, walking directories, and temp files? Eh....
• Terrific perf: Aren't a lot of the tools already pretty well optimized? And aren't most of the optimizations fundamental? Algorithmic? Or based on OS/hardware features? Not directly related to the language? Now if this was "easier to get good performance" then I'd accept that but that's very different from stating "terrific perf".

[Barley9432]

It's not licensed under the GPL, but MIT. While these might be technical replacements for GNU coreutils, mightn't the licensing difference make it tough to use as a drop-in replacement, e.g. for (otherwise GNU) Linux distributions? Is there a good rationale for this licensing decision?

No? There's already software that every distro includes like Mesa that is licensed under MIT, some kernel modules are also dual licensed with MIT and GPL

[jabl]

Wrt the license, there are a number of free software absolutists who seem very offended by uutils being a MIT-licensed reimplementation of GNU coreutils. E.g. here by the FSF sysadmin (and nowadays IIRC a FSF board member as well): https://github.com/uutils/coreutils/issues/1781