[bluGill]

I don't understand this niche. Linux does not need to run on an ARM machine for almost anything. Linux has very good cross platform abilities and so you can build and test on whatever CPU (presumably x86, but any CPU will do), and then when you are confident that everything works cross compile for ARM and things will almost always work. You also have qemu which is slow but plenty good for running some code where this matters.

You do need a little testing because ARM is different, but the odds that are are doing something where it matters are low. I've been doing the above for years and only found two things. First was a bug in GCC (already fixed in a newer version by the time I traced it down). Second was x86 has a strong stronger memory model for sharing data between threads - hopefully you are not doing that (I only hit it because I maintain our cross thread message system).

You also can't test anything that uses GPIO type things - but this computer has different setup and so you couldn't with this anyway. (and you should abstract your GPIO for testing anyway so this because a small test case when you do switch to real hardware)

[AlotOfReading]

I think I'm probably in the target market for this. I have a board using Linux on an Arm v9.2 chip. It'd be nice to run unit tests with exactly the same binaries and compiler settings. The actual boards are a bit expensive and unavailable for CI purposes (vs HIL). Graviton isn't v9.2. QEMU doesn't support v9.2. This does.

Probably won't end up buying this, but it's not hard to imagine a small number of other people would find it useful.

[geerlingguy]

This, basically - if you target embedded, automotive, mobile (Android, perhaps), then having good native machines supporting the latest Armv9 features is helpful, compared to emulating it on another machine, or running stuff in the cloud.

Like I said, a niche, but not one that's nonexistent. I know Minisforum was hyping the Android angle a bit, though in my small amount of mobile app dev, I was happy enough doing that on my Mac.

[mbreese]

Ironically, the most Linux on ARM I have experience with is from a VM on my Mac. It wouldn’t be perfect , but it’s pretty good for working with ARM. You aren’t emulating the CPU architecture, but you are running under virtualization.

I’m just thinking that the Mac Mini might also be better for that usecase, even with the virtualization in place. If you need to support a specific processor, you probably want to work with that exact processor. But if you want to use any ARM, a virtualized Linux running on a Mac isn’t a bad option.

[lostlogin]

Using UTM I managed to get a headless server running on the Mac mini that behaved better than the mini did. Eg mounted file servers actually mounted at boot reliably and container startup was controlled (maybe it’s me but desktop docker… ew).

The downside is that it eats into power usage. Even then, I’m averaging just 6.4w over 30 days.

[bluGill]

portable code is starting to become valued in automotive. In the 8 bit era rewriting for each new modle was a good choice but there days code is too complex and so we need our code to survive longer than the cpus we start with. Often the cpus a car starts with are out of porduction before the model run is done. Car volumes are not big enough to keep a fab open.

[ndiddy]

Besides TSO like you mentioned, the SIMD implementation is different (SSE/AVX vs. NEON) which is important if you do anything that uses SIMD intrinsics directly. If you're deploying to ARM servers, it's also nice to be able to test the exact same binaries you'll be running on the server.