SeaOS — A Pure-Go Operating System
Coral · WrapLinux · the OS for builders
A microkernel-style OS whose entire userland — from PID 1 to the pixel — is written in Go. One binary. Boots on real x86-64 hardware. No C, no libc, no compromise.
Abstract
SeaOS is an operating system whose userland is written entirely in Go with CGO disabled. A single static binary is the init process (PID 1), the service host, the shell, the window manager, the web browser, and the TCP/IP stack. It rides a stock Linux kernel — a model we call WrapLinux — and owns everything above the syscall line: the boot experience, the service model, the network stack, the GUI, and the device's identity.
SeaOS is not another Go web service. It deliberately lives in the part of Go the ecosystem forgot it could reach: pixels, windows, devices, an operating system.
1. Motivation
Own the stack. Modern software is a tower of borrowed parts. SeaOS is an experiment in owning, in one comprehensible language, everything that defines a machine's behavior — talking to the wire byte by byte, drawing every pixel, deciding what the device is.
Go's unlit frontier. Go's center of gravity is servers and infrastructure (Docker, Kubernetes, CLIs, APIs). Almost no one uses Go for graphics or for an operating system. That frontier is nearly empty — and that is exactly where SeaOS plants its flag.
An OS for builders. SeaOS is built for people who want to understand the whole machine. Adding an application is one function and one line; the entire system is one Go program you can hold in your head.
Sovereignty. As governments and organizations move off PROPRIETARY desktops toward Linux for control and independence, "own every line of your device" stops being a hobbyist's value and becomes a buying motive. SeaOS is built for controlled, sovereign devices — not for replacing a consumer desktop.
2. The WrapLinux model
The Go runtime cannot run without an operating system beneath it: it needs OS threads (clone/futex) for its scheduler, memory (mmap) for its allocator, and signals for preemption. "Bare-metal Go" projects (TamaGo, GopherOS) must re-implement that contract; GopherOS stalled, TamaGo stays at security-firmware scale.
SeaOS takes the other shape: keep a real kernel, write the userland in Go.
- Linux is a chosen substrate, not a temporary borrow. Writing one's own kernel — drivers for every NIC, GPU, USB controller, and storage device, plus ACPI and power management — is the graveyard of OS projects. SeaOS treats Linux as a hardware abstraction layer (the world's most thorough one) and is final on this choice: bare-metal Go is explicitly out of scope.
- Android and ChromeOS prove the model: ride Linux, own the experience.
- Coral is SeaOS's conceptual frame above the kernel: a small object model (handles, channels/ports, VMOs, a syscall dispatch table) under which services run as isolated processes — a microkernel shape on a monolithic substrate. Honestly: that object model is a Go-level abstraction — a microkernel-style API simulated in Go, not a second kernel; real hardware syscalls go to Linux. The service isolation, by contrast, is real — they are separate OS processes.
(See ADR-0001.)
3. Architecture
┌─────────────────────────────────────────────┐
│ apps (Editor, Sonar, Git, Monitor, games…) │ ← a Go func → a window
├─────────────────────────────────────────────┤
│ shell · window manager · GUI · login │
├─────────────────────────────────────────────┤
│ svc services (multiserver, own processes) │ devmgr, netstack,
│ ↕ Unix-socket IPC · supervisor restart │ httpd, pkgmgr, crond…
├─────────────────────────────────────────────┤
│ Coral (object model · syscall dispatch)│
├─────────────────────────────────────────────┤
│ Linux kernel (drivers, hardware, syscalls) │ ← the substrate
└─────────────────────────────────────────────┘
SeaOS = everything above the syscall line
Multiserver. Isolatable services re-exec the same binary with a service flag and serve a Unix-domain socket (framed messages); a supervisor restarts crashes; a parent router lets services call siblings. Services are real, separate OS processes — not one heap. (ADR-0002.)
Boot flow. PID 1 → mount virtual filesystems → resolve the boot profile (live-USB / installed-disk / dev-host) → start the service host and services → launch daemons → bring up networking → paint the boot splash → hand the framebuffer to the GUI login.
4. Subsystems
Network — own the wire. SeaOS includes a TCP/IP stack written from scratch in
pure Go: Ethernet, ARP, IPv4, ICMP, TCP (passive and active open, with
retransmission), UDP, and DNS — byte for byte on the wire, over a TAP device — plus
a pure-Go DHCP client that addresses eth0 at boot. It does not borrow the
kernel's sockets. (Run on a Linux test host the stack reached the public
internet — DNS resolution to 8.8.8.8, confirmed with packet capture. Inside
QEMU the stack initializes and addresses its interface; "SeaOS networking on
real hardware" is not yet verified.)
Graphics — Go where Go rarely goes. SeaOS draws directly to the framebuffer
(/dev/fb0): a hand-written bitmap font rasterizer, a window manager with a
keyboard- and pointer-drivable desktop, a compositor, a boot splash, and Sonar
— a GUI web browser that fetches and renders live pages. All in pure Go, at the
OS level, where the Go community almost never ventures.
Apps are functions. An application is a Go function returning a window:
func newHello() *wm.Window {
return &wm.Window{X: 240, Y: 170, W: 380, H: 220, Title: "hello",
Draw: func(c *wm.Canvas) {
c.Fill(framebuffer.RGB(0x14, 0x1d, 0x2a))
c.Text(24, 30, "Hello, SeaOS!", framebuffer.RGB(0xe8,0xee,0xf4), 3)
}}
}
// register: m.AddApp("Hello", "my first app", newHello)
One factory plus one registration line and the icon appears in the launcher.
Apps run in-process, so the entire Go standard library is available to them —
net/http, crypto, encoding/json, and more. (ADR-0003.)
Identity — the device is the disk. A SeaOS machine's identity is anchored to
its GPT disk GUID (rendered as SEA-XXXXXXXX), read directly from the
partition table. Unlike a MAC (which changes with the NIC) or a chassis serial
(often empty in VMs), the disk is the thing that is the installed system. The
owner account binds to it. (ADR-0005.)
Persistence & install. A pure-Go GPT and FAT32 writer lays down a bootable
disk (an EFI System Partition plus a SeaOSData partition). A full-disk install
copies the system and the owner's state; booting from the installed disk reports
the installed-disk profile and restores filesystem and users. (ADR-0004.)
Remote access. A pure-Go SSH server (built on golang.org/x/crypto/ssh)
authenticates against the same account system as the GUI login and gives a real
SeaOS shell over the network — interactive or exec mode.
5. Design record
SeaOS keeps Architecture Decision Records:
- ADR-0001 — WrapLinux: a pure-Go userland on a stock Linux kernel (final).
- ADR-0002 — Multiserver: services as separate processes.
- ADR-0003 — GUI apps are functions.
- ADR-0004 — Full-disk install.
- ADR-0005 — Device identity from the disk GUID (accepted).
6. Status & honesty
SeaOS values calibration: claims must match evidence.
- Verified in QEMU (full-system): ISO boot to the menu; the GUI login
rendering and a keyboard/
rootlogin reaching the desktop; a full-disk install and then booting from the installed disk with restored state and a disk-GUID identity (SEA-XXXXXXXX); services running as separate processes (multiserver); the boot splash. - Verified separately (not on SeaOS-on-metal): the from-scratch TCP/IP stack reaching the public internet — DNS to 8.8.8.8, packet-captured — when run on a Linux test host.
- Starts, but not end-to-end verified here: the SSH daemon binds and listens; a full remote-login round-trip is untested in this record.
- On physical hardware: to date, only that the framebuffer login screen renders (photographed). Networking, persistence, touch, install, and the rest are not yet verified on real metal — honest, pending work, not a claim.
- Maturity: a young, single-author project. Not production. No users yet.
What is real is real; what is unproven is named as such.
7. Who it is for
- Sovereign / single-purpose devices ("SeaBox"): kiosks, terminals, network and industrial appliances — anything that should boot into one controlled application on hardware whose every line you own. This includes industrial HMI panels (operator screens on factory lines, cabinets, and vehicles); see docs/commercial/industrial-hmi.md. This is the natural fit: you ship a device, and SeaOS is the moat, not the product on a shelf.
- Builders: people who want the whole stack in one language they can read.
- Not a desktop OS competing with Windows/macOS/Linux desktops for consumers.
8. Open frontiers
Anti-aliased vector text (golang.org/x/image), an on-screen keyboard for touch,
TCP congestion control and window scaling, a graphical install chooser, real
metal verification of the full stack, a per-device cryptographic keypair, and a
developer community around the simplest app model in any OS.
There is a great deal of Go that has never had its chance to shine. SeaOS is a stage for it.
SeaOS · built in Go · no C, no libc, no compromise. 🌊🐧