Ein halbes Jahr NetBSD-Intensivphase
Die erste Jahreshälfte 2026 war bei mir von einer ungewöhnlich intensiven Beschäftigung mit NetBSD geprägt. Eigentlich begleitet mich das System schon seit vielen Jahren. Mal etwas näher, mal eher aus der Distanz. Mal beim Lesen von Mailinglisten und Commit-Logs, mal auf einem Zweit-Laptop oder einem kleinen Heimserver. Diesmal ging es allerdings deutlich tiefer.
Ausgangspunkt war die Frage, wie sich auf NetBSD stärkere Isolationsmechanismen als ein klassisches chroot umsetzen lassen. Daraus entstanden verschiedene Experimente rund um secmodel_jail, eigene Werkzeuge und schließlich mehrere Prototypen, die ich über Monate hinweg in diesem Blog dokumentiert habe. Parallel dazu habe ich intensiv mit KI-gestützter Entwicklung gearbeitet. Viele Ideen ließen sich dadurch deutlich schneller ausprobieren, als das noch vor wenigen Jahren möglich gewesen wäre.
Wenn Sie die praktische Entwicklung nachvollziehen möchten:
Rückblickend stehen weniger einzelne Prototypen oder konkrete Implementierungen im Vordergrund, sondern die Fragen, die dabei immer wieder aufkamen.
Die Leitfrage
Eine davon beschäftigt mich eigentlich schon seit Jahren:
Wie baut man Systeme, die man auch nach längerer Zeit noch versteht?
Wer meine Artikel regelmäßig liest, wird feststellen, dass viele Themen immer wiederkehren. Messaging statt enger Kopplung. DSLs statt ausufernder Konfigurationslandschaften. Reproduzierbare Builds. Kleine Werkzeuge mit klaren Aufgaben. Auf den ersten Blick wirken diese Themen recht unterschiedlich. Mit etwas Abstand scheinen sie sich aber oft um dieselbe Fragestellung zu drehen.
Ähnliche Gedanken finden sich auch hier:
Was NetBSD dabei sichtbar gemacht hat
NetBSD hat mir geholfen, genauer hinzusehen.
Nicht weil dort alles besser gelöst wäre. Auch NetBSD hat historische Entscheidungen, Kompromisse und Ecken, an denen man merkt, dass dieses System seit Jahrzehnten weiterentwickelt wird. Trotzdem hatte ich bei der Beschäftigung mit dem Kernel und dem Basissystem immer wieder den Eindruck, dass viele Teile einem gemeinsamen Gedanken folgen.
Es gibt Zuständigkeiten.
Es gibt Schnittstellen.
Und es gibt oft eine relativ klare Vorstellung davon, wo eine bestimmte Funktionalität hingehört.
Das klingt zunächst selbstverständlich. Im Alltag ist es das aber nicht immer.
Wie Komplexität schleichend entsteht
Viele Systeme wachsen über Jahre hinweg. Neue Anforderungen kommen hinzu, Werkzeuge werden ergänzt, Abstraktionsschichten entstehen. Jede einzelne Entscheidung ergibt für sich genommen meist Sinn. Erst mit etwas Abstand wird sichtbar, wie komplex das Gesamtsystem inzwischen geworden ist.
Während der Arbeit an den verschiedenen Cells-Prototypen habe ich das mehrfach selbst erlebt.
Viele Ideen begannen erstaunlich einfach. Danach kam eine zusätzliche Funktion hinzu, später etwas Komfort, dann eine weitere Abstraktion. Nichts davon war grundsätzlich falsch. Irgendwann stellte sich allerdings die Frage, ob die zusätzliche Komplexität noch im Verhältnis zum eigentlichen Problem stand.
Erst im Nachhinein wurde mir klar, dass genau dort die eigentlich interessante Fragestellung lag.
Nicht ob etwas technisch funktioniert.
Nicht ob eine weitere Schicht möglich wäre.
Sondern ob sie wirklich notwendig ist.
Dabei geht es nicht darum, Komplexität grundsätzlich abzulehnen. Viele Probleme sind nun einmal komplex. Mir ist während dieser Monate lediglich stärker bewusst geworden, wie schnell zusätzliche Schichten entstehen und wie selten sie später wieder verschwinden.
KI beschleunigt Implementierung, nicht Verstehen
In gewisser Weise haben die heutigen KI-Werkzeuge diese Beobachtung sogar verstärkt.
Die technische Umsetzung vieler Ideen ist deutlich einfacher geworden. Prototypen entstehen schnell. Neue Ansätze lassen sich ohne großen Aufwand ausprobieren. Gleichzeitig wurde für mich immer wichtiger, nachvollziehen zu können, warum bestimmte Entscheidungen getroffen wurden und welche Annahmen eigentlich dahinterstehen.
Das betrifft nicht nur größere Projekte.
Kleine Werkzeuge, lange Tragfähigkeit
Ähnliche Beobachtungen habe ich auch bei deutlich kleineren Themen gemacht.
Tcl/Tk zum Beispiel hatte ich lange Zeit kaum noch auf dem Schirm. Während meiner Experimente bin ich jedoch mehrfach darauf zurückgekommen. Nicht aus Nostalgie, sondern weil sich damit erstaunlich schnell kleine Werkzeuge bauen lassen, die ihren Zweck erfüllen und dabei überschaubar bleiben. Auch hier war weniger die Technologie selbst interessant als die Beobachtung, dass einfache Lösungen oft länger tragfähig bleiben, als man zunächst vermuten würde.
Ähnlich ging es mir bei DSLs.
Schon vor dieser NetBSD-Phase habe ich häufiger darüber geschrieben, warum ich domänenspezifische Sprachen oft für verständlicher halte als immer umfangreichere YAML-Konfigurationen. Die Beschäftigung mit Lua und Tcl hat diese Sicht eher bestätigt als verändert. Je größer ein System wird, desto wichtiger scheint mir die Frage zu werden, wie sich Zusammenhänge beschreiben lassen, ohne dass die Beschreibung selbst zum Problem wird.
Linux neu betrachtet
Interessanterweise hat die Zeit mit NetBSD auch meinen Blick auf Linux verändert.
Früher hätte ich wahrscheinlich länger darüber diskutiert, welches System eleganter oder konsistenter aufgebaut ist. Heute erscheint mir diese Frage weniger wichtig.
Die meisten meiner Systeme werden weiterhin auf Linux laufen. Nicht aus Überzeugung gegen NetBSD, sondern weil Linux für meine Anforderungen häufig die pragmatischere Wahl ist. Hardwareunterstützung, Container-Technologien und die Werkzeuge meines beruflichen Umfelds sprechen dafür.
Gleichzeitig hat mich die Beschäftigung mit NetBSD dazu gebracht, bestimmte Linux-Distributionen neu zu betrachten.
Alpine Linux ist dafür ein gutes Beispiel.
Früher habe ich Alpine vor allem als Grundlage für Container wahrgenommen. Heute sehe ich darin zunehmend ein System, das einige Eigenschaften besitzt, die ich ursprünglich an BSD-Systemen geschätzt habe: ein überschaubares Fundament, wenige Abhängigkeiten und die Möglichkeit, mit vergleichsweise wenigen Bausteinen ein vollständiges System aufzubauen.
Was am Ende bleibt
Mit der Zeit wurde mir klar, dass viele der Eigenschaften, die ich an NetBSD schätze, gar nicht zwingend an NetBSD gebunden sind.
Klarheit.
Überschaubarkeit.
Zurückhaltung bei zusätzlichen Abstraktionen.
Der Versuch, Probleme möglichst dort zu lösen, wo sie entstehen.
Das sind keine Eigenschaften eines bestimmten Betriebssystems. Es sind eher Haltungen beim Entwurf von Software und Systemen.
Rückblickend stehen daher weniger einzelne Werkzeuge, Kernel-Patches oder Prototypen im Mittelpunkt. Entscheidend sind die vielen kleinen Architekturentscheidungen dazwischen: Situationen, in denen zusätzliche Schichten verlockend wirkten, einfache Lösungen aber langfristig tragfähiger waren. Hinzu kommt die Erkenntnis, dass Verstehen häufig mehr Zeit beansprucht als Implementieren.
Viele der Fragen, die mich während dieser Zeit beschäftigt haben, begleiten mich weiterhin. Wahrscheinlich unabhängig davon, ob das darunterliegende System NetBSD, Alpine Linux oder etwas ganz anderes ist.
Mit etwas Abstand scheint mir genau das der interessantere Teil dieser Reise gewesen zu sein.