Roadmap

This page lists the work we are doing next: running SlopOS on a real laptop the way it already runs in QEMU, developing SlopOS inside SlopOS, faster test results, and USB. For each plan it says what the work is for and how far along it is.

How plans relate to these docs

The source repository keeps its plans in plans/, and a plan only ever describes what is still to do. When part of it lands, that part is removed from the plan, and the docs page for the subsystem is updated to describe how it works. When nothing is left, the plan is deleted; git history keeps the record. So if a feature appears in these docs it exists, and if it appears only in a plan it does not.

Running SlopOS on a real machine

What it is for: doing on the tested laptop what SlopOS already does in QEMU: install it from a USB stick onto a disk shared with another OS, boot it from that disk, build and install new versions there, and exchange commits over the wired network. (plans/bare-metal.md)

Where it stands: three of seven steps are done: the NVMe driver, the ext4 filesystem, and a disk layout that shares a disk with another operating system. SlopOS's boot loader sits in its own folder on the shared EFI system partition, and its two boot slots live on a partition of their own. The QEMU boot-slot tests already run on that layout (Installing a system). Still to do (the network work can happen alongside the rest):

1. A crash record: the panic message written to a small partition set aside for it, so the next boot can show what went wrong.
2. An installer, and a live ISO that can run it.
3. A driver for the laptop's Realtek wired network card, DHCP on every network card, and an SSH client so git can reach another machine on the network.
4. Measuring the CPU's real speed during a build, and turning on frequency scaling if it runs slow.

SlopOS as a development machine

What it is for: making SlopOS a place where SlopOS is developed. (plans/self-hosting.md)

Where it stands: the loop works in QEMU. The guest pulls commits over git, builds the whole system, installs it into a boot slot, and pushes commits back (Development machine). Next is the same loop on real hardware, which is the plan above. After that, possibly, a compiler that rebuilds itself inside SlopOS; that phase is not committed to, because it needs tens of gigabytes and hours of CPU per build.

Faster continuous integration

What it is for: keeping the time from a push to a test result short. (plans/ci-latency.md)

Where it stands: the CI jobs are split so that each finishes in about the time the boot tests take. The remaining work is making the longest job's builds cacheable and cutting the setup every job repeats.

USB

What it is for: USB keyboards and mice, and later USB storage and network adapters, through a driver for the USB host controller (xHCI). (plans/usb-xhci.md)

Where it stands: not started. It is a large piece of work, and it would plug into the existing driver framework as one more kind of bus (Drivers).

Plans that have landed

These plans are finished and deleted. What they built is described here:

The source tree also keeps working notes on open bugs (plans/KNOWN_ISSUES.md). The ones that affect you are on Known limitations. Plans can mention file paths that have since moved, so check a path against the tree before relying on it.