Comment by josephg | Hacker News Reader

Comment by josephg | Hacker News Reader

Parent Full thread

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.

GNU utils is battle tested, well reviewed, and STABLE. That's really what I want in an OS, stability. Rust solves only one case of security issues, but it cannot solve logical errors, which there will be many of in a new software project.

I just don't see what's to gain, to suffer through years of instability, waiting for a userspace suite to mature, and reach feature parity, when we have a well understood, and safe tool set know.

Maybe in five years, when coreutils is complete, I'd be okay with Ubuntu replacing user land with it. But we're not there, and it's a problem we shouldn't have to tolerate.

Also I can't stand we're leaving GPL code behind for MIT.

Luckily, the existence of uutils doesn’t change the fact that GNU coreutils exists. In fact, it’s helped improve the stability of the GNU coreutils by clarifying intended behavior and adding test cases. So if you prefer them, you should stick to them. Nobody is taking anything from you.

So I guess to properly clarify, I absolutely do not mind that someone wants to build coreutils in Rust. I don't have a problem with Rust Coreutils existing.

The problem, and the real issue I have is that this project is being used as the default in major linux distros. Eager adoption of this project, and making it the production target does take away things from me. The interface has changed, stability is affected. Correctness is now measured against this incomplete implementation first, not the known correct, and stable GNU coreutils.

That’s not what is happening. One distro is kicking the tires on using this by default. The purpose is exactly because the GNU versions are being treated as the proper versions. Divergences from them are being fixed, so that this new version follows those. You can only do that by actually trying them out, because it’s impossible for the test suite to cover every behavior.

> That’s not what is happening. One disto is kicking the tires on using this by default.

Many people call Ubuntu flavors distributions. This includes Ubuntu developers.

Ubuntu made it default. The tire kicking analogy was incorrect.

> The purpose is exactly because the GNU versions are being treated as the proper versions. Divergences from them are being fixed, so that this new version follows those. You can only do that by actually trying them out, because it’s impossible for the test suite to cover every behavior.

You should assume everyone understands how Ubuntu's decision would benefit this project. You should assume most Ubuntu users do not care.

It is expressly described as an experiment. Making it the default does not preclude it being an experiment. It’s how you get broad enough usage to see if it’s ready. If it isn’t by the time for LTS, then it’ll be unmade as the default. That’s what an experiment is.

> It is expressly described as an experiment. Making it the default does not preclude it being an experiment.

Calling something an experiment does not make it exempt from criticism.

> It’s how you get broad enough usage to see if it’s ready.

My understanding was it was known not 100% compatible. And what did I say you should assume?

> If it isn’t by the time for LTS, then it’ll be unmade as the default.

People use non LTS releases for non experimental purposes.

Of course it’s not exempt from criticism. But suggesting something is permanent and final when it expressly is not is a poor criticism.

All software has bugs. Plus, not every bug is in the test suite. There are open bugs in all of the software shipped by every distro. Software can be ready for use even if there are know bugs in corner cases. Regular coreutils has open bugs as well.

> But suggesting something is permanent and final when it expressly is not is a poor criticism.

No one did this.

> All software has bugs. Plus, not every bug is in the test suite. There are open bugs in all of the software shipped by every distro. Software can be ready for use even if there are know bugs in corner cases. Regular coreutils has open bugs as well.

Stop speaking as if other people know nothing of software development. GNU do not break compatibility knowingly and with no user benefit.

This project is not knowingly breaking compatibility. It expressly considers the GNU behavior to be the correct one.

Canonical broke compatibility knowingly and with no user benefit when they made these utilities default in Ubuntu 25.10. The point was saying the GNU utilities had bugs was specious.

> Many people call Ubuntu flavors distributions. This includes Ubuntu developers.

You seem mad that a Linux distribution (Ubuntu) is trying this software out. Why do you care so much? Do you expect some of the programs you use to break? Have they?

If you don’t want to use uutils, I have good news. You can opt out. Or use Ubuntu LTS. Or use a different distribution entirely. I suspect you’re mad for a different reason. If all the tests passed, would you still be mad? Do you feel a similar way about angry projects like alpine Linux, which ship code built on musl? All the same compatibility arguments apply there. Musl is also not 100% compatible with glibc. How about llvm? Do you wish we had fewer web browsers?

Or maybe, is it a rust thing in particular? Like, if this rewrite was in C, C++ or go would you feel the same way? Are you worried more components of Linux will be ported to rust? (And if so, why?)

Ultimately the strength (and weakness) of Linux is that you’re not locked in to anything. I don’t understand how the existence of this software could make your life worse. If anything it sounds like it might be helping to clarify your stance on OS stability. If you want to make a principled stance there, there’s plenty of stable Linux distributions which will mirror your values. (Eg debian, Ubuntu lts, etc). Or you can just opt out of this experiment.

Given all of that, the tone I’m inferring from your comments seems disproportionate. Whats going on? Or am I misreading you?

You thought I was angry? What would you call Linus Torvalds when someone broke user space?[1]

You confused blunt responses to repetitive, condescending, specious, or false statements and anger at Canonical seemingly.

I made no objection to any software existing.

I like Rust. It was unfortunate this experiment supported stereotypes of Rust fanatics promoting Rust without respect for stability.

I reject the view users should have to wait 2 years for bug fixes and features, accept silently all experiments, or switch silently to a distribution with less 3rd party support and other issues inevitably.

The opt out process I saw required --allow-remove-essential. It would be irresponsible to recommend this.

A more responsible way to conduct this experiment would have been opt in 1st. Then phased. Then opt out for everyone. And waiting until all tests passed would have been better of course.

[1] https://lkml.org/lkml/2012/12/23/75

Ubuntu is using uutils experimentally in a non-LTS release. This kind of widespread testing will speed up the development process. Won't be long before it catches up and surpasses GNU coreutils. Then what? You want people to not use it? why?

One of the major problems with C, which like a lot of C's issues Rust just doesn't have, is that it's getting more difficult to find young, eager programmers willing to maintain a C codebase. The hassle of C outweighs the rewards, especially when Rust exists. So, ceteris paribus, development on the Rust version will outpace the C version, and you'll get more and smarter eyes on the code base.

Best to put the C code out to pasture, i.e. in maintenance mode only, with a deprecation plan in place.

It sounds like your beef is with Ubuntu for shipping some of this code. Not with the project for existing and fixing all the compatibility issues that you seem to care a great deal about.

If you want a purely gnu userland with gpl code and strong stability guarantees, Ubuntu is almost certainly the wrong distribution for you. Plenty of Linux distributions are far more stable, and won’t replace coreutils, maybe forever. (And if this is aiming to be bug for bug compatible, they won’t ever have to.)

As for the gpl, this isn’t new. there’s been bsd/mit licensed alternatives to coreutils for decades. You know, in FreeBSD and friends. It’s only aiming for 100% Linux compatibility that’s new. And I guess, shipping it in Linux. But let’s be real, the gpl v3 is a pretty toxic license. By trying so hard to preserve user freedom, it becomes a new tyranny for developers. If you build a web based startup today hosted on top of Linux, you might be in breach of the gpl. What a waste of everyone’s time. The point of opensource to me is nobody can tell me what I’m allowed to do with my computer. And that includes RMS.

well, sudo-rs had a few privilege escalation CVEs recently. So there has been some recent evidence in favor of the stability argument. I think it’s worthwhile to RiiR in general but I’ll be waiting a few more years for things to mature.

> well, sudo-rs had a few privilege escalation CVEs recently. So there has been some recent evidence in favor of the stability argument.

it would probably be a lot stronger an argument if sudo hadn’t also had a few privilege escalation CVEs recently.

> 4x slower coreutils

I doubt this is true in practice. The majority of coreutils spend the majority of their time waiting for the results of IO/syscalls. (The exception would probably be, the hashing utilities like md5sum.)

I tried md5sum and sha256sum and there was exactly zero difference in runtime (the Fil-C version of sha256sum was consistently faster, in fact..)

Why would it be faster? That seems suspicious to me.

Is all the code being compiled with the same flags? Shasum probably benefits a lot from intrinsics that are only available on newer CPU targets.

Those are also highly algorithmic tools. Probably few code paths and a lot of vector operations where competing compilers may not have much room to differentiate.

It really depends based on how shasum is implemented. If its implemented in assembly, it'll perform the same no matter how its compiled. But if its written using C code, the compiler has a lot of latitude to vectorize based on target CPU features. And not just SSE2 and AVX. Even popcnt isn't even available in the baseline x86_64 target for llvm.

The Fil-C compiler is a fork of llvm. There's no way all that garbage collection code would make fil-c faster. So if its faster, its probably using different target flags. And in that case, its not a fair benchmark comparison.

I'm sure theres a difference in the binary, for a real comparison you would need to compile the same coreutils version with the same options.

I just think the assertion that "compute-heavy" tools like sha256sum would be especially affected by Fil-C is not true, and if that was true given the "baseline slowdown" of 4x, surely it would show up in this sloppy test.

Reply on news.ycombinator.com