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