Ubuntu 26.10 Completes Its Rust Coreutils

Ubuntu 26.10 has completed its transition from GNU Coreutils to Rust-based replacements, according to OMG! Ubuntu. Users will still type commands inherited from the Unix era. The code answering those commands has changed.

The latest additions include cp, mv, and rm, joining previously converted utilities such as ls, cat, chmod, and du, Slashdot reports. The replacements come from uutils, a project reimplementing familiar command-line tools in Rust while seeking compatibility with established behavior.

It's FOSS describes the change as a milestone in Ubuntu's broader Rustification. That label makes the work sound like a montage in which programmers hammer out safer code while an inspirational synthesizer plays. Distribution engineering is usually closer to checking 400 interpretations of a file permission flag and discovering that a backup script from 2009 depends on interpretation 401.

A Rewrite Users Are Supposed to Ignore

The unusual feature of this migration is how little users should notice when it works.

A new desktop, package format, or display system presents visible changes. Core utilities form a stable command-line vocabulary. People and programs expect cp to copy, mv to move, rm to remove, and ls to produce output that other tools can consume. Decades of shell scripts, deployment systems, installers, recovery procedures, and administration habits rest on those expectations.

Uutils therefore faces two jobs. It must implement the useful operation, and it must reproduce the accumulated behavior surrounding that operation. The second job can dwarf the first.

Consider cp. Copying bytes sounds simple until the request involves symbolic links, recursive directory trees, ownership, timestamps, permissions, sparse files, existing destinations, interrupted operations, or conflicting command-line options. rm must navigate similarly old assumptions around recursion, write-protected files, prompts, missing paths, and error handling. A utility can perform its headline function correctly while still breaking a script through a different exit code or message on standard error.

Shell scripting has spent roughly half a century turning documented features, GNU extensions, and assorted accidents into one large de facto contract. Like a universal remote from 1997, every button probably exists because somebody, somewhere, still uses it.

Why Rust Appeals at This Layer

Rust's strongest argument is straightforward. Its ownership and borrowing rules allow the compiler to prevent broad classes of memory-management errors before software ships. Use-after-free flaws, invalid references, and many data races become harder to introduce in safe Rust.

That promise carries extra weight in foundational software. Core utilities run everywhere across a Linux system and often process paths, metadata, and input supplied by other programs. Even small utilities can sit inside privileged maintenance jobs or automated services. Reducing exposure to memory corruption can improve the security baseline across a large installation.

Rust also gives maintainers modern tooling and language constructs for expressing errors and resource ownership. Advocates see a chance to retire some recurring C hazards rather than asking reviewers and tests to catch every one forever. The compiler becomes another layer of enforcement, one that neither gets tired nor approves a patch five minutes before lunch.

The compiler cannot decide whether a replacement matches GNU behavior. It cannot determine that an obscure option combination should emit a certain diagnostic, preserve a timestamp under certain permissions, or return the exit status expected by an old script. Semantic errors sit outside Rust's ownership checker. Logic bugs, incomplete compatibility, and poor performance remain available in every programming language, rather like meetings.

Memory safety also depends on how code and dependencies use Rust. The language permits unsafe blocks when low-level operations require them. That mechanism does not cancel Rust's safety model, although it means audits still have work to do.

Compatibility is the Product

For Ubuntu, the migration's practical standard will emerge from user workloads and bug reports. Passing a project's tests establishes a baseline. A general-purpose Linux distribution supplies a much larger and stranger test suite, including scripts whose authors vanished three employers ago.

Compatibility covers several layers:

Command-line flags and GNU-specific extensions
Exit status under both successful and failed operations
Output formatting consumed by scripts
Error wording, localization, and the choice of standard output or standard error
File permissions, ownership, timestamps, and links
Behavior across filesystems and unusual path names
Performance for large operations and for tiny commands invoked thousands of times

Some scripts parse human-readable output despite years of advice against it. Others rely on ordering or diagnostics that no standard promised. Maintainers still have to decide whether preserving such behavior serves compatibility or fossilizes an old accident.

GNU Coreutils brings decades of deployment and accumulated fixes. Uutils brings Rust's safety properties and an opportunity to reconsider implementation choices. Ubuntu's decision places those two forms of engineering value into direct contact: maturity earned through time and safety enforced through language design.

The available reports establish the completion milestone, but they provide little public evidence about comparative benchmark results, unresolved compatibility counts, or failure rates from broad Ubuntu usage. Claims of success should therefore stay tied to the scope demonstrated so far. The release cycle and subsequent maintenance will produce the useful evidence.

What “Complete” Means in a Distribution

In release engineering, “complete” usually marks completion of a defined migration scope. It does not freeze either codebase or guarantee identical behavior across every input assembled since Ken Thompson had sideburns.

Ubuntu still has to package the utilities, integrate them with the rest of the operating system, respond to regressions, and decide when compatibility bugs warrant updates. Uutils maintainers face reports that may reproduce only on a certain filesystem, architecture, locale, or permission arrangement. GNU Coreutils will also continue to evolve, creating a moving target where Ubuntu wants to preserve GNU-compatible behavior.

Toolchain questions belong in the assessment too. Adopting Rust can affect build infrastructure, dependency management, bootstrap procedures, architecture support, and maintainer skills. Those costs do not erase the security benefits. They do influence whether the migration remains sustainable across future releases rather than becoming an impressive conversion followed by an awkward maintenance hangover.

The burden also falls unevenly. Most desktop users may never know which implementation handles ls. System administrators, package maintainers, container builders, and developers running test suites will encounter differences first. Their reports will reveal whether Ubuntu has found obscure incompatibilities before organizations move the release into production.

Oxidation Meets Unix Sediment

Ubuntu's move fits a broader pattern often called oxidation: rewriting or adding systems components in Rust to reduce memory-safety risk. The metaphor works because oxidation sounds energetic and scientific, while also describing what happened to the wheel arches on a 1988 Ford Escort.

The sensible case for oxidation does not require replacing every mature C program on sight. Rewrites introduce their own risks, especially when they target software with decades of undocumented behavior. A staged migration can capture Rust's benefits while giving maintainers room to measure compatibility and reverse decisions when necessary.

Ubuntu has now made that experiment visible at one of Linux's most heavily used layers. The milestone says the planned substitutions have arrived. The next evidence will come from package builds, shell scripts, recovery sessions, performance measurements, and bug trackers.

If the migration succeeds, cp, mv, and rm will remain boring. For core utilities, boredom is about as close as software engineering gets to a standing ovation.