ABSD

ABSD — An experimental operating system.

ABSD is a small operating system, written in Rust, built to find out what a system looks like when isolation, authority, and failure are stated explicitly and checked. It boots, runs isolated processes, keeps files across reboots, runs some unmodified Rust programs, and is administered over stock OpenSSH.

Current qualification: single-operator system under QEMU (a machine emulator). It is not production-ready, and no physical hardware is supported.

ABSD was built largely by AI coding agents directed by one developer, and has had no independent human review. How it is developed.

What distinguishes it

Isolation

Every program is a separate process in its own address space, started by spawn; there is no fork. A process can act only on itself and its own children; a few whole-system counts are readable by any process. SSH sessions are separate process trees with private scratch space; they belong to one operator and share that operator's files, so they are not a boundary between users. Design: spawn, not fork.

Explicit authority

A process can touch only what it was handed: handles to kernel objects, each carrying rights that can be dropped and never added. There are no user IDs and no ambient privilege. This is the capability model of earlier systems, not a new invention. Design: handles and rights.

Bounded scheduling and recovery

Bounded here means fixed, stated limits, not timing guarantees: 16 processes in the whole system, four SSH connections by default. Processes are preempted by a timer; a fixed-priority periodic scheduling class exists as an experiment, with no real-time guarantee. On the development line and in the source release (not in the qualified release absd-20261003.1), a failure of the SSH or file server after the system has come up is answered by a whole-machine reset at most three times; the fourth stops the machine and names the reason. That budget is demonstrated by its own test, not by the platform gate. A restart is never counted as a recovery. Design: replacement is not recovery.

Evidence-oriented engineering

Claims on the status, design, hardware, and evidence pages carry a label saying how strongly each is supported, in which environment, and where the claim stops. Failed runs stay on record. How statements are labelled.

A session

An SSH session to the operator image, booted under QEMU from the milestone commits. The output below was captured, not written.

absd$ uname -a
ABSD x86_64 x86_64-unknown-absd pid=5
absd$ man afterboot | head
AFTERBOOT(8)                System Manager's Manual               AFTERBOOT(8)

NAME
       afterboot -- building, booting, and checking the operator image

DESCRIPTION
       This page is for the operator of an ABSD system: how to get the
       operator image, boot it, check it, and look after it, and what it
       cannot do yet.  It describes the qualified system (see intro(1),
       "QUALIFICATION"): a served `net fsd' boot under QEMU, whose file server
absd$ ps
session 1 (this session), terminal, connected 2 s
  PID PROGRAM
    4 /bin/absd-sh
other holders: input 0, file server channels 0
absd$ cd /home/operator
absd$ echo hello > notes.txt
absd$ cat notes.txt
hello
absd$ shutdown
ABSD is going down for halt: sessions are told and end, the file server commits and stops, then the machine halts.
absd$ 
sshd: the system is going down for halt; this session ends

Further reading

• About: why ABSD exists, what it is and is not for, how it is developed, and how to follow it.
• Status: what works, what has been qualified and where, what has not, and what the source release establishes.
• Design: spawn instead of fork, handles and rights, and how durability is stated.
• Manual: the 17 pages installed on the operator image, rendered from their mdoc source.
• Hardware: what has been qualified, on what, and how that will be recorded.
• Compatibility: how far unmodified Rust programs get today.
• Research program: the question ABSD tests, the method, and prior work it builds on.