The exception (even those are questionable as running plain Debian did not work right on Pi 3B and others when I tried recently) proves the rule. You have to look really hard to find an x86 computer where things don't just basically work, the reverse is true for ARM. The power draw between the two is comparable these days, so I don't understand why anyone would bother with ARM when you've got something where you need more than minimally powerful hardware.

My uninformed normie view of the ecosystem suggests that it's the support for almost every particular board, and that's exactly the issue. For some reason, ARM devices always have some custom OS or Android and can't run off-the-shelf Linux. Meanwhile you can just buy an x86/amd64 device and assume it will just work. I presume there is some fundamental reason why ARM devices are so bad about this? Like they're just missing standardization and every device requires some custom firmware to be loaded by the OS that's inevitably always packaged in a hacky way?

So, I agree but less than I did a few months ago. I purchased an Orange Pi 5 Ultra and was put off by the pre-built image and custom kernel. The “patch“ for the provided kernel was inscrutable as well. Now I’m running a vanilla 6.18 kernel on a vanilla uboot firmware (still a binary blob required to build that though) with a vanilla install of Debian. That support includes the NPU, GPU, 2.5G Ethernet and NVMe root/boot. I don’t have performance numbers but it’s definitely fast enough for what I use it for.

There's also a risk of your DeviceTree getting pruned from the kernel in X years when it's decided that "no one uses that board anymore", which is something that's happened to several boards I bought in the 2010's, but not something that's happened to any PC I've ever owned.

That makes sense, as the Pi is as easy as x86 at this point. I almost never have to compile from scratch.

I'm not a compiler expert... But it seems each ARM64 board needs its own custom kernel support, but once that is done, it can support anything compiled to ARM64 as a general target? Or will we still need to have separate builds for RPi, for this board, etc?

With this board the SoC is the main problem. CIX is working on mainlining that stuff for over a year and we still dont have gpu and npu support in mainline

I still have to run my own build of kernel on Opi5+, so that unfortunately tracks. At least I dont have to write the drivers this decade

This. The issue is the culture inside many of these HW companies that is oppositional to upstreaming changes and developing in the open in general.

Often an outright mediocre software development culture generally, that sees software as a pure cost centre, in fact. The "product" is seem to be the chip, the software "just" a side show (or worse, a channel by which their IP could leak).

The Rockchip stuff is better, but still has similar problems.

These companies need to learn that their hardware will be adopted more aggressively for products if the experience of integrating with it isn't sub-par.

No it's definitely a problem with the ARM architecture, specifically that it's standard to make black box SoCs that nobody can write drivers for and the manufacturer gives you one binary version and then fucks off forever. It's a problem with the ARM ecosystem as a whole for literally every board (except Raspberry Pi), likely stemming from the bulk of ARM being throwaway smartphones with proprietary designs.

If ARM cannot outdo x86 on power draw anymore then it really is entirely pointless to use it because you're trading off a lot, and it's basically guaranteed that the board will be a useless brick a few years down the line.

> The problem isn't support for the ARM architecture in general,

Of course it is not. That's why almost every ARM board comes with it's own distro, sometimes bootloader and kernel version. Because "it is supported". /s

> I'd expect this to run circles around an N150 for single-threaded perf too

It has basically the same single-core performance as an N150 box

Random N150 result: https://browser.geekbench.com/v6/cpu/10992465

> BTW what's up with people pushing N150 and N300 in every single ARM SBC thread?

At this point I expect a lot of people have been enticed by niche SBCs and then discovered that driver support is a nightmare, as this article shows. So in time, everyone discovers that cheap x86-64 boxes accomplish their generic computing goals easier than these niche SBCs, even if the multi-core performance isn't the same.

Being able to install a mainline OS and common drivers and just get to work is valuable.

> BTW what's up with people pushing N150 and N300 in every single ARM SBC thread?

Because they have a great watt/performance ratio along with a GPU that is very well supported by a wide range of devices and mainline kernel support. In other words a great general purpose SBC.

Meanwhile people are using ARM SBCs, with SoCs designed for embedded or mobile devices, as general purpose computers.

I will admit with RAM and SSD prices sky rocketing these ARM SBC look more attractive.

Because most ARM SBCs are still limited to whatever linux distro they added support to. Intel SBCs might underperform but you can be sure it will run anything built for x86-64.

ARM SBCs that cost over $90 are totally not worth it considering those Nxxx options exist

> BTW what's up with people pushing N150 and N300 in every single ARM SBC thread?

For 90% of use cases, ARM SBCs are not appropriate and will not meet expectations over time.

People expect them to be little PCs, and intend to use them that way, but they are not. Mini PCs, on the other hand, are literally little PCs and will meet the expectations users have when dealing with PCs.

1. Wow, never thought I'd need to do an investment disclosure for an HN comment. But sure thing: I'm sure Intel is somewhere in my 401K's index funds, but also probably Qualcomm. But I'm not a corporate shill, thank you very much for the good faith. Just a hobbyist looking to not get seduced by the lastest trend. If I were an ARM developer that'd be different, I get that.

2. The review says single core Geekbench performance is 1290, same as i5-10500 which is also similar to N150, which is 1235.

3. You can still get N150s with 16gb ram in a case for $200 all in.

Are you sure you don't have single-threaded and multi-threaded backwards?

Why would the A720 at 2.8 GHz run circles around the N150 that boosts up to 3.6 GHz in single-threaded workloads, while the 12-core chip would wouldn't beat the 4-core chip in multithreaded workloads?

Obviously, the Intel chip wins in single-threaded performance while losing in multi-threaded: https://www.cpubenchmark.net/compare/6304vs6617/Intel-N150-v...

I can't speak to why other people bring up the N150 in ARM SBC threads any more than "AMD doesn't compete in the ~$200 SBC segment".

FWIW, as far as SBC/NUCs go, I've had a Pi 4, an RK3399 board, an RK3568 board, an N100 NUC from GMKTec, and a N150 NUC from Geekom, and the N150 has by far been my favorite out of those for real-world workloads rather than tinkering. The gap between the x86 software ecosystem and the ARM software ecosystem is no joke.

P.S. Stay away from GMKTec. Even if you don't get burned, your SODIMM cards will. There are stoves, ovens, and hot plates with better heat dissipation and thermals than GMKTec NUCs.

x86 based small computers are just so much easier to work with than most second- and third-string ARM vendors. The x86 scene has had standards in place for a long time, like PCIe and the PC BIOS (now UEFI) for hardware initialization and mapping, that make it a doddle to just boot a kernel and let it get the hardware working. ARM boards don't have that yet, requiring per-board support in the kernel which board manufacturers famously drag their feet on implementing openly let alone upstreaming. Raspberry Pi has its own setup, which means kernel support for the Pi series is pretty good, but it doesn't generalize to other boards, which means users and integrators may be stuck with whatever last version of Ubuntu or Android the vendor thought to ship. Which means if you want a little network appliance like a router, firewall, Jellyfin server, etc. it often makes more sense to go with an N150 bitty box than an ARM SBC because the former is going to be price- and power-draw-competitive with the latter while being able to draw on the OS support of the well-tested PC ecosystem.

ARM actually has a spec in place called SystemReady that standardizes on UEFI, which should make bringup of ARM systems much less jank. But few have implemented it yet. I keep saying, the first cheap Chinese vendor that ships a SystemReady-compliant SBC is gonna make a killing.

No idea - the ryzen based ones are better!

This OrangePi 6 Plus board comes with cooling and a power supply (usb-c). No case, though.

I've got i3 and i5 systems that do 15W or better idle, and I don't have to worry about the absolute clusterfuck of ARM hardware (and those systems used can be had for less and will probably long outlive mystery meat ARM SBCs).