Vue lecture

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

Podcast Projets Libres saison 4 épisode 21 : postmarketOS, Linux pour faire durer votre smartphone pendant 10 ans !

Podcast Projets Libres saison 4 épisode 21 : postmarketOS, Linux pour faire durer votre smartphone pendant 10 ans !

L'équipe de Projets Libres est ravie de vous présenter un épisode de la série sur la libération des smartphones, dédié à la distribution Linux mobile postmarketOS.
Dans ce long entretien avec Antoine Martin et Ranny Bergamotte, deux contributeurs de confiance du projet, nous abordons une variété de sujets :

  • l'histoire du projet
  • ses différentes composantes (système, environnements de bureau, etc)
  • son équipe
  • son organisation
  • sa gouvernance et ses évolutions actuelles
  • son rapport avec les différents projets upstream
  • son financement
  • son système de tests matériel distribué par internet (hardware-CI)

Nous remercions chaleureusement Ranny pour sa réécriture complète de la traduction anglaise.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Sortie de Trisquel GNU/Linux 12 « Ecne »

La distribution Trisquel GNU/Linux est sortie en version 12 dite « Ecne ». Elle est basée sur Ubuntu et plus précisément sa version 24.04 dite « Noble Numbat » qui est la précédente version maintenue à long terme (Long-Term Support, ou LTS pour les intimes). Mais il y a encore un support de 3 ans (jusqu'en mai 2029) par Canonical (la société derrière Ubuntu), donc ce n'est pas grave, et ça s'explique sans doute par le peu de force de la distribution.

Mais de toute façon, quel est l'intérêt de cette énième distribution GNU/Linux ? C'est rien de moins qu'une des rares qui est 100% libre et donc approuvée par la FSF (Free Software Foundation) sur la base des GNU FSDG (Free System Distribution Guidelines), contrairement par exemple à Debian qui n'en était historiquement pas loin et a récemment régressé. Avec Trisquel, il n'y a donc notamment pas de blob privateur dans le noyau Linux (car oui, de base il en contient) et pas d'incitation à installer du logiciel privateur.

De plus, Trisquel se veut respectueux de la vie privée. On peut constater ça avec le cas des navigateurs web. Firefox n'est pas proposé au profit de Abrowser qui en est une version dérivée (fork) avec quelques améliorations. De plus, GNU IceCat est proposé et va lui plus loin. Enfin, si on veut un autre moteur web majeur, il y a ungoogled-chromium, en plus bien sûr des navigateurs web basés sur WebKit (comme GNOME Web).

Si la souveraineté ordinatique vous intéresse (il parait que c'est devenu à la mode, dans les discours du moins…), Trisquel GNU/Linux est assurément un bon choix si vous vous fichez d'avoir les dernières versions des logiciels. Toutefois il y a aussi GNU Guix si ça vous dérange.

Pour l'anecdote, un VIP du logiciel libre utilise Trisquel. Et oui, rien de moins que Richard Stallman !

Commentaires : voir le flux Atom ouvrir dans le navigateur

Mageia 10 : cycle de publication alpha, bêta, rc

Si vous avez envie de regarder sous le capot et vous impliquer dans le développement d’une distribution Linux c’est le moment de participer aux tests.
Mageia a publié une première version alpha en décembre 2025, la version bêta est désormais disponible et une version candidate est envisagée pour mars/avril 2026 pour publication de Mageia 10 « quand ce sera prêt », l’occasion de revenir sur les différentes étapes et l’implication possible.

Pour l’apparence de la distribution, un concours artistique a été lancé du 29 janvier au 25 février 2026, la participation des plus graphistes d’entre vous est la bienvenue ! Le choix pour la Mageia 10 va bientôt être fait, il reste toujours quelques points à améliorer par la suite ;-)

Bref, une version 10 de Mageia qui s’inscrit dans la continuité de la stabilité de Mageia 9 : le cycle de publication est là pour l’avérer, il y aura des pleurs, des cris et de grandes joies à réussir à faire fonctionner au mieux vos logiciels de prédilection.

Sommaire

Pour cette dépêche, le parti pris est de privilégier les annonces en français. Pour autant, le suivi effectif est à faire en anglais (ensuite décliné au besoin en français).

Quelques sujets pris en compte pour Mageia 10 :

  • choix du noyau Linux 6.18.x qui est une version LTS
  • live ISO 64 bits en 3 versions : KDE, GNOME et XFCE
  • conservation d’une version 32 bits (i686 et non plus i586), nécessitant des tests et une définition du périmètre, un live ISO basé sur XFCE
  • Wayland par défaut pour GNOME, éventuellement (à tester) pour Plasma KDE et autres environnements le proposant, marquant la résorption de Xorg lorsque possible ; plusieurs compositeurs Wayland pour LXQt sont intégrés (Labwc, niri, hyprland, sway)
  • bon fonctionnement de l’infrastructure de mise à jour via URPMI, basé sur RPM ou DNF
  • Peaufinement de l’intégration des pilotes libres de GPU pour Intel et AMD ; pour les pilotes nVidia ça va être plus compliqué :/
  • des mises à jour de vos logiciels préférés (n’hésitez pas à les préciser en commentaire)

Voici les différents cycles et les choix envisageables restant à chaque étape.

Cycle alpha : reprise de publication

Objectif : stabilisation du périmètre envisagé, identification des montées de version de logiciels restant à faire lors du cycle de publication.

Cela permet d’avoir des premiers ISO installables, et de revoir les plannings respectifs de ce qui est à intégrer : des langages (Rust, Ruby…), des logiciels (FreeCAD 1.1 en février donc plutôt lors de la bêta…).

Premières personnes à tester généralement issues de Cauldron—la version de développement en rolling-release—dont l’installation a pour objectif d’avérer la cohérence de l’installation et d'identifier sur le bugzilla les bogues bloquants ce qui en permet le suivi lors de chacun des cycles. Une version plus jolie des bogues bloquants est disponible, même s’ils restent à corriger ;-)

Les arborescences de dépôt 10 sont créées sur les miroirs, pour permettre de gérer l’ajout de nouveaux miroirs au fur et à mesure. Pendant tout le cycle de publication, le fonctionnement est similaire à ce qui se passe en cauldron : l’arborescence release/ reçoit les mises à jour de paquets, rien dans updates/.
Le changement des dépôts de cauldron à 10 est nécessaire pour ne pas rester avec la version de développement une fois Mageia 10 officiellement publiée ; une réinstallation reste préconisée pour ne pas avoir de reliquat des bogues corrigés lors du cycle de publication (même si enlever les différentes versions de noyaux et de bibliothèques permet de faire un 1er ménage, il peut y avoir des reliquats de configuration intermédiaire qui perdurent).

Cycle bêta : consolidation des tests et des choix pour la version à publier

Objectif : stabilisation des versions de logiciels envisagées, identification des correctifs à l’installeur.

Lancement du concours de visuels pour fonds d’écrans de Mageia 10, icônes et économiseurs : du 30 janvier 2026 au 25 février 2026. C’est la bêta2 qui vous fera découvrir la nouvelle apparence retenue pour Mageia 10.

Les pilotes nvidia posant des problèmes récurrents, il est envisagé de ne pas proposer leur intégration aux ISO (ils seraient à installer par la suite). Les tests sont les bienvenus. La version nvidia470 peut encore être configurée après installation initiale : elle est conservée pour les anciennes cartes graphiques—même si elle n’est plus maintenue tandis que la version 390 est obsolète et ne fonctionne plus avec les nouveaux noyaux Linux—et les versions nvidia580 et nvidia590 sont proposées (paquets nvidia-current_all et nvidia-newfeature-all permettant l’ajout des modules dkms), ainsi que le pilote ne fonctionnant qu’à partir des versions de cartes RTX. C’est le pilote nouveau qui est utilisé par défaut lors de l’installation initiale.

Les pilotes graphiques libres de AMD et Intel ont bien sûr aussi été mis à jour, ils sont disponibles directement dans les ISO live d’installation.

Les tests pour Plasma KDE avec la gestion par Wayland permettront d’identifier l’opportunité de proposer Wayland par défaut, le choix alternatif de Xorg restant disponible.

L’utilisation de clé USB persistante (fonctionnalité apparue avec Mageia 7) pourrait permettre d’avoir sur soi une clé d’installation live à jour et bénéficiant des derniers correctifs : démarrage avec clé USB live sur PC à installer, premiers diagnostics de bon fonctionnement du matériel sans installation—utilisation de la partition persistante pour prendre des notes—  afin de lancer l’installation dans les meilleures conditions, bénéficiant des correctifs de l’installeur notamment.

Par exemple, selon la date de publication de FreeCAD 1.1—prévue initialement courant février 2026—il pourrait être disponible dans les dépôts de paquet de Mageia 10 (pas sur les ISO, il n’y a déjà plus beaucoup de place :D).

Cycle version candidate : finalisation

Objectif : pré-version de la version finale, à publier « quand c’est prêt »

C’est l’occasion de finaliser les différentes documentations de Mageia 10.
Les errata ne conservent que ce qui n’a pas pu être corrigé avant publication et nécessitant une intervention manuelle, ils seront tenus à jour après publication pour les cas spécifiques découverts après coup lors d’une utilisation plus large de la distribution.
Les Notes de version ne vont plus évoluer beaucoup, permettant de stabiliser les traductions dans d’autres langues que l’anglais qui reste la référence.

Version finale

Les miroirs pour les paquets peuvent être mis à jour avec la version 10 : l’arborescence release/ ne va plus évoluer et les mises à jour de paquets arrivent dans updates/.

Peaufinement des visuels retenus pour la version 10.

La notification pour proposer de monter automatiquement de version de distribution à partir de Mageia 9 interviendra un peu de temps après la sortie de la version finale : le temps de finir de les mises à jour pour clore les bogues non encore corrigés pour la version finale.

Différences de fonctionnement entre version stable et le cycle de publication.

Le cycle de publication s’appuie sur Cauldron, la version en développement continu ou rolling-release :

  • il n’y a pas d’updates/ : les paquets sont directement remplacés dans release/
  • un corollaire est que lors d’une mise à jour d’un ensemble de paquets (correction), les miroirs ne seront pas forcément complètement à jour, ce qui peut demander une relance de urpmi --auto-update pour mise à jour complète : en cas d’échec temporaire, une relance plus tard est nécessaire
  • ce genre de désynchronisation arrive peu souvent en version stable, un peu plus souvent en Cauldron—ce qui est normal (cela se fait particulièrement sentir lors d’une reconstruction en masse) ;-)

S’impliquer pour Mageia 10

À vous de décider ce que vous souhaitez faire ;-) En comprenant que c’est une version en évolution—certaines choses ne fonctionneront pas—et certaines pourront être corrigées pour la version finale (ou peu après :D). De quoi se mettre le pied à l’étrier pour la version suivante : nouveaux logiciels à (faire) empaqueter, nouvelles versions à prendre en compte…
C’est l’occasion de s’astreindre à lancer certaines applications à partir d’un terminal pour récupérer le maximum de logs possibles, ou d’apprendre à diagnostiquer une configuration spécifique causant des soucis—idéalement pour travailler en amont (upstream) pour faire prendre en compte des correctifs et améliorations.

Vous pouvez vous coordonner en français auprès de nos collègues de MLO pour effectuer au mieux vos remontées d’information.

Rien que les tests permettent de bénéficier de versions actualisées par rapport à Mageia 9 et remonter des bugs restant dans l’intégration de vos logiciels de prédilection à l’environnement de bureau de votre choix. Il y a aussi beaucoup de traductions à effectuer.

C’est l’opportunité de (re-)lire les documentations et les actualiser, notamment les nouvelles fonctionnalités.

Exemples d’utilisations

Je vous laisse ajouter des cas d’utilisation qui vous seraient spécifiques en commentaires.
J’ai la chance de participer à un fablab qui me donne accès à divers matériels pour tester :

  • EeePC ne fonctionnant pas en x86_64 (donc i686 maintenant), netbooks hybrides (tablette tactile + clavier détachable) limités à 2 Go de RAM et un UEFI 32 bits exotique même quand le processeur gère le x86_64
  • (très) vieux portables et ordis—pour la plupart des gens, vieux = plus de 5 ans—là, c’est plutôt (l’ami de Mickey<) de la période 2008-2014 : des MacBook Pro, des iMac, plein de core2duo / Athlon (ça c’est du x86_64 au moins) ou cartes nvidia déclarées obsolètes (des quadro à l’époque réputées de qualité professionnelle, on voit ce que ça veut dire pour nvidia… :/)
  • (très) vieux périphériques : gamepad Sidewinder, volant MT Logic wheel pour supertuxkart avec connectique broche DA-15 jaune (si vous avez d’autres périphériques—préférentiellement en USB—je suis preneur _o/ et, oui, c’est pas loin de Paris…)
  • quelques Raspberry Pi et assimilés—donc architecture ARM—mais ce n’est pas l’axe principalement retenu pour Mageia 10 :/ et pour le coup, Debian reste une valeur sûre pour la diversité des logiciels disponibles, même si des travaux communs avec le projet Fedora permettent de se tenir à niveau ;-)

Et bien sûr, des logiciels classiques dans un fablab qui fonctionnent bien (plutôt en flatpak) : Cura et Bambustudio pour l’impression 3D, IDE Scratch pour robots Thymio… et Inkscape / FreeCAD / KiCAD sur du matériel un peu plus récent et moins contraint en ressources ;-)

Si vous utilisez des window managers spécifiques, cela m’intéresse d’avoir des retours aussi (enlightenment, LXQt, WindowMaker… autres ?), Mageia proposant des installations cohérentes (intégration environnement, logiciels…) via les méta-paquets task- qui permettent d’installer un ensemble de dépendances automatiquement.

Bons tests _o/

Commentaires : voir le flux Atom ouvrir dans le navigateur

JemaOS : un système d’exploitation français et souverain pour lutter contre l'obsolescence

JemaOS est un projet de système d’exploitation français, développé à Sophia Antipolis, qui propose une réponse concrète aux enjeux de souveraineté et de numérique responsable.

Le contexte est marqué par l’arrêt imminent du support de Windows 10, une transition qui menace de mettre au rebut près de 400 millions de PC encore fonctionnels à travers le monde. Face à cette obsolescence matérielle massive, JemaOS permet de réhabiliter ces parcs informatiques (machines de 2010 à 2025) en offrant une alternative fluide et sécurisée.

Architecture Open-Core et Optimisation Cible

Sous le capot, JemaOS s’appuie sur un modèle Open-Core combinant des briques de Gentoo Linux, Arch Linux et Chromium. Pour garantir des performances maximales sur du matériel ancien, le système mise sur une optimisation par compilation pour l’architecture cible. Cette approche permet de tirer le meilleur parti de chaque processeur, là où des distributions génériques peuvent accuser des lenteurs.

Sécurité par immuabilité et sandboxing

La sécurité du système repose sur deux piliers majeurs :

  • L’immuabilité : Le système de fichiers racine est verrouillé en lecture seule, protégeant le cœur de l’OS contre les corruptions accidentelles ou les écritures malveillantes.
  • Le sandboxing : Toutes les applications et processus sont isolés nativement dans des « bacs à sable ». Cette isolation stricte empêche une faille dans une application de compromettre l’intégralité du système, rendant l’usage d’antivirus tiers obsolète.

Pour l’interface, le choix s’est porté sur Aura Shell (Ash) afin d’offrir une expérience utilisateur réactive et épurée.

Le « dispositif Jema » : le Plug & Play pour s’affranchir des configurations complexes pour les non-initiés

L’aspect le plus original de JemaOS est son mode de déploiement via le dispositif Jema (NdM (rectifiée le 22 mars suite à mise à jour de la doc du projet): qui est au format clé USB mais est « un véritable système embarqué complet. Faisant l'objet d'un brevet, (…) Intégrant son propre processeur, sa mémoire vive (RAM) et son espace de stockage interne). » L’idée est de supprimer toute la complexité habituelle : plus besoin de créer des clés USB bootables, de partitionner des disques ou de modifier des réglages BIOS/UEFI complexes.

On branche le dispositif, et le système démarre. Grâce à un chargeur d’amorçage compatible Secure Boot (via « Enroll MOK »), JemaOS tourne en isolation complète. Il exploite les ressources (CPU/RAM) de la machine hôte sans jamais toucher aux données du disque dur interne.

Écosystème applicatif : PWA et P2P

Pour rester léger, le système déporte la partie logicielle vers des Progressive Web Apps (PWA), dont beaucoup fonctionnent en Peer-to-Peer (P2P) pour garantir la confidentialité :

  • Anima & Nephtys : Messagerie et visioconférence en P2P.
  • JemaNote : Prise de notes avec assistance IA (Mistral).
  • OsiVibe : Un éditeur vidéo 4K multi-pistes qui s’exécute directement dans le navigateur.

Gestion de parc et souveraineté

Le modèle économique semble s’appuyer sur une offre SaaS pour les entreprises, permettant une gestion centralisée assez complète :

  • Pilotage de parc : Suivi des machines, sauvegardes et gestion des droits d’accès.
  • Administration : Gestion des dispositifs Jema et support technique.
  • Souveraineté : L’infrastructure Cloud est hébergée en France, ce qui permet de rester sous protection du RGPD et d’échapper au Cloud Act américain.

Une initiative française intéressante à suivre pour ceux qui s’intéressent au numérique responsable.

NdM: les offres Pro/Ultime/Premium sont orientées entreprises avec un paiement mensuel par utilisateur. Les mises à jour OTA majeures sont payantes. Il est possible d'utiliser JemaOS sans payer (cf la documentation) en désactivant les mises à jour automatiques et installant manuellement les nouvelles versions.
Sur les 14 dépôts publics : la licence varie suivant les dépôts (MIT, AGPLv3, BSD avec clause publicitaire (dont une concernant Google (sic), un dépôt avec le logiciel WidevineCdm propriétaire de Google). La plupart des dépôts n'ont qu'un seul contributeur johnkryptochain, visiblement intéressé par les cryptomonnaies, Telegram et les NFT ; l'autre contributeur a deux commits sur un unique dépôt. L'entreprise qui porte le projet a 10 salariés d'après le site.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Emmabuntüs renforce l’accessibilité avec les versions Debian Édition 6 1.00 et 5 1.05

Le collectif Emmabuntüs annonce deux publications récentes mettant fortement l’accent sur l’accessibilité numérique, fruit d’un travail mené en grande partie avec et par des bénévoles non-voyants et malvoyants, directement impliqués dans la conception, les tests et les améliorations ergonomiques de la distribution.

Nouvelle fenêtre d’accessibilité des EmmaDE6/EmmaDE5

La version Emmabuntüs Debian Édition 6 1.00, basée sur Debian 13 (Trixie) avec les environnements Xfce et LXQt, introduit de nombreuses améliorations destinées aux personnes malvoyantes ou non-voyantes : interface dédiée à l’accessibilité, synthèse vocale améliorée (espeak, MBROLA, Piper), profils Orca, support d’embosseuses Braille, intégration de LIOS (OCR), ainsi que divers scripts simplifiant la prise en main. Cette version est notamment destinée à des déploiements au Togo, en partenariat avec les associations françaises A.S.I YOVOTOGO, Mutualistes Sans Frontières et la FETAPH (Fédération Togolaise des Associations de Personnes Handicapées).

En parallèle, la version Emmabuntüs Debian Édition 5 1.05, basée sur Debian 12 (Bookworm) et disponible en 32 et 64 bits, bénéficie des mêmes avancées en matière d’accessibilité. Elle permet ainsi de poursuivre le reconditionnement d’ordinateurs plus anciens, tout en offrant une expérience utilisateur inclusive.

Ces deux versions illustrent l’engagement d’Emmabuntüs en faveur de l’inclusion numérique, du logiciel libre, du réemploi de matériel informatique, ainsi que la place centrale offerte à l’expertise d’usage apportée par ses bénévoles concernés par le handicap visuel.

Le projet reste ouvert aux contributions, notamment pour les tests d’accessibilité, la documentation et l’amélioration des outils destinés aux utilisateurs malvoyants ou non-voyants.

Fin mars, nous publierons une nouvelle version d’Emmabuntüs Debian Édition 6 1.01, plus légère et plus modulable, afin de permettre à chacun de choisir les logiciels dont il a réellement besoin. Nous recherchons des bénévoles pour participer aux tests de cette version.

Commentaires : voir le flux Atom ouvrir dans le navigateur

PearOS 25.12 NiceC0re : Le retour d'une distro emblématique

PearOS renaît avec sa plus grande refonte : une base Arch Linux, KDE Plasma hautement personnalisé, et un design révolutionnaire Liquid Gel

PearOS, la distribution Linux emblématique créée en 2011 par David Tavares pour offrir une esthétique MacOS sous le pingouin, connaît un renouveau remarquable. Après des années d'oubli relatif, PearOS NiceC0re 25.12 revient en décembre 2025 avec une transformation radicale qui le positionne comme un concurrent sérieux dans le paysage des distributions Linux axées sur le design.

Un changement de fondations

La nouvelle version abandonne définitivement ses racines Ubuntu pour embrasser Arch Linux. Cette migration stratégique offre deux avantages majeurs aux utilisateurs : un accès à des paquets plus à jour via les dépôts généreux d'Arch, et un modèle de publication en rolling release. Les utilisateurs n'auront plus besoin d'attendre des versions majeures pour bénéficier des dernières innovations—une mise à jour unique suffit à recevoir les améliorations en continu.

Sous le capot, PearOS 25.12 tourne sur Linux kernel 6.17 et s'accompagne de KDE Plasma 6.5.3. Cette fondation moderne garantit un système performant, stable et doté d'une très large compatibilité matérielle.

L'identité visuelle : Liquid Gel et Glassmorphism

Le cœur de cette nouvelle direction réside dans la philosophie de design cristallisée par le concept de Liquid Gel. Loin d'être une simple application de thème, cette approche réimagine complètement l'interface utilisateur avec des effets de glassmorphism avancés, des animations fluides et des transitions viscérales qui donnent l'impression d'un système extrêmement raffiné.

Le résultat ? KDE Plasma, l'un des bureaux les plus puissants de l'écosystème Linux, a été fortement personnalisé pour reproduire l'esthétique des versions récentes de MacOS. Les thèmes d'icônes, les arrangements de panneaux et chaque détail visuel ont été soigneusement calibrés pour offrir une expérience utilisateur cohérente et agréable.

Un installateur modernisé en Electron

Première d'une longue série d'innovations, PearOS NiceC0re introduit un nouvel installateur créé avec Electron et Node.js. Cette approche web-based, bien qu'actuellement en phase béta, symbolise la volonté du projet de s'approprier les meilleures pratiques modernes de développement.

À quoi s'attendre à l'avenir

L'équipe de développement, actuellement menée par Alexandru Bălan (développeur roumain), ne s'arrête pas là. Trois éléments majeurs sont en chantier :

  • Soda DE : Un nouvel environnement de bureau de nouvelle génération conçu pour redéfinir la manière dont les utilisateurs interagissent avec Linux. Si Soda DE aboutit à ce qui est promis, il pourrait éclipser même KDE Plasma en termes de modernité.
  • Stabilité renforcée : Malgré la nature bêta de l'installateur actuel, l'équipe s'engage pour des améliorations substantielles en fiabilité système, optimisation des performances et correction des bogues.
  • PearOS Pahoe : La prochaine génération de PearOS, déjà en développement, promet une évolution encore plus ambitieuse.

L'équipe a mis l'accent sur l'accessibilité du code source et encourage les contributeurs à explorer le projet sur GitHub. Pour les curieux, l'ISO est d'ores et déjà disponible au téléchargement sur le site officiel.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Sortie de Fedora Linux 43

En ce mardi 28 octobre, les utilisateurs du Projet Fedora seront ravis d'apprendre la disponibilité de la version Fedora Linux 43.

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 de GNOME

Sommaire

Expérience utilisateur

L'environnement de bureau GNOME est proposé dans sa version 49. Cette version apporte comme d'habitude de nombreux changements.
Tout d'abord l'application Showtime remplace Totem en guise de lecteur vidéo par défaut. Basée sur la bibliothèque GTK4 et libadwaita, elle reprend les canons esthétiques minimalistes des applications GNOME. L'interface s’efface derrière la vidéo, n'affichant que les fonctions de base essentielles.

De même l'application pour afficher les documents notamment au format PDF passe de Evince à Papers. De la même manière que précédemment, elle utilise la nouvelle pile logicielle plus moderne, cela permet de refaire le visuel de l'application et d'améliorer dans le même temps les performances. La signature numérique des documents est aussi mieux intégrée de même que les annotations des documents.

L'application de calendrier a eu une amélioration de son accessibilité avec un focus important sur la navigation exclusive au clavier, ce qui a nécessité une refonte de l'interface. L'interface s'adapte en fonction de la taille de l'écran avec notamment la barre latérale qui peut être masquée. Il est également possible d'exporter des événements dans un fichier ICS.

Le navigateur Web bénéficie de nombreuses améliorations comme un bloqueur de publicités plus efficace avec plus de listes de blocage disponibles. La recherche dans la page est plus complète avec la prise en compte de la casse ou de la recherche de mots entiers uniquement. L'édition des marques pages, ainsi que le menu de sécurité pour la gestion des mots de passes ou des cartes de sécurité, ont été remaniés pour être plus simples.

La boutique logicielle bénéficie d'une amélioration significative de ses performances, ce qui était son principal point faible en partie à cause du volume de données à gérer pour les différentes applications disponibles provenant des Flatpak. La boutique consomme moins de mémoire, navigue plus rapidement d'une application à une autre et effectue des recherches efficacement.

La fonctionnalité de bureau distant s'améliore avec la prise en charge des entrées multipoints pour ceux utilisant un écran tactile. De plus le curseur de souris peut fonctionner avec un positionnement relatif ce qui était nécessaire pour quelques applications ou jeux vidéo. Ceux qui le souhaitent peuvent ajouter des écrans virtuels pour une telle session même s'il n'y a pas d'écrans physiques supplémentaires.

De manière plus générale, l'écran de verrouillage permet de contrôler basiquement les applications multimédia, en particulier pour la musique. Il est d'ailleurs possible d'arrêter ou de redémarrer la machine depuis cet écran de verrouillage en activant l'option idoine avec la commande gsettings set org.gnome.desktop.screensaver restart-enabled true. Le bouton Ne pas déranger passe de la zone de notifications au menu principal de GNOME pour une meilleure cohérence de l'interface.

Enfin de nouveaux fonds d'écran sont proposés afin d'exploiter les nouvelles capacités des écrans HDR et l'espace de couleur Display P3 qui sont pris en charge sur les machines compatibles. Capacités HDR qui ont été améliorées par ailleurs avec de nouveaux paramètres pour gérer finement la luminosité de ces types d'écran.

GNOME fonctionnera uniquement en tant que session Wayland, les paquets liés à GNOME pour session X11 sont supprimés. Le projet GNOME a décalé cette décision pour sa prochaine version numérotée 50, mais Fedora maintient le cap car la qualité de ces sessions n'est pas aussi bonne que Wayland faute de tests et de maintenance de la part du projet depuis de nombreuses années. Grâce à XWayland, GNOME reste en capacité d'afficher et de gérer les applications (de plus en plus rares) reposant uniquement sur X11. Cela clôt en un sens la transition vers Wayland pour GNOME entamée il y a 9 ans déjà avec Fedora 25.

Tous les Spins disposent par défaut de la nouvelle interface web d'Anaconda. Fedora Linux 42 ne l'avait proposée que pour Fedora Workstation, en partie parce que certaines options ont dû être ajoutées pour supporter les Spins. En effet, sous GNOME, une partie de la configuration est faite après l'installation avec l'application GNOME Initial Setup. Par conséquent les spins pourront en plus configurer depuis Anaconda la date et l'heure, le compte utilisateur et le nom de la machine. De même, la configuration de la disposition clavier est gérée de manière légèrement différente. Enfin, l'interface n'est pas forcément affichée par une session de Firefox mais peut l'être via le navigateur web fourni par l'environnement en question.

Sur les machines x86_64 compatibles UEFI, Anaconda ne permettra plus d'installer Fedora si le format de partitionnement est basé sur MBR au lieu de GPT. Si la norme UEFI autorise une telle configuration, en réalité sa prise en charge correcte dépend des constructeurs et n'est pas bien testée notamment par l'équipe de Fedora ce qui rend une telle configuration peu fiable. De plus, le chargeur de démarrage GRUB2 suppose déjà qu'un système UEFI implique une table de partitions GPT. Cela a été maintenu par Fedora notamment pour permettre son utilisation dans le service cloud AWS qui ne proposait que de tels systèmes à une époque. Mais cette limitation n'a plus lieu d'être et sa suppression simplifie le test et réduit le risque de crashs au moment de l'installation. Cela ne concerne pas les autres architectures comme ARM car leur implémentation repose plus souvent sur MBR et est mieux gérée.

Écran de verrouillage avec contrôle multimédia

L'installateur Anaconda utilise le gestionnaire de paquet DNF dans sa 5e version dorénavant. Cela améliore la vitesse des opérations à l'installation de Fedora et uniformise la gestion des paquets au sein de Fedora en simplifiant aussi les tests de la distribution.

Fin de support de la modularité des paquets RPM dans l'installateur Anaconda. Les modules ont disparu dans Fedora depuis Fedora Linux 39, ce changement devenait nécessaire avec la non prise en charge des modules par DNF 5 qui est utilisé maintenant par Anaconda comme expliqué précédemment. Cela améliore aussi la maintenance d'Anaconda et de sa documentation en supprimant cette spécificité qui n'est plus utilisée.

Activation de la mise à jour automatique du système pour la variante Fedora Kinoite. Grâce au système atomique, la mise à jour se fait en arrière plan et est appliquée au prochain redémarrage. La fiabilité de l'opération avec la possibilité de revenir à l'état précédent autorise une mise à jour automatique sans trop de problèmes pour simplifier la vie de l'utilisateur et améliorer la sécurité. Les mises à jour des firmware ne sont pas concernées pour des raisons de fiabilité. La mise à jour se fait par défaut de manière hebdomadaire et une notification pour inviter à redémarrer est affichée quand c'est pertinent. Cette fonctionnalité peut être coupée et la fréquence des mises à jour reste configurable.

La police d'affichage d'émojis Noto Color Emoji utilise son nouveau format basé sur COLRv1 pour améliorer le rendu. Le rendu est meilleur car les images sont vectorielles et non sous forme d'images bitmap qui sont moins jolies quand la taille d'affichage augmente. Le tout en prenant moins d'espace disque.

Le fichier initrd utilisé lors du démarrage est compressé avec zstd pour un démarrage plus rapide du système et une taille d'installation plus petite. Cela remplace la dépendance au binaire xz utilisé jusqu'alors, les tests montrent une baisse de la taille d'installation de quelques méga octets pour un temps de démarrage réduit de quelques secondes en moins.

Nouvelle application de lecture vidéos de GNOME

Gestion du matériel

La taille de la partition /boot augmente de 1 Gio à 2 Gio par défaut. En effet la taille des firmwares, des initrd, du noyau, etc. ne cessent d'augmenter alors que la partition est restée à 1 Gio depuis 2016. Cela permet de réduire le risque de manquer de place dans un futur proche pour les nouveaux systèmes.

Prise en charge de la technologie Intel TDX pour exécuter des machines virtuelles avec une plus grande isolation mémoire depuis Fedora Linux. Pour les machines compatibles, cela signifie que chaque machine virtuelle tourne dans un espace mémoire dédié qui est chiffré ce qui apporte des garanties de sécurité et d'intégrité des données pour le système virtualisé.

Mise à jour de Greenboot vers la réimplémentation en Rust. L'objectif de ce composant est de fournir une vérification du système au démarrage et de redémarrer vers un état précédent du système en cas de défaut constaté ce qui est possible dans un système atomique et améliore l'expérience utilisateur en cas de mise à jour défectueuse. L'utilisateur a par ailleurs la possibilité d'ajouter ses propres tests. La précédente implémentation était en Bash et ne proposait que la prise en charge des systèmes basés sur RPM OSTree. Maintenant il peut gérer les systèmes reposant sur bootc qui est de plus en plus employé.

Internationalisation

La police de type monospace aura une police alternative de ce type par défaut en cas de manque dans une langue donnée. Jusqu'ici une police sans-serif était utilisée par défaut ce qui n'était pas idéal car les contextes d'usage sont différents et cela pouvait donner lieu à des comportement imprévisibles suivant les polices installées sur le système. Cela concerne notamment les langues suivantes : l'arabe, l'hébreu, le thaï, le perse, l'hindi, le khmer, etc.

Administration système

Le gestionnaire de paquets RPM passe à la version 6.0. Mais les paquets fournis par le projet Fedora utilisent encore le format de la 4e version. Cette version se focalise sur une amélioration de sécurité, par exemple les clés OpenPGP affichent la version complète de l'id de la clé si l'empreinte numérique n'existe pas. Il est possible de fournir plusieurs signatures à un même paquet permettant d'utiliser des clés différentes suivant la provenance et les objectifs. La construction du paquet peut générer automatiquement la signature ce qui est intéressant dans le cadre de l'empaquetage local. Les clés OpenPGP version 6 sont prises en charge de même que les algorithmes dits post quantiques à base de courbes elliptiques. Il est également possible d'utiliser Sequoia-sq au lieu de GnuPG. Les paquets générés avec la 3e version ne sont cependant plus exploitables.

Réduction du nombre de règles SELinux dontaudit liés au type unlabeled_t. L'objectif de ces règles c'est souvent de réduire le nombre de rapports d'accès anormaux qui sont des faux positifs ou des accès bénins effectués par des applications mal écrites. Cette avalanche de notifications serait contre productive mais cacher ces accès sous le tapis ne permet pas de corriger ces comportements problématiques et complexifie le débogage. L'objectif est de désactiver seulement certaines de ces règles de la politique et non de les supprimer entièrement. Ainsi si le nouveau comportement vous pose problème, vous pouvez exécuter la commande # setsebool -P dontaudit_unlabeled_files 1 pour rétablir le comportement précédent.

Le paquet gnupg2 pour fournir l'outil de chiffrement est dorénavant découpé en plusieurs sous paquets. Cela permet de réduire la taille du système par défaut car uniquement les paquets nécessaires seront installés par défaut, laissant de côté les binaires plus optionnels. L'autre bénéfice est de simplifier le remplacement par Sequoia-PGP car il nécessite la présence de certains binaires de GnuPG mais en remplace d'autres ce qui n'était pas possible de faire avec un paquet unique. Les installations existantes installeront tous les sous paquets par défaut pour éviter de casser les systèmes existants.

Le filtre d'impression Foomatic-rip rejette les valeurs inconnues. En effet il est utilisé pour construire des commandes shell, PostScript ou Perl qui sont ensuite exécutées avant d'envoyer la tâche à l'impression via les options FoomaticRIPCommandLine, FoomaticRIPCommandLinePDF et FoomaticRIPOptionSettings. Cette flexibilité permet d'écrire ou de modifier facilement le pilote de l'imprimante en question mais est source de vulnérabilités de sécurité aussi. Pour limiter les risques, par défaut aucune valeur pour ces options ne sont autorisées. L'utilisateur doit exécuter foomatic-hash une fois pour vérifier la validité des options et s'assurer qu'elles ne font rien de problématiques et déplacer le dit fichier dans /etc/foomatic/hashes.d pour autoriser leur utilisation. Cela ne concerne à priori que des vieux pilotes d'imprimantes et une partie de ceux fournis par CUPS ont déjà les validations nécessaires. D'autres devraient venir progressivement. Les pilotes d'imprimantes déjà installés au niveau du système seront aussi automatiquement validés après une mise à niveau vers Fedora Linux 43. À cause de la flexibilité de la méthode d'origine, corriger ou détecter tous les comportements problématiques automatiquement n'est pas possible.

Le projet 389 Directory Server ne permet plus de modifier ses bases de données BerkeleyDB. Les bases de données utilisaient par défaut LMDB depuis Fedora Linux 40 et l'abandon de BerkeleyDB se fera à priori pour Fedora Linux 45. L'objectif est de permettre la lecture des données pour les migrer vers le nouveau format et ainsi forcer les utilisateurs à effectuer la migration avant son abandon total.

Nouveau visionneur de documents GNOME

Le gestionnaire de base de données PostgreSQL est mis à jour à sa 18e version. Cette version améliore les performances dans le sous-système des entrées-sorties asynchrones et dans l'optimiseur des requêtes. D'ailleurs, la migration d'une base de données vers une version suivante conserve les statistiques de l'optimiseur. Une nouvelle fonction uuidv7() permet de générer un UUID autorisant un tri basé sur un critère temporel. Par défaut les colonnes générées, celles dont le contenu est créé durant une opération de lecture, sont virtuelles et ne résident pas sur le disque. Les B-tree index multi-colonnes peuvent être utilisés plus souvent notamment s'il n'y a pas de contraintes sur les premières clés mais uniquement sur la dernière. Le protocole OAuth peut être utilisé pour s'authentifier dorénavant. Comme d'habitude, les versions 17 et 16 de ce logiciel restent disponibles dans les dépôts autorisant une mise à niveau progressive.

Le gestionnaire de base de données MySQL passe par défaut à la version 8.4. La version 8.4 était déjà proposée dans les dépôts, elle remplace juste la version 8.0 en tant que version de base. Cette dernière reste disponible via le paquet mysql8.0.

Le serveur de courriels Dovecot est mis à jour vers sa version 2.4. ( https://doc.dovecot.org/2.4.0/installation/upgrade/2.3-to-2.4.html ). Cette version change de manière significative la configuration qui nécessite une adaptation. Il est maintenant possible de stopper une commande mail qui prend du temps proprement. Pour l'authentification, les fonctions de hashage SCRAM-SHA-1-PLUS et SCRAM-SHA-256-PLUS sont maintenant disponibles de même que les liaisons de canal TLS. La bibliothèque Lua permet d’interagir avec le client DNS et HTTP fourni par Dovecot.

Le serveur d'application Tomcat est mis à jour vers sa version 10.1. Cela signifie qu'il suit la spécification Jakarta EE 10 ce qui implique un nouvel espace de nom qui passe de javax.* à jakarta.*. À cause de ce changement, la compatibilité ascendante n'est pas garantie et une recompilation des applications web est requise. De même l'API interne de Tomcat a beaucoup changé subtilement ce qui rend la compatibilité binaire impossible à garantir et nécessite une revue pour ceux qui interagissent avec ces APIs. Par défaut les requêtes et réponses Web se font en UTF-8 tandis que les sessions ne sont pas conservées après un redémarrage du serveur. Les fichiers de logs ne seront créés que lorsque du contenu doit être écrit dedans. Enfin les paramètres HTTP en commun entre HTTP 2 et 1.1 seront placés au niveau du connecteur HTTP 1.1 pour permettre à la version 2 d'en hériter et limiter ainsi la duplication des paramètres.

Migration de l'utilitaire de journalisation lastlog à lastlog2. Le premier intérêt de cette migration est de corriger le bogue de l'an 2038 qui n'affecte pas ce dernier. Il peut également utiliser la base de données SQLite 3 pour le stockage. Il utilise aussi des composants PAM pour l'authentification et la sortie est compatible de manière ascendante également. De plus il est légèrement plus performant en augmentant la taille de stockage à partir du nombre d'utilisateurs et non du plus grand id utilisateur dans le lot. Le risque de problèmes de compatibilité devrait être faible. La migration vers le nouveau format sera effectuée automatiquement et des liens symboliques vers les noms des anciens binaires sont créés pour éviter de casser des scripts existants.

L'information PLATFORM_ID dans os-release est supprimée. Cette information a été ajoutée dans le cadre de la modularité, mais avec l'abandon de celle-ci cette ligne n'est plus nécessaire. Ceux qui se basent sur cette information sont invités à changer d'approche.

Nouveau gestionnaire de marques-pages de GNOME Web

Développement

La chaine de compilation GNU évolue avec binutils 2.45 et glibc 2.42. Pour binutils, les informations sframe générées par l'assembleur sont maintenant conformes avec la spécification SFrame V2. L'assembleur gère les dernières évolutions des architectures RISC-V, LoongArch et AArch64. Il peut également utiliser les directives .errif et .warnif pour avoir un diagnostic contrôlé par l'utilisateur avec des critères qui sont évalués uniquement à la fin de l'assemblage.

Pour la bibliothèque C glibc, elle prend en charge de nouvelles fonctions mathématiques introduites dans C23 telles que ompoundn, pown, powr, rootn et rsqrt. Elle propose aussi en avance les fonctions valeurs absolues non signées qui seront proposées par la prochaine norme C. Ajout également de la fonction pthread_gettid_np pour connaître l'id d'un thread à partir d'une structure opaque pthread_t. Le cache local dans malloc gagne en performance pour les petites allocations mémoire et peut prendre en charge des blocs à mettre en cache de plus grande taille via l'option glibc.malloc.tcache_max. Le manuel a été particulièrement enrichi pour être plus complet notamment pour les threads, terminaux, systèmes de fichiers, ressources et fonctions mathématiques.

L'éditeur de lien Gold du paquet binutils-gold est considéré comme déprécié et sera supprimé dans une version future. Fedora Linux a déjà quatre éditeurs de liens : ld.bfd, ld.gold, lld et mold. Se débarrasser de l'un d'entre eux qui n'est plus maintenu par le projet GNU n'est pas un problème et doit améliorer à terme la maintenance.

Mise à jour de la chaine de compilation LLVM à sa version 21. Les cartes graphiques AMD voient une amélioration de la prise en charge de ROCm de même qu'un effort pour proposer une bibliothèque C pour GPU. Mais les architectures RISC-V ou cartes graphiques de Nvidia ont également quelques améliorations mineures de ce côté. Le compilateur C CLang optimise l’arithmétique des pointeurs avec le pointeur null et comme souvent le suivi des futurs standards C et C++ se poursuit. Le compilateur fait de meilleurs messages d'erreurs pour les erreurs de compilation.

Côté Fedora, les RPM de ce projet sont compilés avec un profil d'optimisation ce qui devrait significativement améliorer les performances du compilateur maison.

Le langage Python mue à sa version 3.14. Cette version propose des template strings pour étendre les capacités des f-string afin de plus facilement modifier la valeur de la chaîne de caractères à partir d'autres variables. L'évaluation différée des annotations permet de résoudre les annotations de type qui sont cycliques. De plus, un nouveau module concurrent.interpreters fait son apparition pour permettre l'exécution d'interpréteurs Python dans des fils d'exécution uniques pouvant communiquer entre eux, ouvrant la voie à un vrai parallélisme sans renoncer, pour le moment, au fameux verrou principal nommé GIL. Le module compression accueille l'algorithme zstd qui est de plus en plus utilisé dans divers projets libres. Enfin les UUIDs 6, 7 et 8 font leur apparition, permettant de générer des UUIDs respectant différents critères, les deux premiers autorisent un tri temporel quand le dernier est un assemblage de 3 entiers fournis en paramètre. Il y a évidemment d'autres changements améliorant notamment des performances ou rendant les messages d'erreurs plus clairs.

Le langage Go passe à la version 1.25. Il est possible dans cette version d'activer le détecteur de fuites de mémoire à la compilation d'un programme par la commande go build -asan, le rapport sera généré à la fermeture du programme. La commande go vet détecte les appels de fonctions sync.WaitGroup.Add mal placés de même que l'usage de fmt.Sprintf("%s:%d", host, port) pour construire des adresses de connexions qui sont invalides en cas d'usage d'IPv6. Un nouveau ramasse-miettes expérimental fait son apparition, il doit réduire l'impact de ces opérations de 10-40% pour un programme standard qui fait beaucoup d'allocations et de désallocations de petits objets. En terme d'expérimentations, un nouveau module expérimental encoding/json/v2 fait son entrée en matière pour l'encodage et le décodage de JSON, qui doit être plus performant pour le décodage tout en supprimant certaines limitations. Pour les développeurs, un nouveau module runtime/trace.FlightRecorder permet de facilement enregistrer la trace d'événements précis dans le programme dans le contexte de débogage tout en étant léger pour ne pas perturber l'exécution du logiciel par les traces complètes habituellement utilisées. Dans le contexte du débogage, le format DWARF5 pour les informations de débogage peut être exploité ce qui améliore la taille du binaire et le temps de l'édition des liens par ailleurs.

Le langage Perl fourni une réponse brillante avec sa version 5.42. L'accent a été mis pour améliorer les performances dans cette version. Mais en plus de cela, les méthodes peuvent être déclarées avec une visibilité réduite avec l'instruction my method, ces méthodes peuvent être appelées grâce à l'opérateur ->&. Deux nouveaux opérateurs expérimentaux all et any pour vérifier une condition sur l'ensemble, et respectivement aucun, des éléments d'une liste. Un pragma source::encoding peut être apposé sur un fichier source pour détecter les erreurs d'encodage du dit fichier s'il ne correspond pas à celui mentionné. Une classe peut générer automatiquement un setter pour un de ses attributs via l'attribut :writer qui fonctionne de manière analogue à :reader pour le getter.

La boîte à outils Ruby on Rails démarrera voie 8.0. La gestion de certaines dépendances a été améliorée, en effet pour bénéficier de certaines fonctions telles que les Websockets, les jobs ou le cache il était nécessaire d'utiliser au choix MySQL, PostgreSQL ou Redis. Maintenant SQLite s'ajoute à la liste des possibilités et cela passe par de nouvelles couches d'abstractions Solid Cable, Solid Cache et Solid Queue. Fournir des fichiers statiques repose sur Propshaft au lieu de Sprockets, qui est bien plus simple en tirant profit des changements dans le monde Web opérés depuis 15 ans tels que les frameworks JavaScript ou la bonne gestion des petits fichiers avec le protocole HTTP/2 qui permettent de déléguer la gestion de ces problématiques aux frameworks JavaScript directement. Pour finir, elle propose un moyen simple de générer un template basique mais efficace pour la gestion de l'authentification d'une application, en exécutant bin/rails generate authentication vous obtenez un modèle basique pour la session et l'utilisateur avec des contrôleurs pour la session et l'authentification elle même.

Nouveau gestionnaire de mots de passe de GNOME Web

La machine virtuelle Java OpenJDK 25 est fournie. Parmi les changements, un effort a été consenti pour améliorer le mécanisme de l'Ahead-of-Time, la mise en cache de la JVM. Il devient en effet plus facile d'exécuter une application simple pour générer la liste des objets et modules nécessaires pour rendre les prochains lancement plus rapides et de même les profils générés pour accélérer l'application seront immédiatement exploités au démarrage pour également accélérer le lancement de l'application. Le système d'enregistrement des événements est étendu avec la possibilité d'enregistrer précisément le temps d'exécution d'une fonction et sa pile d'appels. Il est possible d'appeler d'autres fonctions ou opérations dans un constructeur avant qu'il n'appelle lui même un autre constructeur du même objet ou de sa classe parente ce qui peut simplifier le code en le rendant plus naturel.

L'utilitaire dans l'écosystème Java nommé Maven bénéficie de la version 4 en parallèle de la version 3. La version 4 est accessible via le paquet maven4 depuis les dépôts. Parmi les changements fondamentaux, il y a une séparation entre les besoins de compilation et d'utilisation du fichier pom.xml qui mentionnait dans le détail les informations de compilation ou des dépendances ce qui était rarement utile pour les utilisateurs lors du déploiement. Maintenant le fichier destiné à être distribué ne mentionne plus ces informations superflues. Dans ce contexte, un nouveau type de paquet bom est fourni pour générer une liste de composants nécessaires pour ce logiciel ce qui est un atout dans une optique de traçabilité et de suivi des failles de sécurité par exemple. Pour clarifier la différence entre les modules de Maven et ceux de Java, les modules sont renommés subprojects, d'ailleurs ces sous-projets peuvent déduire des informations du parent comme sa version par exemple ce qui rend inutile de le mentionner à nouveau. Les sous-projets peuvent aussi être découverts au sein du projet évitant le besoin de les déclarer explicitement et systématiquement.

Le compilateur pour le langage Haskell GHC a été mis à jour vers sa version 9.8 et son écosystème Stackage vers la version 23. Le langage fonctionnel dispose des ExtendedLiterals pour préciser le type précis d'un entier défini tel quel dans le code, comme 123#Int8 pour un entier représenté uniquement sur 8 bits. Dans le bas niveau, un logiciel compilé avec -mfma pour permettre l'usage des instructions, qui combinent multiplication et addition (telle que fmaddFloat# x y z qui donne x * y + z) si l'architecture matérielle les supporte ce qui peut améliorer les performances du programme. Il introduit des nouveaux pragmas WARNING et DEPRECATED à des fonctions d'un module pour signaler à un appelant de prêter attention à son utilisation, notamment en cas de suppression planifiée de la dite fonction.

Le langage de programmation fonctionnel Idris dispose d'une mise à jour majeure vers sa 2e version. La version 1 reposait sur Haskell mais il devenait de plus en plus difficile de le générer avec des versions récentes du compilateur GHC. La version 2 est implémentée en Scheme et repose sur la théorie des types quantifiés, ainsi une variable assignée à une quantité 0 est effacée, assignée à une quantité 1 elle est utilisée une seule et unique fois, etc. Ce changement de paradigme rend de nombreux programmes écrits pour Idris 1 incompatibles. De plus le Prelude du langage ne contient que les éléments strictement nécessaires dans la plupart des programmes non triviaux, le reste est relégué dans dans la bibliothèque base.

Le compilateur Free Pascal propose des paquets permettant la compilation croisée avec d'autres architectures. Ce changement facilite la compilation de programmes pour d'autres systèmes sans quitter sa Fedora Linux. Les paquets nécessaires sont de la forme fpc-cross-$CPU et fpc-units-$CPU-$OS où le premier fourni le compilateur en lui même à destination d'une architecture matérielle spécifique quand le second fourni des objets précompilés nécessaires la plupart du temps pour générer un programme pouvant s'exécuter sur le matériel et système considéré. Si vous souhaitez compiler pour du Windows x86 il faudra installer par conséquent les paquets fpc-cross-i386 et fpc-units-i386-win32.

La bibliothèque d'Intel tbb pour paralléliser certaines tâches passe à la version 2022.2.0. Les changements sont relativement mineurs mais à cause de la rupture de compatibilité de l'ABI, les logiciels s'en servant doivent être recompilés pour fonctionner avec cette nouvelle version.

La signature cryptographique des informations de débogage debuginfod est maintenant vérifiée automatiquement du côté du client. Les paquets RPM fournissaient la dite signature depuis Fedora Linux 39, le client comme serveur prenaient en charge la fonctionnalité, il ne manquait plus qu'une configuration adéquate pour permettre ce changement. Cela se fait en éditant le fichier de configuration /etc/debuginfod/elfutils.urls ainsi :

ima:enforcing https://debuginfod.fedoraproject.org ima:ignore

Cela ne le fait que pour les informations de débogage provenant du projet Fedora, pour les autres il faudra activer cela manuellement de manière similaire.
En cas de signature invalide, les fichiers concernés seront rejetés et considérés comme non disponibles ce qui améliore la fiabilité et la sécurité du débogage.

La bibliothèque Rust async-std est considérée comme dépréciée avant une suppression future. Il n'est en effet plus maintenu et il est recommandé de passer à la bibliothèque smol à la place.

La bibliothèque Python python-async-timeout est considéré comme dépréciée avant une suppression future. Cette fonctionnalité est en effet fournie dans la bibliothèque standard depuis Python 3.11 rendant cette bibliothèque obsolète. Cependant une trentaine de paquets s'en servent encore directement rendant sa suppression impossible à ce stade.

Le paquet python-nose a été retiré. Déprécié par Fedora depuis plus de cinq ans et sans maintenant depuis plus longtemps, sa suppression devenait nécessaire avec l'impossibilité de s'en servir avec la dernière version de Python. Les paquets qui en avaient encore besoin ont été corrigés pour s'en passer.

Les paquets concernant d'anciennes versions de GTK pour Rust gtk3-rs, gtk-rs-core version 0.18, et gtk4-rs ont été retirés. Ils étaient dépréciés depuis Fedora Linux 42 car non maintenus.

Projet Fedora

Koji utilise localement au sein du projet Fedora une instance de Red Hat Image Builder pour générer certaines images qui en dépendent. Cela concerne les images Fedora IoT et Minimal qui étaient construites via l'infrastructure de Red Hat, Koji ne servant que d'orchestrateur côté Fedora. Cela posait quelques soucis dont la possibilité d'intervenir en cas de problèmes mais aussi le fait qu'il était impossible de geler les changements de l'infrastructure aux moments adéquats pour l'élaboration des nouvelles images. Le paquet koji-image-builder a été créé pour permettre d'exécuter cette machinerie localement au sein de l'infrastructure du projet Fedora. L'objectif est d'inclure cela dans Koji intégralement à terme quand ce sera suffisamment testé.

La génération de l'image Core OS repose sur le fichier de définition de conteneurs Containerfile. Jusqu'ici l'image était conçue via RPM OStree avant d'être convertie en image OCI. L'objectif est donc de sauter l'étape RPM OStree en utilisant les conteneurs, l'image de référence est basée sur une Fedora Linux avec bootc. Cela simplifie la procédure de génération de l'image et permet facilement à quiconque de reproduire ces étapes s'il le souhaite en utilisant podman.

Arrêt de publication des mises à jour de Core OS sur le dépôt OSTree. Cela fait suite au changement introduit dans la version précédente de Fedora où l'utilisation des images OCI avait débuté et que les nœuds existants allaient progressivement migrer vers ce format. Désormais maintenir la publication de mises à jour OSTree n'a plus de sens et permet de réallouer les ressources humaines et matérielles.

Le système d'intégration continue de Fedora ne prend plus en charge le format Standard Test Interface. Il évoluait conjointement avec Test Management Tool qui a maintenant les mêmes capacités et continue d'évoluer. N'avoir plus qu'un format permet de simplifier la maintenance et l'outillage. Il y avait de plus en plus d'erreurs liées à l'usage de STI pour certains paquets incitant à faire la migration. Le format TMT a quelques avantages dont une meilleure organisation des tests et des environnements de tests. Les tests sont également reproductibles localement ce qui est important pour la résolution de problèmes. Grâce à l'intégration avec Packit il peut facilement exécuter les tests à partir des sources du logiciel si besoin ce qui est utile en cas de nouvelle version d'un paquet ou voir si un correctif spécifique à Fedora introduit des régressions.

Les nouveaux paquets recevront automatiquement une nouvelle configuration basée sur Packit pour permettre la gestion automatique de certaines tâches dans le cadre des nouvelles versions de Fedora. Cette étape est faite lors de la création du projet sur le service src.fedoraproject.org, un correctif fournit automatiquement cette configuration initiale. Cela peut être manuellement désactivé lors de la création si un mainteneur ne le souhaite pas. L'intérêt est de simplifier l'accueil de nouveaux empaqueteurs mais aussi d'automatiser certaines tâches par défaut. En cas de nouvelle version d'un composant, le paquet avec cette version sera automatiquement crée pour identifier les éventuels problèmes, et s'il n'y en a pas, permettre de créer automatiquement la nouvelle version du paquet et de la diffuser si l'empaqueteur accepte cette nouvelle version. Cela peut aider à gérer plus de paquets et à mieux les maintenir sur le long terme.

Nouvelle localisation du bouton Ne pas déranger

Les bibliothèques statiques fournies par les paquets RPM de Fedora conservent les informations de débogage pour permettre de comprendre l'origine des crashes des applications les exploitant. Cela est rendu possible par la mise à jour du composant debugedit qui permet une telle opération sans trop de problèmes. En effet il peut maintenant collecter les fichiers sources d'une bibliothèque statique et réécrire les chemins vers le répertoire /usr/src/debug comme attendu par les différents outils de débogage. Cependant les informations de débogage sont fournies dans les paquets RPM des binaires pour éviter la complexité de les inclure manuellement pour les développeurs qui en ont besoin dans leur logiciel. L'espace disque nécessaire pour ces informations est considéré comme relativement négligeable pour prendre cette décision. Pour les développeurs qui ne veulent pas des informations de débogage dans leur binaire peuvent exécuter la commande strip -g après l'édition de liens.

Les macros dédiées pour générer les paquets Python reposant sur setup.py sont dorénavant dépréciées. Cela concerne les macros %py3_build, %py3_install, et %py3_build_wheel. En effet ces macros reposent sur ce script qui ne sera plus maintenu à partir d'octobre 2025 par le projet setuptools. L'objectif est d'inciter et de migrer progressivement ces paquets vers la nouvelle méthode reposant sur les macros %pyproject_* et exploitant le fichier de configuration pyproject.toml. Environ 35% des paquets Python de Fedora sont donc concernés par cette migration à venir qui permettra de moderniser et d'unifier les conventions tout en suivant les bonnes pratiques de l'écosystème Python.

Les paquets Go sont compilés en utilisant par défaut les dépendances du projet compilé plutôt que d'utiliser systématiquement des dépendances basées sur des RPM gérés par le projet Fedora. En effet les binaires Go sont tous statiquement compilés donc l'objectif de maintenir des dépendances ne sert qu'à la construction des dits paquets. Cela concerne environ 1400 paquets pour générer 400 paquets avec un binaire Go. C'est beaucoup de travail de maintenance et cela limitait la possibilité d'inclure plus de paquets Go car il fallait empaqueter toutes les dépendances nécessaires au préalable. Cependant avec cette méthode il devient plus difficile de corriger les bogues ou problèmes de sécurité introduits par ces dépendances si Fedora ne les récupère pas. Et pour les cas où il est préférable d'avoir les dépendances gérées par le projet, cela sera un travail plus important pour un paquet donné car moins de dépendances seront déjà disponibles dans les dépôts. Le suivi des licences nécessite d'être adapté pour s'assurer qu'il n'y a pas de problèmes de compatibilité mais des outils existent déjà pour réduire cette problématique.

Les paquets NodeJs utiliseront un nouveau formalisme pour le chemin de leurs dépendances. En effet le répertoire %{_libdir}/node_modules pointait vers un répertoire spécifique à une version de NodeJs comme %{_libdir}/node_modules20 pour la version 20 de NodeJs. Mais cette solution était plutôt pénible avec Fedora qui propose plusieurs versions de NodeJs en parallèle. L'objectif est de mettre en commun %{_libdir}/node_modules pour les modules où c'est possible, et pour ceux qui ont par exemple un binaire WASM, ils seront affectés dans un répertoire dépendant de la version. Cela simplifie la procédure d'empaquetage de ces composants tout en réduisant les doublons et en évitant les incompatibilités. Cela aide également à mettre en évidence les dépendances binaires cachées pour les reconstruire au sein du projet Fedora, ou les supprimer si cela n'est pas possible, à terme.

Les macros CMake ne fourniront plus de variables d'installation non standards. Cela concerne les variables -DINCLUDE_INSTALL_DIR, -DLIB_INSTALL_DIR, -DSYSCONF_INSTALL_DIR, -DSHARE_INSTALL_PREFIX et -DLIB_SUFFIX. Cela ajoute de la confusion notamment parce que la signification de certaines variables n'est pas transparente comme INCLUDE_INSTALL_DIR qui pourrait attendre des chemins relatifs ou absolus. CMake 3.0 a standardisé beaucoup de choses dans GNUInstallDirs qui sont massivement utilisés depuis. Cela permet de mieux s'intégrer dans l'écosystème de ces projets et limite le risque d'erreurs lors de la construction des paquets.

L'assembleur YASM est considéré comme déprécié pour utiliser NASM à la place. Il n'est en effet plus maintenu même si encore utilisé dans quelques paquets tel que Firefox. D'autres distributions ont déjà sauté le pas.

Ajout des nouveaux macros RPM _pkg_extra_*flags pour permettre à chaque paquet d'ajouter des nouvelles options à la compilation à la liste par défaut fournie par le projet Fedora. L'intérêt est d'avoir un moyen standard d'étendre les options de compilation d'un paquet plutôt que chacun les édite à sa sauce et cela permet dans le même temps de voir facilement quels paquets et quelles options sont personnalisés.

Certaines limitations de l'outil gpgverify utilisé par les mainteneurs de paquets sont corrigées permettant de supprimer des méthodes de contournement associés. En effet l'outil est utilisé pour s'assurer que les sources pour construire le paquet sont bien celles souhaitées. Par exemple il était incapable de lire plusieurs clés GPG fournis dans un fichier dédié comme nginx pouvait le faire. Il était également incapable de gérer automatiquement la signature des sommes de contrôle des archives, il exigeait que l'archive des sources elle même soit signée ce qui n'était pas toujours le cas. Maintenant il prendre également en compte les clés au format keybox. Le tout améliore la maintenance des paquets concernés mais évite aussi la possibilité de contourner la sécurité dans certains cas.

La communauté francophone

L'association

Logo de Borsalinux-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, Sylvain Réault 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 43 ?

Logo de MediaWriter

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

Commentaires : voir le flux Atom ouvrir dans le navigateur

Kazeta OS - La distribution Linux qui transforme votre PC en console des années 90

Vous savez ce qui me manque le plus dans le gaming moderne ?

C’est cette sensation magique d’insérer une cartouche dans une console, d’appuyer sur le bouton power et de se retrouver directement dans le jeu. Pas de mises à jour à rallonge, pas de connexion obligatoire, pas de compte à créer, pas de launcher qui rame. Juste moi, ma manette et le jeu… Oui, je suis vieux.

Toutefois, tout n’est pas perdu pour moi, puisqu’un développeur nostalgique a eu la brillante idée de ressusciter cette expérience avec Kazeta OS , une distribution Linux complètement déjantée.

Alesh Slovak, le cerveau derrière cette idée (et aussi le développeur de ChimeraOS ), a décidé de transformer n’importe quel PC en console de salon façon années 90. Le concept c’est que vous prenez une carte SD, vous y copiez un jeu, vous lui mettez une jolie étiquette et hop, ça devient votre “cartouche”. Une fois insérée dans votre PC sous Kazeta, vous appuyez alors sur le bouton power et vous voilà directement dans le jeu. Pas d’interface, pas de menu compliqué, juste le jeu qui se lance instantanément.

Notez que le nom Kazeta vient du tchèque et signifie “cassette”. Comme Alesh Slovak est d’origine tchèque (mais basé à Waterloo au Canada), il en a profité pour faire un petit clin d’œil linguistique à ses origines.

Kazeta traite donc les cartes SD comme des cartouches en lecture seule. Mais rassurez-vous, vos sauvegardes sont automatiquement stockées sur le disque interne du PC, tout comme sur une vraie console. Et si vous démarrez sans cartouche insérée, vous tombez sur un BIOS rétro style PlayStation où vous pouvez gérer vos sauvegardes. C’est génial non ?

Le système supporte tous les jeux DRM-free que vous pouvez imaginer. Les jeux GOG, itch.io, vos vieux jeux Linux natifs, les jeux Windows via Wine/Proton, et même vos émulateurs préférés. Le développeur a conçu Kazeta pour plusieurs types d’utilisateurs. Je pense d’abord aux non-techos qui se perdent dans les interfaces, mais également aux collectionneurs nostalgiques de jeux physiques, et bien sûr à tous ceux qui veulent préserver leur collection de jeux d’une manière plus tangible.

Après pour installer Kazeta, c’est plutôt cool mais ça demande un peu de préparation. Vous devez d’abord télécharger l’ISO depuis le site officiel, puis vous devez l’installer sur votre PC dédié (pas de dual-boot possible pour l’instant), et ensuite vient la partie fun : Créer vos cartouches. Et pour ça, vous formatez une carte SD, vous y copiez les fichiers du jeu, et optionnellement, vous pouvez même imprimer une étiquette custom pour faire plus authentique. Chaque carte ne doit contenir qu’un seul jeu, exactement comme à l’époque. J’sais pas si c’est très écolo mais vous allez pouvoir acheter des vieux stocks de cartes SD de petite capacité dont personne ne veut plus.

L’OS est écrit principalement en Rust (85% du code) avec une touche de Shell et Docker pour l’infrastructure. Le projet est sous licence MIT et le code source est disponible sur GitHub . C’est un projet encore un peu jeune mais à terme, Kazeta promet de supporter “presque n’importe quel jeu DRM-free, passé ou présent”, ce qui ouvre des possibilités énormes. Imaginez transformer votre bibliothèque Steam (pour les jeux sans DRM), GOG ou même vos vieux CD-ROM en cartouches physiques que vous pouvez ranger sur une étagère.

Il y a également quelques limitations à prendre en compte cependant. Pas de support du dual-boot, pas de machines virtuelles, pas de gestion des GPU hybrides (switchable graphics), pas de multi-écrans, et les contrôleurs Bluetooth ne sont pas encore supportés (mais c’est prévu).

Perso, j’adore ce projet parce qu’il répond à un vrai besoin. On revient aux fondamentaux, un jeu, une cartouche, et on joue. Puis surtout, on pourrait imaginer construire une vraie borne d’arcade ou une console custom avec un Raspberry Pi ou un mini-PC, des slots pour cartes SD façon cartouches (imprimées en 3D), et Kazeta comme OS. Vous pourriez littéralement créer votre propre console de salon personnalisée avec votre bibliothèque de jeux préférés.

A découvrir ici !

Sortie de Fedora Linux 42, la réponse à la grande question sur le Libre, Linux et tout le reste ?

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

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.

GNOME Shell nature

Sommaire

Expérience utilisateur

L'environnement de bureau GNOME est proposé dans sa version 48. Cette version apporte comme toujours son petit lot de nouveautés.
Tout d'abord les notifications sont regroupées par application par défaut ce qui permet d'éviter de rapidement saturer la liste dans le menu idoine. Il reste possible de les déplier manuellement si on souhaite voir le détail pour une application en particulier.

Au sein de l'interface, une nouvelle police fait son apparition par défaut. Dénommée Adwaita, elle remplace l'illustre Cantarel qui remplissait ce rôle jusqu'alors. Elle est basée sur la police Inter qui permet une prise en charge plus complète des langues, une meilleure lisibilité sur les écrans à haute densité de pixels tout en étant accessible et lisible dont pour le terminal. En parlant d'affichage, la prise en charge de la technologie HDR a été introduite pour permette une meilleure qualité d'affichage avec les appareils compatibles.

De manière globale, il est possible de changer les raccourcis clavier de l'interface et le placement des nouvelles fenêtres par défaut est centré.

Comme de nombreux systèmes, GNOME propose des paramètres liés au bien-être. Il permet de rapporter le temps d'écran jour par jour au cours d'une semaine. Par ailleurs on peut lui demander de nous notifier régulièrement de faire une pause visuelle en regardant ailleurs ou en faisant quelques mouvements pendant quelques secondes. Il est également possible de définir une limite d'écran qui transforme l'interface en noir et blanc quand le temps limite est atteint. Au sein des options, pour ceux avec un matériel compatible, il est possible de configurer un pourcentage de charge maximale pour la batterie afin de la préserver dans le temps.

Au niveau applicatif, un nouveau lecteur audio très minimaliste fait son apparition : Decibels. Destiné à remplacer le lecteur vidéo Totem pour jouer un morceau individuel depuis le navigateur de fichiers. Côté visionneur d'images, ce dernier bénéficie d'améliorations pour proposer une édition légère des images affichées. La rotation, le changement de ratio ou le découpage de l'image ce qui permet de faire ces opérations simples et courantes sans utiliser un logiciel d'édition complet qui est beaucoup plus lourd. Ensuite il propose un bouton pour revenir au niveau de zoom d'origine à la demande. Enfin, les images au format RAW peuvent être affichées. Concernant le calendrier, il est possible de renseigner le fuseau horaire pour le début ou la fin d'une activité afin de simplifier l'organisation notamment de réunions internationales. Les performances de l'application sont également améliorées.

Sous le capot, un effort a été fait pour améliorer les performances de l'interface et du système. Par exemple le moteur JavaScript de GNOME consomme moins de mémoire et de processeur. En utilisant ffmpeg au lieu de gstreamer, l'indexation des gros fichiers et des métadonnées multimédia est aussi plus rapide et moins gourmand en mémoire. Les utilisateurs connectant leur écran à une carte graphique dédiée verront aussi leurs performances et la stabilité s'améliorer tandis que redimensionner ou créer de nouvelles fenêtres sera plus rapide.

L'environnement de bureau Xfce bénéficie de la version 4.20. Si cette version introduit un support expérimental du protocole d'affichage Wayland, il n'est pas encore fonctionnel et des améliorations futures devront encore être fournies à ce sujet. Mais concernant l'affichage, la prise en charge des écrans à haute résolution a été améliorée ce qui devrait réduire les flous dans l'interface ou de certaines icônes pour de tels écrans.

Dans le navigateur de fichiers Thunar, les points de montage adoptent une icône spécifique alors que les montages distants IPv6 sont désormais possibles. La barre d'outils s'enrichie avec un menu hamburger quand la barre de menu est masquée. Il permet aussi d'ouvrir facilement un nouvel onglet ou de changer la vue d'affichage du dossier en cours. Pour gagner de la place en hauteur, la décoration côté client est prise en charge ce qui permet de mettre le menu au même niveau que les touches d'actions pour réduire ou fermer la fenêtre. Des améliorations de performances sont également fournies notamment pour le transfert des fichiers ou pour afficher des dossiers avec de nombreux fichiers.

De manière globale il est possible de définir un mode d'énergie ou de performance du système dans les propriétés d'alimentation pour choisir l'équilibre souhaité entre la consommation d'énergie et les performances du systèmes. Il y a également l'apparition des profils d'affichage particulièrement utiles quand il y a plusieurs systèmes de multi-écrans à gérer pour passer d'un mode à l'autre en fonction de ses déplacements.

De nombreuses pages de paramètres ont été remaniées pour être plus simples et plus claires.

L'environnement de bureau LXQt passe à la version 2.1. C'est la première version à fournir une compatibilité complète avec le protocole d'affichage Wayland qui devrait être activé par défaut dans Fedora. En dehors de cela cette version ne fournie que des changements et correctifs assez mineurs.

Choix de langues avec le nouvel Anaconda

Le logiciel d'installation Anaconda en profite pour également être une interface web par défaut pour Fedora Workstation. L'objectif est d'utiliser les technologies React et Cockpit pour définir cette nouvelle interface qui a été entièrement redessinée. Elle abandonne sa vieille approche de choisir les éléments à configurer dans l'ordre de son choix par l'usage d'un assistant de configuration linéaire. Donc après la configuration de la langue qui est basée par défaut sur celle de l'image en cours d'exécution, le choix de la date est ensuite suivie de l'étape de partitionnement qui a également été entièrement refaite avant de procéder à l'installation proprement dite. L'approche linéaire a été jugée plus simple d'utilisation et à maintenir même si cela ne permet pas de sauter des étapes si nécessaire, mais étant donné leur nombre réduit cela n'est pas considéré comme une grande perte.

L'aide a été remaniée dans l'application pour être affichée de côté et qui peut être plus facilement maintenue et traduite à côté du code de l'application.

Concernant le partitionnement, auparavant trois méthodes étaient disponibles :

  • Entièrement automatique ;
  • Personnalisé : approche dite top-down en définissant les points de montages avant de définir les détails concernant les partitions et les volumes ;
  • Basé sur l'outil blivet : approche dite bottom-up où on définit les partitions et volumes avant d'y associer les points de montage.

Cela était complexe pour l'utilisateur et difficile à maintenir même si ça avait l'avantage d'être très flexible. L'objectif est maintenant d'offrir une approche plus guidée avec plusieurs choix plus clairs :

  • Réinstaller entièrement sur les disques ;
  • Installer uniquement dans l'espace libre disponible sur les disques ;
  • Réinstaller sur un Fedora Linux existant ;
  • Utiliser un partitionnement déjà existant ce qui permet à priori de configurer cela avec un autre outil au préalable ;
  • Supprimer manuellement des partitions pour utiliser l'espace résiduel.

Le tout repose sur l'utilisation de la technologie Cockpit Storage ce qui simplifie la maintenance et permet d'avoir une apparence similaire avec le reste d'Anaconda. Dans le futur une installation distante par HTTPS devrait être possible grâce à cela.

Pour les autres éditions, Anaconda devient une application Wayland native. Ce changement est utile pour supprimer les dépendances liées à X11 pour les environnements de bureaux qui peuvent s'en passer ce qui réduit la taille de l'image. Par ailleurs cela permet aussi de migrer pour les installations à distance du protocole réseau VNC à RDP qui est plus performant et sécurisé. Cela a été rendu possible par l'usage progressif de systemd-localed par les différents environnements ce qui permettait une meilleure prise en charge de la configuration du clavier dans ce contexte, faute de définition suffisament commune dans le protocole Wayland encore. Autrement le changement de clavier depuis Anaconda ne se reflétait pas sur le bureau et cela pouvait mener à des soucis comme la difficulté de déverrouillage de la machine après installation car la disposition clavier n'est plus celle utilisée lors de l'installation…

L'édition KDE Plasma devient une édition à part entière, étant mise au même niveau que Fedora Workstation avec l'environnement GNOME. Cela récompense les efforts de longue haleine pour améliorer la qualité de l'intégration de KDE dans Fedora Linux. KDE était cependant déjà un environnement considéré comme assez important pour que son bon fonctionnement conditionne le report ou non d'une sortie de Fedora Linux, donc ce changement de statut n'aura pas d'impact de ce côté là. Elle sera maintenant proposée sur le site principal et mieux mise en avant.

L'écran de chargement lors du démarrage plymouth utilise simpledrm par défaut pour réduire l'attente qu'une carte graphique soit disponible. Les cartes graphiques sont des composants complexes qui peuvent nécessiter du temps pour s'initialiser. Auparavant, plymouth pouvait attendre jusqu'à 8 secondes avant de basculer dans un affichage par défaut assez disgracieux. Cependant grâce à l'UEFI qui fourni un framebuffer, il est possible d'avoir un affichage plus sympa et plus tôt par l'usage de simpledrm qui peut être exploité à cette fin. Cela n'a pas été fait plus tôt car notamment simpledrm ne fournissait pas d'information concernant la rotation de l'écran et la taille physique de l'affichage.

Cependant, dans certains cas l'affichage pourrait être plus moche par l'usage d'une résolution plus faible que ce qui est possible car l'heuristique pour définir si l'affichage est à haute définition de pixels peut se tromper. Il reste toujours possible de désactiver ce changement via la commande sudo grubby --update-kernel=ALL --args="plymouth.use-simpledrm=0"

Si vous souhaitez changer le facteur d'agrandissement, si vous avez un écran à haute définition de pixels par exemple, vous pouvez utiliser la commande sudo grubby --update-kernel=ALL --args="plymouth.force-scale=1" et changer éventuellement la valeur 1 par 2 selon votre cas.

L'environnement de bureau COSMIC bénéficie de sa propre édition Spin. Cet environnement est développé en Rust par l'entreprise System76 qui édite Pop! OS. Les progrès récents justifient selon le projet d'avoir sa propre variante, d'autant que Fedora Linux semblait être déjà une distribution recommandée pour tester cet environnement. Cependant COSMIC n'a pas le statut pour bloquer une sortie de Fedora Linux s'il s'avère trop instable.

Activation de la mise à jour automatique par défaut pour la version atomique de KDE Plasma nommée Kinoite. Ces mises à jour concernent la partie de base du système reposant sur rpm-ostree. Ces mises à jour fonctionnent en arrière plan à intervalle régulier pour être instantanément appliquées lors du prochain redémarrage.

Il est possible de désactiver la fonctionnalité en remplaçant la valeur du paramètre UseUnattendedUpdates à false dans le fichier /etc/xdg/PlasmaDiscoverUpdates.

KDE est mis à l'honneur

Gestion du matériel

Amélioration de la prise en charge des webcams basées sur le protocole MIPI au lieu de USB dans les ordinateurs portables x86. Le travail entamé avec Fedora Linux 41 doit se poursuivre car ce protocole moins générique nécessite beaucoup d'adaptations spécifiques par modèle d'ordinateur portable sur le marché. Quelques nouveaux modèles doivent être pris en charge même si la route reste encore longue mais la voie est libre !

L'Intel Compute Runtime, qui prend en charge notamment le fonctionnement de l'API OpenCL pour les processeurs Intel, a été mise à jour vers la version 24.39 qui signifie également une non prise en charge des processeurs d'avant 2020 (à partir de la 12e génération). Ce changement n'a pas d'impact sur l'Intel Media Driver qui permet l'accélération matérielle pour la lecture ou l'encodage de vidéo.

Fedora restait sur l'ancienne version pour maintenir la compatibilité avec les vieux processeurs, jusqu'à l'architecture Broadwell sortie en 2015. Cependant avec l'évolution du noyau et de la couche graphique cela devenait un problème à maintenir et de l'autre côté Fedora n'était pas en mesure de fournir la compatibilité pour du matériel plus récent et les derniers correctifs qui améliorent notamment les performances.

Introduction de la pile Intel SGX pour permettre son utilisation dans le futur pour améliorer l'isolation et la protection mémoire en particulier pour les machines virtuelles. Cette protection se fait notamment en chiffrant la mémoire ce qui la rend inaccessible aux autres applications, au noyau et aux différents firmwares de la machine. Les bibliothèques et en-têtes nécessaires pour ces opérations sont fournies dans le répertoire /usr/x86_64-intel-sgx. Aucune application n'est fournie avec de telles possibilités aujourd'hui, uniquement le nécessaire pour créer des applications pouvant en tirer profit.

Intégration du projet FEX dans les dépôts pour permettre l'exécution des programmes x86 / x86_64 depuis les architectures AArch64. Contrairement à QEMU, il n'émule pas un système complet ce qui est plus performant pour émuler simplement une application non compatible avec cette architecture. Cela peut être nécessaire car de nombreuses applications non fournies par Fedora sont compilées nativement pour l'architecture x86_64 mais pas pour AArch64 alors que l'inverse est moins vrai.

Pour permettre son fonctionnement sur les Mac avec des processeurs Apple, qui ont une taille de page de 16k au lieu de 4k pour les autres machines, le composant muvm est également fourni avec pour permettre une telle compatibilité.

FEX est par ailleurs fourni par défaut dans la variante KDE Aarch64 du système.

L'installateur Anaconda utilise la norme GPT par défaut pour la table de partitionnement pour les architectures PPC64LE et s390x, l'architecture x86_64 et Aarch64 ayant déjà sauté le pas avec Fedora Linux 37. L'objectif est de réduire les différences entre les architectures sur ce point ce qui simplifie les tests et la maintenance de l'ensemble.

Les versions atomiques n'auront plus d'images compatibles avec l'architecture PPC64LE. D'après les statistiques, aucun utilisateur n'a utilisé de tels systèmes sur cette architecture. Cette suppression permet d'allouer plus de ressources matérielles et humaines pour générer et tester les images destinées pour les autres architectures où les utilisateurs sont plus nombreux de fait. Cela ne concerne pas les images de Fedora basées sur les paquets RPM qui restent disponibles pour cette architecture.

Le paquet du logiciel Zezere qui sert à automatiser l'installation et la configurations de systèmes IoT a été retiré des dépôts. L'objectif est de remplacer ce composant par systemd-firstboot car Zezere ne fonctionnait pas bien notamment sur les réseaux IPv6, ne fournissait que la possibilité d'envoyer une clé SSH personnalisée et de nombreuses fonctions promises n'ont jamais vu le jour.

Internationalisation

Mise à jour de l'entrée de saisie IBus 1.5.32. Cette version apporte principalement la prise en charge du protocole des entrées Wayland version 2 ce qui permet son utilisation dans les bureaux Sway, COSMIC et Hyprland. Il permet également d'afficher la pop-up de suggestions dans les applications XIM ou GTK2 lorsqu'elles sont utilisées dans une session Wayland.

Son aide à la saisie pour le chinois ibus-libpinyin est aussi mise à jour à la version 1.16. Il permet en outre de fournir des suggestions de ponctuations, de personnaliser la disposition du clavier ou d'afficher les convertisseurs Lua depuis un menu des méthodes d'entrées.

Proposition d'une nouvelle aide à la saisie vocale avec Ibus Speech to Text via le paquet ibus-speech-to-text qui permet de faire de la reconnaissance vocale en local. Toutes les applications compatibles avec IBus peuvent donc avoir une telle saisie vocale qui exploite le logiciel VOSK pour la reconnaissance vocale. Aucune connexion à Internet n'est requise et il gère plusieurs langues qui peuvent être facilement téléchargées si besoin. Cela permet d'améliorer l'accessibilité du système tout en préservant la vie privée.

Installation avec le nouvel Anaconda

Administration système

Les répertoires /usr/bin et /usr/sbin sont fusionnés. Ainsi /usr/sbin devient un lien symbolique vers le répertoire /usr/bin, de même que /usr/local/sbin vers /usr/local/bin. Cette séparation entre les utilitaires réservés aux superutilisateurs et les autres était artificielle et non exploitée.

À l'origine, l'objectif de /sbin était d'avoir des binaires liés statiquement qui pouvaient être utilisés dans un système en mode de secours pour dépanner en cas de gros problème au niveau du système. Mais cette méthode n'est plus appliquée depuis longtemps et cette distinction était conservée comme une relique historique. Cela devenait un poids plus qu'autre chose car avec l'avénement des droits d'utilisateurs dynamiques via polkit par exemple, le besoin d'accéder à ces outils nécessitait de donner accès à ces répertoires même pour des utilisateurs sans droits particuliers. Puis, entre les distributions, un utilitaire pouvait être rangé dans un répertoire ou un autre en fonction des choix des empaqueteurs de chaque communauté ce qui rend la portabilité des commandes entre distributions plus difficiles inutilement. D'ailleurs ArchLinux a sauté le pas il y a quelques années déjà.

Cela est la continuité de la suppression de la distinction entre /bin et /usr/bin qui avait le même genre de justifications qui a eu lieu avec Fedora 17, il y a 13 ans déjà.

DNF5 va proposer à l'utilisateur de supprimer les clés GPG qui ont expiré, ou qui ont été révoquées, plutôt que de devoir le faire à la main avec la commande rpmkeys --delete. Si la commande est interactive, le choix sera laissé à l'utilisateur de supprimer ou non la dite clé. En mode non interactif via les options -y ou --assumeno, le choix dépendra de l'option choisie pour l'appliquer automatiquement.

La commande fips-mode-setup a été retirée du paquet crypto-policies qui permet de rendre dynamiquement son système compatible avec les exigences du gouvernement américain concernant les modules cryptographiques. Cette option doit être activée lors de l'installation par d'autres moyens maintenant.

Il est ainsi possible de le faire en utilisant l'argument noyau fips=1 pour le notifier à Anaconda, si l'image a été générée avec osbuild-composer, l'option fips=true dans la section [customizations] permet d'obtenir le même effet ou si bootc est utilisé pour une image atomique de passer par cette configuration.

Le mode FIPS n'améliore pas forcément la sécurité, dans certains cas ça peut en bloquant l'usage des algorithmes obsolètes mais parfois cela peut avoir l'effet inverse en n'autorisant pas d'algorithmes plus récents jugés plus sécurisés, comme l'algorithme de chiffrement Argon2 utilisé par LUKS pour chiffrer le disque dur qui résiste mieux aux attaques effectuées par des cartes graphiques par rapport à l'algorithme PBKDF2 qui est lui autorisé. C'est un mode destiné aux entreprises ou personnes ayant besoin d'être certifiées à ce niveau.

L'objectif de ce changement est de simplifier la vie des mainteneurs qui n'ont plus à se préoccuper de cet outil et de ce que cela nécessite car de nombreux changements dans le système doivent être mis en place pour activer (ou désactiver) ce mode. Par exemple reconfigurer tous les modules cryptographiques du système tels que OpenSSH, OpenSSL, GnuTLS, NSS, libgcrypt ou le noyau lui même, fournir également un module à l'initramfs pour effectuer une vérification de l'image du noyau au démarrage de la machine et ajouter un argument pour le noyau si jamais /boot est dans une partition dédiée afin d'effectuer cette vérification.

Mais aussi le changement à la volée est source de problèmes et de confusions pour les utilisateurs. Par exemple installer Fedora Linux avec un chiffrement du disque avec un algorithme non compatible FIPS avant de l'activer après l'installation. De même si des clés de chiffrement sont générées avec OpenSSH ou autres outils avec des algorithmes non autorisés avant d'activer le dit mode. Ces situations hybrides peuvent induire des dysfonctionnement non prévus. L'objectif est de limiter ces cas problématiques en empêchant le changement à chaud.

Le navigateur de fichiers pour Cockpit cockpit-navigator est remplacé par cockpit-files. Cela suit le changement effectué par le projet qui a entamé cette réécriture et ne maintient de fait plus l'ancien module.

Les fichiers Kickstart seront distribués également comme des artéfacts OCI. L'objectif est de permettre de charger plus facilement une image de Fedora pour conteneurs qui est démarrable via le réseau. Dans ce cas précis, il était nécessaire pour l'utilisateur de récupérer et de transformer manuellement les différents fichiers depuis les dépôts RPM avec des numéros de versions très mouvants afin d'avoir les images du noyau, de l'initramfs, du chargeur de démarrage, de l'image d'installation et de lancement. Ici l'objectif est de pouvoir les fournir dans un endroit centralisé tel que ce dépôt avec des processus plus faciles à automatiser avec Ansible ou Foreman. Ces fichiers sont également signés avec GPG ce qui permet de facilement vérifier leur conformité.

Les éditions dérivées de Fedora Workstation auront par défaut le pare-feu configuré avec l'option IPv6_rpfilter=loose, ce qui suit la politique appliquée pour l'IPv4 depuis Fedora 30. En effet, avec l'option IPv6_rpfilter=strict il y avait notamment régulièrement des soucis pour vérifier la connexion à Internet pour des machines ayant plusieurs interfaces connectées au réseau tel qu'un ordinateur portable passant du Wifi au réseau Ethernet pour se connecter à son réseau domestique.

Ajout du paquet bpfman pour le déploiment et la gestion des programmes eBPF dans le système. Développé en Rust, il permet de fournir une vue d'ensemble des programmes eBPF utilisés dans le système actuellement. Il simplifie aussi leur déploiement dans un cluster Kubernetes par l'utilitaire bpfman-operator tandis que l'outil bpfman-agent exécuté au sein d'un conteneur permet de rapporter si les programmes eBPF sont dans l'état désiré.

Mise à jour de l'outil de gestion de configuration Ansible à la version 11. Cette version propose d'ajouter des tags aux variables ou valeurs pour par exemple retourner un avertissement si on essaye d'accéder une valeur marquée comme dépréciée. Les boucles de tâches peuvent avoir une instruction d'interruption. Enfin, le module mount_facts prend en charge les périphériques non locaux.

Le serveur de proxy inverse Apache Traffic Server évolue vers sa 10e version. Une nouvelle API basée sur JSON-RPC est proposée pour permettre des interactions avec des outils extérieurs. Le module traffic_ctl a une commande monitor pour rapporter en continue des métriques à jour. Les règles ip_allow.yaml et remap.config prennent en charge des intervalles d'IP nommées pour simplifier la configuration. La prise en charge du protocole HTTP/2 pour les connexions provenant du serveur d'origine a été ajoutée même si elle est désactivée par défaut. De plus, les plugins doivent être développés en C++20 uniquement au lieu du langage C.

La version de compatibilité PostgreSQL 15 a été retirée, PostgreSQL 16 reste la version par défaut. Cela fait suite à l'ajout de PostgreSQL 17 dans les dépôts comme version alternative avec postgresql17 comme nom de paquet. Le projet ne souhaite pas maintenir davantage de versions pour réduire la charge de travail tout en permettant de migrer les données d'une version à l'autre. En effet, la migration nécessite le binaire de la version actuellement utilisée pour réaliser un dump avant d'utiliser la nouvelle version pour importer ce dump. Cela signifie que les utilisateurs utilisant PostgreSQL 15 doivent préparer la migration avant la mise à niveau de leur Fedora Linux.

Les utilitaires liés au projet OpenDMARC ont été mis dans des paquets individuels au lieu du paquet opendmarc qui les fournissait tous. En effet de nombreux utilitaires notamment écrits en Perl étaient fournis avec ce paquet sans être nécessaires pour exécuter le service ce qui entrainait l'installation plus que 80 paquets Perl pour rien dans la plupart des cas. Le paquet opendmarc fournit maintenant les outils opendmarc et opendmarc-check quand le reste est fourni avec le paquet opendmarc-tools.

L'agent pam-ssh-agent a été supprimé des dépôts. Le développement a été arrêté il y a plus d'un an par le projet OpenSSH et aucun paquet actuellement maintenu n'en dépend.

La nouvelle application GNOME Decibels

Développement

La chaîne de compilation GNU bénéficie de GCC 15, binutils 2.44 et glibc 2.41. Concernant le compilateur GCC, comme d'habitude il fournit de nombreux changements. Il est possible pour l'optimisation de l'édition de lien de le faire de manière incrémentale afin que cette étape soit plus rapide en cas de petits changements dans le code source. Les très gros fichiers de code source sont également plus rapide à compiler et les erreurs les concernant sont mieux gérées. Les erreurs gagnent encore en lisibilité, en particulier pour les templates C++ ou en présentant le chemin d'exécution qui mène à l'erreur détectée.

Pour la section OpenMP, la prise en charge des normes au dessus de la version 5.0 continue sa progression avec une meilleure gestion des cartes graphiques Nvidia et AMD. Pour le langage C, la norme C23 devient la norme par défaut tandis que le début de prise en charge de la future norme C2Y a été introduit. Pour le C++, c'est la prise en charge de la future norme C++26 qui progresse et une meilleure gestion des modules introduits dans les normes précédentes.

Pour les architectures, de nombreuses améliorations pour la prise en charge des microarchitectures x86_64 dont des nouvelles instructions AMX. Côté Aarch64, ce sont les puces d'Apple qui sont prises en charge maintenant.

Concernant la bibliothèque standard C, il y a quelques changements concernant la résolution DNS. Grâce à la variable d'environnement RES_OPTIONS il est possible d'ignorer des options précisées dans le fichier /etc/resolv.conf. Ainsi utiliser RES_OPTIONS=-no-aaaa permet d'ignorer l'option options no-aaaa. Les fonctions sched_setattr et sched_getattr ont été ajoutées pour permettre de changer les options de la politique d'ordonnancement des processus du noyau, par exemple quand SCHED_DEADLINE est utilisé où certains paramètres peuvent être utilisés. La prise en charge d'Unicode 16.0 a été ajoutée, de même que de nombreuses fonctions mathématiques introduites par la norme C23. Pour l'architecture AArch64, les fonctions mathématiques vectorielles devraient être plus performantes.

Enfin pour les binutils, les extensions de l'assembleur pour les architectures AArch64, Risc-V et x86 ont été mises à jour. L'éditeur de lien peut mixer des objets avec et sans l'optimisation activée.

La chaîne de compilation LLVM progresse à la 20e version. Comme pour son concurrent GCC, les dernières normes C et C++ ont bénéficié de nombreuses améliorations pour leur prise en charge. De même, de nombreuses instructions AMX pour l'architecture x86_64 ont été ajoutées. Un nouveau vérificateur TySan fait son apparition pour vérifier les violations d'aliasing de types, donc utiliser un pointeur d'un type particulier pour accéder à des valeurs d'un autre type en mémoire ce qui dégrade les performances ou peut engendrer des bogues. Le module de télémétrie a été extrait du débogueur pour être disponible dans l'ensemble de LLVM afin de pouvoir rapporter différentes mesures et usages de ces outils aux développeurs mais cela reste désactivé par défaut.

Fedora par ailleurs fournit les outils llvm-bolt, polly, libcxx et mlir dans le paquet llvm au lieu d'être dans des paquets indépendants comme avant. Les binaires, bibliothèques et autres en-têtes sont installées dans le dossier /usr/lib64/llvm$VERSION/ au lieu de /usr, des liens symboliques sont proposés pour garder la compatibilité, l'objectif est de faciliter le passage d'une version à l'autre pour les utilisateurs.

Le cadriciel web Python nommé Django utilise la version 5.x. Les formulaires peuvent bénéficier de la notion de groupe de champs pour simplifier significativement le code du template en évitant de devoir répéter les mêmes informations pour chaque champ s'ils ont la même structure. Les modèles peuvent également recevoir une valeur par défaut obtenue par la base de données. Il est également possible de générer des colonnes qui sont calculées à partir d'autres champs de la base de données.

Mise à jour du langage Go vers la version 1.24. Côté langage, il prend en charge les alias de types génériques ce qui permet d'étendre leur champ d'applications et d'améliorer la lisibilité du code. Comme souvent avec Go, les performances sont améliorées, de l'ordre de 2-3% à l'exécution et la structure map est basée sur les tables suisses pour réduire la consommation mémoire pour les petits objets. La bibliothèque standard fournit des mécanismes pour se conformer au standard FIPS 140 concernant la cryptographie comme expliqué plus haut. Une nouvelle instruction du compilateur go:wasmexport permet d'exporter les fonctions du programme à l'hôte en WebAssembly.

Le langage Ruby brille avec la version 3.4. Le parseur par défaut passe de parse.y à Prism pour améliorer la détection des erreurs, les performances et la portabilité. La bibliothèque de socket dispose du standard Happy Eyeballs Version 2 pour améliorer la résilience et l'efficience des connexions TCP. Le compilateur juste à temps YJIT améliore ses performances pour les architectures x86_64 et Aarch64, il est également plus fiable et réduit un peu sa consommation mémoire tout en ayant la possibilité de définir une limite maximale unifiée. Parser des structures JSON doit être également 1,5 fois plus rapide, de même pour Array#each grâce à une réécriture en Ruby.

Le langage de programmation PHP s'impose de tout son poids à la version 8.4. Outre d'apporter un compilateur juste à temps basé sur IR Framework et diverses améliorations de performance, le langage propose de nouveaux concepts. Les property hooks permettent de facilement définir des structures basées sur une autre valeur pour les garder synchronisées tout en ayant une quantité de code plus réduites et avec moins de risque de faire des erreurs. Il est possible de définir une visibilité asymétrique, en autorisant la lecture d'une propriété mais pas son écriture publiquement et ce sans passer par des getters / setters. L'attribut #[\Deprecated] fait son apparition pour signaler à l'utilisateur qu'une méthode ou valeur sera probablement supprimée ultérieurement. Une nouvelle API pour manipuler les objets DOM apparaît et fournit la prise en charge de HTML5. Et d'autres changements encore.

Le langage de scripts Tcl/Tk a été mis à jour vers la 9e version. Pour des raisons de compatibilité, la version 8 reste distribuée sous le nom de paquet tcl8. Grâce à l'exploitation du 64 bits, il peut maintenant manipuler des données de plus de 2 Gio. La prise en charge d'Unicode et des différentes méthodes d'encodage a été améliorée, en ajoutant d'une part mais aussi en gérant l'ensemble des valeurs existantes. L’interaction avec le système est améliorée avec la possibilité d'envoyer des notifications, d'imprimer ou d'utiliser les icônes de la barre du système. Il y a un début de prise en charge de l'affichage vectoriel permettant d'améliorer le visuel des applications. Les capacités d’interactions tactiles sont améliorées avec la possibilité de gérer des gestes à deux doigts.

La bibliothèque de calcul scientifique en Python NumPy passe à la version majeure 2. Première version majeure depuis 2006, il fournit de nombreuses améliorations de performance en particulier autour des différents algorithmes de tri de même que la sauvegarde de gros objets. La transformée de Fourrier rapide prend en charge les types float32 et longdouble. Un nouveau type pour les chaînes de caractères de taille variable fait son apparition : StringDType qui doit fournir également de meilleures performances. La séparation entre l'API publique et privée a été aussi clarifiée avec une nouvelle structure des modules. API qui a aussi été nettoyée pour enlever ce qui n'était pas pertinent ce qui simplifie l'apprentissage de la bibliothèque.

L'outil de développement de paquets Python Setuptools a été mis à jour vers la version 74. La commande setup.py qui était non recommandée depuis plus de 5 ans disparaît, cela a nécessité notamment de changer près de 150 paquets dans le système pour en tenir compte. D'autres changements plus mineurs sont également fournis.

Mise à jour de la bibliothèque de compression zlib-ng à la version 2.2.x. Parmi les changements, sur l'architecture x86_64 les performances devraient être améliorées de 12% pour la compression avec le niveau par défaut. L'allocation mémoire est également fait en une seule fois ce qui réduit le nombre d'appels systèmes et le risque de fragmentation de la mémoire ce qui améliore également les performances globales. Le risque d'avoir un échec par manque de mémoire s'en retrouve également réduit.

Le langage Copilot avec sa boîte à outil de vérification de runtime fait son apparition. Développé en Haskell par la NASA, il permet de définir des programmes concis qui peuvent ensuite être transpilés en C99 pour permettre un haut niveau de sécurité tout en étant capable de gérer des contraintes temps réel dures ce qui est important dans de nombreux contextes embarqués. Ce langage est disponible via le paquet ghc-copilot.

La bibliothèque graphique SDL utilise la version 3 pour assurer la compatibilité avec ses versions 2 et 1.2 dorénavant. Cela passe par le paquet sdl2-compat qui fourni cette compatibilité car SDL 2 n'est plus développé.

Les anciennes versions de OpenJDK pour le langage Java à savoir 8, 11 et 17 ne sont plus fournies par les dépôts de Fedora mais devront être installées via un dépôt tiers tel que Adoptium Temurin dont le paquet adoptium-temurin-java-repository permet son activation. La maintenance des différentes versions d'OpenJDK a été longtemps une problématique pour Fedora avec leur nombre de versions avec une maintenance officielle qui augmente, cela alourdissait considérablement la charge de travail sans avoir assez de mainteneurs en face. D'autant plus que la plupart des cas d'usage se contentent bien de la dernière version LTS disponible, les versions plus anciennes répondent à des cas plus spécifiques qui peuvent se contenter d'un dépôt externe où les mainteneurs de Fedora travaillent de toute façon ce qui garantie la qualité de l'intégration. Cela diminuera la consommation de ressources pour gérer ces paquets dans Fedora mais aussi l'allégement de la charge de travail permettra de mettre à jour OpenJDK plus rapidement à l'avenir.

Le paquet de compatibilité Python pour la version 3.8 a été retiré. Cette version n'est plus maintenue par le projet Python et ce serait trop coûteux et peu sûr de poursuivre sa fourniture dans la distribution.

La bibliothèque Rust zbus version 1 a été supprimée, la version 4 ou supérieure reste proposée dans les dépôts. Une vingtaine de dépendances obsolètes étaient également maintenues pour ce composant ce qui permettra de réduire la charge de travail pour les mainteneurs et la consommation de ressources pour le projet Fedora. La compatibilité avec les dernières versions du compilateur Rust et certains bogues sur certaines architectures rendaient sa maintenance problématique par ailleurs.

La bibliothèque de compatibilité entre Rust et Python, PyO3, se voit retirer les anciennes versions 0.19, 0.20, et 0.21. Les versions 0.22 et 0.23 restent donc disponibles. Cet abandon devient nécessaire par les changements de l'API et de l'ABI de CPython qui rendent les anciennes versions de plus en plus difficiles à maintenir en état de fonctionnement.

L'utilitaire d'exécution des tests unitaires en Python python-pytest-runner est déprécié et sera supprimé dans un futur proche. Depuis 2019 il est dans un état d'abandon par le projet source, il faut depuis envisager d'utiliser pytest à la place d'autant plus que les incompatibilités avec l'outil setuptools vont en grandissant.

La bibliothèque de compatibilité entre GTK3 et Rust est marquée comme dépréciée et sera supprimée dans une prochaine version. En effet les versions récentes de gtk-rs ne le prennent plus en charge ce qui impose un coût de maintenance d'autant qu'il faut maintenir aussi les anciennes versions de compatibilité avec Cairo et GLib pour cela.

Les nouveaux paramètres de GNOME bien être

Projet Fedora

Fedora Linux proposera des archives permettant d'être installé avec Windows Subsystem for Linux. Windows a récemment amélioré la prise en charge des installations d'un tel système en dehors du magasin d'applications Microsoft ce qui rend ce changement plus intéressant. Idéalement il faut utiliser WSL 2.4.4 ou supérieur même si une procédure sera fournie pour les versions plus anciennes. Le projet Fedora ne souhaite pas à ce jour accepter les conditions pour permettre une publication directement depuis le magasin d'applications. Cela permet de faciliter l'usage de Fedora dans un tel système.

Les paquets RPM peuvent bénéficier de la fonction systemd sysusers.d pour créer des utilisateurs ou groupes dédiés lors de l'installation des paquets RPM. L'objectif à terme est de se débarasser des instructions useradd ou groupadd dans les paquets RPM voire l'usage de la macro %sysusers_create_compat. Cela va permettre d'uniformiser à terme la manière de créer de tels utilisateurs et groupes ce qui va également simplifier les scriplets des différents paquets RPM concernés. Comme cela est intégré dans le format RPM, il devient plus facile de retrouver quels utilisateurs et groupes sont créées par un paquet donné et de définir des dépendances basées sur ce critère si c'est pertinent.

Les mises à jour de Fedora CoreOS passent de OSTree à OCI. Les mises à jour proviennent ainsi du dépôt quay.io/fedora/fedora-coreos. C'est la première étape avant d'être capable de passer à bootc pour gérer la base du système qui permettrait entre autre de faire des mises à jour en miroir en copiant un système existant sur le réseau local ou de laisser l'utilisateur personnaliser facilement ses propres images.

Activation par défaut de composefs pour les images atomiques bureautiques de Fedora Linux pour les images non basées sur OSTree. Faisant suite à ce qui a été fourni pour les images CoreOS et IoT avec Fedora Linux 41, l'idée est de fournir une vérification d'intégrité des images atomiques lorsque le système tourne et d'avoir un système de fichiers du système réellement en lecture seule.

En effet, jusqu'ici l'intégrité des fichiers du système n'est vérifiée que lors de la mise à jour ou l'installation d'une nouvelle image mais rien n'empêche d'avoir une altération malveillante par exemple entre temps. Il fallait exécuter ostree fsck à la main pour vérifier manuellement si le système était conforme. De plus le système même s'il est en lecture seule en théorie, en réalité il était monté en lecture/écriture avec la commande chattr +i / ajoutée pour prévenir les modifications accidentelles.

Avec composefs, qui exploite overlayfs et EROFS, permet de supprimer ces limitations, le système de fichiers sera réellement en lecture seule et la moindre tentative de modification aboutira à une erreur au niveau du noyau Linux en toute circonstance. Les répertoires /etc et /var restent accessibles en lecture/écriture comme avant. L'objectif à terme est de fournir une vraie chaîne de démarrage sécurisée avec la vérification des signatures au niveau du système.

L'utilitaire edk2 est compilé avec des options de sécurité supplémentaires pour améliorer la sécurité des machines virtuelles reposant sur l'UEFI. Ce composant est une implémentation de l'UEFI qui est notamment utilisée par les machines virtuelles créées avec libvirt. Ce changement passe par l'activation du mode strict pour NX qui empêche l'exécution de code provenant de zone mémoire en lecture/écriture. Les pointeurs NULL sont également capturés pour éviter de déférencer le vecteur d'interruption qui existe à cette adresse ce qui peut mener à des accès mémoires non souhaités. Cela ne sera appliqué que pour les sytèmes invités avec Secure boot activé, pour éviter d'introduire des régressions pour les systèmes invités plus anciens qui seraient non compatibles avec ces options de sécurité dans un environnement où ces protections additionnelles seraient moins pertinentes.

En effet, cela est une réponse au problème de sécurité liée au composant shim pour les versions inférieures à 15.8 qui a nécessité en 2024 une mise à jour majeure des chargeurs de démarrage et du noyau Linux. Des systèmes invités avec ce problème de sécurité non corrigé entraineront une erreur mémoire prévenant toute exécution.

Les images live de Fedora Linux utilisent le système de fichiers EROFS en lieu et place de SquashFS. Ce système de fichiers est aussi en lecture seule et est plus activement développé. De fait il peut utiliser des algorithmes de compression plus moderne pour réduire la taille de l'image et a été développé pour avoir de bonnes performances sur les systèmes embarqués ce qui devrait se retrouver aussi sur des machines plus performantes.

Ajout d'un générateur de dépendances pour les extensions de GNOME Shell, permettant de lier la version de l'extension avec celle de gnome-shell à partir du fichier metadata.json de l'extension. Cela permet de détecter de manière générique et donc plus facilement et automatiquement un soucis de compatibilité entre une extension et la version de GNOME Shell fournie par le projet. Cela devrait permettre de travailler sur ces problèmes de compatibilité dès qu'ils apparaissent plutôt que d'attendre le retour d'utilisateurs qui découvrent une extension non fonctionnelle en pratique.

Redéfinition des dépendances de nombreux paquets de git vers git-core. Plus de 200 paquets souhaitent utiliser le binaire git et ont une dépendance envers ce paquet éponyme alors qu'il est fourni en réalité par le paquet git-core. Ce qui implique une dépendance excessive envers 60 autres paquets inutiles dans ce contexte. Cela devrait entre autre réduire les ressources nécessaires pour générer certains paquets.

La communauté francophone

L'association

Logo de Borsalinux-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 cinq 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, Sylvain Réault 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 42 ?

Logo de Fedora Media Writer

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

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

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

Projets Libres! Episode 32 : Emmabuntüs, Linux et réemploi

Pour le premier épisode de la troisième saison du podcast, nous découvrons la distribution Emmabuntüs.

Avec Patrick, son mainteneur, et Yves, un de ses contributeurs régulier, nous abordons les sujets suivants :

  • la naissance et les évolutions de la distribution
  • le réemploi de matériel informatique et la clef de réemploi du projet
  • le rapport avec Emmaüs
  • les améliorations de la distribution pour les déficients visuels
  • la collaboration avec le projet d'ordinateur à fabriquer soit-même Jerry Do It Together
  • le fonctionnement du collectif et sa communauté
  • les défis d'Emmabuntüs

Bonne écoute !

Commentaires : voir le flux Atom ouvrir dans le navigateur

Emmabuntüs DE5, maintenant accessible aux déficients visuels

Ce 29 juillet 2024, le collectif Emmabuntüs vient d’annoncer la sortie de sa nouvelle version Emmabuntüs Debian Édition 5 1.02, basée sur la Debian 12.6 Bookworm (32 et 64 bits) et supportant les deux environnements de bureau Xfce et LXQt.

Rappelons que cette distribution est née au sein d’Emmaüs, pour faciliter le reconditionnement des ordinateurs donnés aux associations, notamment humanitaires, mais aussi pour favoriser la découverte de GNU/Linux par les débutants, tout en prolongeant la durée de vie du matériel informatique, ce qui réduit le gaspillage lié à la surconsommation de matière première.

Logo d'Emmabuntûs

Cette nouvelle version fait suite à une demande de l’A.S.I. YOVOTOGO, afin de donner 90 ordinateurs embarquant cette évolution à la « Fédération togolaise des associations de personnes handicapées » (FETAPH) pour équiper leurs 11 centres de formation.
Pour inclure cette évolution, sans perturber ses anciens utilisateurs, une fenêtre d’activation et de configuration de ces fonctions d’accessibilité a été ajoutée :
Capture d'écran Fenêtre de configuration de l’accessibilité personnalisée

Les principales fonctions d’accessibilité ajoutées dans cette évolution sont :

Menu capture d'écran Menu des applications d’accessibilité

Le collectif a aussi réalisé pour cette évolution un ensemble de manuels pour l’accessibilité ainsi que la mise en place d’une page dédiée sur son site regroupant ces manuels en français et en anglais.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Projets Libres! Episode 29 : Fedora et la communauté Fedora-Fr

Pour ce nouvel épisode, nous partons à la rencontre de la communauté Fedora-Fr et l'association Borsalinux-fr, qui fête ses 20 ans cette année !

Avec Guillaume Kulakowski (Llaumgui) et Charles-Antoine Couret (Renault), nous abordons les thèmes suivants :

  • la naissance et les grandes étapes du développement de Fedora
  • les débuts de la communauté Fedora-Fr et de l'association Borsalinux-fr
  • les relations de l'association avec Red Hat
  • un retour sur les 20 ans de la communauté Fedora-fr
  • les évolutions du packaging
  • les défis à venir

Bonne écoute !

Commentaires : voir le flux Atom ouvrir dans le navigateur

Ubix Linux, le datalab de poche

Ubix Linux est une distribution Linux libre et open-source dérivée de Debian.

Le nom « Ubix » est la forme contractée de « Ubics », acronyme issu de l'anglais Universal business intelligence computer system. De fait, le principal objectif d'Ubix Linux est d'offrir une plateforme universelle dédiée à l'informatique décisionnelle et à l'analyse des données.

Il s'agit d'une solution verticale, prête à l'emploi, dédiée à la manipulation des données et à la prise de décision. Allégée par conception, elle n'embarque qu'un jeu limité d'outils spécialisés dans ce domaine. Ceux-ci permettent néanmoins de couvrir tous les besoins dont l'acquisition, la transformation, l'analyse et la présentation des données.

Ubix Linux - Vue d'ensemble

Origines de la distribution

La volonté initiale du concepteur de la distribution était de pouvoir disposer, à tout moment et en toutes circonstances, des outils lui permettant de réaliser des analyses de données et d'en présenter le résultat ad hoc. Ce « couteau suisse » de manipulation des données, devait également lui permettre d'éviter de devoir justifier, rechercher, acquérir et installer l'écosystème logiciel nécessaire chaque fois que ce type de tâches se présentait à lui.

Son cahier des charges stipulait donc une empreinte disque la plus faible possible sans pour autant faire de concessions au niveau des fonctionnalités. La distribution se devait d'être portable et exécutable immédiatement dans des contextes variés, sans nécessité d'investissement, d'installation ou de droits d'accès particulier.

De ce fait, Ubix Linux ne se démarque pas par ses aspects « système », mais plutôt par sa destination et ses cas d'usage.

Au-delà du besoin initial

À l'heure où de nombreux concepts liés à la manipulation des données tels que le « Big Data », la « Data Science » ou le « Machine Learning » font la une de nombreux médias, ceux-ci restent encore des boîtes noires, affaire de spécialistes et d'organisation disposant des moyens de les mettre en application.

Si le grand public en intègre de mieux en mieux les grandes lignes, il ne dispose encore que de peu de recul sur la manière dont ses données peuvent être utilisées, ainsi que la richesse des débouchés associés.

D'un autre côté, de nombreux gisements de données à la portée du plus grand nombre demeurent inexploités, faute de compétences ou de moyens facilement accessibles.

Il se trouve qu'Ubix Linux peut permettre de surmonter cette difficulté, en offrant à tous les moyens de s'approprier (ou se réapproprier) et tirer parti des données disponibles.

Philosophie

Par nécessité, Ubix Linux a été conçue en intégrant uniquement des produits libres et open-source. Bien que cette distribution puisse s'avérer utile à toute personne devant manipuler des données, elle se doit de préserver et défendre une approche pédagogique et universaliste.

Elle a pour ambition de mettre les sciences de données à la portée de tous. La distribution en elle-même n'est qu'un support technique de base devant favoriser l'apprentissage par la pratique. Il est prévu de l'accompagner d'un tutoriels progressifs.

Les outils low-code/no-code intégrés dans la distribution permettent de commencer à manipuler des données sans devoir maîtriser au préalable la programmation. Néanmoins, des outils plus avancés permettent ensuite de s'initier aux principes des algorithmes d'apprentissage automatique.

Synthèse

Ubix Linux s'inscrit dans la philosophie du logiciel libre et plus particulièrement dans celle des projets GNU et Debian.

Elle se destine à :

  • demeurer accessible à tous ;
  • pouvoir s'exécuter sur des configurations matérielles relativement modestes, voire n'être installée que sur un périphérique portable USB ;
  • proposer un outil pédagogique pour appréhender de façon pratique la science des données et l'apprentissage machine ;
  • permettre la découverte, l'expérimentation et l'aguerrissement de tout un chacun aux principaux outils de manipulation des données ;
  • offrir une boîte à outils légère et agile, néanmoins complète et utile pour un public professionnel averti.

Et après…

Nous sommes à l'écoute de toute suggestion. Toutefois, les moyens étant ce qu'ils sont (au fond du garage), la réactivité à les prendre en compte pourra s'avérer inversement proportionnelle.

Nous souhaiterions que cet outil pédagogique puisse bénéficier au plus grand nombre : si vous voulez contribuer à la traduction du contenu du site officiel en espagnol, en portugais ou en allemand, vous êtes les bienvenus.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Sortie de LuneOS « Eiskaffee »

Tentés par un café glacé ? LuneOS « Eiskaffee » vient de sortir !

LuneOS est une distribution GNU/Linux pour téléphones mobiles et tablettes, héritière de feu webOS. Le projet est porté par l’équipe webOS-Ports, dont le but est de faire revivre webOS sur les matériels contemporains.

logo de LuneOS

Sommaire

Voici bien longtemps que l’équipe de webOS-ports n’avait fait de nouvelle version de LuneOS. De nombreux changements de fond, de nouveaux téléphones et tablettes, des difficultés techniques mais aussi une équipe développement modeste expliquent ce rythme un peu lent qui avance selon le temps libre de chacun.

Pendant ce temps, des versions de test de LuneOS ont été régulièrement mises à disposition sur Github, dans le dépôt « luneos-testing ». Cela permet aux personnes intéressées d’essayer LuneOS, tout en gardant à l’esprit que ce ne sont que des versions intermédiaires.

Petits rappels et lexique

Le projet s’appuie sur Yocto, webOS-OSE, Halium et SHR. Il utilise OpenEmbedded comme environnement de compilation. Cette dernière version de LuneOS se base sur la version « Kirkstone » de Yocto. Ces projets ne vous disent rien ? Voici un rapide lexique :

  • OpenEmbedded est un environnement de compilation, qui utilise un ensemble de « recettes » pour décrire les composants à compiler et installer.
  • Yocto est un ensemble de recettes prêtes à l’emploi qu’on peut utiliser pour se construire une distribution Linux personnalisée. Les recettes mises à disposition vont du noyau Linux à Firefox, et forment un ensemble déjà assez complet.
  • SHR est un système d’exploitation GNU/Linux s’appuyant aussi sur Yocto et OpenEmbedded, et orienté téléphones. Il a connu son heure de gloire à l’époque des téléphones Openmoko comme le FreeRunner. Seule une petite partie est maintenant réutilisée pour les besoins de LuneOS.
  • Halium est un ensemble d’utilitaires et d’images Android permettant de faire tourner un Android minimaliste dans un container dédié sur la distribution hôte. Cela permet d’exploiter les pilotes et firmwares disponibles seulement pour Android, tout en gardant le reste de l’OS sur une pile GNU/Linux/systemd/Wayland classique.
  • webOS-OSE est une distribution Linux maintenue par LG, héritière du code de webOS, et dont LuneOS reprend maintenant beaucoup de composants logiciels.

À l’exception des blobs utilisés pour faire tourner les pilotes Android, l’ensemble de la distribution est libre : tout le monde peut, s’il le veut, recompiler sa propre image chez soi.

Fin du forum webOS Nation et autres tracasseries techniques

Le forum « webOS Nation », qui regroupe des discussions autour de webOS au sens large (vieilles versions de webOS, mods, LuneOS…) a connu quelques turbulences ces dernières années. Devant une fermeture imminente du site web, un nouveau site webOS Archive a été mis en place, avec notamment la majorité des archives des forums de webOS Nation. Un nouveau forum a été mis en place, reprenant globalement le style de webOS Nation.

Sans avoir une activité folle, la communauté autour de webOS reste présente, notamment grâce à la présence aujourd’hui de webOS sur les téléviseurs.

Mort du « builder » dédié à LuneOS

Suite à plusieurs avaries, le builder « Jenkins » a dû prendre une retraite bien méritée. Malheureusement cela implique pour l’équipe de webOS-ports de compiler les différentes images de LuneOS chez soi, ce qui n’est pas très pratique (sans être une catastrophe). Sur une machine raisonnablement puissante, la création d’une image de LuneOS depuis zéro demande plusieurs heures, il faut donc parfois s’armer de patience. Heureusement Yocto permet de mutualiser les résultats de compilation pour les architectures semblables, ce qui fait gagner beaucoup de temps.

Les changements majeurs

Depuis la dernière version publique de LuneOS, beaucoup de changements de fond ont eu lieu. On retrouve entre autres:

Passage de Qt 5 à Qt 6

LuneOS utilise maintenant Qt 6.5.2, l’une des dernières disponibles.

Utilisation du compositeur Wayland de webOS OSE

Le compositeur Wayland propre à LuneOS luna-next a été abandonné, au profit du compositeur Wayland de webOS OSE surface-manager. Cependant la partie graphique (codée en QML) a été conservée, et l’expérience utilisateur reste donc très similaire.
Cela permet de se concentrer sur la partie GUI du compositeur, tout en bénéficiant des mises à jour venant de OSE relatives au cœur même du compositeur.

Changement de moteur Chromium

Les apps webOS utilisant intensivement HTML/Javascript/CSS, l’affichage nécessite un moteur web bien à jour et optimisé. Jusqu’à la dernière version, LuneOS utilisait QtWebEngine, fourni par Qt, pour faire tourner les applications.
Cependant webOS-OSE fournit son propre moteur basé sur chromium, indépendant de Qt et optimisé pour une utilisation embarquée. LuneOS a donc également migré vers cette nouvelle infrastructure logicielle, adoptant ce composant WebAppManager.

Migration générale vers les composants de webOS-OSE

Plus généralement, les composants hérités de feu Open WebOS ont été remplacés par leur équivalent dans webOS-OSE, plus récents et encore maintenus par LG. Pour cette version de LuneOS, la version 2.23.0 de webOS-OSE est utilisée comme base.
Cette migration inclut notamment l’utilisation des « Enhanced ACG », un modèle de sécurité plus efficace utilisé pour la communication entre les services de webOS et les apps.

Ces changements, qui pour la plupart ne sont pas visibles à l’utilisation, apportent de multiples bénéfices pour LuneOS :

  • une réutilisation plus large du code de webOS-OSE (maintenu par LG), ce qui implique moins de maintenance côté webOS-ports
  • meilleure stabilité des composants, qui sont utilisés depuis des années dans les téléviseurs et appareils LG
  • la rétro-compatibilité a tout de même pu être assurée pour les vieilles apps webOS, grâce à des modifications mineures dans certains composants
  • plus de facilité pour mettre à jour les composants venant de webOS-OSE

Téléphones et tablettes: vers plus de Linux « mainline »

Dans le domaine des distributions Linux pour téléphones et tablettes, on parle de noyau « mainline » pour désigner l’utilisation directe du code source venant du noyau Linux, par opposition à l’utilisation d’un code source dérivé et proposé par un constructeur. Ce dernier est souvent proposé dans une vieille version, avec une maintenance très limitée dans le temps.

Cependant, utiliser un noyau « mainline » est à double tranchant : d’un côté, on bénéficie des dernières avancées du noyau, et des dernières versions des pilotes libres. Mais de l’autre, cela signifie devoir se passer des pilotes proposés par le constructeur (pour le son, le GPS, le modem…), qui souvent n’ont jamais été proposés à l’inclusion dans le code source principal de Linux.

Au final, dans le cas de LuneOS, trois voies se dessinent lorsqu’il s’agit de faire tourner l’OS sur un téléphone ou une tablette :

  1. Le constructeur remonte ses changements dans le noyau Linux, et s’appuie sur un développement open-source: Pine64 et Purism sont deux exemples récents de cette approche. C’est le cas idéal pour LuneOS, où des pilotes open-source bien intégrés peuvent être utilisées pour faire fonctionner les composants matériels.
  2. Le constructeur ne propose qu’une version Android de ses pilotes et du noyau; ce dernier reste figé dans une même version, relativement récente, avec une maintenance minimale. LuneOS va alors utiliser Halium pour profiter des pilotes faits pour Android, tout en gardant le reste du système sur une pile logicielle « systemd/glibc » classique. Cette situation reste très présente, car l’immense majorité des téléphones et tablettes du marché tournent sur Android.
  3. Le constructeur propose une vieille version du noyau, non maintenue, et dont les limitations deviennent problématiques pour LuneOS. Dans ce cas, LuneOS va tenter d’utiliser un noyau plus récent, mais qui a un support partiel du matériel. Cette stratégie a souvent un résultat très mitigé, avec de gros manques fonctionnels. En gros, c’est la tentative de la dernière chance avant l’abandon du support de ce matériel.

Le matériel Pine64

Une tablette PineTab2 avec LuneOS

Comme évoqué plus haut, Pine64 cultive ses liens avec la communauté open-source, et incite celle-ci à proposer leurs OS sur leur matériel. On retrouve ainsi de nombreux OS comme PostmarketOS, Plasma Mobile ou encore Ubuntu Touch. LuneOS a pris le train en marche très tôt, et peut aujourd’hui s’installer sur le Pinephone, le Pinephone Pro ainsi que sur la tablette PineTab 2.

Pour le Pinephone et le Pinephone Pro, LuneOS nécessite maintenant l’installation préalable de Tow-boot sur le téléphone. Ce dernier est un dérivé de U-Boot, qui vise à standardiser et faciliter le démarrage des OS sur du matériel embarqué.

Comme ce matériel tourne avec une version très récente du noyau Linux, il est possible pour LuneOS de lancer Waydroid; cependant cette fonctionnalité est jeune et nécessite encore beaucoup de travail.

Le matériel Android

LuneOS peut s’installer sur de nombreux autres téléphones (et sur la vénérable tablette HP Touchpad), grâce à l’utilisation de Halium (ici en version 9.0).

Cependant, même s’il n’est pas prévu d’abandonner les téléphones et tablettes Android, les efforts se concentrent de plus en plus sur le matériel pour lequel un noyau « mainline » existe.

Plans pour la prochaine version

Continuer la migration vers l’infrastructure de webOS-OSE

Mettre à jour les composants vers la dernière version de webOS-OSE, et finir la migration:

  • mettre à jour le moteur web vers Chromium 108 (tout juste sorti du four chez LG)
  • re-baser l’infrastructure audio et multimédia de LuneOS sur les composants fournis par webOS-OSE
  • travailler également sur le support des caméras

Continuer le travail sur le matériel supporté

  • Avoir un noyau « mainline » fonctionnel pour Tenderloin, Hammerhead, Mido and Tissot.
  • Fournir une image GSI unique pour les téléphones Android, permettant de faciliter grandement le support d’autres téléphones

Compléter l’espace applicatif

  • Améliorer ou ajouter des apps de base comme Camera, Flashlight, Audio Player ou Video Player, et améliorer les composants QML.
  • Essayer de profiter du travail fait par la communauté sur les TVs LG « homebrew » : webOS Brew

Envie d’essayer ?

Pour le téléchargement et l’installation, c’est par ici. Il existe notamment une image pour émulateur x86-64, utilisable directement dans VirtualBox.

L’équipe webOS-ports est présente sur IRC (Libera:#webos-ports) ou encore Telegram.

Commentaires : voir le flux Atom ouvrir dans le navigateur

❌