Small and From-Scratch Operating Systems

SliTaz: "SliTaz GNU/Linux Cooking (55 MB)" (slitaz.org/en/get); Kolibri: "requires only a few megabytes of disk space"; Menuet: "Fits on a single floppy"; Alpine: "a minimal installation to disk requires around 130 MB"; Nishi volume is fixed-size FAT32 -- see the next row for what is actually OS

SliTaz 55 (cooking ISO)KolibriOS a few MBMenuetOS 1.44 (single floppy)SerenityOS n/a not publishedHaiku n/a not publishedAlpine ~130 disk installReactOS n/a not published

Nishi MEASURED: BOOTX64.EFI 1536 B + KERNEL.NXE 5064 B, both read back off the written USB and hash-matched to the build; SliTaz "root filesystem under 100 MB uncompressed"; Alpine "A container requires no more than 8 MB" [alpine-about]. This is the one axis where our number is extraordinary -- and it is small because the app layer is ABSENT, not because we compressed it

SliTaz <100000000 rootfs uncompressedKolibriOS n/a not publishedMenuetOS n/a not publishedSerenityOS n/a not publishedHaiku n/a not publishedAlpine 8000000 min containerReactOS n/a not published

Kolibri publishes "12 MB of RAM" (kolibrios.org/en) [kolibrios]; Nishi MEASURED from the image layout: 26 KB loaded image + 16 KiB memory-map buffer + 10 KiB kernel reserve, framebuffer supplied by firmware GOP; SliTaz does not publish a RAM figure on its site -- the 192-256 MB figure is the operator brief, marked community-cited not vendor-stated

SliTaz ~192-256 community-citedKolibriOS 12MenuetOS n/a not publishedSerenityOS n/a not publishedHaiku n/a not publishedAlpine n/a not publishedReactOS n/a not published

Nishi: zero -- own compiler (nx_cc), own executable format (NXE), own emulator, own FAT32 reader; the ONLY foreign format is the PE32+ header UEFI demands, which is the firmware toll every x86 OS pays; Haiku states "numerous open source projects are utilized ... integrated seamlessly" [haiku-about] [serenityos]

SliTaz Linux kernel + Busybox + Openbox + Midori/FirefoxKolibriOS FASM-built own kernel + driversMenuetOS own asm kernelSerenityOS custom core + some portsHaiku kernel own + "numerous open source projects"Alpine Linux kernel + musl + BusyboxReactOS own reimplementation of Windows

SliTaz: "5000+ packages available via Tazpkg from the mirror" [slitaz-about]; Nishi has NO package manager and no package format -- filed rung

SliTaz 5000+ via TazpkgKolibriOS n/a app bundlesMenuetOS n/a app bundlesSerenityOS own ports treeHaiku own + HaikuDepotAlpine large apk repositoryReactOS n/a

SliTaz: "32-bit and 64-bit (native 64-bit in active development)" + "ARM support - Raspberry Pi edition"; Kolibri "an i586 processor"; Menuet "written completely in 64bit assembly language" with 32-bit variants; Nishi x86-64 UEFI here -- a separate sovereign rv64 lane exists but the two have NOT met (that is the open NishiOS rung) [reactos]

SliTaz 3 (i486, x86_64, ARM)KolibriOS 1 (i586 x86)MenuetOS 2 (32-bit and 64-bit asm)SerenityOS 2 (x86_64, aarch64)Haiku n/a not publishedAlpine multipleReactOS 1 (x86 family)

Nishi: UEFI GOP queried by the loader, 1280x800x4 measured 100 percent of 1,024,000 pixels painted, colour-exact on real OVMF (top bar RGB 46,59,78); Menuet "resolutions up to 1920x1080, 16 million colours" [menuetos]; Alpine is server/container-first, desktop is opt-in

Nishi paints a desktop v0 -- background, top bar, accent, taskbar with start block, one window frame with title and close box, NISHI wordmark -- 57 rect fills, verified identically on our emulator and real TianoCore

SliTaz ships Openbox; ours paints ONE static window frame and has no window manager at all -- the single biggest visual-parity gap. Filed rung

Nishi has NO pointer of any kind: no PS/2 mouse driver, no USB HID. Keyboard only. Filed rung

Nishi drives the 8042 directly post-ExitBootServices (ports 0x60/0x64, reads only); PROVEN on real QEMU 8042: tally rose 0 to 640 to 1280 to 2080 pixels with the firmware gone

Nishi DONE 2026-08-05: the kernel renders arbitrary NUL-terminated ASCII from the sovereign 8x8 font carried as payload DATA, at runtime, with the LINE CHOSEN BY THE MACHINE'S OWN STATE -- the assistant verdict is now written in WORDS, not only colour, because a colour block is legible only to someone holding the source. WITNESSED ON REAL TianoCore: 1281 ink pixels, and the banner reads back off the screendump as NISHI OS 0.1 GPT ESP NXE KERNEL AI: OFF. Non-vacuity: one binary, three states, three DIFFERENT transition counts (4227 OFF / 4255 ON / 4303 REFUSED). The whole font ships, not just the characters these lines use. Honest depth gap: 8x8 bitmap, fixed advance, no anti-aliasing, no wrap or shaping -- the estate's nx_ttf_fontlib has those on other surfaces, not yet on the metal

Nishi PAINTS a taskbar and start block but nothing is clickable or focusable -- pixels, not widgets

SliTaz: "Openbox desktop with homemade SliTaz graphical tools" and a web-based admin panel. Ours: none on metal

SliTaz "Midori and Firefox web browsers, Lynx in text mode"; Kolibri ships a web browser; Menuet an http client. Nishi has a REAL sovereign browser engine (nx_browser_render: CSS cascade, box layout, AA vector text, forms) proven on Linux and native Windows -- but it does NOT run on the NXE kernel. Honest n on this axis, and the single most valuable rung on the board

Nishi: none. Note the substrate is now there -- the loader reads a named file off the ESP through real firmware protocols, so listing and reading files is a shell rung, not a research rung

Kolibri ships a text editor; Menuet an "IDE Editor/Assembler". Ours: none on metal

SliTaz has "300+ standard GNU/Linux commands" via Busybox. Nishi has no shell, no command line, no process model on metal

Kolibri: "over 30 exciting games". Ours: none on metal (the estate has game engines, none on the NXE kernel)

SliTaz Tazpkg, Alpine apk. Nishi: none -- but note our update story is different by construction (see the kernel-as-a-file axis below)

Nishi AS OF 2026-08-05 (FS-1): the image is GPT -- protective MBR (type 0xEE), primary header at LBA 1, 128-entry array, and a BACKUP header + array at the end of the disk, every structure carrying a CRC32 this emitter computes and its own gate recomputes. MBR was the genuinely dated part of our layout and it was OURS to fix (2 TiB cap, no integrity field). VERIFIED THREE WAYS: our emitter gate (sig + header CRC + array CRC + backup + type GUID + a guard that the partition cannot overlap its own backup), real TianoCore booting from it, and Linux sfdisk --verify reporting No errors detected. Disk and partition GUIDs are FIXED, not random, because a random GUID would destroy byte-identical rebuild -- a measured property we defend

Nishi NEW TODAY (N1-full): loader walks LoadedImage to DeviceHandle to SimpleFileSystem to OpenVolume to Open to Read and loads /KERNEL.NXE off the ESP; witnessed on real TianoCore, and our OWN FAT32 reader independently parses the same image (5 of 5 tamper teeth)

Nishi REFUSES writes BY CONSTRUCTION: the loader passes EFI_FILE_MODE_READ only, the emulator refuses a write-mode Open with a named sentinel, and the census gate pins the exact call set. This is a deliberate never-brick posture, but it IS a capability gap versus every rival

Kolibri: "full support for FAT12/16/32 file systems, read-only access to NTFS, exFAT, ISO9660, and Ext2/3/4". Nishi reads FAT32 only, read-only. FAT on the ESP is MANDATED -- UEFI firmware carries a FAT driver and the spec requires the EFI System Partition to be FAT [uefi-spec], so every UEFI OS ships one; that is a boundary toll, not a choice. The real gap is that we have NO filesystem of our own, so FAT32's limits become the OS's limits -- notably a 4 GiB maximum file size, which is a hard ceiling on model weights, plus no journaling and no checksums (our loader's own sum64 exists to compensate). FS-2 = a second partition with a sovereign checksummed filesystem

SliTaz: "Persistent storage via USB or mounted partition". Ours: nothing persists -- no writes at all

SliTaz: "Runs entirely in RAM: eject the CD, the system keeps running". Nishi PARTIAL and untested: after ExitBootServices the kernel touches no storage, so it plausibly survives removal -- but we have NOT run that experiment, so this is a ~ with a filed test, not a Y

Nishi walks PCI config space itself post-ExitBootServices (CONFIG_ADDRESS 0xCF8 write-selector only, CONFIG_DATA 0xCFC read-only) with no firmware and no host OS -- witnessed on real hardware: host bridge VERIFIED, e1000 VERIFIED, unknown devices honestly UNBOUND

Nishi UNIQUE IN THIS FIELD: each registry row carries an op-list PROGRAM (READ/AND/EXPECT/SHR/END) that one unchanging interpreter executes; a new device class is a new ROW. Proven on a real e1000 with a 10-step program including a real BAR check, and the negative control (flip the expectation) MISMATCHes on real silicon. Every rival adds a driver by adding code

Nishi enumerates and VERIFIES an e1000 but cannot talk to it -- no rings, no DMA, no packets. This is the gate on the entire browser arc, and its own never-brick audit

SliTaz "ALSA sound support"; Kolibri drivers for "popular sound ... cards". Ours: none

Nishi is PS/2 only post-firmware; a real USB stack is a filed rung. On machines with no PS/2 emulation our post-EBS keyboard will not work -- stated plainly rather than discovered by a user

Nishi: the compiler (nx_cc), the executable format, the image writer, the FAT reader, the emulator and the kernel are all ours, bits-up. EVIDENCE (MEASURED 2026-08-13): a return-42 static ELF from this toolchain is 188 bytes, which cannot contain a libc; and the compiler self-hosts under nx_cc_equiv_gate at 10/10 plus a self-host stage before any promotion, so bits-up is verified by rebuilding the compiler with itself. Kolibri/Menuet write their own kernels in FASM (a third-party assembler); Haiku states it uses numerous open source projects; the Linux-based rows inherit an enormous foreign base

Nishi kernel is NXE (own format, magic + version + payload sum64). EVIDENCE (WITNESSED on real firmware, and this cell cited none until 2026-08-14): the format is not merely declared -- real TianoCore/OVMF was made to print our literal NXE! refusal when handed an ESP with no kernel file, which only happens if the loader is genuinely parsing and validating our own format rather than deferring to a stock one. PE32+ exists in exactly ONE place -- the 1536-byte firmware shim -- and nothing downstream of it is a foreign format

Nishi: the loader re-derives the payload sum64 and compares the magic-version qword, and a mismatch prints NXE! on the firmware console and HOLDS -- never a blind jump. WITNESSED on real OVMF: an ESP with no kernel file made real firmware print our literal NXE!. Secure Boot is a different thing (chain of trust to firmware keys) and we do not have it -- filed

Nishi: the emitter's own gate pins the EXACT firmware call set -- 8 read-only calls (LocateProtocol, HandleProtocol x2, OpenVolume, Open+Read for the kernel, Open+Read for the optional assistant file), 1 refusal print, 1 jump -- and REFUSES to emit if one more appears. The census walks the sites the emitter RECORDED, not bytes that look like a call: a byte scan false-flagged a lea whose displacement happened to be 255; port I/O is decode-restricted to an audited allow-set; a write-mode file open is impossible by construction. No rival makes a machine-checked claim of this shape

Nishi: rebuilding after a no-op source change produced a byte-identical image sha; the toolchain swap earlier this week left the image sha UNCHANGED. EVIDENCE (MEASURED again 2026-08-14 on a different subject, which is what makes it a property rather than an anecdote): renaming two constants in nx_eqsat.nx changed the source text and the rebuilt binary came back byte-identical at sha 49a74350, 153,520 B. Reproducibility that holds across unrelated organs on unrelated days is the integer-determinism doctrine showing up as an observable, not a build flag. Most distros pursue reproducible builds; ours falls out of integer-only determinism

Nishi runs every rung under real TianoCore/OVMF as an ORACLE ONLY -- never in the product path -- and the pixel census is byte-exact against the sovereign emulator [tianocore-edk2]. Rivals are witnessed by their own user bases, which is a stronger form of the same thing

Nishi PARTIAL, corrected 2026-08-05 after MEASURING it: the loader READS /KERNEL.NXE off the ESP rather than embedding it, so updating the OS is genuinely a file copy and needs no image rebuild and no writer -- but moving to GPT made Windows treat the partition as a protected EFI System Partition, and a normal user now gets Access Denied on the mounted volume (under the old MBR type-0x0C layout it mounted as an ordinary FAT32 drive). FIXED THE SAME SESSION (FS-2b): the image now carries a SECOND partition with the Microsoft basic-data type GUID, which Windows, Linux and macOS all mount as an ordinary drive -- that is where NISHI.AI goes, so the file a user actually swaps needs no elevation anywhere. PROVEN END-TO-END ON REAL TianoCore FROM THE IMAGE: the loader booted from the ESP, enumerated every filesystem via LocateHandleBuffer, found NISHI.AI on partition 2 and ran the assistant on its weights (status ON, swatch 0xFFFFFFEC). Still Part, honestly, for TWO measured reasons: the KERNEL remains on the protected ESP so updating IT needs elevation on Windows, and on a PHYSICAL stick the data partition does not yet mount at all -- writing a fixed-size image to a larger device leaves the backup GPT mid-device instead of at the device's last LBA (measured: 7987200 device sectors vs 135269 image sectors). The image is correct; the WRITE PATH must relocate the backup GPT and rewrite the primary header, the way sgdisk -e does. Filed, not hidden

Nishi: the whole nofloat stack is integer -- deterministic and bit-exact BY CONSTRUCTION. EVIDENCE (MEASURED): the determinism is what makes exact-equality gates expressible at all -- the sibling emulator measures 0 divergences in 500 fuzz vectors against QEMU, and the estate's integer organs assert exact integer equalities rather than tolerance bands. A float stack cannot be tested that way, so the FORM of the tests is itself the evidence. No small-OS rival offers on-device inference at all, so this axis is ours by default and worth exactly what it is: a mechanism, not a product

Nishi PARTIAL: the kernel performs 32 signed multiply-accumulates -- the inner loop of every GEMM in our stack -- with no libc, no allocator, no float, and paints the accumulator as a pixel; expected -26 (0xFFFFFFE6) derived by a separate path and confirmed on BOTH the sovereign emulator and real OVMF. That is a proven MECHANISM and nothing about a real model. As of 2026-08-05 the same primitive also runs on weights READ FROM A FILE ON THE BOOT MEDIUM, verified on the sovereign emulator with an independently derived expected value

Nishi DONE 2026-08-05 and unique in this field. NISHI.AI is the SLOT, not the model: the blob carries the ORIGINAL model name, its ORIGIN URL and licence INSIDE the checksummed region, so provenance cannot be edited without detection and the user can always choose a different model. The loader searches EVERY volume for it (so it lives on the user-writable data partition, not the protected ESP), the kernel validates magic + lane count + sum64 before anything executes, and THE SCREEN NAMES THE MODEL IT LOADED. PROVEN ON REAL TianoCore with two different files and ONE unchanged binary: gemma-3-1b-it-abliterated-v2 renders 897 ink px and computes 0xFFFFFFE6; TinyLlama-1.1B-Chat renders 753 px and computes 0xFFFFFFEC. Swap the file, the words and the answer both change. Honest scope: the payload is still a 32-lane integer dot product, not a language model

Nishi PARTIAL and the MECHANISM is done: THE TOGGLE IS THE FILE -- copy /NISHI.AI onto the stick to enable, delete it to disable, and the kernel paints three DISTINCT states (OFF slate, REFUSED red, ON green) so the machine never claims a capability it does not have. All three refusal reasons (bad magic, wrong lane count, bad checksum) fall back to the built-in vectors, so an unvalidatable blob NEVER reaches the compute. What is still missing is a real MODEL: today the payload is a 32-lane integer dot product, not an assistant, and calling it one would be the lie this matrix exists to prevent. Honest ~ rather than Y. Target tier per the operator brief: 350M-1B class (Granite 350M, TinyLlama, MiniCPM, Gemma-3-1b) quantized to integer weights. Original note follows: honest n for everyone. The Nishi design is a toggle in the desktop shell with an explicit OFF default and a visible state, so the machine never runs a model the user did not ask for -- but neither the toggle nor the model exists yet. Target tier per the operator brief: a 350M-1B class model (Granite 350M, TinyLlama, MiniCPM, Gemma-3-1b class) quantized to integer weights

Nishi: an unknown PCI device paints UNBOUND rather than a false bind, a bad kernel file prints NXE! rather than booting something, and the emulator REFUSES an unmodeled port instead of inventing a value. EVIDENCE (WITNESSED on real firmware, cited here from 2026-08-14): the middle case is not hypothetical -- real TianoCore printed our literal NXE! and HELD rather than jumping. Refusal-over-fabrication is only a virtue if the refusal path has been seen to execute, and this one has, on somebody else's silicon. Refusal-over-fabrication is a design rule here, and it is why this matrix has so many n cells