Apple Silicon Macs versus ARM PCs

November 19, 2020

In a comment on my entry on how I don't expect to have an ARM-based PC any time soon, Jonathan said:

My big takeaway from the latest release of Apple laptops is that these new laptops aren't necessarily ARM laptops. [...]

When a person gets an Apple Silicon Mac, they are not getting an ARM computer. They are getting an Apple computer.

As it happens, I mostly agree with this view of the new Apple machines (and it got some good responses on These Apple Silicon Macs are ARM PCs in that they are general purpose computers (as much as any other OS X macOS machine) and that they use the ARM instruction set. But they are not 'ARM PCs' in two other ways. First, they're not machines that will run any OS you want or even very many OSes. The odds are pretty good that they're not going to be running anything other than OS X macOS any time soon (see Matthew Garrett).

Part of that is because these machines use a custom set of hardware around their ARM CPU and Apple has no particular reason to document that hardware so that anyone else can talk to it. In the x86 PC world, hardware and BIOS documentation exists (to the extent that it does) and standards exist (to the extent that they do) because there are a bunch of independent parties all involved in putting machines together, so they need to talk to each other and work with each other. There is nothing like that in Apple Silicon Macs; Apple is fully integrated from close to the ground up. The only reason Apple has for using standards is if they make Apple's life easier.

(Thus, I suspect that there is PCIe somewhere in those Macs.)

Second, they don't use standard hardware components and interfaces. This isn't just an issue of being able to change pieces out when they break or when they don't fit your needs (or when you want to improve the machine without replacing it entirely). It also means that work to support Apple Silicon Macs doesn't help any other hypothetical ARM PC, and vice versa. To really have 'ARM PCs' in the way that there are 'x86 PCs', you need standards, and to get those standards you probably need component based systems. If everyone is making bespoke SoC machines, you have to pray that they find higher level standards compelling, and those standards are useful enough.

(Even laptop x86 PCs are strongly component based, although often those components are soldered in place. This is one reason why Linux and other free OSes often mostly or entirely just works on new laptop models.)

PS: My feeling is that there is no single 'desktop market' where we can say that it does or doesn't want machines with components that it can swap or mix and match. There is certainly a market segment that demands that, and a larger one that wants at least the lesser version of adding RAM, replacing the GPU, and swapping and adding disks. But there is also a corporate desktop market where they buy little boxes in a specific configuration and never open them, and I suspect it has a bigger dollar volume.

Comments on this page:

By Peter at 2020-11-19 03:16:43:

“ (Even laptop x86 PCs are strongly component based, although often those components are soldered in place. This is one reason why Linux and other free OSes often mostly or entirely just works on new laptop models.)”

I haven’t run Linux recently, but this goes against my experience and logic. Linuxes usually support older hardware better because it takes time to reverse engineer the closed parts and add open source support to those. I had lenovos before I’ve turned to macs, and in general the latest and greatest Thinkpad lacks full support that the 1-2, or even the 5 year old Thinkpads have.

By cks at 2020-11-19 10:02:25:

It certainly used to be that way, but there has been a startling sea change in Linux support somewhat recently. These days many new laptops (or at least new models of established laptop series) work or mostly work on day one. My impression is that part of this is that more and more parts of laptops are broadly used components, and some of the more tricky bits come from the CPU vendors, who explicitly develop Linux support for them (eg the core chipset is basically an Intel/AMD show now).

I think laptop vendors have incentives to push toward commodity insides even if you ignore Linux. The more you have custom hardware that standard Windows drivers can't talk to, the more you have to pay for writing your own Windows drivers. And these days if it has a standard Windows driver, Linux and other open source things probably can talk to it too.

By antiphase at 2020-11-20 13:11:31:

This is mere pedantry, but "OS X" has been called "macOS" by Apple for a couple of releases now, and in fact Big Sur which is the latest release and the first to support Apple Silicon is designated as version 11, so there is no more X (in the Roman sense) now at all.

I'm sure this will persist in the same way that "SSL certificates" do though.

By cks at 2020-11-20 16:01:47:

I'm sufficiently out of touch with Macs and Apple's naming that I have to fumble around every time I need to refer to the operating system they use (although I could and should check authoritative sources, but laziness). I'll hopefully remember "macOS" for future use.

(And I'm sure that iOS versus iPadOS will not be confusing in the least in the future, especially if they diverge from each other in important ways while remaining fundamentally the same in others.)

By James (trs80) at 2020-11-25 11:07:47:

I disagree that Apple Silicon Macs are general purpose computers. Look at these instruction for enabling system audio capture, something that isn't even a kernel extension but is subject to the same controls as one. Yes you can do it, no it's not remotely practical.

Written on 19 November 2020.
« Grafana and the case of the infinite serial number
Firefox on Linux has not worked well with WebRender for me so far »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Nov 19 01:21:38 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.