nexoniarz/SchOS
nexoniarz/SchOS
Watch
1
0
Fork
You've already forked SchOS
 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions
SchOS/.claude/memory/schunix-roadmap-and-projects.md
Nexoniarz 3182da3965 Carry project memory in the repo, with tools/memory-sync.sh 
Claude Code keeps per-project memory at <home>/.claude/projects/<key>/,
where <key> is the project's absolute path with every separator and the
drive colon turned into a dash. That makes it both rename-fragile and
machine-specific, and this project has hit each of those once:

  - D:\DEV\Schunix -> D:\DEV\SchOS changed the key, and 43 memories were
    invisible until moved across by hand.
  - Development happens from Windows and from Linux, and each looks in a
    different place for the same checkout.

Committing .claude/memory/ fixes both -- git carries it across renames
and between hosts -- and `import` puts it wherever the local machine
expects. .claude/settings.local.json stays ignored: those are per-machine
permissions.

The colon maps to a dash rather than being dropped. Deleting it gives
D-DEV-SchOS, which matches nothing and silently finds zero memories; that
was the first attempt. On Git Bash the key comes from `cygpath -w`,
because Claude Code is a Windows program and sees D:\DEV\SchOS, not
/d/DEV/SchOS.
2026-08-09 14:27:22 +02:00

4.2 KiB
Raw Blame History

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

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.

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.