{"id":181758,"date":"2026-05-27T02:48:02","date_gmt":"2026-05-27T00:48:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/reliz-almalinux-9-8-i-10-2"},"modified":"2026-05-27T02:48:02","modified_gmt":"2026-05-27T00:48:02","slug":"reliz-almalinux-9-8-i-10-2","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/reliz-almalinux-9-8-i-10-2","title":{"rendered":"Ver\u00f6ffentlichung von AlmaLinux 9.8 und 10.2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Die Version des AlmaLinux-Distributions 10.2 wurde vorgestellt, sowie das Update der vorherigen Version \u2013 AlmaLinux 9.8. Die Releases sind mit Red Hat Enterprise Linux 9.8 und 10.2 synchronisiert und enthalten alle in diesen Versionen vorgeschlagenen \u00c4nderungen. Die Installations-Images wurden f\u00fcr die Architekturen x86_64_v3, x86_64_v2, ARM64, ppc64le und s390x in Form von Boot- (1 GB), Minimal- (1,6 GB) und Voll-Images (10 GB) vorbereitet. Sp\u00e4ter werden Live-Images mit GNOME, KDE, MATE und Xfce sowie Images f\u00fcr Raspberry Pi, Container, WSL (Windows-Subsystem f\u00fcr Linux) und Cloud-Plattformen erstellt.<\/p>\n
Die Distribution ist nach M\u00f6glichkeit bin\u00e4r kompatibel mit Red Hat Enterprise Linux und kann als Ersatz f\u00fcr RHEL 10.2 und CentOS 10 Stream verwendet werden. Neben der Umbenennung und der Entfernung RHEL-spezifischer Pakete weist AlmaLinux 10.2 folgende Unterschiede zu RHEL 10.2 auf:\n<\/p>\n
\n
Ein Repository f\u00fcr Pakete, die f\u00fcr die Architektur i686 erstellt wurden, wurde ver\u00f6ffentlicht, ebenso wie Container-Images im Docker-Format f\u00fcr 32-Bit-Systeme x86. Red Hat hat die Erstellung von 32-Bit-Builds f\u00fcr die Architektur x86 mit der Ver\u00f6ffentlichung von RHEL 7, die 2014 ver\u00f6ffentlicht wurde, eingestellt. Im Branch CentOS 7 wurde die Erstellung von 32-Bit-Paketen vom CentOS Linux AltArch SIG fortgesetzt, aber ab dem Branch CentOS 8 wurde die Erstellung solcher Builds eingestellt. Der Grund f\u00fcr die Wiederbelebung der Builds f\u00fcr die Architektur i686 in AlmaLinux war der Wunsch, die Ausf\u00fchrung \u00e4lterer Anwendungen zu erm\u00f6glichen, die nur in Form von ausf\u00fchrbaren Dateien f\u00fcr 32-Bit-Systeme verf\u00fcgbar sind. Die Builds k\u00f6nnen auch n\u00fctzlich sein, um 32-Bit-Umgebungen f\u00fcr die Code-Tests in Continuous Integration-Systemen zu erstellen und um Container f\u00fcr 32-Bit-Programme auszuf\u00fchren.\n
Die Unterst\u00fctzung f\u00fcr das Btrfs-Dateisystem wurde zur\u00fcckgebracht. Die M\u00f6glichkeit, Speicher mit Btrfs im Installer zu partitionieren, wurde hinzugef\u00fcgt, und das Kernel-Modul btrfs.ko wurde installiert. Das Set von btrfs-progs wurde zur\u00fcckgebracht, und es wurde Arbeit an der Anpassung des Management-Stacks f\u00fcr die Datenlagerung, der Funktionalit\u00e4t der Pakete bcc, buildah, cockpit, ignition, libblockdev, libguestfs, osbuild, osbuild-composer, podman, pykickstart, python-blivet, skopeo, udisks2 und virt-v2v in Btrfs-Umgebungen durchgef\u00fchrt. Red Hat hatte das Btrfs-Dateisystem in der Ver\u00f6ffentlichung RHEL 7.4 (2017) als veraltet erkl\u00e4rt und die Unterst\u00fctzung in der RHEL 8-Reihe vollst\u00e4ndig eingestellt.\n<\/li>\n
Standardm\u00e4\u00dfig ist das Paket-Repository CRB (CodeReady Builder) aktiviert, das eine Sammlung von Paketen enth\u00e4lt, die von Red Hat Enterprise Linux standardm\u00e4\u00dfig nicht angeboten werden, wie Entwickleranwendungen, zus\u00e4tzliche Bibliotheken und Bindings sowie Pakete mit Debugging-Daten, Dokumentation, Header-Dateien, statischen Builds und Beispielcode (Pakete \u201a-devel\u2018, \u201a-example\u2018, \u201a-doc\u2018 und \u201a-static\u2018). Unter anderem sind im CRB Bibliotheken enthalten, die als Abh\u00e4ngigkeiten in Paketen aus dem Repository verwendet werden. \nEPEL (Extra Packages for Enterprise Linux). <\/p>\n<\/li>\n
Pakete f\u00fcr die Installation von NVIDIA-Treibern und dem CUDA-Stack wurden erstellt. Die Treiber k\u00f6nnen in Konfigurationen mit UEFI Secure Boot verwendet werden. Kernelmodule aus dem offiziellen Propriet\u00e4rsatz von NVIDIA k\u00f6nnen im UEFI Secure Boot-Modus nicht geladen werden, da sie nicht mit einer digitalen Signatur des Distributors versehen sind. Diese Einschr\u00e4nkung \nkonnte durch die Verwendung der von NVIDIA bereitgestellten offenen Kernelmodule umgangen werden, auf deren Basis das eigene Paket nvidia-open-kmod mit Modulen erstellt wurde, die mit einer digitalen Signatur von AlmaLinux zertifiziert sind. Separat wurde das Paket almalinux-release-nvidia-driver mit der Konfiguration des von NVIDIA unterst\u00fctzten externen Repositories erstellt, aus dem die CUDA-Treiber und propriet\u00e4ren Komponenten des NVIDIA-Treibers, die im Benutzermodus arbeiten, heruntergeladen werden.<\/p>\n<\/li>\n
Es wurden separate Builds f\u00fcr die zweite Version der x86-64 Mikroarchitektur (x86-64-v2) erstellt, die parallel zu den Basis-Builds x86-64 bereitgestellt werden, die mit Optimierungen f\u00fcr die Mikroarchitektur x86-64-v3 erstellt werden, die in RHEL 10 verwendet wird. Die zus\u00e4tzliche Unterst\u00fctzung von x86-64-v2 erm\u00f6glicht die Kompatibilit\u00e4t mit CPUs, die \u00e4lter sind als Intel Haswell und AMD Excavator, die vor 2013 entwickelt wurden. Neben den Standard-Repositories sind auch x86-64-v2 Builds f\u00fcr Pakete aus dem EPEL-Repository vorbereitet worden.\n<\/li>\n
Die Server- und Clientimplementierungen des SPICE-Protokolls wurden zur\u00fcckgebracht, das die Fernarbeit mit einem Desktop erm\u00f6glicht, der in einer virtuellen Umgebung unter QEMU\/KVM l\u00e4uft. Im Gegensatz zu den Protokollen VNC und RDP erfolgt bei SPICE die Anzeige des Bildschirminhalts und die Verarbeitung von Audiostreams auf der Clientseite, nicht auf Server<\/a>. In RHEL wurde die Unterst\u00fctzung von SPICE mit der Version 9.0 eingestellt.\n<\/li>\n