59aff881ac
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
3.4 KiB
projects/
Things that run on SchOS rather than things that are SchOS.
Everything above this directory — kernel/, boot/, lib/, cmd/,
include/ — is the operating system: it boots, it owns the hardware, and it
is one program that either works or does not. Everything in here is an
ordinary program that talks to it through syscalls, exactly as toybox does.
The split exists because the alternative gets bad quickly. A compositor, a window manager and a desktop are each larger than the kernel will be for a long time. Grown inside the OS tree they would blur into it: a compositor would start reaching into kernel headers because they are right there, the build would grow a dependency from the kernel to a GUI, and "does SchOS boot" would stop having a clear answer. Keeping them separate forces the boundary to be a real interface — syscalls and protocols — rather than a shared header nobody meant to share.
Concretely, code in here:
- links against the sysroot's libc, never against kernel headers
- talks to the kernel only through syscalls and
/dev - can be built, run and debugged without rebuilding the kernel
- may be split into its own repository later without untangling anything
What lives here
| Directory | What it is |
|---|---|
schcom/ |
SchOS Compositor. v0 runs; the plan is for it to draw the installer, and later a desktop (SchDE) on top. |
schinst/ |
The installer, the installation environment, and .sip tooling. |
schfs-linux/ |
SchFS as a filesystem for Linux. FUSE first, a kernel module later. |
schwm/ and schde/ used to be here and were deleted: both held a README and no code. The window manager
is Schcom's own business now (a compositor is its window manager), and SchDE, a panel, launcher and the rest,
comes back as ordinary clients of Schcom once there is something for them to run on. Until then the desktop is
Xorg with Window Maker (docs/architecture/desktop.md).
schfs-linux/ is written to stand on its own. It does not mention SchOS
anywhere, and that is deliberate rather than an oversight: it is intended to be
the first piece released, and it has to make sense to somebody who has never
heard of the OS it came from — a filesystem is judged as a filesystem. The
connection can be made later, once there is a finished system to connect it to.
Practically, that means anything added there needs its own licence header, its
own README framing, and no cross-references into this tree. It shares the
format with kernel/fs/schfs/, not the prose.
Nothing here is a dependency of the kernel build, and nothing here is pointed at by anything above it.
Status
schcom/ is a compositor v0, 715 lines that run, over a wire format of its own. It is kept, with a job: the
installer's GUI (docs/plan/roadmap.md §5) is its first real client, and if it grows
into something actually useful it becomes SchOS's own desktop, SchDE on top. Everything it was blocked on in the kernel
exists (Unix sockets, descriptor passing, memfd, evdev, framebuffer mmap); what it lacks is a protocol designed for
real clients and the clients themselves.
schinst/ and schfs-linux/ are scoped and unstarted, and are frozen -- see
docs/plan/1.0.md.