cb3d28e3d6
README: rewritten around what runs (Linux software, Xorg, apk, Linux's drivers), the honest gaps, measured numbers. plan/: 1.0.md is the finish line, where each clause of the acceptance test stands, and the register (one failing clause: a root that survives a reboot); built plans (foundations, hybrid, alpine, xorg) and the decided-against one (wayland) are gone, their content lives in architecture/; roadmap.md is only what is still open. guides: building/layout/testing/adding-a-driver (Linux code may be used). history: four entries (ls -lR, TLB shootdowns, MDIO 0x02460246, netlink MSG_TRUNC). Website: cards, stack, download page, docs index. Code comments that pointed at deleted plan docs point at the architecture docs. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EVRhxi9zpdW2uDUN4FVcao
59 lines
3.2 KiB
Markdown
59 lines
3.2 KiB
Markdown
# 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. Superseded by Xorg; awaiting deletion (see Status). |
|
|
| `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 have been **deleted**: both held a README and no code, and both
|
|
had said "to be deleted" for long enough to prove that a directory marked for deletion is not deleted by being
|
|
marked. The desktop is Xorg with Window Maker ([`docs/architecture/desktop.md`](../docs/architecture/desktop.md)),
|
|
so the window manager is someone else's and a panel or launcher is an ordinary client.
|
|
|
|
**`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 superseded**: the desktop is
|
|
Xorg on the framebuffer, not a compositor of ours, and nothing speaks Schcom's protocol. It is on the register in
|
|
[`docs/plan/1.0.md`](../docs/plan/1.0.md) as *built and not connected*: delete it, or say what it is for.
|
|
|
|
`schinst/` and `schfs-linux/` are scoped and unstarted, and are **frozen** -- see
|
|
[`docs/plan/1.0.md`](../docs/plan/1.0.md).
|