❌

Vue normale

À partir d’avant-hierFlux principal

Thorium Reader, un logiciel open-source permettant de visualiser et lire des E-Books

Thorium Reader est un logiciel gratuit et open-source (licence BSD 3) développé par EDR Lab permettant de visualiser les livres électroniques au format EPUB 3 sur Windows, Mac et GNU/Linux avec les DRM d'Adobe et les DRM françaises LCP et de lire les livres audio au format MP3.

Les DRM LCP sont utilisĂ©es notamment par les bibliothĂšques et mĂ©diathĂšques françaises et suisses, dans le cadre du PrĂȘt NumĂ©rique en BibliothĂšque (PNB). Elles sont considĂ©rĂ©es plus avantageuses pour les Ă©diteurs, car elles Ă©vitent de payer les tarifs amĂ©ricains d'Adobe DRM. Les DRM Readium LCP ont Ă©tĂ© conçues par Readium Foundation, les spĂ©cifications sont publiques et existent en tant que ISO/IEC 23078-2:2024.

Thorium Reader permet de naviguer dans les catalogues OPDS. CĂŽtĂ© accessibilitĂ© « les personnes incapables de lire les textes imprimĂ©s bĂ©nĂ©ficient dĂ©sormais d'une application de lecture EPUB 3 qui prend en charge les lecteurs d'Ă©cran tels que Jaws et NVDA sur Windows, Voice Over sur Mac Â» (ainsi que Narrator qui fait partie de Windows 11).

Le logiciel est traduit dans 25 langues. Techniquement il repose sur typescript, electron, reactjs, redux, saga et i18next.

Le site Web d'EDRLab nous apprend que c'est une organisation Ă  but non lucratif.

Son budget provient essentiellement de nos membres. EDRLab a dĂ©marrĂ© en France, mais compte dĂ©sormais 60 membres en Europe, AmĂ©rique du Nord, AmĂ©rique du Sud et Asie. Le financement du projet vient des membres fondateurs (Editis, Hachette Livre, Madrigall, MĂ©dias-Participations, Cercle de la Libraire, Syndicat national de l'Édition), de subventions publiques françaises (CNL (Centre National du Livre), MinistĂšre de la Culture) et de subventions supplĂ©mentaires des membres de l'EDRLab intĂ©ressĂ©s par l'ajout de fonctionnalitĂ©s spĂ©cifiques (FĂȘnix Editorial, Canadian Electronic Library, MLOL / Horizons Limited, Lyrasis).

Commentaires : voir le flux Atom ouvrir dans le navigateur

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

❌
❌