Ubuntu Will Use Rust For Dozens of Core Linux Utilities

Ubuntu "is adopting the memory-safe Rust language," reports ZDNet, citing remarks at this year's Ubuntu Summit from Jon Seager, Canonical's VP of engineering for Ubuntu: . Seager said the engineering team is focused on replacing key system components with Rust-based alternatives to enhance safety and resilience, starting with Ubuntu 25.10. He stressed that resilience and memory safety, not just performance, are the principal drivers: "It's the enhanced resilience and safety that is more easily achieved with Rust ports that are most attractive to me". This move is echoed in Ubuntu's adoption of sudo-rs, the Rust implementation of sudo, with fallback and opt-out mechanisms for users who want to use the old-school sudo command.

In addition to sudo-rs, Ubuntu 26.04 will use the Rust-based uutils/coreutils for Linux's default core utilities. This setup includes ls, cp, mv, and dozens of other basic Unix command-line tools. This Rust reimplementation aims for functional parity with GNU coreutils, with improved safety and maintainability.

On the desktop front, Ubuntu 26.04 will also bring seamless TPM-backed full disk encryption. If this approach reminds you of Windows BitLocker or MacOS FileVault, it should. That's the idea.
In other news, Canonical CEO Mark Shuttleworth said "I'm a believer in the potential of Linux to deliver a desktop that could have wider and universal appeal." (Although he also thinks "the open-source community needs to understand that building desktops for people who aren't engineers is different. We need to understand that the 'simple and just works' is also really important.")

Shuttleworth answered questions from Slashdot's readers in 2005 and 2012.

"aims for functional parity"

[Anonymous Coward]

So in other words it's unfinished and doesn't yet have functional parity. Good to know when my collection of very old shell scripts start breaking.

Re:"aims for functional parity"

[Fly Swatter]

'We didn't see a reason anyone would want to keep that feature' - bug closed.

reality: just like a bad movie remake, we couldn't be bothered to put in the effort that made the original popular.

Re: "aims for functional parity"

[Compholio]

They broke the unattended upgrade facility and didn't seem to care, so "yes".

Re:

[bill_mcgonigle]

Reportedly that bug would have been caught if they passed the preexisting date test suite, but their attitude was 'meh'.

I'm not advocating for C but I am advocating for Level I software engineering. Rust doesn't fix this.

Breaking updates is one of the worst positions to be in. Press coverage is a poor substitute, though it's good that it got some.

Re:

[phantomfive]

They are replacing ls, mv, and cp. If there was ever a need for a tool that doesn't leak memory, it was ls. You have no idea how many systems I've had to reboot because a long running ls instance took up all the memory after several days. Also, hackers are well known to use the ls utility to break into ring zero secure boot conclaves. So this can't come soon enough.

Re:

[Mr. Barky]

If the new version of ls is feature compatible with the old, why would it necessarily be better at memory allocation? If a given operation requires a lot of memory in one implementation, it probably will in another. (I have no idea what ls would be doing to require so much memory... I've only used it for simple things.)

Obviously if the current ls has security flaws, a new implementation might fix that (and if the memory use is related to bugs, then a new implementation could also fix that - but it could - a

Re:"aims for functional parity"

[Samare]

Exactly, and there's even a graph of the compatibility over time: https://github.com/uutils/core... [github.com]

Re:

[KiloByte]

If you want an actually sane replacement, made to match POSIX (rather than just bug-for-bug), try voreutils [sr.ht]. Rust free!

Re:

[damas]

I understand the reasoning for porting SUDO, but why mess with the other coreutils? Aren't they local tools for local account usage?

Re:

[mrfaithful]

The conspiratorial take is that it's less to do with "rust gooder" and more to do with "MIT license helps corporate." sudo is probably something I'd rather they don't touch. sudo has had many CVEs against it, but really not that many that were due to C snafus. If it had been rust since before there even was a rust it still would have almost as many CVEs because they were mostly logic problems. Reimplementing it runs a very real risk of bringing back all those problems as the new authors learn by doing.

Peak Tulip Mania

[kurt_cordial]

Reminds me of 1996, before Sridhar Vembu and Tony Thomas founded AdventNet.

Snap

[Anonymous Coward]

No thanks, I will stick with Debian.

Re:

[x0ra]

Don't worry, Canonical is going to enshittify Debian too - https://lists.debian.org/debia... [debian.org]

Re:

[vbdasc]

As far as I see things, it's just the apt maintainer having some interesting ideas. It won't pass without a fight, or even a schism like it went with Devuan.

Will make things less secure

[gweihir]

As any reimplementation does. Rust is not magic. And these basic commandline tools are exceptionally well tested.

Re:Will make things less secure

[abulafia]

They have all the solutions to hard lessons learned written in C for reference, so if they aren't lazy, this shouldn't be too bad.

I agree that, if I had some engineers lazing about and wanted to do something to raise the security bar, this is probably not where I would start.

I think it is more likely that Canonical is worried about IBMHat's increasingly possessive behavior and feels the need to increase it's "ownership" stake in Linux writ large. Depending on Debian gives them a massive leg up on development, but is at best not helpful (and generally a liability for) for strategic control struggles, which is where this is going.

Re:

[Cinder6]

Perhaps they were lazy. [phoronix.com] I read on HN (can't find the post) that even simple tools were failing 3/4 of tests, yet Canonical pushed them out anyway.

Re:

[tlhIngan]

Well, it' passes 3/4 of the GNU tests. The tools aim for 100% GNU compatibility - but you don't need 100% GNU compatibility to be useful. (Think: /bin/sh vs. /bin/bash)

You need compatibility with the common options people use it for - so if it doesn't support some rare and obscure GNU extension that no one uses, it will fail the test but in practical reality, no one would notice.

Ubuntu is also using 25.10 as a beta for 26.04 LTS - so passing 75% of tests would mean most people probably wouldn't notice. And

Re:

[allo]

The developers of the rest tools avoid looking at the source of the finished C programs, because they want to use a less strict license. It is probably about providing Canonical a better way for commercial licensing, just as Android and macOS do not ship GNU tools.

Re:

[pusoozer]

"Avoid looking at source code..." -- Well that explains it, No requirements documents, can't look at source code, so only the man pages are left, and since sort order isn't mentioned in the ls man pages, locale's LC_COLLATE is ignored. I await the 10 years of bad locale implementations done in C to be repeated in Rust ;^( My real issue is making the rust coreutils the default in 25.10.

Re:

[gweihir]

It is not that easy. Otherwise you could build a C-to-Rust compiler and use that. Instead, language semantics is different enough that it will takes 10 years of longer (with widespread adoption, otherwise longer) for these new Rust versions to become as stable and secure as the C ones.

Re:

[Beeftopia]

They have all the solutions to hard lessons learned written in C for reference, so if they aren't lazy, this shouldn't be too bad.

Reading existing code is hard. Editing it without introducing regressions is harder. That's why IMO there's always a desire to sweep the board clean and start anew. That is more fun, and easier, than figuring out the nuances of the existing code. Programmers often don't want to be maintenance programmers. If you apply this analogy to buildings, it's the desire to raze and rebuil

Re:Will make things less secure

[thegarbz]

Yes we all know how "exceptionally well tested" they are. I mean there certainly hasn't been CVEs issued for OpenSSH, sh, chroot, glibc, or net-tools, and surely even if there were, they weren't all discovered this year alone and didn't all come up with a search limited to just the last 9 months...

Oh wait.

Re:

[bsolar]

Yes we all know how "exceptionally well tested" they are. I mean there certainly hasn't been CVEs issued for OpenSSH, sh, chroot, glibc, or net-tools, and surely even if there were, they weren't all discovered this year alone and didn't all come up with a search limited to just the last 9 months...

They are exceptionally well tested, but that doesn't mean they are bug-free. The question is more whether the Rust versions are already more secure or will be more secure in the future. Rust does prevent significant types of exploits, but not all of them.

That the new utils need maturing is evident by Ubuntu's own transition, which led to uncovering a number of issues. Early adopters will always face these kind of maturity issues, but the more early adopters the faster the code matures.

Re:Will make things less secure

[HiThere]

Are you pretending that new code won't have it's own problems just because its written in Rust???

Re:

[thegarbz]

Not at all. But it does prevent a whole class of exploits for a given kind of bug.

Re:

[jsonn]

Take a look at the history of GNU TLS. When they started, they managed to repeat pretty much any algorithmic bug OpenSSL and friends made years before. There is little reason to believe that all those shiny new Rust replacements won't have all kinds of bugs yet again.

Re:

[phantomfive]

We don't expect GNU TLS to be any different than OpenSSL. We expect LibreSSL to be better than OpenSSL because it is made with better engineering practices (some listed in the following link): https://en.wikipedia.org/wiki/... [wikipedia.org]

Re:

[thegarbz]

Who said there won't be bugs?

Re:

[Anonymous Coward]

You know how well secured OpenSSH is? It's not like you can exploit it with a rogue pointer. And some of their internal techniques cannot even be mimiced by rust (without unsafe blocks). If you get full access inside OpenSSH, you're still not root, because they shield different code parts against each other. You may take the other programs to make a point (I dunno about their security), but using OpenSSH as example weakens your point a lot.

Re:

[93 Escort Wagon]

I mean there certainly hasn't been CVEs issued for OpenSSH, sh, chroot, glibc, or net-tools, ...

You're responding to a statement about coreutils by listing applications which for the most part aren't in coreutils.

Re:

[thegarbz]

You're responding to a statement about coreutils by listing applications which for the most part aren't in coreutils.

Oh right, sorry, I guess a whole lot of Linux programs that have existed since the 80s aren't tested. I see my mistake now. Only core utilities got tested. Gotchya! Thanks for correcting my mistake.

Re:

[gweihir]

Indeed. That is because he is simply an asshole with a big ego but very limited insight.

Re:

[gweihir]

And all these are issues that are impossible in Rust, surely? No, they are not. And a reimplementation will add a ton of new issues, no way around that.

Incidentally, the story is not at all about OpenSSH and some of the other stuff you are dishonestly slinging around just to confuse the issue.

Re:

[thegarbz]

And all these are issues that are impossible in Rust, surely?

No of course not. And that's not what I said. And the fact that you just posted this as your first counter argument is incredibly dumb. I'm not going to tell you what logical fallacy you committed, go learn about how to structure an argument and then come back and tell the class what you did wrong.

Oh great, a fresh set of bugs & vulns to iron

[Rosco P. Coltrane]

Note to self: stick to Debian and don't touch Ubuntu or Mint for a few versions until the kinks have been worked out.

Re:

[fluffernutter]

.. or at least until the developers learn memory management.

Re:

[PPH]

.. or at least until the developers learn memory management.

It'll all be maintained and updated by AI. So there's nothing for devs to learn. Because there's none left.

But, all that said: What will we need Rust for since the AI can write perfectly secure C and C++?

Re: Oh great, a fresh set of bugs & vulns to i

[fluffernutter]

Or maybe AI will just work in machine code with even higher optimisation than compiled C.

Re:

[QuietLagoon]

}}} don't touch Ubuntu or Mint {{{

.

I use the Debian-based version on Mint.

Re:Oh great, a fresh set of bugs & vulns to ir

[Big Hairy Gorilla]

I'll play devil's advocate. Notwithstanding having to endure Systemd, Debian is light years closer to freedom than Ubuntu or Mint. Mint is probably closer, but Ubuntu has become an abomination. Under what circumstances would it be a better or even reasonable choice vs vanilla Debian with the DE of your choice? Assuming desktop systems, since you mentioned Mint.

Re:

[markdavis]

>"Debian is light years closer to freedom than Ubuntu or Mint. "

Mint is much better in many ways than Ubuntu, yet retains compatibility. But you also have the option of Mint LMDE (Linux Mint Debian Edition), which is much of the same Mint goodness (installer, tools, desktop options), but based directly on Debian instead of Ubuntu:

https://www.linuxmint.com/down... [linuxmint.com]

Re:

[AleRunner]

Presumably LMDE is, in the end just some free software on top of Debian. Does anyone know what limits the Debian project from adopting it as their own and fully supporting it?

Re:

[markdavis]

Not sure, but curious, myself. Debian seems to be the only "pure in spirit" and "non-crazy" distro left out there. It is just kinda unpolished... which is what Mint LMDE brings to it. I haven't tried it yet, since I am fine with "regular" Mint. But at some point I think that will change, when Ubuntu does something bad enough under the hood on Mint. That is, of course, why LMDE exists.

Re:

[AleRunner]

Do I understand you see Arch and Gentoo as crazy? Presumably then also NixOS?

Re:

[volcan0]

Dude, Gentoo IS crazy.

Regards,
A Gentoo User.

Re:

[markdavis]

>"Do I understand you see Arch and Gentoo as crazy? Presumably then also NixOS?"

Maybe what I wrote is a bit too extreme/sloppy. I wouldn't call Arch, at least, crazy. I meant corporate-controlled Linux distros but neglected to include that qualifier. Wish I could edit...

Re:

[Big Hairy Gorilla]

I''l be "that guy" in this thread.

If you've managed to avoid Gnome, Snaps, Unity, and hopefully what someone aptly called "IBMHat", unfortunately IMHO, you are still the prisoner of Systemd. Why not go take back control and go full Devuan? .... but I can actually understand using Debian. It offers great stability and compatibility to software.
I use it on a few systems, where I have to because of dependencies.
Desktop users stop reading here.

Sysops may continue reading:

with sysvinit. Write your own boot units

Re:

[thegarbz]

Under what circumstances? Ubuntu still has a more cutting edge release cycle than Debian. Since you're talking desktops where people generally don't like to wait ages for packages to become available.

That said I'm sure many people on Slashdot would see not running the latest version of software as a bonus.

Re:Oh great, a fresh set of bugs & vulns to ir

[test321]

"Julian Andres Klode has announced that the Debian APT package-management tool will acquire 'hard Rust dependencies' sometime after May 2026. 'If you maintain a port without a working Rust toolchain, please ensure it has one within the next 6 months, or sunset the port.'" -- https://lwn.net/Articles/10444... [lwn.net]

Results count, press releases don't

[packrat0x]

Ubuntu has nothing without showing A/B testing, size, and speed.

Re:

[thegarbz]

Getting a bit ahead of yourself aren't you? The news here is that they are developing something. Jeesh your UID is too low to be an impatient millennial.

Re:

[MatthewNewberg]

790000 Is not a low UID.

Re:

[boaworm]

They are not "developing something", they are releasing something. As someone running 25.05 on a machine right now, i am being prompted repeatedly by the system to go install 25.10 with these tools live.

It's already going great!

[Hentes]

Unless you want to update, that is [lwn.net].

Hooray For Encryption!

[organgtool]

On the desktop front, Ubuntu 26.04 will also bring seamless TPM-backed full disk encryption. If this approach reminds you of Windows BitLocker or MacOS FileVault, it should. That's the idea.

I know this is for desktops, but could you please update the Ubuntu Server installer so that we can have FDE on drives with software RAID? The installer will let you create an encrypted partition via a volume group for / on top of software RAID, but the installer craps out with a fatal error while attempting to install

As always

[quonset]

When anyone says they're using Rust for anything [9cache.com].

Re:

[kertaamo]

Where doe this nonsense about Rust people wanting to rewrite everything in Rust just "because"?

After six years of following discussions of Rust's developers and users I have heard almost no-one clamouring to rewrite everything in Rust. On the contrary they advise against it for all the obvious reasons. In general they have experience in all kind of languages, still use other languages and fully realise the challenges of rewriting stuff.

Admittedly I don't know what's up with the Ubuntu guys. But Ubuntu has b

MIT license

[iplayfast]

I guess Ubuntu is moving away from the gnu license. which has served it well for many years. Remember when Bsd unix had a license where companies could copy it and not contribute back to the source. Apple took that and ran with it. I wonder how much was lost to the world when it was relicensed under Apple's license. Ubuntu is going to the MIT license, which is nice, but not as nice as gnu as it doesn't require keeping any improvements open.

Re:

[Cinder6]

It's impossible to say what might have been, because we don't know what, e.g., Apple would have done if BSD used GPL. Maybe they would have used it anyway and opened their contributions, but it's perhaps just as likely we'd see many different closed implementations and even more security issues across the major platforms.

Re:

[AleRunner]

There might have been a few more closed implementations, however they would not have done nearly as much damage as the almost open status of Apple's systems. In fact, probably without that, Android would have been fully F/OSS, we would have the full set of device drivers needed to run the phones properly and all sorts of problems facing us such as e-waste and massive scale hacking of old devices by foreign adversaries would have been massively reduced.

Re:

[Mr. Barky]

I think there are few scenarios where either Apple or Google would chose to use a GPL licensed software in core software. It isn't in their DNA. These companies want full control. If MIT (or similar)-licensed code weren't available, they wouldn't have turned to a GPL version. They would have probably purchased another existing closed-source UNIX to use (or re-implemented their own version if they deemed that cheaper).

I am not sure how an "almost open" version (where hardly anyone contributes outside of the

Re:

[AleRunner]

I think there are few scenarios where either Apple or Google would chose to use a GPL licensed software in core software. It isn't in their DNA.

Yes. Which is an important advantage. Remember that both these companies to some extent (more Facebook, Microsoft and Google) have a policy of setting out to identify and destroy companies that might be developing profit. By keeping some distance from them you make more chance that you get far enough to profit either from building a business or actually selling to them at a sensible price.

Re:

[allo]

Without giving back one can assume that their implementation now differs quite a bit from how the original developed.

birlocker

[sjames]

I know of a few people who lost data due to bitlocker and regretted using it. I know nobody who has protected data due to bitlocker and was glad they used it.

So there's that.

Re:

[phantomfive]

Do you know anyone who says, "If only I had used bitlocker, my data would have been protected."?

Re:

[sjames]

That's the point, No I do not. Bitlocker protects against the wrong threat.

Sound great

[OrangeTide]

I mean in 10 years none of these programs will compile. But still, seems like a fun project to work on.

Ubuntu was not to be taken seriously anymore anywa

[Damouze]

I stopped using Ubuntu and taking it seriously when it introduced 'netplan', the idiotic network configuration system where one ill-placed whitespace character could lead your entire system into a boot loop (especially in conjunction with systemd, Linux's own version of svchost.exe).

Repeat after me: whitespaces are NOT tokens and should be ignored.

Safe C implementation seems to exist

[simlox]

https://fil-c.org/ [fil-c.org]. They claim to be able to compile much of the same code memory safe, so no need to rewrite in Rust. Unless the goal is Rust itself. Or corporate pressure to get rid of GPL - a pressure many in the Open Source community falls for.

Filed under...

[DjangoShagnasty]

Another reason to dump ubuntu