{"id":149420,"date":"2025-11-24T23:11:54","date_gmt":"2025-11-24T21:11:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/dostupen-distributiv-almalinux-10-1"},"modified":"2025-11-24T23:11:54","modified_gmt":"2025-11-24T21:11:54","slug":"dostupen-distributiv-almalinux-10-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/dostupen-distributiv-almalinux-10-1","title":{"rendered":"Le distributeur AlmaLinux 10.1 est maintenant disponible.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
La version d'AlmaLinux 10.1 a \u00e9t\u00e9 pr\u00e9sent\u00e9e, synchronis\u00e9e avec Red Hat Enterprise Linux 10.1 et contenant tous les changements propos\u00e9s dans cette version. Les images d'installation sont pr\u00e9par\u00e9es pour les architectures x86_64_v3, x86_64_v2, ARM64, ppc64le et s390x sous forme d'image bootable (927 Mo), d'image minimale (1,4 Go) et d'image compl\u00e8te (8,3 Go). Des versions Live avec GNOME, KDE, MATE et Xfce, ainsi que des images pour Raspberry Pi, des conteneurs, WSL (Windows Subsystem for Linux) et des plateformes cloud seront cr\u00e9\u00e9es ult\u00e9rieurement. <\/p>\n
Le syst\u00e8me d'exploitation est autant que possible binaire compatible avec Red Hat Enterprise Linux et peut \u00eatre utilis\u00e9 comme remplacement de RHEL 10.1 et CentOS 10 Stream. En plus du rebranding et de la suppression des paquets sp\u00e9cifiques \u00e0 RHEL, AlmaLinux 10.1 pr\u00e9sente les diff\u00e9rences suivantes par rapport \u00e0 RHEL 10.1 : <\/p>\n
\n
La prise en charge du syst\u00e8me de fichiers Btrfs a \u00e9t\u00e9 r\u00e9tablie. La possibilit\u00e9 de partitionner les disques \u00e0 l'aide de Btrfs a \u00e9t\u00e9 ajout\u00e9e dans l'installateur, le module du noyau btrfs.ko a \u00e9t\u00e9 install\u00e9, l'ensemble des utilitaires btrfs-progs a \u00e9t\u00e9 restitu\u00e9, et un travail a \u00e9t\u00e9 r\u00e9alis\u00e9 pour adapter le fonctionnement de Btrfs avec la pile de gestion de donn\u00e9es et v\u00e9rifier le bon fonctionnement des paquets bcc, buildah, cockpit, ignition, libblockdev, libguestfs, osbuild, osbuild-composer, podman, pykickstart, python-blivet, skopeo, udisks2 et virt-v2v dans des environnements avec Btrfs. La soci\u00e9t\u00e9 Red Hat a d\u00e9clar\u00e9 que le syst\u00e8me de fichiers Btrfs \u00e9tait obsol\u00e8te dans la version RHEL 7.4 (2017) et a enti\u00e8rement arr\u00eat\u00e9 son support dans la branche RHEL 8.\n
Le d\u00e9p\u00f4t de paquets CRB (CodeReady Builder) est activ\u00e9 par d\u00e9faut, contenant une s\u00e9lection de paquets qui ne sont pas fournis par d\u00e9faut dans Red Hat Enterprise Linux, tels que des applications pour d\u00e9veloppeurs, des biblioth\u00e8ques suppl\u00e9mentaires et des wrappers, ainsi que des paquets contenant des donn\u00e9es de d\u00e9bogage, de la documentation, des fichiers d'en-t\u00eate, des compilations statiques et des exemples de code (paquets \u00ab -devel \u00bb, \u00ab -example \u00bb, \u00ab -doc \u00bb et \u00ab -static \u00bb). Parmi d'autres, le CRB contient des biblioth\u00e8ques utilis\u00e9es comme d\u00e9pendances dans les paquets du d\u00e9p\u00f4t EPEL (Extra Packages for Enterprise Linux).\n
Des paquets ont \u00e9t\u00e9 cr\u00e9\u00e9s pour installer les pilotes NVIDIA et la pile CUDA. Les pilotes peuvent \u00eatre utilis\u00e9s dans des configurations avec UEFI Secure Boot. Les modules du noyau du jeu de pilotes propri\u00e9taires de NVIDIA ne peuvent pas \u00eatre charg\u00e9s en mode UEFI Secure Boot, car ils ne sont pas sign\u00e9s num\u00e9riquement par la distribution. Cette limitation a \u00e9t\u00e9 contourn\u00e9e gr\u00e2ce \u00e0 l'utilisation des modules du noyau ouverts de NVIDIA, sur la base desquels un paquet propre, nvidia-open-kmod, a \u00e9t\u00e9 cr\u00e9\u00e9 avec des modules sign\u00e9s num\u00e9riquement par AlmaLinux. Un paquet distinct, almalinux-release-nvidia-driver, a \u00e9galement \u00e9t\u00e9 \u00e9labor\u00e9 avec la configuration du d\u00e9p\u00f4t externe pris en charge par NVIDIA, \u00e0 partir duquel les pilotes CUDA et les composants propri\u00e9taires du pilote NVIDIA fonctionnant en espace utilisateur sont t\u00e9l\u00e9charg\u00e9s.\n
Des assemblages distincts pour la deuxi\u00e8me version de l'architecture x86-64 (x86-64-v2) ont \u00e9t\u00e9 form\u00e9s, accompagn\u00e9s parall\u00e8lement des assemblages de base x86-64, cr\u00e9\u00e9s avec des optimisations pour l'architecture x86-64-v3, utilis\u00e9e dans RHEL 10. Un support suppl\u00e9mentaire pour x86-64-v2 permet d'assurer la compatibilit\u00e9 avec les CPU plus anciens comme Intel Haswell et AMD Excavator, con\u00e7us avant 2013. En plus des d\u00e9p\u00f4ts standards, des assemblages x86-64-v2 ont \u00e9galement \u00e9t\u00e9 pr\u00e9par\u00e9s pour les paquets du d\u00e9p\u00f4t EPEL. <\/li>\n
Les impl\u00e9mentations serveur et client du protocole SPICE ont \u00e9t\u00e9 r\u00e9tablies, permettant d'organiser le travail \u00e0 distance avec un bureau fonctionnant dans un environnement virtuel sous la gestion de QEMU\/KVM. Contrairement aux protocoles VNC et RDP, dans SPICE, le rendu du contenu de l'\u00e9cran et le traitement des flux audio sont effectu\u00e9s c\u00f4t\u00e9 client, et non sur le serveur<\/a>. Dans RHEL, le soutien pour SPICE a \u00e9t\u00e9 arr\u00eat\u00e9 dans la version 9.0.\n