57aff40228
docs/ was ten files where a plan, a description, a guide and a bug report all
sat next to each other. It is now architecture/ (what SchOS is), plan/ (what it
will be), guides/ (how to work on it) and history/ (why it is like this), with
an index that states the one rule holding it together: when something is
finished it moves from plan/ to architecture/ and is rewritten as a description
of the thing rather than a record of building it.
A ticked checkbox says the work happened. It does not say what the work
*produced*, and six months later the checkbox is all that is left. The network
stack proved the point: finished, verified end to end, and for a month the only
description of it anywhere was a checkbox four levels of indentation deep.
So roadmap.md went from 534 lines to 181 -- nothing deleted, the done work
graduated. Seven subsystems that were finished and undescribed now have
descriptions: boot, kernel, syscalls, filesystem, networking, graphics, usb,
init. Every one ends with "What it does not do", which is the section that pays;
a document listing only strengths is marketing, and the reader who needs it most
is the one about to trip over a limitation nobody wrote down.
schfs.md still opened with "phases 1 through 3 1/2 are done, phase 4 is next"
long after all five had landed. It is a description now, with the phase record
and the hard-won bugs moved to history/.
Three corrections found on the way, all load-bearing:
* projects/schcom/README.md claimed SCM_RIGHTS was done. There is no
sendmsg/recvmsg in the kernel at all, and an entire GUI plan rested on it.
* The root README said "No TCP/IP" months after the stack landed.
* history/kernel.md sec.7 was marked "in progress" on a problem that process
groups solved.
Also adds plan/1.0.md, which draws a finish line so the open list stops being
infinite, and marks schwm/ and schde/ superseded: in Wayland the compositor is
the window manager, so that split dissolves rather than being abandoned.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VQ7Qx8E1q1M1bbCq8QLHS2
2.5 KiB
| name | description | metadata | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| schunix-doom-acceptance-test | The full-stack acceptance test (a ported 1993 shooter) was removed on 2026-08-08 — what it found, why it went, and what to do instead. |
|
Removed 2026-08-08 at Nexoniarz's request ("we don't need it anymore because
we know that doom works"). Do not re-add it, and do not reintroduce the name into
comments — they also asked for trademark words to be cleared from the tree, and
it is now at zero references outside dist/.
Deleted: ports/fbdoom/, tools/doomtest.ps1, tools/doomtest2.ps1, the
doom/doomtest/doom-uninstall Makefile targets, NOTPORTS := fbdoom.
The WADs were moved, not deleted — dist/wads/ — because doom1.wad was a
shareware download that existed nowhere else in the tree, while freedoom1.wad
is recoverable from dist/freedoom-0.13.0.zip.
What it was worth, because the shape is worth repeating. A large program
somebody else wrote, exercising /dev/fb0, evdev, mmap, the ELF loader,
gettimeofday and a fixed-rate tic loop at once, is harsher than any in-house
test because it was not written against our bugs. It found: the
fcntl(F_SETFL, O_NONBLOCK) no-op; the evdev backlog replayed to each new
opener; and the missing EVIOCGRAB. All fixed, all now covered by
tools/bootcheck.ps1 -Evdev / -Sock — which are narrower and do not prove
the whole stack composes. That is the honest cost of the removal.
Why it went beyond being asked: ~100k lines of GPL-2.0 engine on
non-redistributable shareware data, whose safety depended on two separate
opt-outs (NOTPORTS and RAMDISK_EXCLUDE) both staying correct — and the
ramdisk is linked into the kernel binary, so a slip there makes the kernel
undistributable, not just the image. See schunix-ramdisk-root-sizing and
schunix-licensing.
Two techniques from it that transfer:
- Assert on pixels, not log lines. A log-only harness once passed on a blank
screen.
tools/splashshot.ps1counts distinct colours for this reason. - For a crash inside a program you did not write, run
llvm-nmagainst the faultingripto get a function name, then use the fault offset to identify the exact field. "Null pointer plus 24" alone is nearly useless.
Both lessons are written up in docs/plan/roadmap.md Phase 7 and
docs/history/kernel.md §10 and §12, with the program genericised.