Connexion
Fedora Linux 41 est dans la place
En ce mardi 29 octobre 2024, les utilisateurs du Projet Fedora seront ravis d’apprendre la disponibilité de la version Fedora Linux 41.
Fedora Linux est une distribution communautaire développée par le projet Fedora et sponsorisée par Red Hat, qui lui fournit des développeurs ainsi que des moyens financiers et logistiques. Fedora Linux peut être vue comme une sorte de vitrine technologique pour le monde du logiciel libre, c’est pourquoi elle est prompte à inclure des nouveautés.
- lien nᵒ 1 : Site officiel du projet Fedora
- lien nᵒ 2 : Site officiel de la communauté francophone de Fedora
- lien nᵒ 3 : Image Torrent officiels
- lien nᵒ 4 : Procédure de mise à niveau
Sommaire
- Expérience utilisateur
- Gestion du matériel
- Internationalisation
- Administration système
- Développement
- Projet Fedora
- La communauté francophone
- Comment se procurer Fedora Linux 41 ?
Expérience utilisateur
Passage à GNOME 47. Cette nouvelle version de l’environnement phare de Fedora propose de nombreuses améliorations. Tout d’abord, il est maintenant possible de personnaliser une couleur "accentuée" (accent color) qui influencera la couleur de nombreux éléments graphiques comme des boutons. Cela intègre donc un changement en place chez Ubuntu depuis quelques années. Pour ceux disposant de petits écrans, certains boutons et autres icônes sont agrandies pour rendre leur interaction plus aisée dans ce contexte.
L’interface a été en partie remaniée au niveau des boîtes de dialogue pour rendre leur interaction plus simple notamment avec des petits écrans avec des boutons plus gros et plus espacés entre eux. Et bien sûr ces boutons tiennent compte maintenant de la couleur accentuée explicitée précédemment. L’interface pour ouvrir ou sauvegarder un fichier repose maintenant sur le code du navigateur de fichiers nommé Fichiers plutôt que d’utiliser un code indépendant jusqu’ici. Cela simplifie la maintenance mais permet surtout de fournir l’ensemble des fonctionnalités du navigateur de fichiers pour cette tâche. Par exemple il est possible de renommer des fichiers depuis cette interface, de changer l’ordre d’affichage en vue icônes, prévisualiser les fichiers sans les ouvrir, etc. Par ailleurs, le navigateur de fichiers s’améliore aussi. Les périphériques réseaux sont maintenant classifiés permettant d’identifier les ressources où on est déjà connecté, qu’on a précédemment utilisé et les autres. L’ensemble des disques durs internes sont également affichés dans la barre latérale et groupés ensemble pour rendre cela plus accessible et facile d’utilisation. Il est possible également de supprimer les dossiers par défaut dans la barre latérale pour faire de la place si on le souhaite. Et quelques autres changements plus mineurs.
Dans la configuration de l’interface, il est possible via le menu Accessibilité de configurer le changement automatique de focus d’une fenêtre à une autre par le simple survol de la souris. Option désactivée par défaut. De même lors de l’ajout de nouvelles dispositions clavier, la prévisualisation de cette disposition peut être effectuée avant de la sélectionner pour s’assurer que c’est bien celle souhaitée. De manière générale, l’affichage des préférences est plus cohérente dans le choix des éléments graphiques pour les représenter à travers l’interface.
Les comptes en ligne progressent également, les informations IMAP ou SMTP sont préremplies en se basant sur l’adresse électronique. La synchronisation du calendrier, des courriels et des contacts a été ajoutée pour les comptes Microsoft 365 pendant que la configuration d’un nouveau compte WebDAV permet de découvrir les services accessibles depuis ce compte pour faciliter l’expérience utilisateur.
Le navigateur web maison n’est pas en reste et propose quelques améliorations dont le pré remplissage des formulaires en se basant sur les entrées précédentes ce qui est disponible dans de nombreux navigateur. L’option peut être désactivée dans les préférences si nécessaire. Les marques pages ont été aussi remaniés en étant affichés dans un volet latéral et en proposant une barre de recherche intégrée pour retrouver celui qu’on souhaite. Le navigateur peut afficher le nombre de trackers publicitaires qui ont été bloqués. Malheureusement la synchronisation des éléments via Firefox Sync n’est plus possible en ce moment à cause d’un changement dans la procédure d’authentification par Mozilla.
L’application calendrier a été également améliorée avec par exemple une icône de cadenas qui s’affiche pour les événements qui sont en lecture seule. La mise en page est plus cohérente notamment dans l’espacement entre les éléments visuels. L’importation ou l’édition d’événements gèrent mieux les calendriers cachés ou en lecture seule. L’application de cartographie a été aussi légèrement améliorée en utilisant les cartes vectorisées par défaut et en proposant les trajets en transport en commun en exploitant le service Transitous plutôt qu’une solution commerciale.
Pour les amateurs d’enregistrement de leur écran en vidéo, cette tâche peut être effectuée dans la mesure du possible avec de l’accélération matérielle ce qui diminue la consommation d’énergie et améliore les performances du système dans ce cadre. Dans la même veine, le rendu effectué par la bibliothèque graphique GTK se fait via Vulkan dorénavant ce qui améliore les performances en particulier pour les machines plus anciennes et avec moins d’effets visuels indésirables due à la lenteur de certaines opérations. Dans la même veine, il y a une amélioration des performances des applications vidéos, photos et du navigateur web maison par la réduction quand c’est possible du nombre de copies en mémoire des données d’une vidéo ou d’une image.
Pour ceux qui ont accès à leur session à distance, il est dorénavant possible de rendre cette session persistante. En cas de déconnexion il est possible de revenir plus tard et de retrouver la session dans l’état où elle était.
Pour les utilisateurs avancés, il y a des changements expérimentaux qui sont proposés. Si vous souhaitez utiliser la mise à échelle fractionnaire de l’interface pour les applications utilisant X11 via XWayland, vous pouvez l’activer via la commande suivante :
$ gsettings set org.gnome.mutter experimental-features '["scale-monitor-framebuffer", "xwayland-native-scaling"]'
L’environnement de bureau léger LXQt passe à la version 2.0. Cette mise à jour importante est essentiellement technique avec un port complet vers la bibliothèque graphique Qt 6 au lieu de Qt 5 qui n’est bientôt plus maintenue. La prise en charge de Wayland est disponible à titre expérimental, cela devrait être stabilisé pour la version 2.1 à venir.
L’éditeur d’image GIMP utilise la branche de développement qui deviendra la version 3. Cette décision a été prise car GIMP devenait la raison principale pour maintenir le langage Python 2.7 dans la distribution qui n’est plus maintenue depuis quelques années. Alors que GIMP 3 devrait sortir sous peu, il a été décidé de prendre potentiellement un peu d’avance pour permettre de supprimer cette dépendance assez lourde et complexe de Fedora.
Outre cette décision, cette version de l’application propose entre autres une meilleure gestion des couleurs avec notamment la visualisation, l’import ou l’export d’images avec la colorimétrie CMJN. Les tablettes graphiques ont une expérience utilisateur améliorée avec notamment la possibilité de personnaliser l’action des boutons de ce matériel sous Wayland, et la prise en charge des écrans avec une définition HiDPI est aussi améliorée. L’édition non destructive est également possible pour séparer l’application des effets des calques de l’image pour permettre de revenir dessus plus tard. Si on le souhaite, un calque peut se redimensionner automatiquement lors de son édition lors d’un dessin par exemple. Et bien d’autres changements.
Le gestionnaire de listes de tâches Taskwarrior évolue à la version 3. Cette version a surtout changé la manière de stocker les données sauvegardées et n’est pas rétrocompatible avec l’ancienne méthode. Il est donc nécessaire d’exporter les tâches avec l’ancienne version par l’usage de la commande task export et de les importer avec la nouvelle version avec la commande task import rc.hooks=0. La tâche de sauvegarde est aussi confiée à un nouveau module TaskChampion écrit en Rust.
La mise à jour du cœur des systèmes atomiques de bureau peut se faire sans droits administrateurs, mais pas les mises à niveau de celui-ci à savoir par exemple passer d’une version Fedora Linux Silverblue 40 à Fedora Linux Silverblue 41. Cela était déjà le cas pour Fedora Silverblue avec l’usage de GNOME Logiciels mais a été de fait généralisé. L’objectif est de simplifier la procédure de mise à jour du système, qui dans le cadre d’un système atomique est considéré comme plus sûre que dans un système traditionnel de par sa conception qui permet facilement de revenir à l’état précédent et par la faible quantité de logiciels installés dans le cœur du système.
Les autres opérations ne sont pas considérées à ce stade car trop risquées pour être confiées à un simple utilisateur. Pour certaines opérations le mot de passe administrateur sera systématiquement demandé telles que l’installation d’un nouveau paquet local, la mise à niveau complet du système (qui consiste en une opération de rebase avec une autre branche de travail), ou changer les paramètres du noyau. Pour d’autres comme l’installation d’un paquet provenant d’un dépôt, la mise à jour, le retour dans un état précédent ou l’annulation d’une commande peut se faire sans demander systématiquement le mot de passe, comme lors de l’usage de commandes via sudo si les opérations ne sont pas trop espacées.
Mise à disposition des images Spin KDE Plasma Mobile et Fedora Kinoite Mobile. L’objectif est de fournir une image native avec cet environnement qui fonctionne aussi bien pour téléphone que pour les tablettes ou petits ordinateurs portables 2-1 avec possibilité de détacher l’écran tactile du clavier.
De même le gestionnaire de fenêtres en mode pavant Miracle exploitant Wayland est proposé dans Fedora et bénéficie de son propre Spin. Cette interface moderne prend en charge aussi les fenêtres flottantes, prend en charge les dernières montures de Wayland tout en permettant l’usage des pilotes propriétaires de Nvidia. Il consomme également peu de ressources ce qui le rend intéressant dans l’usage de machines peu performantes ou anciennes tout en exploitant une pile graphique très moderne et flexible.
L’installation de Fedora Workstation se fera avec le protocole d’affichage Wayland uniquement, les sessions GNOME X11 restent disponibles et installables après. Cela suit l’effort entrepris depuis longtemps de faire de Wayland le protocole d’affichage par défaut de Fedora et par l’abandon progressif de X11 par GNOME également. L’état actuel du système permet de franchir ce cap par défaut ce qui allège également un peu le média d’installation. Cependant pour ceux qui veulent toujours utiliser GNOME avec X11 après l’installation pour différentes raisons, il reste possible d’installer les paquets gnome-session-xsession et gnome-classic-session-xsession depuis les dépôts officiels.
Gestion du matériel
L’installation du pilote propriétaire de Nvidia via GNOME Logiciels est compatible avec les systèmes utilisant l’option Secure Boot. Ce mode de sécurité s’assure que tous les éléments de la chaine de démarrage de la machine sont signés avec une des clés cryptographiques autorisées. L’objectif est d’éviter qu’une tierce personne puisse modifier un de ces composants dans le dos d’un utilisateur afin de réaliser une attaque plus tard. Le chargeur de démarrage GRUB, le noyau Linux et ses pilotes sont évidemment concernés, et installer le pilote propriétaire de Nvidia qui n’est pas signé pouvait rendre la machine impossible à démarrer.
Même si Fedora ne fournit pas ce pilote, car il est non libre, l’objectif reste d’avoir un système fonctionnel et simple à utiliser. Dans ce contexte, GNOME logiciels permet d’outre passer cette limitation en utilisant l’outil mokutil pour auto signer le pilote Nvidia. L’utilisateur devra saisir un mot de passe à l’installation du paquet, et au redémarrage suivant cet outil sera affiché pour confirmer la clé de sécurité et ainsi autoriser le chargement du dit pilote sans encombre.
Prise en charge des caméras MIPI pour les systèmes utilisant Intel IPU6 qui concerne de nombreux ordinateurs portables actuels. En effet, de nombreux modèles utilisent le bus MIPI CSI2 au lieu du traditionnel USB UVC qui était la norme jusqu’à présent. En effet ce protocole permet des bandes passantes plus élevées, en consommant moins d’énergie et plus facile à intégrer. Sauf que la prise en charge de ce bus n’était pas pleinement gérée, car les images envoyées sont un peu brutes et nécessitent des traitements notamment concernant la balance des blancs ou le dématriçage de l’image ou le contrôle pour l’exposition et le gain. Cela est complexe, car chaque caméra a ses propres caractéristiques qui nécessitent une approche au cas par cas en espace utilisateur. Un travail d’intégration a été fait entre le noyau Linux, libcamera, pipewire et Firefox pour rendre cela possible. Le noyau Linux fourni l’API de base et un pilote pour chaque type de modèles, avec un pilote commun pour la prise en charge du protocole en lui-même. Le flux vidéo est récupéré par libcamera qui applique des traitements tels que le dématriçage en prenant en compte le modèle considéré, qui envoie le flux vidéo obtenu par pipewire vers le navigateur Firefox.
L’installateur Anaconda prend en charge le chiffrement matériel des disques via le standard TCG OPAL2 disponible sur certains péripériques SATA ou NVMe, mais cela nécessite de passer via un fichier kickstart pour personnaliser l’installation. L’outil cryptsetup n’a pris en charge ce standard que très récemment, l’objectif est de fournir les arguments --hw-opal-only ou --hw-opal à cet utilitaire dans le fichier kickstart. Le premier argument n’active que le chiffrement matériel, ce qui est recommandé uniquement pour des périphériques où l’usage du CPU pour cette tâche nuirait grandement aux performances, alors que le second utilise un chiffrement matériel et logiciel. Il n’est pas prévu de fournir cette fonctionnalité par défaut et restera pendant un moment une option pour les utilisateurs avancés, car la sécurité de l’ensemble dépend de la qualité des firmwares de ces périphériques de stockage et qui doivent être maintenus à jour dans le temps ce qui n’est pas garanti.
Utilisation par défaut de l’outil tuned au lieu de power-profiles-daemon pour la gestion de l’énergie de la machine. C’est l’outil qui permet notamment de passer du mode économie d’énergie à performance pour moduler la puissance du CPU en fonction de la consommation d’énergie souhaitée, ce qui est très appréciable sur les ordinateurs portables en particulier. Cependant power-profiles-daemon est très simple, en dehors de ces modes très génériques et d’appliquer cela sur les CPU ou les plateformes matérielles supportées, il ne permettait une configuration plus fine ou l’ajout de modes personnalisées. Les utilisateurs avancés étaient contraints d’installer un utilitaire additionnel comme tuned pour cela. Il a été ajouté un paquet tuned-ppd qui fourni une API DBus compatible avec l’interface de power-profiles-daemon, ainsi les applications telles que le centre de configuration de GNOME, Plasma ou Budgie peuvent s’en servir directement à la place sans régression, tout en permettant aux utilisateurs avancés d’aller plus loin s’ils le souhaitent en modifiant le contenu de /etc/tuned/ppd.conf comme en changeant les réglages périphérique par périphérique.
Mise à jour de ROCm 6.2 pour améliorer la prise en charge de l’IA et le calcul haute performance pour les cartes graphiques ou accélérateurs d’AMD. Il fournit entre autres des nouveaux composants tels que Omniperf pour l’étude et l’analyse de performance, Omnitrace pour tracer l’exécution des fonctions sur le CPU ou le GPU, rocPyDecode comme implémentation de l’API rocDecode en Python pour l’analyse des données de profilage faits avec cet outil en C ou C++ ou ROCprofiler-SDK pour identifier les points bloquants de performance. Il prend en charge également les dernières versions des outils PyTorch et TensorFlow.
L’outil de développement et de débogage des tables ACPI nommé acpica-tools ne prend plus en charge les architectures gros boutistes tels que s390x. En effet, ce standard qui est conçu pour les machines petits boutistes n’a pas beaucoup de sens pour cette architecture, les paquets qui en avaient besoin pour s390x ont de moins en moins cette dépendance et comme l’usage de cette architecture reste faible surtout pour cet usage, il a été décidé de retirer la prise en charge de cette spécificité. 49 correctifs sur 69 concernant ce paquet sont liés à cette prise en charge, car le projet n’a jamais voulu les adopter par manque d’intérêt, ce qui impliquait beaucoup de test et de développement ralentissant la fréquence des mises à jour du paquet. Ces correctifs sont maintenant supprimés.
PHP ne prend plus en charge les processeurs x86 32 bits. Il n’y avait déjà plus de paquets PHP 32 bits dans les dépôts, mais PHP était toujours compilé pour permettre à d’autres dépendances de l’être pour cette architecture. Des restrictions ont été ajoutées à ces dépendances pour que cela ne soit plus bloquant. PHP était souvent utilisé dans le cadre de tests ou pour gérer des plugins ou extensions qui pouvaient être désactivées. L’architecture x86 32 bits n’est pour rappel plus pris en charge par Fedora depuis quelques années maintenant, ces paquets ne sont utilisables que sur des machines x86 64 bits pour des raisons de compatibilité. Ce nettoyage permet en contrepartie un gain de temps machine et de développeurs, car il n’y a plus à gérer ce cas de figure.
Internationalisation
Le gestionnaire d’entrées IBus par défaut pour la langue traditionnelle chinoise de Taiwan passe de ibus-libzhuyin à ibus-chewing. En effet la bibliothèque chewing sous-jacent semble avoir une communauté dynamique qui fournit une bonne maintenance contrairement à libzhuyin qui n’est d’ailleurs pas maintenu en ce moment par un locuteur de cette langue ce qui pose quelques difficultés. Le code semble également mieux organisé et plus maintenable.
Administration système
Le gestionnaire de paquet dnf est mis à jour vers sa 5ᵉ version. Cette version écrite en C++ au lieu de Python est bien plus rapide à l’usage et consomme moins d’espace disque et requiert moins de dépendances pour tourner, l’ensemble est 60% plus léger sur le disque. Par ailleurs dnf5daemon remplace PackageKit comme couche de compatibilité pour dnf dans GNOME Logiciels, ce qui permet notamment le partage des caches entre l’interface console et l’interface graphique évitant un gaspillage d’espace disque et de bande passante. Niveau performance, certaines opérations sont maintenant parallélisées comme le téléchargement et le traitement des données des dépôts qui doit être jusqu’à deux fois plus rapide. Les plugins sont également mieux intégrés ce qui en simplifie leur installation et leur maintenance. Cependant certains plugins n’ont pas été encore portés, vous pouvez suivre l’avancement pour ceux qui manquent à l’appel. Mais cela ne devrait concerner que peu d’utilisateurs. Certaines options de la ligne de commande n’existent plus par ailleurs, cela vous sera rappelé si vous les invoquiez. L’historique des précédentes transactions de paquets comme les mises à jour ou installations ne sont pas compatibles entre l’ancienne et la nouvelle version, vous ne pourrez donc pas voir vos anciennes transactions pour les annuler par exemple.
Tandis que la commande rpm utilise la version 4.20. Cette version permet de lister ou de supprimer les clés pour signer les paquets via la commande rpmkeys alors que l’outil rpmsign permet de signer les paquets avec l’algorithme ECDSA. La commande rpm elle-même permet d’afficher une sortie en format JSON, en plus du format XML déjà pris en charge depuis longtemps. Un nouveau plugin rpm-plugin-unshare apparaît pour empêcher à des scripts d’installation de faire certaines opérations sur le système de fichiers ou via le réseau pour des raisons de sécurité. Côté création de paquet, l’introduction de la directive BuildSystem est sans doute la plus importante pour permettre de définir de manière unique et générique la création de paquets basés sur des outils communs tels que autotools ou cmake. L’empaqueteur n’aurait pas besoin de rappeler pour ces outils courants chaque étape pour la création du paquet, sauf en cas de particularité, ce qui permet une meilleure maintenance et cohérence au sein de la distribution par exemple.
Les systèmes Fedora atomiques de bureau et Fedora IoT disposent de bootupd pour la mise à jour du chargeur de démarrage. La mise à jour du chargeur de démarrage au sein d’un système atomique n’est pas trivial, car ce n’est pas une opération facile à fiabiliser. Par conséquent rpm-ostree ne prenait pas cela en charge, et c’est pourquoi bootupd a été créé et est maintenant intégré dans ces versions. Il était déjà présent depuis quelque temps sur la version CoreOS ce qui a déjà donné un retour d’expérience en conditions réelles. Il peut prendre en charge les systèmes UEFI et BIOS, mais la mise à jour reste une étape manuelle pour être automatisée dans le futur, notamment quand le composant shim sera à jour pour rendre la mise à jour moins risquée sur les systèmes UEFI si la mise à jour est coupée au milieu de l’opération comme lors d’une coupure de courant ou lors d’un plantage. Il permet également de pouvoir bloquer l’usage de versions du chargeur de démarrage plus anciens ayant des failles connues, par l’usage de Secure Boot dbx et le paquet ostree-grub2 pourra être progressivement retiré, ce qui notamment mettra un terme au bogue où chaque déploiement est affiché deux fois dans l’interface de sélection de GRUB et devrait réduire le risque d’avoir certains problèmes lors de la mise à jour du système.
Les images atomiques de Fedora proposent les outils dnf et bootc, ce premier est utilisable dans un contexte de développement pour l’instant mais le second peut commencer à servir à déployer des images du système qui sont bootables. Plus tard il est prévu que dnf puisse remplacer rpm-ostree pour certaines actions. En attendant, en cas d’usage de dnf sur de tels systèmes, le message d’erreur sera plus explicite concernant les outils à employer pour réaliser ces actions. L’objectif est de fournir aux administrateurs systèmes des outils plus familiers pour ces différentes actions tout en ayant un outil clairement identifié pour chaque type de tâches.
Introduction de l’outil fedora-repoquery pour faire des requêtes sur les dépôts comme savoir la version exacte d’un paquet spécifique dans une autre version de Fedora, la date de mise à jour d’un dépôt, ou connaître les paquets qui dépendent d’un paquet spécifique (dépendance inverse donc), etc. Il fonctionne par-dessus dnf concernant cette fonction mais permet de facilement obtenir des informations depuis les dépôts Fedora, CentOS ou EPEL.
La bibliothèque de sécurité OpenSSL n’accepte plus les signatures cryptographiques avec l’algorithme SHA-1. Cet algorithme n’est plus considéré comme sûr, car il devient de plus en plus facile de générer des collisions à la demande. Si vous souhaitez les autoriser à nouveau pour des raisons légitimes, malgré le risque de sécurité, cela reste possible de le faire via la commande
# update-crypto-policies --set FEDORA40Commande qui devrait être prise en charge pendant quelques versions encore.
Le gestionnaire de réseaux NetworkManager ne prend plus en charge la configuration dans le format ifcfg qui était déjà désuet depuis des années. Cela fait suite aux tentatives progressives d’utiliser massivement le format keyfile. Fedora Linux 33 en l’utilisant comme format par défaut pour les nouveaux profils de connexions, tandis que Fedora Linux 36 a poussé la prise en charge de l’ancien format dans un paquet dédié non installé par défaut nommé NetworkManager-initscripts-ifcfg-rh et enfin Fedora Linux 39 a entamé la conversion automatique vers le nouveau format. Et depuis longtemps NetworkManager ne fait que maintenir ce format, de nombreuses options ou types de connexions n’étant de fait pas possibles avec l’ancien format. Cela permet de préparer la suppression future de la prise en charge de ce format de fichier de NetworkManager lui-même.
Dans la même veine, le paquet network-scripts a été retiré, mettant fin à la gestion du réseau via les scripts ifup et ifdown. Depuis 2018 ces outils sont considérés comme obsolète et soumis à une suppression planifiée future. D’ailleurs le projet officiel ne fait plus une maintenance très active de ces outils.
Les interfaces réseaux pour les éditions Cloud vont utiliser les nouveaux noms par défaut (par exemple enp2s0f0) comme adoptés par les autres éditions il y a des années au lieu de conserver les noms traditionnels (tels que eth0). Cela signifie que le noyau ne recevra plus pour ces systèmes le paramètre net.ifnames=0 pour maintenir cet ancien comportement. Le reste de l’écosystème avait adopté la nouvelle nomenclature avec Fedora… 15 en 2011 ! Ce retard est attribuable à certains problèmes avec certains outils tels que cloud-init avec cette convention de nommage qui ont été résolus à la fin des années 2010 seulement. Ainsi les périphériques auront maintenant une correspondance physique, leur rôle devrait être plus facilement identifiable et limiter le risque de problèmes suite à des changements dynamiques des interfaces.
Le gestionnaire de virtualisation libvirt utilise maintenant par défaut le pare-feu nftables au lieu de iptables pour son interface réseau vibr0. En effet Fedora utilise par défaut nftables maintenant et par ailleurs utiliser iptables signifiait créer des règles nftables sous le capot. Cette transition est faite pour améliorer les performances et réduire le risque d’une suppression accidentelle de règles par une application tierce, car tout sera mis dans les règles associées à la table libvirt_network. iptables sera cependant utilisé si nftables n’est pas présent dans le système et le comportement peut être changé dans le fichier de configuration /etc/libvirt/network.conf.
L’outil Netavark pour gérer la pile réseau des conteneurs, notamment avec podman, utilise également par défaut le pare-feu nftables au lieu de iptables. Les avantages du changement sont assez similaires à ce qui est expliqué au point précédent, les règles associées à l’outil seront mises dans la table dédiée netavark. La possibilité d’envoyer les règles par lot peut améliorer de manière légère le temps de démarrage des conteneurs par ailleurs.
Le gestionnaire de conteneurs Kubernetes a des nouveaux paquets versionnés, permettant d’avoir plusieurs versions en parallèle. Ici les versions 1.29, 1.30 et 1.31 sont proposées avec des noms comme kubernetes1.31. Cela devenait nécessaire car Kubernetes maintient 3 versions sur une période de 4 mois par version seulement ce qui rend nécessaire un tel montage. Cela permet aussi de découpler la version de Kubernetes avec la version de Fedora Linux ce qui facilite la gestion pour les administrateurs.
L’implémentation des interfaces de Kubernetes fait par l’OCI a ses propres paquets cri-o et cri-tools qui sont également versionnés pour pouvoir suivre les versions de Kubernetes.
Développement
Mise à jour de la suite de compilation GNU : binutils 2.42, glibc 2.40 et gdb 15.
Pour la suite d’outils binutils, cela se concentre surtout sur la prise en charge plus étendue des instructions des architectures Aarch64, RISC-V et x86_64. Il gère notamment les registres supplémentaires et les instructions associées proposés par l’évolution de l’architecture x86 avec Intel APX. L’assembleur BPF améliore son interopérabilité avec les outils de LLVM en suivant les mêmes conventions.
La bibliothèque standard C commence une prise en charge expérimentale de la norme C23. La capacité de renforcer la sûreté des programmes compilés avec le compilateur Clang a été aussi améliorée pour se rapprocher de ce qui est possible de faire avec le compilateur GCC. De nombreuses fonctions mathématiques ont une version vectorisée pour l’architecture Aarch64 ce qui peut améliorer les performances pour cette architecture.
Pour finir le débogueur améliore significativement son API Python pour faciliter sa manipulation à travers un programme ou script écrit dans ce langage. La prise en charge du protocole Debugger Adapter Protocol s’améliore encore pour faciliter sa manipulation par divers IDE qui s’en servent pour l’intégrer. Les informations de débogage du programme cible au format DWARF sont lues dans un fil d’exécution dédié pour améliorer le temps de chargement.
Mise à niveau de la suite de compilateurs LLVM vers la version 19. Les paquets versionnés des versions précédentes sont toujours disponibles pour ceux qui ont besoin de la compatibilité avec les anciennes bibliothèques. Les paquets clang, compiler-rt, lld et libomp sont maintenant générés à partir du fichier de spécification du paquet llvm ce qui n’était pas le cas avant. Cela permet entre autres de simplifier leur maintenance mais aussi d’appliquer une optimisation Profile-Guided Optimizations sur ces binaires pour améliorer les performances. Les paquets Fedora compilés avec Clang bénéficient aussi de la compilation avec l’option -ffat-lto pour avoir des bibliothèques ayant le bitcode LTO en plus du binaire au format ELF, ce qui permet de réduire le temps de l’édition de lien quand ces bibliothèques sont impliquées. Le tout sans recourir à des macros pour obtenir le résultat après la compilation des paquets et sans renoncer à la compatibilité pour les logiciels non compilés avec ce mode activé.
Retrait de Python 2.7 dans les dépôts, seule la branche 3 est maintenue dorénavant. Enfin, cela est vrai pour l’implémentation de référence, il reste possible de le faire via PyPy qui fourni toujours un support de la version 2.7 via le paquet pypy. Pour rappel, Python 2.7 n’est plus maintenu depuis début 2020, mais ce maintien était nécessaire pour certains paquets qui n’avaient toujours pas terminé leur portage, en particulier le logiciel GIMP, cas abordé plus haut. Les autres paquets concernés n’étaient plus vraiment maintenus de fait et ont été retirés. Cela devenait nécessaire car avec la fin de support de RHEL 7 prochainement, plus aucun correctif pour Python 2 ne sera développé à l’avenir rendant la situation plus critique encore.
D’ailleurs Python bénéficie de la version 3.13. Cette version fournit un nouvel interpréteur interactif avec la coloration activée par défaut pour le prompt ou les erreurs. Il donne la possibilité d’avoir de l’édition multi-lignes qui est préservée dans l’historique. Les touches F1, F2 et F3 donnent respectivement l’accès à une aide interactive, à la navigation de l’historique de l’édition et à un mode de copie plus simple pour copier-coller de gros blocs de code. Les messages d’erreur sont également plus clairs.
En dehors de cela, Python dispose du tant attendu mode sans verrou global nommé GIL ce qui permet d’améliorer les performances et de faire de réels fils d’exécution parallèle dans un programme. Mais ce mode étant expérimental, il faut installer le paquet python3.13-freethreading et exécuter Python avec la commande python3.13t pour en profiter.
Le compilateur juste à temps n’est quant à lui pas fourni d’une façon ou d’une autre, cette fonctionnalité étant aussi expérimentale.
Python est aussi compilé avec l’optimisation -O3 activée, en ligne avec la manière de faire par le projet officiel et améliorant les performances. Selon le test pyperformance le gain de performance est en moyenne 1,04 fois plus rapide rien qu’avec cette option. Auparavant Python était compilé avec l’optimisation -O2 qui est moins agressive, cependant la nouvelle option augmente la taille des binaires concernés d’environ 1.2% (soit 489 kio).
Le framework d’écriture de tests en Python, Pytest se teste avec sa version 8. Cette version n’est pas compatible avec la version précédente, de nombreux éléments obsolètes sont maintenant traités comme des erreurs, et de même la façon dont les tests sont récupérés dans l’arborescence d’un code source a été modifiée ce qui peut poser différents problèmes.
En termes d’amélioration, il propose un meilleur affichage des diff en cas d’erreur lors de l’exécution d’un test, le rendant plus lisible et plus proche du visuel d’un différentiel généré à partir de la commande diff.
Mise à jour du langage Go vers la version 1.23. Cette version apporte la télémétrie pour collecter des données sur l’usage de la chaine de compilation Go aux développeurs du projet, par défaut dans Fedora la télémétrie est activée mais reste uniquement sur votre machine, rien n’est envoyé aux serveurs du projet. Ce comportement peut être changé dans les options.
Autrement, quand le temps de compilation est amélioré lorsqu’un profil d’optimisation est utilisé, passant d’un délai supplémentaire pouvant aller jusqu’au double du temps de compilation normal à maximum 10% supplémentaire maintenant. Les applications Go ont un usage de la pile qui est légèrement réduit tandis que pour l’architecture x86_64, au détriment d’une légère augmentation de la taille du binaire, les boucles peuvent avoir une amélioration de performances d’environ 1-1,5%.
Mise à jour dans l’écosystème Haskell GHC 9.6 et Stackage LTS 22. Le compilateur en lui-même propose de compiler le code pour être exécuté en tant que programme WebAssembly ou JavaScript. Les deux sont cependant considérés comme en développement et peuvent être sujets à des bogues. L’ensemble des messages d’erreur ont maintenant un code unique, permettant de simplifier la recherche d’une explication et d’une solution concernant celui-ci.
Le langage Perl passe à la version 5.40. Un nouveau mot clé __CLASS__ donne la classe d’exécution réelle dont l’instance d’objet est membre, ce qui est utile pour les constructeurs de classes enfants, car l’accès à $self n’étant pas autorisé dans ce contexte. Un autre mot clé :reader est proposé, ajouté à un membre de classe il permet de définir automatiquement une fonction du même nom que le membre, qui renvoie cette valeur. Un nouvel opérateur ^^ est disponible, étant l’équivalent de && et || mais pour la fonction logique ou exclusif.
Node.js 22 devient la version de référence, tandis que la version 20 et 18 restent disponibles en parallèle. Cette version propose entre autres un client Websocket natif sans dépendances additionnelles, une mise à jour habituelle du moteur JavaScript V8 vers la version 12.4 qui propose notamment un ramasse-miette WebAssembly. Les flux de données passent par défaut d’un buffer de 16 kib à 64 kib ce qui augmente les performances au détriment de la consommation de mémoire vive. Enfin le compilateur JIT Maglev fourni par le moteur V8 est activé par défaut, qui améliore les performances en particulier pour les petits programmes exécutés en ligne de commande.
Pour des raisons de changement de licence, le gestionnaire de bases de données clé-valeur Redis est remplacé par Valkey. En effet Redis a adopté la licence RASLv2/SSPL en remplacement de la licence BSD qui n’est pas une licence libre ce qui est en conflit avec les règles de Fedora concernant les licences des logiciels proposés dans ses dépôts. Valkey est un fork de Redis qui réutilise la même licence originelle. À ce jour pas d’incompatibilité est à prévoir pour les utilisateurs de ce logiciel, mais un paquet valkey-compat est proposé pour migrer la configuration et les données depuis Redis. Le changement est effectué automatiquement lors de la mise à niveau de Fedora pour ces utilisateurs.
La bibliothèque Python d’apprentissage profond Pytorch est éclairée avec sa version 2.4. Le changement majeur de cette version est la prise en charge de ROCm pour tirer parti de l’accélération matérielle de l’intelligence artificielle proposée par AMD. Il y a également une amélioration de performances pour ceux utilisant GenAI sur un CPU ou encore exécutant sur des processeurs AWS Graviton3 à base d’architecture Aarch64.
L’API engine de la bibliothèque OpenSSL est dépréciée car non maintenue tout en gardant une ABI stable. En effet cette API n’est pas conforme aux standards FIPS et n’est plus maintenue depuis la version 3.0 d’OpenSSL. Aucun nouveau paquet ne peut dépendre de celui-ci jusqu’à sa suppression définitive pour simplifier la transition. Le code lié à cette API est fourni par le paquet indépendant openssl-engine-devel pour ceux qui en ont besoin. L’objectif à terme est de simplifier la maintenance tout en réduisant la surface d’attaque.
Projet Fedora
L’édition de Fedora KDE pour l’architecture AArch64 est maintenant bloquante pour les sorties d’une nouvelle version. L’édition doit être suffisamment stable pour qu’une nouvelle version de Fedora Linux voit le jour. Cela était déjà le cas pour Fedora Workstation de cette architecture et pour Fedora KDE pour l’architecture x86_64. L’objectif est de garantir une certaine fiabilité pour ses utilisateurs.
Phase 4 de l’usage généralisé des noms abrégés de licence provenant du projet SPDX pour la licence des paquets plutôt que des noms du projet Fedora. Cela devait être l’ultime phase mais quelques contretemps repoussent à nouveau l’échéance. Cette étape et la suivante sont en fait la conversion massive des paquets vers le nouveau format, comme rapporté par ce document, la progression reste rapide et près de 98,5% des licences mentionnées dans les paquets sont déjà converties.
Les bibliothèques Java n’ont plus une dépendance explicite envers le runtime de Java pour simplifier la maintenance, rien ne change concernant les applications. L’objectif est d’éviter de spécifier une version spécifique de la version de Java pour du code qui finalement n’est pas exécuté directement, la dépendance revenant plutôt aux applications à ce sujet. Cela peut faciliter les utilisateurs ou mainteneurs d’utiliser différents JDK pour ces bibliothèques. Cela simplifie considérablement aussi la maintenance des paquets Java dans Fedora, car il n’est plus nécessaire de mettre à jour la valeur de la version du JRE requis.
Le paquet systemtap-sdt-devel n’a plus l’outil dtrace qui a été mis dans le paquet systemtap-sdt-dtrace. L’objectif est de supprimer la dépendance Python dans ce paquet qui est utilisé pour l’image de compilation des paquets de Fedora. Plusieurs centaines de paquets peuvent ainsi être générés plus rapidement par cette dépendance en moins.
Ajout d’une tâche de nettoyage lors de la génération des paquets RPM pour améliorer la reproductibilité des paquets. Depuis quelques années Fedora fait un effort pour rendre la conception de ses paquets reproductibles. L’objectif est qu’un utilisateur devrait être en mesure de recompiler un paquet de son côté avec le fichier spec RPM + sources additionnelles de Fedora et obtenir exactement le même paquet, au bit près, garantissant que le paquet a été généré avec ces éléments sans altérations malveillantes. Cela peut également faciliter le développement, car il rend la comparaison entre versions d’un paquet plus facile à analyser car seuls les changements dans le code sont différents et non des éléments annexes.
Un effort a été fait récemment qui repose notamment sur l’usage du programme add-determinism pour retirer du code source des éléments non déterministes comme la date de compilation. Ce programme est appelé à la fin de la génération du paquet. Fedora n’a pas réutilisé le travail de Debian à base du script strip-nondeterminism qui est un script Perl qui ajouterait une dépendance relativement lourde pour générer tous les paquets de Fedora.
Mise à jour de createrepo_c à la version 1.0 qui gère la génération des métadonnées des dépôts de Fedora. Les versions stables et Rawhide de Fedora vont partager maintenant la même configuration des métadonnées, ce qui rendra la maintenance côté infrastructure plus simple et cohérente. Toutes les métadonnées sont compressées, avant seulement les métadonnées primaires l’étaient pour les versions stables de Fedora par exemple. Certaines données ou métadonnées étaient compressées suivant différents algorithmes :
- gzip pour les métadonnées des dépôts ;
- XZ pour les données XML concernant les mises à jour dans les dépôts concernés.
Maintenant tout cela utilise l’algorithme zstd ce qui devrait améliorer un peu la bande passante et la consommation d’espace de stockage. Il n’est pas exclu de basculer à l’avenir sur zlib-ng dans ce but.
Les fichiers sqlite renseignant la composition des dépôts n’étaient utiles que pour le gestionnaire de paquets YUM, avec son remplacement par DNF depuis quelques années il est inutile de les générer ce qui avait un coût en espace de stockage.
La communauté francophone
L’association
Borsalinux-fr est l’association qui gère la promotion de Fedora dans l’espace francophone. Nous constatons depuis quelques années une baisse progressive des membres à jour de cotisation et de volontaires pour prendre en main les activités dévolues à l’association.
Nous lançons donc un appel à nous rejoindre afin de nous aider.
L’association est en effet propriétaire du site officiel de la communauté francophone de Fedora, organise des évènements promotionnels comme les Rencontres Fedora régulièrement et participe à l’ensemble des évènements majeurs concernant le libre à travers la France principalement.
Si vous aimez Fedora, et que vous souhaitez que notre action perdure, vous pouvez :
- adhérer à l’association : les cotisations nous aident à produire des goodies, à nous déplacer pour les évènements, à payer le matériel ;
- participer sur le forum, les listes de diffusion, à la réfection de la documentation, représenter l’association sur différents évènements francophones ;
- concevoir des goodies ;
- organiser des évènements type Rencontres Fedora dans votre ville.
Nous serions ravis de vous accueillir et de vous aider dans vos démarches. Toute contribution, même minime, est appréciée.
Si vous souhaitez avoir un aperçu de notre activité, vous pouvez participer à nos réunions mensuelles chaque premier lundi soir du mois à 20h30 (heure de Paris). Pour plus de convivialité, nous l’avons mis en place en visioconférence sur Jitsi.
La documentation
Depuis juin 2017, un grand travail de nettoyage a été entrepris sur la documentation francophone de Fedora, pour rattraper les 5 années de retard accumulées sur le sujet.
Le moins que l’on puisse dire, c’est que le travail abattu est important : près de 90 articles corrigés et remis au goût du jour.
Un grand merci à Charles-Antoine Couret, Nicolas Berrehouc, Édouard Duliège et les autres contributeurs et relecteurs pour leurs contributions.
La synchronisation du travail se passe sur le forum.
Si vous avez des idées d’articles ou de corrections à effectuer, que vous avez une compétence technique à retransmettre, n’hésitez pas à participer.
Comment se procurer Fedora Linux 41 ?
Si vous avez déjà Fedora Linux 40 ou 39 sur votre machine, vous pouvez faire une mise à niveau vers Fedora Linux 41. Cela consiste en une grosse mise à jour, vos applications et données sont préservées.
Autrement, pas de panique, vous pouvez télécharger Fedora Linux avant de procéder à son installation. La procédure ne prend que quelques minutes.
Nous vous recommandons dans les deux cas de procéder à une sauvegarde de vos données au préalable.
De plus, pour éviter les mauvaises surprises, nous vous recommandons aussi de lire au préalable les bogues importants connus à ce jour pour Fedora Linux 41.
Commentaires : voir le flux Atom ouvrir dans le navigateur
