uutils/coreutils is easy to misread as a simple "rewrite it in Rust" story. The repository describes a cross-platform reimplementation of GNU coreutils, and the project documentation frames uutils as universal command-line utilities for Linux, Windows, macOS, and other platforms.[3][4] That description is accurate, but it is not the most useful way to watch the FOSDEM 2026 talk "Rust Coreutils in Ubuntu: One Troll, One Argument, One Answer." The stronger reading is that uutils/coreutils is a public audit of Unix command behavior, with Rust as the implementation language and compatibility as the real product.[1][2][3]
Coreutils are not glamorous infrastructure. They are cat, cp, date, ls, mv, rm, sort, stat, tail, and dozens of other commands that scripts treat as background physics. The GNU manual documents version 9.11 of the GNU core utilities and shows how broad that surface is: file output, directory listing, basic file operations, permissions, timestamps, process control, numeric operations, and more.[5] When Ubuntu experiments with replacing that surface, the risky question is not whether Rust can compile a fast binary. It is whether shell scripts, package builds, maintenance jobs, and human muscle memory depend on behaviors that nobody remembered to name.[2][5][6]
Watch the first move: compatibility before ideology
The first useful note to make while watching is that the talk is not really an argument that old C code is bad and new Rust code is automatically good. The FOSDEM page frames the session around what happened when Ubuntu tried to bring Rust Coreutils into a distribution: obscure behaviors, Essential package risk, benchmark claims, and tooling that lets maintainers flip between GNU and Rust implementations.[2] That framing matters because coreutils replacement cannot be sold on taste. It has to survive contact with the archive, with users' scripts, and with the boring commands that run before anyone has a chance to open a debugger.
The uutils README makes the same constraint explicit in project terms. Its goals include matching GNU output and exit codes, treating differences as bugs, improving error messages, supporting UTF-8, improving performance, and running across many platforms.[3] For a viewer, the key phrase is "differences as bugs." That turns the project from a greenfield clone into a behavioral ledger. Every missing flag, odd diagnostic, surprising timestamp format, locale edge case, or filesystem race becomes a compatibility finding rather than a philosophical disagreement.[3][5]
That is why this is a good Annotated Viewing subject for OSS. The talk sits at the junction between upstream ambition and downstream accountability. uutils can move quickly as an open-source project, but Ubuntu has to ask whether the output is safe enough for a default operating-system role.[2][6] The video is most valuable when watched as a distribution engineering case study, not as a programming language debate.
The middle is about all the contracts nobody signed
In the middle of the viewing, pay attention to the practical examples implied by the FOSDEM abstract: scripts that depend on weird flags, packages that assume a particular command behavior, and benchmarks that matter only after correctness is close enough.[2] None of those are API contracts in the library sense. There is no neat semantic-versioned interface for "what every build script expects from date." Yet the contract is real because the ecosystem executes it constantly.
The GNU manual helps explain why this is hard. It is not just a short list of POSIX basics. It documents common options, command-specific behavior, standards conformance, and even a coreutils multi-call invocation form that portable scripts are warned not to rely on by default.[5] That mixture of standard behavior, GNU extension, historical habit, and portability warning is exactly the territory uutils has to traverse. A replacement can be more memory safe and still be operationally wrong if it misses a tiny behavior that a package maintainer, CI job, or installer quietly depends on.[3][5][6]
Ubuntu's April 2026 update makes this concrete. It describes a security review process, an external audit, upstream coordination, and a partial default in Ubuntu 26.04 where cp, mv, and rm stayed with GNU coreutils because remaining time-of-check to time-of-use concerns were still open as of April 22, 2026.[6] That is the sober lesson: modernization is not a flag day. It is a sequence of reviewed substitutions, with the most security-sensitive and filesystem-sensitive utilities getting special scrutiny.[6]
The audit changes what "done" means
For a smaller command-line utility, "done" can mean implemented, documented, released, and packaged. For uutils/coreutils, "done" has to mean something harsher. The command may need to match stdout, stderr, exit status, option parsing, error wording, locale behavior, filesystem semantics, and build-system expectations well enough that users notice the absence of breakage.[3][5] That is not a glamorous metric, but it is the metric that matters.
The project documentation gives a compact version of the ambition: universal command-line utilities in Rust, available across major platforms, with generated user and developer documentation.[4] The GitHub README adds the drop-in replacement goal and notes that all programs have been implemented while some options or behaviors may still differ.[3] Read together with the Ubuntu update, those statements make the project feel less like a completed rewrite and more like a large compatibility campaign that has entered real deployment.[3][4][6]
This is also where the talk's title becomes useful. "One Troll, One Argument, One Answer" gestures at the noise around Rust transitions, but the serious answer is process. You answer compatibility anxiety with tests, audits, real package builds, issue tracking, upstream fixes, and a fallback path. You answer performance anxiety after correctness is measurable. You answer security claims by separating language-level memory safety from command-specific race conditions, permissions behavior, and filesystem edge cases.[2][6]
What to take from the final stretch
By the end, the viewer should be less interested in whether uutils "wins" against GNU coreutils as a slogan. The more useful question is what the replacement attempt reveals about the existing system. It reveals that everyday commands are infrastructure APIs. It reveals that a distribution's default userland is not merely a package choice but a contract with every script and package that assumes those commands behave in a particular way. It also reveals that open-source modernization succeeds when upstream and downstream turn vague trust into specific tests, audits, and release gates.[2][3][5][6]
uutils/coreutils matters because it makes that invisible contract visible. The project may be written in Rust, but its main engineering artifact is not just Rust code. It is the growing map of what compatibility actually requires. That makes the FOSDEM talk worth watching even for people who do not have a strong opinion about Rust. It is a case study in replacing foundational software without pretending that "same command name" means "same system behavior."[1][2][3][6]
Sources
- FOSDEM, "Rust Coreutils in Ubuntu: One Troll, One Argument, One Answer," YouTube video.
- FOSDEM 2026, "Rust Coreutils in Ubuntu: Yes, we rewrote /bin/true in Rust - Here's what really happened," event page and recording links.
- uutils/coreutils, GitHub repository README.
- uutils Coreutils Documentation, "Introduction."
- GNU Project, "GNU Coreutils 9.11" manual.
- Ubuntu Community Hub, "An update on rust-coreutils," April 22, 2026.
- Benjamin Bellamy, "Fosdem 2026 - 15.jpg," Wikimedia Commons photograph.