Ubuntu 25.10’s transition to using Rust Coreutils in place of GNU Coreutils has uncovered a few performance issues so far with the Rust version being slower than the C-based GNU Coreutils. Fortunately there still are a few weeks to go until Ubuntu 25.10 releases as stable and upstream developers are working to address these performance gaps.

  • yamamoon@lemmings.world
    link
    fedilink
    arrow-up
    4
    ·
    16 days ago

    This should be avoided like the plague because of the choice to use MIT over GPL.

    Any work dedicated to this can and will be stolen by corporations without giving back if they find it useful. This is what happened with Sony and Apple and their respective operating systems. They chose to base them on BSD so they could steal work and not give back to the public.

    Do not be fooled.

    • digger@lemmy.ca
      link
      fedilink
      arrow-up
      0
      ·
      16 days ago

      Isn’t this the reason for the switch? I thought MIT was the whole reason they were making the switch.

      • TMP_NKcYUEoM7kXg4qYe@lemmy.world
        link
        fedilink
        arrow-up
        2
        ·
        13 days ago

        The reason Ubuntu switched was Rust’s “safety”. Which is sort of a dumb reason because Coreutils have had very few CVEs in the past. A less dumb reason is performance. Uutils are faster than Coreutils, this was an edge-case.

        MIT license is the schizo reason. Making a closed source version of Unix utilities would not be beneficial for Canonical in any way, but that does not stop the schizos from schizoing.

        • communism@lemmy.ml
          link
          fedilink
          arrow-up
          1
          ·
          16 days ago

          You can fork it and GPL it just fine, the MIT licence allows for that, however anyone who wants to make the codebase proprietary can just fork the original upstream project. Not much point GPLing a project if you make zero changes to it. If you make changes then in practice just your changes are GPLed because anyone wanting to use code from upstream can just use it directly from upstream under MIT.

          • TMP_NKcYUEoM7kXg4qYe@lemmy.world
            link
            fedilink
            arrow-up
            1
            ·
            13 days ago

            Not only that but if you edit the MIT licensed files (Read: They have the MIT notice, which you have to preserve, in them.), they will still be MIT licensed. Only new files and the entire project will become GPL.

            I am not a lawer.

    • atzanteol@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      0
      arrow-down
      1
      ·
      16 days ago

      They chose to base them on BSD so they could steal work and not give back to the public.

      “Here you can use this as you like, no questions asked”

      “Hey! Why did you use that in a way that I told you you could!?!?”

      • magz :3@lemmy.blahaj.zone
        link
        fedilink
        arrow-up
        3
        ·
        16 days ago

        i think the argument here is more that saying “you can use this however you like, no questions asked” is a bad idea because it allows corporations to approriate the work

    • communism@lemmy.ml
      link
      fedilink
      arrow-up
      0
      arrow-down
      1
      ·
      16 days ago

      Author: “I consent to my code being used for proprietary programs!”

      Compant: “I consent to using this FOSS code in my proprietary program!”

      You for some reason: “I don’t!”

      • 3abas@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        16 days ago

        They articulated the reason and gave examples of precedence.

        And you’re dismissing their voice as irrelevant, but as the consumer of the product, their voice is most critical, and more people should be aware of how corporations use their massive wealth to choke and starve open source competition out of existence despite building their products on open source work in the first place.

        • communism@lemmy.ml
          link
          fedilink
          arrow-up
          1
          arrow-down
          1
          ·
          16 days ago

          I continue to fail to see the issue with the author, the person whose actual labour goes into the software, not your labour, deciding that they are fine with their source code being used in any way the general public sees fit provided they simply credit the author and provide a copy of the MIT licence. If I give you something, you’re not stealing by accepting my gift. They’re choosing voluntarily to make their source code available under such a licence. If they weren’t okay with that, they would’ve chosen a copyleft licence.

          And you’re dismissing their voice as irrelevant, but as the consumer of the product, their voice is most critical

          That seems insanely entitled, but you’re allowed to not use non-copyleft software if you really care that much. The authors of permissively licensed software aren’t forcing you to use their software.

          There are plenty of valid reasons to license a work as MIT or BSD or similar. Firstly, libraries are almost always going to be permissively licensed, not just because it allows proprietary software to use those libraries, but also because it allows permissively licensed FOSS to use those libraries. If I want to use a GPL library, it’s not just that I have to make my software FOSS, it’s that I have to make my software GPL specifically. If I want to make a FOSS MIT program, I can’t use any GPL libraries.

          Secondly, sometimes it’s because, well, as the licence text provides, I don’t give a shit what you do with the code. I write lots of little tools that are just for myself and I share them in case they’re of use to someone else. If some big corpo uses it in their proprietary money-making machine it’s no shit off my back. It was just a little tool I wrote for myself and it doesn’t affect me if other people use it to make money.

          I think GPL is reasonable if a lot of labour goes into a project, and you’d be discouraged from working on it if someone was leeching off of it for their proprietary software. But my MIT/BSD code requires 0 maintenance labour from me, and I don’t care to control how other people use it. That’s the whole point of MIT/BSD/Apache/etc. It’s the “don’t give a shit” licence.

  • flux@lemmy.ml
    link
    fedilink
    arrow-up
    0
    ·
    16 days ago

    Rust is great, but might it be a bit premature to replace the venerable coreutils with a project boasting version number 0.2, which I imagine reflects its author’s view on its maturity?

    • MonkderVierte@lemmy.zip
      link
      fedilink
      arrow-up
      1
      ·
      16 days ago

      It’s more a thing like in ripgrep vs. grep; new algorithms being vastly faster in most cases except in some.

    • SavvyWolf@pawb.social
      link
      fedilink
      English
      arrow-up
      1
      ·
      16 days ago

      Rust and C are the same “tier” of performance, but GNU coreutils has the benefit of several decades of development and optimization that the Rust one needs to catch up with.

    • Froggie 🐸@lemmy.zip
      link
      fedilink
      arrow-up
      0
      ·
      16 days ago

      Language isn’t everything. While Rust provides some features and safety that C doesn’t while being roughly equivalent in performance, the algorithms that developers choose will dominate the performance impact on the program.

      GNU core utils has decades of accumulated knowledge and optimisation that results in the speed it has. The Rust core utils should in theory be able to achieve equivalent performance, but differences in the implementation choices between one and another, or even something as simple as the developers not having prioritised speed yet and still focusing on correctness could explain the differences that are being reported.

      • TMP_NKcYUEoM7kXg4qYe@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        13 days ago

        Well the entire point of the project is that they used algorithms/features of Rust that make it easier to write fast code. This article basically reports on a “bug”. Uutils are in many ways already faster than Coreutils.

        Correctness is really more of a byproduct of using Rust. Coreutils have had only a few CVEs in their lifetime so it would be sort of redundant to rewrite them in Rust for “correctness”.