Oboi here we go 🙄

Ubuntu has managed to do away with GNU Core Utilities in its default stack. The last three holdouts, cp, mv and rm, have moved to uutils’ coreutils; the Rust reimplementation Canonical has been feeding into the distro since 2025.

They had been held back from 26.04 LTS over flaws in the uutils versions. Everything else, from ls and cat to chmod and du, made that jump in earlier releases.

This change, while big, sits hidden away in an obscure mention in Canonical’s work-in-progress release notes for Ubuntu 26.10.

It’s been a long road

Canonical started oxidising Ubuntu last year, and Ubuntu 25.10 became the first release to ship coreutils as the default. That release also made sudo-rs the default privilege tool, replacing a command that had been in place for decades.

26.04 was the release where the plan did slow down quite a bit, as Canonical kept cp, mv, and rm on their GNU versions due to a bunch of TOCTOU issues that were blocking the full implementation.

These were caught during an audit, when Canonical commissioned Zellic for two rounds between December 2025 and March 2026, focusing on the most security-sensitive utilities first.

Across both rounds, Zellic raised 113 issues, and 44 of them were assigned CVEs. Canonical says the vast majority have been resolved.

Getting here has had its ups and downs, and the last stretch was not clean. In July, uutils cp went back into the archive and came straight out again after it broke live image builds.

The fix was quick; as the developers marked it “Critical,” the fix went upstream, and the migration landed in time for 26.10. What changes for you?

When typing commands, nothing changes for you on the surface. uutils coreutils is designed to be a drop-in replacement for essential GNU tools, and the project treats any divergence from GNU as a bug, further pointing out that some options may still be missing or behave differently.

So if you prefer staying on the GNU version, you have the option to install the coreutils-from-gnu package that houses all the required components.

The next stage

Coreutils is one piece of a broader campaign. Earlier this year, Canonical became a Gold Sponsor of the Trifecta Tech Foundation, pitching in €40,000 a year to fund memory-safe system software.

Under this, their current target is ntpd-rs, a Rust rewrite of the tools Ubuntu uses to keep its clock in sync. While work is still ongoing, it has already arrived for testing.

Its transition to being default is targeted for Ubuntu 27.04.

What Canonical is gradually building up towards is the completion of their oxidation vision for Ubuntu, and it’s not about blindly including new components. Rather, it looks like a measured approach that’s being worked out a few steps at a time.

  • Azazel@lemmy.ml
    link
    fedilink
    arrow-up
    20
    arrow-down
    2
    ·
    1 month ago

    As a developer I love rust but canonical can fuck all the way off with this shameless license laundering.

    • [object Object]@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      1 month ago

      Yeah, they only need to replace about fifty thousand GPL packages, and voila, Ubuntu’s laundered! Should take only about a hundred thousand years at this pace, very realistic.

    • TeaWithDani@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      1 month ago

      I really don’t see what they would gain by license laundering… They’ll unGPL Debian, Gnome, Wayland and the Linux Kernal next?

      If you wanted something out of copyleft, you would have an easier time just building on top of FreeBSD. It does like ~80% of what Ubuntu does already.

      I don’t feel too hot about them using MIT either, but I fail to see why they would implement this just to get rid of a GPL component. Seems expensive for nothing.

    • thingsiplay@lemmy.ml
      link
      fedilink
      arrow-up
      2
      arrow-down
      3
      ·
      1 month ago

      How is this license laundering? These are complete new implementations and the original projects are not touched.

      • Azazel@lemmy.ml
        link
        fedilink
        arrow-up
        4
        arrow-down
        1
        ·
        1 month ago

        Because Canonicals real goal is to move Ubuntu entirely to corporate friendly licensing under the pretense of migrating to rust. Obviously they leave the original untouched, it’s a matter of adoption. Without the oxidization argument nobody would have gone along with Ubuntu just deciding to do a clean room implementation of gnu tools in corporate friendly licensing, by making it about oxidation they are able to manipulate a large portion of the rust community into contributing/supporting their license laundering.

        • thingsiplay@lemmy.ml
          link
          fedilink
          arrow-up
          1
          arrow-down
          2
          ·
          1 month ago

          It’s not even Ubuntu doing the new implementation. And no, having a new project that is compatible to an existing one does not make it a license laundering. The word “license laundering” doesn’t even make sense.

          • Azazel@lemmy.ml
            link
            fedilink
            arrow-up
            3
            arrow-down
            1
            ·
            1 month ago

            Uh call it whatever you want but canonical pouring money and resources into development of corporate friendly licensed clones to existing tools so they can avoid copyleft restrictions in the future is not good. I never understand when people feel the need to defend corporations obviously harmful behavior.

            • thingsiplay@lemmy.ml
              link
              fedilink
              arrow-up
              2
              arrow-down
              1
              ·
              1 month ago

              This is not about defending corporations. It doesn’t matter who does that, I don’t think writing new tools with a different license is bad. My opinion has nothing to do about who does that, if communities, or corporations. I think having tools in a different language than C, especially something like Rust, is a good thing. Anyone who writes Rust code can read, adapt and make changes to it.

              And for licensing, GPL can be problematic in some cases that is not compatible with every license. Therefore having an alternative in MIT license is a good thing. Even if it ends up being in a proprietary program, its still better than not able to use the code. The old GPL code is still maintained independently.

              • Shanmugha@lemmy.world
                link
                fedilink
                arrow-up
                0
                ·
                1 month ago

                Anyone who writes Rust code can read, adapt and make changes to it

                Lol. Anyone who writes C code can read, adapt and make changes to it

                Anyone who writes Python code can read, adapt and make changes to it

                Anyone who writes Ada code can read, adapt and make changes to it

                What kind of argument is that?

                • thingsiplay@lemmy.ml
                  link
                  fedilink
                  arrow-up
                  0
                  ·
                  edit-2
                  1 month ago

                  What kind of argument is that?

                  I thought its obvious what I meant, based on the context of my entire reply. The argument is, anyone who writes and understands can make changes to the Rust code, but not on C or Python code. I can basic C coding, but wouldn’t trust me doing anything with it, but I would trust me doing something with Rust. Was it really that hard to understand? Also that means following is wrong:

                  Anyone who writes Python code can read, adapt and make changes to it

                  The code is Rust code. Anyone who writes Python code can NOT read, adapt and make changes to it. That’s my point with C vs Rust, because not everyone writes C (or Rust) code.

  • thenextguy@sh.itjust.works
    link
    fedilink
    arrow-up
    9
    ·
    1 month ago

    So, they will have to continue to support feature for feature, bug for bug with coreutils and others forever? What’s the endgame here?

  • Rioting Pacifist@lemmy.world
    link
    fedilink
    arrow-up
    3
    ·
    1 month ago

    This is dumb, I have to use osX for work and having coreutils be similar but not quite the same is a PITA, why would you inflict this on yourself to close a class of bugs that aren’t really a huge concern for coreutils.

    • trevor (any/all) @lemmy.blahaj.zone
      link
      fedilink
      English
      arrow-up
      6
      ·
      1 month ago

      The problem with macOS is that they use BSD utils, which are lacking functionality from GNU utils. If anything, utils being pushover-licensed means that Apple would be more likely to replace their broken coreutils with uutils and you’d get more parity with the coreutils installed on most Linux systems.

      And I say that as someone that despises pushover licenses, but this creates the probably that macOS utils won’t suck someday.

  • mesa@piefed.social
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 month ago

    Its not 1-1 so this is going to fry some bash scripts and install scripts. At work we had to stop using Ubuntu because of a couple of bad installs via this change. Debian is just as good so its fine.

    I have no opinions on the rewrite, but I wish they made a flavor or something just for this.

  • just another dev@lemmy.my-box.dev
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 month ago

    So… Let’s assume I don’t go around reading licenses for fun.

    Can anyone explain to me what the major differences are between MIT and GPL?

    • psycotica0@lemmy.ca
      link
      fedilink
      arrow-up
      1
      ·
      1 month ago

      MIT: The recipient of this source code can do with it as they please. That may include building it, distributing it, modifying it, building and distributing those modifications, commercializing it, whatever.

      GPL: The recipient of this software, including builds of it, is entitled to the source code that was used to build it. Anyone with the source code can modify it, share those modifications, make builds with it, etc, but you cannot restrict the rights of the recipients of your builds more than the terms you yourself received the source code under. So you can make changes and distribute builds of those changes, but users you distribute builds to are also entitled to your code including the changes you made.

      AGPL: Same as GPL, except the recipients of this software also include users of the software, such as over a network. This was because with SaaS suddenly people were using software they hadn’t “received”, because it was running on someone else’s computer and they only provided inputs and received outputs, so the licence was created to bring this back in line with the spirit of the GPL.

      LGPL: You can use this library in your non-GPL code, and it doesn’t “infect” your entire codebase by extending the entitlement of the source code outside the library to all users of your builds. It does still entitle users to the source code of the library itself though, especially if you’ve made changes to the code of that library.

      People often talk about the GPL preventing commercial uses, but that’s actually not true. You’re allowed to sell GPL software. It’s just a somewhat risky venture, because all users you sell software to also get all the source code. That means anyone can buy your software, request the source, and then immediately start competing with you by offering it themselves for free or cheaper or whatever. So it’s allowed, but rarely works for very long unless you have a lot of good will in the community.

      • Auli@lemmy.ca
        link
        fedilink
        English
        arrow-up
        0
        ·
        1 month ago

        Sure but there are lots of companies that don’t provide source code for their GPL software. And nothing happens.

        • psycotica0@lemmy.ca
          link
          fedilink
          arrow-up
          1
          ·
          1 month ago

          There’s an ongoing lawsuit: https://sfconservancy.org/copyleft-compliance/vizio.html

          It just takes forever and lots of money. That’s not a software license problem though, that’s more of an “American Legal System” problem. And I say that not to imply that it’s worse than other legal systems, just that I know it’s one with these problems and I don’t know about others.

    • Dran@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      1 month ago

      MIT: I build my thing on top of your thing, it’s my thing now. I sell it, you have no rights.

      GPL: I build my thing on top of your thing and your license forces me to distribute my thing under the GPL, including the source code.

      There are legitimate arguments for both. Sometimes it sucks when proprietary things get built on top of MIT code but sometimes it takes money for innovation, and in the realm of code the world often benefits anyway by virtue of copycats or distillation.

  • Libre Extremist@lemmy.ml
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 month ago

    As for the tech, I will leave it to those who are experts in the field. My worries are about the licensing. I just love GPL licences.

  • thingsiplay@lemmy.ml
    link
    fedilink
    arrow-up
    1
    ·
    1 month ago

    I don’t understand why Canonical is replacing the existing GNU tools. Unlike many others, I don’t think its “taking over GPL projects” or “license laundering” and I am also not against MIT license. My question is, why Canonical is doing this.

        • mesa@piefed.social
          link
          fedilink
          English
          arrow-up
          0
          arrow-down
          1
          ·
          1 month ago

          Im not sure as well. A lot of popular stuff is on MIT. But if I were to guess, its one of the most permissive licenses, which is somewhat a bad thing when companies suction up solutions with AI and spit them out without attributing the coder involved.

          • thingsiplay@lemmy.ml
            link
            fedilink
            arrow-up
            0
            arrow-down
            1
            ·
            1 month ago

            I don’t think Ai companies care about the license at all, or cannot be checked after the training. So that is not really an argument to me.

            • mesa@piefed.social
              link
              fedilink
              English
              arrow-up
              1
              ·
              edit-2
              1 month ago

              haha. Welp it only becomes an issue if your software doesn’t get audited. I worked in medical and government so it might be a different world where your at. We literally cant use certain software given licenses and such. It can get a bit loony.

              AI has tells they built in nowadays. If you use the newer models at least. But in addition…its pretty easy to just find the code in codebases if you end up in an audit.

              Im not defending it, just saying that MIT is one of those that you can get away with a lot more than other licenses. And that might be an issue to some.

              • thingsiplay@lemmy.ml
                link
                fedilink
                arrow-up
                0
                arrow-down
                1
                ·
                1 month ago

                I can’t speak for medical field… but a more serious topic, in example videogames. :D

                I think sometimes GPL can be in the way, so it is a tradeoff. In example if you use proprietary Steam features in your game, then you cannot build the game with GPL libraries and code, because that is not compatible with proprietary code. For some that is exactly what the GPL is set to do, for others its hindering games and other software to be released on Steam with Steam features. That means, its impossible to sell GPL software on Steam, if you want to use any of those features (I think in example Achievements and online save files in example). MIT would solve this issue.

                • mesa@piefed.social
                  link
                  fedilink
                  English
                  arrow-up
                  1
                  ·
                  1 month ago

                  Ill be honest, I know of GPL but I know theres like 5 different versions of the GPL. Like AGPL is the most restrictive and has held up in court before because someone forked a project then stripped out everything, sold it again. And was deemed liable.

                  MIT could potentially solve it…or make it even more messy. Ill believe you on videogames.

                  If I were to guess, its probably moot in all cases unless it goes to court (or like my orgs not let you use software) and gets defended one way or another.

    • TeaWithDani@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      1 month ago

      Rust eliminates memory safety vulnerabilities. It accounts for a large percentage of bugs that need patching in live environments, like servers.

      I believe Ubuntu wants to grow in Iot or embedded devices so reducing patching needs gives them a competitive edge there.

      • SayCyberOnceMore@feddit.uk
        link
        fedilink
        English
        arrow-up
        0
        ·
        1 month ago

        Whilst that may be true, I would expect coreutils has all memory issues debugged by now.

        I can understand new applications - or perhaps extended versions - to be created in Rust, rather than reinventing perfectly good wheels.

        It feels like they’re doing this just for the sake of it, and I expect there’s probably better things that could be done with the money / labour

    • BB_C@programming.dev
      link
      fedilink
      arrow-up
      0
      ·
      1 month ago

      Getting ahead of the curve regarding potential future legislations/regulations around unsafe languages, which may introduce contract conditions, liabilities…etc (See 2:30-4:30 of this talk for an overview).

      If they listened to the calls describing this move as premature, and it arguably was, they could have gotten strapped for time later.

      An implementation in a good safe fast modern language that developers actually enjoy has other tangible benefits of course. But if people want the “corpo reason”, the above should provide an answer.

      • thingsiplay@lemmy.ml
        link
        fedilink
        arrow-up
        1
        ·
        1 month ago

        Little late, but currently watching the entirety of the talk. Very interesting to see a honest view from someone who is invested into safety and C++. The language itself will probably never be safe, but maybe “safe enough”.

    • mofongo@discuss.tchncs.de
      link
      fedilink
      arrow-up
      1
      ·
      1 month ago

      They’ve been partners ever since WSL launched, it was initially only available with Ubuntu.

      Trust that Microsoft will send upstream any feature they don’t want to maintain themselves. Slowly, but surely there will be featured that only work on Windows. Then, when they believe they don’t have to play nice anymore, they’ll close off the code.

      Embrace, Extend, Extinguish.

  • Hueristic_Autistic@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    1 month ago

    So for someone coming back into the open source linux world and went back to Ubuntu, does this mean that they’re becoming like Microsoft? Does this mean I need to try a different OS?

    Faaack I love Ubuntu but I won’t stand for sticking with enshittification. Windows 11 dogshit is unavoidable trash and Ubuntu is at least a silver lining for a put together somewhat well managed OS.

    • someonesmall@lemmy.ml
      link
      fedilink
      arrow-up
      1
      ·
      1 month ago

      Why Ubuntu though? For someone migrating from Windows I can recommend using an immutable distro like Bazzite/Silverblue/Kinoite (based on Fedora Atomic) or Opensuse Tumbleweed.