31–38 of 38 posts
> You can't run binaries designed for a normal PC on an ARM board ...doesn't Debian ship some multiarch/QEMU/binfmt plumbing to make this work? Binfmt to taste the binary, see that it's i386/amd64, and then launch QEMU (and associated ARM multiarch libs) with user-mode emulation? Slow as dirt I'm sure but it'll work.
> You can't run binaries designed for a normal PC on an ARM board ...doesn't Debian ship some multiarch/QEMU/binfmt plumbing to make this work? Binfmt to taste the binary, see that it's i386/amd64, and then launch QEMU (and associated ARM multiarch libs) with user-mode emulation? Slow as dirt I'm sure but it'll work.
This should be backed up by some numbers. I have seen plenty of benchmarks now that pretty much show that many workloads on ARM64 are a lot faster.
Note that the Raspberry Pi can boot over PXE without an SD card these days, which should make for a much more reliable setup.
I found that to be extremely unreliable, I had to reset the Pi a few times before it actually made TFTP requests. A tiny SDcard with just U-Boot on it, configured to netboot, has been actually reliable.
> You can't run binaries designed for a normal PC on an ARM board ...doesn't Debian ship some multiarch/QEMU/binfmt plumbing to make this work? Binfmt to taste the binary, see that it's i386/amd64, and then launch QEMU (and associated ARM multiarch libs) with user-mode emulation? Slow as dirt I'm sure but it'll work.
Surely that does not qualify as "running the binaries" if you emulate another arch! I mean if you want to be nitpicky, yes, you're running them, but that is not what most people think when saying that.
Given what the article says about k8s not working so well in the RPi's 1GB of RAM, is there another cheap ARM SOC that has more RAM available that could work similarly?
RK3328: Pine64's ROCK64 comes in 2GB and 4GB of RAM (also the RK3399 based ROCKPro64 is even more awesome, bigger form factor, but two A72 cores for actually good performance! Oh and some other manufacturers even made RK3399 based RPi-sized boards!)
Earlier quoted context omitted.
I share your sentiment regarding Mosix. I don't think however, that clustering SBCs is of any value beyond the learning experience. Even a moderately powerful laptop is much faster than a *Pi, e.g. a 2013 Chromebook Pixel is about 16 times faster than a Banana Pi, when measured using `openssl speed`.
It depends when you're trying to do with them, but the network speed of the Pi is definitely a bottleneck for me. If it weren't for that, the throughput could definitely be used for some cool stuff even with modest CPU/RAM. My cluster: https://www.youtube.com/watch?v=lZDUe-_mzHc
Earlier quoted context omitted.
I found that to be extremely unreliable, I had to reset the Pi a few times before it actually made TFTP requests. A tiny SDcard with just U-Boot on it, configured to netboot, has been actually reliable.
If you are using (two) DHCP servers in "proxy" mode as suggested in the official tutorial, it indeed is extremely unreliable. I think the firmware just does not accept the PXE-containing response if it arrives second or something.