Welche Probleme löse ich – und für wen?

Thorsten Geppert

Ich werde immer wieder gefragt, was ich eigentlich genau mache. Die kurze Antwort: Ich entwickle Software und administriere Systeme, vornehmlich unter FreeBSD. Die längere Antwort ist dieser Beitrag.

Meine Arbeit bewegt sich im Spannungsfeld zwischen Softwareentwicklung, Infrastruktur und Systemarchitektur. Ich helfe dabei, Systeme zu bauen oder zu stabilisieren, die langfristig funktionieren – technisch sauber, verständlich und wartbar.

Softwareentwicklung: Qualität statt Fließband

In meinen Blog-Artikeln über Softwareentwicklung habe ich viel darüber geschrieben, was in Unternehmen schief läuft: unlesbarer Code, fehlende Architektur, technische Schulden, die niemand mehr anfasst, und ein Fokus auf Prozesse statt auf das Produkt selbst. Das ist keine abstrakte Kritik, sondern Dinge, die ich über viele Jahre hinweg in verschiedenen Unternehmen hautnah erlebt habe.

Daraus folgt, was ich anbiete: saubere, lesbare, wartbare Software. Code, den auch jemand anderes in fünf Jahren noch versteht. Ich habe langjährige Erfahrung in verschiedenen Programmiersprachen – von der systemnahen Programmierung bis hin zu komplexen GUI-Anwendungen mit Qt und wxWidgets. Datenbanken (insbesondere PostgreSQL) gehören ebenso dazu wie Server-Client-Architekturen und Netzwerkprogrammierung.

Wenn du ein Projekt hast, das aus dem Ruder gelaufen ist, das von einer Einzelperson entwickelt wurde und jetzt kaum noch jemand durchblickt, oder das dringend eine saubere Neuarchitektur braucht – dann bin ich die richtige Ansprechperson.

FreeBSD-Administration: Stabil, sicher, durchdacht

FreeBSD begleitet mich seit Version 4, also seit über zwei Jahrzehnten. Ich betreibe eigene Server damit, kenne ZFS mit RAIDz, FreeBSD-Jails, Bhyve, pf, CARP, HAST und die gängigen Netzwerkdienste (DNS, DHCP, NTP, NFS, Samba, LDAP u.v.m.) aus der täglichen Praxis – nicht nur aus der Dokumentation.

Was ich löse: Du brauchst einen stabilen, sicheren Server oder eine skalierbare Serverinfrastruktur unter FreeBSD? Du möchtest Dienste in Jails isolieren? Du hast ein laufendes System, das Pflege oder Erweiterung braucht? Oder du stehst vor einem konkreten Problem, das sich partout nicht lösen lässt? Ich bin mit solchen Situationen vertraut – und finde pragmatische Lösungen.

Für Unternehmen

Falls du als Unternehmen schaust: Ich bringe Softwareentwicklung und Systemadministration zusammen. Ich bin kein Spezialist, der nur eine Schraube dreht, sondern jemand, der Systeme im Ganzen versteht. Ich habe in Firmen gearbeitet, in denen beides gefragt war, und weiß, wie wichtig es ist, dass Entwicklung und Infrastruktur zusammenpassen.

Ich schätze eine Unternehmenskultur, in der Fehler als Lernmöglichkeit begriffen werden, Kompetenzen sinnvoll eingesetzt werden und das Produkt im Mittelpunkt steht – nicht das Verwalten von Tickets. Wenn das auch dein Ansatz ist, sollten wir sprechen (E-Mail: thorsten@tgeppert.de).

Hier meine Referenzen in Kurzform

Thorsten Geppert

Lebenslauf

OpenSource-Projekte

Verschiedenes

  • YouTube-Kanal (mit Themen über Programmierung, FreeBSD und verschiedene andere Dinge)

Autisten in der IT: Warum man sie einstellen sollte und was sie brauchen

admin Schreib einen Kommentar

Autismus und IT — das ist keine Zufallsbeziehung. Studien zeigen konsistent, dass Autisten in der IT-Branche überrepräsentiert sind. Das ist kein Klischee. Es ist eine Beobachtung, die sich in den Daten wiederfindet und die sich erklären lässt, wenn man versteht, was Autismus eigentlich ist: eine andere kognitive Architektur. Nicht besser. Nicht schlecher. Anders.

Und diese Andersartigkeit ist in der IT besonders wertvoll — weil die IT ein Feld ist, in dem Systemdenken, Mustererkennung und tiefes Eintauchen in komplexe Sachverhalte nicht nur nützlich sind, sondern die eigentliche Arbeitsgrundlage.

Aber es gibt auch eine Kehrseite: Die Arbeitswelt ist nicht für Autisten gebaut. Und das ist kein metaphorischer Satz — es ist eine konkrete Feststellung über Beleuchtung, Geräusche, Kommunikationsstrukturen, Erwartungshaltungen und Prozesse, die neurotypische Normalität als Default setzen.

Dieser Artikel beschreibt beides: Was Autisten in der IT leisten und was sie brauchen, um es leisten zu können.

Was Autismus in der IT bedeutet

Autismus ist ein Spektrum. Das bedeutet: Keine zwei Autisten sind gleich. Die folgenden Beschreibungen sind Muster, keine Diagnosekriterien, und sie treffen nicht auf jeden zu. Aber sie sind Muster, die sich in der Praxis häufig zeigen.

Wie Autisten denken

Systemdenken. Autisten tendieren dazu, Systeme als Ganzes zu erfassen — die Beziehungen zwischen Komponenten, die Regeln, die ein System steuert, die Architektur. Das ist nicht dasselbe wie „gut im Programmieren“. Es ist eine bestimmte Art, die Welt in Ordnung zu bringen: Wenn man die Regeln kennt, kann man das System verstehen. Wenn man das System versteht, kann man es verändern.

Mustererkennung. Autisten bemerken Muster, die andere übersehen. In Logfiles, in Codebases, in Fehlern, in Prozessen. Das ist keine übernatürliche Fähigkeit — es ist ein kognitiver Stil, der darauf ausgerichtet ist, Regelmäßigkeiten und Abweichungen zu identifizieren. In der IT ist das Gold wert: Debugging, Code-Review, Security-Analyse, Monitoring — alles Tätigkeiten, bei denen es darauf ankommt, das Anormale im Normalen zu finden.

Hyperfokus. Wenn ein Autist sich für ein Thema interessiert, kann er sich stundenlang damit beschäftigen, ohne Unterbrechung, ohne Langeweile, mit einer Intensität, die neurotypische Menschen selten erreichen. Das nennt man „Special Interest“ — und es ist kein Hobby, es ist eine kognitive Modalität. In der Praxis bedeutet das: Ein Autist, der sich für eine Codebase interessiert, wird sie verstehen — wirklich verstehen — auf eine Tiefe, die Wochen oder Monate normalem Lernfortschritt entspricht.

Detailorientierung. Autisten arbeiten oft von den Details nach oben: Erst die Einzelteile verstehen, dann das Gesamtsystem. Neurotypische Menschen tendieren zum umgekehrten Weg: Erst das Große, dann die Details. Beide Ansätze haben Berechtigung. Aber in der IT — wo ein fehlendes Semikolon eine Produktionsstörung verursacht, wo eine falsche Berechtigung ein Sicherheitsloch öffnet, wo ein Overflow einen Kernel-Crash auslöst — ist der detailorientierte Ansatz nicht nur nützlich, sondern notwendig.

Wo Autisten besonders wertvoll sind

Debugging und Fehleranalyse

Debugging ist Mustererkennung in Reinform: Etwas verhält sich anders als erwartet, und man muss herausfinden, warum. Autisten sind oft herausragend im Debugging, weil sie die Geduld haben, Schicht für Schicht abzutragen, und weil ihr Gehirn darauf programmiert ist, Abweichungen von Mustern zu bemerken.

Das ist kein Mythos. Es ist eine Konsequenz der Art, wie autistische Wahrnehmung funktioniert: Wenn man die Welt in Mustern wahrnimmt, fällt ein Musterbruch sofort auf.

Code-Review und Qualitätssicherung

Code-Review erfordert dieselben Fähigkeiten: Lesen, Verstehen, Abweichungen identifizieren. Autisten lesen Code oft anders als neurotypische Entwickler — sie nehmen ihn strukturierter, systematischer wahr. Sie bemerken Inkonsistenzen, die andere übersehen, weil für sie die innere Logik des Codes genauso präsent ist wie die Oberflächenbedeutung.

Systemadministration und Infrastruktur

Systemadministration ist ein Gebiet, in dem Autisten traditionell stark vertreten sind. Das ist kein Zufall: Die Arbeit erfordert tiefes Verständnis komplexer, vernetzter Systeme, Präzision in der Konfiguration und die Fähigkeit, bei Ausfällen ruhig und systematisch vorzugehen. Die Belohnung ist ein System, das funktioniert — ein klares, messbares Ergebnis. Das passt.

Security

Informationssicherheit ist ein Bereich, in dem autistische Stärken besonders zur Geltung kommen: Mustererkennung in Netzwerkverkehr, Analyse von Exploit-Ketten, Penetration Testing (systematisches Vorgehen nach klaren Regeln), Code-Audit (Abweichungen von sicheren Mustern finden). Die Hackerkultur war schon immer ein Ort, an dem neurodiverse Menschen willkommen waren — lange bevor Unternehmens-IT den Begriff „Diversity“ entdeckte.

Architektur und Design

Softwarearchitektur ist Systemdenken auf einer höheren Ebene: Wie interagieren Komponenten? Was sind die Abhängigkeiten? Wo sind die Engpässe? Autisten, die von Natur aus Systeme denken, haben hier einen echten Vorteil — besonders wenn die Architektur komplex ist und klare Struktur erfordert.

Dokumentation und Wissensmanagement

Autisten neigen dazu, Dinge vollständig und präzise zu dokumentieren — weil für sie eine unvollständige Dokumentation ein fehlerhaftes System ist. Das kann zu Perfektionismus führen (ein Risiko), aber es kann auch zu Dokumentation führen, die tatsächlich nützlich ist. In einer Branche, in der Dokumentation oft das Stiefkind ist, ist das wertvoll.

Die Herausforderungen

Jetzt der schwierige Teil. Denn die gleichen Eigenschaften, die Autisten in der IT wertvoll machen, können in einer Arbeitsumgebung, die nicht für sie gebaut ist, zu massiven Problemen führen.

Sensorische Überlastung

Das ist das Problem, das am meisten unterschätzt wird und das am häufigsten zu Burnout führt.

Büros sind für neurotypische Menschen gebaut: Offene Raumkonzepte, Neonbeleuchtung, Hintergrundmusik, Gespräche, Tastaturklackern, Klimaanlagenbrummen. Für Autisten ist das keine Unannehmlichkeit — es ist ein permanenter Angriff auf das sensorische System. Das Gehirn muss kontinuierlich filtern, was für neurotypische Menschen automatisch gefiltert wird. Das kostet Energie. Energie, die dann für die eigentliche Arbeit fehlt.

Die Konsequenz: Ein Autist, der in einem Open-Office acht Stunden arbeitet, leistet nicht 80% von dem, was er in einem ruhigen Raum leisten könnte. Sondern vielleicht 30%. Weil der Großteil der kognitiven Kapazität in die Sensorik-Filterung geht.

Kommunikationsstrukturen

Neurotypische Kommunikation ist implizit: Tonfall, Mimik, Kontext, das Ungesagte zwischen den Zeilen. Autistische Kommunikation ist explizit: Man sagt, was man meint, und meint, was man sagt. Das führt zu Missverständnissen in beide Richtungen:

  • Autist zu neurotypisch: „Das wird nicht funktionieren.“ — Gemeint: Die Architektur hat ein grundlegendes Problem. — Verstanden: Der Autist ist negativ und unmotiviert.
  • Neurotypisch zu Autist: „Wir sollten uns das mal ansehen.“ — Gemeint: Mach das bitte bis morgen. — Verstanden: Irgendwann, wenn es passt, soll man sich das ansehen.

Die Implizitheit neurotypischer Kommunikation ist für Autisten eine ständige Quelle von Unsicherheit. Man weiß nie genau, was gemeint ist. Man rät. Man rät oft falsch. Das erzeugt Stress. Und Stress erzeugt Fehler.

Meetings

Meetings sind für viele Autisten eine Qual. Nicht, weil sie nicht zuhören können — sondern weil sie zu gut zuhören. Jedes Nebengeräusch, jede Unterbrechung, jedes gleichzeitige Gespräch wird wahrgenommen und verarbeitet. Nach einem einstündigen Meeting ist ein Autist oft erschöpft, ohne auch nur eine produktive Zeile Code geschrieben zu haben.

Dazu kommt: Meetings verlangen schnelles Reagieren. „Was denkst du dazu?“ — und man hat drei Sekunden Zeit. Autisten brauchen oft länger, um eine Antwort zu formulieren — nicht, weil sie langsamer denken, sondern weil sie gründlicher denken. Sie wollen die vollständige Antwort, nicht die schnelle.

Wechselnde Anforderungen und Kontextwechsel

Autisten bevorzugen Vorhersehbarkeit. Ein Arbeitstag, der um 9:00 mit einer bekannten Aufgabe beginnt und um 17:00 mit einem fertigen Ergebnis endet, ist ideal. Ein Arbeitstag, der um 9:00 mit einer Aufgabe beginnt, um 10:30 mit einem „Kannst du kurz in dieses Meeting?“ unterbrochen wird, um 11:15 eine Slack-Nachricht mit einer „dringenden“ Frage bekommt, und um 14:00 erfährt, dass die Anforderungen geändert wurden — das ist nicht „normaler Arbeitstag“. Das ist ein kognitiver Angriff.

Jeder Kontextwechsel kostet autistischen Menschen mehr Energie als neurotypischen. Das ist kein Mythos, es ist messbar in den kognitiven Ressourcen, die für das Umschalten aufgewendet werden müssen. Das bedeutet: Ein Arbeitstag mit drei Unterbrechungen ist produktiver als ein Arbeitstag mit dreißig — und der Unterschied ist nicht marginal.

Masking

Masking ist der Versuch, neurotypisch zu erscheinen: Blickkontakt simulieren, Smalltalk führen, unauffällig sein. Fast alle Autisten in der IT machen es. Es ist Überlebensstrategie, nicht Wahl.

Das Problem: Masking kostet enorme Mengen Energie. Energie, die für die eigentliche Arbeit fehlt. Und es führt zu langfristigen psychischen Belastungen — Burnout, Depression, Identitätsverlust. Autisten, die jahrelang gemasked haben, berichten davon, dass sie irgendwann nicht mehr wissen, wer sie eigentlich sind.

Unklare Erwartungen

„Sei ein Teamplayer.“ „Zeige Initiative.“ „Kommunikation ist wichtig.“ — Das sind keine klaren Erwartungen. Das sind Interpretationsspielräume. Für Autisten ist das ein Minenfeld: Was heißt „Teamplayer“? Soll man Meetings besuchen? Soll man helfen? Soll man Freundschaften schließen? Was heißt „Initiative“? Soll man Aufgaben übernehmen, die niemand zugewiesen hat? Soll man Vorschläge machen? Wie oft? In welchem Format?

Neurotypische Menschen verstehen diese Implizitheiten intuitiv. Autisten verstehen sie nicht — und werden oft als „schwierig“ oder „nicht kooperativ“ wahrgenommen, weil sie nachfragen, was genau gemeint ist.

Wie man Autisten unterstützt

Die gute Nachricht: Die meisten Maßnahmen, die Autisten helfen, sind weder teuer noch aufwendig. Sie erfordern nur das Bewusstsein, dass die Default-Einstellungen der Arbeitswelt nicht für alle optimal sind.

Räumliche Anpassungen

Ruhige Arbeitsplätze. Ein eigenes Büro, ein ruhiger Winkel, Noise-Cancelling-Kopfhörer — das ist keine „Sonderbehandlung“, es ist eine sinnvolle Arbeitsplatzgestaltung. Ein Autist in einem ruhigen Raum leistet mehr als zwei Autisten in einem Open-Office.

Beleuchtung. Neonröhren, die flackern, können für Autisten körperlich schmerzhaft sein. Dimmbare LED-Panels, Tageslichtlampen, die Möglichkeit, das Licht anzupassen — kleine Änderungen, große Wirkung.

Sitzplatzwahl. Nicht mit dem Rücken zur Tür. Nicht direkt neben dem Kaffeeautomaten. Nicht am Durchgang. Das sind keine Vorlieben — das sind Anforderungen.

Kommunikative Anpassungen

Explizit sein. „Bitte erledige das bis Freitag 17:00 Uhr“ statt „Wir brauchen das bald.“ „Schreib eine E-Mail mit den drei wichtigsten Punkten“ statt „Kommunikation wäre gut.“ Je präziser, desto besser.

Schriftlich bevorzugen. Asynchrone Kommunikation — E-Mails, Tickets, Dokumentation — ist für Autisten oft viel besser als synchrone — Meetings, Telefonate, spontane Gespräche. Nicht weil sie nicht kommunizieren wollen, sondern weil schriftliche Kommunikation ihnen die Zeit gibt, die sie brauchen, um präzise zu antworten.

Nicht auf sofortige Antworten bestehen. Wenn man jemanden in einem Meeting fragt und keine sofortige Antwort bekommt, heißt das nicht, dass er nichts zu sagen hat. Es heißt, dass er nachdenkt. „Lass uns das nach dem Meeting schriftlich klären“ ist eine einfache und wirkungsvolle Anpassung.

Strukturelle Anpassungen

Vorhersehbarkeit. Klare Arbeitszeiten, klare Aufgaben, klare Deadlines. Änderungen frühzeitig ankündigen, nicht spontan überstülpen. Sprint-Planung statt Ad-hoc-Zuweisung.

Geschützte Fokuszeiten. Blöcke von 2-4 Stunden, in denen keine Meetings angesetzt werden und Slack auf stumm geschaltet ist. Das ist kein Luxus — es ist die Zeit, in der die eigentliche Arbeit passiert.

Onboarding anpassen. Autisten brauchen oft länger für das Onboarding, weil sie ein System vollständig verstehen wollen, bevor sie damit arbeiten. Das ist kein Nachteil — es bedeutet, dass sie nach dem Onboarding tiefer verstehen als jemand, der sich schnell zurechtfindet.

Kulturelle Anpassungen

Masking nicht erwarten. Wenn ein Autist keinen Blickkontakt macht, ist das kein Zeichen von Desinteresse. Wenn er keinen Smalltalk macht, ist das kein Zeichen von Unhöflichkeit. Es ist ein Zeichen dafür, dass er Energie für die eigentliche Arbeit aufspart.

Direkte Kommunikation zulassen. „Das wird nicht funktionieren“ ist kein Angriff. Es ist eine Einschätzung. Wer direkte Kommunikation als Konflikt wahrnimmt, muss seine Konfliktwahrnehmung kalibrieren — nicht den Autisten bitten, diplomatischer zu sein.

Spezialinteressen ernst nehmen. Wenn ein Autist sich für ein Thema begeistert, ist das keine „Obsession“. Es ist eine Ressource. Ein Entwickler, der sich tief für Compilerbau interessiert, wird ein besseres Build-System bauen als jemand, dem es egal ist.

Warum man Autisten einstellen sollte

Jetzt die wirtschaftliche Perspektive, weil die menschliche offensichtlich sein sollte, es aber leider oft nicht ist.

Autisten sind keine Diversitäts-Checkbox

Wenn Unternehmen Autisten einstellen, um eine Diversitätskennzahl zu erfüllen, haben sie schon verloren. Nicht weil Diversität unwichtig wäre — sondern weil der Ansatz das Problem ist. Man stellt Autisten ein, weil sie exzellent sind. Weil sie Dinge können, die andere nicht können. Weil sie Probleme lösen, die andere nicht einmal sehen.

Die Diversität ist ein Nebeneffekt, kein Ziel.

Messbare Vorteile

Tiefe Expertise. Ein Autist, der sich auf ein Gebiet spezialisiert hat, hat oft ein Wissensniveau, das Neurotypische in derselben Zeit nicht erreichen. Das Hyperfokus-Phänomen ist real: Wenn jemand 16 Stunden am Tag in eine Codebase vertieft ist, versteht er sie besser als jemand, der 8 Stunden mit Unterbrechungen arbeitet.

Geringere Fluktuation. Autisten wechseln seltener den Arbeitgeber, wenn die Rahmenbedingungen stimmen. Nicht aus Loyalität — aus Pragmatismus: Einen Arbeitsplatz, der funktioniert, wechselt man nicht für ein höheres Gehalt. Das spart Recruiting-Kosten, Onboarding-Zeit und implizites Wissen, das mit jedem Wechsel verloren geht.

Innovation durch andere Perspektive. Autisten denken anders. Das ist kein Buzzword — es ist eine Konsequenz einer anderen kognitiven Architektur. Wenn ein Team aus lauter Menschen besteht, die ähnlich denken, entstehen blinde Flecken. Ein Autist im Team kann den blinden Flecken sichtbar machen — weil für ihn das, was für alle „offensichtlich“ ist, oft nicht offensichtlich ist.

Präzision und Qualität. Autisten haben oft einen höheren Qualitätsanspruch als ihre neurotypischen Kollegen. Das kann zu Konflikten führen („Es ist gut genug“), aber es führt auch zu Software, die tatsächlich funktioniert. Die Frage ist, ob „gut genug“ wirklich gut genug ist — oder ob man jemanden braucht, der das letzte Prozent mitnimmt.

Zuverlässigkeit. Autisten halten sich an Regeln. Das ist keine Charaktereigenschaft — es ist eine kognitive Notwendigkeit. Wenn die Regel sagt, dass ein Deployment-Pipeline durchlaufen muss, bevor Code in Produktion geht, wird ein Autist keinen Shortcut nehmen. In einer Branche, in der Shortcuts zu Ausfällen führen, ist das wertvoll.

Was Autisten selbst tun können

Dieser Artikel wäre unvollständig, wenn er nur die Umgebung adressieren würde. Autisten sind nicht passive Empfänger von Anpassungen — sie können aktiv dazu beitragen, dass die Zusammenarbeit funktioniert.

Kommunizieren, was man braucht. „Ich arbeite am besten, wenn ich ungestört bin.“ „Ich brauche Aufgaben schriftlich.“ „Meetings erschöpfen mich — kann ich asynchron teilnehmen?“ Das ist keine Schwäche — es ist Professionalität. Wer seine Arbeitsbedingungen kennt und kommuniziert, ist besser als jemand, der schweigt und dann nicht liefert.

Grenzen setzen. Nicht jedes Meeting muss man besuchen. Nicht jede Slack-Nachricht muss man sofort beantworten. Nicht jede Einladung zum After-Work muss man annehmen. Grenzen zu setzen ist kein egoistisch — es ist notwendig, um langfristig leistungsfähig zu bleiben.

Stärken einsetzen. Wenn man gut im Debugging ist, dann debuggt man. Wenn man gut in der Dokumentation ist, dann dokumentiert man. Wenn man gut in der Architektur ist, dann archtektiert man. Die Gesellschaft — und insbesondere die IT — neigt dazu, Schwächen zu fixieren statt Stärken zu nutzen. Das ist ineffizient.

Burnout-Signale ernst nehmen. Wenn man merkt, dass man erschöpft ist, dass die Sensorik überlastet ist, dass das Masking nicht mehr funktioniert — dann ist es Zeit, etwas zu ändern. Nicht durchzuhalten. Durchhalten ist die Falle, in die Autisten besonders leicht tappen, weil sie gelernt haben, dass ihre Bedürfnisse „unnormal“ sind.

Die unbequeme Wahrheit

Die IT-Branche profitiert massiv von Autisten. Sie hat davon immer profitiert — lange bevor jemand den Begriff „Neurodiversität“ kannte. Die Pioniere der Informatik waren oft Menschen, die heute als autistisch diagnostiziert würden: Alan Turing, Grace Hopper, Dennis Ritchie — Menschen mit einer Intensität und einem Systemdenken, das nicht „normal“ war, aber das Feld erst möglich gemacht hat.

Die unbequeme Wahrheit ist: Die IT braucht Autisten mehr, als Autisten die IT brauchen. Ohne autistische Denkmuster gäbe es keine Betriebssysteme, keine Compiler, keine Netzwerkprotokolle, keine Kryptografie — keine der Infrastrukturen, auf denen die gesamte moderne Softwarewelt aufbaut.

Und trotzdem ist die Arbeitswelt so gebaut, dass sie die Menschen ausschließt, die sie am meisten braucht.

Das ist kein Trugschluss. Das ist eine Beobachtung. Und es ist eine Aufforderung: Wenn die IT Autisten beschäftigen will — und sie will es, auch wenn sie es nicht so nennt —, dann muss sie aufhören, neurotypische Normalität als Default zu setzen und alles andere als Anpassung zu behandeln.

Ein ruhiger Arbeitsplatz ist keine Sonderbehandlung. Schriftliche Kommunikation ist keine Zumutung. Explizite Erwartungen sind kein Mikromanagement. Es sind vernünftige Arbeitsbedingungen, die allen helfen — nicht nur Autisten.

Und der größte Gewinn ist nicht die Diversitätskennzahl. Der größte Gewinn ist, dass jemand, der Systeme wirklich versteht, in einem System arbeiten kann, das ihn nicht ständig bekämpft.

Infrastructure as Code: Warum Handarbeit auf Servern gefährlich ist

admin Schreib einen Kommentar

Jeder Systemadministrator kennt den Moment: Man meldet sich auf einem Server an, führt ein paar Befehle aus, ändert eine Konfigurationsdatei, installiert ein Paket. Alles funktioniert. Ein paar Wochen später steht man vor demselben Problem — nur auf einem anderen Server. Und man kann sich nicht mehr erinnern, welche Befehle man ausgeführt hat. Der Server ist ein Schneemann: Er sieht aus wie die anderen, aber unter der Oberfläche ist alles anders.

Infrastructure as Code (IaC) ist die Antwort auf dieses Problem. Und wer als Softwareentwickler und Administrator — wie ich — beide Welten kennt, weiß, dass IaC nicht nur ein Trend ist, sondern eine Notwendigkeit.

Das Problem mit manuellen Servern

Manuelle Administration skaliert nicht. Das ist keine Meinungsfrage, sondern Mathematik. Wenn jeder Server ein Unikat ist, dann ist jeder Server ein Risiko. Wenn ein Server ausfällt und niemand weiß, wie er konfiguriert war, dann ist der Wiederherstellungsprozess ein Glücksspiel.

Die typischen Symptome sind vertraut:

  • Konfigurationsdrift. Server, die identisch sein sollten, unterscheiden sich in subtilen — und manchmal kritischen — Details.
  • Wissensmonopole. Nur eine Person weiß, wie ein bestimmter Server konfiguriert ist. Wenn diese Person krank wird oder geht, ist das Wissen weg.
  • Nicht-reproduzierbare Zustände. Ein Server funktioniert, aber niemand kann erklären, warum. Oder schlimmer: Niemand kann ihn neu aufsetzen.
  • Angst vor Änderungen. Weil niemand weiß, was passieren wird, wenn man etwas ändert, ändert man nichts. Bis man es muss. Und dann ist es zu spät.

Was Infrastructure as Code bedeutet

IaC ist nicht einfach „Skripte schreiben“. Es ist ein Paradigmenwechsel in der Art und Weise, wie wir über Infrastruktur denken.

Deklarativ statt imperativ. Statt zu beschreiben wie ein Server konfiguriert werden soll („installiere nginx, kopiere die Konfiguration, starte den Dienst“), beschreibt man was der Zustand sein soll („nginx muss installiert sein, die Konfiguration muss diesen Inhalt haben, der Dienst muss laufen“). Der IaC-Workflow kümmert sich um das Wie.

Versioniert. Jede Änderung an der Infrastruktur ist in Git committet. Man kann sehen, wer was wann geändert hat. Man kann zu einem früheren Zustand zurückkehren. Man kann Änderungen über Code-Reviews prüfen lassen.

Reproduzierbar. Wenn ein Server ausfällt, kann er aus der IaC-Definition komplett neu aufgesetzt werden. Wenn ein neuer Server benötigt wird, kann er in Minuten statt Stunden erstellt werden.

Testbar. Bevor eine Änderung auf Produktion geht, kann sie in einer Testumgebung validiert werden. Syntaxfehler, fehlende Abhängigkeiten, inkompatible Konfigurationen — alles wird erkannt, bevor es Schaden anrichtet.

Die Werkzeuge

Die Wahl des Werkzeugs hängt vom Kontext ab. Hier eine Übersicht der etablierten Optionen:

Ansible

Das probably bekannteste IaC-Werkzeug. Ansible ist agentenlos (arbeitet über SSH), verwendet YAML für die Konfiguration und hat eine flache Lernkurve. Für FreeBSD-Administratoren ist es attraktiv, weil es native Module für ZFS, Jails, pkg und andere FreeBSD-Spezifika hat.

- name: ZFS-Dataset für Backup erstellen
  community.general.zfs:
    name: tank/backup
    state: present
    extra_zfs_properties:
      compression: zstd
      atime: off
      mountpoint: /backup

Der Nachteil: Ansible ist langsam bei großen Infrastrukturen und die YAML-Syntax wird bei komplexen Logiken unübersichtlich.

Terraform / OpenTofu

Für Cloud-Infrastrukturen ist Terraform (oder der Open-Source-Fork OpenTofu) der De-facto-Standard. Es verwaltet die Infrastruktur als Ressourcen — Instanzen, Netzwerke, Sicherheitsgruppen, Speicher — und hält den Zustand in einer State-Datei.

resource "aws_instance" "freebsd" {
  ami           = "ami-0xfreebsd15"
  instance_type = "t3.medium"

  tags = {
    Name = "freebsd-prod"
  }
}

Pulumi

Pulumi geht einen anderen Weg: Statt YAML oder HCL verwendet man echte Programmiersprachen — Python, TypeScript, Go. Das erlaubt echte Logik, Schleifen, Bedingungen und Typsicherheit.

import pulumi
import pulumi_command as command

server = command.remote.Command("freebsd-setup",
    connection=command.remote.ConnectionArgs(
        host="10.0.0.1",
        user="root",
    ),
    create="pkg install -y nginx",
)

Für FreeBSD: Besonderheiten

FreeBSD bringt eigene Werkzeuge mit, die in der IaC-Welt eine Sonderrolle einnehmen:

  • Jails sind leichtgewichtige Container, die sich hervorragend mit Ansible oder Shell-Skripten verwalten lassen.
  • ZFS bietet programmierbare Snapshots und Replikation, die sich in IaC-Workflows integrieren lassen.
  • pkgbase (seit FreeBSD 15.0) macht das Basissystem selbst paketierbar und damit IaC-kompatibel.

Der Pfad zur Einführung

IaC lässt sich nicht über Nacht einführen. Aber man kann schrittweise vorgehen:

  1. Bestandsaufnahme. Welche Server gibt es? Welche Konfigurationen? Was ist dokumentiert, was nicht?
  2. Ersten Server codifizieren. Den einfachsten Server nehmen und seine Konfiguration in Ansible (oder ein anderes Werkzeug) übertragen. Das dient als Lernprojekt und als Template.
  3. Neue Server nur noch via IaC. Jeder neue Server wird ausschließlich über Code konfiguriert. Keine manuellen Änderungen mehr.
  4. Bestehende Server migrieren. Nach und nach die manuelle Konfiguration durch IaC-Definitionen ersetzen. Das ist der langwierigste Teil.
  5. CI/CD für Infrastruktur. Änderungen an der IaC-Definition werden automatisch in Testumgebungen deployed, bevor sie auf Produktion gehen.

Die Kultur ändert sich mit

IaC ist nicht nur ein technischer Wechsel, sondern ein kultureller. Plötzlich sind Konfigurationsänderungen sichtbar. Jeder kann sie sehen, kommentieren, zurückrollen. Das ist ungewohnt — besonders für Administratoren.

Aber es ist der richtige Weg. In einer Welt, in der Sicherheitseinheiten täglich nachweisen müssen, welche Konfiguration auf welchem Server zu welchem Zeitpunkt aktiv war, ist manuelle Administration ein Risiko, das man sich nicht mehr leisten kann.

Und für den einzelnen Administrator ist IaC eine Erleichterung: Man muss sich nicht mehr erinnern, was man auf welchem Server gemacht hat. Es steht alles im Git-Repository. Wenn man nicht weiß, wie ein Server konfiguriert ist — man schaut nach. Immer. Zuverlässig. Ohne Ausnahme.

Automatisierung als Geschäftsmodell: Warum IT-Dienstleister ohne Automatisierung untergehen

Thorsten Geppert Schreib einen Kommentar

Wer IT-Dienstleistungen verkauft, hat ein Problem: Seine Zeit ist begrenzt. Jede Stunde, die er an einem Kundensystem verbringt, ist eine Stunde, die er nicht für einen anderen Kunden aufwenden kann. Das Geschäftsmodell des klassischen IT-Dienstleisters — Stunden abrechnen, Probleme manuell lösen, individuell betreuen — hat eine harte Decke.

Automatisierung ist der Weg durch diese Decke. Und wer als Softwareentwickler und Administrator die Werkzeuge beherrscht, hat einen entscheidenden Vorteil: Er kann Automatisierung nicht nur anwenden, sondern bauen.

Das Problem mit dem Stundensatz

Ein klassischer IT-Dienstleister verrechnet vielleicht 80 bis 120 Euro pro Stunde. Wenn er 40 Stunden in der Woche arbeitet (realistisch sind es weniger, weil Akquise, Verwaltung und Reisezeit abgehen), ergibt das eine Umsatzdecke von etwa 160.000 bis 240.000 Euro im Jahr. Davon gehen Steuern, Versicherungen, Fortbildung, Arbeitsplatzkosten ab.

Skalierung ist in diesem Modell nur möglich, indem man Mitarbeiter einstellt. Aber jeder Mitarbeiter bringt neuen Verwaltungsaufwand, Schulungsbedarf, Qualitätskontrolle. Der Gewinn pro Kopf sinkt, wenn man nicht gleichzeitig die Effizienz steigert.

Was Automatisierung ändert

Automatisierung verändert die Mathematik. Statt eine Aufgabe einmal pro Kunde manuell zu erledigen, baut man sie einmal — und deployt sie x-mal.

Beispiel: Ein Kunde braucht einen Webserver mit Nginx, PHP-FPM, SSL-Zertifikaten und einer Monitoring-Lösung. Manuell dauert das — wenn man ehrlich ist — einen halben Tag. Mit Automatisierung dauert es beim ersten Kunden auch einen halben Tag (zuzüglich der Zeit für das Skript/Playbook). Bei jedem weiteren Kunden dauert es fünf Minuten.

Der Effekt: Die Kosten pro Deployment sinken drastisch, während die Qualität steigt. Automatisierte Deployments sind reproduzierbar, testbar, dokumentiert. Manuelle Deployments sind — wie oben beschrieben — Schneemänner.

Konkrete Automatisierungsfelder

Systemadministration

Alles, was auf einem Server konfiguriert wird, kann automatisiert werden:

  • Server-Setup — Basiskonfiguration, Benutzer, SSH-Keys, Firewall-Regeln
  • Dienst-Konfiguration — Webserver, Datenbanken, Mailserver, Monitoring
  • Updates und Patching — Automatisierte Aktualisierungen mit Rollback-Möglichkeit
  • Backup und Recovery — ZFS-Snapshots, Replikation, automatisierte Restore-Tests

Kundenschnittstelle

  • Onboarding — Neukunden bekommen automatisch ihre Infrastruktur
  • Reporting — Wöchentliche Statusberichte automatisch generiert und versendet
  • Abrechnung — Nutzungsbasierte Abrechnung direkt aus Monitoring-Daten
  • Ticket-Routing — Automatische Zuordnung von Support-Anfragen

Compliance und Dokumentation

  • Audit-Logs — Jede Änderung an der Infrastruktur ist in Git dokumentiert
  • Compliance-Checks — Automatisierte Überprüfung von Sicherheitsstandards
  • Disaster-Recovery-Tests — Regelmäßige, automatisierte Tests der Wiederherstellungsprozesse

Der Preis der Automatisierung

Automatisierung ist nicht kostenlos. Sie erfordert:

Zeit. Die Erstellung eines robusten Ansible-Playbooks dauert länger als die manuelle Konfiguration eines einzelnen Servers. Die Investition amortisiert sich erst ab dem zweiten oder dritten Deployment.

Kompetenz. Wer automatisiert, muss programmieren können. Nicht auf dem Niveau eines Software-Entwicklers, aber ausreichend, um Skripte zu schreiben, Datenstrukturen zu verstehen und Fehler zu diagnostizieren.

Wartung. Automatisierte Prozesse müssen gepflegt werden. Wenn sich Upstream-Software ändert, müssen die Playbooks angepasst werden. Wenn neue Anforderungen dazukommen, müssen sie integriert werden.

Aber — und das ist der entscheidende Punkt — diese Kosten fallen einmal an. Die manuellen Kosten fallen jedes Mal an.

Vom Dienstleister zum Produkt

Die konsequente Automatisierung öffnet einen Weg, der über das Dienstleistungsgeschäft hinausgeht: den Übergang zum Produkt.

Wenn die Infrastruktur-Einrichtung automatisiert ist, kann man sie als Self-Service anbieten. Der Kunde wählt seine Konfiguration über ein Web-Interface, das System richtet alles automatisch ein, und der Dienstleister muss nur noch überwachen und bei Problemen eingreifen.

Das ist der Weg, den erfolgreiche IT-Unternehmen gegangen sind: Hetzner mit der Robot-Weboberfläche, GitLab mit seinem CI/CD-Produkt, HashiCorp mit Terraform Cloud. Alle haben begonnen, Dienstleistungen manuell zu erbringen, und sie dann in Produkte verwandelt.

Für kleine IT-Dienstleister bedeutet das nicht, dass man ein SaaS-Startup werden muss. Aber es bedeutet, dass man seine wiederkehrenden Aufgaben identifizieren, automatisieren und als Paket anbieten kann — zu einem Preis, der manuell nicht erreichbar ist.

Der erste Schritt

Wer mit Automatisierung anfangen will, sollte nicht versuchen, alles auf einmal umzustellen. Der beste erste Schritt ist:

  1. Den häufigsten wiederkehrenden Prozess identifizieren
  2. Ihn einmal vollständig automatisieren
  3. Die Zeitersparnis messen
  4. Den nächsten Prozess angehen

Bei mir war das die ZFS-Replikation mit Syncoid. Ein Prozess, der vorher jeden Abend manuell überprüft werden musste und regelmäßig Probleme verursacht hat. Nach der Automatisierung läuft er im Hintergrund — zuverlässig, reproduzierbar, fehlerfrei.

Die Zeit, die ich dadurch gewonnen habe, habe ich in die nächste Automatisierung investiert. Und die nächste. Irgendwann war der Punkt erreicht, an dem ich mehr Zeit für echte Problemlösung hatte als für wiederkehrende Aufgaben.

Das ist das Versprechen der Automatisierung. Und es hält, was es verspricht — wenn man den anfänglichen Aufwand investiert.

FreeBSD-Wochenrückblick: 6.–13. April 2026

Thorsten Geppert Schreib einen Kommentar

Die Kalenderwoche 15 bringt Bewegung in mehrere Baustellen: Der 15.1-Zeitplan ist offiziell, das Laptop-Projekt ruft zum Community-Test auf, OpenZFS bekommt endlich eine native relatime-Property, und auf freebsd-current wird hitzig über IPv6-only-RA-Flags und einen knote-Panic diskutiert.

FreeBSD 15.1: Zeitplan veröffentlicht, Code Slush am 17. April

Am 3. April verschickten die Release Engineers die offizielle Zeitplan-Erinnerung für FreeBSD 15.1. Die wichtigsten Termine:

MeilensteinGeplant
Code Slush beginnt17. April 2026
releng/15.1-Branch1. Mai
BETA11. Mai
RC122. Mai
RELEASE2. Juni

Der Code Slush startet also noch diese Woche: Ab dem 17. April sollten keine neuen Features mehr in den stable/15-Branch eingefügt werden. Commits sind weiterhin möglich, aber der Fokus verlagert sich auf Stabilität und Bugfixes.

Die Release Notes-Seite existiert bereits und listet die geplanten Neuerungen: KDE-Plasma-6-Installer-Option, verbesserte Realtek-WiFi-Unterstützung (RTW88/RTW89), aktualisierte Grafiktreiber und erweiterte Power-Management-Features.

Was das heißt: Wer noch Änderungen für 15.1 einbringen will, hat noch wenige Tage. Danach geht es in die Beta-Phase.

Laptop-Integration-Testing-Projekt: Aufruf an die Community

Die FreeBSD Foundation hat ein neues Community-Test-Programm ins Leben gerufen: das Laptop Integration Testing Project. LWN berichtete am 6. April darüber.

Die Idee: Die Foundation hat begrenzten Zugang zu Test-Hardware und will die Community einbinden. Freiwillige können FreeBSD auf ihrem Laptop testen und Ergebnisse über ein GitHub-Repository einreichen — ohne sich um Umgebungssetup, Formatierung oder Repo-Details kümmern zu müssen.

Besonders wertvoll: Nicht nur automatisierte Hardware-Erkennung, sondern auch manuelle Kommentare zur persönlichen Erfahrung mit FreeBSD auf dem jeweiligen Gerät. Die Ergebnisse werden in einer öffentlichen Kompatibilitäts-Matrix dargestellt.

Was das heißt: Endlich ein strukturierter Weg, Laptop-Kompatibilität zu dokumentieren. Wer FreeBSD auf einem Laptop nutzt, sollte das Repository besuchen und Ergebnisse einreichen — jeder Eintrag zählt.

Repository: github.com/FreeBSDFoundation/freebsd-laptop-testing

OpenZFS: Native relatime-Property für FreeBSD

Alexander Motin (amotin) hat am 1. April einen lang erwarteten Commit in OpenZFS gemerged: relatime als native ZFS-Property auf FreeBSD.

Bisher mussten FreeBSD-Nutzer, die relatime (relative Access-Time-Updates — atime wird nur geschrieben, wenn sie älter als mtime/ctime ist oder älter als 24 Stunden) nutzen wollten, auf den Mount-Option-Workaround zurückgreifen. Mit dem neuen Commit wird relatime zu einer echten ZFS-Dataset-Eigenschaft, die sich per zfs set relatime=on pool/dataset setzen lässt.

Die Implementierung folgt der Linux-Kernel-Logik: atime wird nur aktualisiert, wenn mindestens eine der Bedingungen erfüllt ist:

  • atime < mtime
  • atime < ctime
  • atime älter als 24 Stunden

Was das heißt: Weniger unnötige ZFS-Writes bei Lesezugriffen, besonders auf SSDs und Laptops. Wer atime=on braucht (z.B. für Maildir oder Backup-Tools), kann jetzt relatime=on setzen und bekommt das Beste aus beiden Welten.

Mailinglisten: IPv6-only-RA-Flag soll weichen

Pouria Mousavizadeh Tehrani hat am 2. April auf freebsd-current einen Vorschlag zur Diskussion gestellt: Die Entfernung der IPv6-only-RA-Draft-Implementierung zugunsten von RFC 8925 (DHCP-basierter Ansatz).

Hintergrund: Bjoern Zeeb hatte eine IPv6-only-Flag-Implementierung als IETF-Draft eingereicht, die auch im FreeBSD-Kernel und Userland vorhanden ist (standardmäßig nicht kompiliert, hinter DRAFT_IETF_6MAN_IPV6ONLY_FLAG). Das Draft wurde jedoch vom IETF aufgegeben, weil RA-Flags trivial fälschbar sind und für Malicious-Disabling von IPv4-Netzwerken missbraucht werden könnten. RFC 8925 verwendet stattdessen eine DHCP-Option, die in der Praxis durch DHCP Snooping besser geschützt ist.

Pouria bittet um Zustimmung, die Draft-spezifischen Codepfade zu entfernen und auf RFC 8925 zu migrieren. Bjoern ist cc’d, und die Diskussion läuft.

Was das heißt: Wer die experimentelle IPv6-only-RA-Flag nutzt, sollte auf RFC 8925 umsteigen. Die Code-Bereinigung ist ein guter Schritt — weniger tote Pfade im Kernel.

Mailinglisten: knote-Panic und etcupdate-Verlangsamung

Zwei aktuelle Probleme auf freebsd-current:

knote-Panic: Nach Commit d9d7b5948649 (main-n284826) tritt bei einigen Nutzern ein Panic auf: "knote ... was already on knlist...". Konstantin Belousov und Kyle Evans arbeiten an der Diagnose. Der Bug (Bugzilla #293382) betrifft closefp_impl und kann zu Deadlocks und Kernel-Crashes führen. Betroffen sind -CURRENT-Nutzer nach dem 2. April.

etcupdate doppelt so langsam: Bob Prohaska berichtet, dass etcupdate auf armv7 (Raspberry Pi 2) mittlerweile doppelt so lange dauert wie früher. Die Diskussion mit Dimitry Andric und Mark Millard legt nahe, dass die Ursache in der pkgbase-Umstellung und der veränderten Dateistruktur liegt — etcupdate muss mehr Dateien prozessieren.

Was das heißt: -CURRENT-Nutzer sollten den knote-Bug im Blick behalten. Auf armv7-Systemen lohnt es sich, etcupdate-Alternativen wie mergemaster zu evaluieren, bis das Problem behoben ist.

Ports: Chromium 146 und Security-Updates

Die Ports-Collection hat in dieser Woche mehrere Updates erhalten:

  • Chromium 146.0.7680.177 (1. April, René Nagy) — aktuelles Major-Release
  • Zuvor: Chromium 146.0.7680.164 mit VuXML-Eintrag für Sicherheitslücken in Versionen < 146.0.7680.164
  • Chromium 30. März: Revert eines Upstream-Commits, der das Datei-Dialog-Verhalten auf FreeBSD kaputtgemacht hatte

Die kontinuierlichen Chromium-Updates zeigen, dass die FreeBSD-Ports-Maintainer aktiv sind — aber auch, dass Upstream-Commits regelmäßig FreeBSD-spezifische Regressionen verursachen.

Neuer Committer: Kenneth Raplee

Am 4. April wurde Kenneth Raplee (kenrap@FreeBSD.org) als neuer Ports-Committer angekündigt. Willkommen im Projekt!

Ausblick auf die kommende Woche

  • 17. April: Code Slush für 15.1 beginnt — letzte Chance für Feature-Commits
  • Der knote-Bug in -CURRENT braucht einen Fix
  • Die IPv6-only-RA-Diskussion könnte zu einem Commit führen
  • Das Laptop-Testing-Projekt hofft auf erste Community-Ergebnisse

Syncoid: ZFS-Replikation ohne Umwege

Thorsten Geppert Schreib einen Kommentar

Wer ZFS nutzt, kennt das Gefühl: Man hat Snapshots, man hat zfs send und zfs recv, und theoretisch ist alles möglich. Praktisch steht man dann vor einer Pipe aus drei Befehlen, fragt sich, ob --verbose vor oder hinter -R gehört, und stellt fest, dass der inkrementelle Sendevorgang um Mitternacht abgebrochen hat, weil irgendein Snapshot auf der Zielseite fehlte.

Genau hier setzt Syncoid an.

Was ist Syncoid?

Syncoid ist Teil des Sanoid-Projekts von Jim Salter und beschreibt sich selbst schlicht als Replikationstool für ZFS. Das klingt bescheidener, als es ist. Tatsächlich löst Syncoid genau die Probleme, die jeden treffen, der ernsthaft ZFS-Daten zwischen Maschinen bewegen will:

  • Es findet selbst heraus, welcher Snapshot der letzte gemeinsame ist.
  • Es erzeugt bei Bedarf einen neuen Snapshot auf der Quelle.
  • Es überträgt inkrementell — nur die Differenz.
  • Es funktioniert lokal und remote, als Push und als Pull.
  • Es macht das alles mit einem einzigen Befehl.

Wer schon einmal versucht hat, eine ZFS-Replikation mit reinen Shell-Mitteln fehlerresistent aufzuziehen, weiß, dass das keine Kleinigkeit ist. Syncoid nimmt genau diesen Aufwand weg, ohne dabei die Kontrolle zu verlieren.

Die Grundlage: ZFS send und recv

Um zu verstehen, was Syncoid leistet, hilft ein Blick auf das, was es vereinfacht. ZFS bringt mit zfs send und zfs recv bereits ein mächtiges Werkzeug für die Replikation mit. Das Prinzip ist einfach: Ein Snapshot wird serialisiert und auf der anderen Seite wieder eingespielt. Inkrementell geht das auch — man sendet nur die Differenz zwischen zwei Snapshots.

In der Praxis sieht das dann so aus:

zfs send -R data/images/vm@syncoid_2026-04-07:12:00:00 | ssh remotehost "zfs recv backup/images/vm"

Das funktioniert. Bis es nicht mehr funktioniert. Weil ein Snapshot auf der Zielseite gelöscht wurde. Weil die SSH-Verbindung abbricht. Weil man vergessen hat, -I statt -i zu verwenden. Weil die Quellseite keine Snapshots hat, die die Zielseite erwartet.

Syncoid kümmert sich um all diese Fälle. Und das ist der eigentliche Mehrwert: nicht dass es zfs send aufruft — das kann jeder —, sondern dass es die Fehlerfälle abfängt, die im Alltag regelmäßig auftreten.

Loslegen: Einfacher geht es nicht

Die grundlegende Syntax ist so simpel, dass man sie sich kaum merken muss, weil sie offensichtlich ist:

syncoid data/images/vm backup/images/vm

Das repliziert den Dataset data/images/vm nach backup/images/vm — lokal, auf derselben Maschine. Beim ersten Lauf wird alles übertragen, bei jedem weiteren nur die Differenz.

Remote geht es genauso, nur mit dem üblichen SSH-Präfix:

syncoid data/images/vm root@remotehost:backup/images/vm

Das ist Push-Replikation: Die lokale Maschine sendet zum Remote. Pull geht auch:

syncoid root@remotehost:data/images/vm backup/images/vm

Hier zieht die lokale Maschine die Daten vom Remote. Der Unterschied mag marginal wirken, ist aber in der Praxis relevant: Pull bedeutet, dass die Backup-Maschine die Kontrolle hat und keinen SSH-Zugang zur Produktionsmaschine benötigt.

Rekursiv geht es mit -r:

syncoid -r rpool remotehost:tank/backup/rpool

Damit werden alle Child-Datasets unter rpool mit übertragen. Für ein vollständiges Backup ist das genau das, was man braucht.

Ohne Root: ZFS-Rechte delegieren

Einer der häufigsten Fehler bei ZFS-Backups ist, sie als root laufen zu lassen. Es funktioniert, aber es bedeutet, dass man root-SSH-Zugang zwischen Maschinen erlaubt. Das ist ein Sicherheitsrisiko, das sich vermeiden lässt.

Syncoid unterstützt den Betrieb ohne Root über --no-privilege-elevation. Dafür müssen auf beiden Seiten die entsprechenden ZFS-Berechtigungen delegiert werden:

Auf der Quellmaschine:

zfs allow -u syncuser send,hold,mount,snapshot,destroy rpool

Auf der Zielmaschine:

zfs allow -u syncuser compression,mountpoint,create,mount,receive,rollback,destroy tank/backup/rpool

Und dann:

syncoid --no-privilege-elevation -r rpool syncuser@remotehost:tank/backup/rpool

Das ist mehr Aufwand bei der Einrichtung, aber es ist der richtige Weg. Kein root-SSH, keine unnötigen Privilegien. Wenn man mit --use-hold arbeitet, kommt noch die release-Berechtigung dazu. Wer --create-bookmark nutzt, braucht bookmark auf der Quellseite.

Die Optionen, die man tatsächlich braucht

Syncoid hat eine überschaubare, aber nützliche Anzahl an Optionen. Die wichtigsten:

--compress: Kompression während der Übertragung. Unterstützt werden gzip, pigz-fast, pigz-slow, zstd-fast, zstd-slow, lz4, xz, lzo (Standard) und none. Wer über ein LAN synchronisiert, kann none wählen; über WAN ist zstd-fast eine gute Wahl.

--no-sync-snap: Standardmäßig erzeugt Syncoid bei jedem Lauf einen eigenen Snapshot. Wer das nicht möchte — etwa weil Sanoid die Snapshot-Verwaltung übernimmt oder weil man in ein Multi-Target-Setup repliziert —, der schaltet das mit --no-sync-snap ab. Verhindert die Anhäufung von Syncoid-Snapshots auf der Zielseite.

--create-bookmark: Setzt auf der Quelle ein Lesezeichen für den letzten erfolgreich replizierten Snapshot. Das ist besonders nützlich bei unregelmäßiger Replikation: Wenn der letzte gemeinsame Snapshot auf der Quelle bereits gelöscht wurde, kann das Bookmark den Zugriff auf den benötigten Punkt trotzdem ermöglichen. Funktioniert nur zusammen mit --no-sync-snap.

--use-hold: Setzt einen Hold auf den neuesten Snapshot auf Quell- und Zielseite und entfernt ihn erst nach dem nächsten erfolgreichen Lauf. Das verhindert, dass ein Snapshot gelöscht wird, bevor er repliziert wurde. Bei Multi-Target-Setups (A→B, A→C) kann man mit --identifier unterschiedliche Holds pro Ziel setzen.

--no-stream: Statt -I (alle Zwischensnapshots) wird -i (nur der neueste Snapshot) verwendet. Spart Bandbreite, wenn man die Zwischenschritte nicht braucht.

--exclude-datasets=REGEX: Schließt bestimmte Datasets von der Replikation aus. Kann mehrfach angegeben werden.

--source-bwlimit und --target-bwlimit: Bandbreitenlimitierung, falls mbuffer nicht verfügbar ist. Nützlich, wenn man die Übertragung nicht die ganze Leitung blockieren lassen möchte.

Snapshots und Pruning

Ein wichtiger Punkt: Syncoid ist agnostisch gegenüber der Snapshot-Verwaltung. Es löscht keine Snapshots auf der Zielseite, nur weil sie auf der Quelle gelöscht wurden. Das ist kein Fehler, sondern ein Feature — es schützt vor Datenverlust.

Für das Aufräumen alter Snapshots auf der Zielseite empfiehlt sich Sanoid mit einer Konfiguration wie dieser:

[backup/images/vm]
autoprune = yes
autosnap = no
frequently = 0
hourly = 36
daily = 30
monthly = 6
yearly = 0

autosnap = no, weil die Snapshots von Syncoid kommen und nicht von Sanoid erzeugt werden sollen. autoprune = yes, um alte Snapshots nach den definierten Regeln aufzuräumen. Das lässt sich mit Templates auch für viele Datasets gleichzeitig konfigurieren.

Oder, kürzer, mit einem Template:

[template_backup]
autoprune = yes
autosnap = no
hourly = 36
daily = 30
monthly = 6

[backup/images]
use_template = backup
recursive = yes

Die Kombination aus Syncoid für die Replikation und Sanoid für das Pruning ist das, was die meisten produktiven Setups verwenden. Und sie funktioniert genau deshalb gut, weil beide Werkzeuge ihre Zuständigkeit klar abgrenzen.

Praktisches Setup: Ein vollständiges Beispiel

Angenommen, man hat einen Server prod mit dem Pool zdata und einen Backup-Server backup mit dem Pool tank. Ziel: Tägliches inkrementelles Backup aller Datasets.

1. Sanoid auf prod einrichten (für die Snapshot-Erstellung):

/etc/sanoid/sanoid.conf

[zdata]
use_template = production

[template_production]
frequently = 0
hourly = 36
daily = 30
monthly = 3
yearly = 0
autosnap = yes
autoprune = yes

2. Cron-Job auf backup (Pull-Replikation):

0 2 * * * syncoid --no-sync-snap --compress=zstd-fast -r syncuser@prod:zdata tank/backup/zdata

3. Sanoid auf backup (für das Pruning):

[tank/backup/zdata]
use_template = backup

[template_backup]
autoprune = yes
autosnap = no
hourly = 36
daily = 30
monthly = 6
yearly = 0

Das ist im Grunde das komplette Setup. Drei Konfigurationsschritte, ein Cron-Job, und man hat eine robuste, inkrementelle ZFS-Replikation, die im Hintergrund läuft, ohne dass man sich darum kümmern muss.

Was man beachten sollte

Ein paar Dinge, die in der Dokumentation eher am Rande stehen, aber im Alltag relevant werden:

SSH-Konfiguration: Syncoid baut für jeden Lauf eine neue SSH-Verbindung auf. Bei häufiger Replikation lohnt sich ein Connection Multiplexing in der ~/.ssh/config:

Host backupserver
  HostName 192.168.1.50
  User syncuser
  ControlMaster auto
  ControlPath ~/.ssh/sockets/%r@%h-%p
  ControlPersist 600

Das spart den Verbindungsaufbau bei jedem Lauf.

mbuffer: Wenn auf beiden Seiten mbuffer verfügbar ist, nutzt Syncoid es automatisch. Das kann die Übertragungsrate deutlich verbessern, weil es die Pipeline puffert und verhindert, dass zfs send auf zfs recv warten muss.

Erstlauf dauert: Der erste Syncoid-Lauf überträgt den kompletten Dataset. Bei mehreren Terabyte bedeutet das: Zeit einplanen. Alle folgenden Läufe sind inkrementell und entsprechend schneller.

Kein Konfigurationsfile: Im Gegensatz zu Sanoid hat Syncoid keine Konfigurationsdatei. Alles wird über Kommandozeilen-Flags gesteuert. Das ist konsistent, bedeutet aber auch, dass man bei komplexeren Setups die Aufrufe entsprechend dokumentieren sollte.

Warum Syncoid und nicht rsync?

Die Frage ist naheliegend. rsync ist etabliert, gut dokumentiert und funktioniert auf jedem System. Aber rsync kennt ZFS nicht. Es kann nicht inkrementell auf Snapshot-Ebene arbeiten, es kann keine Block-Differenzierung nutzen, und es kann nicht garantieren, dass der Zielzustand konsistent ist.

ZFS-Snapshots sind atomar. Ein Snapshot repräsentiert den exakten Zustand eines Datasets zu einem bestimmten Zeitpunkt. Wenn man den repliziert, erhält man auf der Zielseite exakt diesen Zustand — nicht einen Zustand, bei dem einige Dateien schon aus dem Snapshot stammen und andere gerade im Flux sind.

Das ist kein akademischer Unterschied. Wer schon einmal ein Datenbank-Backup mit rsync gemacht hat und feststellen musste, dass die Dateien während der Übertragung verändert wurden, weiß, wovon die Rede ist.

Fazit

Syncoid ist eines dieser Werkzeuge, die man sich früher wünscht. Es nimmt einen wiederkehrenden, fehleranfälligen Prozess — ZFS-Replikation per Hand — und macht ihn zu einem einzelnen Befehl, der funktioniert. Nicht weil er Magie einsetzt, sondern weil er die Randfälle abdeckt, die man selbst immer vergisst: fehlende Snapshots, abgebrochene Verbindungen, falsche Flags.

Wer ZFS einsetzt und nicht bereits ein etabliertes Replikations-Setup hat, sollte Syncoid ausprobieren. Die Einstiegshürde ist minimal, der Nutzen ist sofort spürbar, und falls man doch mehr Kontrolle braucht: Die Optionen sind da, man muss sie nur nutzen.

Und wer Sanoid für die Snapshot-Verwaltung ohnehin schon im Einsatz hat — der hat Syncoid bereits installiert. Es ist Teil desselben Pakets. Man muss es nur nutzen.

Quellen

FreeBSD Änderungen der letzten Woche – 4. April 2026

Thorsten Geppert Schreib einen Kommentar

Übersicht

Diese Woche gab es wichtige Security Updates und interessante Entwicklungen im FreeBSD-Ökosystem. Hier sind die Highlights der letzten 7 Tage.

Wichtige Security Advisories

FreeBSD-SA-26:09.pf – PF Firewall Regelproblem

Datum: 26. März 2026
Betroffen: FreeBSD 14.x, 15.0
Schweregrad: Hoch

Problem: Die pf Firewall ignoriert bestimmte Regeln stillschweigend, was zu unbeabsichtigten Netzwerkzugriffen führen kann.

Lösung:

  • Patches für stable und release branches verfügbar
  • Upgrade via pkg upgrade oder freebsd-update
  • Workaround: Regeln mit Tables oder Labels umschreiben

CVE: CVE-2026-4652

FreeBSD-SA-26:07.nvmf – NVMe over Fabrics Problem

Datum: 25. März 2026
Betroffen: FreeBSD 15.0
Schweregrad: Mittel

Problem: Sicherheitslücke im NVMe over Fabrics Subsystem.

Behoben:

    1. März 2026 01:29 UTC (stable/15)
    1. März 2026 01:11 UTC (releng/15.0)

FreeBSD 14.4-RELEASE – Aktueller Status

FreeBSD 14.4 wurde am 10. März 2026 veröffentlicht und ist die fünfte Version des stable/14 Branch. Wichtige Neuerungen:

Hauptfeatures

  • OpenSSH 10.0p2 mit hybridem Post-Quantum-Algorithmus mlkem768x25519-sha256
  • OpenZFS 2.2.9 mit verbesserter Performance und Stabilität
  • Bessere cloud-init und nuageinit Kompatibilität
  • Neues p9fs(4) für Dateisystem-Sharing zwischen Host und bhyve-Gästen
  • Verbesserte Manpages und Dokumentationswerkzeuge

Support Zeitraum

FreeBSD 14.4 wird bis zum 31. Dezember 2026 unterstützt.

Ports und Packages Updates

pkgsrc-2026Q1 Branch

Der neue Quarterly Branch für pkgsrc wurde am 27. März angekündigt:

  • Aktualisierte Software-Pakete
  • Sicherheitsupdates
  • Verbesserte Abhängigkeitsauflösung

Wichtige Package-Updates

  • OpenSSL 3.5: Mehrere Security-Fixes
  • PostgreSQL 17: Performance-Verbesserungen
  • Python 3.12: Neue Features und Optimierungen
  • pkg 2.6.2_1: Verbesserte Package-Verwaltung

Entwicklung und Community

Google Summer of Code 2026

FreeBSD und NetBSD wurden für Google Summer of Code 2026 ausgewählt. Studenten können an verschiedenen Projekten arbeiten:

  • Kernel-Entwicklung
  • Tooling-Verbesserungen
  • Dokumentation

Release Schedule Änderungen

FreeBSD hat den Release-Zyklus angepasst:

  • Quarterly Releases: Alle 3 Monate
  • Biennial Releases: Alle 2 Jahre (Langzeit-Support)
  • Ziel: Bessere Sicherheit und einfachere Wartung

Systemadministration

Wichtige Befehle diese Woche

# PF Fix anwenden
freebsd-update fetch
freebsd-update install

# Oder via pkg
pkg upgrade

# ZFS Performance Monitoring
zpool iostat -v 1
zfs get all tank

Monitoring Empfehlungen

  • PF Rules überprüfen: pfctl -s rules
  • NVMe Status: nvmecontrol devlist
  • Security Updates: Regelmäßig freebsd-update ausführen

Sicherheitshinweise

BSI Warnungen

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat Updates zu folgenden FreeBSD-Sicherheitslücken veröffentlicht:

  • Lokale Schwachstellen in Jail-Implementierung
  • PF Firewall Regelumgehung
  • NVMe over Fabrics Probleme

Internationale Warnungen

  • Canadian Centre for Cyber Security: AV26-179 Advisory
  • DFN-CERT-2026-0689: Zwei lokale Schwachstellen

Ausblick nächste Woche

  • Weitere Updates für FreeBSD 15.0
  • Mögliche neue Security Advisories
  • Vorbereitungen für Google Summer of Code
  • Weitere Anpassungen am Release Schedule

Ressourcen

  • FreeBSD Security Advisories: https://www.freebsd.org/security/advisories/
  • FreeBSD Mailing Lists: https://lists.freebsd.org/
  • BSDSec Security Announcements: https://bsdsec.net/
  • FreeBSD Release Notes: https://www.freebsd.org/releases/14.4R/relnotes/

Ausführlicher Vergleich der BSD-Familie: FreeBSD, OpenBSD, NetBSD und DragonFlyBSD

Thorsten Geppert Schreib einen Kommentar

Inhaltsverzeichnis

  1. Einleitung und Geschichte
  2. Philosophie, Entwicklungsmodell und Lizenzierung
  3. Typische Einsatzszenarien – Wo welches BSD am besten passt
  4. Kernarchitektur im Detail
  1. Derivate, Spezialdistributionen und Ökosystem
  2. Pro‑ und Contra‑Tabellen – Schnellvergleich
  3. Entscheidungshilfe – Welches BSD ist das Richtige für mein Projekt?
  4. Zukünftige Entwicklungen und Roadmaps
  5. Quellen, weiterführende Literatur und Community‑Links

Einleitung und Geschichte

Die BSD‑Familie hat ihre Wurzeln in der Berkeley Software Distribution (BSD), die 1977 von der University of California, Berkeley, als Weiterentwicklung des frühen UNIX‑Systems veröffentlicht wurde. Die ersten öffentlichen BSD‑Versionen (1.0 – 4.3) legten das Fundament für den heute bekannten TCP/IP‑Protokoll‑Stack, der damals noch ein Forschungsexperiment war, heute aber das Rückgrat des Internets bildet.

Im Laufe der 1990er‑Jahre spaltete sich das Projekt in mehrere unabhängige Richtungen:

  • FreeBSD (gegründet 1993) fokussierte sich schnell auf Performance, Stabilität und eine umfangreiche Ports‑Sammlung für Drittsoftware.
  • OpenBSD (ab 1995) verfolgte das Ziel, ein so sicher wie möglich zu sein. Der Name selbst stammt von der Kombination aus „Open“ und „BSD“ und betont Transparenz.
  • NetBSD (1993) wählte den Pfad der Portabilität – das berühmte Motto „runs on anything“ stammt von NetBSD und spiegelt die Unterstützung von über 50 Prozessorarchitekturen wider.
  • DragonFlyBSD (2003) entstand aus einem Fork von FreeBSD 4.8, weil einige Entwickler mit der Entwicklungsgeschwindigkeit und den SMP‑Architekturen unzufrieden waren. Das Ergebnis: ein System, das stark auf Multi‑Core‑Skalierung und ein eigenes Dateisystem HAMMER2 setzt.

Diese unterschiedlichen Wurzeln bestimmen bis heute die Design‑Entscheidungen, das Community‑Verhalten und die Einsatzbereiche der einzelnen Betriebssysteme.

Philosophie, Entwicklungsmodell und Lizenzierung

ProjektZielsetzungEntwicklungsmodellLizenzierung
FreeBSDHoch‑performante Server‑ und Desktop‑PlattformZentralisiertes Kernteam, Commit‑Access über Core‑Team; offene Ports‑Tree-Pflege durch freiwillige MaintainerBSD‑Lizenz (2‑Clause) + CDDL für ZFS (Kompatibilitäts‑Ausnahme)
OpenBSDSicherheit über alles, Code‑Qualität, AuditsKleine, sehr konservative Entwicklergemeinschaft; Ein‑Person‑Commit‑Policy; jede Änderung wird auditiertBSD‑Lizenz (ähnlich der 2‑Clause); kein CDDL, alles rein Open‑Source
NetBSDPortabilität, Sauberkeit des Codes, Unterstützung exotischer HWDezentralisiert, Git‑basiertes Repository; pkgsrc (Quellpaket‑System) wird separat gepflegtBSD‑Lizenz (2‑Clause) – keine zusätzlichen Einschränkungen
DragonFlyBSDSkalierbare SMP‑Leistung, moderne DateisystemeKleines, fokussiertes Kernteam, schnelle Release‑Zyklen (alle 6‑8 Wochen)BSD‑Lizenz (2‑Clause)

Die Lizenzierung ist ein wichtiger Faktor für Unternehmen. FreeBSD enthält den CDDL‑Teil für ZFS, was in manchen Unternehmens‑Compliance‑Szenarien zu Diskussionen führt. OpenBSD, NetBSD und DragonFlyBSD verwenden ausschließlich die klassische BSD‑Lizenz, was ihre Nutzung in proprietären Projekten vereinfacht.

Typische Einsatzszenarien – Wo welches BSD am besten passt

Web‑ und Datenbank‑Server

FreeBSD ist dank ZFS‑Integration, Jails und einer ausgereiften TCP‑Stack‑Optimierung (z. B. TCP‑Fast‑Open, RACK‑Algorithmus) die erste Wahl für große Web‑Farmen. Unternehmen wie Netflix, Yahoo! und GitHub betreiben Teile ihrer Infrastruktur auf FreeBSD. OpenBSD wird eher für sicherheitskritische Front‑Ends eingesetzt, wo die Angriffsfläche minimal sein soll – beispielsweise als Reverse‑Proxy mit pf und httpd.

NetBSD wird selten in klassischen Web‑Umgebungen eingesetzt, findet aber in Embedded‑Gateways (Router, IoT‑Edge‑Devices) Verwendung, weil es auf ARM‑ und MIPS‑Boards läuft. DragonFlyBSD ist besonders attraktiv für Rechenzentren, die hohe Kernzahlen nutzen – das HAMMER2‑Dateisystem bietet native Deduplizierung, was Speicher‑Kosten senkt.

Firewall‑ und Router‑Appliance

pf wurde ursprünglich von OpenBSD entwickelt und später nach FreeBSD portiert. Heute ist pfSense (FreeBSD) und OPNsense (FreeBSD) die führenden Open‑Source‑Firewalls – sie bauen auf pf auf, bieten eine Web‑UI, Plugins für VPN, Captive‑Portal und IDS/IPS. OpenBSD selbst kann dank pf und spamd ebenfalls als reine Firewall dienen, wird aber seltener als eigenständige Appliance eingesetzt, weil es kein integriertes Web‑Frontend hat.

Embedded / IoT

NetBSD ist das klar dominante BSD‑Projekt für Embedded‑Systeme: Es läuft auf Raspberry Pi, BeagleBoard, MIPS‑Router, PowerPC‑Systemen und sogar auf Spielkonsolen. Die Clean‑room‑Entwicklung sorgt für stabile, deterministische Builds, die in der Industrie geschätzt werden. FreeBSD hat ebenfalls ARM‑Support, aber das Footprint ist größer, weshalb es primär in NAS‑Geräten (z. B. TrueNAS) verwendet wird.

Desktop / Workstation

FreeBSD selbst ist nicht primär für Desktop‑Nutzer gedacht, aber Projekte wie GhostBSD und MidnightBSD bieten fertig vorkonfigurierte Desktop‑Umgebungen (GNOME/KDE) mit ein‑Klick‑Installern. NetBSDs NomadBSD ist ein Live‑USB‑System, das persistent bleiben kann. DragonFlyBSD nutzt ebenfalls einen Desktop‑Installer, ist aber stärker auf Server‑Anwendungen ausgerichtet.

Storage‑Appliances und NAS

ZFS‑Integration macht FreeBSD zum bevorzugten Kernel für TrueNAS CORE (ehemals FreeNAS). Dort werden Snapshots, Replikation und RAID‑Z professionell verwaltet. DragonFlyBSD bietet HAMMER2, das ebenfalls Copy‑on‑Write, Snapshots und Deduplizierung unterstützt – ideal für Backup‑Server, die große Datenmengen deduplizieren wollen.

Kernarchitektur im Detail

Dateisysteme und Speicherverwaltung

  1. FreeBSD – ZFS
  • ZFS ist ein Copy‑on‑Write‑Dateisystem, das Datenintegrität durch Checksummen gewährleistet. Es unterstützt Kompression, Deduplizierung, scrubbing und end‑to‑end‑Encryption. In FreeBSD ist ZFS seit Version 9.0 integral und kann als Root‑Dateisystem verwendet werden. Das Zpool‑Modell erlaubt das Kombinieren unterschiedlicher physischer Laufwerke zu einem logischen Speicher‑Pool.
  • Lizenz: ZFS stammt aus dem CDDL‑Open‑Source‑Projekt von Sun/Oracle, das mit der BSD‑Lizenz nicht kompatibel ist – deshalb existiert eine separate Lizenz‑Ausnahme in FreeBSD.
  1. OpenBSD – FFS + Soft‑crypto
  • Das Fast File System (FFS), auch als UFS bekannt, ist das traditionelle BSD‑Dateisystem. OpenBSD hat keine native ZFS‑Unterstützung, jedoch gibt es experimentelle Ports. Für Verschlüsselung nutzt OpenBSD soft‑crypto, ein Kernel‑Framework, das Block‑Device‑Verschlüsselung auf Ebene des Dateisystems ermöglicht (z. B. bioctl -c C für GELI‑Verschlüsselung).
  1. NetBSD – WAPBL und FFS
  • NetBSD verwendet ebenfalls FFS. Das WAPBL (Write‑Ahead‑Physical‑Logging) ist ein leichtgewichtiges Journal, das nur Metadaten‑Updates protokolliert, wodurch ein gutes Gleichgewicht zwischen Performance und Datenintegrität entsteht.
  1. DragonFlyBSD – HAMMER2
  • HAMMER2 ist ein eigens entwickeltes Dateisystem, das Copy‑on‑Write, Snapshots, Deduplizierung und Cluster‑Level‑Mirroring (via hammer2 cluster) unterstützt. Es ist hoch skalierbar und besonders gut für Systeme mit vielen CPU‑Kernen und großen Datenmengen geeignet. Im Vergleich zu ZFS fehlt jedoch die breite Dritt‑Tool‑Unterstützung (z. B. zpool‑Utility).

Netzwerk‑Stack und Sicherheitsfeatures

  • FreeBSD: Der Netzwerk‑Stack ist für hohe Durchsatzraten optimiert (TCP‑Fast‑Open, RACK‑Congestion‑Control). ipfw ist das traditionelle Firewall‑Framework, aber seit FreeBSD 12 gibt es auch pf, das aus OpenBSD stammt. Das bpf-Subsystem (Berkeley Packet Filter) ermöglicht sehr effizientes Packet‑Capturing, das in Intrusion‑Detection‑Systemen genutzt wird.
  • OpenBSD: Der pf‑Firewall‑Engine ist das Herzstück. OpenBSD legt extremen Wert auf Code‑Reviews, Memory‑Safety (z. B. ProPolice, Stack‑Canaries) und Standard‑Hardenings (z. B. sysctl‑Defaults, disable_ipv6, login.conf). OpenBSD ist das Referenzsystem für PF, OpenSSH und LibreSSL, die in vielen anderen Projekten wiederverwendet werden.
  • NetBSD: Unterstützt sowohl ipfilter, ipfw als auch pf (via Port). Der Netzwerk‑Stack ist sehr portabel – das macht NetBSD attraktiv für kleine Router‑Boards.
  • DragonFlyBSD: Hat ebenfalls pf integriert, nutzt aber zusätzlich das Vimage/-Vkernel‑Framework für leichte Isolation von Netzwerk‑Namespaces. Der Netzwerk‑Stack ist nicht ganz so umfangreich wie bei FreeBSD, dafür aber sehr sauber implementiert.

Virtualisierung, Container und Isolationstechniken

SystemContainer‑LösungHypervisorBesonderheiten
FreeBSDJails – OS‑Level‑Container mit eigenen IP‑Stacks, Dateisystem‑Views und Ressourcengrenzen (via rctl).bhyve – moderner Hypervisor, unterstützt VirtIO‑Devices, UEFI‑Boot und KVM‑Kompatibilität.runjail ermöglicht Docker‑Kompatibilität; vmm-Modul für KVM‑Beschleunigung.
OpenBSDKeines (kein jails‑Äquivalent)vmm – leichtgewichtiger Hypervisor, unterstützt KVM‑Kompatibilität.Fokus liegt auf Sicherheit, daher kein Container‑Framework eingebaut.
NetBSDKeines (kein jails‑Äquivalent)Xen, bhyve, hyper‑v (via hv‑Modul).Sehr breite Unterstützung, jedoch weniger gebündelte Tools.
DragonFlyBSDVkernel – leichtgewichtige, eigenständige Kernel‑Instanz für Isolation (ähnlich zu jails aber mit weniger Overhead).–Vkernel ist ideal für Micro‑VMs und Container‑ähnliche Workloads.

Durch die Kombination aus Jails (FreeBSD) und pf (OpenBSD) können Administratoren sehr feinkörnige Sicherheits‑ und Isolation‑Modelle bauen, die sowohl Performance als auch Härtung liefern.

Derivate, Spezialdistributionen und Ökosystem

DerivatBasis‑BSDZielgruppeBesondere Merkmale
GhostBSDFreeBSDDesktop‑Nutzer (GNOME/KDE)Ein‑Klick‑Installer, automatische ZFS‑Root‑Einrichtung, verschlüsselte Benutzer‑Home.
MidnightBSDFreeBSDDesktop & Server‑Einsteigermidnightbsd-install, grafischer Installer, eigene Paketverwaltung (pkgsrc‑basiert).
TrueNAS COREFreeBSDNAS‑ApplianceVollwertige ZFS‑Verwaltung, Web‑UI, VM‑Support, Replikation, Lizenz: CDDL (ZFS) + BSD.
pfSenseFreeBSDFirewall / RouterUmfangreiche Plugins (OpenVPN, IPsec, Captive‑Portal), Web‑UI, kommerzielle Support‑Optionen.
OPNsenseFreeBSDModerne Firewall‑ApplianceModerne Angular‑UI, IDS/IPS (Suricata), Let’s Encrypt‑Integration, regelmäßige Security‑Updates.
NomadBSDNetBSDLive‑USB + Persistent StorageEinfaches Live‑System, persistente Änderungen, kleine Image‑Größe.
OpenBSD‑based ToolsOpenBSDSicherheitstoolsOpenSSH, OpenBGPD, OpenNTPD, LibreSSL, häufig in anderen Distributionen eingebettet.
DragonFlyBSD‑BobDragonFlyBSDServer‑SkalierungMinimalistisches System, fokussiert auf HAMMER2‑Performance, geringer Overhead.

Durch das breite Derivat‑Ökosystem kann ein Unternehmen das für den jeweiligen Anwendungsfall passende Betriebssystem wählen, ohne tief in die Grund‑BSD‑Distribution einsteigen zu müssen.

Pro‑ und Contra‑Tabellen – Schnellvergleich

FreeBSD

ProContra
Riesige Ports‑Datenbank (≈30 k Pakete)Größerer Footprint – weniger geeignet für ressourcenarme Embedded‑Geräte
Native ZFS‑Integration (Snapshots, Dedupl., Verschlüsselung)Lizenz‑Komplexität (BSD + CDDL) kann in Unternehmen zu Compliance‑Fragen führen
Jails – leichte OS‑Container + Ressourcen‑LimitsJails bieten nicht die gleiche Flexibilität wie Docker‑Container (z. B. keine Overlay‑FS)
Sehr gute Netzwerk‑Performance, pf und ipfw verfügbarTeilweise veraltete Netzwerk‑Features im Vergleich zu Linux‑eigenen Technologien

OpenBSD

ProContra
Höchste Sicherheit (Code‑Audits, securebydefault, minimaler Attack‑Surface)Eingeschränkte Treiberunterstützung, besonders bei neuer Hardware
pf‑Firewall‑Engine, die als Referenz giltKein nativer ZFS‑Support (experimentell)
Kleine, kohärente Code‑Basis – einfach zu auditierenKleine Ports‑Sammlung, selteneres Software‑Portfolio
Integrierte Sicherheits‑Tools (OpenSSH, LibreSSL, OpenBGPD)Fokus auf Sicherheit kann zu Lasten von Performance‑Optimierungen führen

NetBSD

ProContra
Laufzeit auf über 50 Architekturen – ideal für Embedded & ForschungsprojekteKleinere Community, weniger kommerzielle Unterstützung
WAPBL‑Journal für geringes Overhead‑LoggingKein nativer ZFS (nur via Ports)
Saubere, modulare Kernel‑Architektur (leicht zu patchen)Fehlende vorgefertigte Server‑Features (z. B. Jails, pf als Standard)
Starke pkgsrc‑Paketverwaltung – plattformübergreifendDokumentation teils lückenhaft, besonders für Anfänger

DragonFlyBSD

ProContra
HAMMER2 – modernes Copy‑on‑Write‑Dateisystem mit Dedupl. und Snapshots
Vkernel – leichtgewichtige Isolation, ideal für Micro‑VMs
Fokus auf SMP‑Skalierung – gut für Server mit vielen Kernen
Schnelle Release‑Zyklen, aktive Entwicklung
Kleinere Community, weniger kommerzielle Unterstützung
HAMMER2 ist weniger verbreitet als ZFS – geringere Tool‑Unterstützung

Entscheidungshilfe – Welches BSD ist das Richtige für mein Projekt?

AnforderungEmpfohlenes BSDBegründung
Maximale Sicherheit (Firewall, Kryptographie, Audits)OpenBSDpf‑Engine, LibreSSL, OpenSSH‑Audits, securebydefault‑Einstellungen
Enterprise‑Storage (ZFS, Snapshots, Replikation)FreeBSD (bzw. TrueNAS CORE)Native ZFS‑Integration, ausgereifte Verwaltungstools, breite Community
Breite Hardware‑Unterstützung (IoT, ARM, MIPS, SPARC)NetBSDUnterstützt über 50 Architekturen, Clean‑room‑Entwicklung, geringes Footprint
Skalierbare SMP‑Server (viele Kerne, Dedupl.)DragonFlyBSDHAMMER2‑Dedupl., Vkernel‑Isolation, exzellente SMP‑Performance
Desktop‑Erlebnis (Desktop‑Environment, Plug‑and‑Play)GhostBSD (FreeBSD) oder MidnightBSDFertige Installer, vorinstallierte GNOME/KDE, einfacher Paket‑Manager
Firewall‑AppliancepfSense / OPNsense (beide FreeBSD‑basiert)Web‑UI, umfangreiche Plugin‑Bibliothek, kommerzieller Support
NAS / Speicher‑ApplianceTrueNAS CORE (FreeBSD)ZFS‑Management, Web‑Interface, Replikation, VM‑Support
Entwicklung / ForschungNetBSDPortabilität, pkgsrc für plattformübergreifende Pakete

Berücksichtigen Sie zusätzlich Community‑Aktivität, Verfügbarkeit von Paketen (Ports vs. pkg), Lizenz‑Konformität und Unterstützungsoptionen (Mailing‑Liste, Issue‑Tracker, kommerzielle Anbieter).

Zukünftige Entwicklungen und Roadmaps

  • FreeBSD 15.x – Weiterentwicklung des ZFS‑Stacks (z. B. ZFS 2.2 mit Verbesserungen bei Scrubbing und Compression), Unterstützung von GPU‑Pass‑Through für bhyve, engere Integration in Kubernetes via csi‑freebsd.
  • OpenBSD 7.9 – Verbesserungen am pf‑Engine (z. B. stateful‑inspection Optimierungen), Einführung von Trusted Execution Environments (TEE), erweiterte Hardware‑Root‑of‑Trust‑Mechanismen.
  • NetBSD 10 – Fokus auf RISC‑V‑Unterstützung (neue Toolchains, Device‑Tree‑Support), pkgsrc‑Erweiterungen für Container‑Orchestrierung (Docker‑Kompatibilität), Modernisierung der Netz‑Stack‑Bibliotheken.
  • DragonFlyBSD 6 – Finalisierung und Stabilisierung von HAMMER2, neue Vkernel‑Features (z. B. Namespace‑Isolation, cgroups‑ähnliche Ressourcen‑Limits), Integration von ZFS‑Ports für Hybrid‑Lösungen.
  • Derivate: TrueNAS SCALE (Debian‑basiert) entsteht als Konkurrenz zum FreeBSD‑basierten CORE, während pfSense 2.8 führt eBPF‑Unterstützung ein, um modernere Packet‑Processing‑Pipelines zu ermöglichen.

Quellen, weiterführende Literatur und Community‑Links

  • FreeBSD Project – Offizielle Dokumentation: https://www.freebsd.org/docs/
  • OpenBSD Project – Ziele & Sicherheit: https://www.openbsd.org/faq/faq4.html
  • NetBSD Project – Plattform‑Übersicht: https://www.netbsd.org/ports/
  • DragonFlyBSD – HAMMER2‑Dokumentation: https://www.dragonflybsd.org/docs/hammer2/
  • pfSense – Dokumentation & Release‑Notes: https://docs.pfsense.org/
  • OPNsense – Features & Roadmap: https://opnsense.org/
  • TrueNAS – ZFS‑Management: https://www.truenas.com/
  • GhostBSD – Desktop‑Projekt: https://ghostbsd.org/
  • MidnightBSD – Release‑Notes: https://midnightbsd.org/
  • NomadBSD – Live‑USB System: https://nomadbsd.org/
  • NetBSD – WAPBL & FFS: https://netbsd.org/docs/technical/
  • OpenBSD – pf‑Manpage: https://man.openbsd.org/pf.conf
  • FreeBSD – Jails‑Handbuch: https://docs.freebsd.org/en/books/handbook/jails/
  • DragonFlyBSD – Vkernel‑Übersicht: https://www.dragonflybsd.org/docs/vkernel/

Was ist neu in Qt 6.10? Ein Überblick für Entwickler

Thorsten Geppert Schreib einen Kommentar

Qt 6.10 ist ein klassisches „Framework‑Release“, das an vielen Stellen nachzieht, wo sich in den letzten Jahren Anforderungen und Best Practices geändert haben: moderneres UI‑Layouten mit Flexbox, stärkere Unterstützung für Vektoranimationen (SVG/Lottie), vereinfachte Datenanbindung zwischen C++ und QML, neue Hilfstypen für Modelle und Bindungen – und dazu ein spürbares Update bei Accessibility und Plattformintegration.

Im Folgenden ein Überblick über die wichtigsten Änderungen von Qt 6.10, auf Basis der offiziellen Release‑Informationen.

Accessibility: High Contrast und Screenreader werden ernster genommen

Qt 6.10 legt sichtbar mehr Wert auf Barrierefreiheit:

  • High‑Contrast‑Mode auf allen Plattformen:
  • Die eingebauten Styles orientieren sich stärker an den jeweiligen System‑Einstellungen für hohen Kontrast.
  • Ziel: Qt‑Apps sollen sich optisch nahtlos in die restliche Oberfläche einfügen und dabei besser lesbar sein.
  • Für dich als Entwickler bedeutet das: Ohne Codeänderung profitierst du von verbessertem Kontrast, wenn Nutzer das systemweit aktivieren.
  • Bessere Integration mit Assistive Technologies:
  • Qt Widgets und Qt Quick Controls wurden überarbeitet, damit Screenreader und andere Hilfsmittel sauberer angesprochen werden.
  • Besonders für WebAssembly gab es Verbesserungen in der Accessibility‑Implementierung.
  • Viele Änderungen fließen auch in LTS‑Branches zurück (Patch‑Releases), sofern du dort aktuell bleibst.

Unterm Strich: Qt 6.10 hilft dir bei der Einhaltung von Accessibility‑Vorgaben, ohne dass du an jeder Ecke Speziallogik schreiben musst.

Qt Quick: FlexboxLayout und moderne UI‑Bausteine

Qt Quick bleibt die Speerspitze für neue UI‑Konzepte. Mit Qt 6.10 kommen unter anderem:

FlexboxLayout (Tech Preview)

  • Neues Layout‑Element FlexboxLayout für Qt Quick, das sich an CSS Flexbox anlehnt.
  • Vorteile:
  • Besseres Verhalten bei unterschiedlich großen Screens und Aspect Ratios.
  • Weniger Custom‑Layoutcode für „responsive“ UIs.
  • Vertraut für alle, die bereits mit Web/CSS arbeiten.
  • Integration:
  • Bindet sich in das bestehende Layout‑System von Qt Quick ein (attached properties etc.).
  • Ist als Technologievorschau gekennzeichnet – API kann sich bis zum nächsten LTS noch ändern.

Animierte Vektorgrafiken (SVG & Lottie)

Qt 6.10 baut konsequent auf den SVG/Vektor‑Verbesserungen der vorherigen Versionen auf:

  • VectorImage (aus 6.8 bekannt) wird erweitert:
  • Unterstützung für animierte Vektorgrafiken in
    • SVG‑Format und
    • Lottie‑Format.
  • Qt Lottie‑Modul:
  • Deutlich verbesserte Unterstützung moderner Lottie‑Dateien.
  • Lottie‑Assets können jetzt als skalierbare, hardwarebeschleunigte Vektorgrafiken direkt im Qt‑Quick‑Scenegraph gerendert werden.

Für UI‑Designer bedeutet das: Aufwendige, aber leichtgewichtige Animationswelten lassen sich direkt aus Design‑Tools (Figma/After Effects → Lottie) in Qt übernehmen.

Neuer Quick Control: SearchField

  • Spezialisierter Eingabebaustein für Suchfelder.
  • Bringt:
  • nativen Look & Feel auf allen Plattformen (wie andere Qt Quick Controls),
  • integrierte Vorschlagsliste mit Modellanbindung.
  • Integration:
  • suggestionModel kann über die üblichen Mechanismen (QAbstractItemModel, Kontextobjekte, QML‑Modelle) befüllt werden.
  • Besonders interessant in Kombination mit den neuen Modell‑/Bindungswerkzeugen (siehe unten).

Einfachere Verbindung zwischen C++‑Daten und QML‑UIs

Ein klassischer Schmerzpunkt in Qt‑Projekten war die Verbindung zwischen C++‑Backend und QML‑UI. Qt 6.10 nimmt sich genau dieser Nähte an.

QRangeModel: C++‑Container direkt als Modell

  • QRangeModel ist eine schlanke QAbstractItemModel‑Implementierung, die C++‑Ranges (z.B. std::vector, std::array, beliebige iterierbare Container) direkt als Modell zur Verfügung stellt.
  • Eigenschaften:
  • Kann einfache Typen (int, QString, …) wie auch komplexe Typen (GADGETs, std::tuple) abbilden.
  • Modellrollen werden automatisch erzeugt.
  • Funktioniert gleichermaßen in Qt Widgets (Views) und in QML/Qt Quick.
  • Beispiel‑Anwendung:
  • std::vector<int> als Liste in einer QML‑ListView,
  • std::vector<MyGadget> als typ‑sicheres Modell in Delegates mit required property.

Damit entfällt für viele Anwendungsfälle das Schreiben eigener QAbstractItemModel‑Subklassen.

delegateModelAccess: Zurückschreiben in das Modell vereinfachen

Bisher war das Schreiben aus einem Delegate zurück in das Modell oft umständlich:

  • Entweder über model‑Objekte im Delegate
  • oder über Kontextproperties und eigene Signal‑Handler.

Mit Qt 6.10 kann eine View über delegateModelAccess: DelegateModel.ReadWrite explizit erlauben, dass required‑Properties im Delegate direkt zurück ins Modell schreiben. Das reduziert Boilerplate deutlich, insbesondere in größeren QML‑UIs.

Synchronizer: Zwei‑ und Mehrwege‑Bindungen

  • Neues Element Synchronizer (Tech Preview, Modul Qt.labs.synchronizer).
  • Zweck:
  • Mehrere Properties so synchron halten, dass sie (so weit möglich) denselben Wert haben, ohne klassische Bindungen zu „brechen“.
  • Funktioniert für Kombinationen von C++‑ und QML‑Eigenschaften.
  • Praxisnutzen:
  • Typische „Slider ↔ Modell‑Wert“‑Szenarien lassen sich deklarativ und ohne zusätzliche Signal‑Handler abbilden.

TreeModel für QML

  • Neues QML‑TreeModel, mit dem sich Baumdaten direkt in QML deklarieren lassen.
  • Zielgruppe:
  • Prototyping,
  • kleinere Datenmengen,
  • Szenarien, in denen ein kompletter C++‑Baummodell‑Layer Overkill wäre.

Zusammen genommen macht Qt 6.10 die Kante zwischen C++‑Backend und QML‑Frontend deutlich angenehmer.

Qt Graphs: FilledSurface und mehr

Qt Graphs wird auch in 6.10 weiter ausgebaut:

  • Neue Diagrammtypen und Anpassungen:
  • u.a. ein neuer „FilledSurface“‑Graph zur besseren Darstellung gefüllter Flächen.
  • Bessere Integration in Qt Quick und die neuen Layout‑/Vektorfeatures.

Wenn du bereits mit Qt Graphs arbeitest, lohnt sich ein Blick in die konkreten Release Notes für dieses Modul.

Sonstige Verbesserungen und Plattform‑Updates

Wie bei jedem Qt‑Release gibt es eine Reihe weiterer Verbesserungen:

  • Plattformintegration:
  • Qt 6.10 richtet sich nach den jeweils aktuellen Versionen der großen Desktop‑, Mobile‑ und Embedded‑Plattformen (siehe Release Note und Wiki‑Seite).
  • Bugfixes und Feinschliff:
  • Dutzende Fehlerkorrekturen in den Untermodulen (Widgets, Quick, Network, etc.).
  • Viele Details lassen sich in den detaillierten Release Notes (6.10.0–6.10.2) nachlesen.

Fazit

Qt 6.10 ist kein „großer Sprung“ im Sinne völlig neuer Konzepte, sondern ein Release, das viele typischen Alltagsbaustellen adressiert:

  • Accessibility wird ernst genommen (High Contrast, Screenreader‑Integration).
  • Qt Quick bekommt mit FlexboxLayout, animierten Vektorgrafiken und SearchField Werkzeuge, die aktuelle UI‑Designs besser abbilden.
  • Die Verbindung zwischen C++‑Daten und QML‑UIs wird durch QRangeModel, delegateModelAccess, Synchronizer und TreeModel deutlich entschärft.

Wer bereits auf Qt 6.x unterwegs ist, sollte Qt 6.10 vor allem dann in Betracht ziehen, wenn:

  • Accessibility und regulatorische Vorgaben eine Rolle spielen,
  • moderne, animierte UIs (Vektor/Lottie) benötigt werden,
  • oder die Brücke zwischen C++‑Backend und QML‑Frontend bislang viel Handarbeit erfordert.

Quellen

  • Qt Blog: Qt 6.10 Released! – https://www.qt.io/blog/qt-6.10-released
  • Qt Wiki: Qt 6.10 Release – https://wiki.qt.io/Qt_6.10_Release
  • Qt Doku: New Features in Qt 6.10 – https://doc.qt.io/qt-6.10/whatsnew610.html

FreeBSD in den letzten sieben Tagen: Zwischen 14.4-Realität, ZFS-Sorgen und kleinen pkg-Ideen

Thorsten Geppert Schreib einen Kommentar

Wer bei FreeBSD auf den großen Trommelwirbel wartet, wartet oft lange. Das ist einer der Punkte, die ich an dem System gleichzeitig schätze und gelegentlich unerquicklich finde. Schätze, weil man nicht jeden zweiten Tag mit irgendeinem Marketingfeuerwerk belästigt wird. Unerquicklich, weil man sich die wirklich interessanten Entwicklungen oft aus Mailinglisten, Release Notes und Nebensätzen zusammensuchen muss.

Wenn man auf die letzten sieben Tage blickt, dann ergibt sich im Kern ein recht typisches Bild für FreeBSD: Nach außen ist es vergleichsweise ruhig, unter der Oberfläche wird aber an genau den Stellen diskutiert, an denen Betriebssysteme im Alltag entweder angenehm oder unerquicklich werden. Performance beim Bauen von Software, Stabilität und Speicherverhalten von ZFS sowie die Frage, wie sich pkg im PKGBASE-Umfeld sinnvoller bedienen lässt.

FreeBSD 14.4 ist weiterhin das beherrschende Thema

Die wichtigste offizielle Nachricht im betrachteten Zeitraum bleibt letztlich die Veröffentlichung von FreeBSD 14.4-RELEASE am 10. März. Das fällt zwar knapp aus dem Sieben-Tage-Fenster heraus, prägt aber die Diskussionen dieser Woche deutlich. Und das ist auch kein Wunder.

Zu den wichtigen Punkten von 14.4 gehören unter anderem:

  • OpenSSH 10.0p2
  • standardmäßig der hybride Post-Quantum-Algorithmus mlkem768x25519-sha256
  • OpenZFS 2.2.9
  • bessere cloud-init-/nuageinit-Kompatibilität
  • ein neues p9fs(4) für Dateisystem-Sharing zwischen Host und bhyve-Gästen
  • Verbesserungen bei den Manpages und deren Werkzeugen

Das ist insgesamt ein ordentliches Release. Keine Revolution, aber genau diese Sorte Version, die für FreeBSD eigentlich typisch ist: evolutionär, pragmatisch, mit Fokus auf sinnvolle Pflege statt auf Show.

Erwähnenswert ist auch die Widmung der Version an Ken Smith, der Ende letzten Jahres verstorben ist und als Release-Engineering-Leiter über viele Jahre hinweg eine wichtige Rolle bei FreeBSD gespielt hat. Solche Hinweise gehen in technischen Veröffentlichungen gerne unter, sind aber durchaus bedeutend, weil sie zeigen, dass hinter der ganzen Sache eben doch Menschen stehen und nicht nur Code.

Erste Rückmeldungen nach 14.4: Build-Zeiten sorgen für Unmut

Interessanter als die reine Release-Ankündigung waren in dieser Woche die Rückmeldungen aus der Praxis. Auf der Mailingliste wurde ein Fall beschrieben, bei dem sich nach dem Upgrade von 14.3 auf 14.4 die Build-Zeiten mit poudriere teils drastisch erhöht haben. Konkret war von teils doppelt so langen Zeiten die Rede.

Das ist kein kleines Detail. Für Leute, die Ports bauen, Pakete pflegen oder generell viel lokal kompilieren, ist das kein Schönheitsfehler, sondern schlicht Alltagsschmerz. Wenn ein Full Build plötzlich nicht mehr einen Tag, sondern zwei braucht, dann ist das keine Randnotiz mehr.

In der Diskussion wurde darauf verwiesen, dass hier vermutlich ein bereits bekanntes Performance-Problem hineinspielt und dass es dafür inzwischen einen Schalter gibt, um das frühere Verhalten wiederherzustellen. Das ist zunächst einmal die gute Nachricht. Die weniger gute Nachricht ist aber, dass solche Dinge überhaupt erst einmal wieder in der Praxis auffallen müssen und man sich die Informationen aus Threads und Commit-Hinweisen zusammensuchen darf.

Das ist bei FreeBSD leider nicht ganz unüblich: Die Technik ist oft solide, die Kommunikation darüber mitunter weniger komfortabel, als sie sein könnte.

ZFS bleibt hervorragend – und manchmal unerquicklich

Wirklich interessant wurde es bei einer Diskussion zu ZFS-Deadlocks und Memory-Accounting-Problemen auf NFS-Servern. Beschrieben wurde dort ein Verhalten, bei dem Maschinen trotz sehr viel freiem RAM unter Speicherdruck geraten, anfangen zu swapen und im schlimmsten Fall sogar im OOM-Kontext landen. Das ist schon deshalb unerquicklich, weil gerade große Speicher- und Storage-Systeme unter FreeBSD häufig genau mit dem Versprechen betrieben werden, dass ZFS dort besonders gut aufgehoben sei.

Der geschilderte Fall betraf Systeme mit sehr viel RAM, bei denen ARC-Speicher zwar als evictable erschien, das System aber dennoch in einen problematischen Zustand lief. Dazu kamen Hinweise auf blockierte Prozesse und Wartezustände rund um ARC- und dbuf-Mechanismen. Das ist natürlich erst einmal ein Einzelfall aus einer Mailingliste und keine allgemeingültige Aussage über alle 14.x-Installationen. Aber es ist genau die Sorte Signal, bei der Administratoren hellhörig werden sollten.

Denn solche Probleme sind im Alltag nicht deswegen unangenehm, weil sie spektakulär sind, sondern weil sie sich oft lange als „komisches Verhalten“ tarnen. Ein bisschen Swap hier, etwas Last dort, ein paar hängende Prozesse, und plötzlich steht ein System, das laut oberflächlicher Kennzahlen eigentlich gar nicht in Schwierigkeiten sein dürfte.

FreeBSD hat im Storage-Bereich nach wie vor sehr gute Argumente. Aber wenn solche Berichte auftauchen, dann sollte man sie ernst nehmen. Nicht hysterisch, aber ernsthaft.

Kleine pkg-Diskussion, aber durchaus mit praktischer Relevanz

Weniger dramatisch, aber praktisch nicht uninteressant war eine Diskussion um pkg und den Umgang mit PKGBASE. Konkret ging es um den Wunsch, Upgrades für Drittanbieter-Pakete und Base-System sauberer voneinander zu trennen.

Vorgeschlagen wurden zusätzliche Aliase wie:

  • pkg upgrade-packages
  • pkg upgrade-base

Die Idee dahinter ist simpel und vernünftig: Man möchte im Alltag nicht immer alles in einen Topf werfen, sondern bewusst entscheiden können, ob gerade nur Ports-Pakete oder nur das Base-System angefasst werden sollen.

Das ist nun keine Nachricht, bei der irgendjemand in Begeisterung ausbrechen müsste. Aber es ist ein gutes Beispiel dafür, wie sich FreeBSD verändert: oft in kleinen, unaufgeregten, aber alltagstauglichen Schritten. Gerade solche Verbesserungen machen am Ende häufig mehr Unterschied als irgendein groß angekündigtes Großprojekt.

Zugleich zeigt die Diskussion aber auch ein typisches Problem: Benennung und Verständlichkeit sind eben nicht nebensächlich. Wenn man „packages“ sagt, obwohl technisch betrachtet am Ende alles Pakete sind, dann ist die Verwirrung fast schon eingebaut. Das ist kein Drama, aber auch kein Detail, das man völlig ignorieren sollte.

Was bleibt also von dieser Woche?

Wenn man die letzten sieben Tage rund um FreeBSD zusammenfasst, dann ergibt sich aus meiner Sicht vor allem dieses Bild:

FreeBSD wirkt nach außen oft ruhig, fast schon zu ruhig. Unter dieser ruhigen Oberfläche zeigen sich aber genau die Themen, die für Anwender und Administratoren wirklich relevant sind:

  • Wie gut läuft ein frisches Release im Alltag?
  • Gibt es Performance-Regressions?
  • Ist ZFS unter realer Last so stabil, wie man es erwartet?
  • Werden Werkzeuge wie pkg im täglichen Betrieb besser bedienbar?

Das ist am Ende vielleicht auch das eigentlich Sympathische an FreeBSD. Die interessanten Nachrichten sind dort selten bloß „Neu! Größer! Schneller!“. Oft sind es eher Hinweise darauf, wo die Praxis gegen die Theorie arbeitet. Und genau dort entscheidet sich, ob ein System auf Dauer Vertrauen verdient.

14.4-RELEASE ist ohne Frage die wichtigste jüngere Entwicklung. Die anschließenden Diskussionen zu Build-Performance und ZFS zeigen aber auch, dass ein Release eben nicht mit der Veröffentlichung fertig ist. Es beginnt dann erst die Phase, in der sich herausstellt, wie gut die Dinge außerhalb von Release Notes und Ankündigungen wirklich funktionieren.

Und genau diese Phase war in den letzten sieben Tagen die eigentlich interessante.

Quellen

  • FreeBSD News Flash: https://www.freebsd.org/news/newsflash/
  • FreeBSD News RSS Feed: https://www.freebsd.org/news/feed.xml
  • FreeBSD 14.4-RELEASE Announcement: https://lists.freebsd.org/archives/freebsd-announce/2026-March/000228.html
  • FreeBSD-announce Archiv März 2026: https://lists.freebsd.org/archives/freebsd-announce/2026-March/date.html
  • Thread: „Huge build times increase after updating from 14.3 to 14.4“: https://lists.freebsd.org/archives/freebsd-stable/2026-March/003900.html
  • Antwort von Olivier Certner zum bekannten Performance-Problem: https://lists.freebsd.org/archives/freebsd-stable/2026-March/003901.html
  • Nachfrage von Philip Paeps zu den Package-Buildern: https://lists.freebsd.org/archives/freebsd-stable/2026-March/003907.html
  • Thread: „ZFS deadlocks/memory accounting issues“: https://lists.freebsd.org/archives/freebsd-stable/2026-March/003910.html
  • Antwort von Alan Somers im ZFS-Thread: https://lists.freebsd.org/archives/freebsd-stable/2026-March/003911.html
  • Thread/Proposal zu pkg-Aliases: https://lists.freebsd.org/archives/freebsd-stable/2026-March/003942.html
  • Rückfrage zur Benennung der pkg-Aliases: https://lists.freebsd.org/archives/freebsd-stable/2026-March/003944.html
  • FreeBSD-stable Archiv März 2026: https://lists.freebsd.org/archives/freebsd-stable/2026-March/date.html

Internat Alzen: Mobbing gemeldet – Schulvertrag kurze Zeit später beendet – Wie unser autistischer Sohn unverschuldet den Schulplatz verlor

Thorsten Geppert Schreib einen Kommentar

In unserem ausführlichen Erfahrungsbericht schildern wir, wie unser autistischer Sohn nach einem vielversprechenden Start am Internat Alzen wiederholt von Mitschülern belastet wurde und wir dies frühzeitig dokumentiert und gemeldet haben. Aus unserer Sicht reagierte die Schule nicht mit ausreichenden Schutzmaßnahmen, sondern hielt an einem festen Konzept fest, das die Situation unseres Kindes nicht angemessen berücksichtigte. Wenige Wochen nach unseren Hinweisen auf die Problematik wurde das Schulverhältnis beendet.

Wir ordnen den Fall im Kontext von Kinderschutz, Inklusion und schulischer Verantwortung ein und geben Hinweise, worauf Eltern in ähnlichen Situationen achten sollten und berichten von unseren Erfahrungen.

Den vollständigen Artikel mit allen Hintergründen und Dokumentationen findest du hier.