---
name: schunix-roadmap-and-projects
description: "The agreed roadmap through USB, GPU, fonts, network and the GUI; Schcom/SchWM/SchDE and the installer live in projects/, outside the OS tree"
metadata: 
  node_type: memory
  type: project
  originSessionId: a665e14b-86bd-4b41-a228-51377f3e9225
  modified: 2026-08-09T20:20:11.342Z
---

**Set out 2026-08-04.** Recorded in `docs/roadmap.md`; the naming and the
split are Nexoniarz's.

Order asked for: USB → GPU → OTF/TTF → network + sockets → GUI → installer.
Kept, with one dependency fix: shared driver infrastructure came first
([[schunix-driver-infrastructure]]), because it was the first step of USB
rather than a detour from it.

**The GUI stack, all three named by Nexoniarz and all in `projects/`:**

- **Schcom** — Schunix Compositor. Owns the display and input; composites
  client buffers. Policy is *not* its job.
- **SchWM** — window manager, a privileged Schcom client.
- **SchDE** — desktop environment: panel, launcher, settings.
- **schinst** — installer, installation environment, and `.sip` tooling.

`projects/` is at the repo root and is **not part of the kernel build** —
things that run *on* Schunix, not things that *are* Schunix. They link against
the sysroot libc and never against kernel headers. The reason is that each is
larger than the kernel will be for a long time, and grown in-tree the
boundary would blur until "does Schunix boot" stopped having a clear answer.

**The two hard blockers before Schcom can start**, both kernel work:

1. **Unix domain sockets.** `socket()` is still a `NO_LINUX` stub. Needed for
   the client protocol and for `SCM_RIGHTS` — a pipe cannot carry a buffer
   handle. Build these *before* TCP/IP; they are simpler and they are what
   the socket layer's shape should be designed around.
2. **Raw input events** — an evdev-style `/dev/input`. Input only arrives
   cooked through the tty line discipline, line-buffered to one foreground
   process, which is not usable by a compositor.

shm and framebuffer mmap are already done ([[schunix-shm-and-mmap]]).

**`.sip`** = Schunix Installation Package, modelled on WIM: file-based rather
than block-based, so one file holds a whole tree, applies to any partition
size, and dedups across images. Most of it exists — `tools/mkschfs.c` and
`tools/mkfs.c` already do content dedup with an `(st_dev, st_ino)` fast path.
`mksip` should share that code.

## The installer, scoped 2026-08-09

**A live CD is off the list.** The ISO boots a complete system from the
ramdisk, so it already is the live environment; an installer makes a mountable
disc redundant. That drops the ATAPI driver and ISO 9660 filesystem entirely
— see [[schunix-iso-boot]].

Nexoniarz chose the ambitious shape on both open questions:

- **Both firmwares from the start**: GPT with a FAT ESP *and* a SchFS
  partition, bootable on BIOS and UEFI. Needs a FAT writer and GPT code inside
  the OS before anything can be installed at all.
- **`.sip` first**, rather than copying the running root. The installer applies
  a package; `mksip` comes before anything installs.

Dependency chain, each stage separately verifiable:

1. **Raw block device** — *done*, commit 66152ad. `/dev/hda`, `/dev/hdb`,
   major 8, minor = IDE device number. Verified against the host as an
   independent oracle in both directions. **Limit: `devsw` passes the offset as
   a 32-bit `uint`, so a raw disk stops at 4 GB** — widen before installing to
   real hardware.
2. **`.sip` format + `mksip`**, sharing the dedup path in `mkschfs.c`. Test it
   the way the SchFS round-trip is tested: build, apply, `diff -r` against the
   source tree ([[schfs-phase2-mount]]).
3. **In-OS tooling**: GPT writer, FAT ESP writer, native SchFS formatter.
4. **Bootable target**: bootblock + stage2 for BIOS, ESP + BOOTX64.EFI + kernel
   for UEFI.
5. **`schinst`** in `projects/`, driving all of it.

**Confirmed order (2026-08-05):** finish USB, then sockets + raw input, then
virtio-gpu.

**Doom moved (2026-08-05).** It was "explicitly last"; it is now the
**acceptance test** — "an OS that doesn't run Doom is not a real OS".
fbDOOM at that. It is a real load test: framebuffer mmap, raw termios,
file I/O, allocator and timing, all at once. Everything on that list already
exists except possibly `gettimeofday`/`nanosleep` resolution, so **it could
be attempted today** — it needs no sockets, USB, virtio-gpu or fonts.
**It is a test, not a component** — clarified by Nexoniarz: built and run to
prove things work, never shipped in the system. That disposes of licensing
entirely, since nothing is redistributed. Belongs with the test tooling (a
`make doomtest`, same shape as `make crashshot`), not in `cmd/` or the
sysroot. *If* it were ever shipped the licensing returns: engine is GPL-2.0
(fine in `ports/`, never `cmd/`), and the WAD would have to be **Freedoom**
(BSD-3-clause) because `doom1.wad` is not redistributable.

**Sized honestly and not to be underestimated:** OTF/TTF is a rasteriser plus
a variable-width glyph cache, and the console assumes a fixed 8x16 cell grid
throughout — proportional text is a new rendering layer, not a font swap.

**Fonts must be public domain or very permissive** — "PD0", clarified
2026-08-05 (the earlier note read it as "CY-NO", which was never a real
thing). CC0 is ideal; MIT/BSD/Apache fine. SIL OFL is usable but carries a
rename-if-modified obligation, so read it first. A font ships inside every
image, so its licence attaches to the image — see [[schunix-licensing]].

First GPU driver should be **virtio-gpu**, not Intel/AMD: public spec, QEMU
implements it, and it teaches the resource/flush model that a raw framebuffer
never will. Doom stays last. See [[nexoniarz-sharing-preference]].