Canonical's VP of Engineering Jon Seager discusses Ubuntu's deliberate, incremental shift toward Rust-based core system tools, based on a RustRover livestream. Ubuntu 26.04 LTS shipped uutils coreutils and sudo-rs as defaults; ntpd-rs (funded via the Trifecta Tech Foundation) is planned to replace chrony and linuxptp, archiving in 26.10 and fully switching by 28.04; UPKI, a new certificate-revocation project with Rustls, targets 26.10. The piece covers compatibility trade-offs (uutils aiming for bug-for-bug GNU compatibility vs. sudo-rs's intentional behavior changes like asterisk password masking), why changes land at LTS boundaries, Rust packaging via vendored crates and cargo auditable SBOMs, snaps for cross-release compatibility, and future work on Rust-based compression libraries (bzip2-rs, zlib-rs, zstd-rs).
Table of contents
Why Ubuntu is betting on RustWhat is changing in UbuntuThe trade-offsUbuntu Rust: Packaging and deliveryWhat comes nextQuestions this post answers
What Rust tools did Ubuntu 26.04 LTS ship as defaults, replacing GNU coreutils and sudo?
Ubuntu 26.04 LTS shipped uutils coreutils, a Rust reimplementation of GNU coreutils aiming for 100% bug-for-bug compatibility, and sudo-rs, a Rust rewrite of sudo that intentionally changes some behavior, such as showing asterisks by default when typing a password. Both replaced their legacy C counterparts as defaults, while the original utilities remain available in the archive. Track distro-level Rust migrations like this on daily.dev before they land in your next LTS upgrade.
When will Ubuntu switch to ntpd-rs as the default time sync tool instead of chrony and linuxptp?
Ntpd-rs is planned to be archived in Ubuntu 26.10, with a full default switch to it in Ubuntu 28.04, replacing both chrony and linuxptp with a single tool handling NTP, NTS, and PTP. Canonical is funding the Trifecta Tech Foundation to bring ntpd-rs to Ubuntu, announced in June 2026. Follow timelines like this ntpd-rs rollout on daily.dev to plan infrastructure upgrades ahead of time.
Why did uutils coreutils revert its more correct behavior for reading bytes from an empty file back to match GNU coreutils?
Uutils coreutils initially returned an error when told to read N bytes from an empty file, which is arguably more correct than GNU coreutils' behavior of returning zero, but this broke a script buried in an Obsidian snap, so the maintainer reverted it to match GNU behavior. This reflects uutils' priority of 100% bug-for-bug compatibility with GNU coreutils over correctness improvements. Developers weighing compatibility versus correctness in tool rewrites can follow cases like this on daily.dev.