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/schinst
History
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Nexoniarz e04ca28812 Rename Schunix to SchOS; the kernel becomes SchIFT 
Removes the "-unix" element and with it any trademark exposure to The
Open Group.

The split follows the ecosystem layout: SchOS is the system, and the
kernel has its own name. Kernel-identity strings are the only places
that take SchIFT -- uname(2) sysname, /proc/version, and the two licence
sentences that say "kernel" outright. That is what every Unix does here:
`uname -s` on Linux reports the kernel, not the distribution. Everything
a user reads as the product -- panic screen, boot menu, error prefixes,
docs, LICENSE, NOTICE -- is SchOS.

schunix.img is schos.img, the logo assets and the musl TLS patch are
renamed, and __SCHUNIX__ is __SCHOS__ (the define and the patch that
consumes it moved together).

Two things the rename broke, both found by the bootcheck suite:

  - shmtest wrote "SCHUNIX-MMAP-OK" with a hardcoded length of 15 and
    compared it back by hand-counted offsets (m[3]=='U', m[14]=='K').
    The shorter marker left the write running two bytes past the literal
    and the compare reading past the data, failing a file-backed mmap
    that was working correctly. Now written and compared through one
    constant with sizeof.
  - bootcheck asserted a 31-byte file after appending to
    "hello-from-schunix"; the shorter string makes it 29.

Both are the same mistake: a string literal whose length is written out
somewhere else. Full suite green -- base, Tty, Ps, Sock, Fb, Usb, Evdev.
2026-08-09 14:09:59 +02:00
..
README.md Rename Schunix to SchOS; the kernel becomes SchIFT 2026-08-09 14:09:59 +02:00

README.md

schinst — the installer, the installation environment, and .sip

Getting SchOS from an ISO onto a disk.

Three separate things live here:

  1. The installation environment. A SchOS that boots from the ISO into a known state with the installer running instead of a login shell. The ISO already boots to userspace without a hard disk (make iso), so this is a different init and a different root, not a different kernel.
  2. .sip tooling. mksip to capture a tree into a package, and the apply path that unpacks one onto a filesystem.
  3. The installer itself. Partition, make a filesystem, apply the .sip, install the bootloader, reboot.

Status

Not started. .sip needs its format written down before any code exists.

.sip — SchOS Installation Package

The stated model is WIM, the image format Windows PE installs from, and the thing worth copying from WIM is that it is file-based, not block-based.

A block image (.img, .iso) is a byte-for-byte copy of a partition. It can only be applied to a partition of the same size or larger, it carries the free space and the fragmentation of the machine it came from, and two images that share 90% of their files share nothing on disk.

A file-based image stores files and metadata. It can be applied to any filesystem of any size, it carries no free space at all, and identical files across images are stored once.

Sketched structure — one header, one index, one blob store:

  header      magic, version, blob count, index offset, uncompressed size
  index       per file: path, mode, uid/gid, mtime, size, content hash
              (directories and symlinks are index entries with no blob)
  blob store  content-addressed, one entry per distinct hash, compressed

Deduplication falls out of content addressing rather than being a feature: two identical files hash the same and there is only one blob. Most of this already exists. tools/mkschfs.c and tools/mkfs.c both do exactly this dedup, with an (st_dev, st_ino) fast path so a hard link is not hashed twice, and SchFS's B-tree is already content addressed. mksip should share that code rather than reimplement it — that was the reason the dedup was factored the way it was.

Open questions, all of which want deciding before code:

  • Compression. Something with a small decompressor is worth more here than something with a good ratio, because the decompressor has to run in the installation environment.
  • Whether multiple images per .sip (WIM's real trick — install, recovery and boot images sharing one blob store) is worth the complexity now.
  • Whether the kernel can mount a .sip read-only directly. It is close to a filesystem already, and if it can, the installation environment's root can simply be the .sip.