SchOS/README.md
Nexoniarz d73985633b docs: a branding folder, and the three marks are not interchangeable
Shift is the logo, Guru is the icon, SchCotie is the mascot, and the difference
between them is not stylistic. An icon works once, at one size, in one state. A
mascot has to be able to *do* things -- confused, pleased, asleep, seen from
behind -- which is why it costs more and is drawn last. Written down because
this is exactly the kind of decision that gets re-derived badly.

Assets/ becomes docs/branding/, which also fixes two things:

  * Filenames had spaces in them, so every reference needed quoting. They are
    lowercase and hyphenated now.
  * Assets/ held hand-written SVG and generated PNG in one directory, which is
    the one rule docs/guides/layout.md states.

The guide records what was previously only in people's heads:

  * The constraint everything answers to -- include/logo.h is a 128x128
    single-channel coverage mask, so a mark has to survive as a solid shape in
    one colour and be recognisable at 24 px. Colour is the last decision, never
    the first.
  * Guru's purple is load-bearing. PSOGM_BG #4B1D9A is deliberately not the
    accent #7C5CFF, and theme.h's rule is that the full-bleed purple belongs
    entirely to failure. If Guru appears in accent violet on a sticker, the deep
    purple stops meaning "the machine stopped" -- and it is the only colour in
    the system that means anything.
  * Why shift-mask.svg is a separate file from shift.svg. mklogo.py reads ink as
    (255 - luminance) * alpha, so tones survive as coverage and the relationship
    inverts: darkest here is brightest on screen. Copying the violet fills would
    light the object from below.
  * Why a raster is committed beside its SVG. inkscape is not a build
    prerequisite, so requiring a vector rasteriser would break the build on most
    hosts for a file that changes about once a year.
  * That the BSD daemon is copyrighted and SchCotie must be drawn from the
    concept rather than from Beastie. A daemon is a Greek daimon and a Unix
    background process; neither is ownable. The pitchfork, the sneakers and that
    face are.

Format rule: SVG, or PNG at high resolution with no lossy compression, nothing
else. SVG is the source of truth for every mark and a raster is generated from
it, never edited.

include/logo.h regenerates byte-identical from the new path -- only the source
comment differs. The two old wordmark SVGs were deleted outside this session and
are left deleted; their PNGs are kept as superseded-*.png for reference.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VQ7Qx8E1q1M1bbCq8QLHS2
2026-09-12 18:19:09 +02:00

6.9 KiB
Raw Blame History

SchOS

A 64-bit operating system, written from the metal up.

SMP · copy-on-write filesystem · TCP/IP · PCI, USB and virtio drivers · TrueType text · Linux syscall ABI


SchOS began as xv6 and is now mostly something else. The scheduler, the memory manager and the trap path have been rewritten for x86-64 and for more than one processor; the filesystem has been replaced outright; the syscall table speaks Linux numbering so that real software — musl, toybox, mksh — runs unmodified.

It is a hobby system built by one person, and it is honest about that: what works below has been run, not inferred, and the gaps are listed as plainly as the features.

The pieces

Layer Name What it is
System SchOS The distribution — kernel, userland, tooling
Kernel SchIFT Multi-core x86-64 kernel with a modular VFS
Filesystem SchFS Transactional, copy-on-write, the root filesystem
API SchAPI System programming interface — the stable surface
Compositor SchCom Display compositor (planned)
Window manager SchWM (planned)
Desktop SchDE (planned)

uname -s reports SchIFT, the way every Unix reports its kernel rather than its distribution.

What works

Kernel — Long mode, 4-level paging, preemptive multitasking. SMP: one, two and four processors all boot, with CPU enumeration from the ACPI MADT rather than the 1994 MP table. Memory sized from the E820 map, so it runs in tens of megabytes rather than demanding hundreds.

Filesystem — SchFS is the root: a copy-on-write B-tree with a uberblock ring, so a crash leaves either the old tree or the new one and there is nothing to repair. Free space is derived from the tree rather than stored beside it, which removes a whole class of disagreement. /proc/schfs shows the generation counter advancing as writes commit.

Processes — fork, exec, wait, pipes, signals, sessions and process groups, mmap (anonymous and file-backed), POSIX shared memory, Unix domain sockets, poll.

Devices — PCI enumeration with a bus-agnostic device model at /proc/devices. Drivers for e1000 networking, virtio-gpu and stdvga displays, xHCI USB with HID, hub and mass-storage class drivers, IDE, PS/2, serial. /dev/fb0 speaks the Linux fbdev interface.

Networking — ARP, IPv4, ICMP, UDP, TCP and DHCP, on lwIP behind a driver-agnostic interface class. Verified end to end from the host, both directions, rather than by inspection.

Userland — musl, toybox and mksh, built from source. ls, cat, ps, top, wc, cp, mount and the rest behave the way you expect, because they are the real programs.

Text — a TrueType rasteriser (glyf outlines, composite glyphs, cmap format 4) replacing the 8×16 cell grid. JetBrains Mono for the terminal, Roboto for the desktop layer to come.

When it dies — PSOGM, the Purple Screen of Guru Meditation: stop code, fault address, call chain, and a QR code containing a text copy of the whole report.

Quick start

make          # kernel + UEFI loader + root filesystem
make qemu     # build it and boot it
make iso      # a bootable ISO for VMware or real hardware

Builds on Linux, macOS, FreeBSD/OpenBSD/NetBSD and Windows (Git Bash). The toolchain is clang + lld everywhere — it is a cross-compiler by construction, so one LLVM install targets the bare-metal kernel, the 16-bit boot code and musl userland from any host. See docs/guides/building.md for prerequisites per platform, and docs/history/moving-to-linux.md for moving a checkout between machines.

Testing

Booting to a prompt proves nothing: a filesystem can mount and still fail the first real command, and that has happened here. So the test harness drives the serial console and asserts on what comes back.

tools/windows/bootcheck.ps1            # boot, run real commands, check the answers
tools/windows/bootcheck.ps1 -Tty -Ps   # terminal behaviour, process enumeration
make schfs-check                       # SchFS B-tree, object and image suites

bootcheck is PowerShell because pwsh runs on every supported host.

Layout

kernel/     arch/ core/ dev/ drivers/ fs/ net/ proc/ sys/
  fs/schfs/     the filesystem -- same source the host tools compile
include/    kernel and userland headers
boot/       uefi/ (PE loader)  common/ (shared loader UI)
lib/ cmd/   first-party userland runtime and programs
ports/      third-party software built from source
tools/      windows/ (.ps1)  posix/ (.sh)  python/ (.py)  and .c/.pl
docs/       architecture/ (what it is)  plan/ (what's next)
            guides/ (how to work on it)  history/ (why it's like this)

docs/README.md is the index. If you are reading the tree for the first time, docs/architecture/README.md is the system layer by layer.

One rule worth knowing: the kernel and the host tools compile the same SchFS source. mkschfs cannot disagree with the kernel about the on-disk format, because there is only one implementation — found and fixed on the host, where a test takes a second instead of a boot.

Another: syscalls are declared in exactly one place, kernel/sys/table.inc. Everything else is generated from it.

Not there yet

  • No desktop. Schcom composites and routes input; the plan is now to put it on Wayland and delete the homegrown protocol. See docs/plan/wayland.md.
  • No descriptor passing. No sendmsg/recvmsg, so no SCM_RIGHTS — which is what the GUI work stops at. docs/plan/foundations.md.
  • No dynamic linking. exec handles static ET_EXEC only.
  • No page cache, so writable MAP_SHARED of a file is refused rather than faked.
  • A USB disk cannot be booted from — the root device is compiled in rather than selectable.
  • SchFS has no Linux driver yet; the plan is on-disk format version first, then FUSE, then a kernel module.
  • CFF/OpenType outlines and TrueType hinting are deliberately out of scope.

Licensing

Apache-2.0, copyright Nexoniarz. See LICENSE.

The kernel derives from xv6, which is MIT — see LICENSE.MIT. Third-party code redistributed in a built image (musl, toybox, mksh, the fonts) keeps its own licence; NOTICE carries the attributions.

Drivers may be adapted from BSD sources, which are compatible. Linux drivers are not: GPL-2.0-only and Apache-2.0 cannot be combined and redistributed. Reading Linux to understand hardware is fine; translating a driver is not. Best of all is the public specification — xHCI, virtio, AHCI, e1000 — which carries no licence on what you write from it.


Built with stubbornness and a serial console.