ABSD – An Experimental Operating System

Developer preview absd-preview-rc1 of ABSD, a research operating system written in Rust that boots under QEMU on a Linux x86-64 host, has been published as a binary preview alongside source release absd-preview-20261010 dated 2026-10-10. ABSD replaces fork with spawn-based process isolation, uses capability handles with droppable rights instead of user IDs, caps the system at 16 processes and four SSH connections by default, and resets the whole machine at most three times after an SSH or file server failure before stopping and naming the reason. The project states it was built largely by AI coding agents directed by one developer with no independent human review, is qualified only as a single-operator system under QEMU, and supports no physical hardware.

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 https://absd.dev/about/ how . 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 https://absd.dev/about/ says what it is for; below distinct is what distinguishes it. - What you can run today - Binary developer preview absd-preview-rc1 state published : what works, what does not, and how to try it https://absd.dev/try/ on a Linux x86-64 host with QEMU, with no build tools. To build from source instead, follow the source release's README https://github.com/unpingable/absd/blob/absd-preview-20261010/README.md build-boot-test ; status https://absd.dev/status/ source says what each does and does not show. - Where the source is - github.com/unpingable/absd https://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 https://absd.dev/design/ spawn . - 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 https://absd.dev/design/ handles . - 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 https://absd.dev/design/ replacement . - 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 https://absd.dev/status/ labels . 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. See status https://absd.dev/status/ since . - 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 https://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. See status https://absd.dev/status/ source . - 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 https://absd.dev/about/ how . Details, limits, and what is deliberately absent: status https://absd.dev/status/ . The recorded qualification runs: evidence https://absd.dev/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.