69
Rust Coreutils 0.3 Released With Some Major Speed-Ups, Better GNU Compatibility (www.phoronix.com)
submitted 1 year ago by to c/linux@programming.dev
23 comments fedilink hide all child comments
 

The uutils project announced tonight the release of Rust Coreutils 0.3, another step forward for this Rust version alternative to GNU Coreutils that has been attracting a lot of interest lately due to Ubuntu 25.10 now using it by default.

Rust Coreutils 0.3 brings improved GNU test suite compatibility with now passing 532 tests, or nearly an 84% pass rate. There is improved error handling and other updates to better match the behavior of GNU Coreutils... Such as the recently noted date issue breaking Ubuntu 25.10's unattended upgrades.

you are viewing a single comment's thread
view the rest of the comments
[–] 24 points 1 year ago (22 children)

You cant tell me that a rewrite of gnu stuff in rust is just for security. I see that weak permissive license and the conspiracy part of my brain turns on...

  • permalink
  • fedilink
  • source
  • hideshow 22 child comments
    •
  • [–] 12 points 1 year ago (8 children)

    It was just a hobby project that one person started that then got a lot of people behind it. The permissive license was just because he just copied what every other project was using.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [+] -6 points 1 year ago (7 children)

    But the permissive license is why it gained traction, otherwise who would spend so much resources on something that a decade later only accomplishes 85 percent of what coreutils does?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 3 points 1 year ago (5 children)

    I don't know where you are getting "a decade" from, but assuming we are using the percentage of passing tests as our metric of the percentage of "what coreutils does"--which is dubious, but it's your metric so let's go with that for the moment--we see in the very same plot that just four years ago it only did 25 percent of "what coreutils does", so clearly significantly more has happened in the last four years than did in the previous six, rather the project being worked on equally hard for the entire time.

    Also, you seem to imply that it shouldn't have taken them "a decade" to get accomplish "85 percent of what coreutils does", but that raises the question: exactly how long should it have taken exactly? Can you cite evidence that it took significantly less time for coreutils to get to the point where it accomplished "85 percent of what coreutils does" today? If not, then there is no basis of comparison we can use to decide whether a decade is a long time or not to have gotten to this point.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 1 point 1 year ago* (4 children)

    You are fixating on the incorrect premise. I noted that it was started a decade ago as a analogy for how labor intensive the project is. A project that by design has to mirror the behaviour of coreutils.So why are people investing the time in this? What makes it worthwhile? It's the permissive license. If uutils used GPL individuals would instead try to contribute to the much more utilised coreutils, where their contributions would be guaranteed to have an impact.

    Edit: Some of the earlier issues date from 2013, so it has been a decade, although it probably was very obscure at the time.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 1 year ago (3 children)

    So the fact that it is written in Rust has absolutely nothing to do with it?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 1 year ago (2 children)

    Being written in Rust has mixed effects. Rust is still less mainstream than C, so fewer people can contribute. However, it does attract more interest because it's different.

    However, the reasons why you create/contribute to new-but-similar projects is to add functionality that the original project doesn't have. By nature a coreutils replacement has to behave like coreutils or else it will break many configurations. This severely limits the functionality you can provide. So why are people (and Canonical) contributing so much labor to something that still doesn't function as intended?

    I say it's the licensing. I say this as someone who regularly gets requests to change the licensing of my software (more than any feature request). I think licensing is a big deal, and most software devs recognize that.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 1 year ago (1 child)

    Being written in Rust has mixed effects. Rust is still less mainstream than C, so fewer people can contribute. However, it does attract more interest because it’s different.

    Yes, it's "different". That is all that it has to offer: it's "different". There is no other reason why people might be interested in it.

    However, the reasons why you create/contribute to new-but-similar projects is to add functionality that the original project doesn’t have.

    Why is that the only reason to motivate someone to do such a thing?

    So why are people (and Canonical) contributing so much labor to something that still doesn’t function as intended?

    Maybe we should take them that they word that they are genuinely think that coreutils would be better if it were written in Rust? Why is that such a radical possibility?

    I say it’s the licensing.

    Yes, I have noticed that you are very big on saying what others' motivations are.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 1 year ago

    "Take them at their word"

    Who? Has there been a survey of contributors?

    "Genuinely think that coreutils would be better if it were written in Rust"

    I feel like the skill-level of the contributors is high enough that they would not be so naive.

    Programs in different languages can compile to the same machine code. Any advantage would be in language constructs. But if you already have an existing C implementation what advantage do you do from a Rust implementation?

    I personally write in 3 languages: Rust, C++, and Fortran ( or rarely SPARK). I don't port my code across languages, because there is no advantage. If I wanted it better, I would work on my existing codebase.

    Porting really only helps if the original language was hindering development, deployment or runtime. These arguments don't really hold with C, a fast, low-dependency language that is more widely used than Rust.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 19 points 1 year ago (7 children)

    I feel despair every time this project comes up ): I really like the idea of rewriting coreutils in rust, but GNU-compatible coreutils in a permissive license is just asking for trouble...

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 8 points 1 year ago (3 children)

    I'm curious, what's the worst case scenario in your eyes? I struggle to see why anyone would closed-fork it, or what threat it would pose if they did.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 3 points 1 year ago (2 children)

    A rust rewrite of these tools has a lot of potential commercial value, and I can totally see a cloud provider like AWS putting this into some "hardened cloud AI distro" or whatever. They'll be able to do exactly what they did to Elastic Search, or do the EEE thing and add bugfixes/features that they don't contribute back in order to make their offering more competitive, make minor changes to the CLI as a lock-in strategy, etc.

    Not licensing this as GPL will inevitably lead to the erosion of freedoms for everyone.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 3 points 1 year ago (1 child)

    I will take that bet.

    There are already other core utils to choose from. The BSD utils are arguably better than the GNU ones for the use case you mentioned (and permissively licensed obviously). Has anybody “forked” the BSD utils and “taken them proprietary”?

    I mean, people can use the code but that does not take away freedom from anybody (at least not in my view).

    I am quite happy to go on record and disagree with your prediction. Time will tell.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 1 year ago

    You didn't get my point. AWS is incentivized to offer the best product they can sell to their customers, regardless of license. If the Rust core utils reach feature parity with GNU core utils, then Rust's memory safety makes it the superior product (at least on security) and an easy sell to customers.

    That is the point at which the license choice matters for what I said: when it's widely adopted by AWS customers. If it isn't GPL, then AWS is free to do what I described, and incentivized to do so.

    Sure, if AWS customers widely adopted the BSD tools for whatever reason, then it'd be the same situation. I just don't see any particular reason for that to happen.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 5 points 1 year ago (1 child)

    Every time this comes up, I see people complaining about the license, and I have an urge every time to start a project anew, or to find yet another project which re-writes coreutils in Rust but licensed with GPLv3.

    Today I finally gathered enough urge to... do a search in Kagi. No. There is no such project.

    Shall we start one? Even with just a stub it'll be a start. Anyone?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 4 points 1 year ago

    Well, MIT projects can be forked into a new GPLv3 project, right? If Canonical cared, they could have done that to assuage this concern.

    I think it's a valid concern. Pushover licenses are bad. But even if a GPL Rust coreutils project exists (I actually have one, but I don't have the same goals), it seems unlikely that Canonical would be bothered to pivot to it.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 5 points 1 year ago (3 children)

    I like copyleft and have convinced about 7 projects to convert to copyleft. but in this case its such a small project i don't really see anyone turning it into some proprietary project and the project losing a lot of contributions because of it. Also even the FSF says that permissive licenses might be better when you implementing standards (And i think you could argue this project is at least partially a implementation of posix).

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 2 points 1 year ago (2 children)

    Do you have a link to the FSF saying that?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] -1 points 1 year ago (1 child)

    Why do you ask?

    grok came up with this:

    Some libraries implement free data formats that are competing against restricted data formats, such as Ogg Vorbis (which competes against MP3 audio) and WebM (which competes against MPEG-4 video). The success of the free format requires allowing many proprietary application programs to link in the code to handle the format. For instance, we wanted nonfree media players, especially appliances, to include the code for Ogg Vorbis as well as MP3.

    In these special situations, if you are aiming to convince proprietary application developers to use the library for the free format, you would need to make that easy by licensing the library under a weak license, such as the Apache License 2.0.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 1 year ago

    First off, thank you for that.

    That the FSF sees the value in permissive licenses in promoting the success of free data formats is an important calibration.

    I do not believe the tolerance for permissive licenses extends to standards in general. They do have the LGPL though.

    Given that the GPL was created explicitly to license the GNU implementation of the POSIX standard, we for sure know where they stand on POSIX specifically.

  • permalink
  • fedilink
  • source
  • parent