Why axiomOS exists
A note on the gap between 'kernel you can extend' and 'kernel you can trust to extend' — and why both should be available at once.
The eBPF runtime in Linux is a quiet revolution: kernel behavior, modifiable from userspace, with safety properties checked statically. Tracing, networking, security policy — fields that used to require kernel modules now ship as bytecode.
But the same revolution is held just out of reach of embedded robotics, because Linux carries the wrong wall-clock baggage. We get the verifier and the runtime, and pay for them with millisecond-class jitter, megabytes of memory, and seconds of boot time we cannot afford.
The thesis behind axiomOS is plain: there is no inherent reason a verifier-and-runtime stack must live on a multi-megabyte general-purpose kernel. The verifier doesn’t care about the kernel’s complexity; it only cares about the program. The runtime doesn’t need POSIX; it needs an interrupt path. So we built the smallest plausible thing that hosts both — bare metal, no_std Rust, with a verifier sitting at the front door.
This is a research kernel. It will not replace Linux, and it isn’t trying to. It is trying to answer a simpler question: can the eBPF idea run on hardware that Linux is too big for?
So far, yes.