zurück zum Artikel

Nach dem geplatzten Release-Termin ist FreeBSD 13 nun reif für den produktiven Einsatz. Vor allem die schlechte WireGuard-Codequalität hielt das Projekt auf.

Für FreeBSD-Verhältnisse ist das neue Release 13.0 ein mächtiger Schritt nach vorne. Neben der Arbeit vieler freier Entwickler haben auch kleine und große Unternehmen eigene Mitarbeiter für Programmierprojekte und Verbesserungen rund um FreeBSD freigestellt. Außerdem wurden einige Entwickler für bestimmte Aufgaben von Unternehmen oder über die FreeBSD Foundation gesponsort. Doch nicht nur hinter den Kulissen scheint es mit FreeBSD 13.0 geradezu einen Paradigmenwechsel gegeben zu haben, denn eigentlich ist das unter der freien BSD-Lizenz stehende und auf 4.4BSD basierende Betriebssystem für eher konservative Entwicklungssprünge bekannt. Jeden sprichwörtlichen BSD-Graubart erschreckt auch das – im historischen Vergleich – radikal wirkende Abschneiden alter Zöpfe, darunter die langsame Abkehr von i386, das Entfernen der SPARC64-Plattform oder der Rauswurf der NE2000- und 3Com-Etherlink-III-Treiber.

Das deutlich gesteigerte Engagement großer Unternehmen in den Entwicklungsprozess ist natürlich erfreulich. Nicht nur BSD-nahe Firmen wie iXsystems oder Netflix, sondern auch Amazon und Microsoft, Apple, Sony bis hin zu Orange und viele mehr setzen FreeBSD (Download [1]) produktiv ein. Dass für FreeBSD korrekter Code dennoch wichtiger ist als aktuelle Features, zeigt die Panne mit der WireGuard-Implementation von Netgate, die unter anderem Grund für die etwa zweiwöchige Verzögerung des FreeBSD 13.0-RELEASE war.

Die Neuerungen in der Übersicht

Wie geplant begannen die Arbeiten am FreeBSD 13.0-RELEASE Anfang des Jahres. Im Februar gab es vier Beta-Versionen und im März die angekündigten zwei Release Candidates: RC1 brachte nochmal mehr Geschwindigkeit im TCP-Stack und SCTP-Fixes, RC2 behob aufkommende Probleme beim WireGuard-Interface (if_wg) und brachte kleinere Fixes für ZFS und ARM64 AES-XTS. So weit lief alles den üblichen Weg, Entwickler und Anwender hatten währenddessen genug Zeit, FreeBSD 13 zu testen. Der für Ende März vorgesehene Release-Termin platzte jedoch mit lautem Knall und einem notwendigen RC3, denn das FreeBSD-Team entschied sich dafür, den offenbar mit (zu) heißer Nadel gestrickten WireGuard-Code komplett aus dem Release zu werfen – er genügte den Qualitätsansprüchen nicht. Zusätzlich tauchte ein Fehler beim Einsatz von VirtualBox auf: Die I/O-Operationen eines FreeBSD-Gasts konnten sich aufhängen – ein bekanntes Problem von VirtualBox 5.x, das durch einen Patch (Asynchrones IO abschalten) mit herben Performance-Einbußen in FreeBSD 12.x temporär behoben wurde. Dieser "Hot-Fix" schaffte es nicht in VirtualBox 6 und tauchte daher erneut auf.

Als Notlösung kann in die /ect/sysctl.conf folgendes eingetragen werden:

vfs.aio.max_buf_aio=8192
vfs.aio.max_aio_queue_per_proc=65536
vfs.aio.max_aio_per_proc=8192
vfs.aio.max_aio_queue=65536

Einige Fehler in automatischen Installationsskripten, ein lästiges Speicherleck in NETMAP sowie ein aktualisiertes OpenSSL 1.1.1k machten einen RC4 nötig. Dem folgte kurze Zeit später ein RC5, bei dem ein Restart-Problem für Dienste wie nginx behoben und bessere 32-Bit-Kompatibilität bei AArch64 eingeführt wurden.

Das FreeBSD 13.0-RELEASE wurde schließlich wie angekündigt am 14. April veröffentlicht und erhält gemäß der neuen FreeBSD-Support-Richtlinien Unterstützung bis 2026. Der FreeBSD 11.x-Zweig nähert sich damit wohl gegen Ende des Jahres seinem End-of-Life.

Mehr Leistung für alle

Wie immer gibt es viele Neuerungen unter der viel strapazierten Haube, die der FreeBSD-Anwender nicht sieht, aber vielleicht spürt. Der Kernel wechselt an praktisch allen kritischen Stellen von klassischen Locks zu Epochs, also lockfreier Synchronisation. Das hilft massiv vor allem großen, stark parallelisierenden Maschinen mit mehr als 64 Kernen und entsprechenden Workloads. Im kleineren Maßstab, also in Appliances und vor allem auf dem Desktop macht sich das durch flinkere Reaktionen des Systems bemerkbar. Im Rahmen der Umstellung wurden diverse Kernelsubsysteme modernisiert und teilweise neu geschrieben, was nochmal Geschwindigkeitsvorteile bringt.

Die AMD64-Plattform läuft nun auch auf Hygon-Dhyana-Prozessoren. Dabei handelt es sich um eine Variante AMD EPYC-CPU (also den Zen-1-Core), die AMD bereits 2016 über ein kompliziertes Joint Venture an chinesische Prozessorhersteller lizensiert hat. China will damit technologische und wirtschaftliche Abhängigkeiten von ausländischen Produzenten reduzieren. Auf dem Hygon-Dhyana-SoC wurde AES durch chinesische Krypto-Hardware SM2, SM3 und SM4 ersetzt.

Die Unterstützung von Intels 5-Level-Paging [9] (LA57) erlaubt es FreeBSD 13, statt über bisher 48 Bit für virtuelle Adressen und damit 256 TiB Speicher nun 57 Bit (0-56) und damit bis zu 128 PiB anzusprechen. Entsprechende Hardware gibt es ab Ice-Lake-Prozessoren. Auch der native FreeBSD-Hypervisor Bhyve kann damit via "five layer nested page tables" umgehen.

i386 im Tier 2, bleibt trotzdem wichtig

Was etwas wirr klingt, ist die Entwicklung der i386-Plattform unter FreeBSD. 1993 erblickte FreeBSD auf einem Intel 80386 (i386) das Licht der Welt. Da i386-CPUs wichtige Funktionen fehlen, wurde FreeBSD/i386 seit einiger Zeit für mindestens die i486-CPU compiliert. Wer tatsächlich einen i386 einsetzen wollte, musste sich das komplette System selbst übersetzen. Der i386-Port rutscht mit FreeBSD 13 in Tier-Level 2 ab, soll aber trotzdem fast wie Tier 1 gepflegt werden. Das machen die FreeBSD-Entwickler nicht den Hardware-Nostalgikern zu Liebe, sondern um über die 32-Bit-Plattform auch Fehler in amd64 zu finden und vor allem, um viele Appliances und Embedded Devices auf Basis der alten x86-Prozessoren zu unterstützen. Da diese Systeme in der Regel mit i686-kompatiblen Prozessoren arbeiten, wird FreeBSD/i386 ab FreeBSD 13 auf i686 optimiert (default CPUTYPE=686). Damit entfällt die ungewöhnliche und archaische PC98-Architektur (NEC PC-98x1) komplett.

Die PowerPC-Architektur wurde vom alten GCC endlich auch komplett auf die LLVM-Infrastrutur umgestellt, womit die Toolchain nun der von amd64 entspricht. Gleichzeitig wechselte man zur ELFv2-ABI (Application Binary Interface, Binärschnittstelle). Dadurch sind Binaries aus FreeBSD-Versionen vor 13.0 nicht mehr unter 13.x lauffähig – außer sie laufen in einer Jail oder als chroot, da der Kernel nach wie vor ELFv1 unterstützt. Die Plattform erhielt auch weitere Netzwerk- und RAID-Controller-Treiber wie VirtIO für virtuelle Maschinen oder aacraid für Adaptec-Controller.

Der neue powerpc64le-Zweig (64-bit little endian) zielt auf POWER8- und POWER9-Prozessoren ab. Detailverbesserungen sollen deutlich mehr Geschwindigkeit bringen, beispielsweise verspricht ein Treiber für den XIVE-Interrupt-Controller ein Plus von 10 Prozent oder die Konversion von PMAP-Treibern zu ifunc (context switching) 20 Prozent mehr Leistung. Insgesamt soll das Compilieren beispielsweise mindestens 60 Prozent schneller laufen.

Mit einem gigantischen Patch rutscht die SPARC64-Architektur von Tier 2 auf Tier 4 [10] ab und erhält damit keinen Support mehr. RISC-V hingegen ist von Tier 3 auf Tier 2 aufgestiegen und sollte in absehbarer Zukunft auch in der Praxis einsetzbar sein. Bei den diversen MIPS-Port (auch Tier 2) ist es recht ruhig geblieben. Andere alte Architekturen wie IA-64 (Itanium) wurden nur bis FreeBSD 10.4, die DEC-Alphas sogar nur bis FreeBSD 6.4 unterstützt.

Der Aufstieg vom ARM

Wohl "Dank" der gut zweiwöchigen Verzögerungen beim FreeBSD-13.0-RELEASE hat es die 64-Bit-ARM-Architektur (AArch64, manchmal auch arm64) in letzter Sekunde noch geschafft, neben x86-64/amd64 die einzige Plattform mit vollem Support zu werden. FreeBSD definiert den Support in vier Stufen, wobei nur Tier 1 uneingeschränkte Unterstützung sowohl von Entwicklern, dem Release Engineering, dem Security Team, dem Ports-Management Team und eine vollständige Dokumentation erhält. Nur Tier 1 ist für den produktiven Einsatz vorgesehen. In Tier 2 befinden sich in Entwicklung befindliche Architekturen (z.B. RISC-V), Nischen-Architekturen oder Plattformen, die langsam ihr End-of-Life erreichen (z.B. i386). Tier 3 ist experimentell, Tier 4 bedeutet "kein Support".

Ed Maste, Senior Director of Technology innerhalb der FreeBSD Foundation, wies in seiner Ankündigung [11] auf die stark ansteigende Bedeutung von AArch64 hin und lobte die großzügige finanzielle und technischen Unterstützung durch ARM. Die Build-Infrastruktur wurde von Avantek durch ihre Ampere eMAG-Systeme unterstützt, die bis zu 32-Kerne @ 3.3 GHz und bis zu 512 GiB RAM bieten. Auch AWS stellt ihre Graviton-ARM64-Systeme bereit.

Freunde der kleinen ARM-SBCs dürfen sich freuen, denn Mast kündigte auch "one or more low-cost reference [ARM-]platforms" an – Images sind bereits für den Raspberry Pi und einige Pine ROCK64-Varianten vorhanden, in FreeBSD 12.2 gab es zusätzlich Images unter anderem für den Banana Pi M1 und den BeagleBone Black. Für den Raspberry Pi 4 wurde der Netzwerk-Treiber (GENET) von NetBSD portiert. Allgemein erhielt AArch64 den Linux-Compatibility-Layer (Linux-ABI), Unterstützung für den gdb(4)-Kernel-Debugger sowie viel weitere kleine Verbesserungen.

Deutliche Fortschritte gibt es für die Allwinner-SoCs bei GPIO-Interrupts, PMW-Hardware-Support, Audio auf H3/H5, Code für den Infrarot- und den Batterie-Sensor sowie USB DRD – womit USB-Geräte auf Allwinner-Boards endlich richtig nutzbar werden. Auch RockChip-SoCs (RK3328 und RK3399) unterstützen nun PWM-Hardware, externe PCIe-Adapter sowie USB3, dazu wurde das CPU-entlastende Flow-Control und Checksum-Offloading auf der Netzwerkkarte aktiviert.

Abschied von der GCC

Bereits bei FreeBSD 12 wurde die Toolchain auf LLVM/Clang umgestellt. In FreeBSD 13.0 kommen LLVM, Clang, lld, lldb-Tools, Compiler-rt, libunwind und natürlich die libc++-Bibliotheken in Version 11.0.1 zum Einsatz. Die alten GCC-Werkzeuge wurden deaktiviert, waren aber noch für einige Nischen-Architekturen notwendig. Das Problem war der Wechsel von GCC zur restriktiven GPL3, die für FreeBSD nicht akzeptabel ist. Aus diesem Grund konnte nur zähneknirschend die unter der GPL2 stehende, veraltete GCC-4.2.1-Suite eingesetzt werden. Mit FreeBSD 13 ist der Wechsel komplett, die GCC-Suite wird zum Compilieren der wichtigen FreeBSD-Architekturen selbst nicht mehr benötigt. Wer GCC und Co. dennoch benötigt, kann die Software aus den Ports installieren.

Auch andere GNU-Tools wurde nahezu komplett durch unter der BSD-Lizenz stehende Alternativen ersetzt. In der Praxis bedeutet das teilweise mehr, teilweise aber auch weniger Geschwindigkeit und eventuell leicht unterschiedliche Parameterbezeichnungen. Eines der noch unter der GPL stehenden Tools ist "diff3".

Der Kernel von FreeBSD 13 erlaubt W^X (Speicherbereiche sind entweder beschreibbar *oder* ausführbar, nicht jedoch beides) nun auch im Userland. Anders als bei OpenBSD wird diese Option jedoch wegen eventueller Probleme mit Anwendersoftware standardmäßig (noch) nicht eingeschaltet. Über die Kernel-Settings "kern.elf32.allow_wx" und "kern.elf64.allow_wx" kann W^X eingeschaltet werden, problematische Programme lassen sich per "elfctl(1)" und die Option "wxneeded" davon ausnehmen.

Ebenfalls im Kernel ist eine Implementation von KTLS gelandet, die zu GNU/Linux kompatibel sein soll. Hardware-Treiber für AESNI (amd64) und ARMv8cryto (AArch64-SoCs, die dieses Modul besitzen) sollen Verschlüsselungsroutinen beschleunigen.

Vor allem im Bereich Netzwerk und dort im Bereich Routing gab es viele Verbesserungen und teilweise komplett neue Implementationen, die den ohnehin guten Netzwerkdurchsatz von FreeBSD nochmals beschleunigen. Der Routing-Stack samt Multi-Routing-Support beispielsweise wurde komplett neu geschrieben [12] und basiert nun auf "Nexthops". In Nexthops sind alle notwendigen Informationen enthalten, um ein Paket zu routen – in etwa vergleichbar aber umfangreicher als die vorherige "rtentry"-Datenstruktur.

Mehr pf-Leistung dank Sponsor

Ein gutes Beispiel für durch Unternehmen gesponsorte FreeBSD-Entwicklung [13] ist die Arbeit an "pfsync" und "if_bridge": Orange (ehemals France Télécom S.A.). Das größte Telekommunikationsunternehmen in Frankreich betreibt einen Teil seiner Business Gateways mit FreeBSD. Olivier Cochard-Labbé, Gründer des FreeNSD- und des BSD-Router-Projektes, arbeitete bei Orange und erkannte dort einige Probleme bei "pfsync", dem "Packet Filter State Table Synchronisation Interface". Dabei handelt es sich um ein Pseudo-Device, über das die Statustabellen von parallelen Netzwerkverbindungen über den Paketfilter "pf" snychron gehalten werden. Der Paketfilter "pf" ist eine Abspaltung von OpenBSDs "pf" aus dem Jahre 2004 (FreeBSD 5.3). Die Weiterentwicklung von "pf" in FreeBSD hinkt seitdem der in OpenBSD deutlich hinterher.

Um das Performance-Problem für Orange zu lösen, holte Cochard-Labbé den Entwickler Kristof Provost mit ins Boot, der Maintainer von "pf" bei FreeBSD. Provost verdoppelte den Durchsatz von "pfsync" in rund sechs Monaten. Die beiden stießen dabei auf zusätzliche Probleme bei "if_bridge", das bei FreeBSD für das Bridging verantwortlich ist. Dessen massiv genutzter BRIDGE_LOCK-Mutex (Locking) konnte komplett ersetzt werden, was den Bridge-Durchsatz laut Messungen der beiden Entwickler von 3,7 auf 18,6 Millionen Pakete pro Sekunde verbesserte, also verfünffachte.

Ein neuer copy_file_range(2)-Systemaufruf erlaubt es NFS V4.2-Clients, Dateien lokal auf einem NFS V4.2-Server kopieren zu lassen, die Datei muss nicht durch das LAN zum Client und wieder zurück zum Server übertragen werden. Die NFS-V4.2-Implementation unterstützt auch Extended Attributes (RFC 8276). Uralte Treiber für Netzwerkkarten aus den Anfängen des PCs wurden aus dem FreeBSD 13.0 entfernt, darunter NE2000, 3Com Etherlink III, AMD PCnet und viele mehr.

Bhyve, der native und von Grund auf neu entwickelte Hypervisor von FreeBSD läuft mittlerweile stabil mit *BSD-, GNU/Linux-, Windows oder anderen Gästen. Ein paar alte Werkzeuge wie "bvmconsole" und "bvmdebug" wurden entfernt, dafür gibt es mit COM3 und COM4 zwei neue serielle Schnittstellen. Über VirtIO-9p lassen sich Host- und Gast-Dateisysteme teilweise zusammen benutzen – und ja, "9p" deutet darauf hin, dass der Code aus dem glorreichen Plan 9 [14] stammt.

Eine Snapshot-Funktion für virtuelle Maschinen unter Bhyve, die auch während des Betriebs möglich ist und so eine Live-Migration ermöglichen könnte, ist nicht ganz fertig geworden. In FreeBSD 13 ist die Funktion zwar in Bhyve enthalten, jedoch wegen der noch aktiven Entwicklung standardmäßig deaktiviert. VirtIO unterstützt nun die V1.0-Spezifikation, womit FreeBSD-Gäste besser unter den anderen Hypervisoren und unter QEMU beispielsweise mit dem emulierten Intel Q35-Chipsatz läuft.

Vorsicht beim Update von ZFS

ZFS, ursprünglich von Sun Microsystems entwickelt, wurde in drei freien Projekten teilweise getrennt voneinander weitergeführt: in Illumos, in FreeBSD und in GNU/Linux (ZoL) – hinzukommt ferner die Closed-Source-Variante von Oracle. Die drei freien Projekte haben ihre Ressourcen (und Sourcen) vor einiger Zeit im OpenZFS-Projekt zusammengeführt. Diese Codebasis ersetzt in FreeBSD 13 das "ZFS on FreeBSD" vorheriger Versionen. Es gibt neben Bedenken von Anwendern vor allem Verbesserungen in der Performance und in der Handhabung: Der ARC (Cache im RAM) arbeitet effizienter und schneller, der L2ARC (ARC-Erweiterung auf SSD) ist nun zwischen Bootvorgängen persistent, die ashift-Werte (minimale Blockgröße) und ein TRIM-Befehl wurden in die ZFS-Werkzeuge integriert. Für die Kompression wird nun "zstd" verwendet, Datasets lassen sich verschlüsseln und auch verschlüsselt per "zfs send" auf andere Pools duplizieren.

Bei einem Upgrade von FreeBSD 12.x auf 13.0 sollte zunächst von einem Upgrade der ZFS-Pools ("/usr/local/sbin/zpool upgrade tank") abgesehen werden, weil FreeBSD 13 zwar 12er-Pools lesen und schreiben, FreeBSD 12 aber bei einem Rollback mit den 13er-Pools nichts anfangen kann. Der Hinweis eines Lesers, dass nach einem Upgrade von 12.2 auf 13.0 das ZFS-Root-Dateisystem nicht gefunden wird, lässt sich durch Entfernen von

opensolaris_load="YES"

aus der /boot/loader.conf beheben.

Mit aller Macht, das Drama folgt

WireGuard ist eine VPN-Software, die technisch und von der Performance her etablierten Produkten wie OpenVPN überlegen ist. Neben GNU/Linux war es von Anfang an auch für FreeBSD geplant. Bereits Anfang 2020 gab es erste WireGuard-Commits von FreeBSD-Entwickler Matt Macy, der dazu eigens von Netgate bezahlt wurde. Netgate hat die FreeBSD-basierte Firewall-Distribution pfSense von einem freien Community-Projekt in ein kostenpflichtiges Enterprise-Produkt mit "zusätzlichen Funktionen" überführt. Hierbei sollte WireGuard fester Bestandteil von pfSense 2.5 werden und wurde als solches angekündigt – also musste der Code auch irgendwie in den FreeBSD-Kernel kommen. Kurz vor dem ursprünglich geplanten FreeBSD 13.0-RELEASE platzte die WireGuard-Bombe.

Mehrere Benutzer von pfSense beschwerten sich in den Netgate-Foren über Probleme und meldeten die Bugs sogar beim WireGuard-Projekt. Von dort aus nahm das Drama seinen Lauf: WireGuard-Entwickler Jason Donenfeld unterzog den in FreeBSD eingefügten Code einem Audit und fand verheerende Fehler: Sleep-Befehle, um Timing-Probleme im Protokoll zu beheben, Validierungsfunktionen, die einfach nur "true" zurückgaben, löchrige Kryptofunktionen, Teile des Protokolls, die nicht implementiert waren, Tricks, um Sicherheitsfunktionen zu umgehen, Überläufe von Variablen bis hin zu leicht über ein einzigen IP-Paket mit zu großer MTU-Size reproduzierbaren Kernel Panics. Die WireGuard-Implementation für FreeBSD war schlicht unbrauchbar – der gesamte Code flog aus dem Kernel und das RELEASE musste verschoben werden.

Wie konnte das passieren? Der originale Code stammt von Scott Long, aber auch Matt Macy und der FreeBSD-Entwickler Peter Grehan, der den Code einpflegte, sind Profis mit langjährigen FreeBSD-Erfahrungen. Das Security-Team von FreeBSD wurde offenbar nicht explizit mit einem Audit beauftragt und wurde offenbar auch von sich aus nicht aktiv. Am bislang von Netgate beziehungsweise seinen Entwicklern kommenden Code gab es nichts zu beanstanden. Liest man sich in den gesamten Vorgang ein und verfolgte die teilweise persönlich geführte Diskussion, sind wohl zwei Punkt die eigentliche Ursache: Netgate wollte mit aller Gewalt WireGuard in FreeBSD 13.0-RELEASE und damit in dem bereits angekündigten kommerziellen pfSense 2.5 drücken – und Matt Macy schien persönlich ausgebrannt und überfordert zu sein, er wollte das Projekt so schnell wie möglich vom Tisch haben. Die üblichen Kontrollinstanzen haben sich darauf verlassen, dass bei den beteiligten Profis alles so sauber und gut wie bisher lief.

FreeBSDs WireGuard-Maintainer Kyle Evans kündigte an [15], das WireGuard komplett aus dem Kernel des FreeBSD 13.0-RELEASE herausgeflogen sei. Die Entwicklung wird jedoch außerhalb des aktiven Entwicklungszweigs fortgeführt – wobei Evans zwei Tage später sein Amt als Maintainer für WireGuard niederlegte [16].

Damit hat es WireGuard nicht in FreeBSD 13 geschafft. Dasselbe gilt für USB4- und Thunderbolt-Support, der zwar weit gediehen, aber eben nicht fertig ist. Intern will man dringend die antiquierten GIANT-Locks abschaffen, mit der das gesamte System von einer Funktion gesperrt werden kann. An vielen Stellen wurde GIANT-Lock entfernt, einige wenige Relikte sind noch vorhanden, sollten im kommenden FreeBSD 14-RELEASE jedoch von alleine verschwinden, weil die Funktionen die GIANT-Lock benutzen in Codeblöcken zu finden sind, die sowieso ersetzt werden.

In jedem Fall empfehlenswert

Alles in allem fühlt sich trotz des WireGuard-Dramas das neue FreeBSD 13.0 aus Anwender- und Administratorensicht wie ein großer Schritt nach vorne an. FreeBSD als Baukasten für ein freies, maßgeschneidertes Open-Source-Betriebssystem hat einige Kanten und Ecken verloren und spürbar an Geschwindigkeit gewonnen.

Die vielen weiteren Verbesserungen und Bugfixes sind ausführlich in den Release Notes von FreeBSD 13.0-RELEASE [17] dokumentiert. Installationsmedien stehen in verschiedenen Formaten und Größen kostenlos auf der Projektseite für amd64/i386, ARM, PowerPC und RISC-V bereit. Dort sind auch Links zum (deutschen) Online-Handbuch, zu englischen Foren und den für FreeBSD-Admins wichtigen Mailinglisten. Deutsche FreeBSD- und *BSD-Anwender tummeln sich in den deutschsprachigen BSDForen [18].

[19]

(fo [20])

URL dieses Artikels:
https://www.heise.de/-6015871

Links in diesem Artikel:
[1] https://www.heise.de/download/product/freebsd-34126
[2] http://www.netbsd.org/docs/bsd/lite2/
[3] https://www.heise.de/news/Das-Allerwelts-Unix-10-Jahre-NetBSD-76625.html
[4] http://www.openbsd.org/
[5] http://www.netbsd.org/
[6] http://www.dragonflybsd.org/
[7] https://nomadbsd.org/
[8] https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/OSX_Technology_Overview/SystemTechnology/SystemTechnology.html
[9] https://en.wikipedia.org/wiki/Intel_5-level_paging
[10] https://cgit.freebsd.org/src/commit/?id=58aa35d42975
[11] https://lists.freebsd.org/pipermail/freebsd-announce/2021-April/002030.html
[12] https://cgit.freebsd.org/src/commit/?id=a666325282ea
[13] https://freebsdfoundation.org/blog/500-if_bridge-performance-improvement/
[14] https://www.heise.de/news/Plan-9-Der-UNIX-Nachfolger-lebt-und-wechselt-zur-MIT-Lizenz-6000735.html
[15] https://lists.freebsd.org/pipermail/freebsd-arch/2021-March/020296.html
[16] https://lists.freebsd.org/pipermail/freebsd-arch/2021-March/020302.html
[17] https://www.freebsd.org/releases/13.0R/relnotes/
[18] https://www.bsdforen.de/
[19] https://www.heise.de/ix/
[20] mailto:fo@heise.de

Copyright © 2021 Heise Medien