Common questions.

No. swift-os removes legacy rather than emulating it. There is no Linux ABI and no Unix-compatibility layer — tools are recompiled against our own POSIX-like syscall surface.

Embedded Swift gives memory safety and modern ergonomics without a garbage collector or heavy runtime — a good fit for a freestanding kernel. The whole kernel is Swift, with no Foundation or stdlib.

Yes — the in-kernel TCP/IP stack, /bin/httpd, and /bin/llmd (a TinyStories transformer over HTTP) are real and tested. llmd is a CPU proof-of-concept, not a general GPU model runtime. This marketing site is built with SvelteKit + Strapi — but you can boot swift-os in your browser and hit its httpd yourself.

AArch64 under QEMU virt is the reference target (direct -kernel and UEFI/GPT). Real AArch64 boards are planned; x86-64 is a deliberate non-goal.

Clone the repo, install QEMU + the Swift toolchain, then make newlib busybox once, and make build base-image build/virt.dtb && make run. See the Quickstart, or try it in your browser with zero setup.

Yes — anything you write under /data. swift-os has three storage tiers: a signed read-only base image, a volatile RAM tmpfs at /tmp that vanishes on reboot, and a persistent on-disk filesystem (datafs) mounted at /data on its own virtio-blk disk. SQLite databases under /data survive reboot and are crash-safe via fsync; /tmp and the read-only base are not for durable state.

Partly. It boots and runs restricted tests with -smp 4 (S0–S2 of the SMP arc are done); full per-CPU scheduling, TLB shootdown, and arbitrary secondary EL0 execution (S3–S5) are active work.

Not yet. The libc surface, threading model, and syscall set are kept so as not to foreclose them, but Node.js / JVM hosting is recorded Phase-2 design, not something you can run today.