8 ms·

Rust Coreutils 0.5.0 Release: 87.75% compatibility with GNU Coreutils

95 points by maxloh 11mo ago

akagusu 11mo ago
With you want 100% compatibility with GNU Coreutils + memory safety just compile Coreutils with Fil-C. 100% compatibility with 0 rewrite.
- bfrog 11mo ago
  Is Fil-C free of runtime overhead?
  - f_devd 11mo ago
    No, it's gc-like. Up to 4x slowdown iirc
    - westurner 11mo ago
      To better port C to Rust: 3C (Checked C), c2rust, Crown ownership analysis, RustMap, c2saferrust (LLM), Laertes
  - testdelacc1 11mo ago
    The run time overhead is 2-4x.
    - bfrog 11mo ago
      Isn't this putting it in the Java territory?
      - testdelacc1 11mo ago
        Yeah, pretty much. If someone is ok with a 3-4x slower program with higher memory consumption, that’s great if it saves you development time. But I can’t see someone starting a new project in Fil-C when more performant and ergonomic options exist - Java, C#, Go, Swift, Rust. Even Javascript.
- bitbasher 11mo ago
  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 11mo ago
    > The "unknowns" in a C implementation means arbitrary code execution and all kinds of nasty. In Fil-C?
    - lucyjojo 10mo ago
      isnt it x86_64 exclusive?
      - yjftsjthsd-h 10mo ago
        https://github.com/pizlonator/fil-c?tab=readme-ov-file#requirements https://github.com/pizlonator/fil-c?tab=readme-ov-file#requi... says that the current implementation only targets Linux+x86_64 but that they see no reason it couldn't be portable. But you're in the wrong (sub)thread; this (sub)thread is about whether it's safe.
        lucyjojo 10mo ago
        ah, sorry about that and thanks for the link
  - stefan_ 11mo ago
    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 https://ubuntu.com/security/notices/USN-7867-1
- josephg 11mo ago
  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 11mo ago
    > 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.)
    - stefan_ 11mo ago
      I tried md5sum and sha256sum and there was exactly zero difference in runtime (the Fil-C version of sha256sum was consistently faster, in fact..)
      - josephg 11mo ago
        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.
        0cf8612b2e1e 11mo ago
jeffbee 11mo ago
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 11mo ago
  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 11mo ago
    The uutils project has found bugs in upstream, added extra tests, and clarified behavior. It’s helped both projects improve.
    - josephg 11mo ago
      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.
- knorker 11mo ago
  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".
throwaway613745 11mo ago
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)
- hu3 10mo ago
  why isn't that the default? why ship broken implementation prematurely?
  - throwaway613745 10mo ago
    Because Canonical has completely lost the plot and become infected by Rust zealots.
bgwalter 11mo ago
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 11mo ago
  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 https://uutils.github.io/coreutils/docs/test_coverage.html
hejuwjffys 11mo ago
[flagged]
- dr6462910 11mo ago
  [dead]
kachapopopow 11mo ago
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 11mo ago
  I mean, why is Ubuntu using it as default when it isnt 1.0?
  - steveklabnik 11mo ago
    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.
    - pseudalopex 11mo ago
      > Ubuntu is evaluating it as the default in order to see if it’s ready. Did 100% of tests pass when Ubuntu made this decision? My understanding was no.
      - steveklabnik 11mo ago
        No. Because the tests that don’t pass are edge cases and corners that most people wouldn’t notice. It’s arguably more important to fix bugs that impact actual usage, so it can be a valid strategy to do this even before you hit 100% coverage, to help you prioritize the remaining bugs to fix. In other words, there may be more serious bugs not in the test suite than the ones that aren’t passing that are in the suite. And you only find that out through real usage.
WD-42 11mo ago
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 11mo ago
  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 11mo ago
    Were they also open source?
    - gjsman-1000 11mo ago
      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.
      - collinfunk 11mo ago
        MacOS's utilities are really just FreeBSD's with some patches. https://github.com/apple-oss-distributions/text_cmds https://github.com/apple-oss-distributions/text_cmds https://github.com/apple-oss-distributions/system_cmds https://github.com/apple-oss-distributions/system_cmds https://github.com/apple-oss-distributions/file_cmds https://github.com/apple-oss-distributions/file_cmds https://github.com/apple-oss-distributions/adv_cmds https://github.com/apple-oss-distributions/adv_cmds https://github.com/apple-oss-distributions/shell_cmds https://github.com/apple-oss-distributions/shell_cmds https://github.com/apple-oss-distributions/misc_cmds https://github.com/apple-oss-distributions/misc_cmds
ottah 11mo ago
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 11mo ago
  The gnu project is more than welcome to make its own moves away from C.
  - stackghost 11mo ago
    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.
    - c0l0 11mo ago
      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.
- ekjhgkejhgk 11mo ago
  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.
nonameiguess 11mo ago
This is going to sound like a gripe and I swear it isn't, but is there a plan for a reasonably full suite of minimal userspace tools? I don't expect util-linux itself in Rust, but something like: - coreutils - findutils - libmagic and file - tar and some compression libs - grep, awk, sed - the shell and all of its builtins - something functionally equivalent to openssl or GnuTLS - some ssh client and server - curl - a terminal-based editor - man-db and texinfo - some init system and bootloader - pick a package manager, any package manager, and rewrite it in Rust Barring all of that, maybe just busybox but written in Rust. That should give you roughly what you need for a non-graphical system. coreutils isn't nothing, but it's a pretty small part of the system, with much of it ending up implemented by the shell in most distros.
- steveklabnik 11mo ago
  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.
  - adgjlsfhk1 11mo ago
    also worth mentioning that the ones that are user facing are much lower priority than machine facing one. no one cares about CVEs in ed, but a CVE in cp would be really bad
- panick21_ 11mo ago
  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.
  - steveklabnik 11mo ago
    Most (all?) of these projects aren’t aiming for drop-in compatibility.
zorked 11mo ago
Thanks for fixing imaginary memory safety issues in /bin/cat...
- IshKebab 11mo ago
  It's not only about memory safety.
  - alextingle 11mo ago
    No, it's all about corporate greed.
    - IshKebab 11mo ago
      Don't be ridiculous.
      - throwaway613745 10mo ago
        Not ridiculous at all. Rust coreutils are MIT licensed. Canonical sells extended support and security packages. It’s completely reasonable to think they will want to monetize additional patches on coreutils as part of their commercial offerings.
  - egorfine 11mo ago
    Correct. It's almost not at all about memory safety.
knorker 11mo ago
For context, how "compatible" is BSD utils with either one? IOW: how much does it matter?
- IshKebab 11mo ago
  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.
  - knorker 11mo ago
    > expected `uname -p` to work but it just prints `unknown` I just tried that on three very different Linux systems of mine, and all print `unknown`.
- pseudalopex 11mo ago
  These utilities' purpose is to replace GNU utilities. BSD utilities' purpose is not.
  - knorker 11mo ago
    Seems like there's more uproar with this than with changing the /bin/sh symlink to dash, and that difference seems much bigger.
    - NekkoDroid 10mo ago
      To be fair, `/bin/sh` is suppose to be the POSIX shell, so as long as they are compliant it really doesn't matter. The problem with `/bin/sh` being bash, is that it provides extensions (even when running in POSIX mode from what I remember) and relying on them makes those scripts technically broken. It would be more of a comparison if dash was aiming to be a drop-in replacement for bash and not a POSIX shell.
burnt-resistor 11mo ago
While I <3 Rust, rewriting major things in Rust but then taking an additional step of releasing incomplete, incompatible code as "production" like Canonical has done without day 1 full compatibility is inherently unethical, problematic, and counterproductive. Related: Because of Redhat/Fedora's decision; CentOS Stream, Alma, and Rocky 9 & 10 Docker images use a statically-linked "multi-call" variant of coreutils that is also problematic in real-world usage. This can be fixed with the following: sudo dnf install coreutils --allowerasing -y
- Barrin92 11mo ago
  >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.
  - burnt-resistor 11mo ago
    True that, however coreutils-single is already rolled out in Docker images for RH-derived distros. It's not the same thing, but it has breaking incompatibilities that don't appear when the regular coreutils is installed. Small changes done unwisely lead to big breakage in ways arrogant distro maintainers shove down users' throats. Canonical makes reckless changes regularly.
vb-8448 11mo ago
just a curiosity: why not trying to put in a loop gemini o gpt and wait until 100% of test suite is passed?
drnick1 11mo ago
What's the point of that? The C version has been around for ages, works well, and is GPL'ed. Reexamining the code carefully for a rewrite does provide the opportunity to catch some bugs, but the rewrite will most likely introduce countless new bugs. It's not clear what is gained by the Rust rewrite, it's not like Rust is faster than C, it should be very similar or perhaps slower.
- samdoesnothing 11mo ago
  The point is that they get to rewrite it in their favourite language.
  - deleted 11mo ago
    [deleted]
- egorfine 11mo ago
  The point is virtue signaling. There is no technical merit to it.
master_korin 11mo ago
[dead]
squirrellous 10mo ago
Honest question. Why is a Rust rewrite of coreutils getting traction? Nobody thought it’s a good idea to rewrite coreutils with Go, Java, Python, C++, etc etc. It can’t just be memory safety.
- estebank 10mo ago
  > 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.

95 points by maxloh 11mo ago

With you want 100% compatibility with GNU Coreutils + memory safety just compile Coreutils with Fil-C. 100% compatibility with 0 rewrite.

bfrog 11mo ago
Is Fil-C free of runtime overhead?
- f_devd 11mo ago
  No, it's gc-like. Up to 4x slowdown iirc
  - westurner 11mo ago
    To better port C to Rust: 3C (Checked C), c2rust, Crown ownership analysis, RustMap, c2saferrust (LLM), Laertes
- testdelacc1 11mo ago
  The run time overhead is 2-4x.
  - bfrog 11mo ago
    Isn't this putting it in the Java territory?
    - testdelacc1 11mo ago
      Yeah, pretty much. If someone is ok with a 3-4x slower program with higher memory consumption, that’s great if it saves you development time. But I can’t see someone starting a new project in Fil-C when more performant and ergonomic options exist - Java, C#, Go, Swift, Rust. Even Javascript.
bitbasher 11mo ago
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 11mo ago
  > The "unknowns" in a C implementation means arbitrary code execution and all kinds of nasty. In Fil-C?
  - lucyjojo 10mo ago
    isnt it x86_64 exclusive?
    - yjftsjthsd-h 10mo ago
      https://github.com/pizlonator/fil-c?tab=readme-ov-file#requirements https://github.com/pizlonator/fil-c?tab=readme-ov-file#requi... says that the current implementation only targets Linux+x86_64 but that they see no reason it couldn't be portable. But you're in the wrong (sub)thread; this (sub)thread is about whether it's safe.
      - lucyjojo 10mo ago
        ah, sorry about that and thanks for the link
- stefan_ 11mo ago
  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 https://ubuntu.com/security/notices/USN-7867-1
josephg 11mo ago
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 11mo ago
  > 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.)
  - stefan_ 11mo ago
    I tried md5sum and sha256sum and there was exactly zero difference in runtime (the Fil-C version of sha256sum was consistently faster, in fact..)
    - josephg 11mo ago
      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.
      - 0cf8612b2e1e 11mo ago

jeffbee 11mo ago

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 11mo ago
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 11mo ago
  The uutils project has found bugs in upstream, added extra tests, and clarified behavior. It’s helped both projects improve.
  - josephg 11mo ago
    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.
knorker 11mo ago
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".

throwaway613745 11mo ago

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)

hu3 10mo ago
why isn't that the default? why ship broken implementation prematurely?
- throwaway613745 10mo ago
  Because Canonical has completely lost the plot and become infected by Rust zealots.

bgwalter 11mo ago

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 11mo ago
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 https://uutils.github.io/coreutils/docs/test_coverage.html

hejuwjffys 11mo ago

[flagged]

dr6462910 11mo ago
[dead]

kachapopopow 11mo ago

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 11mo ago
I mean, why is Ubuntu using it as default when it isnt 1.0?
- steveklabnik 11mo ago
  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.
  - pseudalopex 11mo ago
    > Ubuntu is evaluating it as the default in order to see if it’s ready. Did 100% of tests pass when Ubuntu made this decision? My understanding was no.
    - steveklabnik 11mo ago
      No. Because the tests that don’t pass are edge cases and corners that most people wouldn’t notice. It’s arguably more important to fix bugs that impact actual usage, so it can be a valid strategy to do this even before you hit 100% coverage, to help you prioritize the remaining bugs to fix. In other words, there may be more serious bugs not in the test suite than the ones that aren’t passing that are in the suite. And you only find that out through real usage.

WD-42 11mo ago

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 11mo ago
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 11mo ago
  Were they also open source?
  - gjsman-1000 11mo ago
    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.
    - collinfunk 11mo ago
      MacOS's utilities are really just FreeBSD's with some patches. https://github.com/apple-oss-distributions/text_cmds https://github.com/apple-oss-distributions/text_cmds https://github.com/apple-oss-distributions/system_cmds https://github.com/apple-oss-distributions/system_cmds https://github.com/apple-oss-distributions/file_cmds https://github.com/apple-oss-distributions/file_cmds https://github.com/apple-oss-distributions/adv_cmds https://github.com/apple-oss-distributions/adv_cmds https://github.com/apple-oss-distributions/shell_cmds https://github.com/apple-oss-distributions/shell_cmds https://github.com/apple-oss-distributions/misc_cmds https://github.com/apple-oss-distributions/misc_cmds

ottah 11mo ago

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 11mo ago
The gnu project is more than welcome to make its own moves away from C.
- stackghost 11mo ago
  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.
  - c0l0 11mo ago
    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.
ekjhgkejhgk 11mo ago
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.

nonameiguess 11mo ago

This is going to sound like a gripe and I swear it isn't, but is there a plan for a reasonably full suite of minimal userspace tools? I don't expect util-linux itself in Rust, but something like: - coreutils - findutils - libmagic and file - tar and some compression libs - grep, awk, sed - the shell and all of its builtins - something functionally equivalent to openssl or GnuTLS - some ssh client and server - curl - a terminal-based editor - man-db and texinfo - some init system and bootloader - pick a package manager, any package manager, and rewrite it in Rust Barring all of that, maybe just busybox but written in Rust. That should give you roughly what you need for a non-graphical system. coreutils isn't nothing, but it's a pretty small part of the system, with much of it ending up implemented by the shell in most distros.

steveklabnik 11mo ago
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.
- adgjlsfhk1 11mo ago
  also worth mentioning that the ones that are user facing are much lower priority than machine facing one. no one cares about CVEs in ed, but a CVE in cp would be really bad
panick21_ 11mo ago
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.
- steveklabnik 11mo ago
  Most (all?) of these projects aren’t aiming for drop-in compatibility.

zorked 11mo ago

Thanks for fixing imaginary memory safety issues in /bin/cat...

IshKebab 11mo ago
It's not only about memory safety.
- alextingle 11mo ago
  No, it's all about corporate greed.
  - IshKebab 11mo ago
    Don't be ridiculous.
    - throwaway613745 10mo ago
      Not ridiculous at all. Rust coreutils are MIT licensed. Canonical sells extended support and security packages. It’s completely reasonable to think they will want to monetize additional patches on coreutils as part of their commercial offerings.
- egorfine 11mo ago
  Correct. It's almost not at all about memory safety.

knorker 11mo ago

For context, how "compatible" is BSD utils with either one? IOW: how much does it matter?

IshKebab 11mo ago
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.
- knorker 11mo ago
  > expected `uname -p` to work but it just prints `unknown` I just tried that on three very different Linux systems of mine, and all print `unknown`.
pseudalopex 11mo ago
These utilities' purpose is to replace GNU utilities. BSD utilities' purpose is not.
- knorker 11mo ago
  Seems like there's more uproar with this than with changing the /bin/sh symlink to dash, and that difference seems much bigger.
  - NekkoDroid 10mo ago
    To be fair, `/bin/sh` is suppose to be the POSIX shell, so as long as they are compliant it really doesn't matter. The problem with `/bin/sh` being bash, is that it provides extensions (even when running in POSIX mode from what I remember) and relying on them makes those scripts technically broken. It would be more of a comparison if dash was aiming to be a drop-in replacement for bash and not a POSIX shell.

burnt-resistor 11mo ago

While I <3 Rust, rewriting major things in Rust but then taking an additional step of releasing incomplete, incompatible code as "production" like Canonical has done without day 1 full compatibility is inherently unethical, problematic, and counterproductive. Related: Because of Redhat/Fedora's decision; CentOS Stream, Alma, and Rocky 9 & 10 Docker images use a statically-linked "multi-call" variant of coreutils that is also problematic in real-world usage. This can be fixed with the following: sudo dnf install coreutils --allowerasing -y

Barrin92 11mo ago
>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.
- burnt-resistor 11mo ago
  True that, however coreutils-single is already rolled out in Docker images for RH-derived distros. It's not the same thing, but it has breaking incompatibilities that don't appear when the regular coreutils is installed. Small changes done unwisely lead to big breakage in ways arrogant distro maintainers shove down users' throats. Canonical makes reckless changes regularly.

vb-8448 11mo ago

just a curiosity: why not trying to put in a loop gemini o gpt and wait until 100% of test suite is passed?

drnick1 11mo ago

What's the point of that? The C version has been around for ages, works well, and is GPL'ed. Reexamining the code carefully for a rewrite does provide the opportunity to catch some bugs, but the rewrite will most likely introduce countless new bugs. It's not clear what is gained by the Rust rewrite, it's not like Rust is faster than C, it should be very similar or perhaps slower.

samdoesnothing 11mo ago
The point is that they get to rewrite it in their favourite language.
- deleted 11mo ago
  [deleted]
egorfine 11mo ago
The point is virtue signaling. There is no technical merit to it.

master_korin 11mo ago

[dead]

squirrellous 10mo ago

Honest question. Why is a Rust rewrite of coreutils getting traction? Nobody thought it’s a good idea to rewrite coreutils with Go, Java, Python, C++, etc etc. It can’t just be memory safety.

estebank 10mo ago
> 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.