Ein Jahr Förderung für die FreeBSD-Entwicklung
(daemonology.net)- In einer Situation, in der FreeBSD/EC2-Wartung und Release Engineering innerhalb der ehrenamtlich verfügbaren Zeit einer einzelnen Person miteinander kollidierten, ermöglichte eine einjährige Förderung durch Amazon gleichzeitig den Release-Betrieb und Verbesserungen der EC2-Plattform
- Die Förderung hatte nominell einen Umfang von 40 Stunden pro Monat über GitHub Sponsors, die tatsächliche Arbeit lag jedoch im Durchschnitt bei 50 Stunden pro Monat; EC2-Themen, Release-Durchführung und sonstiges Release Engineering verteilten sich grob auf 20/20/10 Stunden
- Im Verlauf eines Jahres wurden die Releases FreeBSD 13.4, 14.2, 13.5 und 14.3 betreut, während zugleich priorisierte Arbeiten wie die Verarbeitung von Shutdown-Signalen auf AWS Graviton und Device-Hotplug auf EC2 vorangetrieben wurden
- Um Regressionen bei der Boot-Performance aufzuspüren, wurden wöchentliche EC2-AMI-Builds seit 2018 benchmarked; Verzögerungsursachen bei Root-Disk-Größe, EFI-Entropy-Seeding, ZFS-Transaction-Groups und IMDSv2-IPv6-Änderungen wurden identifiziert und behoben
- Auch nach dem Ende der Förderung wird die Rolle fortgeführt, aber es bleibt weniger Zeit, um Probleme kurz vor einem Release selbst zu beheben oder die EC2-Feature-Liste kontinuierlich voranzubringen
Engpässe vor der Förderung und Zeitverteilung
- Die Wartung von FreeBSD/EC2 läuft seit dem ersten Boot von FreeBSD auf Amazon EC2 im Jahr 2010; im November 2023 kam zusätzlich die Rolle als FreeBSD Release Engineering Lead hinzu
- Mit nur kleinen Förderbeträgen von Antithesis und dem FreeBSD/EC2-Patreon war es schwierig, beide Rollen zu bewältigen
- Die Liste der zu implementierenden Features stagnierte
- Selbst wenn Anomalien entdeckt wurden, fehlte oft die Zeit für Untersuchungen, sodass sie immer häufiger aufgeschoben wurden
- Anfang 2024 wuchs die Sorge, die Rolle eines „guten Owners“ der FreeBSD/EC2-Plattform nicht mehr erfüllen zu können
- Im April 2024 begannen Gespräche über Zeitplan, Umfang und Vorgehen, nachdem bei Amazon eine zuständige Person mit Budget gefunden worden war; Amazon sagte daraufhin eine einjährige Förderung über GitHub Sponsors zu
- Die Förderung umfasste 40 Stunden pro Monat für eine Kombination aus FreeBSD Release Engineering und FreeBSD/EC2-Entwicklung
- Es wurde klargemacht, dass eine Förderung nur eines der beiden Bereiche unrealistisch wäre, da beide Aufgaben voneinander abhängen
- Der tatsächliche Einsatz stieg im Schnitt auf etwa 50 Stunden pro Monat
- Im Mittel entfielen 20 Stunden auf reine EC2-Themen, 20 Stunden auf die Durchführung von FreeBSD-Releases und 10 Stunden auf sonstige Release-Engineering-bezogene Arbeiten, mit starken monatlichen Schwankungen
Quartalsweise Release-Durchführung und Build-Verbesserungen
- Entsprechend dem im Juli 2024 angekündigten quartalsweisen Release-Zeitplan für FreeBSD wurden innerhalb eines Jahres vier Releases betreut
- FreeBSD 13.4: September 2024
- FreeBSD 14.2: Dezember 2024
- FreeBSD 13.5: März 2025
- FreeBSD 14.3: geplantes Release am 10. Juni 2025
- Jedes Release umfasste das Fördern von Code-Merges, das Genehmigen oder Ablehnen von Merge-Anfragen, die Koordination mit anderen Teams, das Bauen und Testen von Images, das Schreiben von Ankündigungen sowie das Beheben von Problemen in Release-Builds
- Üblicherweise werden 3 Betas, 1 Release Candidate und das finale Release gebaut
- Der Großteil der Arbeit fällt in den Monat vor dem Release, also in den zweiten Monat jedes Quartals, den „Beta Month“
- FreeBSD 13.5 benötigte 33,5 Stunden, FreeBSD 14.2 79 Stunden
- Je später ein Stable-Branch in seinem Lebenszyklus ist, desto weniger Fehler treten typischerweise auf und desto geringer wird der Aufwand für das Release
- Für FreeBSD 14.1 wurde nicht mitgemessen, aber der Release-Engineering-Aufwand dürfte nahe bei 100 Stunden gelegen haben; bei FreeBSD 15.0 dürfte er deutlich höher ausfallen
- Im allgemeinen Release Engineering wurde außerdem die Parallelisierung von Release-Builds umgesetzt
- Mit der steigenden Zahl an EC2-AMIs machte die Installation von FreeBSD in VM-Images einen größeren Teil der Zeit aus als der eigentliche Build
- Der Release-Code wurde parallelisiert, allerdings traten sporadische Build-Fehler auf, und da ein kompletter Release-Build etwa 24 Stunden dauerte, war die Ursachenanalyse schwierig
- Die eigentliche Ursache war eine fehlende Zeile in einem Makefile: Ein Verzeichnis musste vor der Dateinstallation erstellt werden
- Nach der Korrektur sank die Dauer eines Release-Builds von etwa 22 Stunden auf etwa 13 Stunden, wodurch auch Erweiterungen der EC2-AMI-Flavours möglich wurden, die zuvor aus Zeitgründen aufgeschoben worden waren
- Probleme bei der Build-Reproduzierbarkeit werden inzwischen regelmäßig mit EC2 überprüft
- Im Rahmen der Tests für wöchentliche Snapshot-Images werden EC2-Instanzen gestartet, die eigene AMIs bauen
- Mit diffoscope werden die erzeugten Disk-Images mit den Original-Images verglichen
- Diese regelmäßigen Tests haben mehrere Probleme aufgedeckt; einige wurden direkt behoben, andere an andere Entwickler weitergegeben
Graviton-Strombehandlung und Hotplug in FreeBSD/EC2
- Die wichtigsten von Amazon priorisierten Features für FreeBSD/EC2 waren ein Power Driver für AWS-Graviton-Instanzen und Device-Hotplug
- Der Graviton-Power-Driver verarbeitet den Weg, über den die EC2-API das Betriebssystem über ein Herunterfahren informiert
- Ohne diese Funktion ignoriert FreeBSD das Shutdown-Signal, und nach einigen Minuten trennt EC2 nach einem Timeout die virtuelle Stromversorgung
- Der „Power Button“ auf Graviton-Systemen ist ein GPIO-Pin, dessen Details im ACPI-Objekt
_AEIhinterlegt sind - Es wurde Code ergänzt, um diese Informationen aus ACPI auszulesen und Konfigurationsdaten an den PL061-GPIO-Controller-Treiber zu übergeben
- Wenn der GPIO-Pin assertet wird, erzeugt der Controller einen Interrupt, worauf ein ACPI-„Power Button“-Event folgt, das zum Shutdown des Systems führt
- Die von EC2 bereitgestellten ACPI-Tabellen verlangen, dass dieser GPIO-Pin als „Pull Up“ konfiguriert wird, aber der PL061-Controller besitzt keine Pullup-/Pulldown-Widerstände
- Linux ignoriert das Scheitern der GPIO-Konfiguration stillschweigend, sodass das Problem dort nicht sichtbar wurde
- FreeBSD deaktivierte das Gerät nach einem Konfigurationsfehler
- Der Fehler auf EC2-Seite wird für künftige Graviton-Systeme voraussichtlich behoben; derzeit enthält das FreeBSD/EC2-AMI jedoch den Quirk
ACPI_Q_AEI_NOPULL, um das GPIO-PullUp-Flag im_AEI-Objekt zu ignorieren
- Hotplug, insbesondere Hot-Unplug, erforderte mehr Arbeit, weil sich auf mehreren EC2-Instanztypen unterschiedliche Probleme überlagerten
- Einige Graviton-Systeme ließen während des PCI-Attachs Reservierungen virtueller IRQs auslaufen; nach 67 Attach/Detach-Vorgängen eines EBS-Volumes waren die IRQs erschöpft und der FreeBSD-Kernel geriet in eine Panic
- Die Ursache lag im Legacy-Code für PCI-Interrupt-Routing; für EC2 wurde eine Bootloader-Einstellung ergänzt, die diesen Code deaktiviert
- Einige Graviton-Systeme verwendeten den PCI-Power-State eines Geräts als Signal dafür, ob das OS die Nutzung des Geräts abgeschlossen hat und zum Eject bereit ist
- Das wird als EC2-Bug eingestuft; derzeit werden mit dem Quirk
ACPI_Q_CLEAR_PME_ON_DETACHvor dem Eject einige Bits im PCI-Power-Management-Register verändert
- Das wird als EC2-Bug eingestuft; derzeit werden mit dem Quirk
- Auf x86 und Graviton aktueller EC2-Instanzgenerationen löste der FreeBSD-Treiber
nvmenach einem PCIe-Unplug eine Panic aus- Dieses Problem wurde an den Maintainer des
nvme-Treibers weitergegeben
- Dieses Problem wurde an den Maintainer des
- Auf einigen x86- und Graviton-EC2-Instanzen blieben nach einem Eject „Ghost“-Geräte auf dem PCI-Bus zurück und verhinderten das Attach neuer Geräte
- Die Nitro-Firmware verwaltet PCI-Bus und PCI-Geräte asynchron, sodass es ein Zeitfenster von einigen Millisekunden gab, in dem ein Gerät zwar bereits unplugged war, der PCI-Bus aber noch als vorhanden gemeldet wurde
- Linux scannt den Bus periodisch und verliert dieses Rennen meist, während FreeBSD direkt nach dem Detach den PCI-Bus sofort erneut scannt und daher häufig den Ghost sieht
- Derzeit fügt der Quirk
ACPI_Q_DELAY_BEFORE_EJECT_RESCANnach dem Eject-Signal eine Verzögerung von 10 ms vor dem erneuten Scannen des PCI-Busses ein
- Einige Graviton-Systeme ließen während des PCI-Attachs Reservierungen virtueller IRQs auslaufen; nach 67 Attach/Detach-Vorgängen eines EBS-Volumes waren die IRQs erschöpft und der FreeBSD-Kernel geriet in eine Panic
- PCIe verlangt nach dem Drücken des „Attention“-Buttons für einen Device-Eject-Request eine Verzögerung von 5 Sekunden; ein zweiter Tastendruck würde den Eject-Request abbrechen
- Auf EC2 gibt es keine Person, die einen physischen Knopf drückt, und auch keinen Mechanismus, denselben virtuellen Knopf erneut zu drücken; die Verzögerung ist daher unnötig
- Es wurde ein Bootloader-Tunable ergänzt, das auf EC2 den Timeout auf 0 setzt
- Mit einem Hotplug-Testskript lässt sich eine EC2-Instanz starten und per EC2-API wiederholt ein EBS-Volume an- und abstecken, um zu prüfen, ob FreeBSD 300 Attach/Detach-Zyklen in Folge übersteht
- Falls künftig Vorabzugang zu EC2-Instanztypen möglich ist, kann dies zur Überprüfung des Hotplug-Verhaltens genutzt werden
Verfolgung von Boot-Performance-Regressionen und AMI-Erweiterung
- Neben Amazons zwei Top-Prioritäten floss etwa die Hälfte der EC2-spezifischen Zeit in andere FreeBSD/EC2-Probleme
- Ende 2023 und Anfang 2024 brauchten FreeBSD/EC2-Instanzen gelegentlich länger als erwartet zum Booten, und in den Tests der wöchentlichen Snapshots musste die Wartezeit zwischen Instanzstart und dem Versuch einer SSH-Verbindung erhöht werden
- Um Performance-Probleme anzugehen, wurden die Boot-Zeiten wöchentlicher EC2-AMI-Builds seit 2018 benchmarked
- Dabei wurden mehr als 10.000 EC2-Instanzen gestartet
- Es wurden FreeBSD-Boot-Performance-Plots erstellt
- Die Erfassung neuer Daten und die Aktualisierung der Plots sind inzwischen Teil der Tests für die wöchentlichen Snapshots
- Mehrere Ursachen für Boot-Verzögerungen wurden identifiziert und behoben
- Seit der ersten Woche 2024 bootete FreeBSD etwa dreimal langsamer; zurückverfolgt wurde dies auf einen Commit, der die Root-Disk-Größe von 5 GB auf 6 GB erhöht hatte
- Prüfungen auf Amazon-Seite ergaben, dass eine Erhöhung der Root-Disk-Größe auf 8 GB die frühere Performance wiederherstellte
- Bei Systemen der Graviton-2-Familie führte ein Problem mit dem Kernel-Entropy-Seeding zu langen Boot-Zeiten
- Dem FreeBSD-Kernel fehlte bei der Erzeugung sicherer Zufallszahlen Entropie; in diesem Fall stoppt der Boot-Prozess, bis mehr Entropie gesammelt wurde
- Es gab bereits Code, um über den EFI-Bootloader einen sicheren Seed von der Nitro-Firmware zu beziehen, aber dieser wurde auf EC2 nicht ausgeführt, und auf Graviton 2 war eine Anforderung von 2048 Byte sehr langsam
- Die Anforderung wurde aus dem Lua-Code des Boot-Menüs an die richtige Stelle im Bootloader-Lua verschoben, damit sie unabhängig davon ausgeführt wird, ob das Menü deaktiviert ist
- Außerdem wurde die Lösung so geändert, dass 64 Byte EFI-Entropie bezogen und per PBKDF2 auf die für die API nötigen 2048 Byte erweitert werden; dadurch sank die Boot-Zeit von FreeBSD
arm64/base/UFSvon etwa 25 Sekunden auf etwa 8 Sekunden
- ZFS-Images booteten langsamer als UFS, und das Ausmaß der Verzögerung hing nicht von der Disk-Größe, sondern von der Datenmenge auf der Disk ab
makefsschrieb alles in eine einzige Transaction Group, und beim Attach eines ZFS lief die Verifikation über die zuletzt verwendete Transaction Group, wodurch sämtliche Dateimetadaten auf der Disk gelesen und verarbeitet wurden- Mark Johnston löste dies, indem das Dateisystem so geschrieben wurde, dass eine höhere Transaction Group eingetragen wird und die einzelne Transaction Group nicht mehr als „recent“ gilt
- Die Boot-Zeit von ZFS-Images sank von etwa 22 Sekunden auf etwa 11 Sekunden
- Nach der IPv6-Unterstützung im Port
net/aws-ec2-imdsv2-getim Dezember 2024 wurde ein Boot-Problem schnell erkannt- Dieser Port stellt eine Kommandozeilenschnittstelle für den EC2 Instance MetaData Service bereit
- Es wurde zuerst IPv6 versucht, obwohl die Standard-IMDS-Instanzkonfiguration nur IPv4 nutzte, und außerdem galt weiterhin der Standard-TCP-Timeout von 75 Sekunden
- Nach der Korrektur wird zuerst IPv4 versucht und der Timeout auf 100 ms reduziert
- Seit der ersten Woche 2024 bootete FreeBSD etwa dreimal langsamer; zurückverfolgt wurde dies auf einen Commit, der die Root-Disk-Größe von 5 GB auf 6 GB erhöht hatte
- Auch die FreeBSD-AMI-Flavours wurden erweitert
- Zuvor gab es nur
baseundcloud-init - Das
small-AMI entfernt Debug-Symbole, LLDB, 32-Bit-Bibliotheken, FreeBSD-Tests, Amazon SSM Agent und AWS CLI und reduziert den Disk-Verbrauch von etwa 5 GB auf etwa 1 GB - Das
builder-AMI stellt FreeBSD-AMI Builder AMIs bereit, mit denen Nutzer leichter angepasste FreeBSD-AMIs erstellen können
- Zuvor gab es nur
- Durch die Kombination aus 4 AMI-Flavours, 2 Dateisystemen, 2 Architekturen und 3 FreeBSD-Versionen nahm die Zahl der wöchentlichen Snapshot-Builds zu; daher wurden alte Images und die zugehörigen EBS-Snapshots aufgeräumt
- Das AWS-Konto des FreeBSD Release Engineering wird zwar durch Amazon gefördert, aber die Kosten trägt trotzdem jemand
- Mit einem Shell-Skript konnten EBS-Snapshots im Umfang von 336 TB entfernt werden
Verbleibende Aufgaben und Einschränkungen nach dem Ende der Förderung
- Neben den großen Projekten liefen auch viele kleinere Aufgaben weiter
- Beheben von Build-Breakages, die in den wöchentlichen Snapshot-Builds gefunden wurden
- Review von ENA-Treiber-Patches
- Unterstützung für Dave Cottlehuber beim Hinzufügen einer Funktion zum Bauen und Hochladen von OCI-Containern in ein Repository
- Verbesserung des Tools
bsdec2-image-upload, damit es interne AWS-Fehler robuster verarbeitet - Meldung eines zufällig entdeckten AWS-Sicherheitsproblems
- Auch nach dem Ende der Förderung bleiben die Rollen als FreeBSD Release Engineering Lead und Maintainer der FreeBSD/EC2-Plattform bestehen
- FreeBSD 15.0 wird im Dezember erwartet
- 2026 sollen 14.4, 15.1, 14.5 und 15.2 folgen
- Mit der sinkenden verfügbaren Zeit wird es schwieriger, Probleme kurz vor einem Release selbst zu beheben
- Spät eintreffende Features werden eher aus einem Release entfernt als rechtzeitig dafür repariert
- Dass OCI Containers ab FreeBSD 14.2 aufgenommen werden konnten, lag daran, dass in der geförderten Zeit sichergestellt werden konnte, dass alle nötigen Teile vollständig vorhanden waren
- Auf der EC2-Seite bestehen dank der Tests für Boot-Performance-Regressionen gute Chancen, entsprechende Probleme früh zu erkennen, aber ohne zusätzliche Zeit könnte die Liste neuer Features stagnieren
- Automatisches Vergrößern des Dateisystems beim Expandieren von EBS-Volumes
- Verbesserte automatische Konfiguration für mehrere Netzwerkschnittstellen und Hotplug von Netzwerkschnittstellen
- Rolling „pre-patched“ AMIs
- Eine Website zur Erzeugung von EC2-user-data-Dateien für Paketinstallation, Start von Daemons und Ähnliches
- Wiederaufnahme der Arbeit an FreeBSD/Firecracker und Ausbau zu einer unterstützten Plattform
- Die Förderung durch Amazon war eine deutlich größere Chance, als die meisten Open-Source-Entwickler sie erhalten, und neben dem Bedauern über ihr Ende bleibt Dankbarkeit für die in dieser Zeit erreichten Ergebnisse
1 Kommentare
Meinungen auf Hacker News
Schön. Ab heute haben wir FreeBSD zur Download-Seite von ziglang.org hinzugefügt, sodass FreeBSD-Nutzer automatisch in der CI gebaute Builds des Master-Branches bekommen können.
Es wird jetzt einschließlich libc-Linking als erstklassiges Cross-Compilation-Target unterstützt, also ist auch etwas wie
zig cc -o hello hello.c -target riscv64-freebsdmöglich.Wenn es C/C++-Abhängigkeiten gibt, kann man sie ins Zig-Build-System holen und bauen, daher dürften sich auch ziemlich komplexe Projekte leicht für FreeBSD cross-kompilieren lassen. Ich hoffe, das hilft mehr Projekten dabei, FreeBSD-Support und CI-Tests hinzuzufügen.
Es wäre schön, einen offiziell anerkannten C-Ersatz zu haben.
Hier gibt es einige ziemlich interessante Stellen.
„Ab der ersten Woche 2024 wurde der FreeBSD-Bootvorgang plötzlich ungefähr dreimal langsamer. Ein Bisect der Commits zeigte, dass die Ursache ein Commit war, der die Größe der Root-Disk von 5 GB auf 6 GB erhöhte. Warum war das so? Als ich Bekannte bei Amazon fragte, lag die Antwort irgendwo zwischen ‚Magie‘ und ‚das willst du wirklich nicht wissen‘; wichtig war, dass die Performance wieder auf das frühere Niveau zurückkehrte, als die Root-Disk auf 8 GB erhöht wurde.“
Ob das mit der beobachteten Performance-Klippe zusammenhängt, weiß ich nicht.
Auch auf der Laptop-Seite passiert viel, und ich habe gelesen, dass die BSD Foundation hier 750.000 Dollar investiert hat.
Dazu gehören Implementierungen wie S0ix-Schlafzustände; das Projekt findet man hier: https://github.com/FreeBSDFoundation/proj-laptop
Ich habe wirklich großen Respekt vor cperciva.
Ich weiß nicht, wie er all das und Tarsnap gleichzeitig schafft.
Fairerweise stammt ein Teil der hier investierten Zeit aus der Tarsnap-Zeit, aber deutlich weniger, als man denken würde.
Ich hätte erwartet, dass Amazon mehr ausgibt und beiträgt, aber grundsätzlich sieht es so aus, als wollten sie nur für minimale FreeBSD-Unterstützung zahlen.
Amazon steht nicht einmal auf der Liste der FreeBSD-Sponsoren [1], Google hat letztes Jahr nur 9.000 Dollar gespendet, und Apple fehlt ebenfalls. Microsoft steht immerhin auf der Liste, das kann man anerkennen. Meta/Facebook fehlt auch.
Diese Unternehmen nutzen FreeBSD und OpenBSD und profitieren weiterhin davon, daher hätte ich grundsätzlich erwartet, dass sie jedes Jahr spenden.
[1] https://freebsdfoundation.org/our-donors/donors/?donationYea...
Zum Beispiel lief das Geld, das sie mir gezahlt haben, nicht über die Foundation. Ich würde schätzen, dass von der FreeBSD-Entwicklung, die mit Unternehmensgeldern finanziert wird, vielleicht etwa 10 % von der Foundation unterstützt werden.
Diese 10 % sind wichtig, weil sie sich besonders auf „was FreeBSD braucht“ konzentrieren können und nicht auf „was Unternehmen X braucht“, aber es bleibt dennoch ein kleiner Anteil.
Erstens zeigt es nur eine Momentaufnahme der Foundation-Spenden eines bestimmten Jahres, daher ist die Spendenhistorie natürlich nicht sichtbar.
Zweitens zeigt es auch keine Entwicklungsbeiträge. Solche Dinge kann man normalerweise zusammengefasst in den jeweiligen Release Notes sehen [1].
[1] https://www.freebsd.org/releases/
Mir fällt auch kein Microsoft-Dienst ein, ob Cloud oder nicht, der auf *BSD läuft.
Ich wollte FreeBSD als Heim-Gateway/Firewall/DNS/DHCP-Server verwenden, aber für meine 10GbE-NIC scheint es keinen Treiber zu geben, daher habe ich mich letztlich für Nix entschieden.
Vor langer Zeit habe ich FreeBSD als Workstation genutzt, und das war eine ziemlich einprägsame Erfahrung. Schön zu sehen, dass es immer noch stetig weiterläuft.
Realtek scheint unter Last kaputtzugehen, obwohl die FreeBSD-Engineers, die den Treiber warten, sich sehr bemühen. Das ist keine Beschwerde; ich respektiere ihre Arbeit.
Das ist ein kleiner Preis und erspart mir, ein weniger stabiles Betriebssystem installieren zu müssen.
Aus der Zeit um FreeBSD 7 oder 8 erinnere ich mich daran, dass die FreeBSD-Treiber für Dinge wie Atheros-Wi-Fi-Karten besser waren als die unter Linux
Bis etwa 2021 bevorzugte ich FreeBSD, aber das änderte sich, als Computer mit gemischten CPU-Kernen häufiger wurden. Zuerst kaufte ich ein RockPro64 mit 2 big Cores und 4 little Cores, später dann Intel Alder Lake
Nach meinem Verständnis kann der FreeBSD-Scheduler solche Konfigurationen noch nicht richtig handhaben und scheint das System auf den kleinsten gemeinsamen Nenner der langsameren Kerne herunterzuziehen
Aus Neugier: Wer sind eigentlich die Hauptnutzer von FreeBSD/EC2?
Ich würde wirklich gern wissen, wer FreeBSD auf EC2 nutzt
Ein Beitrag, der sehr gut zeigt, wie Open-Source-Sponsoring durch Unternehmen funktioniert
Kann jemand, der FreeBSD nutzt, erklären, welche Nische FreeBSD im Unix-Umfeld ausfüllt? Warum FreeBSD und nicht das einfachere und konsistentere OpenBSD oder NetBSD?
Wenn die Antwort Unterstützung für Dinge wie ZFS, Nvidia-Treiber oder ELF ist: Warum dann nicht Linux? Die Probleme mit GNU kenne ich gut, aber gibt es auch bei etwas wie Musl Void Probleme?
Ich bin wirklich neugierig. FreeBSD existiert für mich wie eine Art Schattenbereich: Ich konnte die Kernidentität, die es am Laufen hält, nie genau fassen, weiß aber, dass sie irgendwo da ist
Jeder Dienst lief zur Isolation in seinem eigenen Jail, und ein einzelner, nicht einmal besonders leistungsstarker Server konnte alle Dienste ausführen, was enorm kosteneffizient war
Irgendwann migrierten wir für ein hybrides Setup in die Cloud, und als wir Linux (k8s) und FreeBSD mischten, schossen die Kosten in die Höhe. Im Rechenzentrum muss man Festplatten selbst kaufen und austauschen und auf Dinge wie Brände reagieren, außerdem ist man nur in einem Land präsent; AWS bietet dagegen Multi-Region und viele gute Funktionen, hat aber entsprechend seinen Preis
Wir haben ZFS nicht extrem intensiv genutzt, aber als in der Produktions-DB versehentlich eine Tabelle gelöscht wurde, rettete uns ein sofortiger Rollback auf den letzten ZFS-Snapshot einmal gewaltig. Es gab etwas Datenverlust, aber bei dieser Anwendung war Verfügbarkeit wichtiger, daher war das kein großes Problem. Ich erinnere mich, dass wir ZFS auch für Backups verwendeten
dtrace habe ich ein paar Mal zur Fehlersuche in der Produktionsumgebung genutzt, und als Linux in unsere FreeBSD-Serverflotte eingeführt wurde, wählte jedes Team ganz natürlich eine andere Distribution, sodass eine Art Zoo entstand. Wenn man FreeBSD auf Servern einsetzt, gibt es nur eine Variante
Ich nutze und mag weiterhin beides, aber mir gefällt an FreeBSD wirklich, dass Kernel und Betriebssystem integriert sind
Historisch priorisierte FreeBSD Intel-CPUs, NetBSD war stärker auf Portabilität ausgerichtet, und FreeBSD hatte zwar ebenfalls solide Sicherheit, aber OpenBSD konzentrierte sich noch stärker auf Security
Die ZFS-Unterstützung von FreeBSD ist wirklich ein Gamechanger. Soweit ich weiß, bietet Nvidia erst seit Kurzem native FreeBSD-Treiber an; lange Zeit war dafür die Linux-Kernel-Kompatibilität von FreeBSD nötig
Anders gesagt: FreeBSD mischt die Funktionen, die die anderen BSDs bieten, sehr gut und war auf der von mir hauptsächlich genutzten Hardwareplattform zugleich extrem stabil
NetBSD konkurriert über Portabilität und scheint nicht sehr viel Zeit darauf zu verwenden, den Netzwerkdurchsatz hoch zu halten
Alle BSDs ändern sich insgesamt deutlich weniger, was Vor- und Nachteile hat, sie meiner Meinung nach aber zu besseren Plattformen für Integration macht
Auch die Softwareauswahl ist deutlich größer, und es taugt als modernes Desktop-Alltagsbetriebssystem. Über die anderen beiden lässt sich das schwer sagen
Warum nicht Linux? Weil ich Linux nicht will. Es wird zu sehr von Unternehmensinteressen erdrückt