Ferrix GitHub

Ferrix · an experimental Rust OS

Linux apps without Linux.

Boot Ferrix in QEMU and run Chrome, rustc, git or curl unchanged on its own Rust kernel. Its disk, network, graphics and input drivers run as separate processes that can restart after a crash.

View the source Build and boot it →

x86-64 · AArch64 · ARMv7-A · MIT licensed

The Ferrix desktop: the hyprix Wayland compositor tiling btop, a zinc terminal and Chrome on rust-lang.org
Ferrix running under KVM on x86-64, with btop, the zinc shell and Chrome open in its Wayland desktop.
3architectures in the boot test
5virtio drivers outside the kernel
249interrupted writes checked on btrfs
Chromerunning as an unmodified Linux program
zinc with oh-my-zsh: uname, the ring-3 driver processes, svc, df and curl over HTTPS
The zinc shell, driver processes and a curl request.
Chrome on Ferrix showing Wikipedia's article on Rust
Chrome browsing Wikipedia on Ferrix.
btop monitoring Chrome, the compositor and the user-space drivers
btop showing what's running.

What the boot tests do

These two commands boot Ferrix in QEMU. One checks that rustc can compile and run a program. The other builds a Ferrix image inside Ferrix and boots that image. The output below comes from their serial logs.

cargo xtask test-rustc

The guest reads the rust-lang.org release of rustc and Debian's glibc from btrfs. Compiling hello.rs calls cc, collect2 and rust-lld, with about 350 MiB of shared libraries mapped from disk. The test then runs the program.

  11.41 | FERRIX-BOOT-OK stages 1-12
  12.38 | rustc 1.97.1 (8bab26f4f 2026-07-14)
  12.40 | LLVM version: 22.1.6
  13.28 | cargo 1.97.1 (c980f4866 2026-06-30)
  18.17 | rustc-gate: hello from rustc on Ferrix

cargo xtask test-selfhost

The guest gets the toolchain, this repository and its crates on a btrfs volume. It runs cargo xtask build inside Ferrix, then boots the resulting image.

   5.43 | FERRIX-BOOT-OK stages 1-12
  51.81 |    Compiling ferrix-kernel v0.1.0 (/data/src/kernel)
 106.99 |   image /data/src/build/x86_64/ferrix.img
        |   (63 KiB loader, 76558 KiB kernel, 12187 KiB initramfs)
   5.01 | FERRIX-BOOT-OK stages 1-12
x86_64: Ferrix built its own image, and it booted

The regular boot test checks the memory map against the loader's allocations, exercises the allocators and checks that four processors can reach exactly 100,000 on a shared counter. It also runs a failing case for each check, to make sure the check catches it.

From Rust kernel to desktop

The kernel

UEFI hands off to a Rust kernel without bootstrap assembly. It runs preemptive tasks on multiple processors, uses an EEVDF scheduler and checks that memory is never both writable and executable.

Linux programs, unchanged

Ferrix implements the Linux system-call ABI used by threads, signals, fork, execve and more. Programs can use glibc's dynamic loader. It also runs 32-bit x86 programs.

Drivers in ring 3

devmgr starts the virtio disk, network, graphics, input and console drivers as processes. An IOMMU limits their device access on x86-64 and AArch64. A crashed driver can restart.

btrfs, read and write

The root filesystem is a persistent btrfs volume. A power-failure test kills QEMU during a write, mounts the volume again and checks it with the host's btrfs check. It has run across 249 seeds.

Networking

Inside Ferrix, curl can fetch over HTTPS and git can clone a repository. The network stack includes TCP, UDP, IPv6 and netlink; Ferrix also serves SSH.

A userland of its own

ferrousli is Ferrix's C library, written in Rust. The zinc shell runs oh-my-zsh. There is also an init and service manager, plus the uutils command-line tools.

A desktop

hyprix is Ferrix's Wayland compositor. It reads hyprland.conf, tiles windows and draws through virgl. Chrome can play video with sound on the desktop.

Real hardware

Ferrix has booted from the SD card of an STM32MP157D-DK1 board and on all eight cores of a Pixel 7. Most of the tests run in QEMU, where --accel auto selects KVM, HVF or WHPX.

Who wrote it

Claude sessions write most of the code in separate git worktrees. The project owner sets priorities, a coordinator manages merges, and a certification consultant reviews changes to the kernel core.

Changes have to pass their tests before they land. If a change affects the boot image, it also has to boot on all three architectures. The team has made mistakes, too. After one shared git index silently reverted another session's work, we added a rule to prevent it.

The roadmap shows what is finished, the backlog tracks what is left, and the working rules include the incidents behind them.

  1. First public commit: boot, memory, traps
  2. Ring 3 on three architectures; busybox runs
  3. A ring-3 disk driver behind an IOMMU, and btrfs
  4. Networking, threads, a first pixel on screen
  5. rustc compiles and runs a program
  6. Ferrix builds its own image
  7. Chrome plays video with sound on the desktop

Try it

Install Rust and QEMU first. You can run these commands on Linux, macOS or Windows.

# clone and boot to a shell on the serial console
git clone https://github.com/SetZero/ferrix && cd ferrix
cargo xtask run --arch x86_64

# the Wayland desktop with a terminal
cargo xtask run-compositor

# ...with Chrome, rustc and cargo (fetch them first, see the README)
cargo xtask run-compositor --everything

# run the project checks
cargo xtask check

Quit QEMU with Ctrl-A x. The technical guide covers every flag, the board, and Windows.

Where it's going

Done

The boot test covers stages 0–12 on three architectures. rustc, networking, dynamic linking and the Wayland compositor have their own tests.

In progress

Authentication, process isolation, XWayland and the rest of the desktop work. The first 32-bit pieces needed for Steam are under way.

Further out

Real-time domains, a native GPU driver for bare metal and Steam itself.

Read the full roadmap →

FAQ

Is Ferrix based on Linux?

No. Ferrix has its own Rust kernel, drivers, file systems, C library, shell and compositor. It implements the Linux system-call ABI used by the programs we test, so those binaries can run unchanged. uname -s says Ferrix.

Who writes the code?

Mostly Claude sessions, working in separate git worktrees. The project owner sets priorities and reviews the results. The tests and working rules are in the repository.

Can I use it every day?

No. Ferrix is an experimental system. It runs a desktop, a browser and a compiler, but authentication, namespaces and seccomp are still being written.

How can I help?

Try booting it and file an issue if something fails. You can follow releases on GitHub.