{"id":163967,"date":"2026-03-11T23:11:54","date_gmt":"2026-03-11T21:11:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/beta-testirovanie-fedora-linux-44-inicziativa-po-prodvizheniyu-innovaczij-v-fedora"},"modified":"2026-03-11T23:11:54","modified_gmt":"2026-03-11T21:11:54","slug":"beta-testirovanie-fedora-linux-44-inicziativa-po-prodvizheniyu-innovaczij-v-fedora","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/beta-testirovanie-fedora-linux-44-inicziativa-po-prodvizheniyu-innovaczij-v-fedora","title":{"rendered":"Beta-Test von Fedora Linux 44. Initiative zur F\u00f6rderung von Innovationen in Fedora","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Die Beta-Version des Fedora Linux 44 Distributions wurde vorgestellt, die den \u00dcbergang zur finalen Testphase markiert, in der nur kritische Fehlerbehebungen zul\u00e4ssig sind. Die Ver\u00f6ffentlichung ist f\u00fcr den 14. April geplant. Die Version umfasst Fedora Workstation, Fedora KDE Plasma Desktop, Fedora Server, Fedora IoT, Fedora CoreOS, Fedora Cloud Base, Fedora IoT Edition, Fedora Silverblue, Fedora Kinoite und Live-Images, die in Form von Spins mit benutzerdefinierten Umgebungen wie Xfce, MATE, Cinnamon, LXDE, Phosh, Miracle, LXQt, Budgie, Sway und Cosmic bereitgestellt werden. Die Builds sind f\u00fcr die Architekturen x86_64, Power64 und ARM64 (AArch64) erstellt worden. <\/p>\n
Die wichtigsten \u00c4nderungen in Fedora Linux 44: <\/p>\n
\n
Die Arbeiten zur Verbesserung der Infrastruktur f\u00fcr reproduzierbare Builds wurden vorangetrieben, um mindestens 99% der Pakete im Fedora-Repository abzudecken. In fr\u00fcheren Versionen wurde die Abdeckung durch reproduzierbare Builds auf 90% gesch\u00e4tzt, dank \u00c4nderungen am Build-System, die die Metadaten \u00fcber die \u00c4nderungszeit der Dateien mit dem Referenz-Quellcode synchronisierten, sowie einer konsistenten Reihenfolge der Auflistung der Metadaten und Strukturen in den Bin\u00e4rdateien. Um reproduzierbare Builds in den verbleibenden 10% sicherzustellen, wurden die Betreuer problematischer Pakete hinzugezogen. Reproduzierbare Builds geben dem Benutzer die M\u00f6glichkeit, sich pers\u00f6nlich davon zu \u00fcberzeugen, dass die in den Paketen verteilten Bin\u00e4rdateien aus dem bereitgestellten Quellcode erstellt wurden und keine versteckten \u00c4nderungen enthalten, die durch eine Kompromittierung des Compilers oder der Build-Tools verursacht wurden.\n
In allen Versionen des Distribution mit KDE-Desktop (Fedora KDE Plasma Desktop Edition, Fedora KDE Plasma Mobile Spin und Fedora Kinoite) wird f\u00fcr die Systemkonfiguration nach der Installation das von KDE weiterentwickelte Plasma Setup verwendet, und im Installer Anaconda wurden die sich mit dieser Anwendung \u00fcberschneidenden Konfigurationsstufen deaktiviert.\n
In allen Editionen mit KDE wurde der Anmelde-Manager SDDM durch den Plasma Login Manager ersetzt, ein von KDE entwickeltes Projekt.\n
Die Fedora Games Lab-Edition wurde \u00fcberarbeitet und bietet eine Sammlung von Paketen und Einstellungen f\u00fcr Computer-Gameplay-Enthusiasten. In der neuen Version wurde der Software-Stack zum Ausf\u00fchren von Spielen aktualisiert, und aktuelle Technologien wie Wayland und PipeWire wurden integriert.\n
Die GNOME-Desktop-Umgebung wurde auf die Version 50 aktualisiert, in der die Unterst\u00fctzung f\u00fcr X11 eingestellt wurde und ein neues System zur Sitzungsspeicherung implementiert wurde.\n
Die Benutzerumgebung Budgie wurde auf die Version 10.10 aktualisiert, die auf Wayland umgestellt wurde.\n
Im Installer Anaconda wurde die Logik zur Erstellung von Netzwerkprofilen (Dateien mit Einstellungen f\u00fcr NetworkManager) im installierten System ge\u00e4ndert. Solche Profile werden jetzt nicht f\u00fcr alle vorhandenen kabelgebundenen Netzwerkger\u00e4te erstellt, sondern nur f\u00fcr die Ger\u00e4te, die im Installationsprozess \u00fcber das GUI, die Boot-Optionen oder die Kickstart-Datei konfiguriert wurden. Die Erstellung von Profilen f\u00fcr alle verf\u00fcgbaren Ger\u00e4te, nicht nur f\u00fcr die vom Benutzer ausgew\u00e4hlten, erforderte die L\u00f6schung \u00fcberfl\u00fcssiger Profile nach der Installation und f\u00fchrte zu Schwierigkeiten bei der sp\u00e4teren Notwendigkeit, die Einstellungen zu \u00e4ndern.\n
Auf Systemen mit der Architektur Aarch64 erfolgt die automatische Auswahl der Hardwarebeschreibung DTB (Device Tree Blobs) f\u00fcr den UEFI-Bootloader, wodurch Probleme beim Booten von Live-Images von Fedora auf ARM-Notebooks gel\u00f6st wurden, die mit Windows ausgeliefert werden.\n
In den Live-Images wird das Skript-Set livesys-scripts zur Konfiguration der Arbeitsumgebung verwendet, sowie neue Funktionen des Dracut-Tools zur automatischen Erstellung eines speicherbaren Overlay-Speichers beim Schreiben des Images auf USB-Speicher.\n
Die Arbeit an der Migration der kontinuierlichen Integrationsinfrastruktur (dist-git CI), die die Wiederherstellung von RPM-Paketen nach \u00c4nderungen oder Versionsaktualisierungen durchf\u00fchrt, auf die Standardnutzung des Werkzeugs Packit anstelle von Fedora CI und Zuul wurde fortgesetzt.\n
Im Repository wurde ein Toolkit mit dem Paketmanager NIX hinzugef\u00fcgt, das die Installation von Paketen im NIX-Format aus der Sammlung nixpkgs erm\u00f6glicht. Pakete k\u00f6nnen im Einbenutzer- (in das Heimatverzeichnis des Benutzers) und im Mehrbenutzermodus (in das Verzeichnis \/nix) installiert werden.\n
Standardm\u00e4\u00dfig ist die Verwendung von Hardlinks aktiviert, um identische Dateien, die aus verschiedenen Paketen installiert werden, in der Hierarchie \/usr zu verkn\u00fcpfen. Das Erstellen eines Hardlinks erfolgt automatisch beim Installieren des Pakets durch den Installer in der Phase \u201epost install\u201c.\n
Die Bereitstellung von QEMU-Builds f\u00fcr 32-Bit-Host-Systeme (i686) wurde eingestellt. Diese \u00c4nderung spiegelt die Arbeit des QEMU-Projekts wider, die Unterst\u00fctzung von 32-Bit-Host-Systemen zu entfernen.\n
Die ausf\u00fchrbaren Dateien und Bibliotheken von FUSE 2 wurden aus den atomaren Versionen von Fedora f\u00fcr Desktop-Systeme entfernt (diese Version wurde zuvor als veraltet erkl\u00e4rt und alle Pakete wurden auf die Nutzung von FUSE 3 umgestellt). Auch die Unterst\u00fctzung f\u00fcr veraltete polkit-Regeln, die in pkla-Dateien geliefert wurden, wurde eingestellt.\n
PackageKit wurde auf die Verwendung des neuen Backends DNF5 umgestellt, das mit der Bibliothek libdnf5 erstellt wurde.\n
In der Distribution mit dem Kompositionsmanager MiracleWM wurde die Desktop-Oberfl\u00e4che nwg-shell durch die Dank Material Shell ersetzt.\n
Standardm\u00e4\u00dfig ist das Kernmodul NTSYNC aktiviert, das die Leistung von Windows-Spielen, die \u00fcber Wine gestartet werden, erheblich steigert. Das Modul implementiert das symbolische Ger\u00e4t \/dev\/ntsync und eine Reihe von Synchronisationsprimitive, die im Windows NT-Kernel verwendet werden. Der signifikante Leistungsschub wird durch die Beseitigung von Overhead erreicht, der mit der Verwendung von RPC im Benutzermodus verbunden ist.\n
In Fedora Cloud wird anstelle einer separaten Partition \/boot nun ein gleichnamiger Unterordner von Btrfs angeboten.\n
Die Bereitstellung des Pakets libreoffice-KF5 mit Komponenten zur Integration von LibreOffice mit Qt5 wurde eingestellt. Es wurde durch das Paket libreoffice-kf6 ersetzt, das die Integration mit Qt6 gew\u00e4hrleistet. <\/ul>\n
Zus\u00e4tzlich kann die Initiative zur Reformierung des Fedora-Entwicklungsprozesses hervorgehoben werden, die von Jef Spaleta, dem Projektleiter von Fedora, zur Diskussion gestellt wurde. Jef schl\u00e4gt vor, eine \"Sandbox\" zu schaffen, um das Testen neuer Ideen und das Experimentieren mit neuen Technologien im Distribution zu vereinfachen, ohne das Risiko einer Beeintr\u00e4chtigung der Stabilit\u00e4t des Hauptprojekts. <\/p>\n
Es wird davon ausgegangen, dass innovative Ideen zur Weiterentwicklung der Distribution Hand in Hand mit der Hauptdistribution wachsen werden und im Laufe der Zeit integriert werden k\u00f6nnen, wenn bestimmte Bedingungen erf\u00fcllt sind, der Wert f\u00fcr das Projekt best\u00e4tigt wird und Interesse anderer Entwickler besteht. Der Lebenszyklus experimenteller Technologien umfasst mehrere Entwicklungsphasen mit Bewertungen zu festgelegten Zeitpunkten und dem \u00dcbergang zur n\u00e4chsten Phase, nachdem die f\u00fcr jede Phase festgelegten Kriterien erf\u00fcllt sind. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"