Ich hatte vor gut zehn Jahren das Vergnügen hin und wieder am Aufbau von Autos mitwirken zu dürfen. Das waren entweder Oldtimer oder wüste Rekombinationen vorhandener Teile, also der Bodenplatte eines Schräglenker-Käfers mit Subaru- oder Alfa-Romeo-Wasserboxern, Porsche-Schräglenkern und was sonst noch so herumliegt. Darauf kommt eine Karrosserie, die vom Radstand her eben passt, gerne auch mal aus Fiberglas. Heute würde man wahrscheinlich noch eine Megasquirt in den Ring werfen, und erstmal einen gepatchten GCC dazu verwenden, Firmware zu kompilieren.

Damit sind wir schon ziemlich nahe am Thema: Auch eine Linux-Distribution besteht aus “am Markt erhältlichen Komponenten”, die einfach zusammengefügt werden müssen — in der Theorie. Primär aus Neugier, aber auch weil das eine oder andere Projekt, an dem ich arbeite, eine simple “single purpose live distribution” erfordert, habe ich vor etwa zwei Jahren damit angefangen, eine Distribution auf Basis von BusyBox und einer minimalen Ramdisk aufzubauen.

In den letzten Wochen hatte ich etwas Zeit, daran weiterzuarbeiten und habe ein rudimentäres Paket- und Abhängigkeitsmanagement und eine Buildumgebung für ein glibc basiertes Rootdateisystem drumherum gebaut. Daraus ist bislang ein kleines Desktopsystem mit Xvesa und XFCE 4.6 entstanden, das derzeit 50 bis 70MB Squash-Container belegt und in einer bekannten Umgebung (nur wenige Kernelmodule werden geladen) etwa 12 Sekunden bis zum Desktop braucht. Kompiliert wird in einer Chroot-Umgebung, was die Integration neuer Pakete recht einfach macht: man kann jederzeit eine Kopie der Chroot-Umgebung erstellen, reinwechseln, basteln und das resultierende Buildscript sichern.

Und was ist daran besonders?

• Initramfs modular: Die Tatsache, dass einem modernen Kernel beim Start mehrere Initramfs übergeben werden können, mache ich mir für die Modularisierung zunutze: Ein Initramfs für Kernelmodule, eines mit Scripten und Binaries, eines mit Einstellungen. Das erleichtert beispielsweise Tests mit verschiedenen Kerneln oder Updates der für das /home-Verzeichnis vorgesehenen Einstellungen.
• Bootprozess einheitlich: Als Init kommt das “Simple Init” der Busybox (mit einfacher inittab) zum Einsatz, dieses triggert einige BSD-artige Scripte, jedes dieser Scripte kann über einen Cheatcode skipservices=|network|dropbear|...| deaktiviert werden. Die bei anderen Live-Distributionen übliche Trennung zwischen Startcode für Hardware-Erkennung und Startcode nach Mounten der Container ist damit aufgehoben.
• Modulare Container: /bin, /usr etc. befinden sich jeweils auf eigenen Containern, zusätzliche Container können einfach als SquashFS gepackt und im Containerverzeichnis abgelegt werden. Ein Eintrag in der Datei “mount.txt” definiert dann den Einhängepunkt. Das erleichtert unabhängige Erweiterungen, ohne dass Container oder Initramfs geöffnet und neu gepackt werden müssen.
• Drei Startmodi: Das gesamte System kann als Initramfs geladen werden, es wird dann beim Start in den Arbeitsspeicher entpackt, sinnvoll bei sehr kleinen Systemen wie einem Thinclient oder einem Backup- und Restoretool, das ohne NFS-Server so komplett per TFTP gestartet werden kann. Bei etwas größeren Dateisystemen wie einem Kiosksystem mit Desktop, Browser und Zugriff auf einzelne lokale Geräte, wo die Container gepackt etwa 60MB einnehmen (entpackt 200MB), können die SquashFS-Dateien als Initramfs geladen werden. Und drittens der klassische Startmodus beim Start von USB-Stick oder CD, bei dem die Container read-only vom Startmedium gemountet (oder ggf. vorher ins RAM kopiert) werden.
• Kein Pivoting: Das Root-Dateisystem bleibt auf dem Initramfs. Wozu sollte man das Wurzelverzeichnis pivotieren, wenn sowieso ein temporäres Verzeichnis Root-Verzeichnis ist?
• Busybox für Brot- und Butter-Aufgaben: Die statisch gegen uClibc gelinkte BusyBox stellt auf nur 800kB eine Menge typischer Unix-Tools bereit. Es müssen so nicht dutzende GNU-Pakete kompiliert und integriert werden. Wird während dem Build festgestellt, dass ein GNU-Werkzeug nicht integriert ist, wird auf die entsprechende BusyBox-Funktion verlinkt.

Was es nicht wird!

• Keine Desktop-Distribution: Das können Ubuntu, Fedora, openSUSE und Co besser. Schon der schiere Aufwand, 10.000 Pakete zu pflegen erfordert hunderte Maintainer. Eine Zahl von 500 bis 1000 Paketen dürften ausreichen, ob die oben angesprochenen Einsatzzwecke gut abzudecken (derzeit sind es etwa 200 einzelne Pakete). Wer mehr will, muss obendrauf selbst kompilieren. Zehn bis zwanzig eigene Buildscripte für zusätzliche Pakete sind zumutbar
• Keine Server-Distribution: Auch dutzende Serverpakete zeitnah mit Sicherheitspaketen zu versehen, ist schwierig. Denkbar ist in ferner Zukunft eine Möglichkeit, auch kompakte Xen-Images als Kombination aus ro-Dateisystemen für Anwendungen und rw-Dateisystemen für Daten zu erzeugen. Xen mit Linux-Instanzen, die mit 128MB RAM performant laufen und durch Austausch der ro-Container upzudaten sind, stellt eine interessante Alternative zum Shared Hosting dar… Aber das ist weit entfernt.
• Keine Vielzweck-Live-Distri: Das können Knoppix, Sidux und auch Slax besser. Die Modularität von Slax kommt den Nutzern entgegen, die im Rahmen der vorgesehenen Container kombinieren möchte. Wer es etwas stärker angepasst haben möchte, dürfte dagegen bei “meiner” Distribution fündig werden.
• Keine Cross-Compile-Distri für den Embedded-Bereich: Mittelfristig soll 32 Bit x86, 64 Bit x86/AMD64 und PowerPC 32 unterstützt werden. Aber bis auf die uClibc-Busybox alles in einer Chroot-Umgebung kompiliert. Wer für eingebettete Systeme crosscompilieren möchte, sollte das uClibc Buildroot, Poky, Rock Linux oder T2 ausprobieren.

Alles nur heisse Luft?

Mitnichten, das ISO welches ich im Moment vorliegen habe, hat 372MB — noch integriert es neben 80MB Squash-Containern (nicht optimiert und mit Firefox und Flash) zwei Kernel mit jeweils über 140MB Modulen. Wenn das aufgeräumt ist, gibt es eine erste “Technologiedemo”, die wenigstens auf den gängigsten Ethernet-Chips mit brauchbarer Vesa-Grafik booten sollte. Bereits enthalten ist ein Script welches mittels lshw, lspci und anderen Tools die Hardware-Infos ausliest und — falls vorhanden auf ein FAT32-Medium speichert, das den Ordner hwinfo im Wurzelverzeichnis enthält. Wer möchte, darf mir das dort abgelegte Hardwareprotokoll zu Analyse- und Statistikzwecken zukommen lassen. Mehr in den nächsten Tagen, Nutzer die nicht regelmäßig mitlesen, können mir eine Mail zukommen oder einen Kommentar hinterlassen. Ich informiere dann, wenn es etwas herunterzuladen gibt.

Und wie heisst das Kind?

Angedacht ist lesslinux — light, embeddable, small, scalable linux oder lacking elegance, stupid, scary. 🙂

Let the Flamewar begin, kommentiert schön fleissig.