Please consider subscribing to LWNSubscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net.
Most Linux systems depend on a suite of core utilities that the GNU Project started development on decades ago and are, of course, written in C. At FOSDEM 2025, Sylvestre Ledru made the case in his main stage talk that modern systems require safer, more maintainable tools. Over the past few years, Ledru has led the charge of rewriting the GNU Core Utilities (coreutils) in Rust, as the MIT-licensed uutils project. The goal is to offer what he said are more secure, and more performant drop-in replacements for the tools Linux users depend on. At FOSDEM, Ledru announced that the uutils project is setting its sights even higher.
Ledru has been a Debian developer for more than 20 years, and is a contributor to LLVM/Clang as well as other projects. He is a director at Mozilla, but said that the work he would be talking about is unrelated to his day job.
Bread, woodworking... or Rust?
Ledru said that learning Rust was a project he started during the
COVID lockdown. Some people chose to learn to bake, others took up
woodworking, and he took up rebuilding all the LEGO kits in the house
with his son. But he wanted a project in the evening that would help
him learn Rust. "I have been surrounded by upstream Rust developers
inside the Paris office of Mozilla, so I wanted to learn it
myself
." He didn't want to take on a side project that would
just sit on his hard drive, he wanted to do something with impact.
"So I was thinking, what about reimplementing the coreutils in
Rust?
" Well before COVID, Ledru had worked on rebuilding the
Debian archive using Clang, a project that is documented at clang.debian.net. Ledru said that
he had been inspired by Chris Lattner's work on Clang. One of the core
fundamentals of Clang, he said, is the
philosophy that "if you have different behaviors than GCC, it's a
bug.
"
Next, he asked the audience who knew which programs were in GNU
coreutils. Most people knew at least one, many knew at least
five. But he was pretty sure no one in the audience knew
everything in the list of coreutils, unless they happened to be an
upstream developer on the project. Ledru said that pr, used
to format text for printing "on actual paper
", is one of his
favorite coreutils programs. To start on the project he selected "all
the fancy ones
" like chmod, chown, ls,
and mkdir—the commands that people on Linux and macOS
use almost every day for their work.
Near full completion
Now, five years later, Ledru said that he has more gray hairs, and
the project has Rust replacements for all of the more than 100
commands in coreutils. The project has more than 530
contributors, and more than 18,000 stars on GitHub, "[they're]
meaningless, but it's one of the metrics we have
".
A more meaningful measurement of the project's success is how well
it fares against the GNU coreutils test suite. He said that the
project only passed 139 tests when it started testing in 2021, and it
was now close to 500 out of 617. "I should have worked last
weekend to be at 500, but I didn't have the time
," Ledru
said. (According to the JSON
file of results, it crossed 500 tests passed on
February 4, with 42 skipped and 75 failed.) He
displayed a slide with a graph of test suite runs from April 2021
to late January 2025, shown below.
![[Comparing with GNU's project test suite]](https://static.lwn.net/images/2025/rust-uutils-slide.png "Comparing with GNU's project test suite")
Most of the tests that the project still fails have pull requests
to fix the problems, or may be things that "nobody cares about
"
as well as some "weird ordering
" problems. For example, if a
user tries to use rm in a directory without the appropriate
permissions, the output may be slightly different. "GNU is going to
show something first, and we show it at the end, and it can make a
small difference
".
More and more of the programs are passing all of the GNU tests, but that may not mean the Rust version is fully compatible with the GNU implementation because the test suite itself has some limitations. Ledru said that the project has been contributing to the GNU coreutils project when it finds things that are not tested.
He said that the Rust coreutils are now "production ready
",
and that they support Linux, FreeBSD, NetBSD, OpenBSD, Illumos, Redox,
Android, macOS, and Windows. There are also Wasm versions. According
to Ledru, the Rust coreutils are used by the Debian-based Apertis distribution for
electronic devices, the Spectacles
smartglasses, and Microsoft is using
the project for Visual Studio Code for the web. The Serpent OS distribution is using
them by default, he said. He noted that, since the project is open
source, it is probably in use elsewhere without his knowledge and
asked any company using them to let him know. "I'm always excited
to know when people are using our code
".
Why Rust
Ledru's talk was immediately after Miguel Ojeda's keynote on Rust for Linux. Ledru said that Ojeda had already covered some of the reasons for using Rust, but that he would offer his point of view as well.
As part of the release-management team for Firefox, he was involved
when the browser started shipping with Rust code. That made him
"completely biased
" about the suitability of Rust for the
browser use case. He pointed out that Chrome, the Linux kernel, and
Microsoft Windows are starting to include Rust. "I'm going to
state the obvious, that Rust is very good for security, for
parallelism, for performance
".
The idea to replace GNU coreutils with Rust versions was not about
security, though, because the GNU versions were already quite
secure. "They did an amazing job. They almost don't have any
security issues in their code base.
" And it's not about the
licensing, he said. "I'm not interested in that debate
."
One of the reasons that Ledru liked Rust for this project, he said,
is that it's very portable. He is "almost certain
" that code he
writes in Rust is going to work well on everything from Android to
Windows. That is very surprising, he said, given the complexity of
"everything we do
" but the cost of porting a change to an
operating system is small "thanks to the ecosystem and quality of
Rust
".
Ledru cited laziness as another reason for using Rust. "So if
there is a crate or library doing that work, I'm going to use it. I'm
not going to implement it [myself].
" There are between 200 and 300
dependencies in the uutils project. He said that he understood
there is always a supply-chain-attack risk, "but that's a risk we
are willing to take
". There is more and more tooling around to
help mitigate the risk, he said.
He is thinking about "what we are going to
leave to the next generation
". Developers starting out don't want
to use COBOL, Fortran, or C, he said. They want to work with fancy
stuff like Rust, Swift, Go, or Kotlin. It is a good investment to
start planning for the future now and transition to new languages for
Linux and the computer ecosystem in general.
Demo time
Even though the goal is for the Rust coreutils to be drop-in
replacements, Ledru said, "we take the liberty at times to
differentiate ourselves from the GNU implementation
". Here he
showed a demo of the cp command with a --progress
option that is not available with the standard GNU
version of cp. He said it was available with the
mv command too, and invited the audience to ask if there were
other places the project should add it. "In Rust, it's pretty easy
to add that
".
He also walked through a demo that compared the Rust implementation of sort to GNU's. He used the hyperfine command-line benchmarking tool to run a test ten times; sorting a text file containing all of Shakespeare's works to see which implementation was faster. The first time he performed the test, he used a debug build of the Rust version of sort. In that demo, Rust's version was 1.45x faster than the GNU version. Then he ran the test again using a non-debug version, which showed the Rust version performing the test six times faster than GNU's implementation.
Currently, the project has continuous integration (CI) and build
systems for most of its supported platforms, with almost 88% of the code
covered by a test suite. "If you are above 80, you usually are very
happy. Here we are even happier with nearly 90%
". Despite trying
to demonstrate how the Rust implementation was better than GNU's,
Ledru stressed that there is a friendly collaboration between projects
and that they have been sending bug reports and patches upstream for
GNU coreutils.
What's next
Rewriting more than 100 essential Unix and Linux utilities in a new language is an impressive achievement. Some, upon nearing completion of such a project, might stand back and admire the work and think about calling it a day. Ledru, apparently, is not one of those people.
He displayed a slide with the familiar adage "the best time to
plant a tree is 20 years ago, the second-best time is now
", and
talked a bit about the age of the Unix core utilities. The original
Unix utilities will be 55 years old in four or five months, he
said. Despite their age, the utilities (albeit newer implementations
of them) live on and continue to evolve. Ledru pointed out that the
GNU project continues to add new options to the coreutils and
introduce new algorithms "and we are going to do the same
".
In parallel, Ledru said that the project had started working on
rewrites of GNU
Findutils and GNU
Diffutils. Those have been less of a focus, he said, but people
have been doing great work on implementing those and improving their
performance on the bfs
test suite used to test find. Now, Ledru said, "I'd like
to do the same with most of the essential packages on Debian and
Ubuntu
". There isn't a better time than now to start that
task, he said. What are the essential
packages? He displayed the command he uses to find them:
$ dpkg-query -Wf '${Package;-40}${Essential}\n' | grep yes$
The list includes procps (/proc file system utilities), util-linux (miscellaneous system utilities), acl (access-control-list utilities), bsdutils (standard BSD utilities) and several others.
Ledru then published a blog post from the stage formally announcing the plan to rewrite other parts of the modern Linux stack in Rust. He said that many people were already contributing to the project, and uutils was using the work that has already been done for the coreutils in Rust.
There are many, many functions we have in the coreutils that can be used for other programs as part of that world. So when you need to mount a file system or when you need to look at permissions, we already have all those functions.
He said that the project has a lot of low-hanging fruit and
good first bugs for contributors to get started if they would like to
learn Rust. "It's the way that I learned, and that's why we have so
many contributors
". Projects like rewriting and reinventing the
wheel might sound crazy, he said, but he thought it would work because
there is an appetite from the community.
As I was saying earlier, I'm getting older. We all do, but the new generation is not going to want to do C. And paving the way to do Rust is also a good opportunity for them to be involved in the open-source ecosystem.
The old tools are still using old build pipeline systems, some do not
have CI. They are still using mailing lists to send patches. "I
apologize for the Linux developers here, I still think that using
mailing lists to do a patch review sucks
". With GitLab and GitHub,
he said, there was an opportunity to have a proper pipeline with CI,
quality tools, and so on, which is one of the advantages that uutils has
over the old projects. "To be clear, that works for them, so I'm
happy, but we can do better as a community.
"
Finally, he wanted to mention again that uutils is not a
Mozilla project and has no company behind it, no interest from big
tech. "I'm doing it as a passion because I care about Debian and Linux
in general, it's really a community effort, there is no structure
behind it
". He then opened the floor for questions with a little
bit of time remaining.
Questions
The first question was about portability, and whether Ledru was
tracking the other efforts toward additional Rust compilers to extend uutils coverage. Ledru
said "we will when they are ready
". Another audience member
asked if there were any plans to develop a shell, like Zsh. Ledru said no,
he wanted to replace existing utilities written in C, not to rewrite a
shell, that there was "no need in that space
".
The question that followed was about Ledru's stance on utilities that are written in Rust that are part of the "rewrite in Rust trend" like ripgrep, bat, and others. He said that they are amazing projects, and he uses ripgrep daily, but they are not drop-in replacements.
The final question was about packaging. A member of the audience
observed that it is really hard to package Rust packages due to
dependency management, and wanted to know what Ledru's experience with
that was and how to work around it in future. Ledru agreed that it was
a big deal and that Rust was "quite hard to package
", but he
thought it was going to stabilize.
[I was unable to attend FOSDEM in person, but watched the talk as it live-streamed on Saturday. Many thanks to the video team for their work in live-streaming all FOSDEM sessions.]
| Index entries for this article | |
|---|---|
| Conference | FOSDEM/2025 |