By late 2024, however, Rust enthusiasts were frustrated with stalls and blocks on their efforts, with the Rust for Linux lead quitting over “nontechnical nonsense.” Torvalds said at the time that he understood it was slow, but that “old-time kernel developers are used to C” and “not exactly excited about having to learn a new language.” Still, this could be considered a normal amount of open source debate.
But over the last two months, things in one section of the Linux Kernel Mailing List have gotten tense and may now be heading toward resolution—albeit one that Torvalds does not think “needs to be all that black-and-white.” Greg Kroah-Hartman, another long-time leader, largely agrees: Rust can and should enter the kernel, but nobody will be forced to deal with it if they want to keep working on more than 20 years of C code.
Previously, on Rust of Our Lives
Earlier this month, Hector Martin, the lead of the Asahi Linux project, resigned from the list of Linux maintainers while also departing the Asahi project, citing burnout and frustration with roadblocks to implementing Rust in the kernel. Rust, Martin maintained, was essential to doing the kind of driver work necessary to crafting efficient and secure drivers for Apple’s newest chipsets. Christoph Hellwig, maintainer of the Direct Memory Access (DMA) API, was opposed to Rust code in his section on the grounds that a cross-language codebase was painful to maintain.
Torvalds, considered the “benevolent dictator for life” of the Linux kernel he launched in 1991, at first critiqued Martin for taking his issues to social media and not being tolerant enough of the kernel process. “How about you accept that maybe the problem is you,” Torvalds wrote.
Working at the intersection of Apple’s newest hardware and Linux kernel development, for the benefit of a free distribution, was never going to be easy. But it’s been an especially hard couple of weeks for Hector Martin, project lead for Asahi Linux, capping off years of what he describes as burnout, user entitlement, and political battles within the Linux kernel community about Rust code.
In a post on his site, “Resigning as Asahi Linux project lead,” Martin summarizes his history with hardware hacking projects, including his time with the Wii homebrew scene (Team Twiizers/fail0verflow), which had its share of insistent users desperate to play pirated games. Martin shifted his focus, and when Apple unveiled its own silicon with the M1 series, Martin writes, “I realized that making it run Linux was my dream project.” This time, there was no jailbreaking and a relatively open, if tricky, platform.
Support and donations came quickly. The first two years saw rapid advancement of a platform built “from scratch, with zero vendor support or documentation.” Upstreaming code to the Linux kernel, across “practically every Linux subsystem,” was an “incredibly frustrating experience” (emphasis Martin’s).
Then came the users demanding to know when Thunderbolt, monitors over USB-C, M3/M4 support, and even CPU temperature checking would appear. Donations and pledges slowly decreased while demands increased. “It seemed the more things we accomplished, the less support we had,” Martin writes.
Martin cites personal complications, along with stalking and harassment, as slowing down work through 2024, while Vulkan drivers and an emulation stack still shipped. Simultaneously, issues with pushing Rust code into the Linux kernel were brewing. Rust was “the entire reason our GPU driver was able to succeed in the time it did,” Martin writes. Citing the Nova driver for Nvidia GPUs as an example, Martin writes that “More modern programming languages are better suited to writing drivers for more modern hardware with more complexity and novel challenges, unsurprisingly.”
Enlarge/ Rust never sleeps. But Rust, the programming language, can be held at bay if enough kernel programmers aren’t interested in seeing it implemented.
Getty Images
The Linux kernel is not a place to work if you’re not ready for some, shall we say, spirited argument. Still, one key developer in the project to expand Rust’s place inside the largely C-based kernel feels the “nontechnical nonsense” is too much, so he’s retiring.
Wedson Almeida Filho, a leader in the Rust for Linux project, wrote to the Linux kernel mailing list last week to remove himself as the project’s maintainer. “After almost 4 years, I find myself lacking the energy and enthusiasm I once had to respond to some of the nontechnical nonsense, so it’s best to leave it up to those who still have it in them,” Filho wrote. While thanking his teammates, he noted that he believed the future of kernels “is with memory-safe languages,” such as Rust. “I am no visionary but if Linux doesn’t internalize this, I’m afraid some other kernel will do to it what it did to Unix,” Filho wrote.
Filho also left a “sample for context,” a link to a moment during a Linux conference talk in which an off-camera voice, identified by Filho in a Register interview as kernel maintainer Ted Ts’o, emphatically interjects: “Here’s the thing: you’re not going to force all of us to learn Rust.” In the context of Filho’s request that Linux’s file system implement Rust bindings, Ts’o says that while he knows he must fix all the C code for any change he makes, he cannot or will not fix the Rust bindings that may be affected.
“They just want to keep their C code”
Asahi Lina, developer on the Asahi Linux project, posted on Mastodon late last week: “I regretfully completely understand Wedson’s frustrations.” Noting that “a subset of C kernel developers just seem determined to make the lives of Rust maintainers as difficult as possible,” Lina detailed the memory safety issues they ran into writing Direct Rendering Manager (DRM) scheduler abstractions. Lina tried to push small fixes that would make the C code “more robust and the lifetime requirements sensible,” but was blocked by the maintainer. Bugs in that DRM scheduler’s C code are the only causes of kernel panics in Lina’s Apple GPU driver, she wrote—”Because I wrote it in Rust.”
“But I get the feeling that some Linux kernel maintainers just don’t care about future code quality, or about stability or security any more,” Lina wrote. “They just want to keep their C code and wish us Rust folks would go away. And that’s really sad… and isn’t helping make Linux better.”
Drew DeVault, founder of SourceHut, blogged about Rust’s attempts to find a place inside the Kernel. In theory the kernel should welcome enthusiastic input from motivated newcomers. “In practice, the Linux community is the wild wild west, and sweeping changes are infamously difficult to achieve consensus on, and this is by far the broadest sweeping change ever proposed for the project,” DeVault writes. “Every subsystem is a private fiefdom, subject to the whims of each one of Linux’s 1,700+ maintainers, almost all of whom have a dog in this race. It’s herding cats: introducing Rust effectively is one part coding work and ninety-nine parts political work – and it’s a lot of coding work.”
Rather than test their patience with the kernel’s politics, DeVault suggests Rust developers build a Linux-compatible kernel from scratch. “Freeing yourselves of the [Linux Kernel Mailing List] political battles would probably be a big win for the ambitions of bringing Rust into kernel space,” DeVault writes.
Torvalds understands why Rust uptake is slow
You might be wondering what lead maintainer Linus Torvalds thinks about all this. He took a “wait and see” approach in 2021, hoping Rust would first make itself known in relatively isolated device drivers. At an appearance late last month, Torvalds… essentially agreed with the Rust-minded developer complaints, albeit from a much greater remove.
“I was expecting [Rust] updates to be faster, but part of the problem is that old-time kernel developers are used to C and don’t know Rust,” Torvalds said. “They’re not exactly excited about having to learn a new language that is, in some respects, very different. So there’s been some pushback on Rust.” Torvalds added, however, that “another reason has been the Rust infrastructure itself has not been super stable.”
The Linux kernel is a high-stakes project in which hundreds or thousands of developers have a stake; conflict is perhaps inevitable. Time will tell how long C will remain the primary way of coding for, and thinking about, such a large yet always-moving, codebase.
Ars has reached out to both Filho and Ts’o for comment and will update this post with response.
Enlarge/ A little auto-tiling on the Cosmic desktop.
System76
System76 has released an alpha version of its Cosmic desktop environment for Linux and Unix-like systems. The Linux hardware firm isn’t targeting only its customers with its GNOME replacement; it also hopes to get distro maintainers and app makers on board with its Rust-built, UX-focused desktop.
While the Cosmic desktop will be built into the Linux vendor’s Pop!_OS (which is also in the alpha ISO), it’s also available to other systems, as you might expect. System76 provides drop-in instructions for Fedora and Arch Linux installs, among others.
System76 says it is “excited to see COSMIC integration elevate Linux as a whole,” along with what results “from making UX-building more accessible.” By building Cosmic natively in the Rust language, System76 also intends to provide a more stable and memory-safe environment for apps.
Cosmic shows deep attention to tiling, keyboard shortcuts, and panel and dock customization, as has been present on its Pop!_OS. I’m a bit of a boring side-by-side, single-workspace type; Gardiner Bryant on YouTube went deeper into the Cosmic alpha’s tiling, panels, and GTK app acceptance. I found that getting Cosmic into a reasonable shape I could work from, and picking up its keyboard window shortcuts, was easier than with either KDE or GNOME.
One thing System76 made clear in its push for Cosmic is its readiness for more deeply integrated themes. System76 offered a few examples in its press materials, and I must admit a fondness for its over-the-top examples.
System76 probably can’t officially offer this theme, what with Internet Explorer logo and other recognizable icons, but it does illustrate the theme potentials.
System76
Answering the eternal software question “Can it run Doom?” even in desktop environments.
System76
This? This is the subtle side of this very Polish-RPG-influenced theme.
System76
If you’re going to hack the net and fight the corpos, you gotta wake your eyes up, choom.
System76
Promising, but definitely not production
I’ve been using the Cosmic-topped desktop alpha since last week on an also alpha-ish Pop!_OS 24.04 long-term support distribution with Wayland windowing. It’s running on my desktop-ified Framework laptop, since System76 noted that virtual machines would require some hardware acceleration trickery to function properly. It’s definitely an alpha, with lots of things you’d expect to see in the settings and around the system missing or non-interactive.
What I can say about Cosmic, even at this early alpha stage, is that it’s relatively snappy and cohesive compared to other systems I’ve used. The settings app only has six main categories, and one of them is “Desktop,” with robust settings for changing your dock, windows, workspaces, and appearance. I keep a webcam on top of my monitor, with a clamp big enough to hide the time/date combo sometimes perched there by GNOME desktops. Cosmic’s panel controls made it easy to move this to the right and similarly position and style my dock however I like.
Most of what is on display here is not for end users, though, as much as it is for adventurous users, or maybe community distro packagers, looking for a desktop environment carrying far less technical debt than GNOME and KDE. At the same time, that means there will be some tension and scraping between certain apps and this new environment. Slack’s main window on my system is constantly disappearing, and clicking its persistent notification in the tray won’t bring it back. And I’m the type who always remaps his Caps Lock key to Escape, but there’s no place to do that yet, and the Gnome-Tweaks app won’t work, either. Some of this is probably the distribution itself, some of it is Cosmic, and some of it is between the two. (Yes, I’m certain there’s a way to get that keyboard fix with a command or config file, but this is just a test run.)
The Cosmic team says it will next work on settings pages, the Files app, variable refresh rate, and software rendering, among other bugs and refinements. After that comes the hard part of gaining acceptance and installs across the wider open source community.
