A proposed port of the Rust-based uutils coreutils reimplementation sparked heated debate on the OpenBSD mailing list, with project founder Theo de Raadt and senior developers rejecting it as unnecessary duplication that introduces behavioral incompatibilities with the base system.
A proposal to add the uutils coreutils reimplementation to the OpenBSD ports tree drew sharp criticism from senior developers this week, exposing tensions around Rust adoption, licensing philosophy, and the project's commitment to behavioral consistency across its base system utilities.
David Uhden Collado submitted the sysutils/uutils port on September 20, packaging the Rust-based reimplementations of GNU coreutils as drop-in alternatives. The port installs g-prefixed command names—gcat, gls, gcp, gdate, gsort, gstat, gtail, gtimeout, and others—as symlinks to a multicall binary under libexec/uutils. Each package conflicts with its corresponding GNU implementation and declares the GNU port as a secondary @pkgpath.
The response was immediate and dismissive.
Stuart Henderson, a long-time OpenBSD developer, opened with skepticism: "I don't think this is a usable approach for ports." He acknowledged Ubuntu 26.10's adoption of uutils coreutils but characterized the other reimplementations as works in progress.
Theo de Raadt, OpenBSD's founder, was far more direct. "Smells like agenda," he wrote, before dismantling the licensing argument. "I also think they fit quite well with OpenBSD as alternatives to GNU utilities, particularly because they use a permissive MIT license. Argument is vaguely like: because we already have permissive licenced utilities, our user base are really interested in having a second set of permissive licenced utilities which are very subtly different. That makes no sense."
OpenBSD's base system already ships with permissively licensed (BSD-licensed) implementations of standard utilities. The project has spent decades ensuring these tools behave predictably and consistently with each other. Introducing a second set of tools with "subtly different" behavior, de Raadt argued, creates real problems for users who pipe output between utilities.
"Noone wants subtly different behaving binaries as part of their workflow," de Raadt continued. "If someone runs the openbsd ls command as part of a pipeline that uses openbsd sed, or openbsd cut, or some other openbsd utility and it parses a non-standardized output characteristic by accident, there are no people in this universe who wants to replace that ls with a different ls and get surprised by un-standardized tooling behaviour clash."
This cuts to a core OpenBSD principle: the base system is a cohesive whole. Utilities are developed and tested together. Swapping individual components for reimplementations—even compatible ones—risks breaking scripts and pipelines that depend on specific output formats, exit codes, or edge-case behaviors.
When Collado noted uncertainty about installing individual utilities as separate binaries, citing uutils' metapackage structure and Rust implementation, de Raadt seized on the language: "Oh, because it is written in Rust. Your agenda is showing."
The Rust question has surfaced repeatedly in BSD communities. FreeBSD has experimented with Rust in the base system. OpenBSD has not, citing the language's rapid release cycle, large dependency chains, and the difficulty of bootstrapping a Rust toolchain on the architectures OpenBSD supports. The project maintains its own C compiler toolchain and has historically avoided adding new language runtimes to the base installation.
Henderson's reference to Ubuntu's adoption carried an implicit caveat: Ubuntu 26.10 hasn't been released yet (as of this writing), and Canonical's willingness to ship newer software doesn't map to OpenBSD's conservative release cycle. OpenBSD 7.6 shipped in October 2024; 7.7 is expected in April 2025. The project prioritizes stability over novelty.
Beyond maturity, the port structure itself raised concerns. The uutils project distributes a single multicall binary—one executable that dispatches to different utilities based on argv[0]. This design, borrowed from BusyBox, conflicts with OpenBSD's packaging conventions, which expect individual binaries. The metapackage approach also means updating one utility requires rebuilding and redistributing the entire suite.
The uutils project, hosted at github.com/uutils/coreutils, has made significant progress. As of 2024, it passes the majority of GNU coreutils test suites and has been adopted by several Linux distributions for specific use cases. The MIT license appeals to projects wanting to avoid GPL-licensed code.
But OpenBSD's rejection illustrates a fundamental divergence in philosophy. Linux distributions often treat utilities as interchangeable components. OpenBSD treats them as a curated, integrated system. The project's ls(1) isn't just "an ls implementation"—it's the ls that find(1), tar(1), and shell scripts have been tested against for years.
The port remains in the proposal stage. Given the opposition from both the project founder and senior ports developers, acceptance seems unlikely without substantial changes—perhaps splitting the multicall binary into individual utilities, demonstrating behavioral parity with OpenBSD's base tools, and addressing the bootstrapping concerns around Rust.
For now, OpenBSD users who want GNU-compatible utilities will continue using the existing sysutils/coreutils port, which packages the actual GNU implementations. The uutils experiment, at least on OpenBSD, appears to have hit a philosophical wall.
Source: OpenBSD ports mailing list, September 20, 2026