Is there a reason why it's so hard to support newer M chips after supporting an older one? Like so much harder than supporting a new generation Intel or AMD chip doesn't seem too hard in comparison.
Because Intel/AMD regularly contribute kernel changes to maintain support for their own hardware, whereas Apple keeps making undocumented changes that Asahi has to reverse engineer.
I don't think that's it, as we usually don't even have to update the kernel: when I get a new PC, my old software still boots and runs. The answer has to also provide some analogous note that, unlike new x86 hardware having an interest in still being able to run old versions of Windows, new Apple hardware (maybe... one must presume for the story to be consistent) must not really care about being able to boot old copies of macOS.
> unlike new x86 hardware having an interest in still being able to run old versions of Windows
The "secret sauce" is... we're not speaking about "x86" systems, at least as long as UEFI doesn't enter the game. In fact what we're talking about is "IBM PC-compatible x86" and its BIOS that provides ultra-low-level interfaces for input and output (including a very very basic USB stack). These can then be used to continuously load higher level systems.
Basically what you start with in the BIOS land is the boot sector, you got barely enough code capacity that you have input from the disk and text console output. That you can use to load a second stage bootloader (e.g. GRUB, NTLDR) which now has better knowledge of filesystems, maybe even enough of the driver to bring the GPU up with the basic VESA interface. And that then loads the actual operating system which brings up the rest of the system - proper GPU, a full featured USB stack, you name it. And layered in between that is ACPI for dynamic hardware discovery.
UEFI based systems can skip a lot of the slow early code used to boot in BIOS - it hands over directly to the OS itself in the best case, or to a high-level bootloader such as the modern Windows bootloader that can do all sorts of magic.
In contrast, the ARM world sucks hardcore - there are no standards for board bringup and boundaries, there is only DeviceTree which replaces a very small part of the wonder/hellscape that is ACPI. And that is something even Apple couldn't get rid of. Hell, you can't even be sure it's the CPU that brings everything up - there are weird systems like Broadcom's VideoCore architecture that underpins the Raspberry Pi, where the video chip part of the SoC handles bringing up the ARM CPU.
Basically, x86 has a ton of legacy and warts but for that, backwards compatibility and to a degree even forwards compatibility is a thing. ARM in contrast... it's like if you let a bunch of drugged up monkeys loose.
> In contrast, the ARM world sucks hardcore - there are no standards for board bringup and boundaries
There are standards for ARM, and they are called UEFI, ACPI, and SMBIOS. ARM the company is now pushing hard for their adoption in non-embedded aarch64 world - see ARM SBBR, SBSA, and PC-BSA specs.
> There are standards for ARM, and they are called UEFI, ACPI, and SMBIOS.
The most popular ARM dev and production board - the Raspberry Pi - doesn't speak a single one of these on its own, so do many of the various clones/alternatives, and many phones don't either, it's LK/aboot, Samsung and MTK have their proprietary bootloaders, and at least in the early days I've come across u-boot as well (edit: MTK's second-stage seems to be an u-boot fork). And Apple of course has been doing their own stuff with iBoot ever since the iPhone/iPod Touch that is now used across the board (replacing EFI which was used in the Intel era), and obviously there was a custom bootloader on the legacy iPods but my days hacking these are long since gone.
I haven't had the misfortune of having to deal with ARM Windows machines, maybe the situation looks better there but that's Qualcomm crap and I'm not touching that.
Regarding Windows/PC ARM devices, I think the best experience would be on System76 Thelio (with Ampere CPU), but that's quite a pricy machine.
I don't really care what Apple does on this regard, they were always doing things differently. IIRC, even Macs that supported EFI, only supported EFI 1.1, not 2.0, no?
> I don't really care what Apple does on this regard, they were always doing things differently. IIRC, even Macs that supported EFI, only supported EFI 1.1, not 2.0, no?
Yup, but as long as you got an original Apple GPU that's enough to just stick a Windows or Linux USB stick and you can install straight from the stick. "Normal" PCI GPUs have to be reflashed with a GOP blob [1] so that Apple's EFI implementation can work with it.
Personally, I just went and installed OpenCore once and that's it.
They should have pushed for it years ago, ARM's devicetree clutter and bootloader "diversity" has been a curse on the end user. At this point it's too late, and doubtful that they even have the influence to make OEMs adopt it.
This is because Intel and AMD can develop support for your new hardware and add it to the kernel and userland drivers before the hardware releases. They new hardware GPU hardware revisions are definitely not backwards compatible and always need at least some changes. CPUs are a different story due to x86 being x86.
No: this is obviously incorrect, as even dead operating systems that will never experience a new version or have any driver support work well enough on newer Intel hardware. This is due to some combination of extremely long-lived standards and epic forwards compatibility in the design of the BIOS layer. For a better answer, read mschuster91's response.
Which again, is obviously the wrong answer, as that same argument could try to be applied to Windows and would fall immediately: Windows 95 knows nothing of my new hardware, and yet, by and large, works fine. There is something unique about macOS and Apple that causes their hardware to actively not bother to maintain any form of backwards compatibility with the software that runs on it (which is not to be unexpected from Apple, but still), and that must be present in the answer to this question (which is done really well by mschuster91).
I've found that doing this on laptops is often more problematic, the OS itself will usually boot fine, but you might have issues with drivers for supporting hardware like the GPU, audio, etc.
1) Intel and AMD help to implement support in Linux before their chips even ship. Actually a sanitized version of the Intel graphics ISA bspec is actually available to the OSS community too.
Apple on the other hand provides no support. The one nice thing they did do is allow their bootloader to boot non-apple signed OSes. They do not do this on iPhones, iPads, Apple TVs, Watches, or homepods btw.
2) The GPU ISA changes drastically and often. Its not entirely uncommon for the entire instruction set to change entirely within one generation. Every change to the ISA would require an entire round of new reverse engineering (I suspect, ive never reversed).
I do wonder why Apple chooses not to lock down the Mac to just Mac OS like all their other hardware? I'm sure the sales from people who intend to run something other than MacOS look like a floating-point error on the scales Apple operates.
You replied to your own question. Locking down the system for 3 users worldwide and making sure it stays locked is not worth the effort.
Just not publishing the specs is enough to delay so much the effort that those machines are out of warranty and have depreciated so much by the time they are supported that they aren't competitors to the mac ecosystem anymore.
I don't think it is possible to have a locked down development machine. You have to be able to run arbitrary code on a development machine so they can never lock it down like iOS is.
There are plenty of other ways they can be less open and hackable than Linux but it can never get to the point of the iPhone.
That’s a reasonable take. The never part seems strong though.
If I may offer a slight consideration? “arbitrary code vs arbitrary signed code”.
What’s realistically stopping Apple from requiring all code and processes be signed? Including on device dev code with a trust chain going back to Apple and TPU / Secure Enclave enforcement
They don't because it's a floating-point error now. But with the continued enshitification of MacOS, it likely won't be in the future, and they just may lock it down. But being so hostile to the hacking community would do more harm than good, so I doubt that they would do so even if Linux use on Macs grew to >1%.
M4 had some security stuff added, and M5 much more so. Not sure how/if those can be disabled. Others can be explain why this matters better than I can.
