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

docs: 1.0 is reached; Schcom stays; Linux's r8169 set ships

Browse source 
1.0: the acceptance test drops its reboot clause (a live system is the finish line) and passes. Schcom is kept with a
job: the installer's GUI first, SchDE on top later (roadmap section 5). The old 'LDLS ships no Linux code' policy is
gone from ldls/devices/licensing/Makefile/.gitignore/ldlsd; NOTICE records the r8169 modules (GPL-2.0-only) and the
Realtek firmware. The download button points at the v0.1.0 release asset; the stale 64 MB ISO under docs/Website is
removed. mkaroot.sh's -dumbSched comment no longer claims SchOS has no threads.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EVRhxi9zpdW2uDUN4FVcao
This commit is contained in:
Nexoniarz 2026-10-26 08:23:20 +01:00
commit 59aff881ac
21 changed files with 175 additions and 141 deletions
Download patch file Download diff file Expand all files Collapse all files

21
docs/plan/roadmap.md
View file

@ -54,7 +54,24 @@ what is present ([boot.md](../architecture/boot.md)).
- **udev's job** — a uevent socket and `/sys/devices` — so X and others are told about devices instead of being
given a list.
## 5. The installer and `.sip`
## 5. Schcom, the installer, and SchDE
**Schcom** (`projects/schcom/`) is SchOS's own compositor. v0 is 715 lines that composite clients over a wire format of its
own, and everything it was blocked on in the kernel now exists: Unix sockets, descriptor passing, `memfd`, evdev, framebuffer
`mmap`. The plan is in three steps, each useful on its own:
1. **The installer's GUI is Schcom's first real client.** An installer wants a window, a list, a progress bar and a handful of
input events — small enough to be the program that forces Schcom's protocol to be real, and independent of Xorg, which is not in
the installation environment. It needs a wire format for clients that is designed (Wayland-shaped: surfaces, buffers shared by
descriptor, input events), not the v0 one.
2. **If that works, Schcom becomes useful in its own right**: window management as a module of the compositor (a compositor *is*
its window manager), multiple clients with focus and stacking, damage tracking.
3. **SchDE on top of it**: a panel, a launcher, a wallpaper and settings, as ordinary clients — only once there is a Schcom worth
putting them on. Until then the desktop is Xorg with Window Maker ([desktop.md](../architecture/desktop.md)).
Nothing here starts before [1.0.md](1.0.md)'s register is empty.
### The installer and `.sip`
Scoped in [`projects/schinst/README.md`](../../projects/schinst/README.md), which holds the detail. In short:
@ -79,7 +96,7 @@ Open questions, all wanting a decision before code:
now, or not?
- **Can the kernel mount a `.sip` read-only directly?** If it can, the installation environment's root can simply *be* the `.sip`.
The GUI for this is an X client, like everything else on the desktop.
The GUI for this is a Schcom client (above).
## 6. SchFS beyond SchOS