2026: Ein Projekt mit Systemnähe
Cloud, Plattformen, Abomodelle – die Richtung ist klar.
Infrastruktur wird zunehmend konsumiert, nicht mehr gebaut. Systeme werden zusammengesetzt, nicht mehr entworfen. Gleichzeitig steigen Hardwarepreise, Verfügbarkeit schwankt, Lieferketten werden unzuverlässiger. Das verstärkt den Trend: weniger eigene Systeme, mehr gemietete Dienste.
Das ist nicht überraschend. Es ist die logische Folge eines Marktes, der auf Skalierung, Bequemlichkeit und Kostenoptimierung ausgelegt ist. Ich arbeite selbst in diesem Umfeld. Vieles davon ist sinnvoll und funktioniert gut.
Was dabei auffällt: Man kommt immer seltener mit den eigentlichen Systemen in Kontakt.
Wer heute „Infrastruktur betreibt“, konfiguriert oft Plattformen, die andere Plattformen steuern, die auf fremdverwalteter Hardware laufen. Kernel, Init, Filesysteme, Toolchains – all das rutscht aus dem Fokus. Man bedient Werkzeuge, aber man baut keine Systeme mehr.
Warum ich das ändern will
Für dieses Jahr habe ich mir vorgenommen, wieder näher an die Grundlagen zu gehen.
Nicht, weil moderne Ansätze falsch wären, sondern weil ich verstehen will, was darunter passiert.
Mich interessiert:
- welche Entscheidungen man selbst treffen muss, wenn es keine Plattform vorgibt,
- wo Komplexität wirklich entsteht,
- und was man tatsächlich braucht, um ein System stabil zu betreiben.
Kurz gesagt: Ich will wieder Systeme bauen, die ich vollständig erklären kann.
Systemarbeit im privaten Umfeld
Infrastruktur wächst.
Man installiert etwas, ergänzt etwas, passt etwas an – und irgendwann ist das Ganze nicht mehr überschaubar. Im beruflichen Umfeld ist das normal. Es ist meist genau der Punkt, an dem der Ruf nach mehr Observability, mehr Metriken, mehr Tracing und mehr Dashboards laut wird.
Im privaten Umfeld ist es vor allem eine Frage, wie viel Struktur man sich selbst auferlegt.
Für dieses Projekt setze ich bewusst andere Schwerpunkte:
- lieber einfach als „komfortabel“
- lieber klar getrennt als „praktisch kombiniert“
- lieber selbst gebaut als fertig konsumiert
Nicht als Dogma, sondern als Arbeitsweise.
Warum NetBSD
NetBSD ist für diesen Versuch gut geeignet, weil es sehr kohärent aufgebaut ist.
- Kernel, Toolchain und Userspace kommen aus einem Source-Tree
- Base-System und Zusatzsoftware sind sauber getrennt
- Software wird in der Regel aus Quellen gebaut
- wenig Magie, wenig Sonderlogik
Das macht das System nicht „besser“ als andere, aber gut nachvollziehbar.
Und genau das ist hier der Punkt.
Hardware ist wieder relevant
Hardware wird teurer und schwerer planbar. Gleichzeitig stehen viele funktionierende Rechner herum, die technisch völlig ausreichend sind. Für ein System, das wenig Annahmen macht und auf unterschiedlichen Plattformen läuft, ist das kein Problem.
Im Gegenteil: Es eröffnet Möglichkeiten.
Klassische Architektur
Ich setze für dieses Projekt zunächst auf klassische Virtualisierung statt Container.
Nicht, weil Container schlecht sind, sondern weil ich klare Trennung will:
- ein System pro Aufgabe
- klare Grenzen
- wenig geteilte Zustände
Das ist einfacher zu verstehen, einfacher zu debuggen und einfacher zu dokumentieren.
NetBSD hängt in Bezug auf Containerisierung anderen Systemen aktuell etwas hinterher.
chroot existiert, mit den bekannten Einschränkungen – insbesondere im Hinblick auf Security.
Gleichzeitig sollte klar sein: Containerisierung ist kein Sicherheitsfeature, sondern primär ein Isolations- und Packaging-Mechanismus.
Für dieses Projekt setze ich daher bewusst auf gröbere Granularität bei den Dienstgrenzen. Weniger Feinzerlegung, dafür klarere Räume.
Unabhängig davon reizt mich die Idee, mich so tief in den NetBSD-Kernel einzuarbeiten, dass zumindest aus Sicht der Prozessverwaltung (Signale, Prozessgruppen, Sichtbarkeit) ein Mindestmaß an „Container-Flair“ entsteht – ähnlich dem, was Jails bei FreeBSD leisten.
Dokumentation
Ich dokumentiere meine Projekte sowieso immer sehr genau – für mich selbst.
In diesem Fall mache ich das öffentlich in meinem Blog. Nicht als Tutorial, nicht als Anleitung, sondern als nachvollziehbare Dokumentation eines echten Systems.
- Was gebaut wird.
- Warum es so gebaut wird.
- Was funktioniert.
- Was nicht.
Mehr nicht.
Fazit und Ausblick
Das hier ist kein Manifest und kein Gegenentwurf zur Industrie.
Es ist ein praktischer Versuch, wieder näher an die Systeme zu kommen: einfacher, direkter, verständlicher.
In den folgenden Artikeln dokumentiere ich den Aufbau Schritt für Schritt:
- Erstellung von NetBSD aus den Quellen
- Basisinstallation von NetBSD
- Build- und Paketkonzept
- Virtualisierung
- Netzwerkstruktur
- Storage-Layout
- Betrieb, Updates, Backup
Ziel ist ein System, das man nicht nur benutzt, sondern versteht.
Bildnachweis: Das NetBSD-Logo ist eine eingetragene Marke der NetBSD Foundation, Inc. Verwendung im Rahmen redaktioneller Berichterstattung gemäß den Richtlinien zur Logonutzung.