Manufacturers hack it together, flash to device and publish the sources, but dont bother with upstreaming and move on.
Same story as android devices not having updates two years after release.
At some point the "good" boards get enough support and the situation slowly improves.
We reached the state where you dont need to spec-check the laptop if you want to run linux on it, the same will happen to arm sbc I hope.
For example I have an Orange Pi 5 Plus running the totally generic aarch64 image of Home Assistant OS [0]. Zero customization was needed, it just works with mainline everything.
There's even UEFI [1].
Granted this isn't the case for all boards but Rockchip at least seems to have great upstream support.
[0]: https://github.com/home-assistant/operating-system/releases
Any SBC could buy an extra flash chip and burn an outdated U-Boot with the manufacturer's DTB baked in. Then U-Boot would boot Linux, just like UEFI does, and Linux would read the firmware's fixed DTB, just like it reads x86 firmware's fixed ACPI tables.
But - cui bono?
You need drivers in your main OS either way. On x86 you are not generally relying on your EFI's drivers for storage, video or networking.
It's actually nice that you can go without, and have one less layer.
The shape of historically delivered ARM artifacts has been embedded devices. Embedded devices usually work once in one specific configuration. The shape of historically delivered ARM Linux products is a Thing that boots and runs. This only requires a kernel that works on one single device in one single configuration.
The shape of historically delivered x86 artifacts is socketed processors that plug into a variety of motherboards with a variety of downstream hardware, and the shape of historically delivered x86 operating systems is floppies, CDs, or install media that is expected to work on any x86 machine.
As ARM moves out of this historical system, things improve; I believe that for example you could run the same aarch64 Linux kernel on Pi 2B 1.2+, 3, and 4, with either UEFI/ACPI or just different DTBs for each device, because the drivers for these devices are mainline-quality and capable of discovering the environment in which they are running at runtime.
People commonly point to ACPI+UEFI vs DeviceTree as causes for these differences, but I think this is wrong; these are symptoms, not causes, and are broadly Not The Problem. With properly constructed drivers you could load a different DTB for each device and achieve similar results as ACPI; it's just different formats (and different levels of complexity + dynamic behavior). In some ways ACPI is "superior" since it enables runtime dynamism (ie - power events or even keystrokes can trigger behavior changes) without driver knowledge, but in some ways it's worse since it's a complex bytecode system and usually full of weird bugs and edge cases, versus DTB where what you see is what you get.
It's a problem that's inherit to mobile computing and will likely never change unless with regulation or an open standards device line somehow hitting it out of the park and setting new expectations a la PCs.
The problem is zero expectation of ever running anything other than the vendor supplied support package/image and how fast/cheap it is to just wire shit together instead of worrying about standards and interoperability with 3rd party integrators.
It supports NVMe SSDs same as an N100.
Maintenance is exactly the same; they both run mainline Linux.
Where the N100 perhaps wins is in performance.
Where the Orange Pi 5 Plus (and other RK3588-based boards) wins is in power usage, especially for always-on, low-utilization applications.
For power I don’t know about orange pi 5 but for many SBC power was a mixed bag. I had pretty bad luck with random SBC taking way more power for random reasons and not putting devices in idle mode. Even raspberry pi was pretty bad when it launched.
It’s frustrating because it’s hard to fix. With x64 you can often go into bios and enable power modes, but that’s not the case with arm. For example pcie4 can easily draw 2w+ when active. (The interface!)
See for example here:
https://github.com/Joshua-Riek/ubuntu-rockchip/issues/606
My n100 takes 6W and 8w (8 and 16gb). If pi5 takes 3w that’s not large enough to matter especially when it’s so inconsistent.
Now one place where I used to like rpi zero was gpio access. However I’m transitioning to rp2350 as it’s just better suited for that kind of work, easier to find and cheaper.
I never ran into that bug but I came to the Orange Pi 5 Plus in 2025, so there's a chance the issues were all worked out by the time I started using it.
Looking at a couple of reviews, the Orange Pi 5 Plus drew ~4W idle [0] while an N100 system drew ~10W [1].
1W over a year is 8.76kWh, which here costs ~$2. If those numbers hold (and I'm not saying they do necessarily but for the sake of argument) and with an estimated lifespan of 5 years, you might be looking at a TCO of $140 hardware + $40 power = $180 for an Orange Pi 5 vs. $140 hardware + $100 power = $240 for an N100. That would put an N100 at 33% more expensive. Even if it draws just 6W compared to 4W, that's $200 vs. $180, 11% more expensive.
I'm not saying the Orange Pi 5 Plus is clearly better but I don't think it's as simple as one might think.
[0]: https://magazinmehatronika.com/en/orange-pi-5-plus-review/
[1]: https://www.servethehome.com/fanless-intel-n100-firewall-and...