How it works

From power-on to a
rendered web page.

Every layer here is written in-house. This is the honest version — what exists, how it fits together, and where the hard parts were.

Stage one

Boot

UEFI loads the bootloader

Firmware runs BOOTX64.EFI from the EFI system partition. It reads the memory map, picks a graphics mode, and paints the first splash before the kernel exists.

A/B slot selection

A BOOTSLOT record names the active slot and a trial counter. A slot that never confirms a successful boot is rolled back automatically, so a bad kernel costs one reboot.

The kernel takes over

Long mode, page tables, IDT and the APIC are brought up by hand. Secondary cores are started and parked until the scheduler wants them.

Storage is found, not assumed

USB mass storage, then NVMe, then IDE — the first volume that mounts as FAT becomes the root. The same image boots a USB stick and an internal drive.

Stage two

Running a browser that was never built for you

Chrome expects Linux. Rather than port it, XerisOS answers as Linux at the only boundary that matters — the syscall.

The ELF is unmodified

The same binary a Linux desktop runs. XerisOS maps it, resolves its interpreter, builds the initial stack and auxiliary vector, and enters ring 3.

Threads are real threads

clone creates them, futex blocks and wakes them, and they are scheduled across physical cores — the browser's compositor, IO and worker pools all run concurrently.

Shared memory is really shared

memfd_create plus mmap(MAP_SHARED) hands back pages the kernel and the process both see. Frame buffers are not copied through a pipe.

Descriptors cross the socket

sendmsg with SCM_RIGHTS moves file descriptors between the browser and the compositor, which is how a rendered frame is handed over at all.

InterfaceWhat XerisOS provides
WaylandAn in-kernel compositor: wl_compositor, wl_shm, xdg_shell, pointer, keyboard and axis events
epoll / pollReadiness for pipes, sockets, eventfd and the compositor socket
SocketsTCP and UDP over the in-house network stack, plus a DNS proxy
FilesystemFAT32 and FAT16 with contiguous-run reads and crash-ordered writes
AudioAn ALSA-shaped ioctl surface over the Intel HD Audio driver
Stage three

Hardware, driven directly

No firmware blobs standing in for a driver, and no BIOS calls after boot. Each of these talks to the device the way its specification describes.

Storage

NVMe with its own submission and completion queues, AHCI, legacy ATA with DMA, and USB mass storage over xHCI.

Networking

Intel e1000 and Realtek Ethernet, plus a MediaTek MT7920 Wi-Fi driver with its own firmware upload and MCU handshake.

Audio

Intel HD Audio: codec enumeration, stream descriptors, and a cyclic buffer the mixer writes into.

Graphics

A UEFI-provided linear framebuffer with a double-buffered compositor and damage-tracked blits.

Input

PS/2 keyboard and mouse including the IntelliMouse wheel protocol, with typematic repeat handled in the driver.

Multiprocessor

Secondary cores brought up through the APIC, with the desktop pinned to the boot processor so the UI stays live under load.

Stage four

Ari, and a voice

Inference without a network

Ari's weights load from the boot volume and run on the CPU. There is no account to create, no key to paste, and no request that leaves the machine — because there is no code path that could send one.

Speech from first principles

A formant synthesiser builds speech from phonemes: a glottal source, a cascade of resonators for the vowel tract, a parallel branch for fricatives, and radiation at the lips. Nothing is sampled or streamed.