I promise this isn’t a rant or cry for help; I’m just sharing an interesting observation that the Linux community might appreciate. Please know I’m comfortable and knowledgeable enough to be dangerous on any platform, though I generally prefer Unix/Linux and macOS over Windows. I inherited an obsolete, under-powered MacBook Air (Intel i5, 4G RAM, 128G SSD) and I’ve been testing virtually every popular distro on it for the last few months. I encountered the same Linux shortcoming across every distro, and I thought some of y’all might find this mildly interesting.

There seems to be an underlying issue running Linux on MacBooks, stemming from the fact that MacBooks require a kernel module with proprietary firmware blobs to support their Broadcom wifi & bluetooth hardware. Now, the Broadcom module is readily available in every standard package manager, but it will never be included in the mainstream kernel since it contains closed source software. For distros with a self-contained installer, this is not a huge problem at first - just download and install the appropriate Broadcom package separately to patch your kernel after installation and you should be good, right?

No. Trouble is the kernel and other packages (but mostly kernel) get updated constantly, seemingly without regard to existing kernel module compatibility. Depending on the distro, that Broadcom package might be weeks or even months behind the latest kernel release. The effect of this is that it’s never safe to just run software updates on a MacBook, because you’re playing roulette with your wifi hardware every time. Desktops with ethernet are easier to recover from because it’s easy to plug in, but for a laptop relying on wifi it’s a much bigger hassle when your wifi breaks.

Obviously you can just revert to a prior kernel then pin the working kernel version in place, but held packages like your kernel impact other software as well. Simply running Linux on MacBook hardware generates this ongoing cycle of issues over the proprietary software blobs required for the hardware. Typical designed-for-Windows devices face this issue far less frequently, so the added hurdle for MacBooks feels mostly ignored by the general Linux community.

This makes rolling release distros particularly problematic on MacBooks, which is really a shame. Even an atomic distro like Bazzite (which provides that Broadcom module right out of the box, by the way) breaks a MacBook’s wifi sooner or later if you install updates normally. I thought I was clever running Kali Linux for awhile. It runs really nicely on this meager hardware and KDE felt zippier than many other distros. I still had to manually install the Broadcom driver after installation, but with a Debian back-end I was really hoping it would pull delayed enough releases to keep the wifi working… it did not. Kali runs a rolling release based on Debian Testing, which still pulls recent enough kernel updates to break the wifi.

Many Arch-based distros won’t even install (btw), because the install images require a working networking stack, relying solely on the kernel’s built-in hardware support. I’m certain there are workarounds, but there’s no obvious, easy way for casual users to inject the required Broadcom module into the downloaded installer. Sadly, the best long term solution I’ve found is to just stick to annual, major LTS release distros like Debian Stable where enough time passes after most package updates that my cursed Broadcom module has had sufficient time for the dev to catch up.

Don’t get me wrong, I’ve been running Debian + KDE on my older-but-much-beefier MacBook Pro for years now, and it’s been a constant source of pleasure to use. I just thought I’d share a little about the unique challenges of a Linux fan who happens to own some aging Mac hardware. Someone here probably knows an obvious solution to make this far easier for the average user. I’m not begging anyone for help, though I certainly welcome your comments. In any case, I hope you enjoyed this read. Mac hardware would be really nice to run Linux if it weren’t for this module annoyance.

Author @DetachablePianist@lemmy.ml