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.”
The open source Wine project—sometimes stylized WINE, for Wine Is Not an Emulator—has become an important tool for companies and individuals who want to make Windows apps and games run on operating systems like Linux or even macOS. The CrossOver software for Mac and Windows, Apple’s Game Porting Toolkit, and the Proton project that powers Valve’s SteamOS and the Steam Deck are all rooted in Wine, and the attention and resources put into the project in recent years have dramatically improved its compatibility and usefulness.
Yesterday, the Wine project announced the stable release of version 10.0, the next major version of the compatibility layer that is not an emulator. The headliner for this release is support for ARM64EC, the application binary interface (ABI) used for Arm apps in Windows 11, but the release notes say that the release contains “over 6,000 individual changes” produced over “a year of development effort.”
ARM64EC allows developers to mix Arm and x86-compatible code—if you’re making an Arm-native version of your app, you can still allow the use of more obscure x86-based plugins or add-ons without having to port everything over at once. Wine 10.0 also supports ARM64X, a different type of application binary file that allows ARM64EC code to be mixed with older, pre-Windows 11 ARM64 code.
Wine’s ARM64EC support does have one limitation that will keep it from working on some prominent Arm Linux distributions, at least by default: the release notes say it “requires the system page size to be 4K, since that is what the Windows ABI specifies.” Several prominent Linux-on-Arm distributions default to a 16K page size because it can improve performance—when page sizes are smaller, you need more of them, and managing a higher number of pages can introduce extra CPU overhead.
Asahi Linux, the Fedora-based distribution that is working to bring Linux to Apple Silicon Macs, uses 16K pages because that’s all Apple’s processors support. Some versions of the Raspberry Pi OS also default to a 16K page size, though it’s possible to switch to 4K for compatibility’s sake. Given that the Raspberry Pi and Asahi Linux are two of the biggest Linux-on-Arm projects going right now, that does at least somewhat limit the appeal of ARM64EC support in Wine. But as we’ve seen with Proton and other successful Wine-based compatibility layers, laying the groundwork now can deliver big benefits down the road.
One of the key differences between Apple’s Macs and the iPhone and iPad is that the Mac can still boot and run non-Apple operating systems. This is a feature that Apple specifically built for the Mac, one of many features meant to ease the transition from Intel’s chips to Apple’s own silicon.
The problem, at least at first, was that alternate operating systems like Windows and Linux didn’t work natively with Apple’s hardware, not least because of missing drivers for basic things like USB ports, GPUs, and power management. Enter the Asahi Linux project, a community-driven effort to make open-source software run on Apple’s hardware.
In just a few years, the team has taken Linux on Apple Silicon from “basically bootable” to “plays native Windows games and sounds great doing it.” And the team’s ultimate goal is to contribute enough code upstream that you no longer need a Linux distribution just for Apple Silicon Macs.
On December 4 at 3: 30 pm Eastern (1: 30 pm Pacific), Ars Technica Senior Technology Reporter Andrew Cunningham will host a livestreamed YouTube conversation with Asahi Linux Project Lead Hector Martin and Graphics Lead Alyssa Rosenzweig that will cover the project’s genesis and its progress, as well as what the future holds.
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/ Slowly but surely, the Asahi Linux team is getting Linux up and running on Apple Silicon Macs.
Apple/Asahi Linux
For around three years now, the team of independent developers behind the Asahi Linux project has worked to support Linux on Apple Silicon Macs, despite Apple’s total lack of involvement. Over the years, the project has gone from a “highly unstable experiment” to a “surprisingly functional and usable desktop operating system.” Even Linus Torvalds has used it to run Linux on Apple’s hardware.
The team has been steadily improving its open source, standards-conformant GPU driver for the M1 and M2 since releasing them in December 2022, and today, the team crossed an important symbolic milestone: The Asahi driver’s support for the OpenGL and OpenGL ES graphics have officially passed what Apple offers in macOS. The team’s latest graphics driver fully conforms with OpenGL version 4.6 and OpenGL ES version 3.2, the most recent version of either API. Apple’s support in macOS tops out at OpenGL 4.1, announced in July 2010.
Developer Alyssa Rosenzweig wrote a detailed blog post that announced the new driver, which had to pass “over 100,000 tests” to be deemed officially conformant. The team achieved this milestone despite the fact that Apple’s GPUs don’t support some features that would have made implementing these APIs more straightforward.
“Regrettably, the M1 doesn’t map well to any graphics standard newer than OpenGL ES 3.1,” writes Rosenzweig. “While Vulkan makes some of these features optional, the missing features are required to layer DirectX and OpenGL on top. No existing solution on M1 gets past the OpenGL 4.1 feature set… Without hardware support, new features need new tricks. Geometry shaders, tessellation, and transform feedback become compute shaders. Cull distance becomes a transformed interpolated value. Clip control becomes a vertex shader epilogue. The list goes on.”
Now that the Asahi GPU driver supports the latest OpenGL and OpenGL ES standards—released in 2017 and 2015, respectively—the work turns to supporting the low-overhead Vulkan API on Apple’s hardware. Vulkan support in macOS is limited to translation layers like MoltenVK, which translates Vulkan API calls to Metal ones that the hardware and OS can understand.
Apple’s OpenGL support has been stuck at the 4.1 level since macOS 10.9 Mavericks was released in 2013. Since then, the company has shifted its focus to its proprietary Metal graphics API, which, like DirectX 12 and Vulkan, is a “low-overhead” API meant to reduce the performance overhead sometimes associated with older APIs like OpenGL. But despite declaring OpenGL officially deprecated in 2018, Apple has left its existing OpenGL implementation alone since then, never updating it but also maintaining support even as it has transitioned from Intel’s processors to its own CPUs and GPUs.
Rosenzweig’s blog post didn’t give any specific updates on Vulkan except to say that the team was “well on the road” to supporting it. In addition to supporting native Linux apps, supporting more graphics APIs in Asahi will allow the operating system to take better advantage of software like Valve’s Proton, which already has a few games written for x86-based Windows PCs running on Arm-based Apple hardware.
Though there are still things that don’t work, Fedora Asahi Remix is surprisingly polished and supports a lot of the hardware available in most M1 and M2 Macs—including the webcam, speakers, Wi-Fi and Bluetooth, and graphics acceleration. Other features, like Thunderbolt, running displays over USB-C, the system’s built-in microphone, and the Touch ID fingerprint sensors, remain non-functional. Asahi’s most recent update blog post, published in mid-January, highlighted HDMI support, support for DRM-protected websites via Google’s proprietary Widevine package, Touchbar support for the handful of Apple Silicon Macs that use one, and more.
As for the newest wave of M3 Macs, Asahi developer Hector Martin said in October 2023 that basic support for the newest chips would take “at least six months.” Among other things, the team will need time to support the M3 GPU in their drivers; the team also relies primarily on Mac mini models for development, and the M3 Mac mini doesn’t exist yet.
