Yocto ist ein Build-System, um maßgeschneiderte Linux-Distributionen aus den Quellen zusammenzusetzen. Wenn das eigentliche Ziel enger ist (eine Anwendung auf eine Flotte von Geräten bringen und aktuell halten), trägt man einen Großteil von Yoctos Maschinerie als Kosten, ohne sie zu nutzen. Dieser Artikel betrachtet, wo diese Kosten anfallen und wie ein deklarativer, NixOS-basierter Workflow mit Thymis den Tausch macht.

Warum Teams nach einer Yocto-Alternative suchen

Das Yocto Project ist mächtig, und genau das ist der Punkt: Es ist ein Baukasten für vollständig maßgeschneiderte Distributionen, gebaut für Teams mit dedizierten Embedded-Linux-Entwicklern. Wer „nur” eine Anwendung zuverlässig auf Geräten laufen lassen will, kommt um mehrere Kosten kaum herum:

Steile Lernkurve. Ein Recipe ist eine Mischung aus Python, Shell und BitBake-Syntax, obendrauf bbappend-Dateien, Overrides, Klassen und Layer-Reihenfolge. Änderungen, die trivial aussehen (einen Dienst hinzufügen, ein Paket patchen, eine Kernel-Option umlegen), hängen oft davon ab, zu wissen, wo im Layer-Stack eine Variable zuletzt gesetzt wurde. Die Einarbeitung in einen bestehenden Yocto-Baum misst man in Wochen, nicht in Tagen.

Lange Builds, große Artefakte. Ein arbeitsfähiges tmp/ und der sstate-cache überschreiten leicht 100 GB. Saubere Builds dauern Stunden; selbst inkrementelle Builds sind lang genug, um die Feedback-Schleife zu zerreißen. CI braucht echten Plattenplatz und einen warmen, geteilten sstate-Cache, um benutzbar zu sein; ein kalter Cache nach einem Release oder Host-Wechsel wirft einen zurück zu stundenlangen Builds.

Fragile BSP-Layer. Vendor-BSP-Layer pinnen oft Kernel und Bootloader, die bereits Jahre alt sind. Jedes Yocto-Upgrade bedeutet, erneut zu prüfen, ob die eigenen Patches noch passen und wer jede Komponente pflegt. Diese Wartung endet nie; sie bleibt am Team hängen.

Updates und Sicherheit sind nicht eingebaut. Yoctos Aufgabe endet beim gebauten Image. Dieses Image sicher auf Geräte im Feld zu bringen, ein fehlgeschlagenes Update zu behandeln und CVEs nach dem Release nachzupflegen sind eigene Probleme, die man selbst löst oder durch Integration von Tools wie Mender oder SWUpdate. Mit Pflichten wie dem EU Cyber Resilience Act hört es auf, optional zu sein, genau zu wissen, was auf jedem Gerät läuft.

Der Thymis-Ansatz: Image-Erstellung + Fleet-Management in einem

Thymis baut auf NixOS und dessen funktionalem Paketmanager auf. Statt imperativ zu skripten, wie ein Image gebaut wird, beschreiben Sie deklarativ, was auf dem Gerät gelten soll; dieselbe Definition erzeugt ein reproduzierbares Image und verwaltet das Gerät über seinen Lebenszyklus:

Konfiguration definieren oder Software hochladen: über das Web-Interface, oder durch das Schreiben von Nix-Modulen, wenn Sie tiefere Kontrolle wollen
Reproduzierbares Image erhalten: für Raspberry Pi und weitere ARM-/x86-Ziele, aus denselben Eingaben bit-für-bit reproduzierbar
Flotte betreiben: OTA-Updates, automatischer Rollback bei einem fehlgeschlagenen Update, Remote-Zugriff, Monitoring und eine VNC-Geräteansicht

Reproduzierbarkeit ist hier keine CI-Disziplin, die man erzwingen muss, sondern eine Eigenschaft des Modells. Dieselben Eingaben erzeugen dasselbe Image.

Yocto vs. Thymis im Überblick

	Yocto	Thymis
Einarbeitung	Wochen bis Monate (BitBake, Layer, Recipes)	Stunden: Web-UI, deklarative Konfiguration
Image-Erstellung	Eigene Build-Infrastruktur, Stunden pro Build	Automatisch, von Thymis erzeugt
Reproduzierbarkeit	Möglich, aber aufwendig abzusichern	Eingebaut durch NixOS
OTA-Updates	Nicht enthalten (separat: Mender, SWUpdate …)	Eingebaut, eine Aktion für die ganze Flotte
Rollback	Selbst zu implementieren	Automatisch bei fehlgeschlagenen Updates
Fleet-Management	Nicht enthalten	Dashboard, Tags, Vererbung, Massen-Deployment
Zielgruppe	Embedded-Linux-Spezialisten	Produktteams, die Software ausliefern wollen
Lizenz	Open Source	Open Source (AGPL), Cloud & Enterprise optional

Wann Yocto trotzdem die richtige Wahl ist

Das ist kein Werkzeug-als-Religion-Streit. Wenn Sie exotische Hardware mit eigenem BSP zum Laufen bringen, jedes Byte des Root-Filesystems kontrollieren müssen oder bereits ein dediziertes Embedded-Team haben, das BitBake fließend spricht, ist Yocto eine bewährte Wahl und einen Verbleib wert. Ein NixOS-basierter Workflow ergibt mehr Sinn, wenn Sie auf Standard-Hardware sind (Raspberry Pi, x86-Gateways) und Time-to-Market, Wartbarkeit und ein sicherer Update-Pfad wichtiger sind als maximale Anpassbarkeit.

Von Yocto zu Thymis migrieren

Ein risikoarmer Weg ist inkrementell statt eines Big-Bang-Umstiegs: mit einem Pilotgerät beginnen, die Anwendung als Modul definieren (containerisiert ist meist der reibungsärmste erste Schritt) und das erzeugte Image parallel zum Bestand laufen lassen, bis Sie ihm trauen. Weil der Zustand jedes Geräts eine deklarative Konfiguration ist, können Sie exakt diffen, was sich zwischen alt und neu unterscheidet, statt zu raten, was zugleich die gerätegenaue Nachvollziehbarkeit liefert, die Auditoren sehen wollen.

Häufige Fragen

Brauche ich NixOS-Kenntnisse, um Thymis zu nutzen?

Nein, nicht für den Start. Thymis sitzt vor NixOS mit einer Web-Oberfläche und vorgefertigten Modulen, das erste Image entsteht also aus einer Konfiguration, nicht aus dem Schreiben von Nix. Wenn Sie eigenes Verhalten brauchen, können Sie runtergehen und ein Nix-Modul schreiben; es ist verfügbar, nicht erforderlich.

Welche Hardware wird unterstützt?

Gängige Plattformen wie Raspberry Pi sowie weitere ARM- und x86-Ziele. Die aktuelle Liste finden Sie in der Dokumentation.

Was kostet Thymis?

Die Open-Source-Version lässt sich auf bis zu 5 Geräten kostenlos selbst hosten. Cloud-Pläne starten bei 30 €/Monat, falls Sie den Server lieber nicht selbst betreiben. Zur Preisübersicht.

Ist Thymis auch eine Alternative zu Buildroot?

Weitgehend ja. Buildroot ist schlanker und freundlicher als Yocto, überlässt Updates und Flotten-Management aber ebenfalls komplett Ihnen, derselbe Tausch gilt also.

Zum Ausprobieren

Wenn der oben beschriebene Build-System-Aufwand bekannt klingt: Die Open-Source-Version lässt sich auf bis zu fünf Geräten kostenlos selbst hosten, sodass sich ein Vergleich mit Ihrem aktuellen Setup einfach durchführen lässt.

Loslegen · Auf GitHub ansehen · Doku lesen

Yocto Project and all related marks and logos are trademarks of The Linux Foundation. This website is not, in any way, endorsed by the Yocto Project or The Linux Foundation.

Yocto Alternative: Embedded Linux ohne Build-Schmerzen