Status

ABSD's current qualification is a single-operator system under QEMU. This page lists what that covers, labelled by how strongly each statement is supported. Most of it is the recorded run of the milestone below; work accepted after that milestone is listed separately under since the milestone. Source is currently developed privately, and there is nothing to download.

On this page: since the milestone · labels · works · qualified · not yet qualified · known limits · deliberately absent · deferrals. "Qualified" and "accepted" here mean that recorded checks passed and were re-examined by separate AI model sessions; no independent human has audited the code or the checks (how it is developed).

Since the milestone

Recorded 2026-10-10. Each entry names its own scope; none of it extends the milestone's claims above. Only the first two entries are a release. The rest is development work: none of it has been released, and where an entry says "not merged" the work is on a development branch outside the main line.

• RELEASE-QUALIFIED Release absd-20261003.1 (kernel fcfbab9, platform c54dc90), accepted 2026-10-04. Environment: x86-64 QEMU with TCG or KVM, one CPU, an IDE disk or one NVMe namespace, an e1000 network card. Covered: the whole platform check; files with modification times (filesystem format 2); 300 consecutive SSH sessions returning to the same memory baseline; 87 adversarial program images (60 refused, 27 boundary cases accepted), with resources unchanged after each when run as their own stage (an earlier end-to-end run stopped on a resource-count difference that is not yet explained; see evidence); a scripted check of every kernel-to-process output path for leaked kernel addresses or stale memory (28 checks, none found; side channels not assessed); floating-point control state kept per process.
• RELEASE-QUALIFIED Updating an installed system from the previous release (absd-20261002.3) to absd-20261003.1, and rolling it back, with both installed generations kept and site state preserved; backup and restore of a halted installed image. Updates are staged from a host onto a halted image and take effect at reboot; there is no updater on the running system, and a filesystem format change is refused rather than migrated silently.
• VALIDATED Several CPUs, as research. Under KVM on one development host, with 2, 4, and 6 virtual CPUs: scheduling and migration of processes between CPUs (floating-point state checked between the first two CPUs), device start-up and TCP with the network service on the first CPU, and native command pipelines across CPUs. Each process still runs on at most one CPU at a time; there are no threads; kernel handlers are not preemptible. Throughput scaling was measured and not earned. Running processes on the additional CPUs is switched off in ordinary boots and in every release.
• VALIDATED Misbehaving programs: faults, invalid system-call arguments, exhausted resources, and termination part-way through an operation were contained to the program in every case tried; the kernel, other processes, and the scheduler were unaffected. The cases tried, and what was not tried, are part of the record.
• VALIDATED A 64-bit ARM port of the kernel, under QEMU's virt machine with one, two, or four virtual CPUs: boot, memory management, user processes and their faults, block reads, writes and flushes, local Ethernet, and a workload compared against the x86-64 build. Reviewed and merged on the kernel's main branch 2026-10-05. This is the kernel and its test programs, not the operator system; it has run only as a virtual machine and has not been booted on any physical ARM machine.
• VALIDATED A fixed-priority periodic scheduling class, as an experiment. Its scheduling decisions are checked under QEMU, including KVM; strict timing with another CPU sharing the physical core failed, isolated-core timing is not established, and timing on physical hardware has not been measured. No real-time guarantee is made.
• EXPERIMENTAL-INTEGRATION First native boots on one physical machine, an HP Z2 Mini G3 (2026-10-05 UTC): a read-only image booted from USB under UEFI, ran a hardware survey and the kernel's process suite on the boot CPU, and read one sector from the internal NVMe drive. Disk writes were compiled out. Results were read from photographs of the screen. These are observations, not hardware qualification; see hardware.
• VALIDATED The main development line (kernel 2b4abb4, platform bd99f0fa), which passed the whole platform check under QEMU on 2026-10-10 and is not a release. Beyond release absd-20261003.1 it adds:
  • Block requests of one to eight sectors on the ATA and NVMe models, with the durable-state and filesystem crash matrices rerun over them (the platform check reruns them on ATA; the NVMe reruns were a separate run on 2026-10-08).
  • A boot that finds the network link down comes up degraded and waits, where it used to fail.
  • A recovery budget, in which 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 and the fourth such failure stops the machine with a named reason, the count clearing only after an orderly shutdown or restart (a failure before the system is up still just fails the boot; the budget was qualified by its own run on 2026-10-10 against the previous platform commit, not by the platform check).
  • More of the shell and commands (command lists with ;, && and ||, a system summary command, and ripgrep installed as rg).
  The manual on this site is still the milestone's and does not describe these.
• EXPERIMENTAL-INTEGRATION A seven-day unattended observation of that same build (kernel 2b4abb4, platform bd99f0fa) is in progress: one QEMU guest, TCG, one CPU, probed over SSH every five minutes with file writes and read-backs. It started 2026-10-10 15:22 UTC and is due to end 2026-10-17 15:22 UTC. It has not finished and has no result; nothing is claimed from it. The rules for judging its failures were written down before any failure was observed.
• VALIDATED Further 64-bit ARM work, not merged: the ABSD filesystem running as the first ARM process over a virtio block device, with its flush ordering judged from a log of the virtual device's writes; and support for the GICv3 interrupt controller with one, two, or four virtual CPUs. Run under QEMU's virt machine with TCG, and with hardware virtualization (Apple's Hypervisor framework) on one Mac. The two- and four-CPU GICv3 runs completed in full only under the Hypervisor framework; under TCG the several-CPU test ends in a known memory-ordering test failure that also occurs with the older GICv2 controller. These are virtual machines in every case. ABSD has not been booted on any physical ARM machine, and nothing here is evidence about one.
• VALIDATED USB host controller (xHCI) enumeration, not merged, as a boot-time kernel probe: against QEMU's qemu-xhci model under TCG it takes over the controller, resets a port, assigns an address to one directly attached device, and reads its device descriptor at three bus speeds, and enumerates a device afresh after it is unplugged and plugged back in; malformed and stale controller responses, injected by the test, are refused. It polls on one CPU, handles one device on the first connected port, and has no hubs and no device drivers: no keyboard, no storage, nothing a user can use. Two features that physical controllers commonly require (scratchpad buffers and taking the controller over from firmware) are not present in QEMU's models, so they were exercised only with injected values and a model of the firmware. It has not been run on a physical controller. This is not USB support.
• EXPERIMENTAL-INTEGRATION A successor storage engine is research in progress and not claimed.

How statements are labelled

MILESTONE-QUALIFIED

Passed in the recorded qualification run of the milestone above. The claim is limited to that run's environment.

RELEASE-QUALIFIED

Passed the recorded qualification of a named release (an exact kernel and platform pair) and was accepted on review. Limited to that release and the environment named with it.

VALIDATED

Passed a recorded qualification run of an exact commit, which is recorded privately and not always named here. Limited to that run's environment and the limits stated with it; not by itself a release claim, and it may be on a development branch that has not been merged.

EXPERIMENTAL-INTEGRATION

Exists on an integration branch or as a one-off experiment. Not qualified, and not a claim.

PLANNED

A stated direction with no qualified implementation yet.

UNSUPPORTED

Not provided. Do not rely on it.

Qualification scope

MILESTONE-QUALIFIED QEMU with TCG (no hardware virtualization) on one Linux development host; x86-64, one CPU, -cpu max,vendor=GenuineIntel,+rdrand; QEMU's default PC machine with SeaBIOS; one e1000 (82540EM) network card on QEMU user networking; one IDE disk image. Nothing on this page is a claim about physical hardware.

• MILESTONE-QUALIFIED QEMU: the operator image boots, serves SSH, and halts on request.
• PLANNED Physical hardware qualification: not yet established. A read-only physical boot image exists and has been exercised under QEMU (SeaBIOS and OVMF); the milestone's image has not been booted on hardware; later read-only images were booted on one machine (since the milestone). See hardware.

Works

What an operator can do on the qualified system. Today the only operator is the developer: the system cannot be downloaded or built by anyone else.

• MILESTONE-QUALIFIED With the source tree, which is private: build an operator image (ISO and 64 MiB disk), boot it, and log in with stock OpenSSH using an ed25519 public key. See afterboot(8).
• MILESTONE-QUALIFIED Verify the host key: its fingerprint is printed on the console in ssh-keygen -l form and matches ssh-keyscan.
• MILESTONE-QUALIFIED Run several concurrent SSH sessions, each isolated from the others, with a PTY shell (line editing, ^C) or a single command per connection.
• MILESTONE-QUALIFIED Use a small shell, absd-sh(1), with pipes and redirection; 27 commands under /bin (20 native, and seven unmodified uutils 0.12.0 programs); 17 manual pages read with man; ps for the session's own processes.
• MILESTONE-QUALIFIED Keep files: /home/operator is writable and persists across sessions and reboots; /bin, /etc, /share, and /var/log are read-only to sessions; the SSH host key is unreachable from any session.
• MILESTONE-QUALIFIED Configure the network address and SSH limits in /etc (read at start; a malformed file stops the boot with the file, line, and reason); read logs under /var/log; read the date and uptime.
• MILESTONE-QUALIFIED Copy files byte-exactly over SSH exec (ssh host 'cat > f' < f, ssh host cat f > f). There is no scp or sftp.
• MILESTONE-QUALIFIED End the boot with shutdown or reboot: sessions end, the file server commits, and the machine halts or restarts. Stopping the machine needs a kernel machine handle, which only init holds.
• MILESTONE-QUALIFIED Run real programs from the Constellation project natively, as ordinary workloads: an SQLite-backed store, a journal, a resolver, and a diagnostics tool, each compared against its Linux build. See research.

Qualified

The checks behind the list above, from the milestone's recorded run of the platform's full check script (exit status 0). Counts are the check script's own output.

• MILESTONE-QUALIFIED Build: 55 programs byte-identical across two clean builds.
• MILESTONE-QUALIFIED SSH: 129 checks against ABSD with the host's /usr/bin/ssh (handshake, public-key authentication, exec, PTY shell, ^C within 33 ms, reconnect, session reclaim, host-key persistence, entropy and its negative control), plus 67 against a Linux reference target.
• MILESTONE-QUALIFIED File server: 39 checks (session writes, refused system and raw-block writes, persistence, host-key isolation, several sessions, failure isolation).
• MILESTONE-QUALIFIED Served boot: 65 checks (orderly shutdown, reboot, the stop right, shell shutdown).
• MILESTONE-QUALIFIED Commands and manual: 160 checks, including exact output, refusals, and deliberate absences.
• MILESTONE-QUALIFIED Operator image: 90 checks (host-key fingerprint, /etc configuration observed in effect, file transfer of 0 B to 1 MiB, date and uptime, log rotation, malformed configuration refused).
• MILESTONE-QUALIFIED Networking: ARP, IPv4, ICMP echo, TCP streams, and 200 reconnects with the stack's heap unchanged after the 20th.
• MILESTONE-QUALIFIED Durable state: 26 crash scenarios over 377 boots; filesystem matrix over 349 boots.
• MILESTONE-QUALIFIED Filesystem under abrupt stop: every sector the device acknowledged is kept; after a crash the namespace is that of the last commit.
• MILESTONE-QUALIFIED Filesystem under a modeled power-loss law (QEMU): any write not covered by a completed flush may be lost or reordered per aligned 512-byte or 4 KiB unit. 66 cuts inside an SQLite store's admissions and checkpoints, in the guest, always recovered the prior or the new committed state. The law was enforced by a model of the device; no real power was cut and no real drive's flush was tested.
• MILESTONE-QUALIFIED Compatibility probe: of 19 unmodified crates.io programs, 10 build and 9 run; 19 of 25 cases agree with Linux byte for byte. See compatibility.
• MILESTONE-QUALIFIED Kernel gates at the milestone commit: unit tests, lint, the deterministic QEMU boot suites, broker, image spawning, network, durable reader, block probe (ATA and NVMe), NVMe, external workload, physical-image safety gate, laptop-shaped QEMU machine, shell.

Not yet qualified

• PLANNED Physical hardware of any kind. Physical hardware qualification: not yet established.
• PLANNED Disk writes on physical hardware; the physical boot image is built so that it cannot write a disk.
• UNSUPPORTED Real power loss and any particular drive's handling of cache flushes.
• UNSUPPORTED Hardware virtualization (KVM) as a qualified environment for the milestone; its qualification ran under TCG. The later release also covers KVM (since the milestone).
• UNSUPPORTED At the milestone: updating or rolling back an installed image; a filesystem format change means reformatting. The later release qualifies a host-staged update and rollback (since the milestone).
• EXPERIMENTAL-INTEGRATION In progress at the milestone and not claimed there: containment of commands left running after a session ends, and a read-only survey of a first physical machine.

Known limits

• MILESTONE-QUALIFIED One CPU, one network card, one disk; 16 processes in the whole system; four SSH connections by default (at most eight at the milestone; the later release caps it at four).
• MILESTONE-QUALIFIED Uploads are slow under TCG: about 45 to 60 s per MiB up, about 17 s down.
• MILESTONE-QUALIFIED Programs start slowly: a native command takes 2 to 4 s from typing to the next prompt under TCG, a 1.5 MB uutils program about a minute, because the whole image is read through the file server.
• MILESTONE-QUALIFIED An interrupted command's own children keep running, adopted by init; a later shutdown then ends in an unreaped stop (QEMU status 71) after the file server has committed.
• MILESTONE-QUALIFIED Files have no times (the later release adds modification times); the clock is the RTC, never set or corrected.
• MILESTONE-QUALIFIED A torn superblock (outside the power-loss law) makes the filesystem refuse to mount. There is no repair tool.

Deliberately absent

Not missing by accident. Each would need a mechanism or an authority decision that no current workload has earned.

• UNSUPPORTED fork, exec replacing a running image, signals, job control, process groups, threads.
• UNSUPPORTED Users, groups, UIDs, permission bits, su. Several sessions are not several users.
• UNSUPPORTED Kernel sockets, IPv6, UDP, DNS, DHCP, outbound connections.
• UNSUPPORTED Dynamic linking, C programs and a libc, Linux binaries.
• UNSUPPORTED Packages, /etc/rc.d, syslogd, cron, /proc, fsck, a text editor, a pager, a GUI.
• UNSUPPORTED kill, top, a system-wide process list: a process sees only itself and its own children.

Deliberate deferrals

• PLANNED An exact-hardware-qualified SSH host.
• PLANNED A replacement policy for the SSH server and file server in a long-running boot. At the milestone and in the release, if either ends, the boot ends and is reported failed; the main development line adds a bounded whole-machine reset, not a replacement (since the milestone).
• PLANNED Several independently authenticated principals with different authority. Not accounts or UIDs; the design is open.
• PLANNED An integer file-descriptor table in userspace, when a program needs one.
• PLANNED A Linux binary personality, as a bounded experiment above the native interfaces. Deferred; no commitment.
• PLANNED Multiprocessor support in a release, when a workload needs it. Several-CPU scheduling has been validated as research only (since the milestone).