[HN Gopher] Rust Coreutils 0.5.0 Release: 87.75% compatibility w...
___________________________________________________________________
Rust Coreutils 0.5.0 Release: 87.75% compatibility with GNU
Coreutils
Author : maxloh
Score : 63 points
Date : 2025-12-14 16:40 UTC (3 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| akagusu wrote:
| With you want 100% compatibility with GNU Coreutils + memory
| safety just compile Coreutils with Fil-C. 100% compatibility with
| 0 rewrite.
| bfrog wrote:
| Is Fil-C free of runtime overhead?
| f_devd wrote:
| No, it's gc-like. Up to 4x slowdown iirc
| westurner wrote:
| To better port C to Rust: 3C (Checked C), c2rust, Crown
| ownership analysis, RustMap, c2saferrust (LLM), Laertes
| testdelacc1 wrote:
| The run time overhead is 2-4x.
| bitbasher wrote:
| 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.
| yjftsjthsd-h wrote:
| > The "unknowns" in a C implementation means arbitrary code
| execution and all kinds of nasty.
|
| In Fil-C?
| stefan_ wrote:
| There is no "arbitrary code execution and all kinds of nasty"
| in the Fil-C version and it profits from the decades spent
| fixing all the logic bugs, races, environment variable mess
| in coreutils.
|
| Meanwhile, the Rust version of course is vulnerable to all of
| those: https://ubuntu.com/security/notices/USN-7867-1
| josephg wrote:
| 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.
| wavemode wrote:
| > 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.)
| ottah wrote:
| 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.
| steveklabnik wrote:
| Luckily, the existence of uutils doesn't change the face
| 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.
| jeffbee wrote:
| Another way to pitch the same result is rust coreutils 0.5.0
| ships with 88 documented bugs, in addition to the usual unknown
| ones.
|
| I like the project but beware.
| Sharlin wrote:
| 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.)
| steveklabnik wrote:
| The uutils project has found bugs in upstream, added extra
| tests, and clarified behavior. It's helped both projects
| improve.
| josephg wrote:
| Also bear in mind these tools have a long tail of obscure
| features that aren't used much. Theres a useful subset of
| coreutils that is common across gnu coreutils, busybox and
| FreeBSD & macOS. Full coreutils compatibility is laudable -
| and of course needed if it'll ever be a viable replacement.
| But most shell scripts people actually write probably
| already work on top of this port.
| throwaway613745 wrote:
| If you want 100% compatibility:
|
| sudo apt purge --autoremove --allow-remove-essential coreutils-
| from-uutils # reinstalls gnu coreutils
|
| sudo update-alternatives --config sudo # can switch back to
| regular sudo from sudo-rs
|
| (for Ubuntu 25.10)
| bgwalter wrote:
| Who is declaring the compatibility percentage? Given that GNU
| coreutils is GPL and Rust Coreutils is MIT, they must implement
| clean room development practices.
| maxloh wrote:
| 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
| kachapopopow wrote:
| I really don't understand the hate, it's not 1.0 and majority of
| unsupported cases probably haven't seen use since 1990's and
| especially 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.
|
| also people complaining about inclusion of it in ubuntu versions,
| wait till you find out about the linux kernel.
| mynameismon wrote:
| I mean, why is Ubuntu using it as default when it isnt 1.0?
| steveklabnik wrote:
| Ubuntu is evaluating it as the default in order to see if
| it's ready. That's something you want to do before declaring
| something 1.0.
|
| If it's not ready, they'll roll it back.
|
| Part of why you have to do something like this is because the
| test suite just isn't comprehensive, nor should we expect it
| to be. Real world usage is what shakes out the long tail of
| bugs. You just have to have some sort of stage like this in
| order to get things into a good state.
| kachapopopow wrote:
| so they see issues that rise up from real world issues that
| tests might not cover? the same ubuntu version also bundles
| the latest kernel which is not considered stable to begin
| with.
| WD-42 wrote:
| It's a cool project but does anyone else find the choice of MIT
| kinda icky/disrespectful? Like maintainers have put decades of
| work into the GNU coreutils under the gpl and all that entails,
| and then some people decide to rewrite it and just say "nah".
|
| I know they claim it's a clean implementation but cmon, there's
| no way they aren't peeking at the existing coreutils source.
| steveklabnik wrote:
| 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?
| lnkl wrote:
| Were they also open source?
| gjsman-1000 wrote:
| No. The original UNIX utilities were under proprietary
| licenses for an extremely long time, before eventually they
| broke free under BSD. The BSD tools are descendants of the
| originals and are also the versions used by macOS.
|
| BSD wasn't under an open license when GNU got started, so
| GNU reimplemented the proprietary UNIX utilities with their
| own enhancements and their own GPL license.
|
| As such, complaining about the license is rich, considering
| GNU basically stole it themselves from the first round. And
| to this day, HN complaining about macOS's utilities is also
| rich considering they are actually more standard and
| authentically UNIX than GNU.
| WD-42 wrote:
| AFAIK the GNU authors didn't have access to the original
| source code because they were proprietary. I don't know why
| this matters but it feels different in a purely "feels" way.
| gjsman-1000 wrote:
| Yes and no; due to antitrust laws with AT&T, almost
| everyone had copies of UNIX source code, especially if you
| were near any universities (why does BSD still honor UC
| Berkeley on bootup, do you think?). Easy as pie to get; but
| extremely difficult to legally use without a license.
|
| The question about whether Linux and GNU copied from the
| proprietary originals caused the famous SCO lawsuits. Even
| though this was proven false, there's very little chance
| the originals weren't used as reference in GNU.
| steveklabnik wrote:
| Gotcha! I don't, but that's why I asked, I wasn't sure if
| this was about any specific license or what.
|
| I'm also curious about this: does that it's in a different
| language make any difference here? Like I could also maybe
| see what you're saying if these were also in C, but being
| in Rust, it's not like they can literally copy the code,
| regardless. I know you're talking about feelings and not
| hard and fast rules, but do you think that plays into any
| of the feelings at all?
| josephg wrote:
| 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.
| vasac wrote:
| OpenJDK isn't a clean room port - it was created from the
| original source code of Sun's JDK.
| testdelacc1 wrote:
| It's uncharitable to assume they're lying. In which case, it's
| perfectly ethical and legal to reimplement an existing program.
| ottah wrote:
| 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.
| MangoToupe wrote:
| The gnu project is more than welcome to make its own moves away
| from C.
___________________________________________________________________
(page generated 2025-12-14 20:00 UTC)