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.
