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.
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...
> 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.
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.
> 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.
The author appears to be nostalgic for the wintel monopoly that made it possible to write software for one system standard "PC" and have it run on dozens of different manufacturer's hardware. The people who use ARM chips typically write their own code because they aren't building general purpose computers, they are building an appliance of some sort, whether its a phone or an access point or a disk controller.
I don't disagree at all with you, but it does pain me a little bit to see a phone referred to as an appliance. Phones nowadays are plenty capable general purpose computers if they aren't intentionally handicapped by the manufacturers, and the manufacturers certainly do think of them as appliances and treat them as such, but I wish that collectively we would reject that and insist on not artificially hobbling their capabilities
I know it feels like a semantic quibble. Consider that you can boot and run Linux on the processor that powers a Seagate hard drive. You can even run a c compiler and develop new code on it. But when you pull one from its protective wrapping after you bought it from a distributor, it isn't a "computer", it's a storage device (dedicated function, aka an appliance for storing data), that you can plug into a general purpose computer, or into a smart television, or into a DVR, Etc.
Similarly, for a long time, the CPU in my washing machine (a Z80) was the same processor that my first computer with disk drives had (a Cromemco System 3, aka a "business computer" which ran CP/M) but it was intentionally hobbled to just run the display, run some timed processes, and read various sensors.
Building "purpose built systems" that happen to have a computer processor inside of them because it is cheaper or more efficient to implement their functions in code, are what pretty much everyone considers "appliances." Sometimes obviously so, as in washing machines, and sometimes not so obviously when you can buy "apps", or "personality modules", or "game cartridges" for them to make them do something useful given the constraints of the fixed I/O they have.
But if you have a computer system that is intentionally hobbled to a fixed set of things, then for me, it's an appliance and certainly not a general purpose computer.
You make a good point, I guess the issue is not manufacturers considering it an appliance or even users considering it an appliance. My main issue is with them intentionally locking it down from the user. For example, in the washing machine I see no reason for it to have a locked bootloader with no way for the owner of the device to unlock it. If some Yahoo wants to hack their washing machine and run Doom and Linux, I don't see why that should matter to Samsung or Whirlpool or Google or Apple or whoever.
So I guess my issue is not thinking of these general purpose computers as appliances, so much as it is treating the owner of the device as a security threat. Secure by default is good, as the vast, vast majority of users would not be tinkering with stuff. But if they want to (and that can fully void warranties IMHO), and they own the device, I don't think the manufacturers should be blocking them.
> So I guess my issue is not thinking of these general purpose computers as appliances, so much as it is treating the owner of the device as a security threat.
And in this we are 100% in agreement.
The issue in the US is that liability falls on the manufacturer if they don't "reasonably prevent" the device from deviating from its designed function. So if you hack your washer machine to do a 20,000 RPM spin cycle and it fails catastrophically and kills someone, they have some liability there. Parents have successfully sued when their kids have 'modified' things that later killed or injured that kid. Just as burglars have successfully sued for being injured while breaking into a facility. THAT part of US tort law is really broken and needs to change.
It doesn't appear to me as a nostalgia for wintel at all. The author very aptly points out that standardization known from the PC platform is severely lacking in the ARM ecosystem. This makes ARM a good choice for digital "appliances," but not for general-purpose computers. Just the argument about kernel security updates is serious enough:
Imagine if you were buying x86 hardware. You might have to manage AcerOS, Dellbian, HPian, etc. Most of them have no security support (particularly for the kernel). Some are based on Debian 11 (released in 2021), some Debian 12 (released in 2023), and none on Debian 13 (released a month ago).
I wouldn't like to beg for kernel upgrades from my laptop manufacturer. (Apple is an exception here, because it's also an OS vendor)
Vendors don't need to ship their own images at all. Just let users install stock Debian, then provide a thin vendor package set (kernel, u-boot, DTBs, firmware) tied together by a meta-package. With apt pinning, upgrades become normal Debian transactions, security updates track Debian, and the vendor layer shrinks to a small LTS kernel delta plus boot bits.
Many architectur is free. Spark, MIPS, etc. No problem found a free solution.
But problem is blobs. Many blobs, everywhere blobs for running CPU (motherboard too), blobs in ethernet, wifi, BT etc.
> Raspberry Pi OS is only based on Debian bookworm (released in 2023) and very explicitly does not support a key Debian feature: you can’t upgrade from one Raspberry Pi OS release to the next, so it’s a complete reinstall every 2 years instead of just an upgrade.
What? I've upgraded my RPis in-place every single time there's a new OS release. They don't support upgrading that way, perhaps, but I've never had a problem.
And even for official Debian releases, they recommend you do a full backup, because it might not work.
Been here for a few years already honestly. I've found Raspis kind of annoying to deal with, and x86 mini PCs a lot more consistent and reliable.
Still holding out hope for RISC-V though, my little Milk-V pico-size Ubuntu boards are pretty cool, and I'd much rather write Linux code than rp2040 code directly (because I'm not an embedded developer and don't really know what I'm doing lol)
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
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...
> 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.
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.
> 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.
You don’t need a license to build and sell a RISC-V chip. I believe that is its primary advantage over ARM. Anything more is gravy :)
The author appears to be nostalgic for the wintel monopoly that made it possible to write software for one system standard "PC" and have it run on dozens of different manufacturer's hardware. The people who use ARM chips typically write their own code because they aren't building general purpose computers, they are building an appliance of some sort, whether its a phone or an access point or a disk controller.
I don't disagree at all with you, but it does pain me a little bit to see a phone referred to as an appliance. Phones nowadays are plenty capable general purpose computers if they aren't intentionally handicapped by the manufacturers, and the manufacturers certainly do think of them as appliances and treat them as such, but I wish that collectively we would reject that and insist on not artificially hobbling their capabilities
I know it feels like a semantic quibble. Consider that you can boot and run Linux on the processor that powers a Seagate hard drive. You can even run a c compiler and develop new code on it. But when you pull one from its protective wrapping after you bought it from a distributor, it isn't a "computer", it's a storage device (dedicated function, aka an appliance for storing data), that you can plug into a general purpose computer, or into a smart television, or into a DVR, Etc.
Similarly, for a long time, the CPU in my washing machine (a Z80) was the same processor that my first computer with disk drives had (a Cromemco System 3, aka a "business computer" which ran CP/M) but it was intentionally hobbled to just run the display, run some timed processes, and read various sensors.
Building "purpose built systems" that happen to have a computer processor inside of them because it is cheaper or more efficient to implement their functions in code, are what pretty much everyone considers "appliances." Sometimes obviously so, as in washing machines, and sometimes not so obviously when you can buy "apps", or "personality modules", or "game cartridges" for them to make them do something useful given the constraints of the fixed I/O they have.
But if you have a computer system that is intentionally hobbled to a fixed set of things, then for me, it's an appliance and certainly not a general purpose computer.
You make a good point, I guess the issue is not manufacturers considering it an appliance or even users considering it an appliance. My main issue is with them intentionally locking it down from the user. For example, in the washing machine I see no reason for it to have a locked bootloader with no way for the owner of the device to unlock it. If some Yahoo wants to hack their washing machine and run Doom and Linux, I don't see why that should matter to Samsung or Whirlpool or Google or Apple or whoever.
So I guess my issue is not thinking of these general purpose computers as appliances, so much as it is treating the owner of the device as a security threat. Secure by default is good, as the vast, vast majority of users would not be tinkering with stuff. But if they want to (and that can fully void warranties IMHO), and they own the device, I don't think the manufacturers should be blocking them.
> So I guess my issue is not thinking of these general purpose computers as appliances, so much as it is treating the owner of the device as a security threat.
And in this we are 100% in agreement.
The issue in the US is that liability falls on the manufacturer if they don't "reasonably prevent" the device from deviating from its designed function. So if you hack your washer machine to do a 20,000 RPM spin cycle and it fails catastrophically and kills someone, they have some liability there. Parents have successfully sued when their kids have 'modified' things that later killed or injured that kid. Just as burglars have successfully sued for being injured while breaking into a facility. THAT part of US tort law is really broken and needs to change.
The author is specifically talking about Raspberry Pi upstreaming changes. Isn't that about as close as you will get to a general purpose SoC?
Right, and to emphasise the point there are x86 machines which are not architecturally PCs, such as the original XBox and Playstations 4 and 5.
It doesn't appear to me as a nostalgia for wintel at all. The author very aptly points out that standardization known from the PC platform is severely lacking in the ARM ecosystem. This makes ARM a good choice for digital "appliances," but not for general-purpose computers. Just the argument about kernel security updates is serious enough:
Imagine if you were buying x86 hardware. You might have to manage AcerOS, Dellbian, HPian, etc. Most of them have no security support (particularly for the kernel). Some are based on Debian 11 (released in 2021), some Debian 12 (released in 2023), and none on Debian 13 (released a month ago).
I wouldn't like to beg for kernel upgrades from my laptop manufacturer. (Apple is an exception here, because it's also an OS vendor)
Vendors don't need to ship their own images at all. Just let users install stock Debian, then provide a thin vendor package set (kernel, u-boot, DTBs, firmware) tied together by a meta-package. With apt pinning, upgrades become normal Debian transactions, security updates track Debian, and the vendor layer shrinks to a small LTS kernel delta plus boot bits.
Many architectur is free. Spark, MIPS, etc. No problem found a free solution. But problem is blobs. Many blobs, everywhere blobs for running CPU (motherboard too), blobs in ethernet, wifi, BT etc.
THIS IS PROBLEM
> Raspberry Pi OS is only based on Debian bookworm (released in 2023) and very explicitly does not support a key Debian feature: you can’t upgrade from one Raspberry Pi OS release to the next, so it’s a complete reinstall every 2 years instead of just an upgrade.
What? I've upgraded my RPis in-place every single time there's a new OS release. They don't support upgrading that way, perhaps, but I've never had a problem.
And even for official Debian releases, they recommend you do a full backup, because it might not work.
Been here for a few years already honestly. I've found Raspis kind of annoying to deal with, and x86 mini PCs a lot more consistent and reliable.
Still holding out hope for RISC-V though, my little Milk-V pico-size Ubuntu boards are pretty cool, and I'd much rather write Linux code than rp2040 code directly (because I'm not an embedded developer and don't really know what I'm doing lol)