A bullet fired at a target a thousand yards away does not travel in the direction you aimed it. It falls thirty feet, drifts a foot sideways from its own spin, and gets nudged by the rotation of the Earth. This is a piece about the Rust engine I wrote to predict all of that — how you test physics when you have no oracle, why the hard bugs were never in the equations, and the one problem worth charging for: solving ballistics backwards.
Hands-on review of the FriendlyElec NanoPC-T6N, a Rockchip RK3588 SBC with 16 GB RAM, dual 2.5GbE, and a 6 TOPS NPU running Debian 13 on FriendlyELEC's BSP. It posts the fastest ARM compile time on my bench (52.55s), pushes 2.19 GB/s of AES-128-GCM, and never throttles - peaking at 56.4C under sustained eight-core load. Also the story of why my standard benchmark stopped being comparable to its own history, and what the microSD it shipped booting from is costing it.
NetBSD now runs on my Milk-V Mars: 28 GB root filesystem, gigabit Ethernet at 0.0% packet loss, SSH like any other machine on the shelf. It is the only documented NetBSD Mars I'm aware of, and getting there took a weekend of archaeology: a vendor bootloader whose advertised boot logic is dead code, a QEMU time machine built from Debian's snapshot archive, an SD card doubling as a flight recorder, a serial console that demolished every blind theory in ten minutes, a kernel panic caught with full backtrace, and a filesystem-corruption incident I caused myself by "fixing" a safety mechanism I hadn't understood. The final fix for the whole device-tree saga is one line in a U-Boot defconfig. The whole build is scripted and reproducible; a flashable image is next.
Hands-on review of the Banana Pi BPI-R4 Pro, a MediaTek MT7988A (Filogic 880) router board with quad Cortex-A73, dual 10GbE, and 8GB RAM running OpenWRT. Benchmarked for what a router actually does - CoreMark 9533/37952, ~1 GB/s hardware AES, GbE line-rate networking, 50C under load - and deployed as a real SSH bastion and nginx reverse proxy. A different animal from a compute SBC, reviewed as one.
I had three small Arm64 boards on a shelf, each doing one modest thing and idling the rest of the time — an Orange Pi 5 Max running an occasional local LLM, two Raspberry Pi–class machines mostly serving a web page. Between them they had sixteen cores, forty gigabytes of RAM, and four terabytes of NVMe, and almost none of it was doing anything at any given moment. This is the story of resisting the urge to buy two more boards into a memory shortage, and instead turning that idle majority into a real three-node HA k3s cluster with embedded etcd, then teaching it to do the job the boxes had quietly been built for all along — compiling native FreeBSD, OpenBSD, and NetBSD Arm64 binaries — and the small pile of gotchas that stood between "three SBCs" and "a build farm," from a big.LITTLE crash loop to golden images that turned out to be live disks. And then everything else the reclaimed capacity paid for.
Five weeks ago I ended a post about writing OpenBSD's missing ena(4) driver with a confession disguised as a list — every way the thing didn't work yet. This is the post where I cross them all off. The driver does a full disk install now, comes up multiuser with the AWS network card as its only interface, lets me SSH in over it, pushes 3.16 Gbit across multiple queues with receive-side scaling, and runs unchanged on OpenBSD-current. It is, by every technical measure I set for myself, done. And that is exactly when it walked into the one wall effort can't move: code an AI wrote has no human author, so it cannot go into OpenBSD's tree — not for lack of quality, but for lack of a person. This is the story of finishing it, the one bug I never cracked, and what it means to write working systems code that, in the eyes of the thing it was written for, nobody wrote.
