Asahi Linux on M3

Original Article ↗ Hacker News Discussion ↗

Asahi Linux’s progress in bringing native Linux support to Apple’s M‑series chips, including early M3 work, is widely praised as a remarkable reverse‑engineering effort but still limited by missing pieces like Thunderbolt, USB‑C video on some models, and immature GPU support on the newest hardware. Commenters debate why Apple withholds hardware documentation and drivers—citing business incentives, IP concerns, and its ecosystem strategy—while noting that earlier M1/M2 support is already good enough to make old Macs viable Linux machines once macOS support ends. Some see projects like Asahi (and AI‑assisted efforts such as Omarchy) as crucial to keeping high‑quality Apple silicon hardware useful and open over the long term.

Project status and technical caveats

  • Asahi now boots on newer M-series (including M3), but feature support lags older chips.
  • Mature on M1/M2: functional GPU acceleration with open drivers; used successfully for gaming (via Steam/Proton) and desktop use.
  • M3: GPU support is still missing; HDMI works for some, but USB‑C/Thunderbolt video and full Thunderbolt (PCIe, stable DisplayPort) are not ready.
  • Sleep and suspend remain problematic on some Intel and Apple Silicon Macs; users report hangs and manual power-cycling.
  • Local AI: llama.cpp and similar workloads are much slower than Metal on macOS; some won’t switch until GPU/NPU paths are competitive.

Use cases and target users

  • Core audience: people who want bare‑metal Linux on Apple’s efficient hardware, for daily use, servers, or future-proofing once macOS support ends.
  • Others dual‑boot: macOS for specific apps (music/DJ, iOS/mac builds) and Asahi for everything else or for Steam gaming.
  • Some argue it’s mainly for tinkerers and those who dislike macOS’s UX, policies, or background services.

Apple’s stance, docs, and business incentives

  • Repeated debate: why Apple doesn’t publish hardware specs or Linux drivers.
  • Arguments they don’t: tiny Linux-on-Mac market; high documentation effort; IP protection; avoiding ongoing compatibility obligations; services/ecosystem revenue more important than extra Mac sales.
  • Counterpoints: Intel/AMD provide docs and Linux drivers for their hardware; even partial docs would massively reduce reverse‑engineering effort.
  • Several note Apple could have fully locked out alternative OSes but chose a boot process that allows unsigned OSes; Apple engineers have reportedly even fixed bootloader quirks that broke Asahi.
  • Darwin and various Apple open‑source projects are cited, but many see Apple’s contribution to FOSS as modest compared to other big vendors.

Lifecycle, right‑to‑repair, and e‑waste

  • Strong interest in Asahi as a way to keep capable M1–M3 machines useful after macOS and App Store support end.
  • Some suggest regulators should require hardware documentation or key release at end‑of‑life, possibly with tax incentives or disposal obligations.

Virtualization vs bare metal

  • macOS’s Hypervisor/UTM can run ARM Linux VMs with near‑native speed and is praised by some as “good enough.”
  • Others reject this: they want macOS gone for trust, security, simplicity, or philosophy; running Linux inside an unpatched, end‑of‑life macOS is seen as unsafe.

Omarchy and AI‑generated drivers

  • A separate “Omarchy” effort reportedly uses AI to accelerate driver work (e.g., M4 GPU).
  • Some see potential for code reuse; others warn about legal provenance and “sloppy” AI output, and expect Asahi to avoid that code.