Ubuntu Will Use Rust For Dozens of Core Linux Utilities (zdnet.com)
- Reference: 0179927544
- News link: https://news.slashdot.org/story/25/11/01/079206/ubuntu-will-use-rust-for-dozens-of-core-linux-utilities
- Source link: https://www.zdnet.com/article/inside-canonicals-plan-to-make-ubuntu-26-04-the-linux-desktop-that-finally-goes-mainstream/
> . 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 [2]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 [3]sudo-rs , Ubuntu 26.04 will use the Rust-based [4]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 [5]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 [6]in 2005 and [7]2012 .
[1] https://www.zdnet.com/article/inside-canonicals-plan-to-make-ubuntu-26-04-the-linux-desktop-that-finally-goes-mainstream/
[2] https://thenewstack.io/why-sudo-rs-brings-modern-memory-safety-to-ubuntu-26-04/
[3] https://github.com/trifectatechfoundation/sudo-rs
[4] https://github.com/uutils/coreutils
[5] https://www.gnu.org/s/coreutils
[6] https://interviews.slashdot.org/story/05/04/04/1859255/mark-shuttleworth-answers-at-length
[7] https://news.slashdot.org/story/12/12/09/1828238/mark-shuttleworth-answers-your-questions
Peak Tulip Mania (Score:2)
Reminds me of 1996, before Sridhar Vembu and Tony Thomas founded AdventNet.
Snap (Score:2)
No thanks, I will stick with Debian.
Will make things less secure (Score:5, Insightful)
As any reimplementation does. Rust is not magic. And these basic commandline tools are exceptionally well tested.
Re:Will make things less secure (Score:5, Interesting)
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: (Score:2)
[1]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.
[1] https://www.phoronix.com/news/Ubuntu-25.10-Coreutils-Makeself
Re: (Score:2)
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:Will make things less secure (Score:4, Interesting)
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: (Score:2, Insightful)
> 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: (Score:2, Flamebait)
Are you pretending that new code won't have it's own problems just because its written in Rust???
Re: (Score:2)
Not at all. But it does prevent a whole class of exploits for a given kind of bug.
Re: (Score:2)
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: (Score:2)
> 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: (Score:2)
> 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.
Oh great, a fresh set of bugs & vulns to iron (Score:4, Insightful)
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: (Score:3)
.. or at least until the developers learn memory management.
Re: (Score:2)
> .. 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 (Score:2)
Or maybe AI will just work in machine code with even higher optimisation than compiled C.
Re: (Score:2)
}}} 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 (Score:5, Interesting)
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: (Score:2)
> "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:
[1]https://www.linuxmint.com/down... [linuxmint.com]
[1] https://www.linuxmint.com/download_lmde.php
Re: (Score:2)
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: (Score:3)
"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.'" -- [1]https://lwn.net/Articles/10444... [lwn.net]
[1] https://lwn.net/Articles/1044496/
Results count, press releases don't (Score:3)
Ubuntu has nothing without showing A/B testing, size, and speed.
Re: (Score:2)
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.
It's already going great! (Score:3)
[1]Unless you want to update, that is [lwn.net].
[1] https://lwn.net/Articles/1043103/
Hooray For Encryption! (Score:2)
> 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 (Score:3)
When anyone says they're [1]using Rust for anything [9cache.com].
[1] https://img-9gag-fun.9cache.com/photo/aGyzA9X_700bwp.webp
MIT license (Score:1)
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: (Score:2)
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.
birlocker (Score:2)
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.
"aims for functional parity" (Score:2, Insightful)
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" (Score:5, Insightful)
'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" (Score:4, Insightful)
They broke the unattended upgrade facility and didn't seem to care, so "yes".
Re: (Score:3)
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: (Score:3)
Exactly, and there's even a graph of the compatibility over time: [1]https://github.com/uutils/core... [github.com]
[1] https://github.com/uutils/coreutils?tab=readme-ov-file#gnu-test-suite-compatibility
Re: (Score:2)
If you want an actually sane replacement, made to match POSIX (rather than just bug-for-bug), try [1]voreutils [sr.ht]. Rust free!
[1] https://sr.ht/~nabijaczleweli/voreutils/