Short notes as things get decided. https://ninelives.getfelix.dev/devlog/ 2026-10-28T00:00:00Z https://ninelives.getfelix.dev/devlog/linux-or-our-own-kernel/ 2026-10-28T00:00:00Z 2026-10-28T00:00:00Z Gabriel Loewen

The first open question, with the case for each side. Nothing is chosen yet.

<p>The first question anyone asks is whether NineLives will have its own kernel. There are good Rust crates now, and booting, paging and a basic scheduler are weeks of work, not years. It isn't decided. I opened <a rel="external" href="https://github.com/GetFelix/ninelives/discussions/22">a discussion</a> to work it out, and this is the short version of both sides.</p> <h2 id="the-case-for-stock-linux">The case for stock Linux</h2> <p>What is new in NineLives sits above the kernel: workloads that survive losing a machine, atomic upgrades, system programs that keep their state in the log. None of that obviously needs a new kernel, and all of it is plenty of work. The first thing I want to see is three VMs, one killed, and nothing lost.</p> <p>The hard part of a kernel is what comes after boot.</p> <ul> <li><strong>Drivers.</strong> NVMe, real network cards, whatever each cloud exposes. Most of Linux is drivers.</li> <li><strong>Storage.</strong> Felix's durability depends on <code>fsync</code>, <code>pread</code> and preallocation behaving exactly as documented. A new kernel would have to earn that trust first.</li> <li><strong>Networking.</strong> Felix runs on tokio and QUIC over UDP. A scratch kernel needs a network stack and a port of that runtime.</li> <li><strong>Security and many cores.</strong> Every fix would be ours to write.</li> </ul> <h2 id="the-case-for-a-kernel-of-our-own">The case for a kernel of our own</h2> <p>A kernel built for NineLives could give a smaller trusted base, deterministic scheduling that makes replay stronger, and syscalls designed around the log. With today's crates, booting, paging and a basic scheduler are weeks of work. And nobody else is building an OS with a replicated log at the center, so there's a real research story. The cost is everything after boot, listed above.</p> <p>There are middle paths. <a rel="external" href="https://github.com/asterinas/asterinas">Asterinas</a> aims to be compatible with Linux at the syscall level, so felixd could run on it unchanged, which makes it an experiment rather than a rewrite. <a rel="external" href="https://github.com/hermit-os/kernel">Hermit</a> is a unikernel, and a node that only runs Felix and felixd could be a single image. <a rel="external" href="https://gitlab.redox-os.org/redox-os/redox">Redox</a> and <a rel="external" href="https://github.com/theseus-os/Theseus">Theseus</a> are worth studying for their ideas on recovery. <a rel="external" href="https://rust-for-linux.com/">Rust for Linux</a> is the route if something ever has to live inside Linux.</p> <h2 id="what-i-don-t-know-yet">What I don't know yet</h2> <ul> <li>Is the first goal a cluster that survives losing a machine, or a kernel designed around the log? The answer probably decides this.</li> <li>Would starting on Linux make it harder to move later, or can felixd lean on so little of the kernel that it doesn't matter?</li> <li>Is Asterinas close enough to Linux that trying it is an experiment rather than a rewrite?</li> <li>Are single-purpose nodes enough, or does every machine need a general-purpose OS?</li> <li>What would we give up in debugging, tooling and hardware support?</li> </ul> <p>If you have a view on any of these, or know a project I missed, <a rel="external" href="https://github.com/GetFelix/ninelives/discussions/22">reply in the discussion</a>.</p>