← Back to context

Comment by bigyabai

7 days ago

If anyone wants to read up on all the features Apple didn't implement from Intel Macs that made Linux support take so long, here is a list of UEFI features that represents only a small subset of the missing support relative to AMD and Intel chipsets: https://en.wikipedia.org/wiki/UEFI#Features

Alternatively, read about iBoot. Haha, just kidding! There is no documentation for iBoot, unlike there is for uBoot and Clover and OpenCore and SimpleBoot and Freeloader and systemd-boot. You're just expected to... know. Yunno?

To be fair, this is how homebrew for Apple devices has always worked. You've always had to effectively reverse engineer the platform in order to write privileged code. Although I get the argument that if Apple were explicitly trying to support alternative operating systems they probably could have done more to make it easy, really what they were doing with this was first and foremost enabling additional use cases for macOS, and then maybe silently doing it in a way that third parties would also be able to benefit from. The Asahi wiki does a bit of a better job of explaining this, but the suspicion is that Apple did this not necessarily to make it easier for alternative operating systems to exist but to prevent the Mac from needing to be jailbroken when alternative operating systems were bound to happen anyway.

  • It's not how homebrew worked on Intel Macs, or even PowerMacs[0] either. It's a change made with the Apple Silicon lineup - I cannot speak on Apple's behalf to tell you why they did that. But I can blame UEFI as the reason why the M3 continues to have pitiful Linux support when brand-new AMD and Intel chips have video drivers and power management on Day One.

    [1] https://mac-classic.com/articles/open-firmware-basics/

    • The EFI environment does provide some basic drivers for the boot environment, but they all go away once the OS loads, except for a handful of functions such as EFI variable management. (Linux can also reuse a framebuffer originally obtained from EFI for a very limited form of video support - efifb - but that’s not proper video support.) So EFI doesn’t get credit for video drivers or power management.

      For power management, you can however give some credit to ACPI, which is not directly related to UEFI (it predates it), but is likewise an open standard, and is generally found on the same devices as UEFI (i.e. PCs and ARM servers). ACPI also provides the initial gateway to PCIe, another open standard; so if you have a discrete video card then you can theoretically access it without chipset-specific drivers (but of course you still need a driver for the card itself).

      But for onboard video, and I believe a good chunk of power management as well, the credit goes to drivers written for Linux by the hardware vendors.

    • Sorry, I should have specified Apple Silicon rather than just "Apple devices". Obviously the devices that used widely supported CPUs running pretty much widely supported firmware were pretty easy to install non-Apple things on. My Mid-2015 A1398 ran a triple boot between macOS, Windows and Arch Linux thanks to rEFInd.