❌

Vue lecture

Il y a de nouveaux articles disponibles, cliquez pour rafraĂźchir la page.

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.

Bureau GNOME

Sommaire

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"]'

Couleur d’accentuation dans GNOME

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.

Prévisualisation du clavier dans GNOME

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.

Nouvelles options de focus dans GNOME

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 FEDORA40

Commande 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.

GIMP 3

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

Logo de Boorsalinux-fr

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 ?

Logo de Fedora Media Writer

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

Vous pouvez tester Fedora Linux 41 Beta !

En ce mardi 17 septembre, la communauté du Projet Fedora sera ravie d'apprendre la disponibilité de la version Beta de Fedora Linux 41.

MalgrĂ© les risques concernant la stabilitĂ© d’une version Beta, il est important de la tester ! En rapportant les bogues maintenant, vous dĂ©couvrirez les nouveautĂ©s avant tout le monde, tout en amĂ©liorant la qualitĂ© de Fedora Linux 41 et rĂ©duisant du mĂȘme coup le risque de retard. Les versions en dĂ©veloppement manquent de testeurs et de retours pour mener Ă  bien leurs buts.

La version finale est pour le moment fixée pour le 22 octobre ou 5 novembre.

Sommaire

Expérience utilisateur

  • Passage Ă  GNOME 47 ;
  • L'environnement de bureau lĂ©ger LXQt passe Ă  la version 2.0 ;
  • L'Ă©diteur d'image GIMP utilise la branche de dĂ©veloppement qui deviendra la version 3 ;
  • Le gestionnaire de listes de tĂąches Taskwarrior Ă©volue Ă  la version 3 ;
  • 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 passer d'une version Fedora Linux Silverblue 40 Ă  Fedora Linux Silverblue 41 ;
  • Mise Ă  disposition des images Spin KDE Plasma Mobile et Fedora Kinoite Mobile ;
  • De mĂȘme le gestionnaire de fenĂȘtres Miracle exploitant Wayland est proposĂ© dans Fedora et bĂ©nĂ©ficie de son propre Spin ;
  • L'installation de Fedora Workstation se fera avec le protocole d'affichage Wayland uniquement, X11 reste disponible et installable aprĂšs.

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 ;
  • Prise en charge des camĂ©ras MIPI pour les systĂšmes utilisant Intel IPU6 qui concerne de nombreux ordinateurs portables actuels ;
  • L'installateur Anaconda prend en charge le chiffrement matĂ©riel des disques via le standard TCG OPAL2, mais cela nĂ©cessite de passer via un fichier kickstart pour personnaliser l'installation ;
  • Utilisation par dĂ©faut de l'outil tuned au lieu de power-profiles-daemon pour la gestion de l'Ă©nergie de la machine ;
  • 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 ;
  • L'outil de dĂ©bogue des tables ACPI nommĂ© acpica-tools ne prend plus en charge les architectures gros boutistes tels que s390x ;
  • PHP ne prend plus en charge les processeurs x86 32 bits.

Internationalisation

  • Le gestionnaire d'entrĂ©es IBus par dĂ©faut pour la langue traditionnelle chinoise de Taiwan passe de ibus-libzhuyin Ă  ibus-chewing.

Administration systĂšme

  • Le gestionnaire de paquet dnf est mis Ă  jour vers sa 5e version ;
  • Tandis que la commande rpm utilise la version 4.20 ;
  • Les systĂšmes Fedora atomiques de bureau et Fedora IoT disposent de bootupd pour la mise Ă  jour du chargeur de dĂ©marrage ;
  • 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 ;
  • La bibliothĂšque de sĂ©curitĂ© OpenSSL n'accepte plus les signatures cryptographiques avec l'algorithme SHA-1 ;
  • Stabilisation de la fonctionnalitĂ© de Fedora Linux 36 oĂč ostree prenait en charge les formats OCI/Docker pour le transport et le mĂ©canisme de dĂ©ploiement des conteneurs ;
  • 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 ;
  • 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 ;
  • Les interfaces rĂ©seaux pour les Ă©ditions Cloud vont utiliser les nouveaux noms par dĂ©faut comme adoptĂ©s par les autres Ă©ditions il y a des annĂ©es au lieu de conserver les noms traditionnels tels que eth0 ;
  • Le gestionnaire de virtualisation libvirt utilise maintenant par dĂ©faut le pare-feu nftables au lieu de iptables pour son interface rĂ©seau vibr0 ;
  • 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 unitĂ©s systĂšme de systemd vont utiliser par dĂ©faut beaucoup d'options pour amĂ©liorer la sĂ©curitĂ© des services ;
  • 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. ;
  • 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 ;
  • 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 ;
  • Mise Ă  niveau de la suite de compilateurs LLVM vers la version 19 ;
  • Retrait de Python 2.7 dans les dĂ©pĂŽts, seule la branche 3 est maintenue dorĂ©navant ;
  • D'ailleurs Python bĂ©nĂ©ficie de la version 3.13 ;
  • 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 ;
  • Le framework d'Ă©criture de tests en Python, Pytest se teste avec sa version 8 ;
  • Mise Ă  jour du langage Go vers la version 1.23 ;
  • Mise Ă  jour dans l'Ă©cosystĂšme Haskell GHC 9.6 et Stackage LTS 22 ;
  • Le langage Perl passe Ă  la version 5.40 ;
  • Node.js 22 devient la version de rĂ©fĂ©rence, tandis que la version 20 et 18 restent disponibles en parallĂšle ;
  • Pour des raisons de changement de licence, le gestionnaire de bases de donnĂ©es clĂ©-valeur Redis est remplacĂ© par Valkey ;
  • La bibliothĂšque Python d'apprentissage profond Pytorch est Ă©clairĂ©e avec sa version 2.4 ;
  • L'API engine de la bibliothĂšque OpenSSL est dĂ©sactivĂ©e car non maintenue tout en gardant une ABI stable.

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 ;
  • Ultime 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 ;
  • 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 ;
  • Le paquet systemtap-sdt-devel n'a plus l'outil dtrace qui a Ă©tĂ© mis dans le paquet systemtap-sdt-dtrace ;
  • Ajout d'une tĂąche de nettoyage lors de la gĂ©nĂ©ration des paquets RPM pour amĂ©liorer la reproductibilitĂ© des paquets ;
  • Changement dans les mĂ©tadonnĂ©es des dĂ©pĂŽts de Fedora, avec l'usage de l'algorithme de compression zstd et l'abandon des bases de donnĂ©es sqlite pour diminuer la taille des donnĂ©es Ă  tĂ©lĂ©charger ou Ă  stocker.

Tester

Durant le dĂ©veloppement d'une nouvelle version de Fedora Linux, comme cette version Beta, quasiment chaque semaine le projet propose des journĂ©es de tests. Le but est de tester pendant une journĂ©e une fonctionnalitĂ© prĂ©cise comme le noyau, Fedora Silverblue, la mise Ă  niveau, GNOME, l’internationalisation, etc. L'Ă©quipe d'assurance qualitĂ© Ă©labore et propose une sĂ©rie de tests en gĂ©nĂ©ral simples Ă  exĂ©cuter. Suffit de les suivre et indiquer si le rĂ©sultat est celui attendu. Dans le cas contraire, un rapport de bogue devra ĂȘtre ouvert pour permettre l'Ă©laboration d'un correctif.

C'est trĂšs simple Ă  suivre et requiert souvent peu de temps (15 minutes Ă  une heure maximum) si vous avez une Beta exploitable sous la main.

Les tests à effectuer et les rapports sont à faire via la page suivante. J'annonce réguliÚrement sur mon blog quand une journée de tests est planifiée.

Si l'aventure vous intéresse, les images sont disponibles par Torrent ou via le site officiel.

Si vous avez déjà Fedora Linux 40 ou 39 sur votre machine, vous pouvez faire une mise à niveau vers la Beta. Cela consiste en une grosse mise à jour, vos applications et données sont préservées.

Nous vous recommandons dans les deux cas de procéder à une sauvegarde de vos données au préalable.

En cas de bogue, n'oubliez pas de relire la documentation pour signaler les anomalies sur le BugZilla ou de contribuer à la traduction sur Weblate. N'oubliez pas de consulter les bogues déjà connus pour Fedora 41.

Bons tests Ă  tous !

Commentaires : voir le flux Atom ouvrir dans le navigateur

Fedora Linux 40 est de sortie avec un nouveau GNOME et KDE Plasma

En ce mardi 23 avril, les utilisateurs du Projet Fedora seront ravis d'apprendre la disponibilité de la version Fedora Linux 40.

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.

Cette 40e édition propose principalement une mise à jour de son interface principale GNOME 46 et de son concurrent KDE Plasma 6 qui passe à Wayland par défaut au passage.

Bureau de GNOME

Sommaire

Expérience utilisateur

Passage à GNOME 46. Cette version se démarque par beaucoup d'améliorations pour son navigateur de fichiers nommé Fichiers. Il dispose dorénavant, en plus d'une recherche dans le dossier et sous-dossiers en cours, d'une recherche globale utilisable via le bouton dédié avec une icÎne de loupe ou par le raccourci clavier Ctrl+Shift+F (contrairement à la recherche locale qui se fait via le raccourci Ctrl+F). Il permet de chercher dans l'ensemble du répertoire utilisateur voire davantage selon les préférences de l'utilisateur.

L'icĂŽne de loupe prend place oĂč Ă©tait l'icĂŽne de progression lors des opĂ©rations sur les fichiers comme les dĂ©compressions ou la copie de fichiers. De fait ces opĂ©rations sont affichĂ©es en bas de la barre latĂ©rale ce qui permet d'afficher plus d'informations en un coup d’Ɠil. L'application bĂ©nĂ©ficie en outre d'amĂ©liorations de performances en particulier pour afficher de gros dossiers avec des images ou lors du passage d'une vue liste Ă  une vue par icĂŽnes et vice-versa. Plus de pĂ©riphĂ©riques sur le rĂ©seau peuvent ĂȘtre dĂ©couverts automatiquement permettant notamment de parcourir leurs fichiers.

GNOME prend en charge les comptes Microsoft OneDrive ce qui permet de facilement parcourir les fichiers sauvegardés avec ce service. Dans les comptes à distance, le protocole WebDAV est aussi pris en charge pour l'accÚs à des calendriers, listes de contacts et autres fichiers partagés. Pour l'authentification de ces comptes en ligne, le navigateur par défaut est utilisé dorénavant ce qui permet d'utiliser une plus grande diversité de moyens d'authentifications comme l'usage de périphériques USB dédiés.

Pour les amateurs de la connexion distante, il est maintenant possible de se connecter Ă  GNOME graphiquement Ă  distance via le protocole RDP. Auparavant seulement une session ouverte pouvait ĂȘtre pilotĂ©e ainsi. Cette option est dĂ©sactivĂ©e par dĂ©faut et nĂ©cessite des droits appropriĂ©s, tout se configure via le panneau de configuration tout comme le bureau distant.

En parlant du panneau de configuration, ce dernier a été amélioré en regroupant plusieurs configurations par sections afin d'améliorer la clarté de l'application. La liste des menus devenait particuliÚrement importante et rendait difficile la localisation des éléments à configurer. De plus, la configuration du pavé tactile a été améliorée pour permettre de choisir entre le clic dans un coin ou le clic à deux doigts pour réaliser l'équivalent d'un clic droit avec ce périphérique.

CÎté accessibilité, le lecteur d'écran Orca a été modernisé pour le rendre plus performant, plus fiable et plus compatible avec les applications Wayland ou celles exécutées dans un bac à sable tel que Flatpak. Il est possible de couper temporairement Orca avec le raccourci clavier Ctrl+Alt+Shift+Q ce qui est particuliÚrement utile en cas de conflit entre deux lecteurs d'écran ou si une application utilise du son aussi.

Les notifications dans GNOME indiquent par quelle application elles ont été émises. Il est maintenant possible d'étendre facilement la notification afin de pouvoir la visualiser en entier, utilisant une vue plus compacte par défaut.

De maniÚre plus générale, GNOME bénéfice d'améliorations de performances notamment pour son terminal, son moniteur systÚme qui bénéficie aussi d'un graphe dédié aux entrées / sorties sur les espaces de stockage, pour l'enregistrement de l'écran, le visionneur d'images ou encore pour la recherche globale de GNOME. L'ensemble des applications GTK4 bénéficie d'un nouveau moteur de rendu qui améliore le rendu du texte mais aussi les performances.

Bureau de KDE Plasma

L'environnement de bureau KDE Plasma change de version majeure avec sa nouvelle version 6. Au passage Plasma 6 utilise Wayland par défaut, et s'il était prévu de supprimer totalement la possibilité de l'utiliser avec X11 pour simplifier la maintenance, des volontaires ont permis de repousser l'échéance pour l'instant.

Sous le capot, cette version utilise la nouvelle bibliothĂšque majeure graphique qu'elle emploie Ă  savoir Qt 6. C'Ă©tait l'occasion par ailleurs de rationaliser les diffĂ©rentes couches techniques et APIs internes afin de supprimer ce qui n'Ă©tait plus au goĂ»t du jour ou trop peu employĂ© pour ĂȘtre maintenu.

Cette version propose la prise en charge partielle du rendu des couleurs en HDR pour les applications et matériel compatibles, mais aussi un profil de couleur spécifique par écran afin d'avoir un rendu fidÚle des couleurs. Dans cette thématique pour les personnes souffrant de daltonisme ou d'autres formes de maladies dichromatiques peuvent utiliser des filtres pour améliorer la lisibilité des applications et de leur contenu.

Dans les changements plus classiques, la barre principale est par défaut en mode flottant comme pour beaucoup de docks d'autres environnement de bureaux ou systÚmes d'exploitation. Il est bien sûr possible de changer tout cela dans les paramÚtres et plus encore concernant cette barre principale. Concernant l'affichage principal, l'effet cube en cas de changement de bureau virtuel est de nouveau disponible. Pour la capture d'écran, il est possible de choisir une zone arbitraire de l'écran, d'utiliser le codec VP9 pour les enregistrements vidéos et de choisir sa qualité.

Le thÚme par défaut de l'environnement nommé Breeze bénéficie d'un rafraichissement, il utilise moins de cadres et a un affichage un peu plus compact.

Comme pour GNOME, la recherche a bénéficié d'un effort important. En plus de permettre la conversion de fuseaux horaires ou de trier les résultats par type, les performances sont grandement améliorées : jusqu'à 200% plus rapide pour chercher des documents, jusqu'à 60% plus rapide pour trouver une application, le tout jusqu'à moins 30% d'usage du processeur. La recherche obtient les résultats pour les textes traduits dans votre langue ou en anglais pour les noms ou les descriptions d'applications par exemple.

Il est dorĂ©navant possible de s'authentifier par mot de passe ou par empreinte digitale en mĂȘme temps, il n'est plus nĂ©cessaire de forcer l'une des deux options.

Et tant d'autres changements encore.

Gestion du matériel

Fourniture de ROCm 6 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 concerne notamment les puces AMD Instinct MI300A et MI300X, et fournit de nouveaux algorithmes optimisĂ©s du mĂ©canisme d'attention et de bibliothĂšques de communication. Il permet l'usage de flottant 8 bits pour gagner en consommation mĂ©moire au dĂ©triment de la prĂ©cision du modĂšle pour PyTorch et hipblasLT. Via la plateforme AMD Infinity Hub, il est possible d'obtenir des paquets prĂȘts Ă  l'usage pour certains travaux en IA ou calculs haute performance notamment pour les calculs scientifiques.

Les nouvelles notifications de GNOME

Passage Ă  l'Ă©tape 2 de la prise en charge du noyau unifiĂ© nommĂ©e UKI (donc unifiant noyau, initrd, ligne de commande du noyau et signature) pour les plateformes avec UEFI mais rien ne change par dĂ©faut Ă  ce sujet. L'objectif dans cette phase est de pouvoir dĂ©marrer sur de tels noyaux directement sans chargeur de dĂ©marrage intermĂ©diaire, tout en offrant la possibilitĂ© de dĂ©marrer sur d'autres noyaux et de passer automatiquement au noyau suivant par dĂ©faut suite Ă  une mise Ă  jour. Les machines Aarch64 (ARM 64 bits) peuvent Ă©galement s'en servir maintenant. Une image pour cette architecture et x86_64 doit Ă©galement ĂȘtre fournie pour un contexte de virtualisation en Ă©tant basĂ©e sur ces fichiers kickstart.

Si vous souhaitez tester cela sur un systĂšme existant, vous pouvez installer les paquets virt-firmware, uki-direct avant d'exĂ©cuter le script sh /usr/share/doc/python3-virt-firmware/experimental/fixup-partitions-for-uki.sh pour configurer les partitions proprement afin d'ĂȘtre dĂ©couvrables par le systĂšme, puis enfin installer le paquet kernel-uki-virt pour qu'il installe le noyau proprement avec la nouvelle mĂ©thode. Il est prĂ©fĂ©rable de tester cela sur une machine virtuelle ou si vous savez ce que vous faites avec du matĂ©riel standard type ahci / nvme pour le stockage principal. Bien sĂ»r ce travail reste expĂ©rimental et est rĂ©servĂ© Ă  ceux qui savent comment faire pour rĂ©parer le systĂšme en cas de problĂšmes.

Internationalisation

Le gestionnaire d'entrée de saisie IBus passe à la version 1.5.30. Les commandes pour lancer et relancer IBus fonctionnent depuis l'environnement Plasma Wayland dorénavant, et pour cet environnement aussi les préférences sont maintenant accessibles depuis le menu non contextuel.

Mise Ă  jour de ibus-anthy 1.5.16 pour la saisie du japonais. Le principal changement est la conversion possible d'Ăšre japonaise avec 2024.

Administration systĂšme

NetworkManager tente de dĂ©tecter par dĂ©faut les conflits d'usage d'adresse IPv4 avec le protocole Address Conflict Detection (RFC 5227) avant de l'attribuer Ă  la machine. En somme au moment de s'attribuer une adresse IP donnĂ©e, une requĂȘte ARP est envoyĂ©e au rĂ©seau concernant cette adresse. Si une rĂ©ponse est obtenue, l'adresse est dĂ©jĂ  utilisĂ©e et n'est donc pas exploitable sans perturber le rĂ©seau. Ce mĂ©canisme existe pour les rĂ©seaux avec IP fixes ou mĂȘme avec un serveur DHCP central car rien n'empĂȘche la prĂ©sence d'une machine configurĂ©e avec une IP fixe dans le rĂ©seau malgrĂ© tout. Si le rĂ©seau a un serveur DHCP et qu'un conflit est dĂ©tectĂ©, la rĂ©ponse DHCPDECLINE sera envoyĂ©e pour obtenir peut ĂȘtre une autre adresse. En cas de conflit une erreur sera rapportĂ©e permettant Ă  l'utilisateur de diagnostiquer le problĂšme et d'y apporter une solution. Par dĂ©faut le systĂšme attendra 200 ms avant de dĂ©cider qu'il n'y a aucune rĂ©ponse. Pour l'IPv6 cela est inclus dans le standard RFC 4862 ce qui rend ce changement non nĂ©cessaire dans ce cas de figure.

NetworkManager va utiliser une adresse MAC aléatoire par défaut pour chaque réseau Wifi différent, et cette adresse sera stable pour un réseau donné. En effet, certains systÚmes utilisent l'adresse Mac pour identifier les machines en déplacement de réseau en réseau permettant une pseudo géolocalisation ce qui nuit à la vie privée. Mais la méthode usuelle de changer d'adresse MAC aléatoirement à chaque connexion pose un problÚme en cas de réseau restreignant l'accÚs à certaines adresses MAC uniquement ou en changeant d'adresse IP à chaque reconnexion. Cette méthode est un compromis entre le respect de la vie privée et le confort d'utilisation. Cela est fait en ajoutant la configuration wifi.cloned-mac-address="stable-ssid" dans le nouveau fichier /usr/lib/NetworkManager/conf.d/22-wifi-mac-addr.conf.

Les entrées des politiques SELinux qui font référence au répertoire /var/run font maintenant référence au répertoire /run. Il y a dix ans déjà que le premier répertoire a bougé vers le deuxiÚme chemin mais SELinux a gardé les vieilles rÚgles en utilisant un lien d'équivalence entre eux pour permettre leur utilisation. Cependant certains outils comme restorecon ne gÚrent pas bien cette situation tout comme les administrateurs systÚmes qui ne sont pas sûrs de comment écrire proprement de nouvelles rÚgles. Pour résoudre le problÚme le lien d'équivalence passe de /run = /var/run à /var/run = /run.

La recherche globale dans Fichiers

L'outil SSSD ne prend plus en charge les fichiers permettant de gérer les utilisateurs locaux. Il pouvait exploiter les fichiers /etc/passwd et /etc/group via l'utilisation de l'option id_provider=files. Cependant cette option n'est plus proposée par le projet officiel et n'était à l'époque conservée que pour permettre l'authentification via des cartes à puce ou l'enregistrement de sessions. Mais dans les deux cas il est possible de passer à la méthode proxy via l'option id_provider=proxy pour le remplacer dans ces cas d'usage. Un guide officiel est proposé pour effectuer la conversion pour ceux qui en ont besoin.

DNF ne téléchargera plus par défaut la liste des fichiers fournie par les différents paquets. Jusqu'à présent il le faisait par défaut parmi d'autres métadonnées, mais cette information n'est en réalité nécessaire que dans certains cas précis qui ne concernent pas celui de la majorité des utilisateurs. Notamment pour quelques paquets ayant une dépendance envers un fichier particulier plutÎt qu'un paquet donné ou si on cherche un paquet fournissant un fichier spécifique. Cela permet de réduire les ressources consommées chez les utilisateurs mais aussi au sein de l'infrastructure de Fedora car il n'est plus nécessaire de fournir ces données assez conséquentes de maniÚre systématique.

L'outil fwupd pour mettre à jour les firmwares va utiliser passim comme cache pour partager sur le réseau local les métadonnées liées aux mises à jour disponibles pour les firmwares. Ce fichier qui représente environ 1 Mio est téléchargé quotidiennement parfois sur des liaisons coûteuses. Ainsi la pression est réduite sur les infrastructures notamment le CDN fwupd et la bande passante en utilisant localement la ressource quand elle est disponible. Passim utilise avahi pour signaler son service sur le réseau local qui est disponible via le port 27500 afin que les autres clients puissent identifier si des métadonnées sont disponibles localement.

Les systĂšmes Fedora Silverblue et Kinoite disposent de bootupd pour la mise Ă  jour du chargeur de dĂ©marrage. Par conception les systĂšmes avec rpm-ostree comme ceux-ci n'ont pas le chargeur de dĂ©marrage qui se met Ă  jour par ce biais car cela n'est pas une opĂ©ration sĂ»re. En effet, la mise Ă  jour de ces systĂšmes repose sur le principe de transaction pour que le passage d'un Ă©tat Ă  un autre soit fiable, cependant ce mĂ©canisme ne fonctionne pas bien pour le chargeur de dĂ©marrage qui est un composant distinct et critique. On retrouve la mĂȘme problĂ©matique pour les systĂšmes utilisant un mĂ©canisme de mise Ă  jour basĂ© sur une partition A et B et passant de l'un Ă  l'autre. D'oĂč la crĂ©ation de cet utilitaire qui est mis Ă  disposition pour ceux qui le souhaitent, du moins pour les machines disposant d'un EFI. La mise Ă  jour est pour le moment manuelle Ă  la demande avec la commande bootupctl update. La mise Ă  jour automatique sera prĂ©vue dans le futur.

Le paquet libuser est marqué en voie de suppression pour Fedora 41 alors que le paquet passwd est supprimé. La bibliothÚque libuser sert à cacher les différences entre les utilisateurs locaux et distants via le protocole LDAP. Mais la prise en charge de ce protocole reste incomplet et il n'y a pas de plan pour aller plus loin, comme sssd peut la remplacer dans ce rÎle, la décision de la supprimer prochainement de Fedora fait sens. Pour l'instant seuls les paquets usermode et util-linux en ont encore besoin. Le paquet passwd quant à lui disparaßt pour se débarrasser de la dépendance à libuser. La commande pour changer de mot de passe ne change pas, mais est fournie par le paquet shadow-utils.

Le paquet cyrus-sasl-ntlm a été supprimé. Le protocole d'identification NTLM n'est plus maintenu, au profit du protocole Kerberos et ce composant dans SASL n'est plus maintenu depuis des années justifiant une telle décision.

La gestion des droits utilisateurs pam_userdb passe de la base de données BerkeleyDB à GDBM. BerkeleyDB 5.x fourni par Fedora n'est plus à jour ce qui pose des soucis en terme de bogues et de sécurité, d'autant plus avec le rÎle de PAM dans le systÚme. La licence de BerkeleyDB a changé dans la branche 6.x, passant de BSD à AGPL rendant impossible l'adoption de cette version plus à jour pour ce composant, les licences n'étant pas compatibles. Ainsi GDBM se pose comme une alternative pour résoudre ce problÚme. BerkeleyDB 5.x a débuté sa sortie du projet Fedora depuis Fedora 33, ceci est une étape de plus dans cette direction.

Le filtre antispam bogofilter utilise SQLite au lieu de BerkeleyDB pour gérer sa base de données interne. La raison est analogue au paragraphe précédent.

Le serveur LDAP 389 passe de la version 2.4.4 Ă  la version 3.0.0. Le projet abandonne la prise en charge de BerkeleyDB pour sa base de donnĂ©es interne pour la mĂȘme raison que prĂ©cĂ©demment. En dehors de cela qui introduit des incompatibilitĂ©s, cette mise Ă  jour est en rĂ©alitĂ© assez mineure sur les autres aspects en fournissant essentiellement des correctifs de bogues.

Le paquet iotop est remplacé par iotop-c. Si le nom du paquet change, celui du binaire installé ne change pas. iotop n'est plus vraiment maintenu depuis une dizaine d'années et est sévÚrement concurrencé par iotop-c sur cet aspect qui bénéfice en plus d'une empreinte mémoire plus petite étant rédigé en C au lieu de Python. Il n'est pas pertinent aux yeux des mainteneurs de maintenir les deux ainsi.

L'orchestrateur de conteneurs Kubernetes Ă©volue de la version 1.27 Ă  la version 1.29. Ce changement est communiquĂ© car Kubernetes dĂ©conseille le saut des versions ce que Fedora fait actuellement en passant Ă  la version 1.28 en fournissant ainsi la derniĂšre version disponible. Cette version propose aux utilisateurs la possibilitĂ© d'avoir un Ă©cart de version de n-2 Ă  n-3 pour les versions mineures entre le nƓud principal et le plan de contrĂŽle. Il est Ă©galement possible si un nƓud est indisponible suite Ă  une panne ou Ă  un Ă©tat non rĂ©cupĂ©rable de dĂ©marrer les services qu'il gĂ©rait dans un autre nƓud dans un Ă©tat sain. Le mode d'accĂšs aux donnĂ©es ReadWriteOncePod devient accessible sans restrictions, permettant de restreindre l'accĂšs Ă  des donnĂ©es Ă  un seul pod Ă  la fois plutĂŽt qu'Ă  un seul nƓud, pour rĂ©duire le risque d'accĂšs concurrents en particulier en Ă©criture. De mĂȘme le module KMS v2 est disponible Ă  tous pour rĂ©aliser les services de chiffrement pour vos APIs.

Par ailleurs les paquets de Kubernetes sont restructurés. L'objectif est de se rapprocher de l'organisation du projet upstream et de simplifier la vie des utilisateurs. Ainsi le paquet kubernetes récupÚre l'utilitaire kubelet qui avait son paquet dédié et les services fournis via l'ancien sous-paquet kubernetes-master sont renommés kubernetes-systemd. Les paquets kubernetes-client et kubernetes-kubeadm restent inchangés.

Pendant que podman est mis Ă  jour vers la version 5. Cette version abandonne la prise en charge des cgroupv1 du noyau, de mĂȘme que les plugins CNI ou la base de donnĂ©es clĂ© / valeur Boltdb au profit de SQLite pour les nouvelles instances. Le format des fichiers de configuration pour les podman machines a Ă©tĂ© profondĂ©ment remaniĂ©, rendant nĂ©cessaire la recrĂ©ation des machines virtuelles concernĂ©es conçues avant cette version.

Le paquet wget2 remplace le paquet wget en fournissant une nouvelle version. Cette version propose du code multithreadĂ© et qui tĂ©lĂ©charge plus vite grĂące Ă  la prise en charge du protocole HTTP2 avec la compression ou le tĂ©lĂ©chargement parallĂšle. Il propose plus d'options, il a Ă©galement plus de tests automatiques pour s'assurer de sa robustesse dans le temps. Sa rĂ©Ă©criture dans un style plus moderne devrait faciliter l'adoption de nouveaux protocoles Ă  l'avenir. Par contre les protocoles dĂ©passĂ©s WARC et FTP sont moins bien pris en charge. La licence change pour GPLv3+, de mĂȘme que sa bibliothĂšque libwget2 vers LGPLv3+.

Améliorations du moniteur systÚme

Le gestionnaire de base de donnĂ©es PostgreSQL migre vers sa 16e version. De part l'arrĂȘt des modules, les paquets pour des versions alternatives sont Ă©galement rĂ©introduits. Ainsi les paquets postgresql15* font leur apparition pour la prise en charge de la version prĂ©cĂ©dente, et les paquets postgresql17* seront proposĂ©s quand la 17e version sera disponible. En terme de changements apportĂ©s par cette nouvelle version, les jointures FULL ou OUTER sur des hash peuvent ĂȘtre parallĂ©lisĂ©es pour de meilleures performances. Il est dorĂ©navant possible de rĂ©pliquer des donnĂ©es depuis des serveurs dans un Ă©tat standby, de mĂȘme la rĂ©plication peut ĂȘtre appliquĂ©e en parallĂšle pour de larges transactions afin d'amĂ©liorer les performances de l'opĂ©ration. La vue pg_stat_io fournit des informations statistiques concernant les entrĂ©es et sorties. SQL/JSON qui est introduit dans le standard SQL bĂ©nĂ©ficie de constructeurs dĂ©diĂ©s pour crĂ©er des objets JSON mais aussi des fonctions identitĂ©s pour connaĂźtre le type des clĂ©s. Et ce parmi de nombreuses corrections de bogues et d'amĂ©lioration de performances.

Les paquets MySQL et MariaDB sont remaniés et mis à jour vers la version 10.11 pour MariaDB. Le paquet community-mysql est renommé mysql tandis que le paquet mariadb ne fourni plus de binaires avec le nom mysql. En effet la décision à l'époque a été prise car il semblait convenu que MariaDB remplacerait MySQL tout comme LibreOffice a supplanté OpenOffice.org mais force est de constater que les deux projets vont cohabiter longtemps. Cela rend le tout plus simple pour l'utilisateur. Cependant, puisque ces logiciels évoluent séparément, ils deviennent peu à peu incompatibles et le mainteneur abandonne la possibilité d'utiliser MariaDB comme serveur avec MySQL comme client et vice-versa. Aucune autre distribution en fournissait une telle possibilité et cela devenait difficile à maintenir car cela était source de problÚmes.

En terme de nouvelles fonctionnalitĂ©s pour MariaDB, il est possible de lire entiĂšrement les tables Information Schema Parameters et Information Schema Routines tout en amĂ©liorant les performances dans la procĂ©dure. Il est possible de savoir combien de temps une requĂȘte passe dans l'optimiseur via l'option ANALYZE FORMAT=JSON. Les semi-jointures pour la mise Ă  jour ou la suppression de donnĂ©es sont optimisĂ©es. Les privilĂšges SUPER et READ ONLY ADMIN sont dorĂ©navant distincts, Ă  ce sujet il est possible de fournir Ă  tous les utilisateurs des droits spĂ©cifiques via la requĂȘte GRANT <privilege> ON <database>.<object> TO PUBLIC.

DĂ©veloppement

Mise Ă  jour de la suite de compilation GNU : GCC 14.0, binutils 2,41, glibc 2.39 et gdb 14.1.

Concernant la suite de compilateurs GCC, elle continue l'amélioration de la prise en charge des langages C23 et C++23, alors que débute la prise en charge de la future norme C++26. De nombreux modÚles de puces Aarch64 et x86_64 bénéficient de micro-optimisations, tandis qu'il y a un début de prise en charge des nouvelles instructions pour l'architecture x86_64 d'Intel dénommées APX et AVX10. L'analyseur statique de code peut afficher visuellement les dépassements de tampons pour mieux comprendre ce qui se passe en mémoire.

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.

Quant Ă  la bibliothĂšque standard C glibc, cela se traduit par de nombreuses amĂ©liorations comme la prise en charge de la pile cachĂ©e pour Ă©viter les attaques par modification d'adresse de retour, ce que Fedora Linux active par ailleurs. De mĂȘme pour limiter certaines attaques, la glibc propose de pouvoir rĂ©Ă©crire au lancement la PLT pour obtenir les adresses des fonctions des bibliothĂšques dynamiques plutĂŽt que de les avoir lors du premier appel Ă  chaque fonction. Le programme dĂ©marre plus lentement mais est plus sĂ»r pour la suite. L'en-tĂȘte <stdbit.h> fait son apparition pour les manipulations sur les bits, opĂ©rations basĂ©es sur la norme de C20. Et une nouvelle fonction posix_spawnattr_setcgroup_np est ajoutĂ©e pour dĂ©marrer un processus dans un cgroup donnĂ© afin d'Ă©viter des situations de concurrence entre le moment oĂč le processus est dĂ©marrĂ© et oĂč les restrictions s'appliquent.

Enfin le dĂ©bogueur gdb propose un dĂ©but de prise en charge du protocole de Microsoft Debugger Adapter Protocol pour faire le lien entre les dĂ©bogueurs et des IDEs ou Ă©diteurs de code afin de faciliter leur intĂ©gration mutuelle. Il peut Ă©galement gĂ©rer des entiers au delĂ  de 64 bits, de mĂȘme que d'appeler une commande shell avec l'instruction $_shell pour obtenir son rĂ©sultat. Les instructions de l'architecture Aarch64 SME et SME2 commencent Ă  ĂȘtre gĂ©rĂ©es et l'API Python est considĂ©rablement Ă©toffĂ©e pour ceux qui veulent scripter le dĂ©bogueur.

La suite de compilateurs LLVM est mise Ă  jour Ă  la version 18. Fedora en profite pour que CLang utilise des informations de dĂ©bogage au format DWARF-5 au lieu de DWARF-4 par dĂ©faut comme appliquĂ© par le projet amont. Pour simplifier la procĂ©dure de compilation de Fedora pour les paquets utilisant cette chaĂźne de compilation, le Fat-LTO sera employĂ© pour permettre l'usage du LTO quand c'est possible comme cela Ă©tait dĂ©jĂ  le cas avec GCC. Jusqu'alors ces paquets Ă©taient compilĂ©s avec LTO par dĂ©faut avec une Ă©ventuelle conversion vers ELF Ă  la main si la compatibilitĂ© le nĂ©cessitait ce qui Ă©tait particuliĂšrement lourd. Par ailleurs les paquets de compatibilitĂ© des versions prĂ©cĂ©dentes fournissent les binaires des diffĂ©rents utilitaires et non plus seulement les bibliothĂšques et en-tĂȘtes.

Concernant les nouveautĂ©s apportĂ©es par le projet en lui mĂȘme, comme pour la chaĂźne de compilation GNU, les architectures Aarch64, x86_64 ou RISC-V sont mieux gĂ©rĂ©es. Le compilateur CLang suit GCC avec du travail sur C++20, C++23 pour amĂ©liorer la compatibilitĂ© avec le standard et le dĂ©but de prise en charge de la future norme C++26.

Mise à jour de la bibliothÚque C++ Boost à la version 1.83. Depuis la version 1.81, cette bibliothÚque propose un module pour communiquer avec les bases de données MySQL ou encore une bibliothÚque Compat: pour fournir en code compatible C++11 des ajouts proposés par les standards ultérieurs.

Le langage Go passe à la version 1.22. La sémantique de la boucle for évolue un peu avec la création de la variable de boucle à chaque itération de boucle plutÎt qu'à la premiÚre avec mise à jour à chaque passage. De plus il accepte l'usage des plages de valeurs basées sur des entiers. L'exécution des programmes gagne 1 à 3% grùce à l'optimisation de la localisation mémoire des métadonnées du ramasse miette. Les programmes compilés avec un profil d'optimisation peuvent gagner entre 2 et 14% de performances par rapport à la version précédente grùce à la possibilité d'appliquer la technique sur plus de fonctions qu'avant.

Le JDK de rĂ©fĂ©rence pour Java passe de la version 17 Ă  21. OpenJDK peut maintenant faire du filtrage par motif dans une instruction switch. Il est possible aussi d'affecter le rĂ©sultat d'une identification de type dans une variable directement afin de pouvoir s'en servir immĂ©diatement. Des fils d'exĂ©cution virtuels font leur apparition qui sont plus lĂ©gers et performants, plutĂŽt dĂ©diĂ©s Ă  des tĂąches courtes avec beaucoup d'attentes, ces tĂąches peuvent ainsi bĂ©nĂ©ficier de meilleure performance notamment en terme de latence. Il introduit Ă©galement une API pour les collections d'objet en sĂ©quence (donc ordonnĂ©es). De mĂȘme une nouvelle API pour manipuler les clĂ©s cryptographiques symĂ©triques fait son entrĂ©e. Le ramasse miette Z Garbage Collector amĂ©liore ses performances.

Ruby 3.3 surveille sa syntaxe avec Prism. Prism est un gem introduisant un nouveau parseur trÚs flexible qui a vocation à remplacer Ripper. Le compilateur juste à temps YJIT bénéficie de nombreuses améliorations comme de meilleures performances, une réduction de la consommation mémoire avec un code généré plus compact et avec moins de métadonnées et un temps de compilation plus court. Un concurrent RJIT fait son entrée, écrit en pur Ruby et non en C comme YJIT, il a plus vocation à servir de terrain d'expérimentation. Le ramasse miette est également plus performant.

Connexion Ă  distance dans GNOME

Le langage PHP utilise la version 8.3. Cette version permet de définir des classes constantes, il propose également un attribut #[\Override] si une classe surcharge une méthode d'une classe parente. Une nouvelle fonction json_validate permet de vérifier la validité d'un JSON sans le décoder. Le Randomizer a plus de méthodes pour permettre de générer des noms ou nombres aléatoires suivant les besoins.

La boßte à outils pour le machine learning PyTorch fait son entrée dans Fedora. L'objectif est de fournir une meilleure expérience pour les développeurs de ce genre de solution. Un groupe de travail dédié s'est mis en place avec une réunion bi-hebdommadaire. Pour le moment l'architecture x86_64 est la seule prise en charge avec un effort important mis sur les solutions AMD.

Le paquet python-sqlalchemy utilise la nouvelle branche majeure 2.x du projet, le paquet python-sqlalchemy1.4 est proposé pour garder la compatibilité. Cette version apporte entre autre de l'annotation de type ce qui permet de construire des ORM sur un modÚle déclaratif. Les opérations d'insertions sont aussi bien plus performantes quelque soit le gestionnaire de base de données derriÚre.

La bibliothÚque de validation des données Pydantic utilise dorénavant la version 2. Outre l'amélioration des performances, il change radicalement son API ce qui coupe la compatibilité ascendante.

La bibliothĂšque Thread Building Blocks passe du fil 2020.3 au fil 2021.8. De mĂȘme la compatibilitĂ© ascendante n'est pas garantie ce qui a rendu ce portage compliquĂ©.

La bibliothĂšque OpenSSL 1.1 est supprimĂ©e ne laissant que la derniĂšre version de la branche 3.x. Depuis Fedora 36 la branche 3 est employĂ©e par dĂ©faut dans Fedora. OpenSSL 1.1 n'est plus maintenue depuis fin de l'annĂ©e derniĂšre ce qui rend sa maintenance dĂ©licate et non sĂ»re d'oĂč son abandon malgrĂ© la faible compatibilitĂ© entre les deux versions pour ceux qui s'en servait encore.

Les bibliothÚques zlib et minizip utilisent leur variante zlib-ng et minizip-ng dorénavant. Ces versions sont plus rapides grùce à l'emploi des instructions plus modernes des processeurs actuels tout en gardant la compatibilité par rapport à l'implémentation de référence.

Le langage Python ne bénéficie plus de la version 3.7. Depuis juin de l'année derniÚre cette version n'est plus maintenue et il n'y a pas de raison de poursuivre son maintien dans les dépÎts en tant que version de compatibilité.

Projet Fedora

L'édition Cloud sera construite avec l'utilitaire Kiwi dans Koji. L'utilitaire ImageFactory employé jusqu'à présent n'est plus maintenu. Les outils mkosi et osbuild ont été considérés mais non retenus, le premier car il manque de flexibilité pour fournir toutes les images souhaitées, tandis que le second est certes adopté par l'équipe de Fedora Workstation mais ne semble pas adapté aux besoins des images clouds qui reposent sur d'autres technologies dont rpm-ostree et doit fournir des délivrables plus variés également. En effet l'image cloud cible Vagrant, Azure, AWS, GCP et peut dorénavant viser aussi les images pour WSL2 ou pour conteneurs directement.

Tandis que l'édition Workstation aura son image ISO générée avec l'outil Image Builder. En effet ce dernier bien que déjà employé par Fedora Workstation bénéficie enfin de la prise en charge des images ISO live. Il remplace donc les outils lorax/livemedia-creator qui avaient beaucoup de problÚmes. Il devient aussi plus simple pour quiconque de générer son image ISO avec un simple fichier TOML pour le décrire et quelques utilitaires en ligne de commande.

L'image minimale ARM sera construite avec l'outil OSBuild. Comme dans le cadre de l'édition Cloud, il remplace l'utilitaire ImageFactory qui montrait ses limites. L'objectif à terme est de pouvoir supprimer totalement ou partiellement les hacks nécessaires à ce jour pour utiliser cette image sur une grande variété de systÚmes ARM.

Fedora IoT bénéficiera d'images pouvant démarrer dans des conteneurs. Ainsi il est possible de tester le systÚme dans des conteneurs plutÎt que via de la virtualisation classique ou sur des machines physiques. Cette flexibilité peut aider le test par les utilisateurs mais également par ses mainteneurs.

Il bĂ©nĂ©ficiera Ă©galement des images Simplified Provisioning. Fedora IoT peut ainsi utiliser l'utilitaire coreos-installer pour l'installer sur le disque directement et ce en utilisant un argument noyau pour savoir sur quel disque l'installer. Ainsi pas besoin de fichier kickstart ou d’interaction avec l'utilisateur ce qui simplifie la procĂ©dure et son automatisation. Cela s'intĂšgre parfaitement avec les dispositifs Fido Device Onboarding et Ignition pour la configuration de tels systĂšmes dans un environnement de production.

Et le tout sera construit en utilisant rpm-ostree unified core. L'ancien mode n'est en effet plus maintenu et moins testĂ©. Le mode unifiĂ© permet au compose server, qui est l'image de base crĂ©Ă©e Ă  partir de RPM, de fonctionner de maniĂšre similaire au client qui ajoute des commits par dessus pour personnaliser le contenu du systĂšme. Cela permet de simplifier la maintenance cĂŽtĂ© rpm-ostree mais aussi de rĂ©soudre certaines difficultĂ©s notamment pour la gestion du dĂ©marrage avec bootupd, les labels SELinux et l'utilisation de conteneurs pour les scriplets prĂ© et post installations des paquets. Depuis Fedora Linux 39 oĂč Silverblue et Kinoite ont amorcĂ© la transition, l'Ă©dition IoT Ă©tait la derniĂšre variante Ă  ne pas avoir franchi le pas.

Fedora sera construit avec DNF 5 en interne. Ainsi les outils Mock, Koji et Copr passent le cap, en attendant Fedora Linux 41 pour que cela soit le cas pour les utilisateurs de la distribution. L'objectif est ici double. Les développeurs de DNF auront un retour d'expérience grandeur nature sur cette version et permettra d'identifier d'éventuels problÚmes. Pour l'infrastructure, DNF 5 est plus léger en mémoire, plus performant et consomme moins d'espace disque ce qui permettrait de gagner du temps dans la construction des RPM et des images et de réduire la pression sur le matériel employé à ces tùches.

KDE Plasma avec des applications

Les macros forge passent du paquet redhat-rpm-config à forge-srpm-macros. Ces projets sont maintenant distincts upstream et ce premier dépend maintenant du second. L'objectif est de simplifier la possibilité d'exécuter des tests automatiques sur ces macros afin d'améliorer leur fiabilité.

Phase 3 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. L'objectif de cette phase est de poursuivre le travail entamĂ© dans les versions prĂ©cĂ©dentes en convertissant l'essentiel des paquets RPM vers ce nouveau format. Cependant le travail devrait ĂȘtre achevĂ© pour l'ensemble des paquets pour Fedora Linux 41.

La construction de certains paquets échouera si l'éditeur de lien détecte certaines classes de vulnérabilité dans le binaire en construction. C'est la macro %{hardened_build} qui est étendue pour fournir ce service, cela ne concerne que les paquets l'utilisant. Il peut ainsi générer une telle erreur s'il détecte une pile exécutable, un segment chargeable en mémoire avec des permissions en lecture, écriture et exécutable ou un fil d'exécution local ayant un segment exécutable. L'objectif est donc de renforcer le caractÚre non modifiable des sections mémoires exécutables pour limiter le risque de failles de sécurité. Cela est fait grùce à l'éditeur de lien BFD qui fournit de telles vérifications. Jusqu'à présent ces cas étaient détectés mais ne généraient que des avertissements qui étaient de fait ignorés.

Compilation des paquets en convertissant plus d'avertissements comme erreurs lors de la compilation des projets avec le langage C. L'objectif est de supprimer de plus en plus de code utilisant d'anciennes constructions qui sont source de bogues d'une part, mais qui seront aussi progressivement interdites par dĂ©faut avec les futures versions de GCC. Par ailleurs, certains de ces Ă©lĂ©ments pouvaient ĂȘtre bloquants pour l'adoption d'une nouvelle norme C de rĂ©fĂ©rence pour certains paquets.

Voici la liste des changements opérés :

  • Suppression des dĂ©clarations implicites de fonctions : 54 paquets concernĂ©s ;
  • Suppression du type implicite int quand le type est omis : 5 paquets concernĂ©s ;
  • Obligation de mentionner les types dans les arguments lors de la dĂ©claration de fonctions : aucun paquet concernĂ© ;
  • Interdiction de conversions implicites entre entier et pointeurs : 100 paquets concernĂ©s ;
  • L'instruction return doit avoir les arguments qui correspondent au type de retour d'une fonction (donc pas d'argument si void, et non vide si un entier est attendu par exemple) : 13 paquets concernĂ©s ;
  • Interdiction des conversions implicites de pointeurs de types diffĂ©rents : 381 paquets concernĂ©s.

Certains changements devraient voir le jour dans le futur :

  • Interdiction des dĂ©clarations de fonctions dans le style prĂ©-C89 ;
  • Interdiction d'utiliser des mots clĂ©s bool, true ou false avec des dĂ©finitions locales plutĂŽt que d'utiliser l'en-tĂȘte de la bibliothĂšque standard ;
  • DĂ©clarer une fonction sans argument comme void foo() aurait le mĂȘme sens qu'en C++, Ă  savoir Ă©quivalent Ă  void foo(void) plutĂŽt qu'Ă  accepter n'importe quel type d'arguments.

Clap de fin pour la construction des mises Ă  jour au format Delta RPM. Ils sont dĂ©sactivĂ©s par dĂ©faut dans la configuration de DNF et Fedora ne les gĂ©nĂ©rera plus. Cette fonctionnalitĂ© permettait pour les mises Ă  jour de ne tĂ©lĂ©charger que la diffĂ©rence entre le paquet dĂ©jĂ  installĂ© et celui Ă  mettre Ă  jour. Cela permettait de rĂ©duire la quantitĂ© de donnĂ©es Ă  tĂ©lĂ©charger, la machine de l'utilisateur pouvait reconstruire le paquet Ă  partir de ces informations et ainsi obtenir la nouvelle version. Mais en pratique la fonctionnalitĂ© se rĂ©vĂšle de moins en moins pertinente. Tout d'abord le processus n'est pas fiable Ă  100%, parfois la reconstruction Ă©choue et dans ce cas le nouveau paquet est totalement tĂ©lĂ©chargĂ© Ă  nouveau ce qui conduit Ă  un gaspillage de ressources. De plus peu de paquets Ă©taient concernĂ©s, les delta RPM Ă©taient d'ailleurs construits en gĂ©nĂ©ral que d'une version Ă  une autre ce qui la rend fonctionnelle surtout pour ceux qui mettent Ă  jour trĂšs rĂ©guliĂšrement leur systĂšme. Et pour que cette fonctionnalitĂ© soit exploitable, ces fichiers delta rpm font partie des mĂ©tadonnĂ©es que DNF tĂ©lĂ©charge. Sauf que c'est le cas mĂȘme si les delta rpm sont dĂ©sactivĂ©s par l'utilisateur, ou pour les systĂšmes reposant sur rpm-ostree ou utilisant un GUI comme GNOME Logiciels car PackageKit comme rpm-ostree ne se servent pas de ces mĂ©tadonnĂ©es. Au final cela pĂ©nalise toute l'infrastructure qui doit gĂ©nĂ©rer et stocker ces donnĂ©es, et beaucoup d'utilisateurs qui subissent les inconvĂ©nients sans les avantages le tout pour un gain jugĂ© marginal pour ceux qui s'en servent : moins de 8% de rĂ©duction de la taille des tĂ©lĂ©chargements en moyenne.

Les JDKs ne sont gĂ©nĂ©rĂ©s qu'une fois, et rempaquetĂ©s ainsi Ă  toutes les variantes du systĂšme. Pour cela les paquets du JDK sont gĂ©nĂ©rĂ©s Ă  partir de la version la plus ancienne de Fedora Linux encore maintenue, et le rĂ©sultat est directement rĂ©utilisĂ© pour former les paquets des autres versions du systĂšme. Cela rĂ©duit considĂ©rablement le temps de validation de chaque JDK car il y a cinq fois moins de versions diffĂ©rentes Ă  gĂ©rer. Cela permettra aux mainteneurs de maintenir la diversitĂ© actuelle des JDK Ă  savoir les versions 1.8.0, 11, 17 et la derniĂšre (actuellement la version 20). Si ce rĂ©sultat ne permet pas de libĂ©rer assez de temps aux mainteneurs, la rĂ©duction du nombre de JDK Ă  l'avenir pourrait ĂȘtre considĂ©rĂ©e.

Les images immuables pour les systĂšmes personnels comme Silverblue seront nommĂ©es sous la dĂ©nomination Atomic pour Ă©viter la rĂ©fĂ©rence au terme immuable qui est confus pour les utilisateurs. Les noms de variantes Silverblue, Kinoite, Sericea et Onyx vont ĂȘtre prĂ©servĂ©s, l'objectif est de donner une dĂ©nomination commune qui utilise le terme Atomic dĂ©jĂ  employĂ© par l'Ă©dition Cloud par exemple. Le terme immuable est en effet considĂ©rĂ© comme peu clair car si le systĂšme principal est majoritairement en lecture seule, il ne l'est pas totalement notamment pour la configuration ou les parties dynamiques du systĂšme. Alors que le systĂšme repose sur le concept d'atomicitĂ© en ayant une approche par Ă©tat du systĂšme, d'oĂč la nĂ©cessitĂ© de redĂ©marrer pour changer cet Ă©tat notamment lors d'une mise Ă  jour par ailleurs.

L'objectif est donc purement au niveau de la communication autour de ces systĂšmes. Cependant les nouvelles variantes devraient utiliser ce terme dans ce nom comme par exemple Fedora XCFE Atomic si jamais cette variante prend vie un jour.

La communauté francophone

L'association

Logo de Boorsalinux-fr

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 mensuels 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 40 ?

Logo de Fedora Media Writer

Si vous avez déjà Fedora Linux 39 ou 38 sur votre machine, vous pouvez faire une mise à niveau vers Fedora Linux 40. 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 40.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Fedora Linux 40 Beta est disponible pour les tests

En ce mardi 26 mars, la communauté du Projet Fedora sera ravie d'apprendre la disponibilité de la version Beta de Fedora Linux 40.

MalgrĂ© les risques concernant la stabilitĂ© d’une version Beta, il est important de la tester ! En rapportant les bogues maintenant, vous dĂ©couvrirez les nouveautĂ©s avant tout le monde, tout en amĂ©liorant la qualitĂ© de Fedora Linux 40 et rĂ©duisant du mĂȘme coup le risque de retard. Les versions en dĂ©veloppement manquent de testeurs et de retours pour mener Ă  bien leurs buts.

La version finale est pour le moment fixée pour le 16 ou 23 avril.

Sommaire

Expérience utilisateur

  • Passage Ă  GNOME 46 ;
  • L'environnement de bureau KDE Plasma change de version majeure avec sa nouvelle version 6 ;
  • Le fichier firefox.desktop est renommĂ© en org.mozilla.firefox.desktop pour permettre son utilisation dans la barre de recherche de GNOME.

Gestion du matériel

  • Fourniture de ROCm 6 pour amĂ©liorer la prise en charge de l'IA et le calcul haute performance pour les cartes graphiques AMD ;
  • Passage Ă  l'Ă©tape 2 de la prise en charge du noyau unifiĂ© nommĂ©e UKI (donc unifiant noyau, initrd, ligne de commande du noyau et signature) pour les plateformes avec UEFI mais rien ne change par dĂ©faut Ă  ce sujet.

Internationalisation

  • Le gestionnaire d'entrĂ©e de saisie IBus passe Ă  la version 1.5.30 ;
  • Mise Ă  jour de ibus-anthy 1.5.16 pour la saisie du japonais.

Administration systĂšme

  • NetworkManager tente de dĂ©tecter par dĂ©faut les conflits d'usage d'adresse IPv4 avec le protocole Address Conflict Detection avant de l'attribuer Ă  la machine ;
  • NetworkManager va utiliser une adresse MAC alĂ©atoire par dĂ©faut pour chaque rĂ©seau Wifi diffĂ©rent, et cette adresse sera stable pour un rĂ©seau donnĂ©. Cela permet de concilier vie privĂ©e et confort d'utilisation ;
  • Les unitĂ©s systĂšme de systemd vont utiliser par dĂ©faut beaucoup d'options pour amĂ©liorer la sĂ©curitĂ© des services ;
  • Les entrĂ©es des politiques SELinux qui font rĂ©fĂ©rence au rĂ©pertoire /var/run font maintenant rĂ©fĂ©rence au rĂ©pertoire /run ;
  • L'outil SSSD ne prend plus en charge les fichiers permettant de gĂ©rer les utilisateurs locaux ;
  • DNF ne tĂ©lĂ©chargera plus par dĂ©faut la liste des fichiers fournie par les diffĂ©rents paquets ;
  • L'outil fwupd pour mettre Ă  jour les firmwares va utiliser passim comme cache pour partager sur le rĂ©seau local les mĂ©tadonnĂ©es liĂ©es aux mises Ă  jour disponibles pour les firmwares ;
  • Les systĂšmes Fedora Silverblue et Kinoite disposent de bootupd pour la mise Ă  jour du chargeur de dĂ©marrage ;
  • Le paquet libuser est marquĂ© en voie de suppression pour Fedora 41 alors que le paquet passwd est supprimĂ© ;
  • Le paquet cyrus-sasl-ntlm a Ă©tĂ© supprimĂ© ;
  • La gestion des droits utilisateurs pam_userdb passe de la base de donnĂ©es BerkeleyDB Ă  GDBM ;
  • Le filtre antispam bogofilter utilise SQLite au lieu de BerkeleyDB pour gĂ©rer sa base de donnĂ©es interne ;
  • Le serveur LDAP 389 passe de la version 2.4.4 Ă  la version 3.0.0 ;
  • Le paquet iotop est remplacĂ© par iotop-c ;
  • L'orchestrateur de conteneurs Kubernetes Ă©volue de la version 1.28 Ă  la version 1.29 ;
  • Par ailleurs ses paquets sont restructurĂ©s ;
  • Pendant que podman est mis Ă  jour vers la version 5 ;
  • Le paquet wget2 remplace le paquet wget en fournissant une nouvelle version ;
  • Le gestionnaire de base de donnĂ©es PostgreSQL migre vers sa 16e version ;
  • Les paquets MySQL et MariaDB sont remaniĂ©s et mis Ă  jour vers la version 10.11.

DĂ©veloppement

  • Mise Ă  jour de la suite de compilation GNU : GCC 14.0, binutils 2.41, glibc 2.39 et gdb 14.1 ;
  • La suite de compilateurs LLVM est mise Ă  jour Ă  la version 18 ;
  • Mise Ă  jour de la bibliothĂšque C++ Boost Ă  la version 1.83 ;
  • Le langage Go passe Ă  la version 1.22 ;
  • Le JDK de rĂ©fĂ©rence pour Java passe de la version 17 Ă  21 ;
  • Mise Ă  jour du langage Ruby 3.3 ;
  • Le langage PHP utilise la version 8.3 ;
  • La boĂźte Ă  outils pour le machine learning PyTorch fait son entrĂ©e dans Fedora ;
  • Le paquet python-sqlalchemy utilise la nouvelle branche majeure 2.x du projet, le paquet python-sqlalchemy1.4 est proposĂ© pour garder la compatibilitĂ© ;
  • La bibliothĂšque de validation des donnĂ©es Pydantic utilise dorĂ©navant la version 2 ;
  • La bibliothĂšque Thread Building Blocks passe du fil 2020.3 au fil 2021.8 ;
  • La bibliothĂšque OpenSSL 1.1 est supprimĂ©e ne laissant que la derniĂšre version de la branche 3.x ;
  • Les bibliothĂšques zlib et minizip utilisent leur variante zlib-ng et minizip-ng dorĂ©navant ;
  • Le langage Python ne bĂ©nĂ©ficie plus de la version 3.7.

Projet Fedora

  • L'Ă©dition Cloud sera construite avec l'utilitaire Kiwi dans Koji ;
  • Tandis que l'Ă©dition Workstation aura son ISO gĂ©nĂ©rĂ©e avec l'outil Image Builder ;
  • L'image minimale ARM sera construite avec l'outil OSBuild ;
  • Fedora IoT bĂ©nĂ©ficiera d'images Bootable Containers ;
  • Il bĂ©nĂ©ficiera Ă©galement des images Simplified Provisioning ;
  • Et le tout sera construit en utilisant rpm-ostree unified core ;
  • Fedora sera construit avec DNF 5 en interne ;
  • Les macros forge passent du paquet redhat-rpm-config Ă  forge-srpm-macros ;
  • La construction des paquets Ă©chouera si l'Ă©diteur de lien dĂ©tecte certaines classes de vulnĂ©rabilitĂ© dans le binaire en construction ;
  • Phase 3 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 ;
  • Clap de fin pour la construction des mises Ă  jour au format Delta RPM ;
  • Suite du projet de ne gĂ©nĂ©rer les JDKs qu'une fois, et les rempaqueter ainsi Ă  toutes les variantes du systĂšme ;
  • Compilation des paquets en convertissant plus d'avertissements comme erreurs lors de la compilation des projets avec le langage C ;
  • Les images immuables comme Silverblue seront nommĂ©es sous la dĂ©nomination Atomic pour Ă©viter la rĂ©fĂ©rence au terme immuable qui est confus pour les utilisateurs.

Tester

Durant le dĂ©veloppement d'une nouvelle version de Fedora Linux, comme cette version Beta, quasiment chaque semaine le projet propose des journĂ©es de tests. Le but est de tester pendant une journĂ©e une fonctionnalitĂ© prĂ©cise comme le noyau, Fedora Silverblue, la mise Ă  niveau, GNOME, l’internationalisation, etc. L'Ă©quipe d'assurance qualitĂ© Ă©labore et propose une sĂ©rie de tests en gĂ©nĂ©ral simples Ă  exĂ©cuter. Il suffit de les suivre et indiquer si le rĂ©sultat est celui attendu. Dans le cas contraire, un rapport de bogue devra ĂȘtre ouvert pour permettre l'Ă©laboration d'un correctif.

C'est trĂšs simple Ă  suivre et requiert souvent peu de temps (15 minutes Ă  une heure maximum) si vous avez une Beta exploitable sous la main.

Les tests à effectuer et les rapports sont à faire via la page suivante. J'annonce réguliÚrement sur mon blog quand une journée de tests est planifiée.

Si l'aventure vous intéresse, les images sont disponibles par Torrent ou via le site officiel.

Si vous avez déjà Fedora Linux 39 ou 38 sur votre machine, vous pouvez faire une mise à niveau vers la Beta. Cela consiste en une grosse mise à jour, vos applications et données sont préservées.

Nous vous recommandons dans les deux cas de procéder à une sauvegarde de vos données au préalable.

En cas de bogue, n'oubliez pas de relire la documentation pour signaler les anomalies sur le BugZilla ou de contribuer à la traduction sur Weblate. N'oubliez pas de consulter les bogues déjà connus pour Fedora 40.

Bons tests Ă  tous !

Commentaires : voir le flux Atom ouvrir dans le navigateur

❌