Look — I get it. You've seen this before.
Redox. Asterinas. Theseus. Maestro. KataOS. At this point writing a Rust kernel is basically a rite of passage. Half of r/rust has one in a private repo somewhere.
So why another one?
Honestly? It started as a challenge. A way to burn some tokens with AI and see how far I could push it. (It's 2026. Of course AI is helping me build this. I'm not pretending otherwise.)
But I had an idea. And I thought it was simple.
The original pitch to myself
Here's what I was thinking: target VMs only. No bare metal. Why?
Because the hardest part of any OS project is always drivers. Always. It's not the kernel design. It's not the syscalls. It's the 40 years of weird hardware, vendor docs written by someone who hated you personally, and edge cases that only exist because of a decision made in 1987. Target VMs and you get to largely skip that. The hypervisor becomes your hardware abstraction layer. I figured that assumption would pay off.
It did. That one was right. File that under "things that actually went according to plan."
The second idea: since we're targeting VMs, why go backwards? Why implement stuff from 1980 if we don't need to? The goal was to look at Linux ABI — what processes actually need from a kernel, what the contract looks like at the syscall boundary — and only implement what matters for modern software. Post-2020 workloads. Not every quirk that accumulated over 30 years of "we can't break userspace."
For people who don't live in this space: the Linux ABI is the interface between your programs and the kernel. It's how open() becomes a file, how fork() spawns a process, how your program asks the OS for memory. Linux has ~350 of these syscalls. A lot of them are old. A lot of them exist because removing them would break something written before you were born.
I didn't want to implement those. I wanted to implement the ones real software actually uses.
That scoping decision gave me a fighting chance.
And then it started to grow
We started implementing. One syscall, then ten, then fifty. Drivers weren't the problem — I was right about that. But other things were.
And as we kept going… the project became something I wasn't quite expecting when I started.
We'll get to that.
I've written device drivers. C, C++, assembly. This isn't my first time near the metal. But I have gained a very new, very deep respect for Linus and the kernel contributors. The amount of accumulated knowledge, edge cases, and "why does this work like this" baked into Linux is genuinely humbling.
This is the start of a series. Not a launch announcement, not a roadmap. Just the build log from someone who thought this would be simple.
Famous last words.