Fedora Linux Deep Dive 2026: Was unter der Oberfläche wirklich passiert

Fedora Linux wird meistens über sein Image erklärt: „das schnelle”, „das für Entwickler”, „das mit den neuen Sachen”. Das ist nicht falsch, aber es ist auch keine Aussage — es ist ein Gefühl. Was fast nirgends steht: wie weit vorne genau, gemessen woran, und was der Preis dafür ist.

Also haben wir nachgesehen, statt zu beschreiben. Dieser Artikel ist kein Distributionsvergleich — den haben wir mit Fedora vs Ubuntu und Debian vs Ubuntu bereits geschrieben. Hier geht es um die Mechanik: was Fedora technisch tut, warum es das tut, und wo es weh tut.

Alle Zahlen in diesem Text sind am 15. August 2026 selbst erhoben. Konkret haben wir die Paket-Metadaten von Fedora 44 (Release-Repo, Updates-Repo und Rawhide) heruntergeladen und lokal ausgewertet — zusammen etwa 480 MB SQLite —, dazu die Paketlisten von Debian 13 und Ubuntu 26.04 LTS zum Gegenlesen. Wo wir uns beim Messen selbst korrigieren mussten, steht das im Text. Das gehört zur Methode.

Fedora Linux in Zahlen: Wie groß ist das eigentlich?

Bevor irgendeine Philosophie-Diskussion Sinn ergibt, die Größenordnung. Das Repository „Everything” von Fedora 44 für x86_64 enthält:

Methodik: primary.sqlite aus den Repodata von releases/44/Everything/x86_64/os/, abgerufen und ausgewertet am 15.08.2026. Größen als Summe über alle Pakete, also inklusive der Architektur-Varianten.

Die Verteilung sagt mehr als die Gesamtzahl. 17.233 Pakete beginnen mit rust- — jede Rust-Crate, die als Bauabhängigkeit gebraucht wird, ist ein eigenes RPM. Dazu 4.744 texlive-, 4.075 perl-, 4.073 python3-, 1.203 golang-. Und 28.211 Pakete enden auf -devel.

Das ist der erste Befund, der Fedoras Charakter erklärt: Der Katalog ist auf Bauen ausgelegt, nicht auf Benutzen. Mehr als ein Drittel aller Pakete sind Entwicklungsdateien, ein weiteres knappes Viertel sind Sprachökosystem-Bibliotheken, die kaum ein Endanwender je direkt installiert. Wer Fedora als „Desktop-Distribution” beschreibt, beschreibt die Oberfläche eines Systems, das intern vor allem eine sehr große, sehr aktuelle Baumaschine ist.

Zum Vergleich, aus denselben Rohdaten der jeweiligen Projekte am selben Tag geholt:

Methodik: Fedora aus primary.sqlite (Basis + Updates, eindeutige Paketnamen); Debian aus dists/trixie/main/binary-amd64/Packages.xz; Ubuntu aus dists/resolute/{main,universe}/binary-amd64/Packages.xz. Alle am 15.08.2026 abgerufen.

Die drei sind praktisch gleich groß. Das übliche „Ubuntu hat mehr Software” ist bei den offiziellen Repositories nicht messbar. Der Unterschied liegt woanders — und der ist die eigentliche Geschichte.

Upstream-Nähe: Der Kern des Fedora-Modells, gemessen

„Fedora ist näher am Upstream” ist der Standardsatz. Er lässt sich präzise messen. Wir haben für 17 Kernkomponenten die tatsächlich ausgelieferte Version in allen drei Distributionen verglichen:

Methodik: Fedora aus Release- plus Updates-Repo (also der Stand, den ein aktuelles System heute hat); Debian und Ubuntu aus den offiziellen Packages-Indizes, Upstream-Version ohne Epoch und ohne Distributions-Revision. Alle Werte am 15.08.2026 abgerufen. Ubuntu-Werte aus main und universe.

Fedora liegt in 13 von 14 Vergleichen vorn oder gleichauf. Interessanter als das Ergebnis ist aber die Größe des Abstands, und die ist sehr ungleich verteilt: Bei glibc und Python ist Fedora gerade mal ein Patch-Level vor Ubuntu. Bei LLVM sind es drei Hauptversionen Abstand zu Debian. Bei Rust liegen zwölf Releases zwischen Debian und Fedora.

Das ist kein Zufall, sondern die Bruchlinie: Je schneller ein Upstream-Projekt released, desto weiter fällt eine Distribution mit langem Freeze zurück. Bei Software mit jährlichem Rhythmus ist der Unterschied kosmetisch. Bei Compilern und Toolchains mit sechswöchigem Rhythmus wird er zum Arbeitshindernis.

Der Kernel: die aussagekräftigste Zahl des ganzen Artikels

Fedora 44 wurde am 28. April 2026 veröffentlicht, mit Kernel 6.19.10. Der Kernel, den ein Fedora-44-System heute installiert, ist 7.1.8 — gebaut am 10. August 2026.

Und jetzt der Punkt: Wir haben bei kernel.org nachgesehen, was dort am selben Tag als aktuell gilt. Die Antwort aus releases.json:

latest_stable: 7.1.8 — veröffentlicht am 9. August 2026.

Fedora liefert in einer bereits veröffentlichten Version genau den Kernel aus, den kernel.org einen Tag zuvor als aktuellen Stable freigegeben hat. Nicht in der Entwicklungsversion. In dem stabilen Release, das seit dreieinhalb Monaten auf produktiven Rechnern läuft.

Das ist der Kern des Fedora-Modells und zugleich sein größtes Missverständnis: Fedora friert Versionen innerhalb eines Releases nicht ein. Eine Fedora-Version ist kein Zustand, sondern ein Zeitfenster. Was am Anfang drin war, ist am Ende oft nicht mehr drin.

Wir haben das für den gesamten Katalog gezählt: Von den 67.424 Paketen im Release-Repo haben 19.677 seit dem Release ein Update bekommen. Bei 1.063 davon war es ein Sprung der Hauptversionsnummer — nicht ein Bugfix, sondern eine neue Hauptversion mitten in einem laufenden Release. Zusätzlich sind 1.547 Pakete überhaupt erst nach dem Release dazugekommen.

Methodik: Paketnamen aus Release-Repo und Updates-Repo abgeglichen (Architekturen x86_64 und noarch), Hauptversion als führende Ziffernfolge der Versionszeichenkette. Pakete mit Datumsversionen (etwa 2026.06.16) wurden aus der Zählung der Hauptversionssprünge ausgeschlossen, weil ein Jahreswechsel dort kein inhaltlicher Sprung ist — das betraf 127 weitere Pakete.

Das ist der ehrliche Preis von „aktuell”: Ein Fedora-System, das man drei Monate nicht anfasst und dann aktualisiert, bekommt nicht Sicherheitsfixes, sondern teilweise neue Software. Wer stabile Zielumgebungen braucht, ist hier falsch — und zwar aus Konstruktionsgründen, nicht wegen mangelnder Qualität.

Rawhide: viel näher an „stable”, als der Ruf vermuten lässt

Rawhide ist Fedoras permanent rollender Entwicklungszweig. Der Ruf: „Da bricht ständig alles.” Wir haben nachgemessen, wie weit Rawhide zum Zeitpunkt der Messung tatsächlich von Fedora 44 entfernt ist.

Verglichen wurden alle Pakete, die es in beiden gibt (65.874 gemeinsame Namen):

Methodik: primary.sqlite von development/rawhide/Everything/x86_64/os/ gegen Fedora 44 Release+Updates, eindeutige Paketnamen, Architekturen x86_64 und noarch, abgerufen am 15.08.2026. Momentaufnahme — der Abstand ist kurz nach einem Release am kleinsten und kurz vor dem nächsten am größten.

Fast neun von zehn Paketen sind in Rawhide und im stabilen Fedora bitgleich. Der Unterschied konzentriert sich auf wenige, dafür fundamentale Komponenten:

Das erklärt das Rawhide-Risikoprofil besser als jede Anekdote: Das Risiko liegt nicht in der Breite, sondern in der Tiefe. Die 2,6 % voraus liegenden Pakete sind nicht zufällig verteilt — es sind systemd, glibc, der Desktop und die Sprach-Runtimes. Also genau die Teile, deren Ausfall nicht ein Programm kaputt macht, sondern das Booten.

Und ein Detail, das viele überrascht: In Rawhide stehen Release Candidates und Betas (3.15.0~rc1, 51~beta, 6.1.0~rc1). Das ist kein Versehen, sondern der Zweck. Rawhide ist die Integrationsfläche, auf der Fedora Upstream-Vorabversionen unter echten Bedingungen testet — und damit ein guter Teil dessen, was Upstream-Projekte an Fehlerberichten bekommen, bevor sie final werden.

RPM 6: Das größte Packaging-Update seit Jahren — mit einer Einschränkung

Fedora 44 liefert RPM 6.0.1 aus. Das ist bemerkenswert, weil RPM zwischen 4.0 (Jahr 2000) und 4.20 volle 25 Jahre lang bei der Hauptversion 4 blieb. RPM 6.0.0 erschien am 22. September 2025, 6.0.1 am 10. Dezember 2025.

Die inhaltlich wichtigen Änderungen laut den offiziellen Release Notes auf rpm.org:

• Signaturprüfung ist standardmäßig verpflichtend. Vorher war sie konfigurierbare Kür.
• MD5 und SHA1 sind als Paket-Digests entfernt. Neu: SHA3-256 als Header-Digest, SHA-512 und SHA3-256 als Payload-Digests.
• Unterstützung für OpenPGP v6 und Post-Quantum-Schlüssel. Das ist die konkreteste Vorbereitung auf PQC, die man in einer Paketverwaltung heute sehen kann.
• Mehrere Signaturen pro Paket. Ein Paket kann von Herstellung, Distribution und Nachsignierung getrennt beglaubigt werden.
• Installation von RPM-v3-Paketen entfernt. Abfragen und Entpacken geht weiter.
• Alle Dateigrößen und Grenzwerte sind jetzt 64 Bit.

Der Teil, den wir selbst nachgesehen haben — und der die Schlagzeile relativiert

„Fedora 44 nutzt RPM 6” ist die naheliegende Zusammenfassung. Sie ist ungenau, und der Unterschied ist wichtig: RPM 6 kann zwei Paketformate bauen, v6 und v4. Die Frage ist also nicht nur, welches Werkzeug installiert ist, sondern in welchem Format die Pakete tatsächlich vorliegen.

Das lässt sich direkt an der Datei prüfen. Jedes RPM beginnt mit einem 96-Byte-„Lead”; im fünften Byte steht das Formatfeld. Laut Formatdokumentation von rpm.org trägt es bei v4-Paketen die 3 und bei v6-Paketen die 4.

Wir haben von drei verschiedenen Repositories jeweils die ersten 96 Bytes eines Pakets geholt:

Methodik: HTTP-Range-Request auf die ersten 96 Bytes der jeweiligen .rpm-Datei, Magic ED AB EE DB bestätigt, Byte 4 ausgelesen. Formatzuordnung nach der offiziellen v6-Formatbeschreibung auf rpm-software-management.github.io. Abgerufen am 15.08.2026.

Fedora liefert RPM 6 als Werkzeug aus, baut seine Pakete aber weiterhin im v4-Format — auch in Rawhide, auch bei ganz frisch gebauten Paketen. Die neue Kryptografie und die Post-Quantum-Signaturen sind damit vorhanden und nutzbar, aber im ausgelieferten Katalog noch nicht in Betrieb.

Das ist der ehrlichere Satz, und er ist auch der vernünftigere: Ein Formatwechsel im Paketformat einer Distribution mit 76.000 Paketen ist keine Schalterumlegung, sondern eine Migration, die jedes Werkzeug im Ökosystem betrifft. Wer aus „Fedora hat RPM 6” schließt, dass er heute Post-Quantum-signierte Pakete installiert, liegt falsch.

🔑 Merksatz für jede Versions-Aussage: Die installierte Version eines Werkzeugs sagt, was möglich ist — nicht, was gemacht wird.

DNF5: Was der Umstieg tatsächlich geändert hat

Fedora 44 liefert DNF 5.4.1.0 aus. Der wichtigste Teil dieses Umstiegs ist nicht die Geschwindigkeit, über die alle reden, sondern eine Architekturentscheidung: DNF5 ist in C++ geschrieben, DNF4 war Python. Das hat drei praktische Folgen.

Erstens entfällt der Python-Interpreterstart bei jedem Aufruf. Das ist der Grund, warum sich dnf heute anders anfühlt — nicht ein schnellerer Solver, sondern ein nicht mehr vorhandener Startaufschlag.

Zweitens — und das ist die wichtigere Folge — kann die Paketverwaltung damit als Bibliothek in andere Programme eingebettet werden, ohne einen Python-Stack mitzuschleppen. Deshalb gibt es dnf5daemon als Ersatz für PackageKit: Die grafische Softwareverwaltung im Desktop spricht jetzt direkt mit derselben Bibliothek wie die Kommandozeile. Vorher waren das zwei Wege zum selben Ziel, die sich gelegentlich uneinig waren.

Drittens ist python3-dnf weiterhin installiert — in Version 4.24.0. Wer Automatisierung geschrieben hat, die die DNF4-Python-API benutzt, findet sie also noch vor. Das ist Übergangskomfort, keine Zusage.

Wir haben den Befehlsumfang direkt aus den Paket-Metadaten gezählt, statt die Dokumentation zu zitieren. DNF5 meldet jedes Unterkommando als eigene dnf5-command(...)-Bereitstellung:

Methodik: Tabelle provides aus primary.sqlite, gefiltert auf Einträge der Form dnf5-command(...). Abgerufen am 15.08.2026.

Der Mechanismus dahinter ist eleganter, als er aussieht: Weil jedes Unterkommando eine eigene RPM-Bereitstellung ist, kann DNF bei einem unbekannten Befehl selbst nachschlagen, welches Paket ihn liefern würde. Das ist derselbe Trick wie bei command-not-found, nur innerhalb der Paketverwaltung.

Und dnf5 stellt zusätzlich schlicht dnf bereit. Wer also dnf install tippt, ruft DNF5 auf. Das erklärt die häufigste Verwirrung in Foren: Ältere Anleitungen funktionieren zu 90 % weiter, und genau die verbleibenden 10 % — vor allem einige Optionen und Ausgabeformate — scheitern dann ohne erkennbaren Grund.

Die praktischen Stolpersteine

• dnf5 kennt einige DNF4-Optionen nicht mehr. Der Klassiker ist die Gruppenverwaltung, deren Syntax sich geändert hat.
• Plugins von DNF4 laufen nicht unter DNF5. Sie brauchen eine eigene Portierung — daher die separate Liste oben.
• Skripte, die die Ausgabe von dnf geparst haben, sind grundsätzlich verdächtig. Sie waren es aber schon immer; DNF5 hat nur das Fällige eingesammelt.

SELinux: der Unterschied, den man erst merkt, wenn er stört

Fedora hat SELinux seit Fedora Core 2 standardmäßig aktiv, im Modus enforcing, mit der Policy targeted. Das ist die Einstellung, die neue Nutzer am häufigsten als Erstes abschalten — und die am seltensten verstanden wird.

Der Unterschied zu AppArmor, das Ubuntu und openSUSE verwenden, ist nicht „strenger gegen lockerer”. Es sind zwei verschiedene Modelle:

AppArmor arbeitet pfadbasiert. Eine Regel sagt: Dieses Programm darf auf diesen Dateipfad zugreifen. Das ist lesbar und leicht zu schreiben. Der Nachteil steckt im Modell: Ein Pfad ist ein Name, kein Objekt. Hardlinks, Bind-Mounts und Umbenennungen können die Beziehung zwischen Regel und tatsächlicher Datei lösen.

SELinux arbeitet labelbasiert. Jede Datei, jeder Prozess, jeder Port und jeder Socket trägt ein Label im erweiterten Dateiattribut. Regeln beschreiben, welcher Typ auf welchen Typ zugreifen darf. Das Label klebt am Objekt, nicht am Namen — deshalb verliert es sich beim Verschieben nicht, deshalb ist es aber auch so schmerzhaft, wenn ein Label falsch ist.

Genau daher kommt die häufigste Fedora-Frustration überhaupt: Man kopiert eine Datei mit mv aus dem Home-Verzeichnis nach /var/www, sie behält ihr Home-Label, und der Webserver darf sie nicht lesen. Die Datei ist da, die Rechte stimmen, ls -l sieht perfekt aus — und es geht trotzdem nicht. Das ist kein Fehler, das ist das Modell. restorecon setzt das Label auf den für den Pfad vorgesehenen Wert zurück.

Die Zahl, die zeigt, wie ernst das Ökosystem das nimmt

Eine Sicherheitstechnik ist nur so viel wert wie ihre Abdeckung. Wir haben gezählt, wie viele Pakete in Fedora 44 eine eigene SELinux-Policy mitbringen:

• 73 Pakete enden auf -selinux und liefern damit ihr eigenes Regelwerk mit — darunter container-selinux, flatpak-selinux, cockpit-selinux, fail2ban-selinux, ceph-selinux, grafana-selinux, freeipa-selinux.
• Die zentrale selinux-policy liegt in Version 43.3 und ist in sieben Varianten aufgeteilt: targeted (Standard, ca. 18 MB installiert), minimum, mls, dazu devel, doc, sandbox und das Basispaket.

Methodik: Paketnamen und installierte Größen aus primary.sqlite von Fedora 44, abgerufen am 15.08.2026.

Das ist der eigentliche Punkt: SELinux ist bei Fedora keine Systemeinstellung, sondern eine Paketierungskonvention. Wer eine Server-Anwendung nach Fedora bringt, liefert die Policy mit. Deshalb funktionieren dort so viele Dienste out of the box im enforcing-Modus — und deshalb ist das Abschalten von SELinux teurer, als es sich anfühlt: Man wirft 73 mitgelieferte Regelwerke gleichzeitig weg.

Und die Variante mls ist der Grund, warum diese Technik überhaupt so aussieht, wie sie aussieht: Multi-Level Security stammt aus Anforderungen von Behörden mit Geheimhaltungsstufen. SELinux wurde ursprünglich von der NSA entwickelt und 2000 unter der GPL veröffentlicht; RHEL — und damit Fedora als dessen Vorfeld — hat es zur Standardausstattung gemacht.

Btrfs als Standard: Was das praktisch bedeutet

Seit Fedora 33 ist Btrfs das Standarddateisystem für die Desktop-Varianten. Der Grund steht wörtlich im offiziellen Change-Antrag im Fedora-Wiki: Man wollte Dateisystem-Funktionen „in transparenter Weise” bereitstellen — also Fähigkeiten liefern, ohne dass Nutzer sie konfigurieren müssen.

Was Fedora bei einer Standardinstallation tatsächlich anlegt:

• Eine Btrfs-Partition mit den Subvolumes root und home — keine getrennten Partitionen. Der Platz ist damit gemeinsam, nicht vorab aufgeteilt. Das beendet das klassische Problem, dass /home voll ist, während in / 200 GB brachliegen.
• Transparente Kompression mit zstd:1. Das ist auf modernen CPUs praktisch kostenlos und spart bei Quellcode, Logs und Textdaten erheblich Platz.
• Prüfsummen für Daten und Metadaten. Btrfs erkennt stillen Datenverfall, statt ihn weiterzureichen.

Und jetzt der Teil, der in den meisten Fedora-Empfehlungen fehlt:

Fedora richtet standardmäßig keine automatischen Snapshots ein. Copy-on-Write und Subvolumes sind die technische Voraussetzung für Snapshots, aber die Automatik ist nicht dabei. Wer den openSUSE-artigen Komfort will — Snapshot vor jeder Paketoperation, Rollback aus dem Bootmenü —, muss snapper, den passenden DNF-Plugin und grub-btrfs selbst installieren und einrichten.

Das ist eine bewusste Entscheidung, keine Lücke: Automatische Snapshots brauchen ein Aufräumkonzept, sonst läuft die Platte irgendwann voll — und ein Rollback-Mechanismus, den niemand getestet hat, ist gefährlicher als keiner. Aber man sollte es wissen, bevor man sich auf ein Sicherheitsnetz verlässt, das gar nicht gespannt ist.

Btrfs-Werkzeuge in Fedora 44: btrfs-progs 6.19.1 im Release, inzwischen 7.0 über die Updates. Auch hier wieder ein Hauptversionssprung innerhalb eines laufenden Releases.

Wo Btrfs nicht die richtige Wahl ist

Ehrlich bleiben: Btrfs ist nicht überall überlegen.

• Datenbanken und VM-Images leiden unter Copy-on-Write (Fragmentierung, Schreibverstärkung). Für diese Verzeichnisse ist chattr +C oder ein separates XFS-Volume die bessere Wahl. Fedora Server nutzt deshalb weiterhin XFS als Standard, nicht Btrfs.
• RAID 5/6 gilt in Btrfs weiterhin als nicht produktionsreif. Für Redundanz auf Blockebene bleibt es bei mdraid oder RAID 1/10 in Btrfs.
• Bei sehr vollen Dateisystemen ist das Platzverhalten schwerer vorherzusagen als bei ext4 — df kann bei Btrfs irreführend sein, weil Metadaten und Daten getrennte Reserven haben.

Die Atomic Desktops: Fedoras interessantestes Experiment

Fedora 44 wird in vier Atomic-Desktop-Varianten ausgeliefert. Wir haben die ISO-Verzeichnisse des offiziellen Spiegels geprüft, statt uns auf Übersichtsartikel zu verlassen:

Methodik: Verzeichnislisting von dl.fedoraproject.org/pub/fedora/linux/releases/44/, abgerufen am 15.08.2026.

Das ostree im Dateinamen ist der ganze Unterschied. Ein klassisches Fedora installiert einzelne RPMs in ein beschreibbares Wurzeldateisystem — der Zustand entsteht aus der Summe aller je durchgeführten Transaktionen. Ein Atomic Desktop bekommt stattdessen einen fertigen, unveränderlichen Systembaum, wie ein Container-Image. Es wird nichts einzeln installiert; es wird ein neuer Baum bereitgestellt und beim nächsten Start hineingebootet.

Die praktischen Konsequenzen:

• Das Wurzeldateisystem ist schreibgeschützt. /usr ist nicht beschreibbar, /etc und /var sind es.
• Updates sind atomar. Entweder der neue Baum ist vollständig da, oder es bleibt beim alten. Ein Stromausfall mitten im Update hinterlässt kein halbaktualisiertes System.
• Rollback ist ein Bootmenü-Eintrag. Der vorherige Baum bleibt erhalten. rpm-ostree rollback und ein Neustart genügen.
• Zwei identische Rechner sind wirklich identisch. Bei paketbasierten Systemen ist der Zustand pfadabhängig — was mal installiert und wieder entfernt wurde, hinterlässt Spuren.

Fedora 44 liefert rpm-ostree 2026.1 und bootc 1.12.1 aus. Letzteres ist die interessantere Zahl: Mit bootc verschiebt sich das Modell von „ostree-Bäume” zu „das Betriebssystem ist ein OCI-Container-Image, das man bootet”. Der Werkzeugkasten, mit dem man Container baut, wird damit derselbe, mit dem man Betriebssysteme baut. Zum Zeitpunkt unserer Messung war bootc bei v1.16.8 vom 13. August 2026 — auch hier bewegt sich Upstream schneller als das Release.

Der Preis, den kein Atomic-Werbetext erwähnt

Der Tausch ist real: Man gibt die Fähigkeit auf, einfach mal schnell etwas zu installieren.

Software auf einem Atomic Desktop kommt über drei Wege — und der bequemste ist der, den man am wenigsten benutzen soll:

1. Flatpak für grafische Anwendungen. Der vorgesehene Weg. Fedora liefert flatpak 1.17.6 aus und betreibt eine eigene Flatpak-Registry.
2. Container für alles Entwicklerische, per toolbox (0.3) oder distrobox (1.8.2.4). Man arbeitet in einem Container, der wie ein normales Fedora aussieht, aber das Basissystem nicht anfasst.
3. rpm-ostree install als Ausweg. Das „schichtet” ein RPM in den Systembaum. Es funktioniert — aber jedes geschichtete Paket muss bei jedem Update neu über den Baum gelegt werden. Wer hier zwanzig Pakete anhäuft, hat sich die Nachteile beider Welten eingehandelt.

Unsere ehrliche Einschätzung: Atomic Desktops sind hervorragend für Rechner mit klarem Zweck — Arbeitsgeräte, Kioske, Entwicklerlaptops mit containerisierten Umgebungen, Flotten. Sie sind mühsam für Rechner mit unvorhersehbaren Anforderungen, für Spezialtreiber und für alles, was Kernel-Module braucht. Wer regelmäßig Hardware anschließt, für die es proprietäre Treiber gibt, wird mit dem klassischen Workstation-Modell glücklicher.

Fedora als Entwicklermaschine: warum genau, nicht nur dass

„Fedora ist gut für Entwickler” ist wahr und nichtssagend. Aus den erhobenen Zahlen lassen sich drei konkrete Gründe benennen.

Erstens: Die Toolchain ist die aktuelle, nicht die vom letzten Jahr. GCC 16.1.1, LLVM 22.1.8, Rust 1.97.1, Go 1.26.5, Python 3.14.6. Das ist relevant, sobald man gegen Sprachstandards baut, die sich bewegen: Fedora 44 unterstützt laut Projektangaben C++26 und C23. Wer auf Debian 13 gegen LLVM 19 baut, entwickelt gegen einen Compiler, der drei Hauptversionen alt ist.

Zweitens: Das Repository ist auf Bauen ausgelegt. Die 28.211 -devel-Pakete sind kein Ballast, sondern der Punkt. Fast jede Bibliothek im Katalog hat ihre Header verfügbar. In der Praxis heißt das: dnf builddep auf ein Quellpaket, und die Bauumgebung steht — ohne Suche nach dem Paket, das ausgerechnet diese eine Header-Datei enthält.

Drittens: Container sind erstklassige Bürger, nicht nachgerüstet. Podman 5.8.4 ist Teil des Basissystems, ebenso toolbox und distrobox. Das ist kein Zufall: Podman kommt aus demselben Haus wie Fedora, und der rootless-Betrieb — Container ohne Root-Rechte — hat hier den längsten Praxisvorlauf. Dazu kommt container-selinux, das die Absicherung mitliefert, statt sie dem Anwender zu überlassen.

Der Preis dafür steht weiter oben: 19.677 aktualisierte Pakete in dreieinhalb Monaten, 1.063 davon mit Hauptversionssprung. Eine Entwicklungsmaschine, die aktuell ist, ist per Definition eine, die sich bewegt. Wer eine Zielumgebung braucht, die exakt so bleibt, wie sie am ersten Tag war, baut die in einen Container — nicht ins Hostsystem.

Wayland: der Übergang ist praktisch abgeschlossen

Fedora war die erste große Distribution mit Wayland als Standard (Fedora 25, 2016). Zehn Jahre später ist die interessante Frage nicht mehr, ob Wayland funktioniert, sondern was von X11 übrig ist.

Fedora 44 liefert GNOME Shell 50.0 im Release und 50.4 über die Updates, Mutter in derselben Version. Der GNOME-X11-Sitzungspfad wurde von GNOME upstream entfernt; wer heute unter Fedora GNOME startet, startet Wayland — ohne Wahlmöglichkeit im Anmeldebildschirm.

Was praktisch bleibt:

• XWayland übersetzt weiterhin für X11-Anwendungen. Das betrifft alte proprietäre Software und einige Spiele. Für die meisten Nutzer unsichtbar.
• Bildschirmaufnahme und Fernzugriff laufen über PipeWire und das Portal-System statt über direkten X11-Zugriff. Das ist der Bereich, in dem Fedora-Nutzer historisch die meisten Reibungspunkte hatten — und der Grund, warum GNOME 50 laut Release-Ankündigung ausdrücklich Verbesserungen beim Fernzugriff bringt.
• Anwendungen, die globale Tastenkürzel oder das Fenster anderer Programme brauchen, funktionieren unter Wayland grundsätzlich anders. Das ist kein Fehler, sondern das Sicherheitsmodell: Unter X11 konnte jedes Programm jedes andere belauschen.

Wer KDE bevorzugt: Fedora 44 liefert Plasma 6.6 aus, mit dem Plasma Login Manager anstelle von SDDM.

Die Nvidia-Realität: der ehrlichste Abschnitt dieses Artikels

Das ist der Punkt, an dem Fedora Neulinge am häufigsten verliert — und wir haben hier eigene Erfahrung, weil ein HP Omen mit einer RTX 4070 Laptop-GPU (Ada Lovelace) bei uns auf Fedora Workstation migriert wurde.

Die Ausgangslage: Fedora liefert keine proprietären Nvidia-Treiber aus. Das ist keine technische, sondern eine Lizenzentscheidung — die Fedora-Richtlinien erlauben keine unfreie Software in den offiziellen Repositories. Man braucht RPM Fusion, ein von der Community betriebenes Zusatz-Repository.

Wir haben nachgezählt, was dort für Fedora 44 tatsächlich liegt:

Und die Treiberversionen im nonfree-Zweig:

Methodik: primary.sqlite der RPM-Fusion-Updates-Repositories für Fedora 44, abgerufen am 15.08.2026.

Ein Detail, das wir fast falsch aufgeschrieben hätten

Unser erster Gegencheck war die Datei latest.txt auf Nvidias eigenem Downloadserver. Dort stand 580.126.09. Daraus wäre die naheliegende Schlagzeile geworden: „RPM Fusion liegt mit 610.57.04 sogar vor Nvidias offiziellem Treiber.”

Das wäre falsch gewesen. Ein Blick in das Verzeichnislisting desselben Servers zeigt Ordner für 610.43.02, 610.43.03 und 610.57.04. latest.txt zeigt also nicht auf den neuesten Treiber überhaupt, sondern auf den jeweils aktuellen Stand eines bestimmten Zweigs.

🔑 Merksatz: Eine Datei namens latest ist eine Aussage darüber, was jemand als „latest” pflegen wollte — nicht darüber, was das Neueste ist. Die richtige Zusammenfassung lautet: RPM Fusion liefert 610.57.04, und das ist auch die höchste Version, die auf Nvidias Server liegt.

Warum es trotzdem regelmäßig knallt

Der Mechanismus heißt akmod. Ein akmod-Paket enthält keinen fertigen Treiber, sondern Quellcode plus die Automatik, ihn beim nächsten Kernel neu zu bauen. Das ist die Lösung für Fedoras schnelle Kernel — bei 6.19 zu 7.1 in einem Release wäre ein vorgebautes Modul nach wenigen Wochen wertlos.

Der Preis: Nach einem Kernel-Update muss das Modul gebaut werden, bevor der neue Kernel startet. Passiert das nicht rechtzeitig — weil man zu schnell neu startet, weil der Bau fehlschlägt, weil der neue Kernel eine API geändert hat, die Nvidia noch nicht übernommen hat — bootet man in einen Rechner ohne funktionierenden Grafiktreiber.

Praktische Regeln, die den Ärger fast vollständig beseitigen:

• Nach einem Kernel-Update nicht sofort neu starten. Prüfen, ob das Modul für den neuen Kernel existiert.
• Secure Boot braucht einen eigenen Signaturschlüssel für das selbstgebaute Modul. Ohne diesen Schritt lädt der Kernel das Modul nicht — und die Fehlermeldung nennt selten den wahren Grund.
• Den vorherigen Kernel behalten. Fedora hält standardmäßig drei — das Bootmenü ist das Sicherheitsnetz.
• Bei Laptops mit Hybridgrafik ist der Standardfall, dass die dedizierte GPU nur bei Bedarf anspringt. Wer sie dauerhaft erzwingt, verliert Akkulaufzeit ohne Gegenwert.

Für AMD-Grafik gilt nichts davon. Der Treiber steckt im Kernel, Mesa liefert den Rest — Fedora 44 hat inzwischen Mesa 26.1.6. Das ist der Grund, warum die Fedora-Erfahrung mit AMD-Hardware so viel reibungsloser ist als mit Nvidia, und einer der wenigen Fälle, in denen die Hardwareauswahl die Distributionswahl wichtiger macht als umgekehrt.

Ein Befund am Rande: Fedora paketiert Browser noch selbst

Beim Gegenlesen der Ubuntu-Paketliste ist uns etwas aufgefallen, das nichts mit Fedora zu tun hat und trotzdem viel über Fedora sagt.

In Ubuntu 26.04 LTS sind firefox, thunderbird und chromium-browser keine Programme mehr. Es sind Übergangspakete, die einen Snap installieren:

Methodik: Feld Installed-Size und Description aus den Ubuntu-Packages-Indizes für resolute, abgerufen am 15.08.2026.

In Fedora 44 sind dieselben Programme normale RPMs: Firefox 153.0.3, Chromium 151.0.7922.137 (beide über die Updates; im Release waren es 150.0 und 146.0).

Das ist keine moralische Frage, sondern eine über Kontrolle: Ein Snap wird vom Hersteller-Store aktualisiert, unabhängig vom Systemupdate, und lässt sich nicht ohne Weiteres versionsfest halten. Ein RPM kommt aus demselben Repository, derselben Signaturkette und demselben Update-Vorgang wie der Rest des Systems. Für Arbeitsplätze mit Änderungsprozessen ist das ein handfester Unterschied — und einer der praktischsten Gründe, warum Fedora in Unternehmensumgebungen mit strengen Vorgaben leichter zu rechtfertigen ist als Ubuntu.

Für wen Fedora die richtige Wahl ist — und für wen nicht

Nach allem Gemessenen lässt sich das ziemlich scharf trennen.

Fedora passt, wenn:

• Du entwickelst und eine aktuelle Toolchain brauchst — besonders bei C++, Rust, Go, Python oder allem, was gegen bewegliche Standards baut.
• Du Container als selbstverständlichen Teil der Arbeit betrachtest. Podman, rootless und container-selinux sind hier fertig, nicht nachgerüstet.
• Du AMD-Grafik hast. Dann bekommst du aktuelle Mesa-Versionen ohne Fremdrepositories, und das ist der ganze Aufwand.
• Du regelmäßig aktualisierst. Fedora belohnt kontinuierliche Pflege und bestraft Vernachlässigung — nach sechs Monaten Pause ist das Update groß.
• Du das Sicherheitsmodell ernst meinst und SELinux nicht abschalten willst, sondern verstehen.

Fedora passt nicht, wenn:

• Du eine stabile Zielumgebung brauchst, die sich zwei Jahre nicht bewegt. Dafür gibt es Debian stable, Ubuntu LTS, RHEL/AlmaLinux/Rocky — und Fedora ist deren Vorfeld, nicht ihr Ersatz.
• Du Server betreibst und Ruhe willst. Fedora Server bekommt etwa 13 Monate Unterstützung pro Version. Wer alle 13 Monate seine Server hochziehen will, kann das tun — die meisten wollen es nicht. Wir betreiben unsere eigenen Produktionsserver deshalb mit Debian, nicht mit Fedora.
• Du selten aktualisierst oder Rechner betreust, die monatelang aus sind.
• Du Nvidia-Grafik hast und keine Lust auf den akmod-Zyklus. Das ist beherrschbar, aber es ist Arbeit.
• Du Software brauchst, die nur als .deb existiert. Das wird seltener, kommt aber vor.

Für den Server-Fall lohnt der Blick in unseren Vergleich Debian vs Ubuntu; für die Desktop-Abwägung im Alltag steht die Gegenüberstellung Fedora vs Ubuntu daneben. Wer über Absicherung nachdenkt, findet in IT-Sicherheitslücken die Angriffsklassen, gegen die Techniken wie SELinux überhaupt gebaut wurden — und in unserem Bericht über den fünf Tage lang gekaperten Server den Fall, in dem uns genau das passiert ist.

FAQ: Fedora Linux im Deep Dive

Ist Fedora nur ein Testfeld für Red Hat Enterprise Linux?

Teilweise — und das ist ein Vorteil, kein Makel. Fedora ist die Upstream-Quelle, aus der RHEL-Versionen hervorgehen, und wird von Red Hat maßgeblich finanziert. Das bedeutet aber nicht, dass Fedora instabil wäre: Die Zahlen oben zeigen ein System mit vollständiger Sicherheitsinfrastruktur, mitgelieferten SELinux-Policies für 73 Pakete und einem geordneten Release-Prozess. Was Fedora nicht bietet, sind lange Supportzeiträume — genau die sind das Produkt, das RHEL verkauft.

Wie lange wird eine Fedora-Version unterstützt?

Ungefähr 13 Monate. Neue Versionen erscheinen etwa alle sechs Monate, jede wird bis vier Wochen nach dem übernächsten Release gepflegt. Fedora 44 erschien am 28. April 2026, Fedora 45 ist mit einer Beta im August 2026 in Arbeit. Praktisch heißt das: mindestens einmal pro Jahr ein Versionsupgrade, sonst läuft man ohne Sicherheitsaktualisierungen.

Kann ich Fedora als Server einsetzen?

Technisch ja — es gibt eine eigene Server-Edition, und die Paketauswahl ist hervorragend. Betrieblich sprechen die 13 Monate Unterstützung dagegen. Für Server, die laufen sollen ohne dass jemand hinsieht, sind Debian stable, Ubuntu LTS oder ein RHEL-Nachbau die passenderen Werkzeuge. Fedora Server nutzt übrigens weiterhin XFS als Standarddateisystem, nicht Btrfs.

Ist Fedora schneller als Ubuntu?

In der wahrgenommenen Reaktionszeit oft ja, aber nicht aus dem Grund, den man vermutet. Der spürbarste Unterschied ist, dass Fedora Systemanwendungen als native Pakete ausliefert, wo Ubuntu Snaps benutzt — der Erststart eines Snaps ist merklich langsamer. Dazu kommt bei DNF5 der weggefallene Python-Interpreterstart. Bei reiner Rechenleistung nehmen sich beide Distributionen nichts.

Muss ich SELinux abschalten, damit Dinge funktionieren?

Nein, und man sollte es nicht. Die 73 Pakete mit eigener Policy zeigen, dass das Ökosystem darauf ausgelegt ist. Bei Zugriffsfehlern ist die richtige Reaktion fast immer restorecon auf die betroffenen Dateien oder das Setzen eines passenden Kontexts — nicht setenforce 0. Wer SELinux abschaltet, wirft alle mitgelieferten Regelwerke gleichzeitig weg.

Bekomme ich mit Btrfs automatisch Snapshots und Rollback?

Nein. Fedora legt Btrfs mit Subvolumes und zstd-Kompression an, richtet aber keine automatischen Snapshots ein. Für openSUSE-artigen Komfort braucht es snapper, den DNF-Plugin und grub-btrfs — alles nachinstallierbar, aber eben nachzuinstallieren.

Silverblue oder Workstation — was soll ich nehmen?

Workstation, wenn du unvorhersehbare Software brauchst, Kernel-Module baust oder proprietäre Treiber einsetzt. Silverblue, wenn dein Rechner einen klaren Zweck hat, du ohnehin mit Containern arbeitest und du ein System willst, das sich durch Benutzung nicht verändert. Die ehrliche Faustregel: Wenn du regelmäßig rpm-ostree install brauchst, ist Workstation die richtige Wahl.

Nutzt Fedora 44 wirklich das neue RPM-6-Paketformat?

Nein — und das ist eine wichtige Unterscheidung. Fedora 44 liefert RPM 6.0.1 als Werkzeug aus, das v6-Pakete bauen und lesen kann. Die tatsächlich ausgelieferten Pakete sind aber weiterhin im v4-Format; wir haben das an Paketen aus dem Release-Repo, dem Updates-Repo und Rawhide direkt an der Datei geprüft. Post-Quantum-Signaturen sind damit möglich, aber im Katalog noch nicht in Betrieb.

Lohnt sich Rawhide für den täglichen Einsatz?

Für die meisten nein, aber aus einem präziseren Grund als „zu instabil”. Unsere Messung zeigt 88,4 % identische Pakete zwischen Rawhide und Fedora 44. Der Unterschied konzentriert sich auf systemd, glibc, Desktop und Sprach-Runtimes — also genau auf die Komponenten, deren Ausfall das Booten verhindert und nicht nur ein Programm. Wer beitragen will, sollte Rawhide in einer VM oder auf einem Zweitgerät fahren.

Wie steige ich von Ubuntu auf Fedora um?

Die technische Hürde ist niedrig, die mentale liegt in drei Punkten: apt heißt dnf, SELinux ist scharf statt AppArmor, und proprietäre Treiber sowie Codecs kommen über RPM Fusion, nicht aus dem Hauptrepository. Wer diese drei Dinge am ersten Tag einrichtet, hat die typischen Umstiegsprobleme hinter sich. Details im Vergleich Fedora vs Ubuntu.

Fazit: eine Distribution, die man verstehen muss statt benutzen

Nach dieser Messung würden wir Fedora nicht mehr als „das aktuelle Linux” beschreiben, sondern präziser: Fedora ist eine Distribution, die Aktualität zur Konstruktionsentscheidung gemacht hat — mit allen Konsequenzen, die daran hängen.

Die drei Zahlen, die das belegen, stehen alle oben:

1. Kernel 7.1.8 in einem seit dreieinhalb Monaten veröffentlichten Release — derselbe Stand, den kernel.org einen Tag zuvor als aktuellen Stable freigegeben hat.
2. 19.677 aktualisierte Pakete seit dem Release, 1.063 davon mit Hauptversionssprung. Eine Fedora-Version ist kein Zustand, sondern ein Zeitfenster.
3. 88,4 % identische Pakete zwischen Rawhide und stabilem Fedora. Der Entwicklungszweig ist viel näher dran, als sein Ruf sagt — das Risiko liegt in der Tiefe, nicht in der Breite.

Wer das als Vorteil liest, bekommt eine der besten Entwicklermaschinen, die es gibt. Wer Stabilität im Sinne von Unveränderlichkeit sucht, liest dieselben Zahlen als Warnung — völlig zu Recht.

Und der Befund, der uns beim Schreiben am meisten überrascht hat, ist der kleinste: Fedora liefert RPM 6 aus und baut trotzdem v4-Pakete. Wir hätten das ungeprüft anders aufgeschrieben, und es hätte richtig geklungen. Es ist auch die allgemeinste Lehre dieses Artikels — die installierte Version eines Werkzeugs sagt, was möglich ist, nicht was passiert.