Forgot your password?
typodupeerror
Ubuntu Open Source Programming

Ubuntu's 'Rust-ification' Hits New Milestone: Coreutils Migration is Complete (itsfoss.com) 158

"Ubuntu has managed to do away with GNU Core Utilities in its default stack," reports the blog It's FOSS.

The last three utilities — cp, mv and rm — have been moved to versions from the uutils project (which reimplements utilities in Rust). Everything else, from ls and cat to chmod and du, made that jump in earlier releases... Canonical started "oxidizing" Ubuntu last year, and Ubuntu 25.10 became the first release to ship [ the uutils project's] 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.

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.

Ubuntu's 'Rust-ification' Hits New Milestone: Coreutils Migration is Complete

Comments Filter:
  • by Anonymous Coward on Wednesday September 16, 2026 @12:07AM (#66339242)

    They might as well have rewritten SystemD in Rust and made again zero impact.

    • by strUser_Name ( 7991504 ) on Wednesday September 16, 2026 @12:48AM (#66339262)
      They made impact alright. The big difference is loads of new security issues and loads of incompatibility with edge case usage. It is such a big set-back that it would be unwise to even keep using Ubuntu at this point.
      • by gweihir ( 88907 ) on Wednesday September 16, 2026 @01:23AM (#66339272)

        Which is in no way surprising. Re-implementing well-working, _old_ tools is just dumb.

        • by Anonymous Cward ( 10374574 ) on Wednesday September 16, 2026 @05:09AM (#66339420)
          Try running a Loki Games installer and watch it fall over because head and tail are no longer compatible with themselves without using random, obscure environment variables to try and restore the original default behaviour. That is just the tip of the iceberg for backwards incompatible changes internal to "old" utilities which do in fact still receive regular changes.

          My only complaint with Canonical's approach was pushing half and half into an Ubuntu LTS, which was clearly a terrible idea to anyone watching, but now they're stuck with it, I'm sure they'll learn from it.
          • by gweihir ( 88907 )

            That is why I wrote "well working". Seriously, what is it with people unable to understand compact and clear language?

        • by CAIMLAS ( 41445 )

          This IS the Rust community you're talking about, after all.

          While Rust is a fine language, the community tends to be a bit fanatical and irrational. Pair that with a generally shallow technical aptitude depth and a lack of experience, and vibe coding, and therein lies the problem. There seems to be a high intersection between them and the systemd, so that's not a surprise.

          And that's without getting into questionable mental health practices that are common in that community.

      • by canavan ( 14778 ) on Wednesday September 16, 2026 @03:20AM (#66339332)
        The coreutils are surprisingly complex. If you know a little about kernel functions, it feels like any of those tools should basically map to just a single kernel call. The requirements of the POSIX-standard(s) that define how exactly the tools should work, including how they should handle and report errors, as well as limitations of filesystems (such as long filenames, unsupported characters, ACLs) make correct implementations quite a chore. I'm wondering if the rust implementations pass the test suite that's included in the gnu coreutils source. Does anyone here know?
  • Different license (Score:5, Informative)

    by toutankh ( 1544253 ) on Wednesday September 16, 2026 @12:19AM (#66339250)

    The Rust version is licensed under the MIT license, in case anyone was wondering. The Ubuntu Discourse post says the change is not about licensing, but about security. What it does not provide is any kind of statistic on security issues related to coreutils.

  • Ok, but⦠(Score:4, Funny)

    by kon_ig ( 639555 ) on Wednesday September 16, 2026 @01:29AM (#66339278)
    Not in any way trying to diminish work developers put into this effort, but with all due respect, how difficult can it be to re-write utilities such as cp, mv and rm?
    • Re: Ok, but⦠(Score:4, Interesting)

      by Mr. Dollar Ton ( 5495648 ) on Wednesday September 16, 2026 @01:45AM (#66339286)

      From what little experience I have with rust, the ideology of the language is rather different from c, so while the full set of use cases across all those supported OSes is largely analogous, the implementation has little potential for copypasta, especially where those subtle differences exist.

    • There's versions available in every language, as far as I can tell...

    • Re:Ok, but⦠(Score:5, Insightful)

      by nyet ( 19118 ) on Wednesday September 16, 2026 @03:36AM (#66339348) Homepage

      Literally every one of the coreutils tools have some odd edge cases - some that make sense, some that do not. But at some point that behavior is something that callers expect, and when a replacement does not behave that way... You know the rest. "#define bad" etc.

      • One thing I noticed about modern Linux is if you "cat > file" and then press CTRL-C it overwrites with a blank file. It's not supposed to do that. It's not supposed to create a file at that point and it's supposed to leave the file untouched if it already existed. It's actually a little worrisome that such basic things are wrong.
        • What exactly is wrong with that?
          • Because now you are fighting a language that is trying to prevent you from making mistakes and not getting any benefit out of it and you are reinventing the wheel for little reason. Furthermore you are limiting yourself in terms of the ecosystem. You can't use anything really powerful like Qt because then you are just admitting that C++ is better in the first place.
          • Sorry I answered the wrong comment. To answer what is so bad with that, say you do "cat > file_you_want_to_keep". Now how do you save the file? You can't. Even pressing CTRL-C will wreck it.
            • by gweihir ( 88907 )

              Yes. Same thing as if you do "rm -f" on the file, that is of you have aliased rm to normally ask. For some things you just have to know to be careful. If you do not, that is on you. It is not the fault of the tool.

              • No, it's not the same. There has never been a way out in the OS with rm - f as in your example. I am talking about a specific circumstance where there used to be a way out because someone thought about it carefully at some point but more recent lack of thinking has closed that door, thus forcing the people who use the OS to change their habits slightly.
                • by gweihir ( 88907 )

                  Ah, I see. You do not know how file opening works on Linux. ">" opens files with O_TRUNC. Absolute standard c-library functionality. Nobody is out to get you.

                  • The thing is, no file should be opened until EOF. That's how it used to work in Linux.
                    • That is wrong. That was never how it worked. You don't even know how it works! Every time you post this shit you prove to the whole world that you have no idea what you are on about. Linux has always done it the same way Unix has always done it, and it's the opposite of how you think.

                      Redirection is handled by the shell, I posted an article about that, you can just go read that to see how clueless you are and how it actually works.

                • I am talking about a specific circumstance where there used to be a way out

                  No, you aren't.

                  This is how redirection [dev.to] has worked in UNIX and Unixlikes ever since it was invented.

                  You are imagining that the system used to work the way you wanted when it never did.

        • Re: Ok, but⦠(Score:4, Interesting)

          by gweihir ( 88907 ) on Wednesday September 16, 2026 @06:17AM (#66339472)

          That works as intended. The problem is on your side.
          From the bash man-page: "If the file does not exist it is created; if it does exist it is truncated to zero size."

          If you really want this to work differently, modify or write your own shell.

        • Yes that is what it is supposed to do. You opened a pipe to a file destructively, it did what you asked. Don't ask for that if you don't want it. Once you do that the original file is gone. Either append with >> or write to a temp file next time.

        • by Wolfrider ( 856 )

          > One thing I noticed about modern Linux is if you "cat > file" and then press CTRL-C it overwrites with a blank file

          That maybe a shell-ism. In bash if you ' >file ' with nothing else, you end up blanking the file (and updating the date/time on it) without ^C even being involved.

    • by nyet ( 19118 )

      It's worth noting that busybox replicates many of them, and it has its own oddities.

      • by DrXym ( 126579 )
        Busybox, Toybox and others. The vast majority of docker images running in the wild probably aren't even using coreutils because their aim is small containers with minimalist userland with some even going distroless. They don't even use glibc, using something like musl instead.

        I think for a general purpose Linux dist you'd definitely need coreutils or a drop-in replacement. I think coreutils has a lot of very esoteric features, which uutils have copied so even so, there is merit in examining these and depr

      • It's worth noting that busybox replicates many of them, and it has its own oddities.

        Likewise with *BSD.

    • It's one git clone and a couple of Claude prompts. What could it cost? 10M tokens?

    • Re:Ok, but⦠(Score:5, Insightful)

      by Tom ( 822 ) on Wednesday September 16, 2026 @04:59AM (#66339412) Homepage Journal

      Considerably more difficult than you imagine. Between them, they have almost 70 command-line options or flags. Taking into account that many of those behave differently depending on the presence or absence of other flags, there's a couple hundred different code paths. Then you need to handle directories, files, sparse files, sym- and hard-links, on and across different filesystems, not to mention the various file-like things scattered around (pipes, streams, etc.)

      It's not rocket science, but neither is it trivial.

    • by tlhIngan ( 30335 )

      Not in any way trying to diminish work developers put into this effort, but with all due respect, how difficult can it be to re-write utilities such as cp, mv and rm?

      To do basic functionality? Not hard. Busybox and toybox implement the "90%" use cases of those utilities inside them.

      To achieve POSIX compliance requires more work - you're adding stuff that handles edge cases and little used functionality.

      To achieve GNU coreutils functionality with GNU extensions is a bit more work on top of that.

      Uutils though

  • by Schoenlepel ( 1751646 ) on Wednesday September 16, 2026 @07:43AM (#66339506)

    MIT is _much_ more permissible than GPLv3. I can entirely understand Ubuntu jumping on a change of software, which does the exact same thing, but under a license which is more favorable for corporations.

    That uutils is written in rust, is all a happy coincidence. Security issues aside, with MIT code they can do whatever they want, GPLv3 has all kinds of inconvenient consequences when they work on it. Some of them, I think, a company would be _very_ unhappy with.

    I wouldn't be amazed if Canonical wants to be rid of everything GNU from their core OS somewhere in the future, simply because of the license.

    That something is written in rust, doesn't automatically mean it's better. Also, as older does not automatically mean better, so does newer not automatically mean better.

    • I use Linux specifically because of the license. Linux succeeded because of the license. If Ubuntu wants to change what made Linux successful then the obvious thing to do is to change to not using Ubuntu.

      • This whole discussion has been fascinating. Sadly, the majority of it is over my head. Right now I'm just wondering if this is the moment in history where Mint starts to abandon Ubuntu and goes all in on LMDE.

  • I'm a C coder in my day job, but I have no horse in the Rust nor *nix races. I wonder whether the switchover will lessen the number of Linux contributors in the future who will have to learn another language. I can't tell you how many times I've heard "just learn this new, better thing now" over my career.
    • by HiThere ( 15173 )

      If things were to otherwise stay the same, then it would. They won't. Some descendant of "vibe coding" will become the dominant mode within 20 years. Probably a *lot* sooner. Next year wouldn't really surprise me.

  • 1. GNU coreutils is ancient as is sudo. There's bound to be a metric ton of legacy code in there for all sorts of bizarre edge cases encountered across many platforms and systems over decades. Duplicating all the C code into RUST is a nightmare and the evidence is found in the delays with the uutils being deployed.
    2. This is not about security it's about hijacking the GNU General Public License.

    I was going to upgrade an LTS server to this new release but now I am seriously considering making a different Li

Today's scientific question is: What in the world is electricity? And where does it go after it leaves the toaster? -- Dave Barry, "What is Electricity?"

Working...