It's incredible how in 2025 people still don't grasp what a system on a chip is [1], and that the CPU cores are just a small part of the whole. Your operating system is barely concerned about the instruction set, and much more concerned about the buses and so on that are available, and how to drive them.

You only get standardization in servers because relatively speaking the number of peripheral types on the server SoC is smaller, and their usage modes more predictable.

[1] https://en.wikipedia.org/wiki/System_on_a_chip

▲

anfilt a day ago | parent | next [-]

I would say part of it is that ARM never really had wide spread socketed chips. It's pretty much just always a soldered highly integrated unit.

Go go back far enough you had a point in time for example you could swap an Intel or AMD cpu onto the same motherboard. Also using expansion cards for additional hardware capability was the norm. So software kinda evolved to handle disparate configurations of hardware.

ARM evolved differently. It end up being to be used more in embeded and then SoC systems. Hardware around the CPU and later on Die ended up with often a unique configure for the system/device. So the need to handle disparate hardware configurations was less important. Also the way ARM licenses their IP definitely pushed things to be more like this.

RISC-V atm is often being used in place of ARM so a lot entities are kinda are treating similar to ARM when developing a system/device. However, RISC-V since it's an open license on the ISA does not have to be used in similar way. Like imagine if there was some standardized socket for RISC-V chips and that took off, we would probably see things like UEFI and drivers/kernel drivers meant to work with more than just one single configuration of hardware ect...

▲

kelnos 2 days ago | parent | prev | next [-]

> You only get standardization in servers because relatively speaking the number of peripheral types on the server SoC is smaller, and their usage modes more predictable.

You get standardization on servers because of UEFI and ACPI. There are some ARM boards out there with UEFI, but for whatever reason it hasn't generally caught on in the ARM world like it has for x86.

	▲	M95D 19 hours ago \| parent [-]
		UEFI and ACPI had nothing to do with it. X86 and servers existed well before ACPI, or even PCI, or even ISA PnP(!) were invented. X86 always had standards, they all had the same two 8259 interrupt controllers, same CMOS RTC, same timer, same 16550-compatible UART, same floppy controller, same VGA framebuffer addresses, even the IDE controllers were all using the same driver. Even now, x86 needs only 3 USB drivers to support basic input: UHCI, OHCI and EHCI, and all of them can be discoveded by PCI PnP - ACPI/UEFI isn't needed for this. ARM has dozens of UART implementations, dozens of USB controllers, dozens of RTCs, probably hundreds of timers, dozens of specialized internal buses with no auto-init or discovery (PnP), each and every one turned off by default to save power and requiring specialized init by a specific driver to be functional. That's what's wrong with ARM. Not UEFI. That and the fact that chip manufacturers don't bother to PR to mainline any of thir driver code. UEFI will not change anything. It's a closed-source devicetree equivalent that can compromize any system at ring -2. Of course it will never be updated.

▲

bigstrat2003 2 days ago | parent | prev [-]

> It's incredible how in 2025 people still don't grasp what a system on a chip is [1], and that the CPU cores are just a small part of the whole.

Many people are only casually interested in something, so they learn less quickly. Or they are just learning for the first time. It's not actually particularly incredible that there are people who don't know this.