Pimp My IDE / cloud machine room
Back to garage
October 3, 2026 | operating systems / cloud runtimes / isolation

A boot demo is not a cloud contract.

FTL moves Linux-like OS work into a per-container userspace library over a small kernel. The architecture is worth studying. The project still calls itself very alpha.

Read the layers separately. A Linux binary starting under QEMU proves a narrow compatibility path. It does not prove broad syscall coverage, hostile-workload isolation, storage behavior, or production operations.

FTL cutawayexperimental
Linux processThe application presents Linux system calls and expects familiar process behavior.
Per-container userspace OSProcess, virtual filesystem, networking, and compatibility work live in a library.
Small FTL kernelMemory, virtual CPU, and device multiplexing sit behind a narrow interface.
Separate design / evidence / readiness

FTL changes where the operating system lives.

FTL describes each container as an instance of a userspace OS. Its Linux compatibility library implements process, virtual filesystem, and TCP behavior. A smaller kernel supplies virtual CPU, address-space, memory, and network primitives. The repository calls this a hypervisor-shaped interface, but says FTL catches faults through user mode rather than hardware virtualization.[1]

This is more than a packaging trick. It moves code that would usually live in one host kernel into a library that can vary by container. The project argues that this makes OS behavior easier to change, inspect, and restart without rebooting the machine.[2]

The interesting claim is architectural. The risky claim is operational.

Version 0.1.0 widens the demo lane.

The October 3 release adds Linux threads, futexes, epoll, signals, terminal support, memory mapping, pipes, eventfd, QEMU microVM support, lazy anonymous pages, and x86-64 SMEP and SMAP hardening. The author reports that a Tokio-based HTTP server now runs on FTL and serves the project website.[3]

The release has a downloadable ISO and a QEMU command. We verified the release record and asset through GitHub's API. We also cloned the repository at revision b73801a and found the documented run.sh path. We did not boot the ISO in this run.

Compatibility grows one behavior at a time.

Userspace application kernels have a direct tradeoff. They can put distance between a workload and a host kernel, but the compatibility layer must implement the behavior that applications expect. gVisor's architecture guide states this plainly. If gVisor has not reimplemented a Linux feature, a sandboxed workload cannot use it.[4]

FTL is earlier. Its launch post says the project lacked disk support, efficient copy-on-write fork, /proc, and other facilities at publication. The roadmap puts a filesystem in November and container images, Node.js, Go, symmetric multiprocessing, and Arm support later.[2] Those are plans, not current compatibility.

Isolation needs adversarial proof.

FTL aims for VM-like container isolation with a smaller interface. The author also names a current weakness. Processes inside one container can interfere with the shared userspace OS library. Applications that depend on process isolation, including Chromium, may need more work.[2]

Do not translate "hypervisor-shaped" into "equivalent to a mature hypervisor." Ask for a threat model, interface inventory, negative tests, resource-exhaustion behavior, and escape testing. The same discipline applies to compatibility. Pin a real workload and record every missing behavior.

Use it as a research candidate.

  1. Pin the repository revision or release ISO digest.
  2. Boot the published image with the documented QEMU command.
  3. Run one named workload with fixed input. Keep stdout, exit status, and resource measurements.
  4. Inventory the syscalls, filesystems, devices, and network behavior that workload requires.
  5. Run failure cases for invalid memory, blocked I/O, process exit, memory pressure, and malformed network input.
  6. Keep the host, emulator, CPU flags, and FTL revision in the receipt.
  7. Compare the result with a Linux baseline and one established isolation route.

FTL is a sharp experiment because it makes the OS boundary movable. Treat the move as a test target, not as proof that the boundary is ready.

Interactive makeover / cloud OS lift

Lift the claim only as high as the evidence.

Traditional purpose replaced: a feature checklist that mixes architecture, implemented behavior, and future plans. Better version: choose the claim, connect it to required evidence, and copy a test packet with every proof field still visible.

Artifact
Boot
Workload
Isolation

Claim selector

Choose one claim. The lift moves to its evidence floor. Mark only the test sections you intend to collect.

Claim under review
Packet sections

Evidence bay

The carriage and readout mirror the selected claim. Higher floors require more evidence.

Floor 01 / bootDemo claim

Published image boots

Run the tagged ISO with the documented command. Record the first stable prompt or service response and the emulator exit path.

  • Tagged ISO digest
  • Exact QEMU command
  • Boot output and exit path
1 of 4 packet sections selected.Boot is selected. The execution cell, observed result, and failure drill still need entries.
This lift writes a test packet. It does not boot FTL, inspect syscall coverage, run a workload, or prove isolation.

Sources read

Source log and evidence boundary
  1. FTL repository and Readme, read October 3, 2026. The Readme defines the small-kernel and userspace-OS split, documents Linux compatibility goals, lists the local QEMU path, and labels interceptors as planned.
  2. Seiya Nuta, "Introducing FTL: A new operating system for clouds", read October 3, 2026. The launch post calls FTL very alpha, explains the design, lists working syscalls and missing features, and states the current same-container shared-library weakness.
  3. Seiya Nuta, "FTL v0.1.0", read October 3, 2026. The release post lists new Linux behavior, QEMU microVM support, hardening changes, the Tokio HTTP server, and planned filesystem and sandbox work.
  4. gVisor, "Introduction to gVisor security", read October 3, 2026. The official guide explains an established userspace application-kernel design, its Linux reimplementation cost, its isolation model, and its limits.
  5. Hacker News discussion for FTL, read October 3, 2026. The exact story ID came from the Hacker News API. The discussion raised hardware-driver, authority, and compatibility questions. Comments are context, not proof of FTL behavior.

Artifact check. GitHub's API reported release v0.1.0, published October 3, with an 18,771,968-byte ISO and SHA-256 digest 6c0ee80304b42a98df979ffb39b0f4da804f6c554d582b33bc842948ba9218f5. We cloned 267 tracked files at revision b73801af0321853a8fd97f2ed91cc0f0c0ff315a and inspected the Readme. The source declares MIT or Apache 2.0 licensing.

Evidence boundary. We verified the public release record, repository, source instructions, project website, and comparison documentation. We did not download or boot the ISO, run FTL under QEMU, test a Linux binary, audit the kernel, or assess production security. Runtime and security statements remain attributed to the project unless stated otherwise.