No idea - the ryzen based ones are better!

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.

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.

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

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?

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.

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?