Compatibility

ABSD is not a Unix and does not run Linux binaries. Ordinary programs reach it through layers, each built on the one below and none redefining it.

Layers

Native interface MILESTONE-QUALIFIED: Processes started from an image with an ordered vector of handles; handles with rights; pipes, versioned cells, a block device, a network card, a machine object. The kernel knows no paths, file descriptors, users, or signals.
Rust std userspace MILESTONE-QUALIFIED: An experimental x86_64-unknown-absd target for the Rust standard library. std::fs, std::process::Command, piped standard streams, and std::io::IsTerminal work; File and ChildStdin carry handles directly. Threads return Unsupported.
Unix-style personality MILESTONE-QUALIFIED: Arguments, environment, working directory, relative paths, and program start from the filesystem, implemented in the userspace runtime. The shell, the commands, and the SSH server are written against it.
Integer file descriptors PLANNED: Deferred until a program needs them. It would be a userspace table over handles; descriptor numbers would not weaken handle staleness.
Linux binary personality PLANNED: Deferred, with no commitment. If built, it would sit above the native interfaces and translate Linux behaviour into native mechanisms, adding Linux behaviour only when a real binary needs it. It would not become the native specification.
C programs UNSUPPORTED: There is no C runtime, crt0, or libc for the target. The only C on ABSD is the SQLite amalgamation, compiled freestanding.

Source-compatibility probe

MILESTONE-QUALIFIED Nineteen published crates.io programs, chosen because they are small, widely used, and conventional, were built for ABSD without changing a source file. The only manifest change adds the ABSD runtime as a target-specific dependency. Programs that build were run on ABSD against the same cases as their Linux build, comparing standard output, standard error, and exit status byte for byte.

Measure	Result
Programs tried	19
Build for ABSD	10
Run and agree with Linux on at least one case	9
Cases	25
Cases identical to Linux	19
Cases that differ (each recorded and required to differ)	6

Programs that build and run: uutils basename, seq, cut, fold, nl, uniq, base64 (0.12.0), jsonxf 1.1.1, and ripgrep 15.2.0 (single-threaded). b3sum 1.8.7 builds and starts but fails every case. The seven uutils programs are installed on the operator image unmodified.

Build failures, by first obstacle

Category	Programs	Obstacle
POSIX layer dependency	6	uutils `wc`, `head`, `cat`, `sort`; hexyl; sd. All stop at `rustix` (through `errno`). For the uutils, integer file descriptors are behind it.
C runtime dependency	1	jaq: the `mimalloc` C allocator.
Missing native mechanism	1	fd-find: signals (`ctrlc`).
Missing conventional wrapper	1	xsv: `rand` 0.4 has no path to the hardware random source that newer `getrandom` uses.

Runtime differences

Cases	Program	Cause
3	b3sum	Always builds a thread pool; thread spawn is unsupported.
1	`rg -j2`	Parallel walker needs threads. Without `-j`, ripgrep uses one thread and matches Linux.
1	`rg` with piped input	ripgrep assumes non-Unix standard input is unreadable and searches the directory instead.
1	`cut` on a missing file	Same error kind and exit status; different message text.

Nothing was added to make these pass or fail. The probe is a measurement, not a roadmap: the obstacles above (a POSIX layer, descriptors, threads, signals) enter ABSD only if a native workload needs them.