RamenOS

A computer that works for you

Your computer should feel like it works for you. RamenOS is building an everyday operating system where tasks are straightforward, mistakes are recoverable, and AI can lend a hand with your permission. You decide what happens; the computer helps you get it done.

The experience we’re working toward is easy to picture:

• Understand what you’re allowing. Know what an app or assistant can see and change before giving it access, and take that permission back when you need to.
• Keep your work recoverable. When something fails, find out what happened to your document and have a clear way to continue.
• Choose how you work. Get help from an AI assistant or do the task yourself. Everyday use should remain useful without AI.

RamenOS is in public pre-alpha. These are the goals guiding development; a complete everyday desktop is still ahead.

Part of Whole Machine Works

Whole Machine Works brings RamenOS and Newcomputer together around a shared ambition: computers that keep improving while people stay in control. Newcomputer explores how software can benefit from new methods and machines while preserving the behavior people rely on. RamenOS brings that research toward everyday tasks. Newcomputer’s research archive is private; its public introduction is on the organization profile.

An OS that can change in pieces

A better network driver should not force you to replace your desktop. A failed service should have a recovery path. RamenOS aims to make individual parts easier to improve, so useful changes bring less disruption to the person using the computer.

Imagine editing a document while a replacement for your network driver is checked. The goal is to keep your work intact through the change and recover if the replacement fails. Some changes may still need an interruption or reboot. This is a scenario to demonstrate, not a replacement cycle RamenOS has already completed.

How the parts fit together

• OS Core runs programs and provides the system services they need.
• Foundry is the workshop for developing components and checking how they behave, including what happens when they fail.
• Store is the planned route to discover software, understand its permissions, and put it to work. Existing host services handle stored artifacts and ownership; the complete distribution and launch experience is still being built.

The design gives each part a clear job and an explicit agreement with the parts around it. Those agreements still need testing in real tasks and on the hardware they are meant to support. The platform overview explains the architecture and its implementation limits.

What works today

The source reviewed on November 4 records these development results:

• Editing and recovery: a scripted editor exercises permission preview, logical keyboard input, offscreen rendering, saving and reopening. Reviewed repairs cover the ownership, focus, timeout and journal-staging defects identified in October, with thirteen added regression checks.
• A task with limited permission: a scripted consumer repairs a configuration, checks it, saves it and recovers the original result after restart. An unrelated read is denied.
• System foundations: selected boot, communication, permission and memory paths run in QEMU on x86_64 and aarch64. Network and block-device development also has replay and emulator checks.

The editor and repair tasks use trusted host fixtures. They do not yet establish a complete target desktop, general process containment, an AI performance advantage or physical-machine readiness. The current status carries the detailed scope and the latest changes.

Earlier observations

The October 8 status snapshot recorded editor defects that were unresolved then. The November 4 source above records the subsequent repairs; the historical snapshot remains available with its original limits.

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 step toward everyday use

The priority is one dependable editing task: launch an editor, understand its permissions, change a document, save it, and recover after a failure. The next step takes the existing editor into a real application process. Then the same task must work on RamenOS with actual input, display and persistent storage, followed by qualification on one reference machine.

Work on AI assistance and replaceable components supports that destination. A controlled AI comparison, physical-hardware validation and a demonstrated component-replacement cycle still need their own evidence. No speed, safety or everyday-readiness advantage is established by the current tests.

Read the Vision or Roadmap for the direction and planned work.