RamenOS

An OS that can change in pieces

A new network driver should not require a new desktop. An application should be able to explain the resources it needs before it runs. A failed service should have a defined recovery path. RamenOS brings those questions into the design of an everyday operating system for people and agents.

The intended users include someone editing a document, a developer adapting a driver to a new machine, and an agent working on one authorized task. Human interactions must remain useful without a model. The current pre-alpha is a place to develop and test these interfaces, rather than an everyday desktop to install.

OS Core, Foundry, and Store

• OS Core supplies kernel mechanisms, services, and runtimes. Typed messages describe operations; capabilities grant particular authority; shared memory carries bulk data. Brokers decide grants while the kernel checks selected fast paths.
• Foundry is the development and qualification workshop: contract checks, negative tests, trace replay, QEMU runs, and eventually physical-device tests. A replay result and a result on real hardware answer different questions.
• Store is the planned route to discover software, preview its permissions, activate it, and move useful compatibility software toward native interfaces. The existing host Store already handles artifacts and ownership; the complete distribution and launch experience remains work.

Typed boundaries make dependencies explicit enough to test. Message types alone do not establish behavioral compatibility, security, failure containment, or a working driver. Recovery also depends on implementation and, for hardware, real device reset and memory-access boundaries.

Why independent evolution matters

Imagine editing a document while a better driver is qualified for your network device. The goal is to check and activate that driver against a bounded contract, keep the editing task intact, and recover if the replacement fails. A supported change might still require a service interruption or reboot. This is an illustrative destination, not a replacement cycle RamenOS has already demonstrated.

Hardware adaptation needs more than an interface definition. Foundry’s driver work uses reference behavior and recorded network/block-device traffic to develop a candidate, then requires checks at the actual device boundary. The existing virtio replay and emulator work prepares that loop; it does not qualify a physical machine.

What works today

• QEMU: x86_64 and aarch64 boot, typed IPC, capability checks, shared memory, and tracing on selected target paths.
• Scripted host repair: read a scoped configuration, stage an immutable repair, run a pinned WASM validator, commit the artifact, deny an unrelated resource read, and recover the original receipt after restart.
• Human host task: a default-off, trusted in-process editor consumes logical keyboard input, renders offscreen, and saves through the host Store. The October 8 status records unresolved ownership, focus, and timeout defects; the original passing scenarios did not cover them.
• Driver development: virtio network/block replay and harness transfers, with physical qualification still pending.

The retained repair report shows a configuration changing from enabled: false to enabled: true, while resource 999 stays denied. Its journal retains the transactions. The October 4 provenance record identifies a dirty development worktree and exact artifact hashes. These are project-recorded host results; this website has not rerun the OS task.

The figure above preserves the earlier September 17 CI results, exact log lines, and capture metadata. It is a dated component observation, not the current task proof.

The next boundary

The real editor process, authenticated process transport, target execution, and target persistence are the next integration boundaries after the host reliability repairs. Wasmtime and key services still run on the host; routing work to execution services is simulated, some snapshot metadata is placeholder data, and the kernel’s capability-table use after transition to multiple processors is deliberately blocked.

Current evidence comes from host components and QEMU; physical-hardware validation is still pending. A complete controlled model comparison is also unfinished. The proposed Linux shell / Linux typed / RamenOS typed study separates structured interaction from service-design effects; host results cannot establish an advantage from the RamenOS kernel.

Read the pinned Vision for the destination, Current Status for its limits, and Getting Started to choose a component to run.