What Rose is
Rose is the kernel, not the operating system. Meridian is the operating system, and it will be assembled from several components built one at a time; Rose is the one at the base. It's written from scratch in Rust and isn't derived from Unix or from Windows NT. As a capability-based microkernel, Rose is the foundation the rest of Meridian stands on, not the whole system.
Capabilities are the core idea. Nothing in Rose has ambient authority the way a Unix process runs as root. A component can only touch what it has been handed, as an unforgeable token, so the line between what code can and can't do is concrete instead of assumed.
Development is QEMU-first. Rose boots under emulation, where the whole thing can be inspected, changed, and reset in seconds; every milestone is then re-checked under hardware virtualization in VirtualBox before it counts as done, which has already caught real bugs the emulator never triggered.
The design bets
- Capabilities, not Unix permissions. Access comes from holding a token, not from who you are. There is no ambient root.
- IPC is the only kernel primitive. No sprawling syscall table. Components talk to the kernel and to each other by passing messages.
- Userspace is a component graph, not a process tree. The system is a set of parts wired together, not a hierarchy of forked processes.
- No POSIX until the native model is proven. If a compatibility layer ever exists, it's a server added later, not the shape of the system.
- Rust throughout. Whole classes of kernel bug, use-after-free and buffer overruns among them, are caught at compile time instead of in a crash log.
Bespoke where it matters, standard where it doesn't
Rose builds original where a piece defines what it is, and takes the standard where a piece is only compliance. The capability model, IPC, and component graph are bespoke, because that's what makes Rose neither Unix nor NT. The boot chain isn't: it uses Limine, because BIOS and UEFI bring-up is a solved problem with no design worth reinventing. The same test gets applied to everything that comes later, from storage to drivers to the interface.
What's running
Rose is early, but it's real code that boots, not a paper design:
- Boots to userspace on QEMU under both BIOS and UEFI, with VirtualBox as a real-hardware second opinion before anything is called done. Boot output now renders on screen through a framebuffer console, not just over serial.
- Memory and CPU foundations: a physical frame allocator, a kernel heap, per-address-space page tables, a full interrupt setup, and a preemptive round-robin scheduler that keeps every task isolated in its own address space.
- Capabilities work: each task owns a capability space with copy, mint, move, and revoke; revoking cascades through the whole derivation tree. Untyped memory retypes into kernel objects, and all of it is reachable from ring 3.
- IPC is underway: an endpoint object with blocking send and receive, and call and reply on top, so a task can send a message and block for a specific answer. Verified on QEMU and on real hardware.
- Hardware detection has started: read-only PCI enumeration, reading what standard devices report about themselves, so Rose can recognize hardware without vendor-specific drivers.
- The unsafe code gets audited. A focused security pass over the kernel found and fixed real privilege-boundary bugs, a ring-3 escalation among them, before the project moved on; in kernel code a bug can mean a crossed trust boundary, not just a wrong answer.
Still ahead: boot handoff, a real component model, and the adaptation layer below. The foundation is being finished before the house goes up.
Where this is headed
The kernel is the groundwork for the same idea Compass is testing over on Meridian OS, made native. The end state is a system that watches, in real time, how it's actually being used and adapts to the person, instead of making the person adapt to it. On Debian that lives in Compass, an app on top of a generic OS. In Meridian it's meant to be built in, native to the system rather than an app sitting on top.
It carries no commercial cruft: no telemetry, no ads, no forced accounts, none of the weight an OS hauls around for a business model Rose doesn't have. That adaptation layer is deferred on purpose; it needs capabilities, IPC, and a real component graph to observe before it can mean anything, and those are being built first.
Rose is one piece of a much larger build, made from scratch by one person, on its own timeline. Each part is built on its own, then brought together later.
At a glance
- Language
- Rust (no_std, edition 2021)
- Type
- Capability-based microkernel, IPC-first
- Boot
- Limine (BIOS + UEFI)
- Dev & test
- QEMU first, VirtualBox for real-hardware checks
- Stage
- Phase 0, kernel bring-up
Into kernels, Rust, or capability systems? Rose is public on GitHub; the repository has the full picture, and the changelog here carries the highlights.