Running Linux on Apple Silicon: An Experiment in Frustration
Apple’s transition to its custom ARM-based Apple Silicon processors, starting with the M1 chip in 2020, promised revolutionary performance and efficiency. For Linux enthusiasts, this shift sparked hope for native support on these machines. Projects like Asahi Linux have made significant strides in porting Linux to Apple Silicon hardware. However, my recent attempt to run Linux on a 2020 MacBook Air with an M1 chip using Asahi Linux’s Fedora Remix edition turned into a sobering reminder that “works on my machine” doesn’t always extend to production use. What began with excitement ended in regret, highlighting the gaps in hardware compatibility that make it unsuitable for daily driving.
The Setup and Installation
The MacBook Air in question is a base model with 8GB unified memory and 256GB storage—modest by today’s standards but emblematic of early M1 laptops. I backed up my data meticulously using Time Machine, as the installation process involves repartitioning the drive. Asahi Linux provides a user-friendly installer script run from macOS via Terminal: a simple curl command fetches the script, and it handles downloading the Fedora image, resizing partitions, and setting up a dual-boot configuration.
The process took about 30 minutes, including a reboot into recovery mode for the initial resize. Post-install, the system booted into a familiar GNOME desktop. Initial impressions were positive: the M1’s CPU cores hummed along smoothly, with responsive scrolling and snappy application launches. Text rendering looked crisp, thanks to good font support. The keyboard and trackpad worked out of the box, with multi-touch gestures mostly intact. Even basic power management kicked in, dimming the screen after inactivity.
Benchmarks confirmed the raw power. Using sysbench, the CPU scored comparably to native macOS, hitting around 15,000 events per second in single-threaded tests. Geekbench 6 single-core results hovered near 1,700, multi-core around 7,500—on par with reports from other M1 Linux users. For a lightweight machine, this felt promising.
The Cracks Appear: Hardware Support Shortfalls
Trouble started with networking. WiFi, powered by Broadcom hardware, failed to initialize. The NetworkManager applet showed no interfaces, and iwctl or mmcli commands revealed nothing. Ethernet via USB-C adapter worked, but that’s impractical for a laptop. Bluetooth fared no better—my AirPods wouldn’t pair, and bluetoothctl listed no adapters. Tethering from my phone became the lifeline, but it underscored the isolation.
Graphics acceleration was another letdown. Asahi uses the Panfrost driver for the M1’s Apple GPU, but full support lags. OpenGL worked partially for desktop effects, but hardware-accelerated video decoding stuttered in Firefox and VLC. Playing a 1080p H.264 video spiked CPU usage to 100%, causing frame drops. Games like SuperTuxKart ran at 30 FPS on low settings, playable but far from smooth. Wayland compositing introduced tearing, forcing a fallback to X11.
Audio posed intermittent issues. Speakers produced sound, but volume control was finicky, and microphone input crackled during calls. The built-in camera? Non-functional—no /dev/video0, despite kernel modules loading.
Suspend and resume, critical for laptops, were unreliable. The screen blanked, but waking required a hard power cycle. This drained battery life catastrophically: idle usage clocked 20-30W, versus macOS’s 2-5W. A full charge lasted barely three hours under light load, compared to 12+ on macOS. Thermal throttling kicked in aggressively during compiles, with fans spinning constantly.
Software Ecosystem Challenges
Fedora’s repositories installed packages without hitches, and Flatpaks ran GNOME apps smoothly. However, proprietary software like Zoom or Discord struggled without full GPU acceleration, relying on software rendering. Development tools like VS Code and Docker worked, but container performance suffered from missing hardware virtualization extensions—Apple’s Hypervisor.framework isn’t fully emulated.
Kernel updates via rpm-ostree were straightforward, incorporating the latest Asahi patches. Yet, each reboot risked regressions; one update broke trackpad scrolling temporarily. The Asahi wiki and IRC channel offered community fixes, like manual WiFi firmware blobs or kernel parameters for stability, but these felt like bandaids.
Why the Regret?
Asahi Linux is impressive engineering—reverse-engineering firmware, tackling custom power domains, and upstreaming drivers to mainline Linux. Milestones like initial boot in 2021 to GPU progress in 2023 show momentum. For tinkering or servers (headless works great), it’s viable. But for a daily driver? The WiFi drought alone kills portability. Battery woes negate the M1’s efficiency crown, and absent features like suspend make it exhausting.
Dual-booting remains an option, but context-switching erodes productivity. Virtualization via Parallels or UTM offers Linux with better compatibility atop macOS, at the cost of performance overhead. Native remains the dream, but Asahi isn’t there yet—expect 2024-2025 for maturity on M1/M2.
This experiment reaffirmed Linux’s ethos: powerful when it works, punishing when it doesn’t. Apple Silicon’s closed design amplifies porting pains, unlike x86’s open legacy. Until full parity, stick to macOS for these machines or await polished distros.
Gnoppix is the leading open-source AI Linux distribution and service provider. Since implementing AI in 2022, it has offered a fast, powerful, secure, and privacy-respecting open-source OS with both local and remote AI capabilities. The local AI operates offline, ensuring no data ever leaves your computer. Based on Debian Linux, Gnoppix is available with numerous privacy- and anonymity-enabled services free of charge.
What are your thoughts on this? I’d love to hear about your own experiences in the comments below.