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.
Start here #
- What it is
- A research operating system, not a Unix and not a product: no
fork, no user IDs, and existing Unix or Linux software does not run without porting.About says what it is for;below is what distinguishes it. - What you can run today
- Binary developer preview
absd-preview-rc1(statepublished ):what works, what does not, and how to try it on a Linux x86-64 host with QEMU, with no build tools. To build from source instead, follow the source release'sREADME ;status says what each does and does not show. - Where the source is
- github.com/unpingable/absd : the kernel and the platform, under Apache-2.0 for ABSD's own source; third-party material keeps its own licences. Source release
absd-preview-20261010, 2026-10-10.
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 .
Status #
- Milestone
- General usability under QEMU, 2026-09-27 MILESTONE-QUALIFIED
- Runs on
- QEMU, x86-64, one CPU, e1000 network and IDE disk models MILESTONE-QUALIFIED
- Physical hardware
- Physical hardware qualification: not yet established PLANNED. First read-only boots on one machine have been observed EXPERIMENTAL-INTEGRATION
- Since the milestone
- Release
absd-20261003.1: the same system under TCG or KVM, with host-staged update and rollback RELEASE-QUALIFIED. Several-CPU scheduling, a 64-bit ARM kernel port, and a boot-time probe that enumerates one USB device on an emulated controller (not USB support, not merged), each in virtual machines only and as research VALIDATED. A seven-day unattended observation of a development build ran from 2026-10-10 to 2026-10-17 and passed: 2017 of 2017 five-minute rounds succeeded in one boot, on one emulated guest (TCG, one CPU) on one host. The tool's own verdict still reads RUNNING because the guest was left running on purpose; the adjudicated verdict is SEVEN_DAY_OBSERVATION_PASSED. It is not evidence about KVM, several CPUs or physical hardware, and publishing the source says nothing about it. Seestatus . - Access
- Stock OpenSSH, public-key login, one operator, several isolated sessions MILESTONE-QUALIFIED
- Userspace
- A small shell, 27 commands, 17 manual pages; 55 Rust programs built reproducibly MILESTONE-QUALIFIED
- Source
- EXPERIMENTAL-INTEGRATION Public at github.com/unpingable/absd , source release
absd-preview-20261010. Preview: built, booted and smoke-tested from a clean clone; the qualification suites have not yet been run on these revisions and are scheduled after 2026-10-17. The milestone and the release above were qualified on earlier revisions, not on this one. Seestatus . - Development
- One developer directs the work; AI coding agents did most of the implementation and the review. No independent human audit has been done. See how it is developed .
Details, limits, and what is deliberately absent: status. The recorded qualification runs: evidence.
A session #
An SSH session to the operator image, booted under QEMU from the milestone commits. The output below was captured, not written.
Further reading #
- [About](https://absd.dev/about/) : why ABSD exists, what it is and is not for, how it is developed, and how to follow it.
- [Status](https://absd.dev/status/) : what works, what has been qualified and where, what has not, and what the[source release](https://absd.dev/status/#source) establishes.
- [Design](https://absd.dev/design/) : spawn instead of fork, handles and rights, and how durability is stated.
- [Manual](https://absd.dev/manual/) : the 17 pages installed on the operator image, rendered from their mdoc source.
- [Hardware](https://absd.dev/hardware/) : what has been qualified, on what, and how that will be recorded.
- [Compatibility](https://absd.dev/compatibility/) : how far unmodified Rust programs get today.
- [Research program](https://absd.dev/research/program/) : the question ABSD tests, the method, and prior work it builds on.