Hacker News Reader

Comment by ottah | Hacker News Reader

87.75% compatibility, as measured by a comprehensive, but incomplete test suite. They want 87.75% compatibility to be an accurate measure, but we know that in reality the real number is lower.

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.

View on HN

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.

> 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

The GPL does not state that the source code for any modification must be released immediately, it doesn't even set some kind of time limit so it technically doesn't prevent indefinite delays either.

there's even a question of how much the 12.25% of known test regressions actually matter.

I would think that the regression tests are actually the most worthwhile targets for the new project to validate against: they represent real-world usage and logic corner cases that are evidently easy to get wrong. These are not the kind of bugs that Rust is designed to eliminate.

I agree. But I don't know that the 12.25% of test regressions are regression tests or unit tests from the gnu core utils.

I believe Ubuntu simply copied and transposed a bunch of tests from gnu core utils and that's where these ultimately came from. That doesn't really mean that all these tests arose due to regressions. (for sure some probably did).

To be clear, Ubuntu did nothing. This is a third party implementation that Ubuntu decided to ship in their OS.

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.

You meant moving to MIT from GPL?

Yes. Sorry, I'm retarded.

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.

> CLI tools that are only ever run with same-user privileges?

You don't think these are ever run with sudo/runas/pkexec/run0 or otherwise invoked by a program running as root?

That said I do think things like sudo, ssh, gpg, maybe systemd, http servers like nginx and apache etc. are more valuable to replace with tools written in rust (or more generally a "memory safe language"). But that doesn't mean rewriting coreutils isn't valuable.

Because the reasons to replace coreutils with the Rust rewrite are not technological, they are political. And thus aiming to rewrite something very core and stable is the correct approach to enrage the opposite party.

> comprehensive, but incomplete

????

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

The GNU project can't go to the men's room without a thumbs up from Stallman, who is so disconnected from how real people do their computing that by his own statement he hasn't written any material amount of code in almost 20 years and can't even figure out how to update his own website, instead relying on volunteers to do so.

Stallman comes from the era when C was good enough, because computing was not a hostile environment like it is today.

GNU is never going to "rewrite it in rust" as long as he's living, and probably for several years afterwards.

In other words, it's a social problem not a technical one.

In fact, it is not a problem at all.

Let new generations of Free Software orgs come along and supplant GNU with a GBIR (GNU But In Rust), but don't insist on existing, established things that are perfectly good for who and what they are to change into whatever you prefer at any given moment.

Reply on news.ycombinator.com