What works
What SlopOS can do today, in QEMU and on one real laptop.
SlopOS boots, runs a desktop, keeps your files across reboots and crashes, talks to the network, and in QEMU builds and installs a new version of itself. This page says what works today, area by area, with a link to the page that explains each part. The gaps are on Known limitations, and work that is only planned is on the Roadmap.
Where it runs
QEMU is the main platform: every test runs there, on an emulated PC with UEFI firmware, NVMe and virtio disks, a virtio network card and a virtio display. One real machine, a Lenovo laptop, boots the live ISO from a USB stick and runs the desktop from memory. Our Intel Xe display driver draws the screen, and the keyboard and touchpad are found by reading the firmware's own description of the hardware. See Hardware for exactly what works on it.
The kernel
The kernel runs on all CPUs at once and switches between programs on a timer,
so one busy program cannot freeze the rest
(Scheduling and waiting).
Programs run in the processor's restricted mode and reach the kernel only
through system calls (User mode and kernel mode).
Those calls use Linux's numbers and calling convention, so ported C and Rust
code finds the calls it expects; a call SlopOS lacks fails with ENOSYS
(System calls).
Processes work the way a Unix programmer expects: fork, exec, shell
scripts with #!, process groups, job control and the full set of signals
(Processes and signals). Memory is handed out
lazily and shared copy-on-write after fork, and files can be mapped into
memory (Memory). Each process has limits on what
it can hold, and when memory runs out the kernel kills the largest process
rather than whichever one happened to ask last
(Resource limits). Privileged
system calls, such as rebooting or mounting a disk, require a named
permission that a program receives when it starts
(Permissions).
When the kernel hits a bug, it can often recover from the panic instead of freezing, and a key combination opens a diagnostic console even when the desktop is stuck (Diagnosing the kernel).
Disks and files
The kernel drives NVMe and virtio disks and reads their partition tables (Disks). The root filesystem is ext4, the same on-disk format Linux uses, and it lives on a disk, so files survive a reboot (Filesystem). A journal lets the filesystem come back intact after a crash or power loss (Crash recovery). The system is installed into one of two boot slots, so a new version that fails to boot falls back to the one that worked. The boot slots live on a partition of their own and the boot loader in its own folder on the EFI system partition, so the layout can share a disk with another operating system (Installing a system).
Network
The network stack speaks IPv4, TCP, UDP, DHCP and DNS over the virtio network
card, and Unix sockets connect local programs. An in-tree TLS 1.3 client lets
curl fetch pages over HTTPS and git clone from GitHub
(Networking).
Programs and the desktop
SlopOS has its own C library with a dynamic loader, a C++ standard library,
a POSIX shell and a multi-call coreutils with the everyday tools (ls,
grep, sed, find, tar and the rest) (Userland).
The desktop has a compositor, terminal, text editor, file manager, image
viewer and system monitor (Desktop and windowing).
Building itself
The development machine carries rustc, cargo, clang, lld, git, bash, CMake and Ninja. Inside it, SlopOS pulls new commits over git, builds its kernel, programs and system image, installs them into the spare boot slot, boots into them and pushes commits back (Development machine). The compilers themselves are still built on the host (Toolchain).
How it is checked
More than 3,500 tests boot the kernel in QEMU, beside host-side unit tests
(Write tests). All unsafe Rust in the
kernel sits in one crate, which build gates enforce
(The framekernel), and machine-checked
proofs cover selected parts of it (Proofs).
Summary
| Area | Works today | Read more |
|---|---|---|
| QEMU | UEFI boot, NVMe, virtio disk, network and display | QEMU options |
| Real hardware | Live ISO on one Lenovo laptop: display, keyboard, touchpad, reset and power-off | Hardware |
| CPUs | All cores, preemptive scheduling | Scheduling and waiting |
| System calls | Linux x86-64 numbering, partial coverage | System call ABI |
| Processes | fork, exec, #! scripts, job control, signals, pidfd | Processes and signals |
| Memory | Demand paging, copy-on-write, mmap, memfd | Memory |
| Limits | Per-process quotas, out-of-memory killer | Resource limits |
| Permissions | Named capabilities, checked on every privileged call | Permissions |
| Async I/O | SlopRing submission and completion rings | SlopRing |
| Disks | NVMe, virtio-blk, GPT partitions | Disks |
| Filesystem | ext4 root with a journal | Filesystem |
| Updates | A/B boot slots with fallback | Installing a system |
| Network | IPv4, TCP, UDP, DHCP, DNS, Unix sockets, TLS 1.3 | Networking |
| Userland | C library, C++ library, shell, coreutils | Userland |
| Desktop | Compositor, terminal, editor, file manager, image viewer, system monitor | Desktop and windowing |
| Self-hosting | Builds and installs itself in QEMU | Development machine |
| Testing | 3,500+ QEMU tests, host unit tests | Write tests |
| Verification | One unsafe crate, gates, Verus proofs, Miri | The framekernel |
Programs on every system image
Every system image carries these programs (listed in scripts/lib/base.sh):
init shell coreutils terminal compositor roulette halt bootctl editor
file_manager image_viewer sysmon nmap ip keymap ss nc curl ping oops_smokeThe test image adds the test programs and the shared libraries they load. To try it yourself, start with the Quickstart.