The System, Running

Every image on this page is a capture of the real GodspeedOS, booted in QEMU with an emulated framebuffer and photographed straight from the guest's video memory. website/capture/fb_shot.py grabs a single boot frame; website/capture/fb_capture.py drives the shell over the COM1 serial line (where the shell reads input) and screendumps the framebuffer at a chosen state. Nothing here is a mockup.

Boot to steady state

The kernel comes up on all cores, spawns the supervisor directly, and the supervisor wires each service from its name-cap map. Here the USB stack has just enumerated a keyboard end to end, and the shell is ready. Boot output reaches the display through the kernel's own minimal framebuffer blit, which hands the screen to the console service when the kernel grants it the framebuffer at spawn; the serial line keeps the full log either way.

The shell, and exactly what it may do

gsh is not a Unix shell - it is a capability-broker service. It holds a console capability and a handful of others, and it can do precisely what those grant, nothing more. Here it answers date, cores, and uptime, and then caps prints its own capability table: the resource each cap targets and the rights on it (log_write, spawn, console_read, introspect, service_control, and its IPC endpoints). Authority is never ambient or inherited - it is this list, and only this list.

Live introspection: observe

observe is a live, full-screen view of every service the system is running - scheduler slot, name, core, state, memory against its contract limit, restart count, IPC queue depth, CPU share, and uptime. It reads structured per-service state the kernel and supervisor already track; there is no /proc text to parse. This capture is from July 2026, when the system ran eight services, all healthy here; it runs more than twice as many now.

Persistent storage: drives

State that must survive a reboot lives on disk, reached only through the fs service, which reaches the disk only through the block-driver, which alone holds the hardware capability. drives lists the mounted volumes: one GSFS filesystem, 16 MiB, with its free space. Every byte crossed an IPC boundary and a capability check to get there - there is no ambient file access anywhere in the system.

Editing a file: edit

edit is a full-screen, modeless text editor - a title bar with the filename and a dirty mark, the text area, and a status bar showing the two keys you need (Ctrl-S save, Ctrl-Q quit), the column, the byte count, and the edit-buffer fill (buf 106/32768). It opens a file of any size without loading it whole: the original stays on disk, read in fixed windows as you scroll, while edits accumulate in a bounded add-buffer and a save streams the pieces back out. Bounded, no heap, loud when the buffer fills - never a silent truncation.

Scripting: a .gsh script via run

Commands compose into scripts. Here a small script is authored in one line (statements separated by ;), saved as /demo.gsh, and executed with run: the runner echoes each statement, shows its output, and prints a pass/fail summary - run: ran 4, failed 0. This is the same mechanism the shell's own suites use - a .gsh file, run and checked. And like everything else, a script is capability-scoped: run can do only what the shell already holds.

Maximum carnage: chaos max-carnage

This is the fire (Commandment II). chaos max-carnage all-services storms every live service at once - kill-storms, queue floods, system-wide memory pressure, and spawn-storms - for exactly the number of rounds you type (chaos max-carnage all-services 100), or until you press q. Each round picks a random subset of the live services, the shell and the supervisor included, floods each one it can and kills every one it picked. The table counts the punishment each service has taken. This capture is from July 2026, when every round still tore down fs and shell: by round 28 they had been killed 28 times each, the supervisor itself 5 times, the drivers flooded 28 times.

And the line that is the whole point:

kernel: ALIVE

Everything above the kernel dies and is respawned - even the supervisor, which the kernel itself brings back. Only the kernel is unkillable (Commandments II and V). The abort is deliberately a serial-console q, because the storm will kill the keyboard driver too.