Somewhere in the sprawling machinery of every Linux system sits a collection of command-line tools so fundamental they’re almost invisible. ls, cp, cat, sort, chmod — the GNU Coreutils. They’ve been written in C for decades, battle-tested across billions of installations. And now, a growing team of open-source contributors is methodically rebuilding them from scratch in Rust.
The project just shipped version 0.0.29, a release that pushes Rust-based Coreutils past a significant threshold. According to Phoronix, the project now passes roughly 80% of the GNU Coreutils test suite — a benchmark that, for a rewrite effort of this scope, represents years of painstaking compatibility work. The project refers to this as the “Coreutils 0.8” milestone internally, reflecting its progress toward full GNU parity.
That number matters more than it might seem at first glance.
GNU Coreutils isn’t a single program. It’s more than 100 individual utilities, each with its own flags, edge cases, and decades of accumulated behavior that scripts and systems depend on. Replicating all of that — not just the documented behavior but the undocumented quirks that real-world software relies on — is an enormous undertaking. Getting to 80% test compatibility means the Rust versions of these tools can now handle the vast majority of common operations identically to their C counterparts.
Why Rust, and Why Now
The motivation behind uutils/coreutils, as the project is formally known on GitHub, isn’t academic curiosity. It’s memory safety. The GNU Coreutils codebase is written in C, a language that gives programmers direct control over memory allocation and deallocation. That power comes with risk. Buffer overflows, use-after-free bugs, null pointer dereferences — entire categories of vulnerabilities that have plagued C codebases for decades.
Rust eliminates most of these by design. Its ownership model and borrow checker enforce memory safety at compile time, without the performance overhead of garbage collection. For system-level utilities that run with elevated privileges on virtually every Linux machine in existence, that’s not a theoretical benefit. It’s a concrete security improvement.
The broader industry trend is unmistakable. The Linux kernel itself began accepting Rust code in 2022. Google has invested heavily in Rust for Android. Microsoft has been rewriting core Windows components in Rust. The White House Office of the National Cyber Director published a report in early 2024 urging the software industry to adopt memory-safe languages. Coreutils in Rust fits squarely within this movement.
But there’s a difference between writing new software in Rust and rewriting foundational infrastructure that’s been stable for 30 years. The latter requires not just technical skill but an almost obsessive attention to behavioral compatibility. A sort command that handles 99% of inputs correctly but silently mangles the other 1% is worse than useless in production — it’s dangerous.
The uutils project, which has attracted over 500 contributors on GitHub, has been chipping away at this problem since 2013. Progress was slow for years. Then it accelerated.
The 0.0.29 release includes improvements across dozens of utilities. According to the project’s release notes and reporting by Phoronix, significant work went into dd, tail, cp, mv, and ls — some of the most heavily used tools in the collection. Test suite pass rates for individual utilities have climbed substantially, with several now at or near 100% GNU compatibility.
Performance has also been a focus. In some benchmarks, the Rust implementations already match or exceed the speed of their GNU equivalents. For I/O-heavy utilities like cat and cp, the differences are often negligible. For text-processing tools like sort and cut, Rust’s zero-cost abstractions and modern compiler optimizations can sometimes produce faster binaries than hand-tuned C.
Sometimes. Not always. Performance parity across every utility and every workload remains a work in progress.
The Distribution Question
Technical achievement is one thing. Adoption is another. The real question facing Rust Coreutils is whether any major Linux distribution will ship it as the default.
That’s a high bar. Distributions like Ubuntu, Fedora, and Debian have deeply integrated GNU Coreutils into their build systems, package managers, and post-install scripts. Swapping in a different implementation — even one that passes 80% of the test suite — would require extensive validation. The remaining 20% of failing tests likely includes obscure but real behaviors that some package’s build script or some system administrator’s cron job depends on.
There are precedents for this kind of transition, though. Alpine Linux ships BusyBox instead of GNU Coreutils by default. Some embedded Linux distributions use toybox. Android uses a mix of toybox and custom implementations. The idea of non-GNU coreutils isn’t radical. But replacing GNU with Rust on mainstream desktop and server distributions would be unprecedented in scale.
Some distributions have already begun packaging uutils as an optional install. The project is available in the Arch User Repository and through various package managers. Debian has packaged it experimentally. But optional availability and default installation are very different things.
Sylvestre Ledru, a key maintainer of the uutils project who also works at Mozilla, has been vocal about the project’s long-term ambitions. The goal isn’t to be a curiosity or a proof of concept. It’s to be a production-ready, drop-in replacement. The 80% milestone is a waypoint, not a destination.
And the project’s velocity is increasing. Contributions have picked up as Rust’s popularity has grown and as institutional interest in memory-safe rewrites has intensified. The gap between 80% and 95% will likely close faster than the gap between 0% and 80% did, because the remaining failures tend to cluster around specific, identifiable behaviors that can be fixed individually.
The gap between 95% and 100%, though, could take years. Edge cases have a way of multiplying.
For enterprise Linux users and the companies that support them — Red Hat, Canonical, SUSE — the calculus involves weighing the security benefits of Rust against the risk of subtle behavioral differences. In environments where compliance and predictability are paramount, even a 1% incompatibility rate can be disqualifying. But in environments where security is the primary concern — cloud infrastructure, containerized workloads, IoT devices — the tradeoff looks different.
There’s also a philosophical dimension. GNU Coreutils is maintained by the Free Software Foundation and carries the GPL license. The Rust uutils project uses the MIT license, which is more permissive. For some in the open-source community, that distinction matters deeply. For others, it’s irrelevant compared to the technical merits.
What’s undeniable is that the project has reached a level of maturity that demands serious evaluation rather than casual dismissal. Passing 80% of the GNU test suite with a codebase that eliminates entire classes of memory vulnerabilities is a substantial engineering achievement. The contributors behind uutils have proven that a Rust rewrite of foundational Unix tooling isn’t just feasible — it’s happening, methodically and with increasing momentum.
The next major milestone will likely be a distribution brave enough to make Rust Coreutils the default. When that happens — not if — it will mark one of the most significant shifts in the Linux toolchain in decades. Not because the tools will look any different to the user typing commands at a terminal. But because underneath, the code will be fundamentally safer.
And in an era where software supply chain security dominates boardroom conversations and government policy papers alike, “fundamentally safer” is exactly what the industry is demanding.
WebProNews is an iEntry Publication