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>
59 lines
3.0 KiB
Markdown
59 lines
3.0 KiB
Markdown
# 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:
|
|
|
|
1. **It tests itself.** 538 power-on self-tests cover the engine and its FORTH-79 vocabulary.
|
|
2. **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.
|
|
3. **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
|