Fedora 33 wird ein enorm spannendes Release und vermutlich auch das größte seit Jahren. Einige mittlerweile teils angenommene Vorschläge habe ich bereits vorgestellt. Dabei ging es um Swap per zRAM, Btrfs als Standard-Dateisystem und die Auslieferung von Stratis 2.1.0.
Für Windows-Games unter Linux
Jetzt wurde ein weiterer Vorschlag eingebracht, der den Gamern unter den Fedora-Nutzern gefallen wird. Dabei soll DXVK das bisherige wined3d-Backend für die Verwendung von Direct3D 9, 10 und 11 ersetzen. Die Wine-Entwickler arbeiten seit geraumer Zeit daran, Vulkan direkt zu unterstützen, jedoch geht hier wohl noch einige Zeit ins Land. Das in Wine implementierte wined3d nutzt für Direct3D OpenGL.
DXVK für Wine als Standard
Das auf GitHub gepflegte DXVK ist eine Alternative zu wined3d und bietet eine leistungsfähigere und kompatiblere Möglichkeit, Windows-Anwendungen und Spiele mit DirectX 9, 10 und 11 auszuführen. Während Anwender DXVK seit Fedora 31 mit dem Paket wine-dxvk auch bisher schon installieren konnten, soll es nun zum Standard-Backend werden.
Sollte der Vorschlag angenommen werden, wird im Paket wine-dxvk sichergestellt, dass es nur auf Systeme als Standard-Backend angeboten wird, deren GPU Vulkan-kompatibel ist. Das Paket wine-dxvk wird dann als Empfehlung in Wine selbst eingefügt. Eine Alternative stellt der Spiele-Manager Lutris dar, der ebenfalls DXVK unterstützt.
Verbesserte Leistung
Fedora-Benutzer, die aktuelle Windows-Spiele ausführen, erhalten mit DXVK verbesserte Leistung und Kompatibilität. Steam Play und Proton nutzen die Alternative bereits mit Erfolg, aber es gibt auch andere Game Stores und eigenständige Spiele, die von DXVK profitieren. Benchmarks belegen, dass DXVK in der Lage ist, in vielen Spielen bis zu 85 Prozent der nativen Frameraten zu erlangen.
Erst letzte Woche hatte das Fedora-Steuerungskomitee beschlossen, dass mit Fedora 33 Btrfs das neue Standard-Dateisystem für die Desktop-Varianten der Distribution sein wird. Jetzt wurde ein weiterer recht später Vorschlag unterbreitet, Stratis 2.1.0 mit Fedora 33 auszuliefern.
Red Hats eigene Storage-Lösung
Der zeitliche Zusammenhang lässt darauf schließen, das Red Hat darauf drängt, das dort favorisierte Storage-System Stratis 2.1.0 ebenfalls mit auszuliefern. Da Btrfs bei Fedora nur den Desktop betrifft, können sich die Varianten Server, IoT und andere die erweiterten Möglichkeiten von Stratis 2.1.0 zugute machen. Red Hat hatte sich 2017 von Btrfs abgewandt und die Entwicklung von Stratis begonnen.
Gut integrierte Lösung
Stratis soll die Eigenschaften von ZFS und Btrfs mit Blick auf künftige Anforderungen an Storage abbilden. Dabei will Red Hat aber kein neues Dateisystem schreiben, sondern unter Verwendung von XFS eine Anwendung bauen, die Anwendern mit unterschiedlichsten Storage-Anforderungen eine gut integrierte Lösung mit konsistenter Konfiguration bietet.
In Rust und Python umgesetzt
Hauptentwickler Andy Grover beschrieb es in einem Strategiepapier als eine Kommandozeilenlösung mit einer umfassenden API, die auf bestehenden Techniken aufbaut. Stratis wird in Rust und Python umgesetzt. Die eingesetzten Komponenten sind das Dateisystem XFS als Grundlage und Device-Mapper als Schnittstelle zur Erzeugung virtueller blockorientierter Geräte.
Verschlüsselung per Pool
Stratis 2.1.0 bietet Verschlüsselung auf der Ebene von Pools auf der Basis von LUKS2, führt neue D-Bus-Schnittstellen ein und baut stratis-cli weiter aus. Die Verschlüsselung eines Pools schließt alle darin eingebundenen Geräte ein. Pools werden mithilfe eines Schlüssels im Kernel-Schlüsselring verschlüsselt. Jeder verschlüsselte Pool kann einen anderen Schlüssel verwenden, aber alle Geräte in einem Pool werden mit einem einzigen Schlüssel verschlüsselt.
Nur für neue Pools
Anwender werden die neue Verschlüsselungsmethode nur wahrnehmen, wenn sie einen neuen Pool aufsetzen. Für bestehende Dateisysteme ändert sich nichts. Ein Tutorial auf der Webseite von Red Hat, führt in die Verwendung von Stratis ein, beinhaltet aber noch nicht die neuen Möglichkeiten der Verschlüsselung mit Stratis 2.1.0.
Prall gefülltes Release
Das für den 20. Oktober zur Veröffentlichung anstehende Fedora 33 schickt sich an, eine der Veröffentlichungen mit den meisten Änderungen der letzten Jahre zu werden, sowohl was die Zahlen als auch die Bedeutung der Änderungen angeht.
Vor rund zwei Wochen wurde ein Vorschlag publik, Btrfs zum Standard-Dateisystem bei den Desktop-Varianten des im Oktober zur Veröffentlichung anstehenden Fedora 33 zu machen.
Zustimmung und Kritik
Sah es zunächst wegen viel Kritik, zuletzt im Blog von Red-Hat-Entwickler Colin Walters, so aus, als habe dieser Vorschlag wenig Chancen auf Erfolg, so wurde er gestern vom Fedora Engineering and Steering Committee (FESCo) mit 8 zu 1 Stimmen angenommen. Damit geht der Staffelstab von Ext4 an Btrfs über, sofern bis Oktober keine triftigen Gründe auftauchen, die den Wechsel verhindern.
Btrfs als Standard für Fedora 33
Somit wird Fedora 33 mit Btrfs als Standard-Dateisystem veröffentlicht. Das betrifft die Workstation-Edition und sämtliche Spins und vermutlich auch die Labs. Nicht betroffen sind Fedora Server, CoreOS, und IoT. Über Fedora Silverblue bin ich mir noch nicht im Klaren. Es ist eine Workstation-Variante, die eigentlich für Btrfs prädestiniert scheint, jedoch gibt es einigeBugs im Zusammenhang mit OSTree, die noch nicht komplett gelöst sind.
Vor 10 Jahren gescheitert
Bereits vor fast 10 Jahren unternahmen Fedora-Entwickler einen ersten Vorstoß, Btrfs zum Standard zu machen, was jedoch bei Fedora 15 und 16 scheiterte. Btrfs bietet gegenüber Ext4 zusätzlich CoW-Snapshots, transparente Dateisystemkomprimierung, SSD-Speicheroptimierungen, native RAID-Funktionen, Checksummen, die I/O-Isolation per Cgroups2 und eine Vielzahl anderer moderner Funktionen.
Desktop-Nutzer sollen profitieren
Die Fedora-Entwickler, die hinter dem aktuellen Vorschlag stehen – darunter auch Facebook-Btrfs-Betreuer Josef Bacik, der bereits 2011 den ersten Vorschlag einreichte, wollen damit »neue Funktionen hinzufügen und gleichzeitig die notwendige Menge an Fachkenntnissen verringern, die für den Umgang mit Situationen wie dem Mangel an Festplattenspeicher erforderlich sind«. Btrfs sei von der Designphilosophie her gut an diese Rolle angepasst, so die Entwickler.
Es wird nun interessant sein zu sehen, wie Red Hat auf diese Änderung reagiert. Dort hatte man 2017 die Unterstützung für Btrfs aufgegeben und vermehrt in XFS und Stratis investiert.
Seit einigen Tagen wird auf der Fedora Mailingliste ein Vorschlag diskutiert, mit dem für den Herbst erwarteten Fedora 33 Btrfs anstatt Ext4 als Standard-Dateisystem für die Fedora Workstation auszuliefern. Der Vorschlag wird nicht nur von langjährigen Fedora-Entwicklern wie Neil Gupta unterstützt, sondern auch von Btrfs-Maintainer Josef Bacik, der bei Facebook mit für Btrfs verantwortlich ist.
Besser als sein Ruf
Btrfs hat über die Jahre einen schlechten Ruf erworben. Es gab viele Probleme, die teils sogar mit Datenverlust einhergingen. Auch die fehlenden oder qualitativ schlechten Tools zur Problemanalyse und -behebung standen in der Kritik. Damit hat die einst als das kommende neue Standard-Dateisystem für Linux gehandelte Software viel von ihrem Renommee verloren.
Seit Jahren im Einsatz
Andererseits setzen openSUSE und SUSE das Dateisystem seit 2014 als Standard ein. Bei Facebook laufen Millionen Server mit einfachen Consumer-SSDs auf Btrfs. NAS-Distributionen wie Rockstor oder die Software von NAS-Hersteller Synology und einiger anderer setzen ebenfalls darauf.
Ist der Ruf erst ruiniert…
Eines der Probleme von Btrfs heute ist, dass ein angekratzter Ruf schwer zu revidieren ist, da helfen die gebetsmühlenartig wiederholten Berichte aus der Vergangenheit nicht. Dabei ist das Dateisystem laut Meinung vieler Entwickler heute um einiges besser als sein Ruf. Lediglich bei RAID5/6 gibt es noch Probleme, die aber zum Teil auch an der Implementierung dieses RAID-Levels liegen.
Btrfs hat gegenüber dem derzeit bei Fedora genutzten Standard LVM + ext4 unbestreitbare Vorteile, allen voran native Subvolumes, Crc32c-gestützte Checksummen, transparente Kompression, Deduplikation und Resizing. Hinzu kommen Snapshots, die auf einzelne Subvolumes begrenzt werden können.
Erster Versuch
Fedora und Red Hat haben eine wechselvolle Geschichte, wenn es um das Next-Gen-Dateisystem geht. Bereits 2011 sollte Btrfs mit Fedora 16 zum Standard werden, jedoch fand dies auch mit den Ausgaben 17 und 18 keine Mehrheit in Fedoras Steuerungskomitee FESCo.
Bei Red Hat wurde das unter RHEL 6 als technische Vorschau eingeführte Dateisystem Btrfs nicht in RHEL 7 übernommen, sondern von XFS ersetzt. Gleichzeitig startete Red Hat auf dessen Basis die Entwicklung von Stratis als neuem Storage-System.
Als Gründe für den Umstieg gab Red Hat den berüchtigten »out of disk space« Fehler an, der es bereits in die offizielle FAQ geschafft hatte, sowie Probleme mit den Balance Filtern für Metadaten. Zudem soll OverlayFS nach einer Auswertung bei Red Hat schneller beim Erstellen und Entfernen von Docker-Containern sein als Btrfs.
Kein Entwickler an Bord
Red Hats Entscheidung ist nachvollziehbar, wenn man weiß, dass mit Josef Bacik bereits 2012 der einzige Btrfs-Entwickler auf Red Hats Besoldungsliste das Unternehmen verließ, um 2013 zusammen mit Btrfs-Vater Chris Mason bei Facebook anzuheuern, wo seitdem der Schwerpunkt der Weiterentwicklung liegt.
Die Diskussion bei Fedora beginnt gerade erst und es wird spannend zu sehen, ob Fedora diesen Schritt für das im Oktober erwartete Fedora 33 geht, obwohl Red Hat Btrfs 2017 den Laufpass gegeben hat.
Fedora plant für die Ausgabe 33 im Herbst 2020 die Einführung von Swap per zRAM. Das geht aus einem jetzt veröffentlichten Vorschlag hervor, der noch vom Steuerungskomitee FESCo abgesegnet werden muss.
ARM und IoT
Bereits mit Fedora 29 wurde zRAM als Swap für die ARM-Spins und für Fedora IoT eingeführt. Jetzt sollen Fedora Workstation und alle anderen Editionen, Spins und Labs folgen. Damit würde für Fedora die herkömmliche langsame Swap-Partition der Vergangenheit angehören.
Seit 2014 im Kernel
zRAM ist ein Kernelmodul zum Erstellen eines komprimierten Blockgeräts im RAM, also einer RAM-Disk, aber mit Komprimierung zur Laufzeit. Das mit zRAM erstellte Blockgerät kann dann für Swap oder als Allzweck-RAM-Disk verwendet werden. zRAM ist seit 2014 und Version 3.14 im Kernel. Googles Chrome OS nutzt zRAM bereits seit 2013, Android liefert es seit Version 4.4 aus.
Der jetzt vorliegende Vorschlag der Fedora-Entwickler geht davon aus, dass Swap generell eine gute Sache ist, außer er ist langsam. Computer nutzen Swap zum Auslagern, wenn der Platz im Arbeitsspeicher knapp wird. Dazu kam bisher meist eine Swap-Partition oder eine auch später anzulegende Swap-Datei zum Einsatz.
Einrichten beim Hochfahren
Mit Fedora 33 soll beim Hochfahren ein Swap-on-zRAM eingerichtet werden. Das virtuelle Gerät zram, typischerweise /dev/zram0, hat eine Größe, die bei der Einrichtung früh im Bootprozess durch den zram-generator per Konfigurationsdatei festgelegt wird. Der verwendete Speicher ist nicht vorbelegt, er wird dynamisch zugewiesen und bei Bedarf wieder freigegeben. Aufgrund der Komprimierung verbraucht ein volles /dev/zram0 nur etwa halb so viel Speicher wie seine tatsächliche Größe.
50 Prozent oder maximal 4 GByte
Die Standardeinstellungen sehen vor, dass für /dev/zram0 50 Prozent des RAM oder maximal 4 GByte reserviert werden. Wird der Swap vollständig mit 4 GByte gefüllt, werden die Daten im Idealfall auf 2 GByte komprimiert. Die tatsächliche RAM-Auslastung lässt sich mit dem Befehl zramctl überprüfen. Wird die Nutzung von zRAM nicht gewünscht, so kann sie per swapoff /dev/zram0 stillgelegt oder per rm /etc/systemd/zram-generator.conf ganz entfernt werden.
Alle halbe Jahre und zeitlich nicht weit vom Ubuntu-Release entfernt erscheint eine neue Version von Fedora, der Distribution aus Red Hats Hexenküche. Bei Fedora wird das entwickelt, was zeitversetzt dann bei Red Hat Enterprise Linux (RHEL) kommerziell angeboten wird.
Pünktlich ausgeliefert
Zunächst um eine Woche verschoben, steht mit Fedora 32 jetzt zum geplanten Ausweichtermin die neue Version ins Haus, die in den Varianten Workstation, Server und Cloud und IoT ausgeliefert wird. Grundzutaten bei der Workstation sind Kernel 5.6 und GNOME 3.36.
TRIM: Spät aber doch noch
Auffallende Neuerungen bei Fedora 32 sind die Einführung von EarlyOOM für eine besser kontrollierte Speichernutzung und die standardmäßige Aktivierung von TRIM für SSDs. Mit EarlyOOM soll das Einfrieren des Rechners bei vollem Speicher verhindert werden. Das kann passieren, wenn nur wenig Speicher verbaut ist oder wenn fehlerhafte Anwendungen den Speicher volllaufen lassen.
Speicher verfügbar halten
Das jetzt standardmäßig aktivierte Paket EarlyOOM tritt dem entgegen, indem es bei Speichernotstand von nur 10 Prozent freiem Speicher den speicherhungrigsten Prozess sauber herunterfährt (SIGTERM) oder bei 5 verbleibenden Prozent sofort beendet (SIGKILL).
Warum die Entscheidung, TRIM standardmäßig zu aktivieren, so spät kommt, bleibt unklar. Jetzt ist es aber so weit. Einmal pro Woche wird per Systemd-Timer der Befehl fstrim ausgeführt und damit flashbasierte Storage-Geräte wie etwa SSDs über nicht mehr verwendete Blöcke informiert, die dann wieder freigegeben werden.
Modularität gescheitert?
Bei der Bestrebung nach mehr Modularität in Fedora gehen die Entwickler aufgrund von anhaltenden Diskussionen auf der Mailingliste nun einen Schritt zurück. Das Projekt stand von Anfang an unter keinem guten Stern. Die Beschwerden kommen sowohl von Anwendern als auch von Paketbetreuern, sodass die Entwickler ein Einsehen zeigen und bei Neuinstallationen die aktivierten zusätzlichen Streams wegfallen, bis eine praktikable Richtlinie dazu gefunden ist. Bestandsanwender können die Streams aus den zusätzlichen Repositorien deaktivieren.
Python 2 ist Geschichte
Die Toolchain setzt bei Fedora 32 auf die GNU Compiler Collection 10 (GCC) und LLVM 10, die GNU-C-Bibliothek in Version 2.31, Binutils 2.33, Ruby 2.7, Golang 1.14 und Python 3.8. Bei Python 2 erfolgt ein klarer Schnitt. Python 2 sowie alle Unterpakete und Abhängigkeiten sind aus Fedora 32 entfernt worden. Ein älteres python27-Paket wird aus Kompatibilitätsgründen weiterhin zur Verfügung gestellt. Alle Pakete, die Python 2 zur Ausführung benötigen oder die zum Kompilieren Python 2 benötigen, wurden unabhängig von ihren Abhängigkeiten ebenfalls entfernt.
Spins und Labs
Fedora 32 wird in vielen Varianten veröffentlicht. Neben Fedora Workstation für den Desktop und den Versionen für Server und Cloud in Form von Fedora Silverblue wurden auch die Spins und Labs aktualisiert. Mit den Spins stellt Fedora von der Community gepflegte Varianten mit verschiedenen Desktops bereit. Derzeit stehen Spins für KDE Plasma, Xfce. LXDE, LXQt. Mate-Compiz, Cinnamon und Sugar on a Stick (SOAS) zur Verfügung.
Bei den Labs handelt es sich um Abbilder, die für verschiedene Interessengruppen erstellt werden. Derzeit decken die Labs die Gebiete Astronomie, Design, Spiele, Musikproduktion, Python, Sicherheit und seit dieser Ausgabe auch Computer-Neurowissenschaften ab. Daneben bedient Fedora auch die ARM-Plattform sowie die Power-Architektur und S390x mit Abbildern für Workstation, Server und für alle Spins.
Pünktlichkeit ist eine Zier…
Lobend zu erwähnen bleibt die pünktliche Veröffentlichung von Fedora in letzter Zeit. War Fedora früher notorisch für über Wochen verschobene Releases bekannt, so hat der neue Release-Zyklus mit einem Veröffentlichungstermin und einem Ausweichtermin eine Woche später dazu geführt, dass die Veröffentlichungen zuverlässig diese Termine einhalten. Fedora Workstation 32 steht auf Get Fedora für x86_64 und ARM zum Download bereit.
Schaut man sich auf Linux-Konferenzen um, so ziert die Mehrzahl der dort versammelten Notebooks ein ThinkPad-Logo. Diesem Umstand trägt Lenovo, weltweit größter Notebook-Hersteller, demnächst im Rahmen seiner Linux Community Series Rechnung, indem die GNU/Linux-Distribution Fedora Workstation auf einigen Modellen vorinstalliert angeboten wird. Das gab Fedora-Projektleiter Matthew Miller jetzt im Fedora Magazine bekannt.
Lenovo und Fedora
Die Zusammenarbeit betrifft zunächst die Modelle ThinkPad P1 Gen2, ThinkPad P53 und ThinkPad X1 Gen8 und wird vielleicht später um weitere Modelle ergänzt. Fedora Workstation kann bei der Konfiguration der Geräte als Betriebssystem ausgewählt werden. Dabei gelangt die am 28. April zur Veröffentlichung anstehende Fedora Workstation 32 auf die ThinkPads.
Nur freie Software
Entwickler von Lenovo und Red Hat haben zusammen daran gearbeitet, auf den ThinkPads ausschließlich freie Software auszuliefern. Sollten die Geräte über Grafikkarten von Nvidia verfügen, so kann der proprietäre Treiber aber nachträglich installiert werden.
Weitere Verbreitung
Miller sieht die weltweit angebotenen ThinkPads mit Fedora als große Chance für das Projekt. Der Fedora-Installer versuche zwar, die Installation so einfach wie möglich zu gestalten, das sei aber für technisch nicht so versierte Anwender oft immer noch ein Hindernis. Ein Laptop dieser großen Marke mit vorinstalliertem Fedora werde dazu beitragen, Fedora einem breiteren Publikum zugänglich zu machen.
Hochpreisige Einstiegsmodelle
Weitere Einzelheiten will Miller vor dem Start, dessen Datum der Artikel noch nicht verrät, bekannt geben. Die beim Start der Aktion angebotenen ThinkPads liegen alle im höherpreisigen Bereich zwischen 1.650 und 1.850 Euro in der Grundausstattung. Weitere Einzelheiten könnte es auf dem in diesem Jahr virtuell abgehaltenen Red Hat Summit geben.
Es ist wieder die Zeit im Jahr, wo kurz nacheinander Ubuntu und Fedora ihre neuen Veröffentlichungen freigeben. Bei Ubuntu steht der 23. April als Termin fest, während Fedora den Nachfolger von Fedora 31 gerade um eine Woche auf den Ausweichtermin 28. April verschoben hat.
Release-Blocker
Grund für die Verschiebung sind verbleibende Fehler, die noch nicht ausgeräumt werden konnten. Ob der neue Termin zu halten ist, wird die Sitzung des Fedora-Steuerungskomitees am 23. April zeigen.
Zu den blockierenden Fehlern zählen etwa Probleme mit der Nvidia-Turing-Architektur im Zusammenhang mit Secure Boot bei einigen Lenovo Thinkpads sowie das Nichterkennen von LVM-Partitionen im Rescue Mode. Zudem startet der Plasma Desktop nicht, wenn der User gewechselt wird.
Bessere Planung
Fedora hatte in der Vergangenheit häufig Probleme, Veröffentlichungstermine einzuhalten. Man legte sich im Vorfeld auf einen Termin fest, der dann oft um Wochen verschoben wurde. Unter dem derzeitigen Projektleiter Matthew Miller hat sich die Situation deutlich verbessert. Neben dem geplanten Termin für Beta und stabile Veröffentlichung gibt es je einen Ausweichtermin eine Woche später, der mittlerweile meist eingehalten wird.
EarlyOOM und TRIM
Fedora 32 bietet neben Kernel 5.6 und GNOME 3.36.1 mit EarlyOOM ein Tool, das verhindern soll, dass ein vollgelaufener Speicher das System einfriert, indem speicherhungrige Prozesse vorher geregelt beendet oder aber auch abgeschossen werden. Zudem wird das Freigeben von nicht mehr belegtem Speicherplatz auf SSDs per TRIM endlich zum Standard und einmal wöchentlich per Systemd-Timer ausgeführt.
Wie immer bietet auch Fedora 32 neben vielen aktuellen GNOME-Apps und sonstigen Anwendungen auch eine aktuelle Toolchain mit GCC und LLVM 10, die GNU-C-Bibliothek Glibc 2.31, Binutils 2.33, Ruby 2.7, Golang 1.14 und Python 3.8. Mono wird von Version 5.20 auf 6.6 aktualisiert.
Fedora ist die Hexenküche von Red Hat, in der viele neue Entwicklungen angestoßen werden. Damit ist das zweimal jährlich veröffentlichte Fedora die vermutlich innovativste Linux-Distribution auf dem Markt. Jetzt war es wieder so weit, Fedora 31 hat das Licht der Welt erblickt. Diese Veröffentlichung erfolgt nur wenige Tage vor dem fünfzehnten Jahrestag der Veröffentlichung von Fedora Core 1, der ersten Veröffentlichung von Fedora.
Bereits im Juli hatte der bei Red Hat angestellte Fedora-Entwickler Christian Schaller einen ausführlichen Ausblick auf die zu erwartenden Neuerungen von Fedora 31 gegeben. Was davon die nötige Reife zur Veröffentlichung erreicht hat, verrät das Changeset. Zwei grundlegende Änderungen betreffen Anwender von 32-Bit-Maschinen und Python-Anwender.
Gnome 3.34
GNOME 3.34 stellt den Desktop von Fedora 31, der durch Sammelordner mehr Übersicht in der Shell erlaubt. Auch optisch wurde die GNOME-Shell an einigen Stellen aufgewertet und reagiert schneller auf Eingaben und bei Animationen. Der Standard-GNOME-Browser Web, früher als Epiphany bekannt, lässt Webseiten nun in getrennten Sandbox-Prozessen laufen, was Sicherheit und Leistung zugutekommt.
Wayland
Wayland ist und bleibt Thema und darf natürlich in der Liste der Verbesserungen nicht fehlen, ist doch der Gleichstand mit X11 bei der Funktionalität noch nicht ganz erreicht. Eine der Neuerungen bei GNOME 3.34 ist, dass die Position des Mauszeigers nun auch unter Wayland durch Drücken von STRG hervorgehoben wird, sofern die Funktion vorher aktiviert wurde.
Firefox als Wayland-App
Eine weitere wichtige Verbesserung im Hintergrund betrifft den GNOME-Fenstermanager und Wayland-Compositor Mutter. Dieser erlaubt es fortan, X-Wayland nur noch bei Bedarf zu starten, um eine X11-Applikation zu unterstützen. Zudem ist Firefox als GNOME-Wayland-Version verfügbar. In allen anderen Sitzungen wird Firefox-X11 verwendet. QT-Apps laufen mithilfe des Qt Wayland-Platform-Plugins und Qt 5.12 jetzt nativ in GNOME-Sitzungen mit Wayland.
32-Bit auf dem Rückzug
Fedora 31 stellt mit Linux 5.13 keine i686-Kernel mehr bereit und liefert keine 32-Bit Installationsmedien mehr aus. Zudem fallen Teile der 32-Bit Repositorien weg. Lediglich die Kernel-Header sollen weiterhin bereitgestellt werden, um die notwendigen Abhängigkeiten für 32-Bit-Programme zu bedienen, die diese Header benötigen.
Das bedeutet nicht nur, dass Fedora 31 keine Installationen auf 32-Bit mehr unterstützt, sondern der Wegfall der Repositorien »Everything« und »Modular« trifft auch Bestandsanwender, denen lediglich die Multilib-x86_64 Repositorien bleiben.
Python 2 bald ohne Unterstützung
Python 2 und seine Pakete sollen mit Fedora 32 komplett aus der Distribution entfernt werden, denn am 1. Januar 2020 wird die Unterstützung für Python 2 offiziell endgültig eingestellt. Derzeit verbleiben noch 828 dieser Pakete in der Distribution. Bereits mit Fedora 31 bedeutet die Schreibweise Python ohne Zusatz jedoch, dass es sich um ein Python 3 Paket oder einen entsprechenden Befehl handelt.
Kein SSH per Root mehr
Fedora 31 schaltet die Kernelfunktion CgroupsV2 frei. Die standardmäßige Aktivierung der CgroupsV2 ermöglicht es Anwendungen wie Systemd, Container-Tools und Libvirt, die Vorteile der neuen Features und vieler Korrekturen seit CgroupsV1 zu nutzen. Die Nutzung des Root-Passworts zum Erstellen von SSH-Verbindungen wurde aus Sicherheitsgründen standardmäßig deaktiviert, wie das bei OpenSSH bereits seit Jahren der Fall ist.
Das Paketformat RPM wechselt bei der Kompression von Xz zu Zstandard (Zstd), womit Pakete wesentlich schneller ausgepackt werden können. Das Paket RPM selbst wird auf Version 4.15 aktualisiert. Standard bei Node.js ist jetzt Version 12 mit 30 Monaten Langzeitunterstützung, Version 10.x verbleibt als Modul im Repository. PipeWire erhielt einige Verbesserungen und ist als technische Vorschau integriert.
Verschiedene Varianten
Fedora 31 steht in verschiedenen Varianten zum Download bereit. Neben Fedora Workstation und der Server-Edition stehen Fedora Silverblue, Fedora CoreOS und Fedora IoT bereit. Als alternative Architekturen werden ARM AArch64, Power und S390x bedient. Darüber hinaus bietet Fedora Spins mit verschiedenen Desktops sowie Labs mit Themenschwerpunkten wie Astronomie, Games oder Sicherheit.
Dieser Frage geht der bei Google tätige Entwickler Michael Stapelberg derzeit in seinemBlog und in einem Vortrag nach. Im März hatte Stapelberg seinen Rückzug aus Debian bekannt gegeben, wo er über zehn Jahre tätig war. Grund für seine Kritik an Debian waren dessen Strukturen, die ihm ein effizientes Arbeiten unmöglich machten.
Testobjekt Paketmanager
In der Zwischenzeit hat sich Stapelberg der Paketmanager angenommen und die bekanntesten Exemplare unter Linux systematisch untersucht. Im Grunde gibt es nur zwei Formate, von denen fast alle anderen mehr oder weniger abgeleitet sind. Dabei handelt es sich um das Debian-Paket deb und den Red Hat Package Manager rpm, die beide im Grunde Archivformate sind.
Sie machen zu viel
Was passiert nun, wenn wir eine Paketinstallation anstoßen? Traditionell werden zunächst die Paketlisten gelesen und die Abhängigkeiten überprüft. Darauf folgt der Download, das Entpacken der Archive und das Konfigurieren auf der Basis der im Paket hinterlegten Anweisungen. Schließlich wird das Paket in /usr/bin installiert.
Hoffen und Bangen
Der Moment der eigentlichen Installation nach dem Download der Pakete ist bei den hier betrachteten Paketmanagern heikel. Wenn währenddessen der Akku leer ist oder der Kernel aussteigt oder die Software fehlerhaft, haben wir meist ein Problem. Um das möglichst abzufedern, bedienen sich die Paketmanager des Linux-System-Calls fsync, um den gepufferten Dateiinhalt nicht nur im RAM zu haben, sondern auch auf den Datenträger zu schreiben. Das ist aber nur ein Grund warum eine Paketinstallation teilweise so lange dauert.
Stapelberg hat getestet, wie lange eine Auswahl von Paketmanagern braucht, um ein kleines und ein größeres Paket zu installieren:
Dabei hat das Paket ack eine Größe von 70 Kb, während qemu im Download 70 MB in die Waagschale wirft. Fedora macht bei beiden Paketen die schlechteste Figur. Die herunterzuladenden Metadaten stehen in keinem Verhältnis zur Größe des Pakets und das umso mehr, je kleiner das Paket ist.
Maintainer-Scripte
Ein weiterer Grund, warum Paketmanager lange für eine Paketinstallation brauchen sind die Maintainer-Scripte, die während der Installation über Hooks und Trigger abgearbeitet werden. Dabei werden Anweisungen aus den mit im Paket befindlichen Dateien preinst und postinst ausgeführt, die nach Stapelbergs Ansicht meist auch beim ersten Programmstart aufgerufen werden könnten. Zudem verhindert dieses Abarbeiten der Scripte, dass Pakete parallel installiert werden können.
Aus diesen Beobachtungen zog er den Schluss, dass entweder das Potenzial besteht, den Paketmanager selbst zu optimieren oder was das System macht, ist einfach zu komplex. Das veranlasste ihn dazu, eine experimentelle Distribution namens distri zu erstellen, die einige Dinge anders angeht und über einen wieselflinken Paketmanager verfügt.
Nicht ganz neu
Dabei hat Stapelberg das Rad nicht völlig neu erfunden, sondern verwendet Ideen aus der Distribution NixOS und deren Paketmanager Nix. Betrachtet man obige Grafik, so schafft es Nix einerseits, die benötigten Daten klein zu halten, erreicht aber andererseits nur lausige Übertragungsraten, sodass von der möglichen Geschwindigkeit nichts übrig bleibt. Stapelberg vermutet hier Implementationsfehler. Alpine und Arch Linux sind deutlich schneller als der Rest. Sie machen weniger als der Rest und das effizienter.
Images anstatt Archive
Stapelberg verwendet anstelle von Archiven, die entpackt werden müssen, Images, die schnell gemounted werden können, ähnlich wie bei AppImage oder Snap. Als Format kommen nur lesbare Squash-Images zum Zug, gemounted wird per FUSE. Ein weiterer Vorteil dieser Herangehensweise ist, dass die Pakete nicht verändert werden können. Ähnlich wie bei NixOS werden alle Bestandteile eines Pakets in ein einziges Verzeichnis installiert.
Wer näheres dazu lesen möchte, findet Details im Blog. Die Distribution soll ihren experimentellen Charakter behalten, kann aber von GitHub in verschiedenen Formaten heruntergeladen und getestet werden.
