Version 0.11.0 implements every utility, with compatibility gaps
Version 0.11.0 arrived on August 31, 2026, and the README says every GNU Coreutils program has an implementation. That does not make uutils an identical replacement. Some options can still be absent and some behavior can differ, with those differences tracked as bugs. The distinction is important because these commands sit underneath installers, shell scripts, and operating-system jobs where a changed error code or a slightly different date string can become an application failure.
The project still has a clear reason to exist beyond language preference. One Rust codebase targets Linux, macOS, BSD, Windows, and WASI, and uutils has shipped by default in Ubuntu since version 25.10. At commit 48a2013, the common build produced a BusyBox-style multicall program on supported platforms, while individual utility crates could be built separately. That flexibility suits distributions and cross-platform developer tools better than assuming every target already has the GNU suite.
The 13.6 MB checkout expands into a substantial Rust build
Our checkout contained 1,891 files, about 273,458 source lines, and occupied 13.6 MB before dependencies. Installation then pulled 384 packages. The source tree is large because each familiar command has its own parsing, filesystem behavior, error handling, platform branches, and tests. It is still navigable: utilities live in separate crates and share lower-level code through uucore, so a contributor working on tail does not need to treat the repository as one giant executable.
The measured build took 102 seconds after a 17-second install in our 3-CPU, 12 GB container. That is reasonable for an occasional source build, but it is heavier than dropping a prebuilt utility bundle into an image. uutils publishes stable artifacts and main-branch binaries, with musl variants for systems that cannot use the glibc build. The repository itself has no Dockerfile, so container users must choose their Rust base and caching strategy.
What happened when we ran it
Our sandbox installed 384 packages in 17 seconds, then built commit 48a2013 successfully in 102 seconds. cargo test completed in 153 seconds with 10,276 passed and 0 failed out of 10,276. The run used 3 CPUs, 12 GB of RAM, the lab-rust:1 image, and an unprivileged fresh Debian container with no secrets. No step failed, and the supplied results contain no warning that changes that outcome.
The same checkout had 22 CI workflow files and a tests directory, but no Dockerfile. Its 1,891 files and roughly 273,458 source lines make the clean result more persuasive than a token smoke test. It remains a Rust-suite result for one commit, not proof that every utility matches every GNU release and locale. Our run did not report command-by-command compatibility, shell-script behavior, performance, or a vulnerability scan, so we do not claim any of those outcomes.
The 384-package build can produce one binary or selected commands
Our install pulled 384 packages before the default Cargo command produced a portable common set as one multicall binary. Feature flags expand it for Unix or Windows, and another documented target covers WASI. Packagers can build all utility crates as individual binaries or select packages such as uu_cat and uu_rm. GNU Make adds install prefixes, exclusion lists, manuals, and shell completion files. A plain cargo install --path . --locked is simpler, but the README explicitly says it omits manpages and completions.
Special features add system choices beyond the 102-second default build we measured. SELinux support for chcon and runcon needs libselinux and libclang. The optional OpenSSL path can accelerate checksum commands and normally builds its library from source, while an environment setting switches to dynamic system libraries. Release-small mode favors binary size. These switches are useful because a distribution and a developer workstation want different outputs, though they also mean one passing default configuration does not validate every package variant.
Passing 10,276 Rust tests does not prove GNU parity
All 10,276 tests in our run passed, yet the project itself says output and exit-code differences from GNU are bugs still being found. Issue 14351 gives a concrete example: combinations of case flags in date format specifiers produced different text from GNU. The report compared specific formats and locales, which is exactly the kind of edge a generic application suite may never exercise until a shell script depends on it.
Other September reports cover a tail overflow at an extreme byte count and an ls panic with a short LS_COLORS style in overflow-checking builds. They were opened after the 48a2013 snapshot, so they should not be retrofitted into our clean 153-second result. They do narrow the adoption advice. Test your own command lines against GNU, especially locale handling, unusual numeric boundaries, permissions, and machine-read output, before replacing a base-system package.
A fresh release and daily fixes show an active project
GitHub recorded 24,032 stars, 1,157 open issues and pull requests, and a last push on September 2, 2026. Release 0.11.0 appeared two days earlier. The combined open count is not a count of bugs: the current queue includes implementation pull requests, performance work, and compatibility reports. A same-day fix for one build-profile question and ongoing work across ls, tail, and date show maintainers are processing detailed reports rather than merely collecting them.
The health evidence matches our clean commit 48a2013 run: 22 workflow files, 10,276 passing tests, and active changes around GNU behavior. uutils is mature enough to ship in an operating system and honest enough to state that parity remains unfinished. That makes it a good engineering choice when portability or Rust ownership pays for the migration testing. For a script fleet already stable on GNU Coreutils, replacing the foundation without a command-level comparison buys risk with little immediate return.