Why Vibrix exists: building an OS that can leave the machine

Most operating systems assume the computer is the permanent thing. Vibrix starts with the opposite assumption: the system should be able to leave.

The central idea is deceptively simple. Put the operating system, its persistent root, applications, configuration and user data on removable USB storage. Boot that same system on another compatible machine and rediscover the hardware around it. The USB device isn't installation media. It is the Vibrix machine's persistent identity.

Portable is an architectural constraint

This changes what “portable OS” means. A live image that forgets its state is easy by comparison. Vibrix eventually needs to leave UEFI firmware services, reacquire its own USB device through native xHCI and mass-storage drivers, mount its own filesystem, preserve state safely, and avoid treating an internal NVMe or SATA disk as its system target.

That constraint reaches surprisingly deep: boot-device identity, driver discovery, filesystem design, update rollback and flash-write behavior all matter. Hardware has to be rediscovered every boot because yesterday's PCI topology is not today's promise.

Why Rust?

Operating-system code inevitably touches raw pointers, page tables, MMIO, interrupts and DMA. Rust doesn't make those things magically safe. What it can do is make the dangerous boundary visible. Vibrix tries to keep unsafe primitives narrow, document their invariants, and expose safer interfaces above them.

The project is Rust-native from its UEFI loader through the kernel and, eventually, its userspace. That does not mean every data structure or parser must be invented here.

Independent doesn't mean alone

One early Vibrix rule was too restrictive: build practically everything from scratch. We changed it. Community Rust crates are now allowed when their license, provenance, unsafe behavior, transitive dependencies and bare-metal compatibility make sense.

That distinction matters. Vibrix should own its architecture, kernel, ABI and system design. It does not gain independence by rewriting a perfectly good generic crate badly. The dependency gate now checks RustSec advisories and policy, while GitHub Actions are pinned to immutable revisions and updated through reviewable dependency PRs.

Evidence over vibes

The funniest part of an AI-engineered OS project is also the easiest trap: generating a lot of code can look exactly like progress. Vibrix deliberately refuses that equivalence. A roadmap checkbox requires observed behavior on its stated target.

Today the standalone kernel boots after ExitBootServices under QEMU/OVMF. Memory foundations, exception handling, ACPI discovery, PCI enumeration and bounded MCFG-selected ECAM reads have real test evidence. That is meaningful. It is also nowhere near the same thing as a finished portable operating system.

The next human-visible moment

The next milestone I'm excited about is M4.5: the interactive kernel console. Before Ring 3 userspace, VFS and the real Rust shell arrive, Vibrix is aiming for a genuine vibrix> prompt with native keyboard input and diagnostic commands.

It is intentionally temporary architecture. But it changes the feeling of the project. A kernel that prints logs is something you observe. A kernel that accepts a command is something you can begin to use.

Where this experiment goes

The long road is processes, syscalls, VFS, native USB, a persistent filesystem, networking, packages and eventually self-hosting. Some of that will use carefully selected external crates. Some will be Vibrix-specific because the architecture demands it. All of it should remain understandable enough that “AI-built” never becomes an excuse for code nobody can explain.

That's the experiment I find interesting: not whether an AI can emit enough Rust to resemble an OS repository, but whether we can keep turning generated work into tested, documented, composable engineering until the machine actually boots into something useful.