Fedora-Fr - Communauté francophone Fedora - Linux

Planet de Fedora-Fr : la communauté francophone autour de la distribution Linux Fedora

A propos

Cette page est actualisée toutes les heures.

Cette page est une sélection de blogs autour de Fedora. Fedora-Fr.org décline toute responsabilité au sujet des propos tenus par les auteurs des blogs de ce planet. Leurs propos sont leur entière responsabilité.

Le contenu de ce planet appartient à leurs auteurs respectifs. Merci de consulter leur blogs pour obtenir les licences respectives.

Mot-clefs : Fedora

12/20 Élections pour le Conseil, FESCo et Mindshare pendant encore quelques jours

Charles-Antoine Couret

Comme le projet Fedora est communautaire, une partie du collège des organisations suivantes doit être renouvelée : Council, FESCo et Mindshare. Et ce sont les contributeurs qui décident. Chaque candidat a bien sûr un programme et un passif qu'ils souhaitent mettre en avant durant leur mandat pour orienter le projet Fedora dans certaines directions. Je vous invite à étudier les propositions des différents candidats pour cela.

J'ai voté

Pour voter, il est nécessaire d'avoir un compte FAS actif et de faire son choix sur le site du scrutin. Vous avez jusqu'au vendredi 4 décembre à 1h heure française pour le faire. Donc n'attendez pas trop.

Par ailleurs, comme pour le choix des fonds d'écran additionnel, vous pouvez récupérer un badge si vous cliquez sur un lien depuis l'interface après avoir participé à un vote.

Je vais profiter de l'occasion pour résumer le rôle de chacun de ces comités afin de clarifier l'aspect décisionnel du projet Fedora mais aussi visualiser le caractère communautaire de celui-ci.

Council

Le Council est ce qu'on pourrait qualifier le grand conseil du projet. C'est donc l'organe décisionnaire le plus élevé de Fedora. Le conseil définit les objectifs à long terme du projet Fedora et participe à l'organisation de celui-ci pour y parvenir. Cela se fait notamment par le biais de discussions ouvertes et transparentes vis à vis de la communauté.

Mais il gère également l'aspect financier. Cela concerne notamment les budgets alloués pour organiser les évènements, produire les goodies, ou des initiatives permettant de remplir les dits objectifs. Ils ont enfin la charge de régler les conflits personnels importants au sein du projet, tout comme les aspects légaux liés à la marque Fedora.

Les rôles au sein du conseil sont complexes.

Ceux avec droit de vote complet

Tout d'abord il y a le FPL (Fedora Project Leader) qui est le dirigeant du conseil et de facto le représentant du projet. Son rôle est lié à la tenue de l'agenda et des discussions du conseil, mais aussi de représenter le projet Fedora dans son ensemble. Il doit également servir à dégager un consensus au cours des débats. Ce rôle est tenu par un employé de Red Hat et est choisi avec le consentement du conseil en question.

Il y a aussi le FCAIC (Fedora Community Action and Impact Coordinator) qui fait le lien entre la communauté et l'entreprise Red Hat pour faciliter et encourager la coopération. Comme pour le FPL, c'est un employé de Red Hat qui occupe cette position avec l'approbation du conseil.

Il y a deux places destinées à la représentation technique et à la représentation plus marketing / ambassadrice du projet. Ces deux places découlent d'une nomination décidée au sein des organes dédiées à ces activités : le FESCo et le Mindshare. Ces places sont communautaires mais ce sont uniquement ces comités qui décident des attributions.

Il reste deux places communautaires totalement ouvertes et dont tout le monde peut soumettre sa candidature ou voter. Cela permet de représenter les autres secteurs d'activité comme la traduction ou la documentation mais aussi la voix communautaire au sens la plus large possible. C'est pour une de ces places que le vote est ouvert cette semaine !

Ceux avec le droit de vote partiel

Un conseiller en diversité est nommé par le FPL avec le soutien du conseil pour favoriser l'intégration au sein du projet des populations le plus souvent discriminées. Son objectif est donc de déterminer les programmes pour régler cette problématique et résoudre les conflits associés qui peuvent se présenter.

Un gestionnaire du programme Fedora qui s'occupe du planning des différentes versions de Fedora. Il s'assure du bon respect des délais, du suivi des fonctionnalités et des cycles de tests. Il fait également office de secrétaire du conseil. C'est un employé de Red Hat qui occupe ce rôle toujours avec l'approbation du conseil.

FESCo

Le FESCo (Fedora Engineering Steering Committee) est un conseil entièrement composé de membres élus et totalement dévoués à l'aspect technique du projet Fedora.

Ils vont donc traiter en particulier les points suivants :

  • Les nouvelles fonctionnalités de la distribution ;
  • Les sponsors pour le rôle d'empaqueteur (ceux qui pourront donc superviser un débutant) ;
  • La création et la gestion des SIGs (Special Interest Group) pour organiser des équipes autour de certaines thématiques ;
  • La procédure d'empaquetage des paquets.

Le responsable de ce groupe est tournant. Les 9 membres sont élus pour un an, sachant que chaque élection renouvelle la moitié du collège. Ici 5 places sont à remplacer.

Mindshare

Mindshare est une évolution du FAmSCo (Fedora Ambassadors Steering Committee) qu'il remplace. Il est l'équivalent du FESCo sur l'aspect plus humain du projet. Pendant que le FESCo se préoccupera beaucoup plus des empaqueteurs, la préoccupation de ce conseil est plutôt l'ambassadeur et les nouveaux contributeurs.

Voici un exemple des thèmes dont il a compétence qui viennent du FAmSCo :

  • Gérer l'accroissement des ambassadeurs à travers le mentoring ;
  • Pousser à la création et au développement des communautés plus locales comme la communauté française par exemple ;
  • Réaliser le suivi des évènements auxquels participent les ambassadeurs ;
  • Accorder les ressources aux différentes communautés ou activités, en fonction des besoin et de l'intérêt ;
  • S'occuper des conflits entre ambassadeurs.

Et ses nouvelles compétences :

  • La communication entre les équipes, notamment entre la technique et le marketing ;
  • Motiver les contributeurs à s'impliquer dans différents groupes de travail ;
  • Gérer l'arrivé de nouveaux contributeurs pour les guider, essayer de favoriser l'inclusion de personnes souvent peu représentées dans Fedora (femmes, personnes non américaines et non européennes, étudiants, etc.) ;
  • Gestion de l'équipe marketing.

Il y a 9 membres pour gérer ce comité. Un gérant, 2 proviennent des ambassadeurs, un du design et web, un de la documentation, un du marketing, un de la commops et les deux derniers sont élus. C'est pour un de ces derniers sièges que le scrutin est ouvert.

Fin de vie de Fedora 31

Charles-Antoine Couret

C'est en ce mardi 24 novembre 2020 que Fedora 31 a été déclaré comme en fin de vie.

Qu'est-ce que c'est ?

Un mois après la sortie d'une version de Fedora n, ici Fedora 33, la version n-2 (donc Fedora 31) est déclarée comme en fin de vie.

Ce mois sert à donner du temps aux utilisateurs pour faire la mise à niveau. Ce qui fait qu'en moyenne une version est officiellement maintenue pendant 13 mois.

En effet, la fin de vie d'une version signifie qu'elle n'aura plus de mises à jour et plus aucun bogue ne sera corrigé. Pour des questions de sécurité, avec des failles non corrigées, il est vivement conseillé aux utilisateurs de Fedora 31 et antérieurs d'effectuer la mise à niveau vers Fedora 33 ou 32.

Que faire ?

Si vous êtes concernés, il est nécessaire de faire la mise à niveau de vos systèmes. Vous pouvez télécharger des images CD ou USB plus récentes.

Il est également possible de faire la mise à niveau sans réinstaller via DNF ou GNOME Logiciels.

GNOME Logiciels a également dû vous prévenir par une pop-up de la disponibilité de Fedora 32 ou 33. N'hésitez pas à lancer la mise à niveau par ce biais.

Revue de presse de Fedora 33

Charles-Antoine Couret

Cela fait depuis Fedora 19 que je publie sur la liste de diffusion de Fedora-fr une revue de presse de chaque sortie d'une nouvelle version. Récapituler quels sites en parle et comment. Je le fais toujours deux semaines après la publication (pour que tout le monde ait le temps d'en parler). Maintenant, place à Fedora 33 !

Bien entendu je passe sous silence mon blog et le forum de fedora-fr. Je prends le parti pris de parfois pointer les annonces de la Bêta quand elles sont plus complètes pour décrire les nouveautés que pour la version finale. C'est notamment le cas de NextINpact qui évidemment ont toujours un petit mot que la version sort en version finale. ;-)" class="smiley

Sites web d'actualité

Soit 6 sites sur les 25 contactés.

Blogs, sites persos ou sites non contactés

Soit 3 sites.

Bilan

Le nombre de sites parlant de Fedora 33 est en stabilisation.

La semaine de sa sortie, nous avons eu globalement une augmentation de visites par rapport à la semaine d'avant de cet ordre là :

  • Forums : hausse de 18,1% (environ 1200 visites en plus)
  • Documentation : hausse d'environ 13,6% (soit environ 650 visites en plus)
  • Le site Fedora-fr : hausse de 12,3% (soit 200 visites en plus)
  • Borsalinux-fr : hausse de 225% (soit 45 visites en plus)

À tenir compte de la situation particulière avec le confinement. Cela semble cependant assez similaire à ce qu'on a vécu en mai avec la précédente version.

Si vous avez connaissance d'un autre lien, n'hésitez pas à partager ! Rendez-vous pour Fedora 33.

Nouvelle version de Fedora dite 33

Charles-Antoine Couret

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

Fedora 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 peut se voir comme une sorte de vitrine technologique pour le monde du logiciel libre, cest pourquoi elle est prompte à inclure des nouveautés.

Fedora garde un rôle central dans le développement de ces nouveautés via le développement en amont. En effet, les développeurs de la distribution contribuent également directement au code dun certain nombre de logiciels libres contenus dans la distribution, dont le noyau Linux, GNOME, NetworkManager, PackageKit, PulseAudio, Wayland, systemd, la célèbre suite de compilateurs GCC, etc. Cliquez ici pour voir lensemble des contributions de Red Hat.

Cela a été aussi abordé dans une série d'articles ici, et par ici encore.

GNOME-Bureau.png

Expérience utilisateur

Passage à GNOME 3.38. Cette mise à jour apporte de nombreux changements :

  • Les grilles d'applications fréquemment utilisées et toutes ont fusionné.
  • L'application Visite a été revisitée pour guider les utilisateurs lors de leur première utilisation de GNOME, pour présenter les fonctionnalités de base et être plus accessible aux débutants.
  • Un contrôle parental a été ajouté au panneau de configuration des utilisateurs. Des applications peuvent ne pas être lancées ou installées par un utilisateur particulier.
  • Quelques améliorations ergonomiques avec l'option pour afficher le pourcentage de batterie (sans recourir aux paramètres avancés) ou la possibilité de redémarrer la machine directement depuis le menu principal.
  • Certaines applications ont été redessinées comme l'outil de capture d'écran ou l'enregistrement vocal. De nombreuses icônes d'application ont été aussi redessinées.
  • Amélioration des performances lors de l'enregistrement de l'écran.
  • Avec Wayland uniquement, les écrans peuvent avoir un taux de rafraichissement différent, selon les spécifications de la machine.
  • Le navigateur Web de GNOME active par défaut une protection contre le pistage, permet de rendre un onglet muet et désactive la lecture automatique des vidéos.
  • Le gestionnaire d'index de fichiers Tracker a été mis à jour vers la version 3 et la plupart des applications GNOME en tire profit. Il permet principalement à chaque application d'avoir son propre index, ce qui est aussi utile dans le cas des applications fonctionnant avec Flatpak.

Nettoyage de la fonction pour cacher le menu du chargeur de démarrage. Cette fonction introduite avec Fedora 29 permet de mettre à jour le noyau de manière transparente pour l'utilisateur. Si après une mise à jour du noyau le démarrage échoue, le chargeur de démarrage le détectera pour choisir le noyau précédent automatiquement par la suite. Cette fonction était spécifique à Fedora et l'objectif ici est de la rendre disponible en amont et sera également plus maintenable en tirant parti de l'API de systemd et de sa variable d'environnement SYSTEMD_REBOOT_TO_BOOT_LOADER_MENU.

C'est le retour des fonds d'écran animés par défaut, le fond d'écran a une teinte qui varie en fonction de l'heure de la journée. Fedora avait introduit cette nouveauté dans Fedora 7 avant de la rendre facultative par la suite.

L'environnement de bureau LXQt 0.15.0 a été mis à jour. Cette version apporte entre autres :

  • Un nouveau widget pour la barre principale pour changer la luminosité de l'écran.
  • La luminosité de l'écran peut également se réduire automatiquement si l'ordinateur est inactif trop longtemps.
  • Depuis la barre des tâches il devient possible de changer le bureau virtuel d'une application.
  • Le navigateur de fichiers peut sauvegarder les mots de passe pour monter un système de fichier, si le démon gnome-keyring est actif.

GNOME-Redémarrer.png

L'éditeur de texte en console nano devient l'éditeur de texte par défaut en lieu et place de vi . En réalité la variable $EDITOR n'a jamais été configurée par défaut dans Fedora et pour de nombreux outils tels que git, vi devenait le choix alternatif privilégié. Cependant nano est considéré comme plus intuitif pour les utilisateurs en ne nécessitant pas de connaissances particulières pour s'en servir. Que les amateurs de l'éditeur du diable se rassurent, le paquet vim-minimal qui installe vi (mais pas vim) est installé par défaut, il reste donc disponible sur une nouvelle installation. Seule la variable $EDITOR est ici affectée.

L'extension de mémoire avec le mécanisme du swap utilise maintenant zram par défaut. En effet, quand la mémoire vive physique vient à manquer, le noyau peut utiliser la pagination pour transférer des programmes ou données en mémoire sur la mémoire de masse comme le disque dur ou un SSD. Cela est transparent pour l'utilisateur et les programmes mais cependant cette procédure est lente car ces périphériques ne sont pas aussi rapides d'accès que la RAM. Il n'est pas rare en effet que l'usage de swap puisse ralentir un ordinateur trop fortement, nécessitant de le redémarrer brutalement. Pour améliorer la réactivité et les performances, on peut à la place compresser en RAM ces données. Cela libère de la place tout en étant plus rapide que d'utiliser la mémoire de masse en échange d'un léger surcoût en mémoire de 0,1% à 0,04%. C'est ce que propose zram. Ce changement concerne aussi les systèmes existants. Les partitions ou fichiers swap existants sont préservés et obtiennent une priorité d'utilisation plus faible, donc uniquement quand zram aura atteint ses propres limites. Par défaut zram sera configuré pour avoir une taille équivalente à la moitié de la RAM du système, borné à 4 Gio si l'ordinateur a plus de 8 Gio de RAM.

Btrfs devient le système de fichier par défaut des variantes orientées bureautiques dont Fedora Workstation. Il remplace ainsi ext4 qui reste évidemment possible d'utiliser pour ceux le souhaitant. Notons que OpenSuse 13.4 avait sauté le pas en 2014, et Facebook l'utilise en interne depuis un moment, un employé de l'entreprise ayant d'ailleurs participé à ce changement dans Fedora. Les bénéfices attendus sont :

  • La correction de certains bogues liés à la séparation stricte entre les partitions / et /home.
  • Une compression native des données redondantes, réduisant l'espace de stockage pris et l'usure des périphériques de stockage.
  • La possibilité de réserver des IO minimum à certains processus via l'usage des cgroups, ce que Btrfs gère bien.
  • Réduction de la complexité du stockage en ayant Btrfs qui gère l'ensemble depuis le noyau.

Les systèmes existants ne sont pas concernés par ce changement pour éviter les problèmes liés à une telle migration qui serait compliquée d'automatiser de manière fiable.

DXVK devient l'implémentation de référence de wine3d en étant basé sur Vulkan. Cela améliorera les performances et la compatibilité des programmes graphiques prévus pour Windows et fonctionnant sous Fedora, en particulier les jeux vidéo. Le paquet wine-dxvk était disponible depuis Fedora 31 pour activer ce changement manuellement.

Alors que earlyoom était apparu sur Fedora Workstation 32, la variante Fedora KDE le propose désormais par défaut. En somme, quand la mémoire vive descend en dessous de 4% de mémoire disponible et que la mémoire swap descend en dessous des 10%, un signal SIGTERM sera envoyé au processus choisi pour être coupé proprement afin de libérer assez de mémoire pour que la machine continue de tourner dans ces conditions. Si cela descend respectivement à 2% pour la RAM et 5% pour la swap, un signal SIGKILL sera envoyé ce qui mettra fin au processus immédiatement. L'objectif est de garder un système fluide et utilisable pour l'utilisateur, en évitant de devoir recourir à un redémarrage forcé.

Un cgroups a été créé pour réserver des ressources minimum aux sessions graphiques actives. Un utilisateur actif avec une session graphique a 250 Mio de réservé, plafonné à 10% de la mémoire vive disponible. Ce dispositif repose sur le démon uresourced pour le moment, l'objectif sera de le l'intégrer dans les projets en amont plus tard.

Gestion du matériel

Activation des techniques Arm Pointer Authentication et de Branch Target Identification pour l'architecture Aarch64 pour améliorer la sécurité des programmes par défaut. La première technique permet de se protéger contre les attaques de type Return Oriented Programming, les pointeurs reçoivent un tag qui est ensuite vérifié pour s'assurer qu'il n'a pas été altéré. Le second consiste en identifiant les sauts et branchements dans le code pour qu'ils ne puissent aller que dans une liste d'instructions autorisées, limitant le risque d'exécution de code arbitraire. Les paquets sont donc compilés avec GCC et son option -mbranch-protection=standard.

Meilleure gestion des pics d'activité et de la chauffe des processeurs Intel, entre autre via le démon thermald. En effet les processeurs modernes, notamment ceux d'Intel, disposent d'une grande variété de capteurs de températures et de différents modes pour limiter la fréquence du processeur afin de réduire ou contenir la température. Ce démon va collecter les données du processeur pour choisir le mode le plus optimal de fonctionnement.

Pourcentage batterie.png

L'écosystème .NET Core est disponible pour Aarch64 et non plus uniquement pour l'architecture x86_64.

L'édition Internet des objets de Fedora devient une édition officielle de Fedora. Il obtient donc le même statut que l'édition Workstation ou Server. Cette édition qui cible les architectures x86_64, Aarch64 et ARMv7 repose sur rpm-ostree comme Fedora Silverblue et les applications dans des conteneurs pour faciliter la maintenance et la mise à jour des composants internes. C'est également une édition minimaliste par défaut.

Internationalisation

La plateforme de traduction Zanata tire complètement sa révérence de l'écosystème Fedora. Cela met fin à la transition de la plateforme de traduction de Zanata vers Weblate qui a franchi une grande étape déjà dans Fedora 32. Ainsi il n'y a plus qu'une seule plateforme de traduction active, ce qui simplifie la maintenance et la gestion des traductions.

Weblate apporte aussi entre autre pour les contributeurs :

  • De simplifier l'accès aux nouveaux, en n'ayant pas besoin d'approuver les comptes avant qu'ils ne puissent contribuer.
  • La possibilité d'ajouter des notifications ou des commentaires pour simplifier le travail.
  • D'utiliser un outil utilisé par d'autres projets libres, permettant de mutualiser les développements autour de cet outil.
  • D'automatiser certaines tâches comme la mise à jour automatique des fichiers de traduction.

Administration système

La synchronisation du temps par le réseau sécurisé (NTS) est prise en charge dans le client NTP chrony et l'installateur anaconda. Cela permet d'éviter les attaques de type homme du milieu pour le changement d'heure, trop loin dans le futur ou dans le passé. Cette synchronisation utilise le protocole de sécurité TLS.

Les dépôts modulaires sont proposés dans un paquet à part : fedora-repos-modular. Ce paquet reste installé par défaut. Cela permet aux utilisateurs de désactiver facilement les dépôts en supprimant le paquet plutôt qu'en changeant la configuration des dépôts ce qui empêche les mises à jour ultérieur de ces fichiers de configuration.

Renforcement de la politique globale du système :

  • désactivation des protocoles TLS 1.0 et TLS 1.1 ;
  • rejet des clés Diffie-Hellman 1024 bits et de la fonction de hashage SHA-1 en guise de signature.

En cas de problèmes, pour revenir à une politique plus souple, vous pouvez exécuter la commande :

# update-crypto-policies --set LEGACY

Ajout de PARSEC pour proposer une API pour le matériel de sécurité ou des services de cryptographie en étant indépendant du matériel. Il peut exploiter les matériels de sécurité suivants : TPM2, HSM et Arm TrustZone. L'édition Internet des Objets propose cette API par défaut.

Storage Instantiation Daemon fait son arrivée en grande pompes. L'objectif est d'avoir un démon unique pour étendre udev pour la gestion des espaces de stockage pour éviter d'aboutir à des règles complexes que l'on pouvait avoir dans des systèmes complexes. Cela permet de collecter facilement tous les évènements relatifs à un périphérique de stockage comme son insertion ou son retrait du système. Il prend en charge des périphériques employés à travers plusieurs sous systèmes comme LVM, multipath ou MD avec les mêmes commandes.

LxQT-Bureau.png

Mise à jour de Stratis 2.1. Cette version apporte le chiffrement des données avec notamment une interface DBus pour leur gestion. Les clés de chiffrement sont ensuite gérés dans le noyau. L'utilitaire en ligne de commandes peut aussi initialiser le cache avec la commande init_cache. Les sous commandes report et key sont ajoutés pour gérer ou voir respectivement les rapports générés par Stratis et les clés de chiffrement.

Le gestionnaire de paquets RPM 4.16 a été mis à jour. Le parseur des fichiers specs et macro a été amélioré. Les macros disposent de nouvelles fonctionnalités comme l'opérateur ternaire ou une comparaison des versions nativement. Les meta dépendances sont également ajoutées.

Les bases de données RPM passent du format Berkeley DB à SQLite. Ceci arrive grâce à la nouvelle version de RPM. L'ancien format n'était plus maintenu depuis des années car la nouvelle version de l'utilitaire Berkeley DB 6.x a adopté une licence incompatible. De plus ce format n'était pas transactionnel, donc incapable de détecter et de corriger lui même les erreurs suite à un crash ou à une corruption de données par exemple. SQLite offre donc une solution plus robuste.

La communauté francophone

L'association

Logo.png

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 hebdomadaires chaque lundi soir à 20h30 (heure de Paris) sur IRC (canal #fedora-meeting-1 sur Freenode).

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, José Fournier et les autres contributeurs et relecteurs pour leurs contributions.

L'équipe se réunit tous les lundis soir après 21h (heure de Paris) sur IRC (canal #fedora-doc-fr sur Freenode) pour faire progresser la documentation par un travail collaboratif. Le reste de la semaine cela 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 33 ?

Mediawriter.png

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

Fedora 33 Beta est de sortie

Charles-Antoine Couret

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

Malgré les risques concernant la stabilité dune 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 33 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 20 ou 27 octobre. Voici les nouveautés annoncées pour cette version :

Expérience utilisateur

  • Passage à GNOME 3.38.
  • Nettoyage de la fonction pour cacher le menu du chargeur de démarrage. Cette fonction introduite par le passé permet de mettre à jour le noyau de manière transparente pour l'utilisateur, si après une mise à jour du noyau le démarrage échoue, le chargeur de démarrage le saura pour choisir le noyau précédent automatiquement au redémarrage. Cette fonction était spécifique à Fedora et l'objectif ici est de le rendre disponible en amont.
  • C'est le retour des fonds d'écran animés par défaut, le fond d'écran a une teinte qui varie en fonction de l'heure de la journée.
  • L'environnement de bureau LXQt 0.15.0 a été mis à jour.
  • Le service dmraid-activation.service ne sera pas activé si aucun système RAID n'est détecté lors de l'installation.
  • L'éditeur de texte nano devient l'éditeur de texte par défaut en lieu et place de vi car il est considéré comme plus intuitif.
  • L'extension de mémoire avec le mécanisme du swap utilise maintenant zram par défaut pour améliorer la réactivité et les performances. Cela est effectué aussi pour les systèmes existants. Les partitions ou fichiers swap existants sont préservés et obtiennent une priorité d'utilisation plus faible.
  • Btrfs devient le système de fichier par défaut des variantes orientées bureautiques dont Fedora Workstation. Il remplace ainsi ext4 qui reste évidemment possible d'utiliser. Notons que OpenSuse avait sauté le pas il y a déjà plusieurs années.
  • DXVK devient l'implémentation de référence de wine3d en étant basé sur Vulkan. Cela améliorera les performances des programmes graphiques prévus pour Windows et fonctionnant sous Fedora, en particulier les jeux vidéo.
  • Alors que earlyoom était apparu sur Fedora Workstation 32, la variante Fedora KDE le propose désormais par défaut
  • Un cgroups a été crée pour réserver des ressources minimum aux sessions graphiques actives.

Gestion du matériel

  • Activation des techniques Arm Pointer Authentication et de Branch Target Identification pour l'architecture Aarch64 pour améliorer la sécurité des programmes par défaut.
  • Meilleure gestion des pics d'activité et de la chauffe des processeurs Intel, entre autre via le démon thermald.
  • L'écosystème .NET Core est disponible pour Aarch64 et non plus uniquement pour l'architecture x86_64.
  • L'édition Internet des objets de Fedora devient une édition officielle de Fedora.

Internationalisation

  • Mise à jour d'IBus 1.5.23.
  • La plateforme de traduction Zanata tire complètement sa révérence de l'écosystème Fedora.

Administration système

  • La synchronisation du temps par le réseau sécurisé (NTS) est prise en charge dans le client NTP chrony et l'installateur anaconda.
  • Les dépôts modulaires sont proposés dans un paquet à part : fedora-repos-modular.
  • La résolution des noms de domaine dans les applications se fera via systemd-resolved. La bibliothèque glibc utilisera nss-resolve au lieu de nss-dns jusqu'à aujourd'hui.
  • Renforcement de la politique globale du système : désactivation des protocoles TLS 1.0 et TLS 1.1, rejet des clés Diffie-Hellman 1024 bits et des hash SHA-1 en guise de signature.

En cas de problème, pour restaurer à une politique plus souple, vous pouvez exécuter la commande :

# update-crypto-policies --set LEGACY
  • La prise en charge du format dbm dans NSS a été supprimée.
  • Ajout de PARSEC pour proposer une API pour le matériel de sécurité ou des services de cryptographie en étant indépendant du matériel. Il peut exploiter les matériels suivants : TPM2, HSM et Arm TrustZone.
  • Storage Instantiation Daemon fait son arrivée en grande pompes. L'objectif est d'avoir un démon unique pour étendre udev pour la gestion des espaces de stockage pour éviter d'aboutir à des règles complexes que l'on pouvait avoir dans des systèmes complexes.
  • La collection d'outils X.org sera proposée via des paquets plus individuels que les paquets génériques xorg-x11-{apps,font-utils,resutils,server-utils,utils,xkb-utils} employés jusqu'ici. Certains utilitaires sont également supprimés.
  • Mise à jour de Stratis 2.1.
  • Le paquet device-mapper-multipath a été supprimé des LiveCD (et de fait des installations par défaut) ce qui améliore le temps de boot pour les usages bureautiques. Les serveurs et data center qui en ont besoin pour leur usage pourront toujours l'installer ou en disposer via une image plus adaptée.
  • Les profils de connexion de NetworkManager seront sauvegardés dans le format officiel keyfile au lieu d'utiliser le format spécifique à Red Hat qui est ifcfg-rh. Cela ne concerne que les nouveaux profils, la compatibilité est pour l'instant conservée pour les profils pré-existants.
  • Le gestionnaire de paquets RPM 4.16 a été mis à jour.
  • Les bases de données RPM passent du format Berkeley DB à Sqlite.

Développement

  • LLVM passe à la 11e version.
  • Make prépare sa 4.3 version.
  • Mise à jour de la bibliothèque C glibc 2.32.
  • Mise à jour des outils Binutils 2.34.
  • Petit coup de Boost 1.73 pour la bibliothèque générique C++.
  • Mise à jour de l'environnement MinGW pour la compilation d'applications Windows sous Linux.
  • Passage de Golang à la version 1.15.
  • OpenJDK 11 danse la Java.
  • Node.js fait un 14e nœud.
  • Erlang 23 est disponible.
  • Mise à jour de GHC 8.8 et de Haskell Stackage LTS 16.
  • Le langage Perl est proposé à la version 5.32.
  • Ruby On Rails embarque dans la voiture 6.0.
  • La version 3.9 de Python débarque.
  • Alors que les versions 2.6 et 3.4 de Python sont supprimées.
  • À propos de Python, le paquet python-pytoml est déprécié et sera supprimé prochainement.
  • mod_php est supprimé, il permettait au serveur Apache d'exécuter du PHP directement.
  • La bibliothèque libdb est dépréciée et sera supprimée définitivement dans une prochaine version de Fedora.
  • Le paquet glibc-headers.i686 et glibc-headers.x86_64 ont fusionné dans le nouveau paquet glibc-headers-x86.noarch. Pour les autres architectures le paquet glibc-headers a fusionné dans glibc-devel.
  • Les paquets de BLAS/LAPACK seront compilés avec FlexiBLAS qui est un wrapper pour pouvoir choisir la bibliothèque compatible BLAS de référence de son choix.

Projet Fedora

  • CMake peut être utilisé pour faire des compilations dans différents répertoires pour la conception des RPM.
  • Mise à disposition de ELN qui est un nouveau buildroot qui permettra de simuler un environnement RHEL afin d'évaluer les impacts des changements de Fedora dans RHEL directement.
  • Les paquets sont maintenant compilés avec l'optimisation au niveau de l'éditeur des liens qui supprime le code inutile.
  • Phase 3 pour supprimer les éléments automagiques pour la constructions des paquets RPM autour de Python.
  • Les dépendances additionnelles des paquets Python seront automatiquement générées.
  • La macro non versionnée %{__python} génèrera une erreur.
  • Ajout des macros %make_build et %make_install pour la conception des RPM afin d'avoir un usage plus uniforme de la commande make pour créer ces paquets.

Tester

Durant le développement d'une nouvelle Fedora, 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, linternationalisation, 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 32 ou 31 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.

Bons tests à tous !

AMC version 1.4.0 Fedora 32

Patrice Kadionik

Les RPM d'AMC (Auto Multiple Choice) version 1.4.0 pour Fedora 32 sont disponibles dans le dépôt eddy33.


Installation :

$ sudo dnf install perl-Gtk3 perl-Clone
$ sudo dnf install http://kadionik.vvv.enseirb-matmeca.fr/fedora/eddy33-release-32.rpm
$ sudo dnf install auto-multiple-choice
++

Fedora 32 vs Fedora 31 : comparaison des performances pour les versions 64 bits

Patrice Kadionik

Salut.

Voici les résultats comparatifs de Fedora 32 vs Fedora 31.

Pour rappel, ma machine est équipée d'un Quad Core Intel Q6600 à 2,4 GHz avec 4 Go de RAM.

Je me suis limité au benchmark UnixBench qui fournit un indice global, ce qui me simplifiera la comparaison. La version UnixBench utilisée est la version 4.1.0.

Mon protocole de tests est le suivant :
  • Installation de Fedora 32 version 64 bits avec le noyau Fedora  5.6.6-300.fc32.x86_644.
  • La machine est placée en niveau 3 (init 3).
  • 10 séries de tests avec UnixBench compilé sous Fedora 32 et exécuté sous Fedora 32 (5.6.6-300.fc32.x86_64).
  • 10 séries de tests avec UnixBench compilé sous Fedora 31 et exécuté sous Fedora 31 (5.3.7-301.fc31.x86_64).
Voici les résultats obtenus :

Fedora 32 version 64 bits :

Série 1 : 672.0
Série 2 : 680.7
Série 3 : 671.5
Série 4 : 687.4
Série 5 : 681.9
Série 6 : 675.2
Série 7 : 670.2
Série 8 : 688.8
Série 9 : 679.6
Série 10 : 682.9

Moyenne : 679.0

Fedora 31 version 64 bits :

Voici pour rappel les résultats obtenus avec Fedora 31 :
Série 1 : 673.4
Série 2 : 680.6
Série 3 : 683.4
Série 4 : 688.7
Série 5 : 688.8
Série 6 : 709.1
Série 7 : 725.5
Série 8 : 686.1
Série 9 : 701.7
Série 10 : 718.8

Moyenne : 695.6

Résultats :

Pour Fedora 32, on obtient un indice moyen de 679.0 pour UnixBench.
Pour Fedora 31, j'avais obtenu un indice moyen de 695.6 pour UnixBench.


On a donc une petite baisse de 2,4 % de Fedora 32 64 bits par rapport à Fedora 31 64 bits :

perfs_fedora_F32.png

Conclusion :

Au moment de ces tests, le noyau Fedora 32 (basé sur le noyau vanilla 5.6.6) est un peu moins performant de près de 2,4% que le noyau Fedora 31 (basé sur le noyau vanilla 5.3.7). On retrouve la fluctuation habituelle par rapport aux précédents tests.

++

Résultats des élections de Fedora 06/20

Charles-Antoine Couret

Comme je vous le rapportais il y a peu, Fedora a organisé des élections pour renouveler partiellement le collège de ses organes FESCo, Mindshare et Council.

Le scrutin est comme toujours un vote par valeurs. Nous pouvons attribuer à chaque candidat un certain nombre de points, dont la valeur maximale est celui du nombre de candidat, et le minimum 0. Cela permet de montrer l'approbation à un candidat et la désapprobation d'un autre sans ambiguïté. Rien n'empêchant de voter pour deux candidats avec la même valeur.

Les résultats pour le Conseil sont :

  # votes |  noms
  - --------+----------------------
  654   Aleksandra Fedorova
  - --------+----------------------
  591   Till Maas
  314   James Cassell
  303   Alberto Rodriguez Sanchez

À titre indicatif le score maximal possible était de 267 * 4 votes soit 1068.

Les résultats pour le FESCo sont (seuls les quatre premiers sont élus) :

  # votes |  noms
- --------+----------------------
    1507  | Neal Gompa (ngompa)
    1450  | Stephen Gallagher (sgallagh)
    1372  | Igor Raits (ignatenkobrain)
    1148  | Clément Verna (cverna)
- --------+----------------------
    1124  | Justin Forbes (jforbes)
     997  | Chris Murphy (chrismurphy)
     937  | Petr Šabata (psabata)
     904  | Frantisek Zatloukal (frantisekz)
     755  | James Cassell (cyberpear)
     730  | Michal Novotný (clime)

À titre indicatif le score maximal possible était de 273 * 10 soit 2730.

Les résultats pour le Mindshare sont donc :

     # votes |  noms
     - --------+----------------------
     586        Maria Leandro
     - --------+----------------------
     420        Sumantro Mukherjee
     288        Alessio Ciregia
     188        Daniel Lara

À titre indicatif le score maximal possible était de 220 * 4 soit 880.

Nous pouvons noter que globalement le nombre de votants pour chaque scrutin avec un réel enjeu était proche aux alentours de 275-250 votants ce qui est proche de l'édition précédente. Les scores sont aussi plutôt éparpillés.

Bravo aux participants et aux élus et le meilleur pour le projet Fedora.

06/20 Élections pour le Conseil, FESCo et Mindshare pendant encore quelques jours

Charles-Antoine Couret

Comme le projet Fedora est communautaire, une partie du collège des organisations suivantes doit être renouvelée : Council, FESCo et Mindshare. Et ce sont les contributeurs qui décident. Chaque candidat a bien sûr un programme et un passif qu'ils souhaitent mettre en avant durant leur mandat pour orienter le projet Fedora dans certaines directions. Je vous invite à étudier les propositions des différents candidats pour cela.

J'ai voté

Pour voter, il est nécessaire d'avoir un compte FAS actif et de faire son choix sur le site du scrutin. Vous avez jusqu'au vendredi 12 juin à 2h heure française pour le faire. Donc n'attendez pas trop.

Par ailleurs, comme pour le choix des fonds d'écran additionnel, vous pouvez récupérer un badge si vous cliquez sur un lien depuis l'interface après avoir participé à un vote.

Je vais profiter de l'occasion pour résumer le rôle de chacun de ces comités afin de clarifier l'aspect décisionnel du projet Fedora mais aussi visualiser le caractère communautaire de celui-ci.

Council

Le Council est ce qu'on pourrait qualifier le grand conseil du projet. C'est donc l'organe décisionnaire le plus élevé de Fedora. Le conseil définit les objectifs à long terme du projet Fedora et participe à l'organisation de celui-ci pour y parvenir. Cela se fait notamment par le biais de discussions ouvertes et transparentes vis à vis de la communauté.

Mais il gère également l'aspect financier. Cela concerne notamment les budgets alloués pour organiser les évènements, produire les goodies, ou des initiatives permettant de remplir les dits objectifs. Ils ont enfin la charge de régler les conflits personnels importants au sein du projet, tout comme les aspects légaux liés à la marque Fedora.

Les rôles au sein du conseil sont complexes.

Ceux avec droit de vote complet

Tout d'abord il y a le FPL (Fedora Project Leader) qui est le dirigeant du conseil et de facto le représentant du projet. Son rôle est lié à la tenue de l'agenda et des discussions du conseil, mais aussi de représenter le projet Fedora dans son ensemble. Il doit également servir à dégager un consensus au cours des débats. Ce rôle est tenu par un employé de Red Hat et est choisi avec le consentement du conseil en question.

Il y a aussi le FCAIC (Fedora Community Action and Impact Coordinator) qui fait le lien entre la communauté et l'entreprise Red Hat pour faciliter et encourager la coopération. Comme pour le FPL, c'est un employé de Red Hat qui occupe cette position avec l'approbation du conseil.

Il y a deux places destinées à la représentation technique et à la représentation plus marketing / ambassadrice du projet. Ces deux places découlent d'une nomination décidée au sein des organes dédiées à ces activités : le FESCo et le Mindshare. Ces places sont communautaires mais ce sont uniquement ces comités qui décident des attributions.

Il reste deux places communautaires totalement ouvertes et dont tout le monde peut soumettre sa candidature ou voter. Cela permet de représenter les autres secteurs d'activité comme la traduction ou la documentation mais aussi la voix communautaire au sens la plus large possible. C'est pour une de ces places que le vote est ouvert cette semaine !

Ceux avec le droit de vote partiel

Un conseiller en diversité est nommé par le FPL avec le soutien du conseil pour favoriser l'intégration au sein du projet des populations le plus souvent discriminées. Son objectif est donc de déterminer les programmes pour régler cette problématique et résoudre les conflits associés qui peuvent se présenter.

Un gestionnaire du programme Fedora qui s'occupe du planning des différentes versions de Fedora. Il s'assure du bon respect des délais, du suivi des fonctionnalités et des cycles de tests. Il fait également office de secrétaire du conseil. C'est un employé de Red Hat qui occupe ce rôle toujours avec l'approbation du conseil.

FESCo

Le FESCo (Fedora Engineering Steering Committee) est un conseil entièrement composé de membres élus et totalement dévoués à l'aspect technique du projet Fedora.

Ils vont donc traiter en particulier les points suivants :

  • Les nouvelles fonctionnalités de la distribution ;
  • Les sponsors pour le rôle d'empaqueteur (ceux qui pourront donc superviser un débutant) ;
  • La création et la gestion des SIGs (Special Interest Group) pour organiser des équipes autour de certaines thématiques ;
  • La procédure d'empaquetage des paquets.

Le responsable de ce groupe est tournant. Les 9 membres sont élus pour un an, sachant que chaque élection renouvelle la moitié du collège. Ici 4 places sont à remplacer.

Mindshare

Mindshare est une évolution du FAmSCo (Fedora Ambassadors Steering Committee) qu'il remplace. Il est l'équivalent du FESCo sur l'aspect plus humain du projet. Pendant que le FESCo se préoccupera beaucoup plus des empaqueteurs, la préoccupation de ce conseil est plutôt l'ambassadeur et les nouveaux contributeurs.

Voici un exemple des thèmes dont il a compétence qui viennent du FAmSCo :

  • Gérer l'accroissement des ambassadeurs à travers le mentoring ;
  • Pousser à la création et au développement des communautés plus locales comme la communauté française par exemple ;
  • Réaliser le suivi des évènements auxquels participent les ambassadeurs ;
  • Accorder les ressources aux différentes communautés ou activités, en fonction des besoin et de l'intérêt ;
  • S'occuper des conflits entre ambassadeurs.

Et ses nouvelles compétences :

  • La communication entre les équipes, notamment entre la technique et le marketing ;
  • Motiver les contributeurs à s'impliquer dans différents groupes de travail ;
  • Gérer l'arrivé de nouveaux contributeurs pour les guider, essayer de favoriser l'inclusion de personnes souvent peu représentées dans Fedora (femmes, personnes non américaines et non européennes, étudiants, etc.) ;
  • Gestion de l'équipe marketing.

Il y a 9 membres pour gérer ce comité. Un gérant, 2 proviennent des ambassadeurs, un du design et web, un de la documentation, un du marketing, un de la commops et les deux derniers sont élus. C'est pour un de ces derniers sièges que le scrutin est ouvert.

Fin de vie de Fedora 30

Charles-Antoine Couret

C'est en ce mardi 26 mai 2020 que Fedora 30 a été déclaré comme en fin de vie.

Qu'est-ce que c'est ?

Un mois après la sortie d'une version de Fedora n, ici Fedora 32, la version n-2 (donc Fedora 30) est déclarée comme en fin de vie.

Ce mois sert à donner du temps aux utilisateurs pour faire la mise à niveau. Ce qui fait qu'en moyenne une version est officiellement maintenue pendant 13 mois.

En effet, la fin de vie d'une version signifie qu'elle n'aura plus de mises à jour et plus aucun bogue ne sera corrigé. Pour des questions de sécurité, avec des failles non corrigées, il est vivement conseillé aux utilisateurs de Fedora 30 et antérieurs d'effectuer la mise à niveau vers Fedora 32 ou 31.

Que faire ?

Si vous êtes concernés, il est nécessaire de faire la mise à niveau de vos systèmes. Vous pouvez télécharger des images CD ou USB plus récentes.

Il est également possible de faire la mise à niveau sans réinstaller via DNF ou GNOME Logiciels.

GNOME Logiciels a également dû vous prévenir par une pop-up de la disponibilité de Fedora 31 ou 32. N'hésitez pas à lancer la mise à niveau par ce biais.

Apports de Fedora à l'écosystème du Logiciel Libre partie 3

Charles-Antoine Couret

Il est courant, au sein de la communauté du Logiciel Libre, de présenter une distribution GNU/Linux comme une simple intégration, ou un assemblage de tous les logiciels qu'elle propose. Une sorte de glu entre eux.

Si c'est sans doute le cas de certaines d'entre elles, nous ne pouvons en conclure que c'est toujours le cas. En particulier, la distribution Fedora va au delà de ce constat. Ses objectifs et sa communauté lui permettent de réaliser d'autres choses. En effet depuis sa création Fedora est une vitrine technologique et à ce titre a essayé de mettre en avant ou de développer des solutions novatrices pour le Logiciel Libre. Mais depuis Fedora 21, sortie fin 2011, Fedora s'est découpée en trois produits distincts. Si finalement une Fedora Workstation et Server ont accès aux mêmes paquets, le projet a souhaité fournir des expériences utilisateur adaptées à chaque cas d'usage dès la fin de l'installation. Par conséquent, Fedora Workstation a sa liste de travail pour intégrer et développer de nouvelles solutions pour améliorer l'usage bureautique de l'utilisateur.

Et si la distribution Fedora est souvent considérée comme une version de tests pour la distribution Red Hat Enterprise Linux (RHEL) de Red Hat nous allons constater que finalement toute la communauté tire des bénéfices de ses travaux.

Le présent article est une adaptation des articles de blogs ici et là encore de Christian Schaller qui m'en a donné l'autorisation. Il fait suite à un premier article à ce sujet puis à un second. Le premier article avait donné lieu à une conférence lors des JM2L de 2017 et aux RMLL de 2018 dont la vidéo est disponible ici.

Wayland

La transition vers ce nouveau protocole d'affichage requiert toujours des ajustements et des travaux de long terme.

Actuellement GNOME Shell est en train d'achever cette transition en étant capable de lancer une session GNOME sans utiliser XWayland. Ce dernier ne serait démarré qu'en cas de lancement d'une application ayant toujours besoin de X11. En effet quelques composants internes, comme le démon GNOME Setting, reposaient encore sur l'existence de X11 pour fonctionner.

Il est possible à titre expérimental de forcer ce comportement à l'aide de la commande suivante :

$ gsettings set org.gnome.mutter experimental-features "['autostart-xwayland']"

Cela est rendu possible par Carlos Garnacho pour le travail sur GNOME Shell, Olivier Fourdan pour le nettoyage du centre de contrôle de GNOME, Iain Lane (de Canonical) pour l'amélioration des sessions utilisateurs de systemd et Benjamin Berg de manière générale.

Dans la même veine, Martin Stransky et Jan Horak ont travaillé pour corriger les derniers bogues afin que Firefox puisse utiliser Wayland par défaut dans Fedora 31. Martin Stransky a aussi travaillé pour fournir la prise en charge de l'accélération matérielle pour WebGL.

hoverclick.png

L'une des grandes régressions étaient aussi les outils d'accessibilité de X.org qui ne fonctionnaient plus sous Wayland. Mais grâce à Olivier Fourdan cette prise en charge a été améliorée et il est maintenant possible de cliquer grâce survol d'un élément graphique pendant un certain temps.

Hans de Goede travaille aussi pour autoriser les applications XWayland à être lancées avec les droits super utilisateur. Certes cela n'est pas une action recommandée mais peut être nécessaire pour des raisons de compatibilité.

Il travaille aussi pour améliorer la prise en charge de la bibliothèque d'affichage SDL pour fonctionner correctement sous Wayland, en particulier pour les jeux vidéo avec une faible résolution.

Enfin Adam Jackson opère sur la possibilité d'avoir l'accélération matérielle pour les applications XWayland, quand le pilote propriétaire nVidia est utilisé. Les autres pilotes ou cartes matériels n'ont quant à eux pas ce genre de problèmes grâce à leur inclusion dans le noyau Linux officiel en exploitant l'API moderne correspondante pour l'affichage.

Si vous souhaitez les aider dans ce travail, vous pouvez modifier le fichier /usr/lib/udev/rules.d/61-gdm.rules pour commenter la ligne suivante :

DRIVER=="nvidia", RUN+="/usr/libexec/gdm-disable-wayland

Qui doit devenir

# DRIVER=="nvidia", RUN+="/usr/libexec/gdm-disable-wayland

Ainsi même avec le pilote propriétaire de nVidia, la session de GNOME par défaut sera Wayland et non X.org comme c'est le cas pour les autres cas de figure. X.org sera utilisé en cas de problèmes majeurs d'affichage. Et si vous rencontrez un bogue dans cette configuration, n'oubliez pas de le signaler aux développeurs.

Il n'est plus très loin le moment où X.org ne sera qu'un projet en mode maintenance uniquement.

Pipewire

Wim Taymans continue de travailler pour être capable de remplacer Jack et PulseAudio pour la gestion du son. Par ailleurs le remplacement de Jack est considéré comme opérationel aujourd'hui. Pour PulseAudio le remplacement est fonctionnel en ce moment pour la lecture simple de flux audio mais pas au delà.

Avec Jonas Adahl et Benjamin Berg ils ont apporté la prise en charge de Miracast pour exporter l'écran et le son vers un appareil via le réseau comme un téléviseur.

GNOME Network Display.png

Un client de test pour GNOME, Network Displays, a été conçu à cette fin avant une intégration probable dans la base de GNOME à l'avenir.

Une option de configuration a été ajoutée dans Google Chrome pour prendre en charge le partage d'écran sous Wayland via WebRTC.

Les avancées de Pipewire rendent envisageable sa mise en place par défaut dans Fedora Workstation 33.

Flatpak

Le travail se poursuit pour fournir une infrastructure automatique qui génère des Flatpak à partir de RPM. Les étapes sont à ce jour encore trop manuelles.

Une intégration future de Flathub et de Quay comme dépôts alternatifs disponibles par défaut suit aussi son chemin.

Fedora Toolbox

Debarshi Ray a amélioré l'intégration dans GNOME Terminal. Quand une instance est ouverte dans un onglet, en ouvrir un nouveau à partir de celui-ci va pointer par défaut sur l'espace de ce conteneur plutôt que sur le dossier courant du système hôte.

L'outil a été réécrit pour améliorer sa maintenance à long terme. En passant d'un immense script shell vers un programme conçu en Go. De plus comme les outils buildah et podman sont eux même conçus en Go, cela simplifiera les synergie et les collaborations entre ces différents projets.

Fleet commander

La version 0.14.1 de cette application ajoute la prise en charge des réseaux d'entreprise basés sur Active Directory en plus de FreeIPA. Cela favorisera son adoption dans un réseau d'entreprise centré sur Windows, ce qui est encore souvent le cas.

Il est aussi possible depuis cette version de déployer une extension GNOME dans le parc de machines.

Un travail est en cours pour améliorer la prise en charge de la configuration de Firefox par Oliver Gutierrez Suarez.

Mode jeu

Le fameux gamemode développé par Christian Kellner continue ses améliorations avec une meilleure intégration avec les applications Flatpak.

Gestion du matériel

Lecteurs d'empreintes digitales

La pile fprint qui est la référence libre pour la prise en charge de ces appareils a été pendant longtemps dans un état léthargique. Bastien Nocera a entreprit une modernisation de ce composant, qui consiste notamment en une amélioration de la documentation du projet, en l'ajout de code d'exemples et une mise à jour de certains pilotes.

Un nouveau pilote pour prendre en charge certains lecteurs de Synaptics est en voie de finalisation.

Benjamin Berg quant à lui essaye d'apporter la possibilité d'enregistrer les empreintes digitales au sein du lecteur lui même, quand c'est possible, plutôt que de les stocker sur le disque dur comme cela est fait actuellement.

Dell Totem

dell-totem.jpg

Le dispositif de pointage très particulier Dell Totem est maintenant pris en charge par la bibliothèque libinput. Benjamin Tissoires et Peter Hutterer ont rendu cela possible, alors qu'il est utilisé notamment dans le domaine de la conception assisté par ordinateur.

Firmware

GNOME Firmware.png

Richard Hughes continue son travail sur LVFS pour fournir des mises à jour de firmware sous Linux. Il a écrit une application GNOME Firmware pour afficher les firmwares de votre système, quelques informations à leur propos et s'ils sont compatible la recherche de leur mise à jour.

Sysprof et les performances

Sysprof.png

L'amélioration des performances est un sujet important pour les utilisateurs comme les développeurs. Dans la course à améliorer celles de GNOME Shell, un constat s'est imposé, il manque des outils simples d'usage pour mesurer précisément les performances d'un bureau ou d'une application. Afin d'identifier et de corriger finement les comportements qui réduisent les performances du système.

Christian Hergert a conçu l'outil GNOME Sysprof pour récupérer et afficher des données relatives à un processus.

L'application permet de mesurer durant l'utilisation du logiciel à analyser au cours du temps différents paramètres comme l'usage de la mémoire, du CPU, des accès disques ou réseaux. Il affiche également les fonctions qui allouent de la mémoire et le temps processeur passé dans les fonctions.

D'ailleurs Christian Hergert a découvert et corrigé des appels d'API bloquants dans la boucle principale e GNOME Shell ce qui réduisait la fluidité en cas d'utilisation intensive des entrées / sorties de l'ordinateur. Le système devrait se montrer plus réactif dans ce cas de figure.

GNOME

Le nouvel écran de verrouillage

GNOME écran de verrouillage.png

Il a été profondément remanié par Allan Day et l'équipe design de GNOME. L'intégration entre l'écran de verrouillage, où les notifications et l'heure sont affichées, et celui de la saisie du mot de passe est meilleure. Ce dernier par ailleurs permet d'afficher le mot de passe si souhaité pour s'assurer qu'il est correctement introduit.

Le fait d'utiliser le fond d'écran de l'utilisateur en mode flouté permet aussi d'apporter plus de cohérence et d'élégance à l'interface.

GNOME Extension

GNOME Extensions.png

Cette nouvelle application a été conçue pour gérer les extensions de GNOME, qui permettent d'ajouter ou de modifier des comportements de GNOME Shell sans entraver la maintenance du code principal.

Auparavant les extensions étaient gérés soit via GNOME Ajustements qui est un peu fourre tout ou via https://extensions.gnome.org/ le si... à cet effet. Ce n'était pas spécialement clair pour l'utilisateur comment faire. Ici l'application soccupera exclusivement de cette tâche et son nom aidera à guider les utilisateurs vers cette fonction s'ils le souhaitent.

GNOME Classique

GNOME Classique est un thème de GNOME Shell pour essayer de reproduire l'interface de GNOME 2, tout en gardant les bases techniques de GNOME 3.

Allan Day a supprimé la vue globale des applications, qui est spécifique de l'interface de GNOME 3, dans ce mode pour le rendre plus proche de l'expérience utilisateur que l'on avait avec GNOME 2. Ce mode était automatiquement utilisé en pointant le curseur de la souris dans le coin supérieur gauche de l'écran.

QtGNOME

Cette couche de compatibilité entre les applications écrites en Qt et GNOME permet de s'assurer que les applications s'intègrent du mieux que possible dans GNOME. Utiliser le même thème, choisir l'affichage sombre ou clair, etc.

Jan Grulich a apporté une mise à jour de ce composant pour refléter les changements du thème par défaut de GNOME, Adwaita, et améliorer l'intégration avec les applications Flatpak.

Internationalisation

L'internationalisation est rarement quelque chose de totalement bien prise en charge. Elle requiert souvent des étapes manuelles pour l'utilisateur afin d'avoir tout le contenu de son système dans sa langue natale, avec les polices qui peuvent l'afficher et un format de données qui correspond.

Malgré les améliorations constantes de ce domaine ces dernières années, changer de langue nécessite toujours de faire des actions à plusieurs endroits, comme configurer l'environnement de bureau et installer les paquets manquants. Sundeep Anand a corrigé ce problème sous GNOME, où choisir la langue dans le centre de contrôle entraînera l'installation des langpacks nécessaires.

Codec multimédia

Cisco, Endless, Red Hat et Centricular ont œuvré pour fournir une mise à jour du codec OpenH264 2.0. Cette mise à jour permet la prise en charge de profils additionnels de ce codec, ici High et Advanced, afin de pouvoir lire plus de fichiers employant ce codec.

Wim Taymans a corrigé certains bogues de qualité audio pour les fichiers audio encodés avec AAC.

Le codec MPEG2 est également dans la liste des travaux à venir pour améliorer sa prise en charge native avec du Logiciel Libre avec une bonne qualité. Pour les codecs plus exotiques comme Windows Media ou DivX sont en vue mais pas dans les priorités du moment.

Ce que le futur nous réserve

GNOME

Certaines optimisations dans GNOME devraient encore avoir lieu, notamment autour de la gestion du matériel. En ne démarrant les services et les interfaces de configuration uniquement si le matériel sous-jacent les rendent pertinents. Ainsi le démon de prise en charge du Bluetooth ne sera pas démarré si le matériel ne le prend pas en charge.

Pipewire

Les avancées de Pipewire rendent envisageable sa mise en place par défaut dans Fedora Workstation 33. Bien qu'il reste à finaliser le remplacement de PulseAudio.

Par ailleurs, un travail est en cours pour permettre l'enregistrement de flux vidéo avec zéro copie mémoire. Une optimisation nécessaire pour garantir un traitement rapide en évitant de surcharger le processeur dans cette tâche.

Prise en charge du matériel

Atomic KMS

Jonas Ådahl travaille pour utiliser atomic KMS dans le noyau et la pile graphique du système, afin que l'affichage et la configuration de celui-ci se fassent de manière atomique. Cela peut permettre aussi d'utiliser des fonctionnalités plus avancées du matériel.

Par exemple utiliser le matériel pour stocker le contenu de chaque fenêtre cliente de manière indépendante. Ainsi si seulement le contenu de l'une d'elle change, l'étape de composition peut être sautée au niveau logiciel ce qui accélère la vitesse du rendu. Ou encore permettre d'utiliser des framebuffers sur des écrans plus grands encore avec de bonnes performances.

De plus, le rendu KMS pourrait être effectué dans un fil d'exécution séparé, ce qui réduirait la latence entre un mouvement de la souris et son affichage.

Divers

En collaboration avec Lenovo, certaines fonctionnalités sont attendues dans le futur.

Tout d'abord la prise en charge des microphones à large champ, ce qui est utile en téléconférence quand la personne n'a pas de casque et est possiblement éloigné du micro.

Ensuite il y a la détection de l'utilisation de l'ordinateur portable sur des jambes, pour éviter de brûler l'utilisateur dans un tel cas ce qui est courant en déplacement.

Enfin, il y a la prise en charge de la fonctionnalité matérielle pour limiter l'angle de lecture sur l'ordinateur. La lecture ne serait possible que de face, évitant qu'un voisin ou quelqu'un qui passe derrière vous puisse lire l'intégralité de votre écran. Cela améliorerait la confidentialité de ce qui est affiché.

Conclusion

Comme nous pouvons le voir avec cette liste d'exemples, une distribution denvergure comme Fedora, mais aussi Ubuntu, Debian ou autres peuvent apporter bien plus qu'une liste de logiciels à installer. Ils proposent des nouveaux outils, participent au développement ou à la stabilisation des logiciels qu'ils fournissent, peuvent collaborer avec d'autres entreprises ou communautés pour améliorer la prise en charge de leur produit.

Ici nous ne parlons que des travaux significatifs de ces dernières années, Fedora a également œuvré pour PulseAudio, systemd, PackageKit, NetworkManager, le pilote libre nouveau et tant d'autres composants par le passé !

Malgré les liens forts entre Red Hat et Fedora, nous pouvons voir que beaucoup des travaux de Fedora de ces dernières années ont bénéficié à la plupart des distributions aujourd'hui. Et cela n'est pas près de se terminer.

Par ailleurs, la consécration de ces efforts a été la signature récente du partenariat entre Lenovo et Fedora pour fournir des ordinateurs portables avec Fedora Workstation préinstallé. Cela n'étant possible que parce que le système a atteint une certaine maturité. De plus, ce partenariat sera sans doute le point de départ pour améliorer encore la prise en charge du matériel nativement par le système comme cela a été expliqué brièvement plus haut.

Revue de presse de Fedora 32

Charles-Antoine Couret

Cela fait depuis Fedora 19 que je publie sur la liste de diffusion de Fedora-fr une revue de presse de chaque sortie d'une nouvelle version. Récapituler quels sites en parle et comment. Je le fais toujours deux semaines après la publication (pour que tout le monde ait le temps d'en parler). Maintenant, place à Fedora 32 !

Bien entendu je passe sous silence mon blog et le forum de fedora-fr.

Sites web d'actualité

Soit 5 sites sur les 25 contactés.

Blogs, sites persos ou sites non contactés

Soit 3 sites.

Bilan

Le nombre de sites parlant de Fedora 32 est en stabilisation.

La semaine de sa sortie, nous avons eu globalement une augmentation de visites par rapport à la semaine d'avant de cet ordre là :

  • Forums : hausse de 12,5% (environ 1000 visites en moins)
  • Documentation : hausse d'environ 10% (soit environ 600 visites en plus)
  • Le site Fedora-fr : hausse de 57% (soit 460 visites en plus)
  • Borsalinux-fr : hausse de 241% (soit 60 visites en plus)

À tenir compte de la situation particulière avec le confinement.

Si vous avez connaissance d'un autre lien, n'hésitez pas à partager ! Rendez-vous pour Fedora 33.

Fedora Silverblue en pratique

Charles-Antoine Couret

Fedora Silverblue tente d'établir un système fonctionnel conciliant Fedora Workstation, la version bureautique de la distribution éponyme, et le projet Atomic. Cette déclinaison de Fedora commence à monter en puissance en terme de développements depuis quelques temps et nous réalisons que pour beaucoup de personnes extérieures ce projet reste très flou tant dans ses objectifs mais aussi sur les implications techniques.

Nous avons présenté dans un article précédent l'historique et ce qui a motivé la conception de Fedora Silverblue. Ici nous allons nous attarder plutôt à un cas d'usage en pratique pour voir la différence avec une Fedora classique.

silverblue-logo.png

Généralités

Beaucoup de choses restent identiques par rapport à une Fedora Workstation classique. Même bureau, même interface, logithèque ou fraîcheur des versions. La procédure d'installation avec Anaconda ne change pas vraiment non plus.

Si vous souhaitez tester, vous pouvez télécharger Fedora Silverblue directement ou par Torrent. Ensuite pour l'installer vous pouvez lire le début de cette page de documentation, cela fonctionne aussi bien sur Silverblue.

La différence, comme expliqué dans l'article précédent, réside dans la gestion de la logithèque. Et nous allons en étudier cela en pratique.

Base du système avec RPM ostree

Comme vous le savez, la base du système est un tout uni et dans l'ensemble en lecture seule. Mettre à jour le système signifie passer d'un état vers un autre sans autre altération.

Cela se passe avec la commande suivante :

# rpm-ostree upgrade

Mise à jour Silverblue.png

Une fois cela fait, il suffit de redémarrer et vous basculez vers le votre nouvel état du système, à jour. Notons que GNOME Logiciels permet de réaliser la mise à jour aussi de la base du système mais graphiquement.

On peut voir en effet qu'un nouvel état est installé sur votre machine via la commande :

$ rpm-ostree status

State: idle

AutomaticUpdates: disabled

Deployments:

  ostree://fedora:fedora/31/x86_64/silverblue

                   Version: 31.20200410.0 (2020-04-10T14:27:44Z)

                   Commit: 16f67d3577701f988cb6c32a6376700f24e720e0896b2f5f4a6b6ab65f030b31

              GPGSignature: Valid signature by 7D22D5867F2A4236474BF7B850CB390B3C3359C4

                      Diff: 524 upgraded, 24 downgraded, 13 removed, 18 added



● ostree://fedora:fedora/31/x86_64/silverblue

                   Version: 31.1.9 (2019-10-23T21:44:48Z)

                   Commit: c4bf7a6339e6be97d0ca48a117a1a35c9c5e3256ae2db9e706b0147c5845fac4

              GPGSignature: Valid signature by 7D22D5867F2A4236474BF7B850CB390B3C3359C4

Le système avec le symbole est la version courante du système, sur lequel j'ai démarré après l'installation de Fedora. On constate qu'après la mise à jour un nouvel état est disponible avec sa date d'installation et la référence de la version employée.

Notez la ligne Diff pour cet autre état, il explique la différence entre l'état actuel et celui-ci qui consiste majoritairement en paquets plus récents ici.

Et en effet, après redémarrage de la machine, le symbole a changé de place. La mise à jour a bien été effective et le redémarrage aussi rapide que d'habitude.

La référence vers l'état précédent reste présente, ce qui nous autorise à revenir en arrière automatiquement en cas de gros soucis pour démarrer sur le nouvel état, ou manuellement si on a un problème qu'on a constaté nous même.

Amusons-nous à revenir en arrière, cela se fait simplement :

# rpm-ostree rollback

Et après un redémarrage, on a basculé vers l'état précédent. Simple, fiable et rapide. Notez qu'il est possible de choisir l'état au démarrage via GRUB. En cas d'installation mono-système, le menu de GRUB est caché par défaut, appuyez sur la touche ESC au démarrage de GRUB pour l'afficher et faire votre choix.

Bien sûr il est possible de configurer un peu ce système de base pour résoudre certains problèmes même si cela viole un peu l'esprit derrière Silverblue.

Par exemple, si nous voulons profiter du pilote propriétaire de nVidia car le pilote libre nouveau ne fonctionne pas suffisamment bien sur notre machine. Nous pouvez faire les choses ainsi :

D'abord il faut installer le dépôt externe RPMFusion qui dispose du paquet RPM nécessaire. Un redémarrage est évidemment nécessaire pour changer d'état avec ce dépôt disponible.

# rpm-ostree install https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-31.noarch.rpm  https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-31.noarch.rpm

# systemctl reboot

Ensuite on peut installer le paquet nécessaire et changer l'argument de démarrage du noyau pour désactiver le recours au pilote nouveau. Un redémarrage sera encore nécessaire pour valider l'action.

# rpm-ostree install akmod-nvidia xorg-x11-drv-nvidia-cuda libva-utils libva-vdpau-driver gstreamer1-libav

# rpm-ostree kargs --append=modprobe.blacklist=nouveau --append=rd.driver.blacklist=nouveau

# systemctl reboot

rpm-ostree se charge de tout pour altérer l'état du système de base.

Comme vous pouvez le voir, il reste possible d'installer des paquets RPM à l'ancienne bien que dans le cas de Silverblue cela reste déconseillé en dehors de quelques cas comme celui évoqué plus haut. Cela se fait dans une couche indépendante du système de base et sera déployé au dessus de votre version de référence après chaque mise à jour de ce dernier.

Notez que pour certaines applications, le fait que le système principal soit en lecture seule, peut poser des soucis de compatibilité.

Et si jamais vous souhaitez revenir dans l'état de base de votre système, vous pouvez utiliser simplement cette commande :

# rpm-ostree reset

Et comme Silverblue fonctionne par état pour les mises à jour, ce que l'on a vu plus haut, changer de branche de Fedora est également possible facilement.

GRUB Silverblue.png

D'abord listez les versions possibles et enfin déployez cette version.

# ostree remote refs fedora

# rpm-ostree rebase fedora:fedora/32/x86_64/silverblue

Redémarrez et mission accomplie, vous voilà sous Fedora 32. Cela fonctionne également dans l'autre sens, pour revenir sur Fedora 31 si vous êtes sur la version 32.

Fedora Toolbox

Comme cela a été expliqué dans l'autre article, Fedora Toolbox est une surcouche à podman et buildah. Son but est de facilement créer un conteneur avec une version de Fedora comme base. Il se charge lui même de récupérer les données, de faire en sorte que l'utilisateur soit le même que sur l'hôte, etc. Par ailleurs le répertoire /home est partagé entre l'hôte et les conteneurs ce qui autorise d'exploiter les outils sur vos données.

podman est pour rappel un utilitaire compatible avec Docker mais qui ne nécessite pas d'un démon avec les droits super utilisateurs pour fonctionner. Pour des raisons de sécurité.

Créer un conteneur est très simple :

$ toolbox create

Qui va en créer un avec un nom par défaut et la même version de Fedora que votre instance de Silverblue. Ici fedora-toolbox-31.

Mais on peut bien entendu personnaliser tout ça ainsi :

$ toolbox create --container <nom> --release <version>

$ toolbox create --container fedora30 --release f30

Ensuite on peut utiliser une session de shell pour entrer dans le conteneur de votre choix :

$ toolbox enter --container <nom>

Vous constaterez que le prompt se dote d'un coloré au début, pour vous rappeler que vous êtes dans un conteneur.

Podman.png

Une fois à l'intérieur, vous pouvez faire ce que vous voulez. Utilisez dnf pour installer des paquets, les mettre à jour comme avant, configurer votre système, etc. Lancer des applications depuis un tel conteneur est aussi possible.

D'ailleurs pour exécuter une commande dans un conteneur sans y obtenir un shell, vous pouvez faire :

$ toolbox run --container <name> <commande>

$ toolbox run --container fedora30 gnome-builder

Pour vous y retrouver si vous avez plusieurs conteneurs, vous pouvez les listez ainsi :

$ toolbox list

Images created by toolbox

IMAGE ID      IMAGE NAME                                        CREATED

64e68e194389  registry.fedoraproject.org/f31/fedora-toolbox:31  6 weeks ago

Containers created by toolbox

CONTAINER ID  CONTAINER NAME     CREATED            STATUS                IMAGE NAME

dc75753d59a2  fedora-toolbox-31  2 hours ago        Up 2 hours ago        registry.fedoraproject.org/f31/fedora-toolbox:31

1a9eaf6067c9  fedora30         About an hour ago  Up About an hour ago  registry.fedoraproject.org/f31/fedora-toolbox:31

Et si un conteneur n'est plus utile, vous pouvez le supprimer ainsi :

$ toolbox rm <name>

$ toolbox rm silverblue

L'objectif de Toolbox est de vous simplifier la vie dans la configuration du conteneur pour cet usage, surtout si vous n'êtes pas habitués à cet écosystème. Mais rien ne vous empêche d'utiliser podman ou Docker manuellement. Les commandes podman peuvent être exploitées à la place de Toolbox par exemple sur les conteneurs crées par ce dernier.

Flatpak

Par défaut il n'y a pas beaucoup de Flatpak disponibles dans Silverblue (mais c'est en cours de résolution). La première étape étant d'en installer un dépôt externe comme Flathub. C'est très simple et rapide.

GNOME Logiciels Flatpak.png

Globalement cela consiste à exécuter cette commande :

$ flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

Ensuite vous pouvez utiliser GNOME Logiciels pour télécharger et mettre à jour ces applications.

Ou alors à la main comme suit :

$ flatpak update

$ flatpak list

Name                                              Application ID                                Version           Branch          Origin           Installation

Platform                                          org.fedoraproject.Platform                                     f32             fedora           system

default                                           org.freedesktop.Platform.GL.default                            19.08           flathub          system

openh264                                          org.freedesktop.Platform.openh264                              2.0             flathub          system

Geary                                             org.gnome.Geary                               3.36.1           stable          fedora           system

Lollypop                                          org.gnome.Lollypop                            1.2.33           stable          flathub          system

GNOME Application Platform version 3.36           org.gnome.Platform                                             3.36            flathub          system

Comme vous pouvez le voir, Geary et Lollypop ont été installés par Flatpak, l'un via Flathub, l'autre via Fedora Registry qui propose ses propres Flatpak aussi exploitables dans un conteneur podman ou Docker. Les runtimes nécessaire pour ces applications ont aussi été installés et sont listés ici comme GNOME Application Platform.

Pour installer, il suffit de chercher si un tel paquet existe puis l'installer. Prenons GNOME Agenda comme exemple.

$ flatpak search calendar

Name         Description                                                                  Application ID                Version                   Branch  Remotes

Agenda       Agenda de GNOME                                                              org.gnome.Calendar            3.36.0                    stable  fedora,flathub

$ flatpak install org.gnome.Calendar

Comme l'application existe dans Flathub et Fedora, Flatpak vous demandera la source à utiliser ici. Par défaut un Flatpak est installé dans /var/lib pour être accessible pour l'ensemble des utilisateurs. Mais si pour une raison particulière vous souhaitez que seul votre utilisateur ait accès, vous pouvez ajouter l'argument --user :

$ flatpak install --user org.gnome.Calendar

L'un des avantages de Flatpak est qu'il repose aussi sur des états. Si une mise à jour ne vous plaît pas car elle introduit une régression gênante pour vous, vous pouvez facilement revenir en arrière. D'abord il faut identifier la liste des états disponibles de votre application.

$ flatpak remote-info --log flathub org.gnome.Geary

Ensuite choisir un état et l'appliquer.

$ flatpak update --commit bba3bbb1ab3b127de0fd984279d99170f9ec671b05c18cc64a0c102243664a1c org.gnome.Geary

GNOME Shell permet de les lancer comme une application native évidemment, mais depuis le terminal c'est possible ainsi :

$ flatpak run <application id>

$ flatpak run org.gnome.Geary

Peu à peu les Flatpak disposent d'un système de permissions et de portails pour permettre l'accès aux ressources dont les applications ont besoin uniquement.

Notons aussi que GNOME Logiciels peut présenter les choses de manière un peu trompeuse. Par exemple installer Lollypop qui était le premier Flatpak nécessitait de télécharger près de 1 Gio de données pour 40 Mio installé. En fait le gigaoctet de données était lié aux runtimes nécessaires à télécharger. Mais Geary qui utilise les mêmes runtimes n'a eu besoin que de quelques mégaoctets seulement pour être installé par après. Comme Silverblue repose énormément sur les Flatpak, vos runtimes seront rentabilisés car partagés par beaucoup d'applications.

Si vous souhaitez voir les changements opérés sur les Flatpak comme les installations et mises à jour, une commande est possible :

$ flatpak history

Time              Change         Application                         Branch Installation                                                                         Remote

avril 11 18:00:17 add remote                                                system                                                                               flathub

avril 11 18:06:07 deploy install org.fedoraproject.Platform          f32    system                                                                               fedora

avril 11 18:06:12 deploy install org.gnome.Geary                     stable system                                                                               fedora

Mode de travail avec Silverblue

Avant nous avions un système unifié avec des dépôts centralisés pour tout et il n'y avait pas beaucoup de possibilités pour installer des applications ou maintenir le système. Silverblue en plus introduit une certaine redondance par endroit. Comment s'y retrouver ?

La base du système est globalement en lecture seule et minimaliste. À part le mettre à jour il n'y a pas grand chose à faire en temps normal. Y toucher peut devenir essentiel pour ce qui a trait à la gestion du matériel comme le chargeur de démarrage GRUB ou le noyau et ses pilotes. En dehors de cela il n'est pas recommandé d'essayer de le manipuler. L'objectif est qu'il soit minimal, simple et fiable. Le reste repose sur les conteneurs et Flatpak.

Les Flatpak seront à privilégier pour les applications graphiques. Après tout seules ces applications peuvent être installées par ce biais.

Pour le reste, il y a les conteneurs avec Fedora Toolbox. Utile pour les applications textes, environnements de développement, etc. Le fait d'avoir plusieurs conteneurs permet de séparer les tâches. Le développement Python d'un côté, le serveur Web de l'autre, l'expérimentation d'un projet, un environnement pour le travail professionnel, etc. À vous de voir selon vos envies et besoins. S'il reste possible d'avoir un conteneur fourre tout pour simuler une Fedora classique, cette approche n'est pas réellement dans l'esprit de Silverblue.

Le gain ?

Une partie des gains a été largement relatée dans l'article précédent. Mais avec un peu de pratique, que pouvons-nous observer ?

Tout d'abord la séparation du système en plusieurs parties permet de leur donner une responsabilité propre ce qui améliore dans un sens sa fiabilité mais aussi son élégance. Le système de base se charge de fournir un système qui démarre et qui est exploitable. Il est beaucoup plus difficile d'aboutir à un situation complexe inextricable avec une machine peu fonctionnelle.

La flexibilité est plus grande, via Fedora Toolbox et Flatpak, il est plus facile d'expérimenter des choses et d'adapter votre système à vos besoins. Vous souhaitez tirer profit d'une version de Python qui est dans Fedora 32 et dans Fedora 29 pour vos tests ? Vous pouvez avoir les deux facilement avec Fedora Toolbox en ayant un conteneur pour chaque.

Et si vous avez fini un projet professionnel et que vous n'avez plus besoin de ces conteneurs spécialisés de Python avec les versions spécifiques, il suffit de les supprimer. Plus besoin de chercher les paquets qui étaient nécessaires pour cette tâche et dont vous n'avez plus besoin pour toiletter le système.

Vous souhaitez une version de Firefox très récente mais une de LibreOffice plus ancienne ? Flatpak le permet de concilier les deux facilement comme nous l'avons vu.

Et chaque application n'aura accès qu'aux données et ressources pour lesquels il dispose de votre autorisation, limitant les problèmes dus à des bogues ou des failles.

Mais bien sûr cela a un coût. Besoin de plus de bande passante, de mémoire, CPU et d'espace disque. Le système dans son ensemble est aussi plus complexe à appréhender, de nouvelles choses sont à apprendre.

Présentation de Fedora Silverblue

Charles-Antoine Couret

Fedora Silverblue tente d'établir un système fonctionnel conciliant Fedora Workstation, la version bureautique de la distribution éponyme, et le projet Atomic. Cette déclinaison de Fedora commence à monter en puissance en terme de développements depuis quelques temps et nous réalisons que pour beaucoup de personnes extérieures ce projet reste très flou tant dans ses objectifs mais aussi sur les implications techniques.

L'objet de cet article est de retracer l'histoire rapidement de Atomic et Fedora Silverblue avant d'évoquer les détails de fonctionnement de celui-ci.

silverblue-logo.png

Avant Fedora Silverblue, émergea Fedora.next

Les fondements de Fedora Silverblue prennent racine dans la réflexion menée dans le cadre de Fedora.next, projet censé inscrire Fedora dans la durée après avoir fêté ses dix années. En effet, en 2013-2014, le projet Fedora s'est mis en pause technique pour réfléchir quant à son avenir, dans ce qu'elle souhaitait délivrer à ses utilisateurs tout en tirant un bilan de la situation actuelle. C'est pourquoi il y a eu près d'un an entre Fedora 20 et Fedora 21, au lieu des six mois habituels, pour dégager du temps et prendre du recul au sein du projet tout entier.

Le bilan

Le bilan dressé du développement d'une distribution est particulièrement critique. Il est particulièrement mis en exergue par le manque d'attrait des utilisateurs pour leur distribution, même en dehors de Fedora, et aussi certains défauts structurels quant à l'approche traditionnelle d'aborder la réalisation d'une distribution Linux.

Une distribution Linux classique génère et propose des paquets pour ses utilisateurs, afin qu'ils puissent installer les applications concernées en résolvant les dépendances nécessaires et à priori avec une intégration entre elles pour fournir une expérience utilisateur acceptable. Ensuite il y a deux modèles qui s'ajoutent à ce tableau. Le premier, plus répandu et employé par Fedora, Debian, Ubuntu ou Mageia est de proposer à une fréquence fixe une nouvelle version de leur système. Et très souvent, pour une version donnée de ces systèmes, les logiciels fournis sont comme figés. Les mises à jour concernent surtout les problèmes de sécurité ou la correction de bogues, plus rarement des versions qui apportent de nouvelles fonctionnalités. Pour obtenir des logiciels plus récents, il faut donc changer de version du système via une mise à niveau. Le second modèle, porté par ArchLinux et Gentoo par exemple, ne propose pas réellement de versions de leur système. Les logiciels sont continuellement mis à jour vers la dernière version.

Ce modèle a rarement été remis en cause. Il apporte en effet des avantages certains. Installer un paquet depuis les dépôts officiels est très simple et efficient pour l'utilisateur. La mise à jour est centralisée ce qui limite le temps de maintenance nécessaire à cette activité. Et au niveau de la sécurité et de l'économie de ressources cela est également le bienvenu car les logiciels peuvent partager des ressources en commun sans difficulté et il est inutile de maintenir plusieurs fois la même bibliothèque commune par exemple.

Mais ce modèle a également un revers pour l'utilisateur et la mise au point des distributions. Tout d'abord l'utilisateur est comme piégé par sa distribution. Il est très difficile d'installer en parallèle deux applications identiques de versions différentes. Et si on souhaite une version différente d'un logiciel que celle proposée par sa distribution, comme la dernière version de GNOME, ou la version précédente de Python, la distribution ne fournit rien pour répondre à ce besoin. L'utilisateur doit se débrouiller pour cette tâche ce qui est particulièrement peu flexible. Et au niveau de la fiabilité ou de la maintenance, cela est également plutôt complexe si on cherche à atteindre une certaine qualité. Les applications dans ce modèle ont accès à tout dans le système, et les opérations d'installation ou de mise à jour peuvent corrompre le système si une coupure de courant intervient au mauvais moment par exemple. Enfin, mettre à jour ou installer un paquet n'est pas anodin, il y a souvent exécution de scripts pour convertir des fichiers de configuration pour être compatible avec la nouvelle version, ou pour rendre ce dernier exploitable comme créer un utilisateur qui va exécuter le service nouvellement installé. Sauf que, chaque installation de Fedora est différente, les utilisateurs n'installent pas les mêmes logiciels et ne les utilisent pas de la même manière. Il faut donc que le mainteneur anticipe de nombreux problèmes potentiels liés à ces contextes très différents pour s'assurer que son paquet sera exploitable pour tous sans accrocs.

Or ces défauts sont très problématiques. En particulier à un moment où les logiciels disponibles pour Linux se multiplient et se développent un peu partout en étant pas fournis via la distribution mais par Github par exemple. D'autant plus que l'utilisateur est habitué des systèmes d'exploitation macOS et Windows où installer une nouvelle application est assez indépendante de la version du système qui l'exécute. En plus d'être capable d'installer plusieurs versions en simultané s'il le souhaite. Et force est de constater qu'aucun système Linux populaire, en dehors d'Android, n'a réellement mis les moyens de changer ce modèle en profondeur.

Enfin, récemment il y a eu l'émergence d'autres systèmes de gestionnaires de paquets qui forment des écosystèmes indépendants des distributions. On peut évoquer en premier lieu les langages de programmation qui proposent des modules facilement téléchargeables pour les développeurs comme Python avec pip, Ruby avec gem, Go, Rust ou PHP. De plus, certaines applications ont leur propre écosystème d'extensions comme Firefox ou GNOME Shell et les paquets peuvent être redondants avec cette infrastructure.

L'architecture envisagée

Pour résoudre ce problème, en découplant la base du système des applications, Fedora.next a exploré l'idée de transformer Fedora en un système avec trois couches de logiciels.

La première couche est une base qui se veut très minimale et comporte à peine ce qui est nécessaire pour avoir un système fonctionnel. Cela concerne la gestion du matériel via le chargeur de démarrage et du noyau, les bibliothèques essentielles comme la bibliothèque C, de quoi gérer des paquets et de démarrer des services comme systemd. Guère plus.

La seconde couche concerne plutôt les piles technologiques qui sont également assez essentielles au fonctionnement du système et de la plupart des applications. C'est là qu'on retrouvera la plupart des bibliothèques très importantes, mais surtout les langages de programmation et leur écosystème comme Python, Ruby, PHP, Perl, etc.

Enfin, la dernière contient les applications elles-mêmes avec éventuellement une séparation entre les environnements de bureaux comme GNOME, KDE / Plasma ou Xfce des autres applications.

Fedora.next_architecture.jpg

La mise en œuvre

Le projet Fedora développa plusieurs solutions dans ce cadre. La première est la création immédiate des produits, à savoir Fedora Workstation, Server et Cloud à l'époque. Le but était de fournir une expérience par défaut qui corresponde au mieux à ces différents cas d'usage, que ce soit par les paquets fournis par défaut, les options ou configurations natives. Mais aussi, cela permettait à Cloud d'expérimenter une architecture plus agressive et différente des deux autres : le projet Atomic que l'on abordera un peu plus loin.

Ensuite, le projet Fedora travailla sur le concept des modules. L'objectif est qu'une version de Fedora puisse installer plus facilement la version d'un composant de la seconde couche (les fameuses piles mentionnées plus haut) fournies par une autre version de Fedora. Cela permet donc d'utiliser par exemple la dernière version de Python même si on ne bénéficie pas de la dernière version de Fedora si on le souhaite. Le tout en passant par les dépôts de manière assez classique.

Malheureusement l'architecture envisagée permet difficilement l'installation simultanée de deux piles complètes en parallèle. À part le cas Python 2 et Python 3 qui a demandé un investissement important sur la durée pour l'autoriser, les dépôts traditionnels et les modules n'offrent que la possibilité d'installer une version de référence différente de celle proposée par défaut.

Flavor-workstation-background.png

Le projet Atomic

Genèse

En 2014, le projet Atomic est lancé. Son but est d'essayer de simplifier l'usage des systèmes RHEL, CentOS ou Fedora au sein des conteneurs tels que Docker. Donc nous sommes plutôt dans un contexte cloud où les images sont minimales et gèrent peu de services à la fois. Pour monter en charge, il suffirait d'en instancier plus ce qui est intéressant si le système est fiable et minimal.

Cela passe par une refonte de la manière de concevoir ces systèmes. Jusqu'ici toute distribution Linux peut être résumée par l'architecture tout est paquets. Chaque logiciel ou composant est fourni à travers un paquet. La cohérence et le fonctionnement de l'ensemble repose donc sur le gestionnaire de paquets et les liens de dépendances définis au sein de chacun.

Atomic repousse ce modèle traditionnel, du point de vue utilisateur du moins, avec le composant rpm-ostree et le système qui est considéré comme un tout unifié avec la possibilité de réaliser des mises à jour atomiques. Il faut voir rpm-ostree comme un gestionnaire de versions (un outil similaire à git par exemple) pour des binaires. Ce système de fichiers de base du système sera versionné comme un code sous git. Chaque mise à jour de ce dernier sera vu comme un commit.

En cela il s'inspire du projet NixOS pour refaire les fondations d'une distribution. Mais NixOS a une approche différente, tandis que Atomic privilégie l'approche commit / déploiement, NixOS repose sur des sommes de contrôles et des chemins dans la définition des paquets. L'inconvénient est qu'une modification dans une dépendance majeure du système, comme glibc, implique de régénérer l'ensemble des paquets qui en dépendent alors que la compatibilité n'a pas été changée au niveau de l'ABI. L'approche d'Atomic permet d'éviter cet écueil. Atomic peut également être utilisé par n'importe quel outil capable de générer un système de fichiers alors que NixOS requiert des outils et un langage spécifique.

Différences avec une distribution traditionnelle

La conséquence évidente c'est que la notion de paquets disparaît pour l'utilisateur, le système de base est un tout indivisible et chaque composant est lié aux autres. Une mise à jour d'un élément dans ce système de base entraîne une mise à jour de l'ensemble. Heureusement grâce aux delta entre chaque version seulement ce qui a différé est réellement téléchargé et appliqué en cas de mise à jour. Sur une distribution plus classique, chaque paquet est mis à jour de manière indépendante les uns des autres. Cela est fait à travers la commande rpm-ostree upgrade qui regarde dans le dépôt où est versionné l'image pour récupérer la dernière version publiée.

Un avantage immédiat est que l'ensemble est standardisé. Chaque poste qui disposera de la version X de l'image Atomic considérée sera identique aux autres du point de vue du système de base. Avec la méthode plus traditionnelle de faire, pour différentes raisons, cela n'est pas forcément le cas. Certains ne mettent pas tous les paquets à jour ou à la même fréquence. Les mises à jour n'ont pas lieu forcément dans le même ordre ou certains peuvent sauter des transitions intermédiaires dans le processus. Ce nouveau procédé améliore la reproductibilité et aussi la fiabilité car les tests d'assurance qualité reproduisent de fait le comportement de toutes les images en production.

L'autre intérêt est également le versionnage même du système. Si la mise à jour pose problème, revenir en arrière est simple et immédiat car il suffit de sélectionner la révision antérieure dans l'outil de gestion (comme la commande rpm-ostree rollback voire le chargeur de démarrage lui même). Avec un système de paquets c'est souvent une étape bien plus complexe à réaliser et coûteuse à base de clichés du système. Et en cas de coupure de courant au mauvais moment, le système Atomic sera toujours opérant comme avant alors que l'état d'un système plus traditionnel sera plus aléatoire voire non fonctionnel.

Changer par ailleurs de version est relativement immédiat et complet. Le démarrage sélectionne la version désirée, la déploie et l'ensemble des paquets sont à jour ensemble. Cela évite les possibilités d'incohérence que l'on peut avoir habituellement, si on redémarre une application en cours de mise à jour par exemple alors que potentiellement d'autres composants ne le sont pas encore.

Enfin, cela permet d'envisager d'aller plus loin. Comme le système de base est réalisé en bloc, il est possible de rendre ce système de base en lecture seule. Cela signifie isoler les dossiers qui ne peuvent être changés que par rpm-ostree lors d'une mise à jour. Ces dossiers là seront en lecture seule pour limiter la possibilité d'écriture qu'à certains dossiers précis pour la configuration, les données ou ajouter des logiciels supplémentaires. Ainsi cette partie là du système est plus robuste car moins sensible aux accidents ou aux actes malveillants.

De manière plus concrète, les dossiers /etc et /var sont les seuls dossiers accessibles en lecture et écriture. Ils sont préservés en cas de mise à jour. En cas de modification de la configuration d'un logiciel dans /etc, ostree applique le 3-way merge pour fusionner vos modifications avec ceux fournis par la mise à jour. /var peut être utilisé pour reproduire une hiérarchie FHS traditionnelle si nécessaire exploitable via chroot ou similaire.

Personnaliser le système

Se pose la question de la personnalisation du système. Comment faire dans ce cas pour ajouter un nouveau service dans une image ?

La première solution est de générer cette image personnalisée soi même. rpm-ostree n'a pas de notion de paquets mais on peut générer une image OSTree avec des paquets, donc à partir d'une image classique de Fedora par exemple.

Ensuite, c'est d'installer un nouveau composant sous forme d'une surcouche au système de base. Par exemple exécuter la commande rpm-ostree install toolbox va récupérer l'image produit par le paquet toolbox et le déployer par dessus celui du système de base. Il suffit de générer le système de fichiers voulu avec les logiciels souhaités avant de déployer l'ensemble et de maintenir les mises à jour soi même.

Sinon la philosophie de cette architecture est de recourir à des conteneurs pour isoler au mieux les applications personnelles et faciliter la maintenance et le déploiement.

Mise en œuvre dans Fedora

Dès 2014, Fedora va travailler pour proposer une image de sa version cloud minimale reposant sur le projet Atomic. Très rapidement cette implémentation va devenir celle par défaut car elle correspond bien au but même de produit.

Fedora Silverblue

Naissance du projet

Devant les promesses du projet Atomic, les réflexions de Fedora.next et la transition réussie pour Fedora Cloud, l'idée émerge de réaliser Fedora Workstation avec le projet Atomic en marge du projet Fedora dans un premier temps. En revenant dans le giron de Fedora, l'équipe a décidé de renommer le projet en Fedora Silverblue en 2018 pour donner plus de visibilité à ce projet de long terme tout en le distinguant de Fedora Atomic qui est associé à Fedora Cloud.

L'objectif est évidemment de fournir les avantages cités lors du traitement du projet Atomic mais pour l'image phare de Fedora. Les avantages étant les mêmes, nous n'allons pas les énumérer à nouveau pour plutôt évoquer les difficultés et le travail qui reste à fournir. Et l'avenir éventuel de ce projet.

Il est évident que la conception du projet Atomic colle parfaitement avec les exigences d'une image minimale telle que Fedora Cloud. Pour Workstation cela est plus complexe. Un utilisateur installe et configure beaucoup de logiciels différents. Cette combinaison est presque unique. Il est impensable d'avoir une image universelle qui contiendrait l'ensemble des logiciels pour chaque utilisateur avec une telle architecture. Et il est assez irréaliste d'exiger à un utilisateur commun de manipuler un outil tel que Docker pour parvenir à ses fins. Installer de nouveaux outils se fera par deux voies différentes.

Flatpak

La première repose sur Flatpak. Flatpak est un projet pour fournir un système de paquets dit universel dans un système isolé de bac à sable. Flatpak dispose de nombreux atouts dans ce contexte.

Pour commencer, il autorise l'installation de logiciels par des utilisateurs normaux simplement, sans droits super-utilisateur contrairement à un paquet d'une distribution traditionnelle. Car le logiciel s'installe dans le répertoire de cet utilisateur par défaut.

Ensuite, à cause de l'isolation du logiciel et de l'universalité de la solution, il doit embarquer ses propres dépendances. Cela alourdi le paquet et complexifie la maintenance des bibliothèques très communes, mais un paquet Flatpak peut fonctionner sur n'importe quelle distribution et il est possible d'installer plusieurs versions d'un même logiciel en même temps ce qui donne plus de liberté à l'utilisateur.

Un autre aspect intéressant est le concept des portails. Comme les paquets Flatpak sont isolés du système, ils n'ont accès qu'à peu de choses par défaut. Ils ne peuvent lire les données dans vos répertoires personnelles par exemple. Pour que cela soit possible, les Flatpak vont utiliser des portails pour informer l'utilisateur que l'application a besoin de permissions spéciales pour effectuer une action comme prendre une capture globale de l'écran, accéder au réseau, accéder à la webcam, lire un fichier personnel, etc.. L'utilisateur peut librement autoriser ou non cette application à réaliser cette action à la volée. Ce fonctionnement ressemble au mécanisme de permissions des systèmes mobiles comme iOS ou Android. Cette architecture permet d'améliorer la sécurité en minimisant les droits des applications au strict nécessaire, en alertant l'utilisateur et limite les problèmes en cas de bogue de l'application.

Pour atténuer les inconvénients mentionnés précédemment, Flatpak fonctionne aussi avec des dépôts pour centraliser les mises à jour de l'ensemble de ses applications. Il dispose également de contextes d'exécution pour unifier les bibliothèques très communes et éviter que chaque application ne les embarque ou ne les mette à jour eux mêmes. Ces contextes d'exécution pouvant être installés en parallèle, on peut garder une application fonctionnelle même en cas de rupture de compatibilité entre deux versions d'un contexte d'exécution. La mise à jour par delta limite également le besoin en bande passante d'une mise à jour au strict nécessaire.

Cependant Flatpak ne concerne que les applications disposant d'une interface graphique. Or il y a d'autres composants qu'un utilisateur voudrait pouvoir installer sur sa Fedora Silverblue comme des outils de développement.

Fedora toolbox

C'est la deuxième voie pour installer des logiciels supplémentaires dans le système. Fedora toolbox repose sur buildah et podman qui est lui même un clone de Docker pouvant s'exécuter sans droits super-utilisateur.

Ainsi il devient possible d'installer facilement des conteneurs pour un utilisateur donné pour ses développements. On reprend les avantages cités plus haut en terme de sécurité, fiabilité ou encore de possibilité de manipuler des versions différentes d'un même composant. Ce qui est un besoin récurent en développement par ailleurs.

En fait cet utilitaire permet de créer un conteneur basé sur une version de Fedora de votre choix, avec une configuration par défaut pour que le partage avec l'hôte soit simple comme la correspondance des noms utilisateurs et des différents IDs. La base du conteneur peut être partagé entre les instances : deux conteneurs basés sur F31 ne requiert de télécharger qu'une fois cette base.

État du projet et avenir

Fedora Silverblue bénéficie d'un grand investissement et de grands progrès sont réalisés de version en version. Mais le projet est encore trop immature pour envisager de remplacer Fedora Workstation par défaut, car les difficultés à résoudre restent nombreuses.

En effet, le public de Fedora Workstation est très hétérogène et les besoins entre chaque utilisateur sont importants. Il faut s'assurer que l'ensemble des cas d'usages soient couverts malgré leur diversité. Et cela sans que le dit système soit plus complexe.

Pour l'instant l'intégration rpm-ostree, Flatpak et toolbox fonctionne plutôt bien. Pour des usages très simples et peu exotiques c'est un système qui peut être utilisable. Mais les usages plus complexes ou exotiques sont encore mal gérés.

Quelques exemples de problèmes à résoudre actuellement :

  • Le fonctionnement des environnements de développement dans un tel contexte ;
  • L'installation et l'usage de codecs multimédia additionnels ;
  • Certaines applications qui dépendant de pilotes spécifiques comme VirtualBox ;
  • Les extensions systèmes.

Mais ceci n'est qu'un aperçu des problèmes, il y en a bien d'autres dans le détail. Et même s'il y a une volonté de tous les résoudre, personne n'a la réponse de si Fedora Silverblue pourra réellement remplacer Fedora Workstation à terme. Du moins avec le respect complet de son architecture tel qu'il a été envisagé. Sans oublier les adeptes des distributions traditionnelles pour les avantages que cela leur procure.

L'équipe de Fedora Silverblue propose des versions majeures synchronisées avec le reste du projet. Donc si cela vous intéresse de tester la bête en vrai, n'hésitez pas !

Fedora 32 se déconfine

Charles-Antoine Couret

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

Cette version apporte beaucoup de changements concernant l'expérience utilisateur et l'abandon de Python 2.

GNOME Bureau.png

Expérience utilisateur

Passage à GNOME 3.36. Cette version apporte de nombreuses petites améliorations dont voici un extrait :

  • refonte de l'interface de connexion (GDM) et du verrouillage de l'écran ;
  • GNOME affiche un bouton pour afficher le mot de passe du champ de saisie si nécessaire pour le vérifier ;
  • les boutons du menu de GNOME Shell ont été remaniés pour laisser apparaître la mise en veille sans utiliser une touche du clavier au préalable comme avant ;
  • une nouvelle application GNOME Extensions pour les configurer et les gérer plutôt que via votre navigateur web ;
  • un nouveau bouton Ne pas déranger est disponible dans la zone de notifications pour les désactiver temporairement pour l'utilisateur ;
  • le centre de configuration a été réarrangé rendant la navigation plus simple quand la section Vie privée liste désormais les applications qui ont obtenu des autorisations pour accéder aux services de localisation, à la caméra et au micro. Laccès peut être révoqué individuellement pour chaque application ;
  • GNOME Logiciels détecte les connexions limitées (via le téléphone ou une puce 4G interne par exemple) pour désactiver le téléchargement automatique des mises à jour dans ce cas ;
  • un système de contrôle parental fait son apparition pour autoriser ou non l'accès à des applications ;
  • le navigateur web peut afficher les fichiers PDF directement ;
  • les utilisateurs de pilotes propriétaires NVIDIA peuvent désormais lancer les applications en utilisant la carte graphique dédiée depuis GNOME Shell, avec le menu consacré.

GNOME écran de verrouillage.png

Une nouvelle image alternative Comp Neuro Lab est disponible pour proposer par défaut des paquets relatifs aux neuro-sciences et qui est prête à l'emploi. Une documentation officielle est par ailleurs fournie pour voir les paquets proposés nativement comme octave, numpy ou encore neurord.

Plusieurs polices bitmaps sont converties en OpenType pour être exploitables par des applications plus modernes qui reposent sur la nouvelle version de la bibliothèque pango. En effet ce dernier depuis Fedora 31 utilise la bibliothèque HarfBuzz au lieu de FreeType pour effectuer le rendu des caractères et qui oblige de fait l'usage de polices vectorielles. Cette conversion a reposé principalement sur l'usage de l'outil fonttosfnt. Cela augmente de fait la diversité des polices prises en charge.

Gestion du matériel

Le service fstrim.timer est activé par défaut. Il est exécuté de façon hebdomadaire pour signaler la liste des secteurs effacés au contrôleur de mémoires flash compatibles pour améliorer leur gestion d'un point de vue performance. Par défaut il est exécuté chaque lundi à minuit, ou au prochain redémarrage ou sorti de veille survenant après cette date si la machine était inactive.

GNOME GDM.png

Cela pourrait sur quelques rares matériels quelques problèmes de performances durant l'opération (soit quelques secondes). Cela est également actif depuis quelques années chez Ubuntu ou OpenSUSE ce qui a conforté le projet Fedora dans la fiabilité d'un tel changement.

GNOME ne pas déranger.png

Administration système

Le paquet earlyoom est installé par défaut. En cas de mémoire insuffisante (RAM et swap utilisés à plus de 90%), un signal SIGTERM sera envoyé au processus ayant le plus gros score OOM. À plus de 95% d'utilisation, c'est le signal SIGKILL qui est envoyé.

Le but est d'essayer de sauver la machine en cas de problèmes de disponibilité de mémoire et quand la partition d'échange est très sollicitée. Une situation où un redémarrage brutal matériel était souvent nécessaire jusqu'ici même sur les machines puissantes disposant d'un SSD.

Contrairement à l'OOM du noyau (qui s'active plus tard), le signal SIGTERM est envoyé pour donner une chance au processus de se terminer proprement.

Pour revenir à la situation précédente vous pouvez exécutez la commande

# systemctl disable earlyoom.service 

Ou configurer earlyoom pour correspondre à vos besoins.

GNOME Extensions.png

Développement

Python 2 est retiré. Plus exactement, le paquet python2 est remplacé par celui de python27 pour des raisons de compatibilité. Les paquets qui dépendent de cette version de Python de même que les bibliothèques Python 2 sauf quelques exceptions sont quant à eux supprimés des dépôts. Cela met fin à la transition de Python 2 vers Python 3, ce premier n'étant plus maintenu officiellement depuis janvier 2020.

Projet Fedora

Le projet améliore la façon d'avoir des statistiques sur l'utilisation de Fedora. L'objectif est de connaître plus finement le nombre de machines employant Fedora, mais aussi avoir des informations sur la version utilisée, sa variante (comme le Spins), etc. Ce qui permet à l'équipe qualité mais aussi au projet dans son ensemble de baser leurs décisions sur des données factuelles.

Actuellement le tout reposait sur la collecte de données des différents miroirs pour connaître le nombre d'installation en vigueur ce qui n'était pas fiable, à cause du fait que derrière une adresse IP peut se cacher plusieurs installations. Et cette méthode était plutôt lente pour remonter les informations.

Et il fallait trouver un moyen qui garantisse un respect de la vie privée maximale. Et bien évidemment, il faut que le mécanisme fonctionne si l'utilisateur utilise dnf, GNOME Logiciels ou Cockpit par exemple pour gérer ses paquets.

Pour éviter cela, tous les 7 jours lors d'une requête vers un dépôt, libdnf va envoyer la chaîne libdnf/VERSION (NAME VERSION_ID; OS.BASEARCH) comme user agent et incrémenter un compteur interne qui est aussi envoyé. Cela permettra d'obtenir les informations suffisantes à savoir la version de Fedora, la variante utilisée, l'architecture mais aussi la durée de vie d'une Fedora (une semaine, un mois, deux ans ?). L'user agent peut être changé via l'option user_agent dans le fichier de configuration de dnf. Cette fonctionnalité est également désactivable avec l'aide de l'option countme dans ce même fichier qui est configuré à False. Cette option étant activée par défaut.

Pour éviter le risque de traquer une machine en particulier, le compteur n'est plus incrémenté au bout de 60 semaines soit la durée de support approximative d'une Fedora.

Cette nouveauté a été proposée pour Fedora 30 mais a été finalement reportée.

La communauté francophone

L'association

Logo.png

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 hebdomadaires chaque lundi soir à 20h30 (heure de Paris) sur IRC (canal #fedora-meeting-1 sur Freenode).

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, José Fournier et les autres contributeurs et relecteurs pour leurs contributions.

L'équipe se réunit tous les lundis soir après 21h (heure de Paris) sur IRC (canal #fedora-doc-fr sur Freenode) pour faire progresser la documentation par un travail collaboratif. Le reste de la semaine cela se passe sur les listes de diffusion.

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 32 ?

Mediawriter.png

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

Fedora 32 beta sort de confinement

Charles-Antoine Couret

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

Malgré les risques concernant la stabilité dune 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 32 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 21 ou 28 avril. Voici les nouveautés annoncées pour cette version :

Expérience utilisateur

  • Passage à GNOME 3.36.
  • Une nouvelle image alternative Comp Neuro Lab est disponible pour proposer par défaut des paquets relatifs aux neuro-sciences.
  • Plusieurs polices bitmaps sont converties en OpenType pour être exploitables par des applications plus modernes qui reposent sur la bibliothèque pango.

Gestion du matériel

  • Le service fstrim.timer est activé par défaut. Il sera exécuté de façon hebdomadaire pour signaler la liste des secteurs effacés au contrôleur de mémoires flash pour améliorer leur gestion d'un point de vue performance.

Internationalisation

  • Migration de la plateforme de traduction de Zanata vers Weblate pour le projet Fedora. Le premier n'était plus vraiment maintenu et souffrait de sérieux défauts.

Administration système

  • Le paquet earlyoom est activé par défaut. En cas de mémoire insuffisante (RAM et swap utilisés à plus de 90%), un signal SIGTERM sera envoyé au processus ayant le plus gros score OOM. À plus de 95% d'utilisation, c'est le signal SIGKILL qui est envoyé. Le but est d'essayer de sauver la machine en cas de problèmes de disponibilité de mémoire, situation où un redémarrage brutal matériel était souvent nécessaire.
  • Le gestionnaire de base de données MariaDB est mis à jour vers la version 10.4.
  • Son alter-ego PostgreSQL passe quant à lui à la version 12.
  • Le redémarrage des services après une mise à niveau est centralisé. Cela réduira le nombre de scriptlets à maintenir à cet effet dans les paquets, mais surtout évite de redémarrer un service alors qu'une dépendance n'a pas fini sa mise à niveau en cours ce qui peut être source de bogues.
  • Le pare-feu dynamique firewalld migre de iptables vers nftables.
  • Par ailleurs la variante iptables par défaut devient iptables-nft.
  • Le paquet apt va fournir le projet de Debian plutôt que apt-rpm.
  • L'outil de sauvegarde rdiff-backup a été mis à jour vers sa dernière version 1.2.8 qui repose sur Python 3 et est incompatible avec celle qui reposait sur Python 2.
  • Les utilisateurs systèmes adoptent le format sysusers.d ce qui permet d'unifier les procédures, de facilement observer quels paquets créent un nouveau utilisateur et se rapprocher d'OpenSUSE dans l'approche de cette problématique.

Développement

  • La suite de compilateurs GCC 10 est proposée.
  • Son concurrent direct LLVM vient également dans sa version 10.
  • La bibliothèque C GNU C Library progresse à la version 2.31.
  • Mise à jour de Binutils 2.33.
  • Le paquet clang-libs ne proposera plus que la bibliothèque partagée libclang-cpp.so, les 37 autres fichiers ayant fusionné avec ce dernier.
  • La bibliothèque de calcul multi-précision flottant mpfr a une précision de 4.0.2.
  • Le compilateur Pascal libre, Free Pascal Compiler, passe à la version 3.2.0.
  • Le langage Python rampe vers la version 3.8.
  • Tandis que Python 2 est retiré. Plus exactement, le paquet python2 est remplacé par celui de python27 pour des raisons de compatibilité. Les paquets qui dépendent de cette version de Python de même que les bibliothèques Python 2 sont quant à eux supprimés des dépôts. Cela met fin à la transition de Python 2 vers Python 3, ce premier n'étant plus maintenu officiellement depuis janvier 2020.
  • Le paquet python-nose est déprécié en vue d'une suppression future.
  • La boîte à outils Django 3 est disponible.
  • Ruby brille de 2.7 feux.
  • Le générateur de pages statiques Jekyll version 4 est exposé dans les dépôts.
  • Le gem Ruby Bundler passe quant à lui la 2e.
  • Le langage Go quant à lui file vers la version 1.14.
  • Haskell Stackage LTS va vers la version 14.
  • La pile .Net libre Mono évolue de la version 5.20 à 6.6.
  • PHP écrase avec sa version 7.4.
  • Le gestionnaire de versions Bazaar laisse place à son fork Breezy, qui est mieux maintenu.
  • La chaîne de compilation mingw32 change de systèmes d'exception de SJLJ vers dwarf-2.
  • Python est compilé avec le drapeau -fno-semantic-interposition pour améliorer ses performances.

Projet Fedora

  • Le projet améliore la façon d'avoir des statistiques sur l'utilisation de Fedora. Actuellement le tout reposait sur la collecte de données via les miroirs pour connaître le nombre d'installation en vigueur ce qui n'était pas fiable. Pour éviter cela, chaque requête tous les 7 jours vers un dépôt officiel sera enregistrée par machine. Cela évitera les problèmes liés à la vie privée. Cette nouveauté était proposée pour Fedora 30 mais a été finalement reportée.
  • Un bogue sur les images Live sur CD ne sera plus bloquant. En cas de bogues spécifiques à ces images une nouvelle version de Fedora sera proposée malgré tout. Le correctif nécessaire pourra avoir lieu après la disponibilité officielle. Cela permet de réduire la charge des tests pour finalement assez peu d'utilisateurs.
  • De manière similaire, l'image Xfce 32 bits ne sera plus bloquant alors que l'image Workstation pour AArch64 le sera.
  • Un nouveau buildroot pour le projet Fedora voit le jour pour proposer de tester un changement dans la micro-architecture x86_64. Ceci afin d'évaluer les possibilités d'améliorer les performances et de voir les éventuelles régressions en vue d'une mise à jour globale des exigences de l'image x86_64.
  • Le lien entre une langue couverte et une police d'écriture n'est plus dans le paquet de la police mais dans un paquet langpack spécifique nommé langpacks-core-font-<code langue>.
  • Juste après la séparation entre Rawhide et une nouvelle version de Fedora, ici 32, une période de gel des paquets sera observée comme avant une Beta ou une sortie finale pour améliorer la stabilisation.
  • L'ensemble des paquets qui gère des unités utilisateur pour systemd doivent recourir aux preset et non gérer cela à la main pour simplifier la maintenance et la cohérence. Cela reprend le même mécanisme proposé pour les services introduit dans Fedora 18.
  • Les paquets de base, qui sont notamment utilisés pour produire les images minimales pour conteneurs, réduisent leur nombre de scriptlets pour unifier les procédures et améliorer leur gestion.

Tester

Durant le développement d'une nouvelle Fedora, comme cette version Beta, quasiment chaque semaine le projet propose des journées de tests. Le but est pendant une journée de tester une fonctionnalité précise comme le noyau, Fedora Silverblue, la mise à niveau, GNOME, linternationalisation, etc. L'équipe 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 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 31 ou 30 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.

Bons tests à tous !

AMC version 1.4.0 Fedora 31

Patrice Kadionik

Les RPM d'AMC (Auto Multiple Choice) version 1.4.0 pour Fedora 31 sont disponibles dans le dépôt eddy33. Fedora 31 ne supportant plus l'architecture x86 32 bits, seule la version AMC 64 bits sera disponible.


Installation :

$ sudo dnf install perl-Gtk3 perl-Clone
$ sudo dnf install http://kadionik.vvv.enseirb-matmeca.fr/fedora/eddy33-release-31.rpm
$ sudo dnf install auto-multiple-choice
++

Fedora 31 vs Fedora 30 : comparaison des performances pour les versions 64 bits

Patrice Kadionik

Salut.

Voici les résultats comparatifs de Fedora 31 vs Fedora 30.

Pour rappel, ma machine est équipée d'un Quad Core Intel Q6600 à 2,4 GHz avec 4 Go de RAM.

Je me suis limité au benchmark UnixBench qui fournit un indice global, ce qui me simplifiera la comparaison. La version UnixBench utilisée est la version 4.1.0.

Mon protocole de tests est le suivant :
  • Installation de Fedora 31 version 64 bits avec le noyau Fedora  5.3.7-301.fc31.x86_64.
  • La machine est placée en niveau 3 (init 3).
  • 10 séries de tests avec UnixBench compilé sous Fedora 31 et exécuté sous Fedora 31 (5.3.7-301.fc31.x86_64).
  • 10 séries de tests avec UnixBench compilé sous Fedora 30 et exécuté sous Fedora 30 (5.0.9-301.fc30.x86_64).
Voici les résultats obtenus :

Fedora 31 version 64 bits :

Série 1 : 673.4
Série 2 : 680.6
Série 3 : 683.4
Série 4 : 688.7
Série 5 : 688.8
Série 6 : 709.1
Série 7 : 725.5
Série 8 : 686.1
Série 9 : 701.7
Série 10 : 718.8

Moyenne : 695.6

Fedora 30 version 64 bits :

Voici pour rappel les résultats obtenus avec Fedora 30 :
Série 1 : 603.2
Série 2 : 612.5
Série 3 : 620.0
Série 4 : 620.0
Série 5 : 605.6
Série 6 : 605.2
Série 7 : 605.4
Série 8 : 611.3
Série 9 : 614.1
Série 10 : 609.5

Moyenne : 610,7

Résultats :

Pour Fedora 31, on obtient un indice moyen de 695.6 pour UnixBench.
Pour Fedora 30, j'avais obtenu un indice moyen de 610,7 pour UnixBench.


On a donc une hausse significative de 13,9 % de Fedora 31 64 bits par rapport à Fedora 30 64 bits :

perfs_fedora_F31.png

Conclusion :

Au moment de ces tests, le noyau Fedora 31 (basé sur le noyau vanilla 5.3.7) est nettement plus performant de près de 14% que le noyau Fedora 30 (basé sur le noyau vanilla 5.0.9).

++

Résultats des élections de Fedora 12/19

Charles-Antoine Couret

Comme je vous le rapportais il y a peu, Fedora a organisé des élections pour renouveler partiellement le collège de ses organes FESCo, Mindshare et Council.

Le scrutin est comme toujours un vote par valeurs. Nous pouvons attribuer à chaque candidat un certain nombre de points, dont la valeur maximale est celui du nombre de candidat, et le minimum 0. Cela permet de montrer l'approbation à un candidat et la désapprobation d'un autre sans ambiguïté. Rien n'empêchant de voter pour deux candidats avec la même valeur.

Les résultats pour le Conseil sont :

# votes |  noms
520     Dennis Gilmore
--------------------------------------------
259     Alberto Rodríguez Sánchez
237     John M. Harris, Jr.

À titre indicatif le score maximal possible était de 243 * 3 votes soit 729.

Les résultats pour le FESCo sont (seuls les cinq premiers sont élus) :

# votes |  noms
1490 Miro Hrončok
1350 Kevin Fenzi
1115 Zbigniew Jędrzejewski-Szmek
879     Fabio Valentini
877     David Cantrell
--------------------------------------------
868     Justin Forbes
813     Randy Barlow
534     Pete Walter

À titre indicatif le score maximal possible était de 273 * 8 soit 2184.

Les résultats pour le Mindshare sont donc :

# votes |  noms
134     Héctor Louzao

À titre indicatif le score maximal possible était de 172 * 1 soit 172.

Nous pouvons noter que globalement le nombre de votants pour chaque scrutin avec un réel enjeu était proche aux alentours de 275-250 votants ce qui est un peu plus que la fois précédente (150-200 en moyenne). Les scores sont aussi plutôt éparpillés.

Bravo aux participants et aux élus et le meilleur pour le projet Fedora.

Fin de vie de Fedora 29

Charles-Antoine Couret

C'est en ce mardi 26 novembre 2019 que Fedora 29 a été déclaré comme en fin de vie.

Qu'est-ce que c'est ?

Un mois après la sortie d'une version de Fedora n, ici Fedora 31, la version n-2 (donc Fedora 29) est déclarée comme en fin de vie.

Ce mois sert à donner du temps aux utilisateurs pour faire la mise à niveau. Ce qui fait qu'en moyenne une version est officiellement maintenue pendant 13 mois.

En effet, la fin de vie d'une version signifie qu'elle n'aura plus de mises à jour et plus aucun bogue ne sera corrigé. Pour des questions de sécurité, avec des failles non corrigées, il est vivement conseillé aux utilisateurs de Fedora 29 et antérieurs d'effectuer la mise à niveau vers Fedora 31 ou 30.

Que faire ?

Si vous êtes concernés, il est nécessaire de faire la mise à niveau de vos systèmes. Vous pouvez télécharger des images CD ou USB plus récentes.

Il est également possible de faire la mise à niveau sans réinstaller via DNF ou GNOME Logiciels.

GNOME Logiciels a également dû vous prévenir par une pop-up de la disponibilité de Fedora 30 ou 31. N'hésitez pas à lancer la mise à niveau par ce biais.