SchOS
A 64-bit operating system written from scratch — its own kernel, its own
filesystem, its own bootloader. It boots on UEFI, drives real hardware,
and runs unmodified musl and toybox on top.
Origin
It started as a teaching kernel and stopped being one
SchOS began as xv6, MIT's teaching operating system: 32-bit, single core, one filesystem, a few dozen syscalls. Almost none of that survives. What follows is what replaced it.
64-bit, and more than one core
Four-level paging, a real SMP bring-up, per-CPU state and a trap path that survives both. This is the part that invalidates most of what a 32-bit uniprocessor kernel assumes.
Its own filesystem
xv6's log-structured filesystem was replaced by SchFS: a copy-on-write B-tree with an uberblock ring, extents and checksummed metadata. A crash leaves either the old tree or the new one.
A Linux-shaped ABI
The syscall table adopted Linux numbering, which is what makes an
unmodified musl and an unmodified toybox run. The table is one
.inc file, and it is the seam the whole system is built around.
Hardware, not emulation
A UEFI loader, xHCI and USB storage, an e1000 with a real TCP/IP stack, virtio-gpu and VBE framebuffers, and a device model where a driver never names its consumer.
Architecture
Two seams hold the whole thing together
Above the syscall table, software is ordinary and portable. Below the device model, a driver never names its consumer and a consumer never names a driver. Everything else is arrangement.
cmd/.inc file — the ABI seamboot/uefi
uname -s reports SchIFT — the kernel — the way every Unix
reports its kernel rather than its distribution.
What it has
Built and running, and honest about the rest
Every card marked runs is in the tree and works today. The tags are not aspirational; the things that are not finished say so.
SchFS
Copy-on-write B-tree, a 128-slot uberblock ring, extents with refcounts and reflink, CRC32c on metadata, and free space derived from the tree rather than stored beside it — so there is no second structure to disagree with the first. There is nothing to repair after a crash.
SMP x86-64 kernel
Four-level paging, multiple cores, preemptive scheduling, a calibrated LAPIC timer, real signal delivery and job control. 205 syscalls on Linux numbering.
Networking
An e1000 driver under lwIP, with sockets for AF_INET, AF_UNIX and
AF_NETLINK. DHCP brings the interface up at boot; ping
reaches the outside world.
UEFI boot
A PE/COFF loader built with clang and lld-link that sets up its own page tables and hands the kernel a framebuffer. No BIOS path, no chainloading.
USB
xHCI, hubs, HID and mass storage — a keyboard and a USB disk that the kernel can mount, through the same device model as everything else.
A real userland
musl and toybox, both unmodified, plus mksh as /bin/sh.
fastfetch builds from upstream source with an empty
patches/ directory — when it could not detect something, the
answer was to give the kernel what it was looking for.
Schcom
The compositor that will own the display. v0 runs. The desktop above it is the next large piece of work, and it is deliberately Wayland-shaped.
SchAPI
The native programming interface — specified, not built, and deliberately so. It should be designed from the compositor's experience rather than before it.
Numbers
The size of it
kernel/ and include/
When it stops
PSOGM
When the kernel panics it does not scroll a stack trace past you. It draws a full-screen report — what failed, where, and the state that mattered — and encodes the whole thing as a QR code so it can leave the machine without being retyped.
This purple is #4B1D9A, and the theme reserves it for exactly
this. Normal states are calm and dark; only failure is loud. It is the one
colour in the system that means something, which is why it appears once on
this page and nowhere else.
Reading
Where to look
The documentation is written to outlive the work. Anything finished is
described in architecture/; anything intended lives in
plan/; and the bugs worth remembering are kept in
history/, in full, including the wrong turns.