The Rust Implementation Of GNU Coreutils Is Becoming Remarkably Robust

[ClosedSource]

unfortunately, it doesn't ship man pages but instead suggests you "look online". Hopefully, that will change in the future.

[bachchain]

Also, a case conversion library?

Why pick that as your example? I wouldn't consider case conversion trivial.

[rclark]

I thought this was a replacement for Coreutils, so the current man pages should work. Ie. whether using the standard or the Rusty version should do exactly the same... Basically reinventing the wheel... Right?

[ermo]

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

Which parts of that post signifies "seem very offended" to you?

I mostly read it as a matter of fact and polite reminder that the ethical thing to do would be to remind any user serious enough to read the source code of uutils of the origins of the tools and why the origin tools were put under the GPL in the first place?

What am I missing?

[jabl]

Why pick that as your example? I wouldn't consider case conversion trivial.

It is trivial if ASCII is all you care about. Enter Unicode and suddenly, yeah, not so trivial anymore.

[atmartens]

Re: the license, my thinking was along the lines outlined here. For example:

The crucial question for a free software license is what it requires about the licensing of augmented versions. Lax, permissive licenses, including the Expat license, the X11 license and the Apache 2.0 license, permit augmented versions of the program to be nonfree. Per-file copyleft licenses such as the Mozilla Public License (MPL) likewise permit this. The result is that any intermediary can straightforwardly convert the program into nonfree software simply by augmenting it.

A copyleft license, including any version of the GNU GPL or GNU AGPL, requires augmented versions to be free under the same license -- the same requirement it applies to modification of the code.

It's a step backwards to allow conversion to nonfree software, but I applaud the technical merits of this project.

[stompcrash]

All hail our Lord and Saviour, Rust. Until the next fad language come out but we won't talk about that yet.

[dlq84]

All hail our Lord and Saviour, Rust. Until the next fad language come out but we won't talk about that yet.

If you think Rust is a fad language you're fooling yourself.

[cb88]

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

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

Why would "coreutils" be treated any differently than normal applications... after all that is what they are. Why should they get implementation specific one off implementations of reusable functionality? The crates just mean that the code can get shared with other applications... if anything it should be a boon to code quality also through more the more eyes principle.

Even most applications build such things as libraries at build time and link them together.... not sharing that work is unbeneficial.

[mmstick]

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.

Misconception. https://wiki.alopex.li/LetsBeRealAbo...otta-go-deeper