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.

top 50 comments

sorted by: hot top controversial new old
[–] 128 points 1 week ago (40 children)

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

  • source
  • hideshow 40 child comments
  • [–] 8 points 1 week ago* (last edited 1 week ago) (8 children)

    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.

  • source
  • parent
  • hideshow 8 child comments
  • [–] 20 points 1 week ago (7 children)

    Yea know that is a fair point. I guess I struggle to see any other reason to support this? Even though I believe rust is nominally more secure it’ll be a decade before any core utils clone will be as hardened as the original just by virtue of the original having decades of bug finding and fixes done already.

    I don’t think canonical would go through the effort under normal circumstances but I think they’re just taking the opportunity in front of them to ride the rust hype into a less copyleft ecosystem.

    This actually ties into a broader complaint I have that the rust ecosystem is built around MIT due to influence of the corporate backers of the rust foundation. Which is unfortunate because I actually really love rust as a language.

  • source
  • parent
  • hideshow 7 child comments
  • [–] 13 points 1 week ago* (6 children)

    My bet is, Canonical as a service provider has a customer that is willing to pay for access to more secure rust utils. Or they want to save resources fixing CVEs.

    There's also the spectre of future security regulations possibly demanding these changes one day too.

    I still think its built on someone else's money. lol

  • source
  • parent
  • hideshow 6 child comments
  • [–] 11 points 1 week ago* (last edited 1 week ago) (2 children)

    Ubuntu did invest in a security audit of uutils. It revealed issues that show fundamental misunderstandings on how to use posix APIs. If they cared about security they would have postponed the adoption at least one more cycle. Uutils are they not ready for general availability.

    Plus after decades of bug fixing coreutils doesn't have lots of security issues.

    The VP of engineering of canonical keynoted Rust conf about uutils and is pushing forward the project. My guess is for political capital inside canonical.

    Will long term uutils or another coreutils written in Rust will be a great improvement. Today is not the day.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 11 points 1 week ago (1 child)

    As an example look at that https://github.com/uutils/coreutils/issues/10011

    Even calling it a race is a looking at the issue wrong. They are creating the file with more permissions that necessary and restricting later instead of the other way around.

    There was another issue with chroot that had the same fundamental mistake.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 6 points 1 week ago (2 children)

    Hmm you could very well be right. I guess I’m being to reasonable by knowing new rust code is not automatically (and not usually) more secure then old c battle tested c code. Shareholders and CEOs don’t understand that, I wouldn’t be surprised if someone’s been convinced rust is axiomatically more secure and bankrolling the migration over it

  • source
  • parent
  • hideshow 2 child comments
  • load more comments (2 replies)
  • load more comments (30 replies)
    [–] 48 points 1 week ago (13 children)

    screw this project and it's goal of corporate takover of a GPL project

  • source
  • hideshow 13 child comments
  • load more comments (13 replies)
    [–] 46 points 1 week ago

    i don't really trust this

  • source
  • [–] 34 points 1 week ago (8 children)

    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.

  • source
  • hideshow 8 child comments
  • [–] 8 points 1 week ago (6 children)

    I had a problem literally today because some script was relying on a particular behaviour of dirname that was handled differently between uutils and GNU. It's been fixed already in a newer version than the one I had, but it took me a long time to figure out what the heck was going on, because finding a missing expectation in a nested shell script is tough...

    It was just mysteriously doing the wrong thing.

  • source
  • parent
  • hideshow 6 child comments
  • load more comments (6 replies)
  • load more comments (1 reply)
    [–] 22 points 1 week ago (5 children)

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

  • source
  • hideshow 5 child comments
  • [–] 20 points 1 week ago* (last edited 1 week ago) (1 child)

    The corporate adoption on uutils already started.

    https://learn.microsoft.com/en-us/windows/core-utils/overview

    Windows is now using uutils for their coreutils. I want to see if Microsoft gives back anything to the project with that permissive license. Also, aren't canonical and Microsoft partners or something? I saw the Ubuntu wsl news.

  • source
  • hideshow 1 child comment
  • [–] 6 points 1 week 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.

  • source
  • parent
  • [–] 17 points 1 week ago (3 children)

    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.

  • source
  • hideshow 3 child comments
  • [–] 19 points 1 week ago* (2 children)

    The problem with macOS is that they use BSD utils, which are lacking functionality from GNU utils. If anything, Rust uutils 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.

  • source
  • parent
  • hideshow 2 child comments
  • load more comments (2 replies)
  • [–] 13 points 1 week 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.

  • source
  • [–] 9 points 1 week ago (9 children)

    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?

  • source
  • hideshow 9 child comments
  • [–] 38 points 1 week ago (5 children)

    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.

  • source
  • parent
  • hideshow 5 child comments
  • [–] 5 points 1 week ago

    Two additions:

    • some software is also sold under a separate license in addition to GPL, so you can choose if you want free open source or paid closed source (e.g. Qt has this model)
    • being in breach of license terms doesn't mean you're forced to do anything automatically: it means you can get sued and a judge might order you to do something (probably pay money) to heal the breach, or you can settle out of court (probably by paying money).
  • source
  • parent
  • load more comments (4 replies)
  • [–] 15 points 1 week ago (1 child)

    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.

  • source
  • parent
  • hideshow 1 child comment
  • load more comments (1 reply)
    [–] 5 points 1 week ago

    The rust has set in and the rot begins...

  • source
  • load more comments
    view more: next ›