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

Getting Schunix from an ISO onto a disk.

Three separate things live here:

1. **The installation environment.** A Schunix 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` — Schunix 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`.