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-packagespkg 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