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/projects/README.md
Nexoniarz ed81f9a07a Schcom is gone; the desktop path is Xorg now, Wayland groundwork next 
SchOS will not write its own compositor. projects/schcom, its test and its make targets are deleted. roadmap.md section 5 is
now the road to Wayland (udev/eudev, a /sys/devices tree and uevent netlink, libinput and libseat, a DRM device via the GPU
plan) and 5b is the boot manager rework (Niveus/skeuomorphic UEFI GUI). XLibre, Xorg or a Wayland compositor from Alpine,
whichever suits; Xorg for now.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EVRhxi9zpdW2uDUN4FVcao
2026-10-26 09:35:54 +01:00

2.7 KiB
Raw Blame History

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 desktop environment is 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
schinst/ The installer, the installation environment, and .sip tooling.
schfs-linux/ SchFS as a filesystem for Linux. FUSE first, a kernel module later.

schcom/, schwm/ and schde/ used to be here and were deleted: SchOS does not write its own compositor, window manager or desktop. The desktop is Xorg with Window Maker (docs/architecture/desktop.md), and the road to Wayland is Alpine's compositors on top of udev and a DRM device (docs/plan/roadmap.md §5).

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

schinst/ and schfs-linux/ are scoped and unstarted, and are frozen -- see docs/plan/1.0.md.