Stephen’s dad, is that you?

It’s mainly due to PA Semi acquisition. These guys were the ones responsible of making excellent PowerPC processors, which were similar to what ARM has now.

These guys are probably happier now that they have more resources, target devices and tightly coupled software.

NeXT computers were based on Motorola 680x0 processors that were actually CISC ( not RISC ). Steve Jobs did run MacOS on RISC in the 90s though as that is what PowerPC was.

Modern Apple silicon is of course ARM64 so not the same architecture as PowerPC at all.

Yeah. Linux is also optimized to run well. Has a capable community and a few good design choices. Many people use it to run it on servers so I wouldn’t be surprised if it performed well well on servers.

Also there is a well known fork that is used on millions/billions(?) of ARM phones. So it’d better be a good choice for that use case.

Windows on ARM is a steaming pile of garbage

NT is not the majority of windows code though; for windows to be multi architecture, all of windows needs to work with the new architecture; NT, drivers & userspace.

For Linux, if an existing userspace application doesn’t work in aarch64, somebody somewhere will build a port. For windows, so much of their stuff is proprietary that Microsoft are the only ones able to build that port.

Not because “windows bad”, just a consequence of such a locked down system which doesn’t have anything open source to inherit.

Not my area, but since OSs are really low-level (obviously), they can be affected by details of the host architecture that we don’t often think about. Endianness, for instance.

I opened up the source package for the kernel I’m currently running (6.1.42) and looked at it. The smallest set of architecture-specific code is the ~2MB for sh (I assume that’s SuperH, a 32-bit RISC architecture from the early 1990s). 32-bit ARM takes up 27MB, although if you check the individual files, a fair amount of that is device trees and the like. So we’re talking about less than 50MB of arch-specific source code for most platforms, and probably less than 10 in many cases, but it depends on the design of the architecture and how many times it’s been extended.

Looking at individual file names, topics addressed in the kernel’s arch-specific code files appear to include booting, low-level memory access, how to idle the CPU, crypto primitives, interrupts, suspending/hibernating the system and other power management, virtualization facilities if the CPU provides them, crash dumps and stack traces, and, yes, endianness.

You may also need additional drivers for odd bits of hardware not used by other systems. Or not, but it’s a common sticking point with ARM SOCs and other small-format machines.

That’s just the kernel. You’ll also need to establish a working cross-compiler before you can get your kernel onto the system. At that point, you can probably bootstrap much of the rest by running make and get to a working command-line system (GUI is going to be more of a crapshoot, requiring additional work on video acceleration and such in order to run well). And there may be odd warts in other pieces of software, each requiring a few lines of code that add up over time.

Because it’s open source and most of the applications for it are open source. That means you can compile it and the applications specifically for the hardware you have.

Windows does kind of support ARM on its specific hardware, but it can’t be adjusted for other hardware and they have to translate most applications to work. Apple has done much of that work for their hardware to work well, as well as very good translation for x86, and because they leaned hard into the transition, developers were mostly forced to compile for ARM going forward. Microsoft hasn’t done the same, and ARM is a tiny target, so it doesn’t happen with any regularity there.

Because people have been doing so for a long time and have ironed out most of the quirks. The software is also generally quite simple, meaning there are just fewer quirks that need to be ironed out. And the ecosystem is largely open source, meaning everything can be recompiled to target the relevant architecture, so while translation layers are still useful, they’re not the essential tool they are in proprietary ecosystems. The main headaches that plague windows on arm mostly just don’t exist on the Linux side.

Because you can try compile it on arm, and if something doesn’t work you can report it or fix it yourself. That said windows worked fine on arm years ago. Many gps, medical, and such devices used to use windows ce on arm, mips. (Windows phone too, arm)

ARM the company as well as industry partners contribute code & resources to the linux kernel…so that would be one reason why linux on ARM runs well.

Unsure how we are tracking Microsoft ARM as worse than Linux arm, what benchmarks did we see?

You still need a way to know which memory addresses your I²C or SPI interface has. While DeviceTree is better than nothing, it’s way worse than the “It just works” of ACPI

I don’t know what distros are available, but the big project everyone is talking about when talking about Linux on apple silicon is Asahi Linux

Ooops! I meant to type ‘Macbook Air’. I’ll leave the goof up to give your comment context, but I don’t have a MBP these days. I used the initial Asahi release and I’ve been upgrading it in place for a year or so.

A key factor is LINUX has been available for ARM since nearly “the beginning”. Unlike Windows, which was basically Intel only for well over a decade, LINUX has had strong support for multiple architectures throughout its lifecycle. As a result, software that grew up within that ecosystem tended to be more agnostic in design which helps porting efforts.