rajamesandClaude Opus 5.5
26c588792e
For Captain Bob to edit into his own voice: the sponsorship pitch and tiers, the first devlog
('Building an OS that keeps its own receipts'), and a 5-7 minute video script with an OBS setup.
Claims limited to what is true today: QEMU on three ISAs, the stick in progress, hardware next.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
3.0 KiB
Devlog #1: Building an OS that keeps its own receipts
Draft (2026-10-28). Captain Bob to edit into his own voice before posting.
I spent a good part of my career validating software for regulated industries. If you've done that work, you know what it's like: a big commercial system, a stack of virtualisation and Windows under it, and months spent producing screenshots and signed test scripts to prove it does what the vendor says. The evidence never existed from the start; you dig it up afterwards.
So I started building an operating system where the evidence comes first.
What StarshipOS is
StarshipOS boots straight from a PC's UEFI firmware. There's no Linux and no libc underneath: the kernel, LithosAnanke, sets up memory, interrupts and devices itself, then hands the machine to StarForth v4, a FORTH engine modelled on Chuck Moore's F18, the tiny stack-machine core of the GreenArrays chips.
FORTH might seem an odd choice in 2026. But a stack machine is small enough to understand completely, and small enough to prove things about. That's the point.
Evidence at every boot
Every time StarshipOS starts, it does three things before it shows a prompt:
- It tests itself. 538 power-on self-tests cover the engine and its FORTH-79 vocabulary.
- It fingerprints itself. Every piece of software is a capsule identified by the hash of its
contents, and the system prints a hash of its whole dictionary. On x86-64, ARM64 and RISC-V,
that hash is identical:
0xfec8c47cfc6f437f. Three different CPUs, one system, provably the same. - It waits for its owner. Without the owner's identity stick plugged in, there's no prompt at
all. With it, you're greeted by name:
[zuse@Hera] ok>.
How it gets built
The development method matters as much as the code. Every change starts with a test that fails. Every decision that deviates from the plan is written down with its reason. And every claim of "it works" is backed by a boot log that's committed to the repository, never just summarised.
Just this week, that habit caught a regression within the hour. A change that put the owner's identity on a single USB stick quietly broke the older v3 system's login: v3 can't read the stick's partition table. The next day's tests found it, it was fixed, and the fix is on the record.
What's next
- This week: the USB stick that boots a real PC, carrying the whole system and its owner's identity on one drive.
- Then: the first boot on real hardware, a small x86 mini PC on my bench.
- November: the engine onto an FPGA board, the first step toward proven cores in silicon.
- Later: an SDK where every program is a "book": plain-English pages saying what it does, the code, the tests, and the proofs, side by side, with each claim marked stated, tested or proven.
If you'd like to follow along or help keep the lights on, there's a sponsorship page [link]. Next devlog: the first boot on real metal, whichever way it goes.
— Captain Bob