Asahi Linux 7.0 on Apple Silicon: I Installed It on My Real Machine and Here's What It Says About the Future of the Kernel on ARM

Why do we keep treating Apple Silicon like hostile territory for Linux when the upstream kernel has been absorbing Asahi patches for months? I'd been asking myself that every time I landed on an HN thread where someone swore that "Linux on a Mac isn't usable for real work." This week the Asahi Linux 7.0 post hit 620 points on Hacker News — that's not noise. That's signal. I decided to stop reading threads and do what I always end up doing: install it, break things, measure.

Spoiler: not everything works. But what does work completely changed how I read the problem.

Asahi Linux 7.0 on Apple Silicon: What Upstream Kernel Support Actually Means and Why It Matters More Than the GPU Driver

The coverage over the last few days focused on the GPU driver — makes sense, it's the most photogenic headline. But there's something more important underneath: Linux 6.x (and what's coming in 7.0) started absorbing native Apple Silicon support into the mainline kernel tree. Not a patch you download from some fork. Not a specialized distro living in its own bubble. The mainline tree.

That has concrete consequences — I'll detail them with what I measured — but first, the context for why I personally care.

My daily development workflow runs on Next.js, TypeScript, Docker, and PostgreSQL on Railway. Last week I was evaluating TypeScript 7.0 Beta against reproducible example codebase — you can read that experiment in the TypeScript 7.0 Beta post. What I learned there made me pay closer attention to how fragile it is to depend on an ecosystem you don't control. Asahi Linux gives me the same feeling, but on the hardware side.

When I ran the Asahi Linux 7.0 installer on my MacBook Pro M2, the first thing I noticed was how ordinary the process felt. No dramatic warnings. No cathartic ceremony. That in itself is a technical statement.

What I Measured in My Real Workflow: Honest Numbers

The Environment

# Hardware: MacBook Pro M2, 16GB RAM
# Asahi Linux 7.0 (Fedora Asahi Remix)
# Kernel: 6.12.0-asahi (base for the 7.0 series)
# Shell: zsh, tmux

uname -r
# 6.12.0-asahi-00001-g3e5f8b2d1a4c

# Verify actual architecture
uname -m
# aarch64

That — aarch64 on a Mac — still feels slightly like science fiction. But here we are.

Docker: The First Real Test

# Brought up my usual development stack
docker compose up -d

# PostgreSQL 16 + Next.js dev server + Redis
# Boot time on Apple Silicon with Asahi:
time docker compose up -d
# real    0m8.341s

# Same stack on x86_64 (reference point, different hardware, not a direct comparison):
# real    0m11.2s (average of 3 runs)

The number isn't a fair cross-architecture comparison — the hardware is different. What I can say: Docker on Asahi Linux on M2 is not the bottleneck. There was never a moment where I thought "this is being throttled by the kernel." Containers came up, volumes mounted, ports exposed. Normal flow.

What did take longer was the first docker pull of linux/arm64 images — not every image has multi-arch manifests. Official PostgreSQL 16: no problem. Some internal tooling images we have on the team: broken. That's not Asahi's fault, it's arm64 debt in the container ecosystem. Different cause, different fix.

Node.js and the Next.js Build

# Cloned my main project
git clone [email protected]:juantorchia/mi-proyecto.git
cd mi-proyecto
npm ci

# Production build
time npm run build

# Result on Asahi Linux / M2:
# real    1m14.3s

# Previous references (same project, same commit):
# M2 macOS: 0m58.1s
# x86_64 Linux (Railway VPS): 1m49.2s

Here's the interesting data point: Asahi Linux on M2 is faster at compilation than any x86 VPS I have access to. Slower than native macOS, yes — there's kernel overhead and some syscall translation layers that aren't fully optimized yet. But "slower than native macOS" isn't the relevant benchmark. The relevant benchmark is: can I do my work? The answer is yes, with room to spare.

What Doesn't Work Yet

I'm not going to pretend everything runs clean. Some things are broken:

Suspend/wake: the laptop sometimes comes back from suspend with a dead network connection. I need sudo systemctl restart NetworkManager to recover it. It's a 3-second workaround, but it's a workaround. That's not a workflow, it's a scar.

Bluetooth: I connected my AirPods. They paired. Audio comes through. With noticeable latency on calls — usable for background music, completely unusable for a Zoom meeting. For that I'm still on macOS or wired headphones.

GPU: the Asahi GPU driver (Honeykrisp) works for basic acceleration and Vulkan. For my development workflow I don't need more than that. But if you're running local ML workloads or editing video, the story is different.

The Mistakes I Made (And That You'll Make Too)

1. Assuming the Dual Boot Would Be Transparent

The Asahi installer handles partitioning in a way that's non-standard by Apple's own conventions. The first time I tried to shrink the macOS partition, the process failed silently — no error, no message, nothing changed. I had to reread the documentation (which is good, but dense) to understand I needed to do it from Apple's Recovery Mode with specific diskutil commands.

# This does NOT work from normal macOS:
diskutil apfs resizeContainer disk0s2 100GB

# This DOES work from macOS Recovery:
# diskutil apfs resizeContainer disk0s2 100GB
# (same command, different context — where you run it matters)

Three hours lost on something the documentation explicitly explains, but that I skipped because I was being arrogant about it.

2. Assuming Every Docker Image Has arm64 Support

Already mentioned above, but it deserves its own bullet: check the manifests before building a workflow that depends on specific images. docker manifest inspect image:tag before you're crying at 11pm.

3. Confusing "Kernel Support" With "Feature Parity"

Upstream kernel support for Apple Silicon doesn't mean everything that works on macOS works on Linux. It means the kernel knows how to talk to the base hardware. On top of that you still have individual drivers, firmware, userspace layers. It's real progress but it's not a "done" flag. If you came in with that expectation, you're going to be frustrated.

4. Not Making a Backup Before the First Attempt

Obvious. I'm saying it anyway because I was tempted to skip it myself. I made the backup. I'm an adult.

My Real Thesis on What Asahi Linux 7.0 Actually Means

The GPU driver is the headline. But the real story is that Apple Silicon stopped being a trap for Linux developers.

Trap in what sense: before Asahi, if you bought an M1/M2 Mac and wanted to run Linux on real hardware, you were on your own. You could use a VM but you'd lose the chip's performance. You could wait for someone to port something, but that someone had no long-term maintenance commitment. The hardware was excellent and the Linux ecosystem was telling you "you're not welcome here."

What changed with upstream support is the chain of trust. Now when there's a kernel bug related to Apple Silicon, there's a community with actual incentives to fix it in the mainline tree. Not in a fork that someone abandons when they take a job somewhere else. That's what I learned with the Bitwarden CLI supply chain attack: the trust surface of a tool isn't just its code, it's its maintenance chain. Asahi improved that chain structurally.

When we migrated Notion notes to Markdown and found that portability has a hidden cost, the problem wasn't the format — it was platform lock-in. Apple Silicon with macOS was that same problem on the hardware side. You buy the best chip on the market and you're stuck with the manufacturer's OS. Asahi Linux 7.0 starts breaking that lock-in in a legitimate way.

Is it production-ready today? For a server, no — it doesn't make sense. For a development workstation where you already know the gotchas and can tolerate meh Bluetooth and the occasional suspend failure, yes, right now.

FAQ: Asahi Linux 7.0 on Apple Silicon

Is Asahi Linux 7.0 stable for daily use? Depends on what you mean by "daily use." For software development — compiling, running Docker, writing code — it's stable. For video calls over Bluetooth or suspending the laptop ten times a day, there's still real friction. My honest take: if your work is mostly terminal and browser, yes. If you need the full multimedia stack without configuration, not yet.

Does Docker work on Apple Silicon with Asahi Linux? Yes. Docker runs natively on aarch64 without an emulation layer. Images with linux/arm64 manifests work without issues. Images that only have linux/amd64 will fail or need emulation via --platform. Check the manifests for the images you use before migrating your full workflow.

Which Apple chip works best with Asahi Linux 7.0? M1 and M2 have the most mature support because they've been under the community's microscope the longest. M3 and M4 have growing but more incomplete support, especially for GPU drivers. If you're choosing new hardware with Asahi in mind, M2 Pro is the sweet spot right now.

Does the Asahi GPU driver (Honeykrisp) hold up for development? For web development, yes — basic acceleration works, GPU-accelerated terminals run well, the desktop experience is smooth. For local ML workloads or 3D rendering, the current state isn't enough. Vulkan works but not at the speed of Apple's native Metal.

Can I use Asahi Linux as a complete macOS replacement? Today: partially. About 80% of a modern development workflow runs without friction. The remaining 20% — mature Bluetooth, solid suspend/resume, some tools that assume macOS — still needs workarounds or trade-offs. In 12 months that ratio is going to shift. The pace of upstream contributions accelerated noticeably with the 6.12+ series.

Is it worth installing if I already have a macOS workflow that works? If the workflow works, don't break it out of curiosity. Install it in dual boot if you want to explore without risk. What does make sense to do today: evaluate whether your development stack runs cleanly on arm64 Linux, because that knowledge is going to be relevant when more infrastructure migrates to ARM. That's why I did this — not to escape macOS, but to understand the terrain before it becomes mandatory to understand it. Same reason I benchmark GPT-5.5 in the API or evaluate whether Claude's quality degradation justifies canceling: I don't wait for the ecosystem to tell me. I measure it myself.

The Lock-In Nobody Names

I spent years worrying about software platform lock-in — SaaS, tools, languages. What I wasn't measuring was hardware lock-in. Apple Silicon is the best laptop chip on the market right now. The problem was that buying it meant committing to macOS with no real exit.

Asahi Linux 7.0 doesn't solve that completely. But it lays the first stone of an exit. Upstream kernel support changes the long-term maintenance equation — and for me, that weighs more than the GPU driver. Because drivers improve over time. What doesn't improve on its own is the incentive structure. And that structure today favors the people who want Linux on Apple Silicon.

What I'm not buying: the hype that "it's ready for everyone." It's not. You still need tolerance for discomfort and a genuine willingness to debug weird things at 2am on a Saturday. But that tolerance was always the price of admission to the Linux world. What's new is that now there's something on the other side that justifies it.

If you want to get started: asahilinux.org, read the full documentation before touching the disk, and make a backup. The rest is the same honest chaos it's always been.