Sortie d'AlmaLinux 9.8 et 10.2.

La version d'AlmaLinux 10.2 a été publiée, ainsi qu'une mise à jour de la précédente branche — AlmaLinux 9.8. Les versions sont synchronisées avec Red Hat Enterprise Linux 9.8 et 10.2, et contiennent tous les changements proposés dans ces versions. Des images d'installation sont préparées pour les architectures x86_64_v3, x86_64_v2, ARM64, ppc64le et s390x sous forme d'images de démarrage (1 Go), minimes (1,6 Go) et complètes (10 Go). Des builds Live avec GNOME, KDE, MATE et Xfce, ainsi que des images pour des plaques Raspberry Pi, des conteneurs, WSL (Windows Subsystem for Linux) et des plateformes cloud seront créés ultérieurement.

Le distributeur est autant que possible binaire compatible avec Red Hat Enterprise Linux et peut être utilisé comme un remplacement pour RHEL 10.2 et CentOS 10 Stream. En plus du rebranding et de la suppression des paquets spécifiques à RHEL, AlmaLinux 10.2 présente les différences suivantes par rapport à RHEL 10.2 :

• Un dépôt de paquets compilés pour l'architecture i686 a été publié, ainsi que des images de conteneurs au format Docker pour les systèmes 32 bits x86. La société Red Hat a abandonné le développement de builds 32 bits pour l'architecture x86 dans la version RHEL 7, publiée en 2014. Dans la branche CentOS 7, la compilation de paquets 32 bits a été poursuivie par l'équipe CentOS Linux AltArch SIG, mais à partir de la branche CentOS 8, ce développement a cessé. La raison de la renaissance des builds pour l'architecture i686 dans AlmaLinux a été le désir de permettre l'exécution d'anciennes applications, disponibles uniquement sous forme d'exécutables pour systèmes 32 bits. Les builds peuvent également être utiles pour créer des environnements 32 bits pour tester du code dans des systèmes d'intégration continue et pour exécuter des conteneurs pour des programmes 32 bits.
• Le support du système de fichiers Btrfs a été rétabli. La possibilité de partitionner les disques avec Btrfs a été ajoutée dans l'installateur, le module de noyau btrfs.ko a été installé, l'ensemble d'outils btrfs-progs a été réintroduit, et des travaux ont été effectués pour adapter l'utilisation de Btrfs dans la pile de gestion des données et vérifier 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été Red Hat a déclaré le système de fichiers Btrfs obsolète dans la version RHEL 7.4 (2017) et a complètement cessé son support dans la branche RHEL 8.
• Par défaut, le dépôt de paquets CRB (CodeReady Builder) est activé, qui fournit une sélection de paquets non proposés par défaut dans Red Hat Enterprise Linux, tels que des applications pour développeurs, des bibliothèques supplémentaires et des wrappers, ainsi que des paquets contenant des données de débogage, de la documentation, des fichiers d'en-tête, des assemblages statiques et des exemples de code (paquets « -devel », « -example », « -doc » et « -static »). Parmi les autres, le CRB contient des bibliothèques utilisées comme dépendances dans les paquets du dépôt.
  EPEL (Extra Packages for Enterprise Linux).
• Des paquets pour installer les pilotes NVIDIA et la pile CUDA ont été formés. Les pilotes peuvent être utilisés dans des configurations avec UEFI Secure Boot. Les modules du noyau provenant de l'ensemble de pilotes propriétaires officiel de NVIDIA ne peuvent pas être chargés en mode UEFI Secure Boot, car ils ne sont pas signés numériquement par la distribution. Cette restriction
  a pu être contournée grâce à l'utilisation de modules du noyau ouverts par NVIDIA, sur la base desquels a été formé un paquet propre nvidia-open-kmod avec des modules signés numériquement par AlmaLinux. Un paquet séparé, almalinux-release-nvidia-driver, a été créé avec la configuration du dépôt externe pris en charge par NVIDIA, à partir duquel les pilotes CUDA et les composants propriétaires du pilote NVIDIA fonctionnant dans l'espace utilisateur sont chargés.
• Des assemblages distincts pour la deuxième version de l'architecture x86-64 (x86-64-v2) ont été formés, accompagnés parallèlement des assemblages de base x86-64, créés avec des optimisations pour l'architecture x86-64-v3, utilisée dans RHEL 10. Un support supplémentaire pour x86-64-v2 permet d'assurer la compatibilité avec les CPU plus anciens comme Intel Haswell et AMD Excavator, conçus avant 2013. En plus des dépôts standards, des assemblages x86-64-v2 ont également été préparés pour les paquets du dépôt EPEL.
• Les implémentations serveur et client du protocole SPICE ont été rétablies, permettant d'organiser le travail à 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'écran et le traitement des flux audio sont effectués côté client, et non sur le serveur. Dans RHEL, le soutien pour SPICE a été arrêté dans la version 9.0.
• Le registre processeur %rbp est de nouveau utilisé comme pointeur de base pour la trame de la pile, contenant les adresses de retour et les variables de la fonction (frame pointer). L'utilisation du pointeur de cadre de pile permet d'exploiter des fonctionnalités supplémentaires pour le traçage et le profilage du système dans le distributeur.
• Il est désormais possible d'utiliser un hyperviseur KVM sur des systèmes avec des processeurs IBM POWER. Dans RHEL, un tel soutien a été interrompu dans la branche 9.0.
• Le dépôt est pris en charge.
  Synergy, qui abrite des paquets différents de ceux de Red Hat Enterprise Linux. Actuellement, le dépôt Synergy a déjà publié des paquets avec l'environnement utilisateur Pantheon, développé par le projet Elementary OS, et l'outil Warpinator, conçu pour le partage de fichiers chiffré entre deux ordinateurs.
• La possibilité de démarrer en mode UEFI Secure Boot a été mise en œuvre pour les systèmes avec des processeurs Intel/AMD et ARM.
• Le support de plus de 150 dispositifs matériels, non pris en charge dans RHEL 10.2, a été rétabli. Par exemple, les identifiants des anciens périphériques PCI dans les pilotes ont été réintroduits :
  • aacraid — Dell PERC2, 2/SI, 3/SI, 3/DI, produits avancés Adaptec RAID, HP NetRAID-4M, IBM ServeRAID & ICP SCSI
  • be2iscsi — Emulex OneConnect Open-iSCSI pour BladeEngine 2 et 3
  • be2net — Adaptateurs Emulex BladeEngine 2 et 3 *
  • hpsa — Contrôleur HP Smart Array
  • lpfc — SCSI Fibre Channel Emulex LightPulse
  • megaraid_sas — Broadcom MegaRAID SAS
  • mlx4_core — Mellanox Gen2 et ConnectX-2
  • mpt3sas — LSI MPT Fusion SAS 3.0
  • mptsas — Hôte SAS Fusion MPT
  • qla2xxx — HBA Fibre Channel QLogic
  • qla4xxx — HBA iSCSI QLogic.

La distribution AlmaLinux est basée par CloudLinux en réponse à l'arrêt prématuré du support de CentOS 8 par Red Hat (la sortie des mises à jour pour CentOS 8 s'est arrêtée fin 2021, et non en 2029 comme prévu par les utilisateurs). Le projet est soutenu par une organisation à but non lucratif distincte, l'AlmaLinux OS Foundation, qui a été créée pour le développement sur une plateforme neutre avec la participation de la communauté et en utilisant un modèle de gestion similaire à celui du projet Fedora. La distribution est gratuite pour toutes les catégories d'utilisateurs. Tous les travaux développés pour AlmaLinux sont publiés sous des licences libres.

En plus d'AlmaLinux, d'autres alternatives au classique CentOS incluent Rocky Linux (développé par la communauté sous la direction du fondateur de CentOS), Oracle Linux, SUSE Liberty Linux et EuroLinux. En outre, Red Hat a offert la possibilité d'utiliser gratuitement RHEL dans les organisations qui favorisent le logiciel open source et dans des environnements de développeurs individuels comptant jusqu'à 16 systèmes virtuels ou physiques.

Source : opennet.ru