[tliltocatl]

The early PC era was a mess, and that's not the period I'm talking about. IBM was clearly not up to the task and Intel didn't care much yet, but Microsoft certainty did a lot for compatibility from the start (i. e. DOS abstracted away a lot of BIOS routines, so it would be easy to port MS-DOS to a non-IBM x86). But after IBM revealed MCA to show just exactly how much do they care about compatibility and platform openness, Intel realized they are missing out and cleaned up the MCA/EISA/VLB mess with PCI. Then Microsoft and Intel jointly released APM 1992 (which was clearly not enough), and then ACPI in 1996 (which is a total dumpster fire, but a sufficiently functional dumpster fire). I. e. ACPI and UEFI are exactly the product of the monopoly. M$/Intel profited from the abundance of cheapo white boxes, so it was in their best interest to come up with a standard even DELL can implement. The fact that AMD is going to implement the ACPI too wasn't much bother for Intel - they were so dominant that they could afford not to care.

On the other hand, ARM sells the cores to SoC vendors (and doesn't care much what becomes of it), SoC vendors ducktape the ARM cores to a bunch of Synopsys peripherals and sell the resulting SoCs to smartphone and car makers (and doesn't care much for the product). System integrators throw Android on top and sell it to the customers. Then Google, who get all the cream via Play, hides all the mess behind a thousand layers of Java abstractions.

DeviceTree is an offshot of Sun's OpenFirmware (and it leaves out all the hard stuff - OpenFirmware had Forth, DeviceTree expects the kernel to support every single brand of fan switch). OpenSBI is a disaster. I'm sorry, but what kind of bright mind came up with the idea of hiding damn *timer* behind a privilege switch? Timers were enough of a pain point on x86 already, then it settled on userspace-accesable RDTSC. RISC-V SBI? Reproducing x86 one stupid decision at a time.