What the Shelf of SBCs Actually Builds

A.C. Jokela — Sat, 01 Aug 2026 17:00:00 GMT

A few weeks ago I wrote about turning three idle Arm64 boards into a high-availability k3s cluster, and about the real reason the cluster existed at all: those boards had quietly been compiling native BSD binaries for a couple of projects that care, past all reason, about running on operating systems almost nobody uses. I named the projects in a single sentence and moved on. One was a small programming language. The other, I said, was "a ballistics engine written in Rust with the same ambition."

A few people wrote to ask what that was. This is the answer — and a good excuse to show what the shelf actually builds now that it has grown.

The thing itself

ballistics-engine is an external-ballistics library written in Rust. External ballistics is the physics of a bullet after it leaves the muzzle and before it hits something: gravity pulling it down, air dragging on it, wind pushing it sideways, its own spin steering it in ways that surprise people. Mathematically it is an initial-value problem — you know the bullet's state at the muzzle and you integrate its equations of motion forward through the air — and the engine solves it with a fourth-order Runge–Kutta integrator, the same workhorse method you would reach for to march any well-behaved system of ODEs through time.

The interesting part is not the integrator; it is everything the derivative function has to account for once you want the answer to match reality at eight hundred yards. Real drag is not a constant — it depends on the bullet's speed relative to the speed of sound, and it does something rude right around the transonic region where a supersonic bullet slows back through Mach 1. A spinning bullet does not simply fall; it drifts sideways, because gyroscopic precession tips its nose and the airflow answers. The Earth rotates underneath a shot that spends two full seconds in the air, so the Coriolis effect is real and, at distance, measurable. There is a Magnus force, an aerodynamic jump on the first instant of a crosswind, a slow decay of the spin itself. The engine models these as individually switchable pieces of physics, off by default because most of them matter only when you have already accounted for the ones that matter more.

None of that is behind a wall. The library is on crates.io: cargo add ballistics-engine and it is yours. cargo install ballistics-engine gives you a command-line tool called ballistics that will solve a single trajectory, run a Monte Carlo dispersion, find the sight-in that zeroes your rifle, back out a true muzzle velocity from drops you measured at the range, and build reticle and BDC hold tables for a scope. It compiles to WebAssembly, which is what drives the browser calculators at ballistics.rs. There are Python and Ruby bindings for people who would rather not touch Rust. It is free and open, and if you build something with it I would honestly like to hear about it.

The fleet has a day job, and the fleet has grown

In the cluster post, kubectl get nodes returned three lines — three Arm boards, all of them serving as the control plane, all of them Arm64:

NAME              STATUS   ROLES                VERSION
orangepi5-max     Ready    control-plane,etcd   v1.36.2+k3s1
raspberrypi-cm5   Ready    control-plane,etcd   v1.36.2+k3s1
rpi5              Ready    control-plane,etcd   v1.36.2+k3s1

That was four weeks ago. Here is the same command today:

NAME                STATUS                     ROLES                ARCH
orangepi5-max       Ready                      control-plane,etcd   arm64
raspberrypi-cm5     Ready                      <none>               arm64
rpi5                Ready                      control-plane,etcd   arm64
rpi5-2              Ready                      control-plane,etcd   arm64
nanopct6            Ready                      <none>               arm64
plebian-quartz64b   Ready,SchedulingDisabled   <none>               arm64
bosgame             Ready                      <none>               amd64
fileserver          Ready                      <none>               amd64

The three originals are still there. What joined them tells the story. rpi5-2 is a second Raspberry Pi 5, and it took over an etcd seat: the quorum is still three voting members, but the Compute Module handed its vote to the new Pi and dropped back to being a plain worker, which is exactly the kind of quiet reshuffle a cluster should let you do without ceremony. bosgame and fileserver are amd64 — two x86-64 boxes — so the cluster stopped being an Arm monoculture and became mixed-architecture, which matters more than it sounds like when the whole point is building software for lots of machines. And nanopct6 is one regular readers will recognize, because I reviewed that exact board — the FriendlyELEC NanoPC-T6N — a couple of weeks ago. The review unit did not go back on the shelf. It went into the rack.

Underneath, the storage grew up too. The first cluster leaned on each node's local NVMe: gloriously fast, but it pins a stateful pod to one board, and if that board goes away, so does the pod's data. The cluster now runs Longhorn, which replicates block volumes across nodes, so a volume outlives the machine it happened to be sitting on. It is the difference between "the metrics live on the CM5" and "the metrics live on the cluster."

And what all of this builds, for the ballistics engine specifically, is a thirteen-target release. The current version ships native binaries for Linux on x86-64, Arm64, RISC-V, and 64-bit MIPS; macOS on Intel and Apple Silicon; Windows; and FreeBSD, OpenBSD, and NetBSD, each on both x86-64 and Arm64. That is thirteen distinct platforms, plus a WebAssembly build for the browser.

There is no single machine that can produce all thirteen, which is the whole reason a fleet earns its keep here. The Arm64 BSD binaries are built precisely the way the cluster post described: a privileged pod boots a real FreeBSD, OpenBSD, or NetBSD Arm64 guest under QEMU with KVM acceleration, compiles the engine inside it over SSH, copies the binary out, and powers the guest down — a whole operating system spun up for the length of one build and then gone. Those three Arm64-BSD artifacts even carry a provenance record now, a small signed note of what built them. The x86-64 BSDs are the same trick run against the VMs on the fileserver. RISC-V builds on an actual RISC-V board, because emulating it is slow enough to feel like a penalty. And 64-bit big-endian MIPS — a target the rest of the world has cheerfully forgotten — cross-compiles and then boots just far enough under emulation to prove the binary actually runs. A tag pushed to the release repository sets the whole fan-out going; some time later, thirteen binaries and their checksums are sitting on the release page.

Solving it backwards

Everything above is what I would call forward ballistics: you give the engine a bullet, a velocity, an atmosphere, and a wind, and it tells you where the bullet goes. That is the well-understood direction, the initial-value problem you march forward in time.

It is also not the question anyone actually asks at the loading bench. Nobody stands there wondering, given this precise load, where will it land? They stand there wondering the other way around. I want it to land here — what gets me there? What powder, and how much of it, reaches this velocity? What barrel twist will stabilize this bullet? What overall length should I seat to? What is this bullet's ballistic coefficient, really, derived from its actual dimensions rather than a number on a box?

Those are inverse problems, and inverse problems are the hard, interesting ones, because they rarely have a closed-form answer. You cannot solve them directly; you search — you run the forward model over and over, hunting for the input that produces the output you asked for. The engine has four of them, and they are the four questions above, in order: recommend a powder and charge for a target velocity, recommend an optimal twist rate, recommend a cartridge overall length, and calibrate a ballistic coefficient from a bullet's geometry.

What keeps them honest rather than a plausible-looking toy is the drag model the search leans on. Instead of assuming every bullet behaves like the century-old standard projectile the classic drag tables were built around, the model is calibrated against Doppler-radar-measured drag curves — the actual deceleration of actual bullets, including the transonic region where the simple assumptions fall apart. A backward solver is only as trustworthy as the forward model inside its loop, and this is where that trust has to come from.

The split, stated plainly

So here is the arrangement, and I would rather just tell you than have you reverse-engineer it. The engine is free and open — the library, the command-line tool, the WebAssembly build, the Python and Ruby bindings, the whole forward solver and everything built on it. cargo add ballistics-engine and you can compute trajectories, run Monte Carlo dispersions, true your velocity, and build hold tables until the sun burns out, no account required. That is ballistics.rs.

The four inverse solvers are the one piece I put behind a subscription, Ballistics Insight. They run as a service — in the browser, or from the very same CLI once you have logged in with a token from your account:

ballistics login
ballistics recommend-powder --cartridge "308 Winchester" --bullet-weight 175 --desired-velocity 2600

Why those four and not the rest? Because they are the ones with real ongoing cost behind them — the calibrated data, the compute to run the searches — and because, candidly, someone has to pay for the shelf of single-board computers. If you shoot, it may be worth it to you. If you are here for the build and not the bullets, the engine is free and the fleet does not mind in the least.

One honest word if you do use the powder solver: it gives you a starting point, not a recipe. Every number it hands back is a place to begin working a load up carefully, against published data, over a chronograph, the slow and boring and safe way. The physics is good. The physics is not your reloading manual, and it will not pretend to be.

The cluster post ended on the idea that the capacity had been there all along — it simply had not been told what to do. This is the other half of that thought. Those boards do not only run the fuzzers and hold the metrics and answer the occasional language model. A few times a month, they turn a single git tag into thirteen binaries of a real piece of software, for thirteen kinds of computer, most of which no sane person would build for by hand. That is the day job. The shelf earns its keep.

TinyComputers.io (Posts about mips)

What the Shelf of SBCs Actually Builds

The thing itself

The fleet has a day job, and the fleet has grown

Solving it backwards

The split, stated plainly