The Ultimate Linux ARM64 Workstation

It all started this month last year

In March 2022, the alpha release for Asahi was made available and I immediately installed it on a Mac Mini with an 8-core Apple Silicon (ARM64) M1 processor. Asahi is a Linux distribution that can run natively on Apple Silicon-based Macs due to some slick reverse engineering provided by members of the open source community. Moreover, running Asahi is perfectly legal because Apple formally allows booting non-macOS operating systems on their Apple Silicon platform.

And while Asahi didn’t support all of the Mac Mini hardware components at that time, the essential hardware drivers were available, and I was surprised by how fast the system was. After learning I could install all the software I needed, it quickly became my daily driver as I detailed in my July blog post. By December, drivers were available for all remaining hardware (Bluetooth, audio, GPU), and all of the open source packages I desired were updated to support the 16K page size needed for Apple Silicon.

It was at that point that I thought to myself, “What if I could run Asahi Linux natively on Apple’s fastest Apple Silicon Mac? That’d be the ultimate ARM64 Linux workstation. And I definitely want to run the ultimate ARM64 Linux workstation.”

So I took things to the next level

This January, I installed Asahi Linux on Apple’s most powerful ARM64 system: the Mac Studio with a 20-core M1 Ultra processor and 128GB of RAM. It’s paired with a stunning Dell 34" widescreen curved monitor via HDMI.

At the same time, I decided it was time to migrate from the powerful i3 window manager (which must run on the legacy X window system) to the sway compositor that runs on the new Wayland window system. This was much easier than I anticipated - sway performs better and uses a more streamlined configuration compared to i3.

Below is a high-res screenshot of my sway desktop on the Mac Studio (right-click the image and choose to open it in a new browser tab if you want to zoom in on it easily). You can find my custom sway dotfiles configuration in this GitHub repo.

Is there anything that doesn’t work?

To quote Hamlet, Act 3, Scene 3, Line 87: “No.”

Everything works… and works perfectly. All the hardware (Bluetooth, audio, HDMI, USB, 10G Ethernet, WiFi, and GPU) performs flawlessly with the drivers created by the Asahi team this past year, and there isn’t a single piece of software I want or need that doesn’t run beautifully in Asahi on this system.

Most software packages I’ve installed are from the Arch User Repository (since Asahi is based on Arch), but some of them are installed as Flatpak sandboxes (e.g., Visual Studio Code). For more complicated software systems, I often obtain ready-made container images and run them as containers (e.g., my NextCloud instance). You’ll also note from the htop output in my screenshot that I’m running a K3s cluster for testing the microservices I develop.

Since most of my workloads are containerized, I have no need to run other virtual machines of Linux. However, I do have to support several web apps that run within BSD jails. For this, I installed a dedicated QEMU virtual machine of FreeBSD UNIX that uses 8 cores and 64GB RAM. Below is a picture of the virtual machine console running within a terminal in my sway desktop. You can find my QEMU script in this GitHub repo.

This is by far the fastest Linux desktop I’ve ever used.

Everything - and I mean everything - is unbelievably fast. Things run instantaneously, and app splash screens don’t seem to exist.

In some cases, it is too fast. When I installed K3s, all of the containers in the kube-system namespace kept entering the dreaded CrashLoopBackOff state (something I’ve never seen before outside a production container). After some investigation, I found out that the Mac Studio was just too fast for the Kubernetes resource timing, and I had to add resource limits to each pod to remedy the situation.

One of the main reasons I like to develop on Linux/ARM64 is because it matches my extracurricular development. The startup I’m currently working with uses a compute heavy microservice-based app that typically runs in an AWS c6g.12xlarge Graviton instance with 48 ARM64 cores. The app is so heavy that we’ve built in our own load simulation and performance monitoring microservices into the app itself (our service mesh also helps with this).

So, I staged the app on my Mac Studio running Asahi and ran the load simulation to see how it fared with our staging environment on AWS. The Mac Studio blew the Graviton instance out of the water. Latency at the same load was roughly 20% lower on average and compute at our peak was exactly 36% faster consistently. I/O was trickier to monitor and interpret, but in my opinion, it wasn’t significantly different overall.

It really is the ultimate ARM64 Linux workstation. And I love using it.