What sigilOS Does
A capability-secure OS, written from scratch in Sigil, that scales from a Pi 3 to a workstation.
Not a Linux distribution, not a POSIX clone. sigilOS is built from the compiler up — its own language, its own kernel, its own filesystem, its own desktop. Here's what's inside.
The model: capability security
sigilOS has no ambient authority. Every process, driver, and subsystem is granted exactly the capabilities it declares at startup — and nothing else. A network driver cannot touch the filesystem. A sandboxed browser renderer cannot open raw sockets. A downloaded WASM game cart sees its 64 KB of memory and a granted draw API, and no more.
The confinement boundary is enforced at runtime by the MMU and the capability gate — not by the compiler, not by an ACL, not by a policy file. The compiler helps with contracts and invariants, but the hard boundary is runtime caps plus hardware memory protection. This is structural, not advisory: it's how the OS is built, top to bottom. Even the brokered session token never crosses the EL0 boundary — the kernel injects it on each tag-query syscall, so userland never holds it.
The Four Pillars
Every design decision is held against all four simultaneously — they show up in code review, in architectural rulings, and in how features are scoped.
GPU-first rendering with a SIMD present path (SSE2/AVX2 on x86, NEON on ARM). Software-2D fallback is the Pi-3 floor, never the ceiling.
Runs in the Pi 3's 1 GB. Content-addressed storage deduplicates. Every feature tiers by hardware capability.
Capability security end to end. No ambient authority. Untrusted code is confined by caps + the MMU, not trusted by default.
Reproducible builds from a committed seed. Real-metal proof as a release gate, not just emulator green.
Core capabilities
Real TLS 1.3 LIVE
A complete TLS 1.3 handshake in Sigil: ClientHello → ServerHello → certificate chain → key exchange → encrypted application data. The crypto suite — TLS 1.3 key schedule, X.509 parsing, and certificate verification for ed25519, RSA, and ECDSA-P256 — is its own compiled module, AEAD-verified. HTTPS GET over a Cap<NetConn> works end to end; the network capability is brokered, so an app does the fetch without ever holding a raw socket.
Content-addressed dedup & the CAS filesystem LIVE
The filesystem is built on content-addressed storage: identical data is stored once and referenced by hash. Snapshots are copy-on-write forks; replication is a CAS diff-and-push that no-ops on objects the receiver already has. Defrag compacts dead objects and reclaims B-tree pages. Overlay mounts layer a writable upper over a read-only CAS snapshot. Integrity is HMAC-SHA256 tamper detection over data paths — and AEAD (ChaCha20-Poly1305, memory-hard KDF) encrypts the rootfs transparently at the mount layer.
See the content-addressed dedup mockupSigDB — embedded database LIVE
A SQLite-compatible embedded database engine written in Sigil. Strict types (UUID, TIMESTAMP, BOOL, native JSON), MVCC concurrency, native AEAD encryption, first-class schema versioning, and capability-gated handles. The cc0 compiler owns the SQL parser and emits a typed query plan; SigDB's plan-based executor runs SELECT (point/range), INSERT, UPDATE, and DELETE without re-parsing text. Secondary B-tree indexes are auto-maintained, with WAL checkpointing, vacuum, online backup, and row triggers.
See the SigDB query mockupThe font subsystem 1.0 GATE
An all-Sigil font stack: TrueType/OpenType parsing with composite glyph support (recursive component merge + F2Dot14 scaling, so accented and CJK glyphs render) and full-Unicode cmap format 12 (emoji + supplementary CJK, not just the Basic Multilingual Plane). The rasterizer turns glyph outlines into coverage bitmaps with nonzero-winding fill, bounded so no glyph can stall the renderer. This is the subsystem that put correct, anti-aliased text on the x86 login screen on real hardware.
See the glyph rasterization mockupSmart Folders & the Lumen desktop LIVE
A tag-driven file model with no physical folders — a window is a live tag query, a Smart Folder is a saved one. The Lumen desktop (NeXTSTEP-inspired, dark by default with an LCARS alternate theme) navigates the tag hierarchy through a column browser, manages tags through a tag well, and saves queries to a shelf. All of it wired to live filesystem calls through a dedicated EL0 tag-query syscall seam — with the session token kernel-injected, never EL0-supplied.
See the Lumen desktop mockupThe Lumen look — a coherent design language IN BRING-UP
Lumen has a specified visual language, rendering on metal: an elongated diamond cursor (tilts by handedness, casts a shadow), bordered icon tiles that rise a few pixels off the desktop, press-depress physicality (the cursor tips down like a stylus; the art sinks and the rim casts a shadow into the well), and one lighting model — the geographic sun sets shadow direction by time of day and length by season and latitude, handed at night to a user-placed virtual light. One light governs icons, windows, the cursor, and the login screen alike.
Multi-arch, scale-with-hardware LIVE
One codebase targets AArch64 (Raspberry Pi, Apple Silicon) and x86-64 (any UEFI machine), booting bootable PE32+ binaries on x86. The unified Pi image detects the SoC at boot and scales up from the Pi-3B floor: Pi 4 adds xHCI/HDMI/PCIe, Pi 5 adds RP1/compute — one kernel, one SD card, capability-tiered. The hard floor (Pi 3, 1 GB, software raster) always works; everything above it is additive.
See the scale-with-hardware mockupMore depth: SRDX remote display · Relics & Forge · the Forge toolchain · SWiM — the portable window framework · the development blog. The full milestone spine is in the roadmap, and the metal bring-up story is in the build journal.