The question is going to be how much of that unknown/untested percentage actually matters. I mean, there's even a question of how much the 12.25% of known test regressions actually matter.

> Also, I have major issues with dumping GPL userspace utilities, for an MIT license suite, that is known to not be feature complete, only, and literally only because it was written in Rust. This does not make sense, and this is not good for users.

Thinking about it, I guess I have to agree. This allows ubuntu to avoid releasing security fixing patches if they so choose. You can't do that with GPLed code. It means they can send out binary security fixes and delay the source code release for as long as they like or indefinitely. Which is pretty convenient for a company that sells extended security support packages.

To me moving from MIT to GPL is a downgrade regardless of features. Not everything is about features. Some people also care that their work can't be re-utilized as a tool by Big Corp in their march forward to subjugate their users.

Part of this project has been writing a lot of new tests, which are run on both GNU coreutils and rust coreutils. Some of these tests have found bugs in the original GNU coreutils.

This does not make sense to you because you are looking from a technological standpoint. The reason to rewrite coreutils (or sudo) in Rust is not technological, as there is no merit. Coreutuils are titanium rock stable tools that no one asked to rewrite.

And this is precisely why the worst Rust evangelists aim to rewrite it: virtue signaling with no suffering of the opposing party is not good enough.

Also, I don't really get why coreutils would be a worthwhile candidate for a Rust rewrite. A rewrite of curl/wget or sudo I can understand, but what's the security benefit to improved memory safety for CLI tools that are only ever run with same-user privileges? Even if there's an exploitable bug there, there's no avenue for privilege escalation.

> comprehensive, but incomplete

????

The gnu project is more than welcome to make its own moves away from C.

why isn't that the default?

why ship broken implementation prematurely?

In the short term, yeah 4x slower coreutils is probably worth it for memory safe code. In the long run, I’m glad rust coreutils is slowly working through these compatibility issues so we don’t have to pay for memory safety. Yeah, it'll have new bugs. And right now it’s slightly incompatible. But give it a few more years to cook. I’m sure they’ll get there.

As an aside, I find it weird how much negativity rewrites like this get. If someone decided to make a new web browser, C compiler or kernel people would be congratulating them. I really don’t understand the conservatism when it comes to Linux. Is the current implementation perfect? Should it be preserved in amber? The gnu runtime seems like a messy, badly specified hairball of hacky, inconsistent scripts to me. Some guys in a certain room in the 70s and 80s wrote some C programs. And now every bad idea they had lives in perpetuity in my /usr/bin directory? In the decades since, these tools have sprouted hundreds of weird features that almost nobody uses. And now what, people care what language it’s all written in? This code must never be changed?? Who cares.

Is Fil-C free of runtime overhead?

The problem is in the unknowns. The "unknowns" in a C implementation means arbitrary code execution and all kinds of nasty. The unknowns in a Rust implementation means a crash/denial of service.

I know which I prefer.

It's not only about memory safety.

> uutils coreutils aims to be a drop-in replacement for the GNU utils. Differences with GNU are treated as bugs.

> Our key objectives include:

> Matching GNU's output (stdout and error code) exactly

> Better error messages

> Providing comprehensive internationalization support (UTF-8)

> Improved performances

> Extensions when relevant (example: --progress)

> uutils aims to work on as many platforms as possible, to be able to use the same utils on Linux, macOS, Windows and other platforms. This ensures, for example, that scripts can be easily transferred between platforms.

Experimenting with better error messages, as test-bed for extensions that might not be able to be tried or accepted in GNU coreutils (for technical, social or other reasons), and being able to use the same tools in all major OS are very reasonable divergences from GNU's project to "justify" its existence.

The project was originally just a learning project for someone who wanted to learn Rust by reimplementing tools that were small, not a moving target and useful. From there, it grew as it found an audience of developers interested in productionalizing it. There have been coreutils ports for the languages you mention (go-coreutils, pycoreutils, coreutils-cpp, etc.), they just didn't (yet?) hit critical mass. It is a harder sell for GC-based projects in this case because they are unlikely to ever be included as part of a dirtribution's base. Lets not forget that coreutils themselves are a rewrite of previously existing tools to begin with.

Do you think it was disrespectful for the GNU project to reimplement the original tools in a different license than the original authors had written them in?

Only if you think it’s also icky for OpenJDK to have a clean room port of Java. I’m sure oracle would love to force Android and everyone else using Java to pay licensing fees in perpetuity.

It’s uncharitable to assume they’re lying. In which case, it’s perfectly ethical and legal to reimplement an existing program.

>but then taking an additional step of releasing incomplete, incompatible code as "production"

nobody runs Ubuntu's six-month releases in production. Like Fedora it's cutting edge in the literal sense of that term, and if you deploy Ubuntu anywhere in the business world you're on the LTS release.

That the rust coreutils aren't at full parity yet is explicitly mentioned in the release notes of 25.10, if you're installing a distribution with a lifespan of half a year it pretty much goes without saying you're a beta tester for the next LTS release. Like, even if everything was pristine and stable it makes no sense to use an operating system with six months of support in production.

These utilities' purpose is to replace GNU utilities. BSD utilities' purpose is not.

Not very. Most notably `env -S` doesn't work on some systems. I did get bitten by one script on Ubuntu using uutils where the script expected `uname -p` to work but it just prints `unknown` (technically legal I guess). But when I went to fix it they already had.

Probably was a bit premature for Ubuntu to enable it by default. Looking at the graph uutils will be fully compatible (or as close as makes no difference) in about 2 years, so I would have waited until then.

Still, I think most of the push-back is just the usual anti-Rust luddites.

The point is virtue signaling. There is no technical merit to it.

The point is that they get to rewrite it in their favourite language.

systemd sort of did this to certain parts and it's the worst thing that happened to Linux. Standardizing on Rust political rewrites of tar and libmagic is going to be an epic disaster and a decade of never-ending fun for Rust evangelicals.

I’m not aware of a unified plan to do this. uutils was started as a fun project, not some plan to build a Rust-only userland.

There are already many of these. fd, httpie, rg, and so on.

There is of course RustTLS that already exists and is already very advanced.

For package manager see for example AerynOS (or its new name that I can't remember).

There are lots of rust editors, terminal and otherwise.

And of course the complete Cosmic Desktop is written in Rust, so you don't have to go 'non-graphical' at all.

So AerynOS, with uutils and Cosmic is very close I would say.

The hateable part is the license. I love Rust but this is a huge step backwards.

> wait till you find out about the linux kernel

Check the extent to which this is true. Also are we rewriting good kernel code that works?

I mean, why is Ubuntu using it as default when it isnt 1.0?

How many documented and undocumented bugs does GNU coreutils ship with? 0.5.0 is explicitly a pre-stable version.

(Sure, I realize that GNUcu is old and mature enough to have been pretty thoroughly debugged by this point.)

Are they bugs, though? Or just ambiguities where they want bug-for-bug compat?

Another commenter said "dumb cases where it's 100x slower when providing unrealistic values like parsing e9000000 which is actually because it attempts to actually parse it due to bigint support instead of clamping to i128".

They test Rust coreutils against the GNU coreutils test suite, with 87.75% of the test cases passing.

https://uutils.github.io/coreutils/docs/test_coverage.html