Words and Code
Welcome

The Linux universe had a serious discussion a few years ago about how to talk to each other, and it seemed like things were going better, but the recent dust-up between the Rust for Linux (R4L) community and some of the kernel maintainers has left me wondering if more needs to be said.
Dear Reader,
The Linux universe had a serious discussion a few years ago about how to talk to each other, and it seemed like things were going better, but the recent dust-up between the Rust for Linux (R4L) community and some of the kernel maintainers has left me wondering if more needs to be said.
At the core of the argument is the fact that the community is contending with two wholly incompatible truths. On one hand, the world would be better off if programming were done in memory-safe languages. On the other hand, retooling a huge project like the Linux kernel to support development in multiple languages is a massive undertaking that could add chaos and, some would argue, is not worth the risk and trouble despite the potential benefits.
Keep in mind that kernel maintainers and kernel contributors are often overworked, underappreciated, and subject to abuse from cranky end users who think they can talk to a volunteer the way you talk to a paid attendant at the complaints desk. In that sense, one can hardly blame the volunteers for venting, but it is important for those around them to keep pointing out that inflammatory language really doesn't help. In an effort to minimize further trolling, I won't name names, but I'll describe the situation.
The Rust for Linux project was announced to the Linux Kernel Mailing List in 2020, and since then, the initiative to integrate Rust as a potential development language has gained the official support of the Linux leadership. In that context, members of the Rust for Linux community were dismayed when a maintainer rejected a patch that would allow Rust drivers to use the DMA API for allocating and mapping memory regions. In the ensuing discussion, the maintainer wrote, "Don't force me to deal with your shiny language of the day. Maintaining multi-language projects is a pain I have no interest in dealing with …"
The Rust for Linux folks explained that they would maintain their own abstraction layer to the C API, and the C side of the kernel would not change, but the maintainer wasn't persuaded, adding, "If you want to make Linux impossible to maintain due to a cross-language codebase, do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-language codebase and not Rust itself, just to escape the flameware brigade)."
The first question is whether it actually improves the communication to call Rust "your shiny language of the day." The people working on Rust for Linux invest a lot of time and effort into it, and if you imply that they are doing what they are doing for some frivolous, fad-conscious reason, you almost guarantee they will stop listening. The next question is whether it really helps to say "If you want to make Linux impossible to maintain." Of course, no one wants to make Linux impossible to maintain. Is there any reason for suggesting it? As for the part about "spreading this cancer to core subsystems," when you call someone else's ideas "cancer," you are basically announcing that this will be a war and not a tech session.
Things escalated from there. Another leader of a prominent community suggested that Rust for Linux developers submit the patch directly to Linus (which is outside of the normal process), stating that, "If Linus pulls it, what [the maintainer] says doesn't matter. If Linus doesn't pull it, the R4L project is essentially dead until either Linus or the maintainer make a move."
He then added, "Rust folks: Please don't waste your time and mental cycles on drama like this. It's not worth your time. Either Linus likes it, or he doesn't. Everything else is distractions orchestrated by a subset of saboteur maintainers who are trying to demoralize you until you give up …"
All this was just more churning. First of all, as any couples counselor will tell you, calling someone else's complaint "drama" is a sure way to get them to shut down and stop communicating. Starting a paragraph with "Please don't waste your time" has a similar effect. Also, calling someone who is trying to stop your progress a "saboteur" might be tempting, but it just stirs up more invective. Other voices jumped in at that point, with one commentator stating, "Being toxic on the right side of an argument is still toxic," which was the truest thing said over the whole thread.
In the end, at least one important developer resigned, several more were undoubtedly more burned out than ever, and there appeared to be no progress with the central question that caused all the anger in the first place, which was, is the Linux community truly invested in adding Rust as a development language, and, if so, what is the responsibility of individual maintainers to support or at least tolerate that integration?
Given the complexity of integrating a new language, the Linux community is bound to have disagreements over this issue. Some of that is baked into the process, but seriously, it will all go a lot smoother if everyone will consider their words as carefully as they consider their code.
Joe Casad, Editor in Chief
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

News
-
System76 Releases COSMIC Alpha 7
With scores of bug fixes and a really cool workspaces feature, COSMIC is looking to soon migrate from alpha to beta.
-
OpenMandriva Lx 6.0 Available for Installation
The latest release of OpenMandriva has arrived with a new kernel, an updated Plasma desktop, and a server edition.
-
TrueNAS 25.04 Arrives with Thousands of Changes
One of the most popular Linux-based NAS solutions has rolled out the latest edition, based on Ubuntu 25.04.
-
Fedora 42 Available with Two New Spins
The latest release from the Fedora Project includes the usual updates, a new kernel, an official KDE Plasma spin, and a new System76 spin.
-
So Long, ArcoLinux
The ArcoLinux distribution is the latest Linux distribution to shut down.
-
What Open Source Pros Look for in a Job Role
Learn what professionals in technical and non-technical roles say is most important when seeking a new position.
-
Asahi Linux Runs into Issues with M4 Support
Due to Apple Silicon changes, the Asahi Linux project is at odds with adding support for the M4 chips.
-
Plasma 6.3.4 Now Available
Although not a major release, Plasma 6.3.4 does fix some bugs and offer a subtle change for the Plasma sidebar.
-
Linux Kernel 6.15 First Release Candidate Now Available
Linux Torvalds has announced that the release candidate for the final release of the Linux 6.15 series is now available.
-
Akamai Will Host kernel.org
The organization dedicated to cloud-based solutions has agreed to host kernel.org to deliver long-term stability for the development team.