According to the Indiegogo page, the EM2 has 1 USB-C port on the back.

We don't use the 64-bit OS on RPi. As you point out the software support is not as mature and there's really no benefit to running 64-bit OS on RPi unless you have more than 4GB of RAM on your board.

I agree that there are much better SBC options out there if you just want to run basic Linux applications that require Ethernet or WiFi. However, where the RPi shines is in how mature the software stack is for it. The support for video, audio, and I/O is truly excellent on the RPi compared to other vendors. Our company had been using RPi3B+ and RPI4 boards to interface with our own Pi hat that passes video through CSI-2 to the RPi and is controlled by the RPi using SPI and GPIO. The I/O stack just works, and it works reliably (not to mention availability of documentation). We ported our platform to the NanoPi M4 and M4B and had nothing but problems. The imaging and I/O software stack is horrid on NanoPi and just plain unreliable. The bottom line is if you want to do real embedded systems things with your SBC, you'll have a much easier time with the RPi than anything else in its class.

Definitely a cool use of the Framework hardware, but as TFA points out, the Framework motherboard alone is more expensive than a Steam Deck. Hard to see much value in design around Framework's modular hardware if upgrade costs are the same as buying an entirely new device. How many people out there want to pay such a premium just to more easily customize a hand-held device?

TFA says this problem is associated with Intel GPUs, not Intel CPUs. Seems like the summary should have made that clear.

The Pixel line is replacing Nexus, so isn't the Nexus/Pixel buyer in the same position? So, if you want the latest and greatest Android has to offer, you should by the phone from Google. However, I agree that it is a bit annoying that the current Nexus phones will not move forward with these new features.

Exactly!

You seem to be missing the point of this completely. ;) I needed a cluster to test some distributed programs (yes, you can test distributed programs inside a cluster). The cluster itself has nothing to do with my PhD work other than that it is a tool I created to ensure I could test the software I've been developing. As for providing a tutorial on how to do what I did, I was writing this to enable freshman engineers understand what was involved with building the cluster. Not everyone knows Linux, or how simple it is to build a Beowulf cluster.

Thanks. You have accurately deduced my intent ;) I started this project when the 32-node cluster I had been using was taken offline for renovations of the lab it resides in.

I actually just installed openmpi on it, I just need to port my programs over....slightly different function names than mpich, of course. One especially nice benefit to openmpi is that you don't have to compile it from source for ARM. It is available in the Arch Linux repositories.