Tine: a Buck2-based open-source build system for verified bootable OS images

A new build system for bootable operating systems

On 24 September 2026, Daan De Meyer and Martin Pitt published tine, an open-source build system designed to produce bootable operating system images — including signed ones — from scratch. The announcement post, "From Thin Air to Bootable Images", appeared on amutable.com and was picked up on the front page of Hacker News. Rather than a build tool written from zero, tine is a layer of prescriptive rules on top of Buck2, Meta's open-source build engine, covering rpm packages, Rust crates, Go modules, UKIs and final images.

The problem tine sets out to solve

According to the authors, the starting point is a claim about trust: an operating system whose integrity can be verified cryptographically can only come out of a build system that has the same properties. From there they derive a long list of requirements. The tool must run anywhere with as few host dependencies as possible, pin every piece of software that enters a product, and offer machinery for importing, updating and merging packages from upstream distributions such as Fedora, CentOS, Arch or Debian — while still making it easy to diverge from upstream, temporarily or permanently, when a CVE demands it.

Builds must run hermetically and produce bitwise-identical output, bootable images and systemd sysext images must be buildable natively and in parallel, and rebuilding the entire world after a toolchain bump must be inexpensive. The whole operating system lives in a single monorepo, so a change to an imported RPM or to a Go or Rust component pulled from a pinned external repository — Kubernetes is given as an example — can be built and tested across the full image set without intermediate commits or pushes. Images must stay compatible with SBOM tooling and security scanners like syft, grype and trivy, and unchanged components must be retrievable from local or global caches, since a complete from-scratch build can take hours.

Why the existing tools fell short

The post candidly reviews four alternatives. mkosi was a natural first candidate — the tine team includes its creator and maintainer — and it works well for building individual images out of upstream packages, but the authors found it restrictive once many loosely related artifacts are involved. In their framing, mkosi is a framework that knows how to build images and exposes only opaque hooks for everything else, whereas they wanted a language that can call library functions for tasks like compiling a crate or assembling a UKI.

The Open Build Service, which SUSE and openSUSE use to produce everything from packages to ISOs, was ruled out on architectural grounds: it depends on a central server that is non-trivial to self-host and is not a general-purpose build system, so new artifact types would have to be squeezed into the package model or patched in.

Apache BuildStream, used to build freedesktop-sdk, GNOME OS and WebKitGTK, came closer. It describes an image as a graph of YAML elements built in sandboxed environments and cached by input hash, not unlike Buck2. The authors' objections centre on bootstrapping and extensibility: it is a Python application that leans on host tooling and a host Python runtime, and because YAML has no functions, projects tend to accumulate copy-paste over time.

Antlir, Meta's own OS image builder, is also built on Buck2, but it is shaped around Meta's internal repository — it requires btrfs, for instance. The authors skipped Antlir itself and adopted its underlying engine, aiming to combine the best ideas from Antlir and mkosi in one tool.

Boxes: declared, pinned build environments

tine asks only three things of its build host: git, python3 (used for bootstrapping, not for production builds) and user namespaces. Everything else is bootstrapped from pinned declarations into a reproducible environment, which can be as old or as modern a distribution as the project needs.

The central abstraction is the "box": an environment for running a build task that is declared and pinned inside the build graph. The authors compare it to containers or distrobox, except it is expressed natively in Buck2's language and covered by the same caching and rebuild rules, so it builds quickly, stays reproducible and needs no extra tooling to run. tine ships boxes for rpmbuild, go and cargo, plus a larger multi-purpose fedora.rawhide.box containing tools such as systemd-ukify for image assembly and QEMU for running virtual machines. Projects can define their own.

The Buck2 foundation

For readers coming from Make or Meson, the post offers a short primer: each directory's BUCK file, written in the Python dialect Starlark, declares the buildable targets; the graph is divided into named "cells" that roughly follow repository boundaries, so // refers to your own operating-system project while tine// is the tine checkout; and a target is simply a named node in that graph. Images produced by tine can be signed either with a hardware key through PKCS#11 or with a locally generated key.

Why it matters

Operating-system image assembly has long been dominated by imperative, framework-style tooling. tine's bet is that a correct, aggressively cached, language-based build graph is a better foundation — and for anyone shipping an OS whose integrity must be verifiable end to end, hermetic and fully pinned builds are the precondition, not a nice-to-have. The open-source release makes that workflow available to others, and the post's honest comparison of mkosi, OBS, BuildStream and Antlir doubles as a useful map of the current OS build-tooling landscape.