Today in Tedium: Over the weekend, something really awesome happened. An official distro of Linux came to Apple Silicon. And honestly, it’s extremely impressive, a joy to use (even if there are a whole bunch of gaps in the production, a number of to-come features that will limit its usefulness for the time being), and … honestly, everything that MacOS is not. It’s inspiring, and reflects a culture in which people are willing to try new things, and in which they succeed at trying out those new things just because there was enough public support for it. It’s arguable that in a technology world full of exciting things, you don’t get much more exciting than Asahi Linux—all the more exciting when you consider that its install process is surprisingly painless. In honor of its release, today’s Tedium culls together some thoughts on Linux and ARM, two great things that taste great together (as long as the fragmentation is kept in check). — Ernie @ Tedium
We accept advertising, too! Check out this page to learn more.
“I’ve been waiting for an ARM laptop that can run Linux for a long time. The new Air would be almost perfect, except for the OS. And I don’t have the time to tinker with it, or the inclination to fight companies that don’t want to help.”
— Linus Torvalds, in a Real World Technologies forum post from 2020, upon the release of the M1 line of MacBooks, discussing the desire to use an ARM-based laptop for Linux. About two weeks later, Hector Martin—a developer with experience in reverse-engineering the Nintendo Wii, Microsoft Kinect, and Sony Playstaon 4—made his desire to develop an Apple Silicon version of Linux publicly known.
Thoughts on the Asahi Linux install process, from someone who installed a version of Linux on the M1 before there was really a distro
Based on the fact that Asahi Linux is a very early alpha and many of its features are not working as of yet, I don’t think it’s fair to do a review, but I do want to offer a bit of a comment on something I noticed because I was one of the few people to take the plunge into Linux-land well before Asahi Linux ever saw release.
Simply put: Its installer is amazing and, if you’re at all curious about Linux, it makes the process simple.
A lot of my interest in Linux on the M1, early on, reflected sort of the new frontier-ness of it all, the ability to play with virtual machines on a platform where the story hadn’t been fully written yet.
But while VMs are fun, at some point, you get curious about what else might be possible. And that led me to trying the first attempt at bringing a natively booting Linux to the M1, made by the device virtualization and security research firm Corellium. I kinda saw it as an opportunity to experiment with something that was literally bleeding edge—a version of Linux (an Ubuntu build, to be exact) that was literally being hacked into working form by a company that saw a lot of technical opportunities in doing so.
I have tried out a number of ARM-based Linux platforms over the last few years, in an effort to understand the landscape of the market. But the M1 was a beast in its own right, and a big part of the problem is that Apple went out of its way to make the process scary. To boot into Corellium’s Ubuntu build, you literally had to go into the recovery system (which Apple calls 1 True Recovery OS) every single time, type in a command, and go through a number of screens warning you that that you’re about to do puts your system at a security risk. It felt dangerous, because Apple put threats in front if you every time you tried to bend the system’s will.
But that will was certainly bent in a way that offered a taste of what was to come. The company’s CTO, experienced iOS hacker Chris Wade, put a lot of the work into creating the port that allowed for this, had to account for numerous edge cases. One of those edge cases: I could not install the Linux build on my MacBook Air because of some differences between the solid-state chips it sported and the ones on the MacBook Pro which he built on. I pointed this out to Wade and he spent a lot of time working with me to test the issue. Soon enough, we had it working.
So about a month after I got my 16-gigabyte M1 MacBook Air (after starting with an 8-gigabyte model), here I was trying to put Linux onto it with the help of someone who can code rings around this thing. Slowly, but surely, things began to work—first, off a USB, and then off the SSD itself. And the operating system, despite lacking GPU support, was extremely fast.
I will admit that there was a degree of excitement to this process; one of the golden geese was to get the thing to run an eGPU eventually. But the technical differences between Apple Silicon and other ARM64 platforms meant it was a somewhat bumpy ride—fun to play around in, not necessarily turn into a daily driver. Corellium’s efforts, while they didn’t bring us to Linux nirvana in the end, should be seen as historically important, the first released efforts to allow Linux to run on Apple Silicon.
The makers of Asahi Linux, led by Martin, took a very different approach to handling all this. (And honestly, it’s great they did; we needed both approaches!) Martin and his team—Alyssa Rosenzweig, Dougall Johnson, Sven Peter, and Mark Kettenis—have spent more than a year building the tooling for a version of Linux that was built from the ground up for this operating system. Rather than hacking an existing version of Linux to work on the platform, the team worked on the project through a strongly supported crowdfunding effort that helped to take on different elements of the system.
Each dev has their role. For example, Rosenzweig, an expert at graphics systems, is currently working on reverse-engineering the Apple Silicon GPU; Kettenis, who generally works on OpenBSD, helped to design the boot system.
And honestly, the final result is extremely impressive—even before it supports any of the stuff it’s going to eventually support—because of the novel solution they used to allow it to boot. Unlike the Corellium solution, the installation process starts in the user space, at the command line, with a single terminal command. And to boot into it, you’re not stuck going into recovery mode every single time—in fact, you can even make Linux the default operating system on your Mac, if that’s how you roll.
And it starts with the command line. This command takes you through a fairly simple process that’s loaded with a whole bunch of hand-holding. It tells you in detail what’s about to happen and makes it clear what you’re agreeing to.
But the truly novel part is how it works around the discomfort of threatening your user partition just to install your system: It literally installs another recovery partition just for Linux, uses that for the complex setup (but automatically runs a script to minimize discomfort within the recovery interface), has you type in your password a couple of times, and boom, you’re an M1 Linux user.
(The only truly quirky part is the requirement to hold your power button a certain way, but honestly, it struck me as very similar to what I usually do when booting into recovery mode.)
And then when you get to the final result, you get an interface which does not support GPU-driven graphics, yet somehow feels significantly faster than my Pinebook Pro, which does have the benefit of a GPU. (It should be said that the Pinebook, following PINE64’s general philosophy, is significantly more open than the M1 MacBook Air.)
The greatest trick of all is that Asahi Linux has the ability to install itself within your computer while maintaining the integrity of the rest of your system. By building a separate recovery mode, the Linux system basically lives distinctly from the rest. It’s a clever solution that puts a reasonably technical person in the driver’s seat.
If you ask me, that’s something missing in a lot of Apple experiences. There’s often an implicit distrust of what the user is going to do, down to the hardware level, that is completely at odds with what Linux represents. So seeing a team of developers take so many steps to neutralize some of the scary parts of installing a third-party OS onto a Mac is refreshing.
The year Debian first saw an ARM port, on version 2.2 of the operating system, codenamed Potato. It was the first major Linux distro that appeared on ARM architecture. Interestingly, the first PowerPC port of Debian appeared at right around the same time. What varied histories those two architectures have had.
The very first version of Linux built for ARM dates all the way back to 1994 … and grew increasingly fragmented over time
Now that we’ve literally spent a bit talking about the bleeding edge of bleeding edge of Linux distributions for ARM architectures, let’s take a few minutes to look back at where this all started.
While ARM has a reputation of being a somewhat new and exotic platform, the truth of the matter is that it is one of the longest-supported architectures in all of Linux, all thanks to the formative works of a British university student named Russell King. In many ways, he became the Linus Torvalds of ARM—an academic whose interest in ARM-based flavors of Linux eventually became his full-time job.
In the spring of 1994, King worked on developing a port of the Linux kernel—which had just hit version 1.0 at the time and had only at that time been designated as production-ready—for his primary computer, the Acorn A5000, which was part of the Archimedes line of computers.
“It was already about 3 years old and underpowered at that time, with only 4MB of RAM, but it was the machine I had,” King told the website KernelTrap in 2001.
King’s efforts to port ARM perhaps seemed a bit experimental at the time—as he put it on his website for the ARM Linux port, “the port was started before the kernel even knew about the SPARC, MIPS, Alpha or M68K architectures”—but he noted that some of the then-existing limitations of Acorn’s native RISC OS, which didn’t support virtual machines at the time.
“With the source code available, and time, there is the possibility to get anything working on ARM,” King told KernelTrap. “ARM does have some unique problems, but it wouldn’t be any fun if it didn’t!”
At the time of his KernelTrap interview, King noted that he managed the code bases for as many as 120 distinct types of machines. But this was nothing compared to where ARM was headed. As ARM’s commercial prospects improved along with the technology, he found his services in maintaining the kernel increasingly in demand from a commercial standpoint, which created complexities as the role evolved. Simply put, all the differences in various use cases for the ARM chipset had created degrees of fragmentation that remain an ongoing challenge for the architecture’s operating system use cases.
A Computerworld piece from 2011 referred to the Linux ARM codebase of the time as “a hot mess” and noted that many of the code updates to ARM Linux were not making it in the main branch at the time because the job had simply gotten too difficult to maintain. In the middle of all of this, of course, was King:
As many note about [Linus] Torvalds in general and maintainers specifically, Linux ARM maintainer Russell King does not scale. Faced with increasingly frequent and often-redundant proposed changes to the kernel, King and his team of sub-architecture maintainers (of which Likely is a member) could often fall behind.
Now ARM support is a labyrinthine maze of wheels within reinvented wheels, to mix the metaphors. But in recent years there has been a concerted and growing movement in the ARM community to finally bring about consolidation across features.
Torvalds himself became critical upon signs of fragmentation when they emerged, saying as such:
People need to realize that the endless amounts of new pointless platform code is a problem, and since my only recourse is to say “if you don’t seem to try to make an effort to fix it, I won’t pull from you,” that is what I’ll eventually be doing.
Exactly when I reach that point, I don’t know.
One thing that eventually helped to calm down some of the complexity around ARM was the creation of a nonprofit called Linaro, which aimed to align the industry around more consistent solutions across the board and stronger consolidation around the kernel, especially in use cases like embedded systems. The concept has shown enough success that its mission has recently expanded to Windows, if you’d believe it, complete with support from Microsoft.
As for King, he’s still an active maintainer of the Linux kernel for ARM use cases to this day, as an employee of Oracle. Not a bad evolution for the creator of a 28-year-old port of Linux to the only computer he had available at the time.
I realize that my longstanding interest in ARM and Linux is kind of “my” nerd thing, a thread that I’ll continue to follow as the market evolves.
But I want to take a step back and just reflect on the fact that a lot of where we’re at reflects miles and miles of code audits and low-level modifications of code to make things like this work.
In a lot of ways, Linux has evolved into a bedrock of many commercial use cases, many of which would not be possible without a whole lot of extra work and investment. But it’s rooted in the work of the individual user.
In November of 2020, Hector Martin asked his audience on Twitter a simple question: “Would you be willing to fund a Linux port to Apple Silicon macs, and if so, how much would you pledge?”
With just the promise of his existing track record to support his cause along with a passion around the technology, Martin convinced numerous people to support his work in creating a version of Linux of the M1 Mac. And in a little less than 16 months, he and his team fulfilled the basic goals of that mission. That work will open up endless commercial possibilities for the M1 that weren’t previously available. And even if he stopped what he was doing tomorrow, he will have left such an impressive body of work that the community could pick up where Asahi Linux left off and it would be great.
Following through on a huge promise is hard, so that it happened in a reasonable amount of time is not just impressive, it’s groundbreaking.
In an increasingly locked-down world, work like this is what will help us continue to ensure the end user stays at the forefront of the conversation.
Find this one an interesting read? Share it with a pal!