Status · what works today

No overclaiming. Here's exactly where swift-os stands.

Experimental, but real. This page carries the honesty so the rest of the site can be confident. Everything marked Works is exercised by an acceptance gate in make test.

Embedded Swift · aarch64 · QEMU virt Phase 1 — hardening (active) · no stable version yet, built from source

Works Primary path Active hardening Non-goal

Capability	Status	Notes
AArch64 boot cortex-a72 · -kernel + UEFI	Works	Deterministic boot to a Swift login in under a second.
QEMU virt machine qemu-system-aarch64	Primary	The reference target; every gate runs here.
UEFI / GPT boot BOOTAA64.EFI · make disk-run	Works	Signed image, GPT-partitioned, AAVMF firmware.
Swift userland shell + native tools at EL0	Works	ls, cat, ps, top, id, httpd, ssh — Embedded Swift.
Three-tier storage ro base.img · tmpfs /tmp · /data	Works	Signed packed base, volatile /tmp, and a persistent on-disk /data (datafs) that survives reboot; crash-safe SQLite via fsync.
Networking in-kernel TCP/IP · virtio-net	Works	IPv4, DHCP, DNS, TCP/UDP, ICMP/ARP. IPv6 partial.
HTTP server /bin/httpd · :8080	Works	Concurrent poll-driven static server with MIME + listings.
AI inference /bin/llmd · TinyStories	Works	Native Swift transformer over HTTP. CPU proof, not a GPU runtime.
Package system .swpkg · signed repo · 12 ports	Works	pkg install NAME from a signed static repository.
Capability handles principal · typed handles	Hardening	Capability bits today; C1–C5 typed handles landed, C6 active.
SMP multi-core scheduling	Active	Boots with -smp 4; S0–S2 done, S3–S5 in progress.
TLS 1.3 ChaCha20-Poly1305 · client	Active	Client path works; cert verification incomplete.
Linux ABI syscall compatibility	Non-goal	We remove legacy, not emulate it. Tools are recompiled.
Docker / x86-64 containers · alt arch	Non-goal	Isolation is native; AArch64 only, deliberately.

Roadmap

Done, in flight, and planned.

Done

✓ Boot to Swift login (direct + UEFI)
✓ MMU process isolation (EL0/EL1)
✓ In-kernel TCP/IP + /bin/httpd
✓ TinyStories inference (/bin/llmd)
✓ Signed base image + .swpkg packages
✓ Persistent /data filesystem (datafs)
✓ Try-in-browser (qemu-wasm) demo

Active

◐ Typed capability handles (C5–C6)
◐ SMP scheduling (S3–S5)
◐ Restartable driver services
◐ TLS 1.3 record layer + cert verification

Planned

○ Node.js / JVM hosting (Phase 2)
○ Real-hardware AArch64 boards

Known limitations & non-goals

What we won't do is part of the design.

Not a Unix-compatibility exercise

No Linux ABI, no POSIX emulation layer. Existing binaries are recompiled against our own syscall surface, not ported.

Single architecture, on purpose

AArch64 only. Supporting x86-64 would double the trusted surface for little gain to the project's goals.

Volatile by default

The base image is read-only and /tmp vanishes on reboot; durable state is an explicit choice — you write it to the persistent /data tier. Persistence is opt-in, never accidental.

No ambient authority, no GPU runtime

Being "root" grants nothing by itself, and AI hosting is CPU-only — no GPU/NPU acceleration is in scope today.

Acceptance gates

Every claim above is a test.

These gates run on each commit in CI under QEMU. A red gate blocks the merge.

ports in the seed repo

SMP boot tested (-smp 4)

panics on the boot gate

syscalls in the ABI

make test · acceptance

PASS  boot_test.sh               boots to swift-os login
PASS  cap_enforce_test.sh        EL0 cannot open without the capability
PASS  ipc_socket_transfer_test   endpoint handle move semantics
PASS  smp_boot_test.sh           boots with -smp 4 · per-CPU timers
PASS  llm_serve_test.sh          POST /completion returns text
PASS  package-local-install      signed .swpkg installs + verifies
─── make test · host unit + in-QEMU boot assertions ───