On the Pi Zero and Pi CM (maybe also others) you don't even need an SD card to boot it. You can boot it via rpi-boot https://github.com/raspberrypi/usbboot
so no need for qemu for testing. You can just test it on real hardware in no time.
Without qemu you have to implement serial interfaces early in order to debug your own OS. Qemu is a huge benefit early on, and provides a sane environment for deterministic development as opposed to potentially quirky hardware.
Usually hobbyist OS projects don't start directly on hardware. Many of them never reach the point of running on hardware.
I don't know about qemu for a PI/arm in general, but you do have to be careful on x86, because segmentation limits aren't checked by default, and you can be lulled into doing things that don't work on hardware (I messed up secondary processor starting), and if you don't frequently test on hardware, it's easy to forget things. (See also homebrew games that only work on emulators)
But, you can certainly wait to start on hardware until you've got it started on qemu. Debuggability is a lot better unless you've got specialized equipment for your hardware setup
On Arm a couple of only-on-hardware pitfalls are (a) cache maintenance -- QEMU doesn't model caches so won't notice if you forget to clean the dcache and flush the icache before executing code you just wrote or modified and (b) synchronization/barriers -- QEMU doesn't reorder memory accesses and generally makes writes to system registers take effect immediately, so won't notice if you forget necessary barrier insns.
The Pi 3 and 4 can also boot from TFTP with an NFS root. This also allows you to switch the OS your Pi is booting just by renaming a symlink on your server. All my home Pis boot that way. As a bonus, you never need to worry about an SD card going bad.
I have been playing with it yesterday night and noticed that I can achieve a throughput of 17.8 Gbit/s on iperf3 with the standard FreeBSD 13.0 stack (in a VM with virtio-net) and only 13-14 Gbit/s on the Rack Stack. Is there something I'm missing?
Rack is not tuned for single stream bandwidth. There are things that it does which may lead to lower single stream bandwidth. For example, if you have 1MB ready to send and enough receiver window, the default stack will loop around in tcp_output() and send all 1MB immediately 16 64K TSOs. I believe Rack will back off in between.
It might be the head parking / reentering. This is called "load cycle" count. You might check smartctl and see if the number of load cycles increases after each time you hear that sounds.
I've had this problem with my Seagate Exos X 14TB. In the end I've disabled the idle2 timer, which is resposible to park the head after 2m of inactivity. This resulted in 1000 load cycles just after I had the disk for 100h somehow.
Does the modem have access to GPS? If so, it would be interesting to implement theft protection or things alike.
Do binaries built with "GOARCH=ARM ARM=7 GOOS=linux go build" work?
I didn't worked with exactly this modem model, but yes Go binaries work just fine on most of them since it's usually heavily cut Android inside which using BusyBox.
Great, works out of the box. I'd add an anonymous option to the login, even though you can leave the password empty.
Also, an indicator if TURN is used and if it's non-encrypted or encrypted would be great.
I haven't thought about it seriously, but I was thinking about simply using a shared key (PBKDF2, since that is implemented in the browser), with a symmetric cipher and HMAC.
To tell the truth, I haven't seen much demand for end-to-end: this is a web application, so an attacker who controls the server can simply serve Javascript with a backdoor.
Makes sense. WebRTC seems to address a lot of the security concerns [1], and with it being a web-application served remotely, not much need for e2e. Though, if you were to host the application locally, and manage the updates yourself you may want to have some form of e2e.
Remember it was initially implemented to support giving lectures to tens of students, who may join late or leave early. Having to teach remotely, let's try to at least not reproduce the annoyance of the physical world with the noise of the classroom's door ;-)
I am a little confused about the statement of 8000 messages per second. What messages? Sensor readings? 8000 ASCII commands received via UART? To be honest, parsing 8k of data per second is not much at all. I am also wondering why this particular board uses a PIC microcontroller when other multi- core and cheaper variants are available (e.g. ESP32, XMOS, ..).
Yes, this article is garbage and the design is a head-scratcher. I guess possibly because it was something the designer was familiar with or they wanted some feature of the chip, eg. very low idle power.
