tine: Buck2 tabanlı, doğrulanabilir önyükleme yapılabilir OS imajları için açık kaynaklı bir build sistemi

Önyükleme yapılabilir işletim sistemleri için yeni bir build sistemi

24 Eylül 2026'da Daan De Meyer ve Martin Pitt, sıfırdan — imzalı imajlar dahil — önyükleme yapılabilir işletim sistemi imajları üretmek için tasarlanmış açık kaynaklı build sistemi tine'ı yayımladı. Duyuru yazısı "From Thin Air to Bootable Images" başlığıyla amutable.com'da ortaya çıktı ve Hacker News'in ana sayfasına taşındı. Sıfırdan yazılmış bir build aracı olmaktan ziyade tine, Meta'nın açık kaynak build motoru Buck2'nin üzerine kurulmuş, rpm paketlerini, Rust crate'lerini, Go modüllerini, UKI'leri ve nihai imajları kapsayan bir kural katmanıdır.

tine'ın çözmeye çalıştığı sorun

Yazarlara göre başlangıç noktası güvene dair bir önerme: bütünlüğü kriptografik olarak doğrulanabilen bir işletim sistemi, ancak aynı özelliklere sahip bir build sisteminden çıkabilir. Buradan uzun bir gereksinim listesi türetiliyor. Araç, mümkün olduğunca az host bağımlılığıyla her yerde çalışabilmeli, bir ürüne giren her yazılım parçasını sabitlemeli (pin) ve Fedora, CentOS, Arch veya Debian gibi upstream dağıtımlarından paket içe aktarma, güncelleme ve birleştirme mekanizmaları sunmalı — ama bir CVE gerektirdiğinde upstream'den geçici veya kalıcı olarak ayrılmayı da kolaylaştırmalı.

Build'ler hermetik çalışmalı ve bit düzeyinde özdeş çıktı üretmeli; önyükleme yapılabilir imajlar ve systemd sysext imajları doğal ve paralel olarak derlenebilmeli; bir toolchain güncellemesinden sonra tüm dünyayı yeniden derlemek ucuz olmalı. İşletim sisteminin tamamı tek bir monorepo'da yaşar; böylece içe aktarılan bir RPM'de ya da sabitlenmiş harici bir depodan çekilen bir Go veya Rust bileşeninde — örnek olarak Kubernetes veriliyor — yapılan bir değişiklik, ara commit'lere veya push'lara gerek kalmadan tüm imaj seti boyunca derlenip test edilebilir. İmajlar syft, grype ve trivy gibi SBOM araçlarıyla ve güvenlik tarayıcılarıyla uyumlu kalmalı; değişmeyen bileşenler yerel veya global cache'lerden alınabilmelidir, çünkü tamamen sıfırdan bir build saatler sürebilir.

Mevcut araçlar neden yetersiz kaldı

Yazı dört alternatifi açık sözlülükle değerlendiriyor. mkosi doğal ilk adaydı — tine ekibinde onun yaratıcısı ve bakımcısı da var — ve upstream paketlerinden tek tek imajlar derlemek için iyi çalışıyor; ancak yazarlar, birbiriyle gevşek ilişkili birçok artefakt devreye girdiğinde kısıtlayıcı bulmuş. Onların çerçevesinde mkosi, imaj derlemeyi bilen ve diğer her şey için yalnızca opak hook'lar açan bir framework; oysa kendileri bir crate derlemek veya bir UKI birleştirmek gibi görevler için kütüphane fonksiyonlarını çağırabilen bir dil istiyordu.

SUSE ve openSUSE'un paketlerden ISO'lara her şeyi üretmek için kullandığı Open Build Service ise mimari gerekçelerle elendi: kendi sunucunuzu barındırması önemsiz olmayan merkezi bir sunucuya bağımlı ve genel amaçlı bir build sistemi değil; dolayısıyla yeni artefakt türleri ya paket modeline sıkıştırılmak ya da yama ile eklenmek zorunda kalırdı.

freedesktop-sdk, GNOME OS ve WebKitGTK'yı derlemek için kullanılan Apache BuildStream daha yakındı. Bir imajı, sandbox ortamlarında derlenen ve girdi hash'ine göre cache'lenen YAML elementlerinden oluşan bir graf olarak tanımlar; Buck2'den çok farklı değil. Yazarların itirazları bootstrapping ve genişletilebilirlik üzerine odaklanıyor: host araçlarına ve host Python runtime'ına yaslanan bir Python uygulaması ve YAML'da fonksiyon olmadığı için projeler zamanla kopyala-yapıştır birikimine eğilimli.

Meta'nın kendi OS imaj derleyicisi Antlir de Buck2 üzerine kurulu, ama Meta'nın iç deposuna göre şekillendirilmiş — örneğin btrfs gerektiriyor. Yazarlar Antlir'ın kendisini atlayıp altındaki motoru benimsedi ve Antlir ile mkosi'nin en iyi fikirlerini tek bir araçta birleştirmeyi hedefledi.

Box'lar: bildirimsel, sabitlenmiş build ortamları

tine build host'undan yalnızca üç şey ister: git, python3 (bootstrapping için kullanılır, üretim build'leri için değil) ve user namespace'ler. Geri kalan her şey, sabitlenmiş bildirimlerden tekrarlanabilir bir ortama bootstrap edilir; bu ortam projenin ihtiyacına göre istenildiği kadar eski veya modern bir dağıtım olabilir.

Merkezi soyutlama "box"tır: bir build görevini çalıştırmak için build grafının içinde bildirilen ve sabitlenen bir ortam. Yazarlar bunu container'larla veya distrobox'la karşılaştırıyor; tek fark, Buck2'nin dilinde doğal biçimde ifade edilmesi ve aynı cache ve yeniden derleme kurallarıyla kapsanması — bu yüzden hızlı derlenir, tekrarlanabilir kalır ve çalıştırmak için ek araç gerektirmez. tine, rpmbuild, go ve cargo için box'larla birlikte geliyor; ayrıca imaj birleştirme için systemd-ukify ve sanal makineleri çalıştırmak için QEMU gibi araçları içeren daha büyük, çok amaçlı bir fedora.rawhide.box da içeriyor. Projeler kendi box'larını tanımlayabilir.

Buck2 temeli

Make veya Meson'dan gelen okuyucular için yazıda kısa bir giriş var: her dizinin BUCK dosyası, Python lehçesi Starlark ile yazılır ve derlenebilir hedefleri bildirir; graf, kabaca depo sınırlarını izleyen adlandırılmış "cell"lere bölünür — böylece // kendi işletim sistemi projenize, tine// ise tine checkout'una işaret eder; bir hedef de o graf içindeki adlandırılmış bir düğümden ibarettir. tine'ın ürettiği imajlar ya PKCS#11 üzerinden donanım anahtarıyla ya da yerel olarak üretilmiş bir anahtarla imzalanabilir.

Neden önemli

İşletim sistemi imajı birleştirme uzun zamandan beri imperatif, framework tarzı araçların egemenliğindeydi. tine'ın bahsi şu: doğru, agresif biçimde cache'lenen, dil tabanlı bir build grafı daha iyi bir temeldir — ve bütünlüğü uçtan uca doğrulanabilir olması gereken bir OS dağıtan herkes için hermetik ve tamamen sabitlenmiş build'ler bir lüks değil, ön koşuldur. Açık kaynak sürümü bu iş akışını başkalarının kullanımına sunuyor; ayrıca yazıdaki mkosi, OBS, BuildStream ve Antlir karşılaştırması, mevcut OS build araçları manzarasının yararlı bir haritası işlevi de görüyor.