Ein Jahr Förderung für die FreeBSD-Entwicklung

• Mit Förderung von Amazon wurde ein Jahr lang an FreeBSD Release Engineering und der FreeBSD/EC2-Entwicklung gearbeitet
• Release-Management und EC2-bezogene Verbesserungen wurden parallel vorangetrieben, mit im Schnitt 50 Arbeitsstunden pro Monat
• Wichtige Funktionsprobleme und Qualitätsverbesserungen wurden bei Energieverwaltung für Graviton-Instanzen, Hotplug-Unterstützung und der Boot-Performance erreicht
• Durch Erweiterung der AMI-Typen und Build-Automatisierung wurden Vielfalt und Effizienz der Bereitstellung von FreeBSD-AMIs erhöht
• Nach Ende der Förderung werden eine Verlangsamung des Entwicklungstempos und Stagnation bei einigen Funktionen erwartet

---

Rückblick auf ein Jahr Förderung der FreeBSD-Entwicklung

# Hintergrund und Weg zur Förderung

• Die FreeBSD/EC2-Plattform wird seit 2010 betreut; seit November 2023 wird außerdem die Rolle des Leads für FreeBSD Release Engineering ausgeübt
• Es gab bereits kleinere Förderungen über Antithesis, Patreon usw., doch die Arbeit am Release Engineering nahm immer mehr Zeit von der FreeBSD/EC2-Entwicklung in Anspruch
• Mit Amazon wurden über mehrere Jahre Gespräche über ein Sponsoring für EC2-Arbeiten geführt; im April 2024 kam der Kontakt zu der für die Budgetfreigabe zuständigen Person zustande, wodurch eine einjährige Förderung möglich wurde
• Die Förderung wurde über GitHub Sponsors abgewickelt; der von Amazon beabsichtigte Förderzeitraum und der tatsächliche Zeitpunkt der Auszahlung können voneinander abweichen

# Förderung und Verteilung der Arbeitszeit

• Auf Wunsch von Amazon wurde zugesagt, monatlich 40 Stunden für FreeBSD Release Engineering und EC2-Entwicklung bereitzustellen
• Tatsächlich wurden pro Monat etwa 50 Stunden investiert, aufgeteilt in 20 Stunden für EC2-Probleme, 20 Stunden für Release-Arbeiten und 10 Stunden für sonstiges Engineering
• Die monatliche Arbeitszeit schwankte dabei teils deutlich

# FreeBSD-Release-Management

• Durch Einführung und Verwaltung eines quartalsweisen FreeBSD-Release-Zeitplans wurden innerhalb eines Jahres vier Releases durchgeführt: FreeBSD 13.4 (2024.9), 14.2 (2024.12), 13.5 (2025.3), 14.3 (voraussichtlich 2025.6)
• Zu jedem Release gehörten das Anhalten von Entwickler:innen zur Einhaltung des Code-Freeze, die Freigabe und Koordination von Merge-Anfragen, das Bauen und Testen von Images, das Schreiben von Mitteilungen sowie die Behebung verschiedener Fehler in Release-Builds
• Der Zeitaufwand für Release Engineering lag je Quartal zwischen 33,5 und 79 Stunden; mit zunehmender Stabilisierung nahm das Arbeitsvolumen im späteren Verlauf tendenziell ab

# Wichtige EC2-Funktionsverbesserungen und Qualitätssteigerungen

Power-Treiber und Hotplug-Unterstützung für Graviton-Instanzen

• Ein Problem wurde behoben, bei dem FreeBSD auf Graviton-Instanzen das reguläre Shutdown-Signal der EC2-API nicht erkennen konnte

  • Unter Nutzung des ACPI \_AEI-Objekts wurde ein GPIO-basiertes "power button"-Signal mit der Treiberlogik verbunden
  • Ein Problem mit deaktivierten Geräten aufgrund inkonsistenter Pull-Up-Flag-Einstellungen in den von EC2 bereitgestellten ACPI-Tabellen wurde durch Hinzufügen der Einstellung ACPI\_Q\_AEI\_NOPULL zu FreeBSD/EC2-AMIs abgefangen

• Die Hotplug-Probleme bei Geräten (insbesondere Hot-Unplug) auf EC2-Graviton- und x86-Instanzen wurden umfassend analysiert und behoben

  • Dabei wurden verschiedene Fehlertypen behandelt, darunter IRQ-Leaks, Inkonsistenzen zwischen PCI-Stromzustand und OS-Signalen sowie "Geister"-PCI-Geräte
  • Als Zwischenlösung wurden ACPI-Quirks eingesetzt, etwa ACPI\_Q\_CLEAR\_PME\_ON\_DETACH und ACPI\_Q\_DELAY\_BEFORE\_EJECT\_RESCAN; Fehler auf EC2-Seite sollen noch behoben werden

Automatisierung von Hotplug-Tests und Qualitätsverbesserungen

• Es wurde ein Skript entwickelt, das in EC2 wiederholt EBS-Volumes an- und abkoppelt; die Stabilität wurde durch 300 aufeinanderfolgende Testläufe überprüft
• Die unnötige Verzögerung von 5 Sekunden bei PCIe-Hotplug, die nur auf physischen Systemen sinnvoll ist, wurde in EC2 auf 0 Sekunden gesetzt, was die Qualität verbesserte

Verbesserungen der Boot-Performance

• Probleme bei der Boot-Geschwindigkeit von FreeBSD/EC2 wurden durch systematische Datenerhebung und Analyse verbessert
• Nacheinander wurden eine Anfang 2024 durch Vergrößerung der Root-Disk verursachte dreifache Boot-Verzögerung, Verzögerungen beim Kernel-Entropy-Seeding auf Graviton2-Instanzen, längere ZFS-Boot-Zeiten und IPv6-Support-Probleme im Zusammenhang mit IMDSv2 behoben
• Optimierungen erfolgten in vielen Bereichen, darunter Unterschiede der Boot-Performance je Dateisystem, ineffiziente Entropieversorgung und Verzögerungen bei der Netzwerkinitialisierung

# Mehr Vielfalt bei FreeBSD-AMIs und Automatisierung von Build und Verteilung

• Zusätzlich zu den bisherigen base- und cloud-init-AMIs wurden ein small AMI (ohne unnötigen Debugging- und Test-Code/Tools, 1 GB Größe) sowie ein builder AMI (Builder für benutzerdefinierte Anpassungen) hinzugefügt
• Mit 4 AMI-Typen * 2 Dateisystemen (UFS/ZFS) * 2 Architekturen (amd64/arm64) * 3 Versionen (13, 14, 15) wuchs die Zahl der Image-Kombinationen stark an; deshalb wurden das automatische Löschen alter Images und die Skript-Automatisierung vorangetrieben und 336 TB an EBS-Snapshots bereinigt

# Allgemeine Engineering-Verbesserungen

• Durch Parallelisierung der FreeBSD-AMI- und Release-Builds wurde die gesamte Build-Zeit von etwa 22 Stunden auf 13 Stunden verkürzt, wodurch mehr Spielraum für zusätzliche AMI-Typen entstand
• Mithilfe automatisierter Tests auf Basis von EC2-Instanzen und Vergleichen mit diffoscope wurden Probleme bei der Build-Reproduzierbarkeit (reproducible builds) analysiert und schrittweise behoben
• Parallel dazu liefen diverse kleinere Aufgaben wie Review von ENA-Treiber-Patches, Build von OCI-Containern und Upload in Registries, Verbesserungen an AWS-bezogenen Tools sowie Reports zu Sicherheitsproblemen

# Ausblick und Grenzen

• Die Rolle bei der Betreuung des FreeBSD Release Engineering und der EC2-Plattform bleibt bestehen, allerdings wird künftig weniger Zeit dafür verfügbar sein als zuvor
• Die Releases FreeBSD 15.0 (Dezember 2024) sowie 14.4/15.1/14.5/15.2 (2026) sollen wie geplant erscheinen, allerdings dürfte sich das Tempo bei neuen Funktionen und Bugfixes verlangsamen
• Bei noch offenen Themen wie automatischer Dateisystem-Erweiterung, mehreren NICs und Hotplug-Automatisierung, der Bereitstellung vorab gepatchter AMIs, einem Web-Tool für EC2-Nutzer:innen und Unterstützung für FreeBSD/Firecracker ist langfristig mit Stagnation zu rechnen

# Schlusswort

• Diese Förderung durch Amazon ist für Open-Source-Entwickler:innen eine äußerst seltene Gelegenheit, und es werden Stolz auf die erzielten Ergebnisse sowie Dankbarkeit dafür empfunden

[GN⁺]

Hacker-News-Kommentare

• Heute wurde mitgeteilt, dass FreeBSD zur Download-Seite von ziglang.org hinzugefügt wurde; FreeBSD-Nutzer können damit nun leicht automatisch in CI gebaute Builds des Master-Branches erhalten.
  FreeBSD wird jetzt offiziell vollständig als Cross-Compile-Ziel unterstützt, und man kann ähnlich wie unter Linux für FreeBSD kompilieren, zum Beispiel mit zig cc -o hello hello.c -target riscv64-freebsd.
  Wenn es C/C++-Abhängigkeiten gibt, lassen sie sich leicht in das Zig-Build-System übernehmen und bauen, wodurch sogar recht komplexe Projekte problemlos für FreeBSD querkompiliert werden können.
  Die Hoffnung ist, dass dadurch mehr Projekte FreeBSD-Unterstützung und Tests zu ihrer CI hinzufügen.

  • Es wird gesagt, dass Zigs Cross-Compile-Funktion wirklich großartig ist und dass es erfreulich ist, FreeBSD als unterstütztes Ziel hinzugefügt zu sehen.

• Beim Lesen gab es viele interessante Stellen.
  Ein Fall, in dem der FreeBSD-Boot-Prozess ab der ersten Woche 2024 plötzlich dreimal so langsam wurde; nach weiterem Verfolgen der Commits stellte sich heraus, dass die Ursache darin lag, dass die Größe der Root-Disk von 5 GB auf 6 GB erhöht worden war.
  Auf Nachfrage bei einem Amazon-Bekannten kam eine fast schon magisch klingende Antwort im Stil von: „Genau wissen wir es nicht, aber vielleicht ist es besser, es einfach nicht zu wissen.“
  Wichtig ist, dass sich die Leistung wieder auf das frühere Niveau erholte, nachdem die Root-Disk auf 8 GB vergrößert wurde.

  • Solche Geschichten machen einen jetzt erst recht neugierig auf den tatsächlichen Grund.

  • Man fragt sich, wie viel Zeit das Commit-Bisecting gekostet hat, um so ein Problem zu finden.
    Man stellt sich vor, ob dafür jedes Mal ein Image gebaut und die VM neu gestartet wurde.

  • Erwähnung eines eigenen Blogposts von 2006 darüber, dass die ursprüngliche Größenbegrenzung von Objekten in S3 bei 5 GB lag.
    https://aws.amazon.com/blogs/aws/amazon_s3/
    Ob das direkt mit der langsamer gewordenen FreeBSD-Performance zusammenhängt, ist unklar.

• Auch bei der Laptop-Unterstützung läuft viel.
  Es wurde gelesen, dass die BSD Foundation 750.000 US-Dollar investiert, um sich auf verschiedene Funktionen wie die Implementierung des S0ix Sleep State zu konzentrieren.
  Das zugehörige Projekt ist unter https://github.com/FreeBSDFoundation/proj-laptop zu finden.

  • Es laufen wirklich viele Arbeiten gleichzeitig, aber geteilt wurde nur der Teil, an dem man selbst direkt arbeitet.

• Man hatte gehofft, dass Amazon mehr Unterstützung und Beiträge leisten würde, doch in der Realität scheint es bei minimaler Unterstützung für FreeBSD zu bleiben.
  Amazon steht nicht einmal auf der Liste der FreeBSD-Sponsoren; Google hat letztes Jahr gerade einmal 9.000 US-Dollar gespendet, und Apple sowie Meta/Facebook fehlen ebenfalls.
  Umgekehrt ist es lobenswert, dass Microsoft auf der Liste steht.
  Es ist überraschend, dass diese Großunternehmen stark von FreeBSD und OpenBSD profitieren, aber nicht jedes Jahr automatisch spenden.
  Informationen zu Sponsoren gibt es unter https://freebsdfoundation.org/our-donors/donors/?donationYear=2024.

  • Der Wunsch, dass Amazon FreeBSD stärker unterstützt, ist nachvollziehbar.
    Aber nur weil Amazon nicht in der Spenderliste der FreeBSD Foundation steht, heißt das nicht, dass es keine Unterstützung gibt.
    Auch die eigene Entwicklungsfinanzierung lief nicht über die Foundation, und tatsächlich macht von der Foundation unterstützte Entwicklung nur etwa 10 % der gesamten Unternehmensunterstützung aus.
    Von der Foundation unterstützte Entwicklung ist wichtig, weil man sich dabei auf Arbeiten speziell für FreeBSD selbst konzentrieren kann, insgesamt ist sie aber nur ein kleiner Teil.

  • Der Hinweis, dass man anhand dieses einen Kommentars nicht die ganze Lage beurteilen kann.
    Zu sehen ist nur eine Momentaufnahme der jährlichen Spenden an die Foundation, während die tatsächlich geleistete Entwicklungsarbeit in den Release Notes der einzelnen Versionen zusammengefasst ist.
    https://www.freebsd.org/releases/

  • Es stellt sich die Frage, warum Microsoft FreeBSD unterstützt.
    Selbst die Hyper-V-Erweiterungen sind nicht so vollständig wie unter Linux, es gibt keinen offiziellen .NET-Port, und es wirkt auch nicht so, als betreibe Microsoft Dienste auf Basis von FreeBSD.

  • Die Meinung, dass Amazon unter den FAANG-Unternehmen am wenigsten zu FOSS beiträgt.

• Es wird großer Respekt für cperciva ausgedrückt.
  Man fragt sich, wie Tarsnap und FreeBSD gleichzeitig gemanagt werden.

  • Es wird die Erfahrung geteilt, dass Geld ab einem gewissen Punkt zu Zeit wird.
    Einfache Reparaturen kann man entweder selbst machen oder Fachleute rufen.
    Nur ein Teil der Zeit, die in diese FreeBSD-Arbeit geflossen ist, kam von Tarsnap, und es war weniger als man vielleicht denken würde.

• Früher wurde FreeBSD einmal als Workstation verwendet, und das war beeindruckend.
  Man wollte FreeBSD gern als Heim-Gateway/Firewall/DNS/DHCP-Server nutzen, entschied sich am Ende aber für Nix, weil der Treiber für eine 10GbE-NIC nicht unterstützt wurde.
  Es ist schön zu sehen, dass FreeBSD weiterhin gut gepflegt wird.

• Es stellt sich die Frage, wer die großen Nutzer von FreeBSD/EC2 sind.

  • Das weiß man selbst auch nicht genau.
    Tatsächlich machen die Nutzer, die direkt Kontakt aufnehmen, offenbar nicht einmal 0,1 % aller FreeBSD/EC2-Nutzer aus.
    Man würde wirklich gern wissen, wer FreeBSD auf EC2 verwendet.

  • Die Frage, ob Netflix FreeBSD nur auf Edge-Boxen einsetzt.

• Es stellt sich die Frage, welche Nische FreeBSD innerhalb der Unix-Familie füllt.
  Warum man das komplexere FreeBSD statt OpenBSD oder NetBSD verwenden sollte, und ob man, wenn man ZFS, Nvidia oder ELF braucht, nicht gleich besser Linux nimmt.
  Die GNU-Problematik ist bekannt, aber es gibt auch Alternativen wie Musl Void; gefragt ist aus ehrlicher Neugier, was die klare „Identität“ von FreeBSD ist.

  • Erfahrung aus dem Finanzbereich mit FreeBSD sowohl auf EC2 als auch auf Bare-Metal-Servern im eigenen Rechenzentrum.
    ZFS und Jails wurden intensiv genutzt.
    Alle Dienste liefen getrennt in einzelnen Jails, was sehr kosteneffizient war.
    Als ein Teil in die Cloud verlagert wurde und ein hybrider Betrieb aus Linux (k8s) + FreeBSD entstand, stiegen die Kosten stark.
    Der direkte Betrieb des eigenen Rechenzentrums ist zwar umständlich, etwa bei Festplattenaustausch oder Brandfällen, aber AWS bietet dafür viele Funktionen wie Multi-Region-Betrieb — allerdings zu entsprechendem Preis.
    zfs half einmal enorm, als versehentlich eine Produktions-DB-Tabelle gelöscht wurde; dank Snapshots war ein sofortiges Rollback möglich, und zfs wurde auch für Backups genutzt.
    Außerdem gab es Erfahrungen mit Troubleshooting in Produktion per dtrace.
    Als auf den Servern nur FreeBSD lief, war die Verwaltung einfacher, weil es nur eine OS-Familie gab; mit der Einführung von Linux entstand Verwirrung, weil jedes Team eine andere Distribution nutzte.
    Es wird geschätzt, dass FreeBSD als integrierte Struktur aus Kernel + OS auftritt.

  • Aus eigener Sicht wirkt FreeBSD wie eine gelungene Mischung der Stärken von OpenBSD und NetBSD.
    Früher war FreeBSD bekannt für Optimierungen für Intel-CPUs und solide Sicherheit, und insbesondere die ZFS-Unterstützung war ein entscheidendes Unterscheidungsmerkmal.
    Native FreeBSD-Unterstützung für Nvidia-Treiber gibt es auch erst seit Kurzem.
    Letztlich verbindet FreeBSD die Stärken anderer BSDs gut mit Hardware-Stabilität.

  • FreeBSD hat einen deutlich größeren Nutzerstamm als OpenBSD oder NetBSD.
    Auch der Software-Katalog ist umfangreicher, sodass selbst die tägliche Nutzung als Desktop gut möglich ist.
    Warum nicht Linux? Weil Linux zu stark mit Unternehmensinteressen verflochten sei.

  • Die Meinung, dass FreeBSD bei der ZFS-Unterstützung Linux überlegen ist.
    Dank der Lizenzsituation bietet FreeBSD hier die bessere Umgebung.

  • FreeBSD ist OpenBSD bei der Netzwerk-Throughput-Leistung überlegen.
    Generell ändern sich BSDs weniger schnell und eignen sich daher gut als integrierte Plattform.

• Die Meinung, dass dieser Text das Entwicklungsumfeld von FreeBSD nicht besonders gut aussehen lässt.
  Angesichts der Komplexität eines solchen Betriebssystems sollte es mindestens jemanden geben, der hauptberuflich das Release-Management übernimmt; dass es in einem Jahr nur bei Teilzeit bleibt, wirkt bedauerlich.
  Trotzdem ist die Existenz von FreeBSD wichtig, weil Linux nicht die einzige Alternative sein sollte.