Wahrscheinlich brauchen Sie Yocto nicht – und das ist in Ordnung

• Yocto ist keine Distribution, sondern ein Werkzeug zum Zusammenstellen einer eigenen Linux-Distribution, und wenn man diese Kontrolle nicht braucht, ist es schwer als Standardwahl zu rechtfertigen
• Eine eigene Distribution bedeutet eigene Wartung – inklusive Regulierung wie dem CRA und der Verantwortung für Sicherheitsupdates über die gesamte Produktlebensdauer
• Die Einführung von Yocto bringt Build-Zeiten von mehreren Stunden, Build-Verzeichnisse mit über 100 GiB, eine Lernkurve von mehreren Wochen und BSP-Layer mit stark schwankender Qualität mit sich
• Wenn man nur eine robuste Linux-Basis zum Ausführen von Anwendungen braucht, können Debian und Image-Werkzeuge wie mkosi, ELBE und debos mit deutlich weniger projektspezifischem Aufwand ausreichen
• Yocto gewinnt nur bei starker Anpassung, harten Größen- oder Bootzeitvorgaben, Lizenz-Ausschlüssen und solider Yocto-Unterstützung durch den Hersteller; im Zweifel ist eine bestehende Distribution die bessere Wahl

---

Was Yocto tatsächlich ist und warum es oft zur Standardwahl wird

• Yocto ist nicht eine „Yocto-Linux-Distribution“, sondern eine Sammlung von Werkzeugen zum Erstellen einer eigenen Linux-Distribution
• Das Yocto Project liefert mit bitbake, openembedded-core und meta-yocto auch die Referenzdistribution Poky
• Yocto erlaubt es, das für ein Embedded-Projekt benötigte Linux-System sehr fein zusammenzusetzen
  • Der komplette User Space kann für die Ziel-CPU kompiliert werden
  • Auf jede Komponente können Patches angewendet werden
  • Funktionen einzelner Rezepte lassen sich ein- oder ausschalten
  • Alle Versionen können festgelegt oder geändert werden
• Viele SoC-Hersteller und Hardware-Partner liefern direkt nutzbare BSP-(Board Support Package)-Layer, die einen Startpunkt schaffen, der auf realer Hardware läuft
• Durch die Kombination aus Flexibilität und Herstellerunterstützung wird Yocto oft zur Standardwahl, aber wenn man dieses Maß an Kontrolle nicht braucht, kann die Last größer sein als der Nutzen

Eine eigene Distribution bedeutet eigene Wartung

• Regulierungen wie der Cyber Resilience Act (CRA) verlangen, dass Anbieter die mit dem Produkt ausgelieferte Software sicher halten und über die gesamte Produktlebensdauer Sicherheitsupdates bereitstellen
• Eine normale Yocto-Version wird typischerweise nur etwa 7 Monate gepflegt, bis die nächste Version erscheint
• Seit Yocto 5.0 Scarthgap erhalten LTS-Versionen nach aktueller Richtlinie bis zu 4 Jahre Updates
• Eine Yocto-Version besteht aus einem Satz bitbake-Rezepte mit bestimmten Versionen und Metadaten sowie der Referenzdistribution Poky
• Während des Wartungszeitraums übernehmen die Yocto-Maintainer Fehler- und Sicherheitskorrekturen in Komponenten und in Poky; Änderungen an Softwarekomponenten werden meist aus neueren Upstream-Versionen zurückportiert
• In realen Produkten wird Yocto selten unverändert eingesetzt; typische Änderungen sind
  • nicht triviale Patches oder lokale Änderungen an einzelnen Komponenten
  • zusätzliche Komponenten, die Yocto nicht bereitstellt
  • Versions-Upgrades oder Pinning, um Fixes zu erhalten oder einen bekannten guten Zustand zu halten
• Mit jeder Yocto-Wartungsversion muss geprüft werden, ob sich die lokalen Änderungen sauber auf den neuen Stand anwenden lassen
• Bei zusätzlichen oder festgepinnten Komponenten können die Yocto-Maintainer nichts wissen, daher muss man selbst prüfen, ob diese Komponenten weiterhin Fixes erhalten
• Wenn Poky fast unverändert genutzt wird, sollte man erneut prüfen, warum Yocto überhaupt nötig ist

Linux-Kernel und Herstellerabhängigkeit

• Yocto liefert und pflegt den Linux-Kernel als Teil jeder Version, aber in realen Produkten wird dieser selten ohne Änderungen verwendet
• Meist müssen zumindest Hersteller-Patches angewendet werden, und es muss ein ausreichend neuer Kernel mit den benötigten Treibern und Korrekturen genutzt werden
• Schon allein der Kernel ist, inklusive CVE-Tracking, eine erhebliche Wartungslast – unabhängig davon, ob Yocto verwendet wird oder nicht
• Um den Wartungsaufwand beherrschbar zu halten, wird empfohlen, auf einem LTS-Kernel von kernel.org aufzubauen und alle Änderungen als ordentlich gepflegte Patch-Queue zu führen
• Um Sicherheitskorrekturen nachzuziehen, wechselt man auf neue Stable-Releases und wendet die Patch-Queue erneut an
• Da kernel.org LTS-Kernel über mehrere Jahre pflegt, lässt sich die Patch-Queue meist sauber anwenden; echte Arbeit fällt in der Regel erst beim Wechsel auf ein neues LTS-Release an
• Je nach Konfiguration und Sicherheitsanforderungen gelten dieselben Prinzipien auch für den Bootloader, der ebenfalls meist stark SoC-spezifisch ist
• Den vom Hersteller gelieferten Kernel dauerhaft beizubehalten, ist in der Regel keine gute Idee
  • Ein Vendor-Kernel liegt oft Jahre hinter kernel.org zurück
  • Er erhält kaum Updates
  • Die meisten Sicherheitskorrekturen fehlen

Kosten der Einführung von Yocto

• Die Entscheidung, eine eigene Distribution zu bauen, kostet reale Engineering-Zeit

• Build-Zeit

  • Yocto kompiliert praktisch alles aus dem Quellcode
  • Selbst ein Clean Build eines nicht ganz einfachen Images dauert auf einer schnellen Workstation mehrere Stunden
  • sstate-cache und ein gemeinsames DL_DIR beschleunigen wiederholte Builds, aber schon kleine Änderungen an Rezepten können große Teile des Caches ungültig machen

• Speicher- und CI-Kosten

  • Yocto-Build-Verzeichnisse wachsen leicht auf über 100 GiB
  • CI-Runner brauchen ausreichend Speicher und eine Möglichkeit, sstate zwischen Jobs zu teilen
  • Das Spiegeln von sstate und DL_DIR kann Schmerzen lindern, aber diese Infrastruktur muss man selbst betreiben

• Lernkurve

  • Es gibt viel zu lernen: bitbake-Rezepte, Layer, dynamische Layer, Klassen, Overrides, bbappend-Dateien, PACKAGECONFIG, der Unterschied zwischen DEPENDS und RDEPENDS und mehr
  • Es dauert nicht Tage, sondern mehrere Wochen, bis ein Engineer in eine Yocto-Codebasis eingearbeitet ist

• Schwankende Qualität von BSP-Layern

  • Einige SoC-Hersteller liefern saubere und gut gepflegte BSP-Layer
  • Andere liefern meta-vendor-Layer, die auf einem fünf Jahre alten Kernel oder Bootloader festhängen, maschinenspezifische Rezepte in die falschen Layer hart codieren und bei jedem Poky-Upgrade kaputtgehen
  • Ein BSP, das wie ein guter Startpunkt aussieht, kann sich als der schlechteste Teil des Builds erweisen
  • Das sind keine Gründe, Yocto pauschal zu meiden, sondern Gründe, vor der Einführung zu prüfen, ob es wirklich nötig ist

Alternative: eine bewährte Distribution wiederverwenden

• Wenn nur eine robuste Linux-Basis zum Ausführen von Anwendungen benötigt wird, löst eine bestehende Distribution wie Debian GNU/Linux viele derselben Probleme mit deutlich weniger projektspezifischem Aufwand
• Debian bietet derzeit rund 70.000 Binärpakete
• Zu den unterstützten Architekturen gehören amd64, i386, arm64, armhf, riscv64, ppc64el und weitere
• Viele SoCs können Debian-Binärpakete wahrscheinlich direkt ohne Neukompilierung ausführen
• Debian ist nicht nur eine Distribution, die einen modernen User Space mit systemd, udev und dbus liefert
• Das Archiv enthält auch Bausteine für kleine Linux-Systeme mit SysV-artigem Init oder auf BusyBox-Basis
• Man kann eine schlanke Basis wählen und nur die für das Produkt nötigen Pakete installieren, während man gleichzeitig von der Arbeit der Debian-Paketbetreuer profitiert

Debians Wartungsmodell

• Debian stable erhält etwa 3 Jahre lang Sicherheitsupdates vom Debian Security Team
• Danach verlängert das gemeinschaftsgetragene Projekt Debian LTS den Support für allgemeine Architekturen um etwa 2 weitere Jahre
• Damit sind pro Release in der Praxis etwa 5 Jahre Support möglich – ähnlich wie bei Yocto LTS, aber mit deutlich weniger projektspezifischer Arbeit
• Um die neuesten Fixes zu übernehmen, reicht es, die aktuellen Debian-Pakete zu holen und das Image neu zu bauen
• Das ist eine grundsätzlich andere Art von Arbeit als bei Yocto, wo Upstream-Patches direkt zurückportiert oder lokale Änderungen immer wieder gegen Wartungs-Releases geprüft werden müssen

Aufbau von Embedded-Images

• Ein Debian-basiertes Embedded-Image bedeutet nicht, auf dem SoC von einem USB-Stick zu booten und den Debian-Installer auszuführen
• Stattdessen wird auf dem Build-Host ein flashbares Image erzeugt und anschließend auf das Gerät geschrieben
• Dafür braucht man typischerweise
  • einen meist SoC-spezifischen Bootloader, etwa u-boot
  • einen meist SoC-spezifischen Linux-Kernel
  • ein Root-Dateisystem auf Basis eines Linux-User-Space, direkt aus Debian übernommen
  • ein Werkzeug zum Zusammensetzen des Images, das diese drei Elemente zu einem flashbaren Image kombiniert
• Gängige Werkzeuge dafür sind mkosi, ELBE und debos
• Alle drei sind freie Software und erzeugen deterministische Images, die auf die Hardware geflasht werden können
• Der Wartungsaufwand sinkt deutlich, und die meisten Updates bestehen eher darin, Pakete im Image per apt zu aktualisieren, als Rezepte neu zu schreiben

Beispiel für einen Debian-Build mit debos

• debos liest YAML-Rezepte
• Ein Rezept besteht aus einer Liste von Aktionen, etwa dem Ausführen von Befehlen, dem Erzeugen eines Root-Dateisystems oder der Installation von Debian-Paketen aus konfigurierten Quellen
• Ein typischer Ablauf sieht so aus
  • Mit aptly wird ein lokaler Debian-Mirror betrieben, der Kopien aller benötigten Debian-Pakete enthält
  • Der Linux-Kernel und bei Bedarf der Bootloader werden als Debian-Pakete gebaut und dem Mirror hinzugefügt
  • Es wird ein Snapshot des Mirrors erstellt und getaggt
  • Dieses Tag ist das Release
  • debos wird so konfiguriert, dass es diesen Mirror verwendet, und es werden Rezept-Aktionen zum Erzeugen des Ziel-Images geschrieben
  • Falls nötig, werden Debian-Source-Pakete und das SBOM (Software Bill of Materials) des Images zusammen mit dem Image archiviert
• Das Aufbewahren von Source-Paketen und SBOM hilft, GPL-Pflichten zur Bereitstellung des Quellcodes sowie Anforderungen des CRA an die Stückliste einzuhalten
• Werkzeuge wie debsbom erzeugen ein SBOM direkt aus einem Debian-System

Wann man Yocto wählen sollte

• Yocto passt, wenn eine stark angepasste Distribution benötigt wird
  • angepasster User Space
  • angepasste Compiler-Flags
  • tiefe Änderungen an Basiskomponenten
• Es passt bei strengen Größen- oder Bootzeitvorgaben, die mit einer Standarddistribution nicht erreichbar sind
• Es passt bei Lizenzvorgaben, bei denen bestimmte gängige Lizenzkategorien ausgeschlossen werden müssen
  • In manchen Branchen, etwa Medizintechnik, Automotive oder bestimmten Verteidigungsprojekten, werden keine GPLv3-Komponenten ausgeliefert
  • Yoctos Mechanismus INCOMPATIBLE_LICENSE macht es einfach, bestimmte Lizenzfamilien über das gesamte Image hinweg auszuschließen
  • Bei einem normalen Debian-Setup müsste man Pakete selbst prüfen und reduzieren
• Es passt, wenn der offizielle Support-Pfad des SoC-Herstellers auf Yocto basiert und die BSP-Qualität solide ist

Wann man Yocto meiden sollte

• Wenn nur ein modernes Linux zum Bereitstellen und Ausführen einer Anwendung benötigt wird, braucht man Yocto möglicherweise nicht
• Wenn Speicher- und RAM-Budget ein normales Debian-basiertes Image zulassen, schrumpft der Vorteil von Yocto
  • Als grober Richtwert gelten einige hundert MB Flash und mindestens 256 MB RAM
• Wenn die Produktlebensdauer lang ist und es sinnvoller ist, sich auf das Debian Security Team als auf eigene Wartung zu stützen, sollte man Yocto eher vermeiden

Wann man Debian meiden sollte

• Wenn viele Debian-Pakete geändert oder neu gebaut werden müssen, ist Debian im Nachteil
  • Das Neubauen einiger weniger Pakete ist beherrschbar
  • Jedes neu gebaute Paket wird zu zusätzlicher eigener Wartungsarbeit
  • Wenn Dutzende Upstream-Pakete gepatcht werden, baut man im Grunde die Arbeit nach, die Debian-Maintainer sonst übernehmen
  • In dieser Größenordnung ist Yoctos Rezeptmodell sauberer
• Wenn eine nicht-glibc-libc wie musl oder uClibc gebraucht wird, passt Debian nicht
  • Debians Hauptarchiv basiert weitgehend auf glibc
  • Um das auszutauschen, müsste man den Großteil des Archivs selbst neu bauen
• Wenn deutlich neuere Software benötigt wird, als Debian stable bereitstellt, ist Debian im Nachteil
  • Backports helfen bei manchen Paketen
  • Wenn das Produkt aktuelle Compiler oder aktuelle Laufzeitumgebungen braucht, gerät Debian stable an Grenzen
  • Debian testing ist kein Ziel für den Produktionseinsatz

Entscheidungsprinzipien und Fazit

• Die Entscheidung für oder gegen Yocto sollte bewusst und früh im Produkt getroffen werden
• Diese Wahl ist eine grundlegende Architekturentscheidung, die sich später, wenn das Produkt bereits im Feld ist, nur schwer rückgängig machen lässt
• Im Zweifel ist es besser, mit einer bestehenden Distribution zu beginnen
• Später auf Yocto zu wechseln, sobald es einen echten Grund dafür gibt, ist deutlich günstiger, als mitten im Projekt festzustellen, dass man sich ohne realen Nutzen jahrelange Wartungsarbeit aufgeladen hat
• Yocto ist ein hervorragendes Stück Engineering, das es erlaubt, genau das Linux-System zu bauen, das benötigt wird – aber genau diese präzise Kontrolle wird zum Problem, wenn man sie nicht wirklich braucht
• Dieselbe Logik gilt fast unverändert auch für andere quellcodebasierte Build-Werkzeuge wie Buildroot
• Sobald man beginnt, eine eigene Distribution zusammenzustellen, übernimmt man auch selbst die Verantwortung für ihre Wartung
• Das zentrale Fazit ist klar
  • „Eigene Distribution“ bedeutet in der Praxis eigene Wartung
  • CRA und ähnliche Regulierungen machen diese Kosten sehr real
  • Ein stark modifizierter Yocto-Build erbt Upstream-Fixes nicht kostenlos
  • Jedes Wartungs-Release bedeutet erneute Prüfung und Nacharbeit
  • Eine bestehende Distribution wie Debian, mit mkosi, ELBE oder debos in ein Image gebracht, deckt den Normalfall mit deutlich weniger projektspezifischem Aufwand ab
  • Wenn man das System chirurgisch präzise kontrollieren muss, gewinnt Yocto
  • Andernfalls ist die Wahl von Yocto ein langer und teurer Weg zur Lösung eines Problems, das man gar nicht hat

[GN⁺]

Lobste.rs-Kommentare

• Wenn der offizielle Support-Pfad des SoC-Anbieters Yocto ist, dann ist das meiner Meinung nach in der Regel besser als ein Ubuntu-Port von meist niedriger Qualität, selbst wenn das BSP nicht besonders solide ist
  Ein Ubuntu-Port macht Dinge wie die Integration von RAUC oder ein unveränderliches Root-Dateisystem umständlich. Ich hasse Yocto und seine abgewandelten bash/python-Dialekte wirklich, aber am Ende ist man daran gebunden

• Ich mache viel Yocto-Consulting, habe die im Artikel beklagten Probleme aber fast nie erlebt. Meistens ist es eher umgekehrt: Selbst in Situationen, in denen Yocto die beste Wahl ist, wollen Kunden es unbedingt vermeiden, und man muss das Management überzeugen
  Dass Yocto unbeliebt ist, kann ich allerdings verstehen. Es ist schwierig, verwirrend, langsam, und auch die Tools könnten besser sein. Trotzdem weiß ich nicht, ob es eine echte Alternative gibt, und ich frage mich, ob es auf der BSD-Seite etwas Vergleichbares gibt

  • Ich weiß nicht, wie ähnlich es Yocto ist, aber die übliche Methode zum Erstellen von Embedded-System-Images unter FreeBSD ist NanoBSD
    https://docs.freebsd.org/en/articles/nanobsd/
  • Ich habe es in der Praxis nicht intensiv genutzt, und es ist vielleicht weniger ausgereift als Yocto, aber in buildroot steckt ziemlich viel Gutes
    Ich habe es vor allem im Kontext von Nerves verwendet; Nerves ist im Grunde eine Kombination aus buildroot + fwup + Erlang-VM und begleitender Software. Für die Entwicklung sowie das Paketieren/Verteilen eingebetteter Linux-Systeme war das ziemlich komfortabel
  • Ich arbeite nicht direkt mit Embedded-Linux/BSD-Systemen, aber aus meiner Erfahrung mit NetBSD scheint schon das Build-System build.sh auszureichen
    Damit lassen sich Kernel und Userland leicht cross-kompilieren. Wenn man am Ende noch pkgsrc-Anwendungen hinzufügen oder einen Bootloader wie u-boot in das erzeugte Image einbauen muss, braucht man vielleicht etwas Skripting. Es ist womöglich kein vollständig ausgearbeiteter Ablauf, den man sofort für eine Anwendung maßschneidern kann, aber als Grundlage ist es ordentlich
  • NetBSD ist gut auf Cross-Kompilierung für eingeschränkte Umgebungen ausgelegt, und wenn man einmal den Dreh raus hat, ist es ziemlich angenehm

• Nach meiner begrenzten Erfahrung, in der ich ein wenig vom Schrecken der Embedded-Welt mitbekommen habe, passte NixOS für solche Zwecke ziemlich gut, und die Build-Tools waren viel besser als bei Yocto

  • Ich frage mich, ob das auch auf ARM-Geräten so ist. Ich dachte, das NixOS-Ökosystem sei für solche Geräte noch ein bisschen zu früh dran

• Zufällig haben wir im Unternehmen gerade angefangen, einen benutzerdefinierten Linux-Kernel und eine Distribution für ein Rockchip-basiertes Gerät zu planen und zu bauen, daher kommt der Artikel genau zur rechten Zeit
  Das BSP scheint einiges an Wartungsaufwand mit sich zu bringen, und Debian „einfach zu verwenden“ wirkt deutlich besser handhabbar als die von mir schlampig geschriebenen BitBake-Jobs. Trotzdem ist das Yocto-Ökosystem selbst ziemlich ordentlich, und es gibt Tools wie kas oder isar, die den Einstieg erleichtern

  • Wenn ich mir das isar-README ansehe, wirkt es nicht Yocto-, sondern Debian-basiert. Ich frage mich, ob es üblich ist, beides zu kombinieren
    Im Artikel klingt es eher nach Yocto oder Debian und nicht nach einem Ansatz, der beides verbindet