I’m a software engineer focused on highly scalable infrastructure — decentralized, open source, and built to last.
I co-founded Five Binaries, building products and infrastructure on top of distributed systems.
Outside of engineering, I’m interested in governance models — particularly liquid democracy and how decentralized decision-making can work at scale.
Few days ago I built a CI pipeline that flashes AutoSD onto a Raspberry Pi 4 and tests it on real hardware. It builds the image, flips an SD-Wire mux, power-cycles the board through a smart plug, waits for SSH, and runs a pytest suite — on every push. That was the fun part. This is the sequel, and it has a sillier premise: what if the same pipeline also tested my actual car? ...
This started as a weekend project. I had a Raspberry Pi 4, some spare hardware lying around, and a question: could I set up a fully automated CI pipeline that builds an automotive Linux image and validates it on real hardware — end to end, no manual steps — in a single day? And how many club-mates would it take? The answer is 4, and here’s how it works. The testbench. SD Wire circled at the bottom — this is what lets the runner flash the card without touching it. Shelly Plug S circled at the top — smart outlet for remote power control. AutoSD is the CentOS Automotive SIG’s Linux distribution aimed at in-vehicle software. It’s an ostree-based OS with a real-time kernel, built for the kind of reliability requirements you’d find in a car. I wanted a proper test setup: not just “does it boot”, but a fully automated pipeline that builds the image, flashes it to real hardware, and runs a test suite on every single push — no manual steps, no “works on my machine.” ...
My Raspberry Pi 5 with 16 GB of RAM had been sitting mostly idle for a few months — running the usual homelab suspects, nothing that really pushed it. Then MicroShift caught my eye. A single-binary OpenShift/Kubernetes distro built for edge devices, maintained by Red Hat, targeting exactly the kind of constrained ARM hardware I had on my desk. I decided to give it a proper shot. Why MicroShift I’ve been working with OpenShift professionally for a while, and the appeal of having a real OCP-compatible cluster at home — one that speaks the same APIs, uses the same RBAC model, and supports the same operator patterns — is hard to overstate. Alternatives like k3s or microk8s are fine, but they diverge enough that you’re always translating. MicroShift is a subset, not a fork. Anything I test locally maps directly to what runs in production. ...