Abstract—I am an electrical engineer, not a software engineer, who never quite stopped writing software. My working life began at a refinery and a power company and moved into the data center, where I deployed software, kept it running in production and eventually retired it. Since then I have published sixteen open-source repositories under five GitHub accounts, fourteen of them under the MIT licence: an operating system, instruments, file formats and games, running on hardware from a 1984 home computer to an FPGA beamformer.
I. The Pitch
A coding agent can now take a well-described ticket and write the code for it. Mihail Eric, who teaches at Stanford and runs AI work in industry, said as much on Sajjaad Khader's channel: the engineers at risk are the ones who only turn tickets into code. Nobody has ever handed me a ticket. Every project here began with the question of what the problem actually was, and I had to scope it myself, because I was the only stakeholder. I can recommend that stakeholder. He is very understanding about deadlines.
Eric's main advice for staying useful is to become interdisciplinary, and the example he gives is people strong in hardware who combine it with coding agents. That one made me feel seen. My projects usually start at the physics and work up to the code: a Geiger counter's pulses, a camera sensor's exposure, a phased array's beam, the keyboard matrix of an 8-bit chip. I design the measurement, write the software and publish the result where people can read it.
He also describes a job he expects to grow: the engineer who goes on site, hears the customer say a button is broken, and realises they need something else entirely. That describes my career well before agents arrived. Refineries, power plants and data centers don't give you specifications. They give you a plant that has to keep running, and you turn what is happening on the floor into a system that fixes it.
II. Problems I Solve
| The problem | What I bring | Shown in |
|---|---|---|
| A machine must keep its state, or a fleet must stay observable | An operating system built from a reproducible installer, then the console and the task manager the fleet needed | Copal, Orrery, copal-tm |
| An instrument produces numbers nobody can see | Reading the hardware directly, logging honestly, and publishing a live report | RadBeeper, birdshot |
| Data must survive damage and arrive in order | A file format with Reed–Solomon codes, parity, and checkpoints signed with an SSH key | Static Stream |
| A radio question needs an answer before money is spent | A gated investigation, one question at a time, then a Rust design for the system: LoRa over a 4.9–6.0 GHz phased array with an ECP5 FPGA beamformer | quadrf |
| Players need to share a game with no server in the middle | Clients that find each other on the LAN, measure the links between them, and elect the best-connected host | Treadcore |
| Old hardware and old code are still worth running | Repairing the machine, writing for its 8-bit CPU, and carrying a 1997 game into its third generation | ASCITTY, UR FINKEL, Yodacon, the Plus/4 repair |
| A lot of noise has to become one ranked list | A layered, source-pluggable engine with a single read model | TrendCatcher |
| A website has to work everywhere and ship safely | Plain HTML that reads in Lynx, a stdlib-only generator, a link check, and a key-only deploy that shows its changes first | This site |
III. Résumé
| Refinery | Where my working life began: engineering for a plant that cannot stop. |
|---|---|
| Power company | Electrical engineering at a utility. |
| Data centers | Deploying software applications and managing their lifecycle, from first install to retirement: production operations, keeping a fleet observable and recoverable. |
| Independent work | Sixteen open-source repositories, fifteen websites and a hardware bench. Everything on this site. |
| Languages | Rust, C, C++, Go, Python, JavaScript, POSIX shell, QML |
|---|---|
| Hardware | Raspberry Pi and Compute Module 4, IMX477 camera, GQ GMC-320 Plus Geiger counter, ECP5 FPGA phased-array SDR, Commodore Plus/4 (MOS 7501 and TED), a hand-built PDP-11 simulator |
| Systems | Alpine Linux, Hyprland, UEFI and Raspberry Pi boot, UTM on Apple Silicon, Apache on DreamHost |
| Practice | Makefiles and CI, releases on crates.io, written house rules (AGENTS.md) for coding agents, IEEE-style lab reports |
IV. Curriculum Vitae: the Open-Source Record
- Sixteen public repositories under five GitHub accounts. My personal account, vonglurt, holds ten of them: ASCITTY, birdshot, Codex of Conquest, copal-tm, linux-antiquity, Orrery, quadrf, RadBeeper, Static Stream and UR FINKEL. The projects big enough to need a home of their own have their own organizations: copallinux, yodacon, crabminer and treadcore. I could have kept everything in one place. That would have been far too reasonable.
- Fourteen of the sixteen are under the MIT licence. Take them, ship them, sell them, and keep my name in the file. Gonex and Konex keep the GPL-2.0 licence they inherited from ConEx.
- Over three thousand commits in Rust, C, C++, Go, Python, JavaScript, shell and QML.
- Releases on crates.io: RadBeeper, Static Stream and copal-tm install with
cargo install. - Fifteen websites on their own domains, this one included. Most of the others are small games and simulators.
Every project has a page under Work; the whole list, one line each, is on the text-only page.
V. How I Work
Eric describes the top 1% of engineers as doing three things well. My projects line up with each of them, mostly because I needed to stay sane.
Breaking the problem down. quadrf is a sequence of gated steps, and nothing moves on until the previous question has an answer. Copal is the same idea at a larger scale: a distribution, a console, a task manager and a transport, each built on the one below it.
Switching between agents. His line is that the job becomes being the scrum master of a team of very enthusiastic interns. In October 2026 alone, nine of my repositories got commits, often on the same day. It is less heroic than it sounds. My job is mainly knowing which intern is stuck and what it needs clarified.
Building codebases that agents can work in. Agents do good work in a house that is already built: tests, a reliable build and written-down rules. Thirteen of my repositories have a Makefile, seven run CI on GitHub Actions, and several carry an AGENTS.md that tells an agent the house rules before it touches anything. This site has a pre-commit hook that refuses secrets, and a check that every link and image resolves before anything goes out.
VI. Where the Conversation Goes Next
Open source works better as a conversation than as a monologue. The next step is to give each family of projects a place for that conversation: forums for Copal, for the Yodacon and ConEx line, and for the instruments, where people can bring their own counters, cameras and clusters and argue with me about my choices. If you have used any of this, come and argue. Until then, the issue trackers on GitHub are open.
- github.com/vonglurt: Personal projects
- github.com/copallinux: Copal Linux
- github.com/yodacon: Team Yodacon
- github.com/crabminer: Crabminer
- github.com/treadcore: Treadcore
The career ideas quoted here are Mihail Eric's, from his interview on Sajjaad Khader's channel. The counts are as of October 2026.