« J'étais tranquille j'étais peinard / je réparais ma mobylette » / la nouvelle a surgi le soir / un truc pas vraiment super-chouette… » Eh oui, le couperet est tombé, les utilisateurs de l'agrégateur de flux Web Netvibes.com ont reçu le 15 avril un courriel de Dassault Systèmes leur annonçant que leur agrégateur préféré aller se désagréger définitivement dans l'atmosphère le 2 juin 2025 à midi, avec toutes leurs données, tel un Starship numérique. Si l'on en croit le début du message, cela est lié au développement d'un nouveau service de l'entreprise nommé 3D UNIV+RSES, avec plein d'IA et tout et tout. Le courriel d'avertissement indique certes comment sauvegarder ses données, mais « et maintenant, Papa / C'est quand qu'on va où ? »

Sommaire

• Good vibrations 2.0 ou le cubisme informationnel
• J'ai rencard avec Pétrolette
  • Procédure migratoire
  • Synchronisation ?
  • Nouveaux développements
• Retour d'expérience
  • Points négatifs
  • Points positifs
• Prêts pour l’équipée sauvage ?

Good vibrations 2.0 ou le cubisme informationnel

Netvibes.com, lancé par une start-up en 2005 et racheté par Dassault Systèmes en 2012, était un lecteur en ligne permettant d'afficher les flux RSS ou Atom dans des petits cadres qu'on pouvait regrouper dans des onglets thématiques. Chaque cadre était configurable (longueur, affichage d'images ou non…) et déplaçable facilement. Les flux se mettaient automatiquement et régulièrement à jour. On pouvait aussi ajouter de petites applications (listes de choses à faire, accès courriels, accès à différents réseaux sociaux, etc.). Wikipedia décrit Netvibes.com comme « un portail Web personnalisable. Représentatif de ce qu'on appelle le Web 2.0 ». En tout cas, c'était un très bon outil de veille que j'utilisais tous les jours depuis belle lurette.

Lancé en 1990, donc à peu près en même temps que le World Wide Web, le Courrier international nous permettait d'avoir accès à une pluralité de points de vue issus des journaux du monde entier. Un agrégateur de flux, c'est un peu l'équivalent informatique. Il permet un véritable cubisme informationnel. Avoir un onglet News agrégeant des flux de journaux d'horizons politiques différents et de plusieurs pays, c'est échapper à la bulle informationnelle, à la ségrégation sociale créée par les grands réseaux sociaux commerciaux. Car observer depuis le point de vue d'autrui est un bon exercice, même si ça peut parfois être désagréable comme du poil à gratter. Enfin, avec un agrégateur, l'algorithme c'est vous : votre œil survole l'ensemble des titres et capte au vol ce qui l'intéresse ou le surprend.

J'ai rencard avec Pétrolette

L'outil libre qui se rapproche le plus de Netvibes.com est Pétrolette, « la page d'actus qui ne sait rien de toi », développée par YPhil en JavaScript. Comme son nom l'indique, Pétrolette n'est pas un gros SUV qui fait tout, même le café, mais une application libre qui essaie de faire au mieux une seule chose : afficher des flux Web dans des cadres classés dans des onglets. Donc disons le tout de suite, il faut oublier les éventuelles autres applications que vous utilisiez dans Netvibes. D'après son CHANGELOG, Pétrolette est en version 1.7 depuis l'été 2023. Le GitLab de Pétrolette est indiqué comme étant un miroir de son Framagit mais est en fait plus à jour, la dernière activité remontant à Noël 2024. C'est là que le développement se passe.

D'après le compte Mastodon de Pétrolette, suite à des problèmes d'hébergement, l'instance principale est depuis décembre 2024 https://petrolette.onrender.com/ bien que celle-ci soit considérée comme temporaire. Les plus admin pourront bien sûr héberger leur propre instance, soit en local soit sur le Web, par exemple sur https://place.de.ma.mob/ si le domaine n'est pas déjà réservé.

Procédure migratoire

Par défaut, quand on va sur l'instance principale, qui est une instance partagée, on a un certain nombre d'onglets pré-remplis, avec en tout plus de trois cents flux. On peut les personnaliser (ce sera stocké en local), mais ce qui nous intéresse ici, c'est migrer de Netvibes à Pétrolette. Voici la procédure :

• Dans Netvibes.com, sauvegarder ses données en allant dans « Compte > Sauvegarder vos données », choisir le tableau de bord, cliquer sur Exporter (fichier XML).
• Dans Pétrolette, supprimer tous les onglets par défaut (croix rouges), importer le XML avec « Flux > Ouvrir ».
• Tous les onglets et flux sont récupérés. Le titre d'un flux apparaîtra quand on clique sur son icône pour le déployer.
• Déplier et configurer chaque flux (mais on devrait éventuellement aussi pouvoir travailler à partir du .conf pour réduire ce travail fastidieux).

La configuration est stockée localement sur l'ordinateur et non pas en ligne (on n'a donc pas de compte Pétrolette, donc elle « ne sait rien de toi », elle ne sait pas ce que tu lis). On peut l'exporter dans un fichier .conf au format JSON et l'importer sur un autre PC pour avoir la même configuration.

Synchronisation ?

Mais une telle synchronisation manuelle n'est pas idéale et l'application peut utiliser le protocole remoteStorage pour pouvoir partager la même configuration sur plusieurs PC, et en particulier vers l'application 5apps. D'après l'aide, l'instance principale de Pétrolette ne gère que 5Apps (mais le menu affiche également des icônes pour Dropbox et Google Drive, qu'on devrait donc pouvoir utiliser si on héberge sa propre instance).

On peut s'enregistrer sur 5apps à partir d'un compte GitHub, Bitbucket, GitLab.com ou en se créant un compte (adresse email, identifiant, mot de passe). 5apps vous fournit une « adresse utilisateur » du type login@5apps.com. On peut alors aller dans le menu de Pétrolette, cliquer sur remoteStorage et entrer l'adresse utilisateur pour faire la connexion. Il n'y a plus qu'à autoriser Pétrolette à y accéder et faire de même sur tous vos PC. Pour cela, sur chaque machine, connectez-vous à votre compte 5apps puis dans la liste des « Connected Apps », cliquez sur le lien petrolette.onrender.com, dont l'URL est du type https://5apps.com/rs/oauth/token/123d3215c5484b9a78987e8/launch_app.

Nouveaux développements

Ça c'est la théorie, dans la pratique la synchronisation semble problématique, avec un fonctionnement très capricieux, et après discussion avec l'auteur il pourrait bien s'agir d'un bug où l'application s'emmêlerait les pinceaux entre stockage local et stockage distant. C'est la mauvaise nouvelle. La bonne nouvelle (scoop !) c'est que ça pourrait être résolu dans une future Pétrolette 2 à laquelle réfléchit l'auteur !

Voilà une bonne raison de réfléchir à l'invitation à faire un don au projet Pétrolette dans la fenêtre pop-up qui surgit de temps en temps. Il est en effet possible de faire un don sur Liberapay ou de prendre un abonnement sur Ko-fi : à partir de 1 €/mois le pop-up disparaît. Au-delà, on peut demander à l'auteur de créer un nombre plus ou moins important de flux RSS pour des sites qui n'en proposent normalement pas. Rappelons-nous que dans surveillance://, Tristan Nitot nous avertissait sur notre fâcheuse tendance à aimer la gratuité.

Retour d'expérience

Commençons par les points négatifs, ce qui nous permettra de finir sur le positif !

Points négatifs

• Lenteur pour mettre à jour les flux : quand on affiche sa page Pétrolette, tous les flux sont mis à jour simultanément, c'est-à-dire même dans les onglets qui ne sont pas affichés.
• Pas de mise à jour périodique des flux. On peut certes les mettre à jour individuellement en cliquant sur une icône. Mais malheureusement, recharger la page avec F5 permet certes de mettre à jour tous les flux mais nous remet systématiquement sur le premier onglet. Pétrolette 2 proposera peut-être des fonctionnalités pour faciliter les mises à jour des flux.
• N'affiche pas l'heure de parution des actualités, contrairement à Netvibes. Mais la date et l'heure sont indiquées dans la fenêtre d'aperçu quand on survole un titre.

Points positifs

• Les aperçus du texte qui apparaissent au survol de la souris sont plus longs qu'avec Netvibes, et même parfois très longs, ce qui permet d'avoir un bon aperçu du contenu avant un éventuel clic, voire même de s'en passer.
• La hauteur (en pixels) des cadres peut être réglée plus finement qu'avec Netvibes (où seules trois hauteurs standards étaient disponibles). Cela peut d'ailleurs être utilisé pour augmenter la distance verticale entre deux cadres, ceux-ci étant par défaut collés de façon un peu compacte.
• Les titres longs apparaissent en entier sur plusieurs lignes, alors qu'ils sont coupés dans Netvibes. Cela peut-être un avantage mais parfois aussi un défaut avec certains sites qui proposent des titres à rallonge (du genre trois lignes sur Developpez.com !) que l'oeil a du mal à lire au vol.
• Le menu principal propose de déposer un marque-page dans la barre du navigateur. Il contient un script qui d'un clic ajoutera le site de l'onglet courant dans votre Pétrolette.
• Le champ de recherche permet de chercher un terme dans tous les titres de l'ensemble des onglets. Les zones où il est trouvé apparaissent encadrées en jaune.

Prêts pour l’équipée sauvage ?

« Dès que les vents tourneront nous nous en allerons… » Il le faudra bien, le 2 juin tout s'arrête. Et donc tout recommence. On a maintenant toutes les réponses à la question synthétique et sympathique « c'est quand qu'on va où ? » Quand ? On le sait depuis le début et on l'a répété, c'est le 2 juin ! Où ? On espère y avoir apporter une réponse dans cette dépêche.

Et puis à l'heure où les algorithmes profiteurs des réseaux sociaux commerciaux tendent à enfermer l'utilisateur dans sa bulle informationnelle au seul motif d'optimiser les profits et où les moteurs IA sapent la sérendipité du Web, se balader humblement en mobylette RSS devient une véritable mesure d'hygiène mentale. En plus c'est libre.

Figure 1 - « Quand j’me balade en mobylette / On dirait l’équipée sauvage ». Ouais, ça carbure librement avec « La Pétrolette » (Duncan & Suberbie, 1895 - 1898) [source : Wikimedia, domaine public].

PeaZip n'a jamais été abordé dans ces colonnes jusqu'à présent, alors qu'il fait partie des outils multi-plateformes permettant une transition en douceur vers le libre. Il a presque dix ans. Sortie le 14 avril, la version 10.4 continue la série 10.0 commencée en octobre 2024.

PeaZip affiché avec son thème sombre dans Wayland

Giogio Tani, le développeur de PeaZip publie plusieurs versions chaque année. Le logiciel évolue par petites touches largement testées via les fonctions "expérimentales" des versions précédentes.

Je trouve beaucoup d'atouts à PeaZip

Il est libre, multi-plateformes, multi-architecture, portable (nomade), écrit en FreePascal avec Lazarus, ouvre et écrit plusieurs formats d'archives. Il est rapide et assez léger pour un tout-en-un (11,2 MB). Il est bien maintenu, l'auteur est transparent sur la sécurité, documentation et tutoriels sont conséquents et pédagogiques. L'interface est travaillée, sobre, ergonomique, thémable, configurable, jolie, … N'en jetez plus ! Ah si encore : il est dispo en Gtk et Qt sous X11 et Wayland, et l'auteur l'empaquête à tout va.

C'est un humble logiciel très bien foutu, très travaillé, utile pour installer des outils libres sur les systèmes proprios afin de les amener en douceur vers Linux ou *BSD (il ne fonctionne pas encore sous Haïku).

Architectures et systèmes

• Linux x86_64, x86, ARM, aarch64 ;
• Windows, ReactOS, Wine ;
• Darwin, macOS Intel et aarch64 (Apple Silicon), la famille BSD.

PeaZip propose des fonctions peu courantes

• Le moteur de scriptage intégré permet de convertir vos opérations graphiques pour les automatiser et les étendre avec des options en ligne de commande ;
• un chiffrement solide est disponible, avec authentification à double facteur ;
• l'interface graphique est unifiée sur tous les systèmes et architectures pris en charge, même pour les formats moins courant (zpaq, brotli, zstandard) ;
• le gestionnaire de fichiers avancé facilite, par exemple, la vérification des sommes de contrôles, la déduplication, la conversion de formats d'archives, la recherche, etc ;
• c'est un outil portable et nomade qu'on peut copier sur une clé usb, sur le net ou partager en réseau sans l'installer ;
• PeaZip dispose d'une transparence et des options de suivi pour la vie privée et la sécurité.

Scenari est un ensemble de logiciels open source dédiés à la production collaborative, publication et diffusion de documents multi-support. Vous rédigez une seule fois votre contenu et vous pouvez les générer sous plusieurs formes : site web, PDF, OpenDocument, diaporama, paquet SCORM (Sharable Content Object Reference Model)… Vous ne vous concentrez que sur le contenu et l’outil se charge de créer un rendu professionnel accessible et responsive (qui s’adapte à la taille de l’écran).

À chaque métier/contexte son modèle Scenari :

• Opale pour la formation ;
• Dokiel pour la documentation ;
• Optim pour les présentations génériques ;
• Topaze pour les études de cas ;
• et bien d’autres…

💗 Parole de Scenariste

Scenari a attiré mon attention en 2020, à l'occasion d'une formation chez un un grand compte public qui m'en parle. J'ai découvert le potentiel d'une dissociation entre contenu et forme.
Nous percevons les avantages d’une réutilisation de contenus et la déclinaison de supports avec une mise en forme différence selon le contexte d’animation de nos formations.
Chez way2Sv, nous décidons de migrer l’ensemble du corpus de nos formations dont les supports étaient initialement au format Libre Office. Cette migration s’opère en mode coopératif, grâce à l’usage de MyScenari.

	Eric Fruit, gérant de way2Sv, consultant et formateur sur l’usage du numérique et gestion de la connaissance métier. Modèles utilisés : Opale

📣 Réorganisation des catégories dans le forum

Nous avons réorganisé les catégories dans le forum pour qu'elles soient plus en adéquation avec le site de téléchargements.

Juste après la catégorie « Actualités », tu trouveras désormais les catégories « Modèles et applications bureau » et « Solutions serveur ».

Nous avons créé aussi la catégorie « Usages / métiers » pour discuter non pas de l'utilisation des outil Scenari, mais autour d'un métier ou d'un domaine. En effet, parfois on a besoin d'être guidé vers le ou les bons outils pour une pratique donnée.

📣 Nouvelle page vidéos de présentation outils

Une nouvelle page a vu le jour sur scenari.org : « Présentation d'outils Scenari ».

Tu y retrouveras une présentation de chacun des principaux modèles et outils Scenari sous forme de vidéo courte (moins de trois minutes).

📣 On parlera de Scenari au QPES2025

Sandrine et Nicole, membres du bureau de l'association Scenari, donneront, avec d'autres collègues du Cnam, une conférence intitulée « Accessibilité et pédagogie numérique au Cnam : 10 ans d'expérimentation avec Scenari Opale » le 22 mai à 14h au colloque QPES2025 : Colloque "Questions de Pédagogies dans l'Enseignement Supérieur". 👏

L'article qu'elles ont cosigné présente les vertus de Opale pour créer des contenus accessible et explore les atouts et freins à l'adoption de Scenari, en s'appuyant sur les résultats de l'enquête de notre stagiaire Eric.

✨ Le savais-tu ?

Il existe un atelier communautaire de tutoriels. L'idée est de créer et maintenir ensemble des tutoriels Scenari.

Tu peux :

• consulter ces tutoriel sur la page dédiée sur scenari.org
• récupérer les sources de ces tutoriels ou participer à leur amélioration en :
  1. te connectant à ton compte scenari-community
  2. rejoignant l'équipe des contributeurs (bouton à cliquer)
  3. te connectant à l’atelier de rédaction communautaire de tutos

📊 Le chiffre du mois

	5, C'est le nombre de langues dans lesquelles Opale 24 est officiellement disponible. Et les traductions dans 5 autres langues sont en cours. Si tu peux donner un coup de main pour les traductions, écris à direction@scenari.org.

🦋 Scenari présent dans …

• Access42, qui présentera aux Rencontres 2025, conjointement avec Kelis, une conférence sur l'amélioration de l'accessibilité de la publication web Opale 25, mentionne les Rencontres 2025 sur son site.
• L'école d'ingénieurs CESI recrute un⋅e « Assistant⋅e d'édition numérique bilingue ». Dans la fiche de poste, la connaissance des « chaînes éditoriales (Scenari) » est requise.
• Grace à l'invitation de Adil, Loïc proposera un atelier « création de micro ressources numériques à l’aide de la chaîne éditoriale Scenari » au colloque « Villes apprenantes et qualification linguistique » le 7 mai à Essaouira au Maroc.
• Le bulletin du mois précédent (avril 2025) a été publié sur linuxfr.org.

👋 Nouvelles adhésions d'organisations

Souhaitons la bienvenue à :

• Le Pole développement de l'arbitrage de la commission sportive roller hockey / FFRS qui nous a rejoint dans le collège des Utilisateurs Personne Morale. Outils libres utilisés : Opale , Parcours, Platine-suite.

Comme tous les ans, Qemu sort une nouvelle version majeure. Le numéro n'implique donc pas de grands bouleversements. Il s'agit plutôt d'une base stable qui va être maintenue et améliorée pendant quelques années. Ainsi, les versions 7, 8 et 9 ont eu des mises à jour en mars 2025.

Comme d'habitude, les architectures ARM et Risc-V se taillent la part du lion et sont enrichies de nouvelles architectures. Les accès aux stockages sont partout plus rapides, et l'espace utilisateur accède toujours mieux au matériel.

Qemu est devenu une pièce importante dans le monde des serveurs et des développeurs. En tant qu'émulateur il permet de développer, compiler ou lancer un programme sur un processeur ou une machine différente. Couplé à KVM, XEN ou VMWare, il permet une virtualisation performante.

Quoi de neuf ?

L'article de Next résume bien les changements sur ARM et Risc-V. C'est technique, n'étant pas connaisseur je vous y renvoie.

x86 bénéficie de changements globaux à toutes les architectures avec quelques ajouts spécifiques pour des processeurs Intel. Mon petit doigt impatient de tester me souffle que ça sera plus rapide avec des accès "multithread¹" aux périphériques de stockage (virtio-scsi et virtio-blk). L'accès direct au matériel en espace utlisateur continue de s'améliorer (VFIO, fonctions virtuelles d'entrées-sorties).

Les autres changements concernent l'émulation des architectures HPPA et S390.

Attention aux trucs enlevés

À chaque version ou presque, des morceaux sont enlevés. Si vous faites dans l'exotique, ne vous précipitez pas sur la dernière version sans consulter la liste des Removed features.

Documentation d'introduction pour QEMU et la virtualisation

En guise de conclusion, voici quelques pistes pour ceux et celles qui débutent avec la virtualisation sous Linux et/ou QEMU. Différentes distributions Linux ont de la documentation sous licence libre. Loin d'être exhaustif, voici quelques choix :

• Le wiki d'Arch Linux a une catégorie sur la virtualisation.
• Dans la documentation de Red Hat Enterprise Linux, il y a ce document : Configuring and managing virtualization.
• Dans la documentation de SUSE Linux Enterprise Server, il y a notamment le Virtualization Guide.

Dans le cadre des 20 ans de Fedora-fr et du Projet Fedora en lui-même, Nicolas Berrehouc alias Nicosss et moi-même (Charles-Antoine Couret alias Renault) avons souhaité poser des questions à des contributeurs francophones du Projet Fedora et de Fedora-fr.

La diversité des profils permet de voir le fonctionnement du projet Fedora sous différents angles, au-delà de la distribution, mais aussi comment il est organisé et conçu. Certains points s’appliquent d’ailleurs à d’autres distributions.

N’oublions pas que le Projet Fedora reste un projet mondial et un travail d’équipe, ce que ces entretiens ne permettent pas forcément de refléter. Mais la communauté francophone a la chance d’avoir suffisamment de contributeurs et de contributrices de qualité pour permettre de donner un aperçu de beaucoup de sous-projets de la distribution.

Chaque semaine un nouvel entretien sera publié sur le forum Fedora-fr.org, LinuxFr.org et le blog de Renault.

L’entretien du jour concerne Timothée Ravier, contributeur au Projet Fedora en particulier aux systèmes dits immuables et à l’environnement KDE Plasma.

Sommaire

• Conclusion

Bonjour Timothée, peux-tu présenter brièvement ton parcours ?

J’ai commencé à m’intéresser aux logiciels open source autour de 2004 lorsque j’ai découvert Firefox (version 1.0 à l’époque) par l’intermédiaire d’un ami qui l’a téléchargé pour moi sur un CD ré-inscriptible, car je n’avais pas encore l’ADSL à l’époque. J’ai ensuite découvert Linux avec Ubuntu 6.06. Après mes études d’ingénieur en sécurité informatique, j’ai travaillé à l’ANSSI pendant cinq ans sur le projet CLIP OS et je travaille désormais pour Red Hat où je co-dirige l’équipe CoreOS, qui est responsable de la maintenance de Fedora CoreOS et de Red Hat Enterprise Linux CoreOS pour OpenShift.

Peux-tu présenter brièvement tes contributions au Projet Fedora ?

Mes contributions à Fedora sont liées à mon intérêt pour les systèmes orientés conteneurs, parfois dénommés immuables (immutable). Je fais ainsi partie de l’équipe qui maintient Fedora CoreOS, je suis un mainteneur des Fedora Atomic Desktops (principalement Silverblue et Kinoite) et je suis membre du KDE Special Interest Group (SIG).

Qu’est-ce qui fait que tu es venu sur Fedora et que tu y es resté ?

Je suis passé par plusieurs distributions Linux (Ubuntu, Gentoo, Arch Linux) mais je suis désormais sur Fedora.

Je pense que les « Four Foundations » de Fedora représentent bien mon parcours :

• Freedom : Je suis là parce que je suis intéressé par les logiciels libres, car ils permettent un partage, une mise en commun au bénéfice de tous.
• Features, First : C’est la force de la communauté Fedora d’un point de vue technologique. Je développe ce point dans les questions suivantes.
• Friends : Je me suis fait des amis dans la communauté Fedora et cela contribue à la bonne ambiance et la motivation pour continuer à contribuer.

Pourquoi contribuer à Fedora en particulier ?

Je préfère être proche des projets upstream et des dernières évolutions. C’est pour cela que j’étais pendant un long moment sous Arch Linux.

Mais le processus pour pousser des changements dans Arch Linux était plutôt flou. Il est important de noter que cela a peut-être changé désormais. Mon expérience date de plus de 6 ans et je crois qu’ils ont un processus de RFC maintenant. Le fonctionnement d’Arch Linux impose aussi des mises à jour régulières et une certaine discipline lors des mises à jour liée au modèle de développement sans version fixe.

Je commençais alors à m’intéresser de plus en plus aux systèmes à base d’images (CoreOS Container Linux et Fedora Atomic Host à l’époque) et je suis donc allé voir Fedora Atomic Workstation (ancien nom de Silverblue) pour créer une version à base de l’environnement KDE Plasma, qui est devenue Fedora Kinoite.

Le processus pour pousser des changements dans Fedora est ce qui fait la force de la distribution. Il permet d’obtenir des discussions et des décisions sur les évolutions à apporter à la distribution pour la prochaine version.

Contribues-tu à d’autres Logiciels Libres ? Si oui, lesquels et comment ?

En dehors de Fedora, je contribue principalement au développement des projets KDE. Je fais partie de l’équipe qui maintient les applications KDE empaquetées avec Flatpak et publiées sur Flathub.

Je contribue aussi occasionnellement à différents projets open source en fonction des besoins.

Utilises-tu Fedora dans un contexte professionnel ? Et pourquoi ?

Oui, mes ordinateurs professionnels et personnels tournent sous Fedora Kinoite et mes serveurs personnels utilisent Fedora CoreOS. Une partie des serveurs que nous utilisons pour développer et produire les versions de Fedora CoreOS sont aussi sous Fedora CoreOS. D’autres sont sous Red Hat Enterprise Linux CoreOS, car ils font partie d’un cluster OpenShift.

En gros, nous sommes aussi des utilisateurs directs des logiciels que nous développons.

Est-ce que tes contributions dans Fedora se font entièrement dans le cadre de ton travail ? Si non, pourquoi ?

Une grosse partie de mes contributions se font dans le cadre de mon travail, mais toute la partie liée à KDE et aux Fedora Atomic Desktops est faite sur mon temps personnel.

Est-ce que être employé Red Hat te donne d’autres droits ou opportunités au sein du Projet Fedora ?

Je n’ai pas plus de droits dans Fedora parce que je travaille pour Red Hat. Je dois suivre tous les processus de Fedora comme n’importe quel contributeur. J’ai d’ailleurs commencé à contribuer à Fedora avant d’avoir été employé par Red Hat.

En revanche, il est indéniable que cela m’aide pour contribuer, car j’ai régulièrement l’occasion de discuter avec d’autres contributeurs Fedora dans le cadre de mon travail.

Tu as débuté une carrière dans la sécurité pour finalement travailler pour Red Hat en tant que mainteneur de CoreOS, Silverblue, Kinoite et contributeur à KDE, pourquoi ne pas avoir continué dans la sécurité pour cet écosystème ?

Quelque part je continue à faire de la sécurité mais sous un autre angle. La sécurité que je faisais avant ne bénéficiait qu’à un petit nombre de personnes qui avait accès aux systèmes que l’on développait. La nouvelle version open source de CLIP OS devait rendre le système plus accessible mais le projet était complexe et je crois qu’il est désormais archivé.

Je travaille désormais à améliorer la sécurité de Fedora CoreOS et des Fedora Atomic Desktops sans compromettre leur utilisabilité. L’objectif est de fournir une distribution Linux avec des mises à jour robustes qui soit utilisable par des non développeurs.

Tu participes à CoreOS pour RHEL, CentOS Stream et Fedora. Peux-tu expliquer le but de CoreOS et ses principales caractéristiques ? Quelles sont les différences entre RHEL, CentOS Stream et Fedora à ce sujet ?

L’objectif pour les systèmes CoreOS est de faire tourner au mieux des applications dans des conteneurs. Pour Fedora CoreOS, c’est un système minimal, avec des mises à jour automatiques, proposant à la fois podman et moby-engine (Docker) installés par défaut, prêt à faire tourner des conteneurs sur un seul nœud ou dans le cadre d’un cluster Kubernetes.

Pour Red Hat Enterprise Linux CoreOS (et CentOS Stream CoreOS), ce sont des systèmes qui forment le socle d’OpenShift (et d’OKD), une plateforme qui intègre plein de projets open source dont Kubernetes.

Bien qu’il n’y ait pas une correspondance exacte un pour un dans la liste des logiciels inclus, Fedora CoreOS est l’upstream de CentOS Stream CoreOS et Red Hat Enterprise Linux CoreOS, de la même façon que Fedora est l’upstream de CentOS Stream, qui l’est de Red Hat Enterprise Linux.

L’architecture atomic a gagné du terrain sur les systèmes pour le bureau avec Silverblue et Kinoite et devient relativement populaire, peux-tu expliquer quel en est l’intérêt d’une telle conception pour ce genre de systèmes ?

Le principal intérêt pour un utilisateur est la robustesse et rapidité des mises à jour. Celles-ci sont préparées en arrière plan alors que le système fonctionne normalement. Il suffit alors de redémarrer pour mettre à jour son système. Il n’y a pas d’attente supplémentaire ni à l’extinction ni au démarrage.

Si une mise à jour échoue, le système reste dans l’état actuel, et il est possible de réessayer plus tard.
Si une mise à jour introduit un problème important empêchant le démarrage du système par exemple, il est possible de redémarrer et de choisir la version précédente dans le menu de démarrage de GRUB.

Les utilisateurs sont aussi poussés à utiliser Flatpak pour installer leurs applications graphiques et toolbox (ou distrobox) pour utiliser les applications en ligne de commandes dans des conteneurs.

Quels sont les défis techniques de proposer cette conception dans ces systèmes par rapport à CoreOS par exemple ?

La principale différence est la présence d’une interface graphique. Les applications graphiques doivent être parfois adaptées pour fonctionner avec Flatpak. C’est désormais le cas de la plupart d’entre elles.

Tu y contribues en tant que membre de Fedora Atomic Desktops SIG, peux-tu expliquer son rôle dans Fedora et ton activité dedans ?

Le rôle du Fedora Atomic Desktops SIG est de regrouper l’ensemble des contributeurs Fedora des différentes variantes Atomic : Silverblue, Kinoite, Sway Atomic et Budgie Atomic. Bien que chacun de ces systèmes propose un environnement de bureau distinct, ils partagent énormément d’éléments, tant au niveau des composants de base du système que de l’infrastructure Fedora. Le SIG permet donc de regrouper les contributeurs pour pouvoir les inclure dans les prises de décisions qui impactent ces systèmes.

Je participe à la maintenance des Fedora Atomic Desktops et plus principalement de Silverblue et Kinoite. Cela peut impliquer des mises à jour de paquets, des corrections de bugs dans des projets upstream ou des rajouts de fonctionnalités pour améliorer l’expérience sur ces systèmes. Je surveille aussi que tous les Atomic Desktops continuent de recevoir des mises à jour régulièrement.

Penses-tu qu’un jour ces systèmes atomic deviendront la référence par défaut ? Si oui à quelle échéance ? Quelles sont les difficultés actuelles à résoudre ?

Je l’espère ! Il est impossible de donner une échéance et cela ne dépend pas vraiment de moi. La difficulté la plus importante est la prise en charge du matériel et les pilotes qui ne sont pas intégrés dans Fedora. C’est un problème que l’on ne peut pas résoudre dans Fedora à cause des contraintes légales et qui sont traitées par le projet Universal Blue, dont la variante Bazzite (https://bazzite.gg/), est très populaire.

Pour la problématique des pilotes, est-ce que l’initiative du noyau unifié (d’avoir une image universelle et signée comprenant le noyau, initrd, la ligne de commande) te semble être une solution à cette problématique ?

Ces deux sujets ne sont pas liés.

Le problème des pilotes externes au noyau Linux upstream est divisé en deux cas principaux :

• Les pilotes propriétaires : Ils ne seront jamais ajoutés directement à Fedora pour des raisons légales et de licence.
• Les pilotes open source mais non inclus dans le noyau Linux upstream : Fedora met à jour le noyau Linux très régulièrement et suit les nouvelles versions stables peu de temps après leur sortie officielle. Il faut donc que ces pilotes soient mis à jour pour suivre les nouvelles versions du noyau et cela demande toujours du temps lorsque ceux-ci ne font pas partie du noyau upstream.

Les images noyau unifiées (Unified Kernel Images ou UKI) incluent le noyau, l’initrd et la ligne de commande du noyau dans un seul fichier. Cela présente des avantages pour mettre en place une chaîne de boot mesurée, notamment à l’aide du TPM, et donc pour offrir de meilleures garanties de sécurité. Leur intégration est encore en cours dans les variantes CoreOS et Atomic Desktops.

Les développeurs et administrateurs systèmes ont souvent besoin d’outils qui à ce jour nécessitent souvent de recourir à rpm-ostree plutôt que Flatpak ou Fedora toolbox dans le cadre d’un système immuable. Penses-tu que ces verrous sont un réel problème et qu’ils seront éventuellement résolus dans le temps ?

L’un des objectifs de la nouvelle initiative conteneurs bootables (« Bootable Containers ») est justement de rendre plus ergonomique la modification du système de base. Le système est distribué sous forme d’une image de conteneur standard (image OCI) et il est possible de la modifier à l’aide d’un Containerfile / Dockerfile et d’outils natifs aux conteneurs. Cela permet aux utilisateurs de ré-utiliser leurs habitudes et outils pour modifier aussi leur système de façon sûre et de partager le résultat à l’aide d’un registre d’image de conteneurs.

Nous allons aussi ajouter à nouveau dnf (version 5) dans ces images de conteneurs pour mettre à disposition des utilisateurs une interface familière et toutes les options de dnf lors de la construction de ces images.

Une autre piste est d’utiliser le concept des extensions systèmes de systemd (systemd system extensions ou sysexts), qui permettent d’ajouter du contenu dynamiquement à un système sans perdre les avantages de la gestion à base d’images. Les sysexts utilisent la même technologie que pour les conteneurs (overlayfs) pour ajouter des éléments (merge) au contenu des dossiers /usr et /opt de l’image de base. Je suis en train d’investiguer cette option pour rendre son usage ergonomique pour ces systèmes : https://github.com/travier/fedora-sysexts.

Il est aussi possible de modifier temporairement le système en utilisant un système de fichier temporaire monté au-dessus des emplacements en lecture seule (overlayfs). Les fichiers de /usr peuvent alors être modifiés et de nouveaux paquets RPM installés à la demande. Les modifications disparaîtront au redémarrage.

Tu participes aussi à l’équipe de KDE SIG, peux-tu expliquer son rôle dans Fedora et ton activité dedans ?

L’objectif du KDE SIG est de proposer la meilleure expérience possible de KDE sur Fedora. Nous suivons et contribuons aussi au développement de KDE upstream.

Je participe au KDE SIG en tant que mainteneur de Kinoite et développeur KDE.

GNOME reste le bureau principal de Fedora à ce jour, cependant la qualité de l’intégration de KDE progresse depuis de nombreuses années maintenant, penses-tu que la qualité entre les deux est aujourd’hui équivalente ? Est-ce que les contributions pour KDE sont freinées de par le statut de GNOME au sein du projet ?

C’est une question très difficile, car elle est très subjective. J’utilise principalement KDE sur mes systèmes, mais j’apprécie énormément le travail de design fait sur GNOME. Pour moi c’est un choix personnel.

D’un point de vue technologique, il est possible de trouver des éléments “meilleurs” dans GNOME que dans KDE et l’inverse.

Il n’y a pas de bénéfice à opposer ces deux projets. C’est au contraire la collaboration qui améliore l’expérience utilisateur.

Je ne pense pas que les contributions à KDE soient freinées par le status de GNOME dans Fedora.

L’équipe KDE SIG a récemment proposé d’améliorer le statut de KDE au sein du projet, quitte à même remplacer GNOME pour Fedora Workstation, peux-tu expliquer cette demande ? Penses-tu qu’un jour KDE remplacera GNOME au sein de Fedora ou de RHEL par exemple ?

L’idée des membres soutenant cette proposition (qui ne vient pas uniquement de personnes faisant partie du KDE SIG) est de remettre en question la place de GNOME « par défaut » dans le projet Fedora (notamment Fedora Workstation). Poser cette question force le projet à clarifier les critères qui font qu’un environnement de bureau est considéré comme majeur et donc autorisé à être représenté par une “édition” comme Fedora Workstation. Tous les environnements de bureau non-GNOME ne sont actuellement pas bien présentés sur le site de Fedora notamment.

Il est important pour un projet communautaire de pouvoir justifier ses choix, que l’on soit d’accord ou non avec les arguments présentés. Si ces choix sont perçus comme arbitraires (« c’est comme ça que cela a toujours été », « c’est un employé de Red Hat qui l’a décidé »), alors le projet Fedora perd en crédibilité. Il faut, par exemple, pouvoir justifier que GNOME est un bon choix à présenter aux utilisateurs découvrant Fedora.

Je ne pense pas que KDE va “remplacer” GNOME dans Fedora et ce n’est pas vraiment l’idée derrière cette proposition qui a été formulée explicitement de la sorte pour forcer la discussion. L’objectif est de rendre KDE plus visible dans Fedora.

Pour ce qui est de remplacer GNOME dans RHEL, c’est peu probable et cela serait une décision de Red Hat.

Penses-tu que Fedora est une distribution de référence pour utiliser KDE aujourd’hui ? Par le passé OpenSUSE, Kubuntu ou Mageia étaient souvent recommandées pour utiliser cet environnement.

Oui ! :) Fedora propose depuis plusieurs années les dernières versions de KDE à des fréquences très proches des sorties upstream. Nous sommes actuellement l’une des premières distributions à proposer le bureau KDE Plasma dans sa version 6. Le KDE SIG suit et participe activement au développement de KDE upstream et certains développeurs KDE recommandent désormais Fedora.

Je travaille avec Fedora Kinoite à rendre le développement de KDE plus abordable, notamment pour le test des versions en cours de développement.

Si tu avais la possibilité de changer quelque chose dans la distribution Fedora ou dans sa manière de fonctionner, qu’est-ce que ce serait ?

Je regrouperai l’intégralité des dépôts Git, codes sources, projets, suivi des bugs, etc. sur une (ou plusieurs) instance GitLab hébergée par le projet Fedora. C’est un projet qui est désormais en cours pour migrer vers Forgejo. Finies les instances Pagure (forge de développement Git), plus de Bugzilla (suivi des bugs). Il faudrait aussi abandonner les listes de diffusion pour utiliser Discourse à la place (transition aussi en cours).

D’un point de vue personnel, la migration du projet KDE vers GitLab fut un facteur déterminant dans ma capacité à contribuer au projet KDE. Le mode de contributions à l’aide de Pull Requests / Merge Requests à travers une interface web est devenu un standard qui réduit significativement la difficulté pour un premier contributeur à participer à un projet.

Je pense que c’est la prochaine étape importante pour rendre le développement de Fedora plus accessible et donc pour attirer plus de contributeurs.

À l’inverse, est-ce qu’il y a quelque chose que tu souhaiterais conserver à tout prix dans la distribution ou le projet en lui-même ?

Le processus pour proposer un changement (Change Process). C’est la clé de ce qui fait de Fedora une distribution à la pointe, qui évolue à chaque nouvelle version et qui pousse l’écosystème en avant.

Que penses-tu de la communauté Fedora-fr que ce soit son évolution et sa situation actuelle ? Qu’est-ce que tu améliorerais si tu en avais la possibilité ?

Malheureusement, je n’ai pas eu beaucoup d’interactions avec la communauté Fedora-fr, donc je n’ai pas grand-chose à dire.

Quelque chose à ajouter ?

Merci pour l’entretien !

Si vous souhaitez en apprendre plus sur ces systèmes, je vous recommande les documentations officielles des projets ou les présentations que j’ai réalisées (une ou deux en français).

Merci Timothée pour ta contribution !

Conclusion

Nous espérons que cet entretien vous a permis d’en découvrir un peu plus sur les systèmes immuables de Fedora et l’environnement KDE Plasma.

Si vous avez des questions ou que vous souhaitez participer au Projet Fedora ou Fedora-fr, ou simplement l’utiliser et l’installer sur votre machine, n’hésitez pas à en discuter avec nous en commentaire ou sur le forum Fedora-fr.

À dans 10 jours pour un entretien avec Thomas Canniot, ancien traducteur de Fedora en français et fondateur de l’association Fedora-fr.

Proxmox Server Solutions GmbH a publié la version 8.4 de sa plate-forme de virtualisation libre Proxmox Virtual Environment (VE). Proxmox VE est sous licence GNU Affero GPLv3. Proxmox Server Solutions propose un support d’entreprise à partir de 115 € par an et par processeur.

Principales nouveautés de la version 8.4

• Migration à chaud avec des dispositifs médiés :
  Les dispositifs médiés permettent de partitionner les ressources matérielles physiques en plusieurs dispositifs virtuels. Il est désormais possible de migrer des machines virtuelles (VM) en cours d’exécution utilisant des dispositifs médiés, tels que les vGPU NVIDIA.

• API pour les solutions de sauvegarde tierces :
  Proxmox VE propose une API qui simplifie le développement de plug-ins par les fournisseurs de solutions de sauvegarde externes. Ces solutions de sauvegarde tierces peuvent désormais implémenter directement des fonctionnalités de sauvegarde et de restauration dans Proxmox VE, tout en tirant parti de fonctionnalités avancées.

• Passage direct de répertoires via Virtiofs :
  La version 8.4 offre la possibilité de partager des fichiers et des répertoires directement entre un hôte et les machines virtuelles (VM) exécutées sur cet hôte. Cette fonctionnalité est rendue possible par virtiofs, qui permet aux machines virtuelles d’accéder aux fichiers et répertoires de l’hôte sans surcharger le système de fichiers réseau. Les systèmes invités Linux modernes sont dotés de la prise en charge native de virtiofs, tandis que pour les invités Windows, l'utilisation de cette fonctionnalité nécessite un logiciel supplémentaire.

• Mises à jour de tous les composants libres :
  Proxmox VE 8.4 est basé sur Debian 12.10 (“Bookworm”), mais utilise par défaut le noyau Linux 6.8.12. Cette version de Proxmox VE inclut des mises à jour vers les dernières versions des principales technologies open source pour les environnements virtuels, telles que QEMU 9.2.0, LXC 6.0.0. La solution est livrée avec ZFS 2.2.7 et Ceph Squid 19.2.1.

D’autres améliorations incluent un mécanisme de filtrage de sauvegarde plus robuste, des améliorations de la pile SDN (réseau défini par logiciel), et de nouvelles options dans l’installateur ISO.

Cette dépêche fait suite à celle sur les interfaces temps réel ainsi qu’a celle sur l’informatique sans écran. C’est une dépêche de réac qui se plaint que c’était bien mieux avant et qu’on ferait bien d’écouter les anciens un peu plus.

Sommaire

• Retour vers le futur boutonneux
• C’était mieux avant ! (On était jeune)
• Ça change quoi ? Un bouton c’est un bouton, non ?
• Le patch de Colombia
• L’urgence ergonomique
• Bibliographie

C’est une note du blog de ploum qui m’a fait réaliser que l’on a besoin de remettre des boutons, des touches, des joysticks, des potentiomètres linéaires et autres boules de pointage (trackball), souris (boutons et molette), manettes… sur nos ordinateurs, télés, ordiphones, bagnoles et autres mixeurs à soupe mouchard. C’est urgent à l’heure où même nos guitares sont menacées par les écrans tactiles. Bref, une bonne interface Humain/Machine passe par un retour tactile de nos actions : on veut des boutons !

Figure 1 - Refus catégorique de ChatGPT. Peut-être que « Dessine moi un adolescent avec plein de moutons » aurait été mieux accepté. Big Data implique Big Culture, non ?

Retour vers le futur boutonneux

Avant de râler et de déclencher la Guerre des boutons, interrogeons-nous sur ces objets du quotidien. On est sérieux à nôtre âge, on n’a plus dix-sept ans.

Si on considère les touches des claviers d’instruments de musique comme les ancêtres du bouton, alors on peut remonter jusqu’à l’Antiquité et aux premiers orgues : l’hydraule, orgue où l’air est mis sous pression par une chute d’eau, date en effet du III^e siècle avant notre ère (Ctésibios d’Alexandrie). C’est aussi le premier instrument à clavier. Ses touches avaient probablement des mécanismes très simples et il n’y avait pas de touches blanches et noires, comme dans cette reconstitution d’un orgue antique (avec même le son dans la vidéo). Vers 320-322 de notre ère, Claudien écrit un poème contenant ces vers :

« Qu’un autre enfantant, par une légère pression, des sons au loin retentissant, modère les mille voix de mille tuyaux d’airain, les fasse tonner sous ses doigts errants, et d’une onde profondément agitée par le jeu du levier, tire d’harmonieuses modulations. » (Panégyrique sur le consulat de Flavius Mallius Theodorus)

Figure 2 - Reconstitution d’un orgue romain. [Source : Wikimedia, domaine public]

On trouve déjà dans cette description le constat qu’il suffit d’appuyer sur un bouton pour déclencher des tâches mobilisant une grande puissance. Seize siècles plus tard, en pleine guerre froide et deux ans après la crise des missiles de Cuba, le jeune Bob Dylan (22 ans) chante dans With God On Our Side (The Times They Are A-Changin’, 1964) :

One push of the button
And a shot the world wide

Figure 3 - Tableau de bord des missiles de croisière nucléaires du sous-marin USS Growler (1958-1964). [Source : Wikimedia, licence : CC-BY-SA par Flintmichigan]

C’est en fait dans les deux dernières décennies du XIX^e siècle, avec la diffusion de l’électricité dans les villes, que se produit la grande éruption des boutons. Nous avons bien sûr oublié à quel point c’était magique à l’époque ! Mais on s’inquiète aussi rapidement de l’avènement d’une humanité presse-bouton :

Plotnick cite un éducateur et activiste de 1916 déplorant que le fait d’appuyer sur un bouton « semble nous décharger de toute nécessité de se sentir responsable quant à ce qui se passe derrière le bouton ».

Les récits d’anticipation s’en emparent. Par exemple, Edward Morgan Forster publie en 1909 une nouvelle intitulée The Machine Stops (La Machine s’arrête) dans laquelle les êtres humains vivent sous terre isolés chacun dans une pièce, quasiment sans contact physique, la Machine satisfaisant tous leurs besoins :

Puis elle activa la lumière, et la vue de sa chambre, inondée de lumière et constellée de boutons électriques, la revigora. Il y avait des boutons et des interrupteurs partout - des boutons pour demander de la nourriture, de la musique, des vêtements. Il y avait le bouton du bain chaud, qui faisait surgir du sol une cuve en (faux) marbre, remplie à ras bord d’un liquide chaud et désodorisé. Il y avait le bouton du bain froid. Il y avait le bouton qui produisait de la littérature. Et il y avait bien sûr les boutons qui lui permettaient de communiquer avec ses amis. La chambre, bien que ne contenant rien, était connectée avec tout ce qui lui importait dans le monde. (Version originale en ligne sur The Project Gutenberg et version française éditée par l’échappée)

C’était mieux avant ! (On était jeune)

Tout râleur qui tient à sa crédibilité se doit de râler en connaissance de cause. On n’ira donc pas jusqu’à prétendre que c’était mieux sans bouton et on se contentera de notre vécu : c’était mieux avant quand il y avait de vrais boutons ! Qu’on pouvait pressurer et qui faisaient de vrais sons, « des clip, crap, des bang, des vlop et des zip », qui résistaient, qui vibraient, qui glissaient ! Bref, qui nous donnaient des sensations.

Figure 4 - Malgré cet appel touchant, les portes de la perception semblent désormais presque fermées. Le monde est devenu plat et lisse ; les êtres humains se sont enfermés dans leur caverne numérique. [Source : Wikimedia, licence : CC-BY par SunOfErat]

Bien que la technologie des écrans tactiles soit assez ancienne, c’est surtout l’envolée des ventes de smartphones et tablettes autour de 2010 qui va propager les interfaces tactiles à d’autres objets du quotidien : des appareils électroménagers jusqu’aux voitures, pour le meilleur et pour le pire. Probablement parce qu’un écran tactile avec des menus permet de remplacer de nombreux boutons et aussi par effet de mode (ça fait moderne, en attendant les interfaces cérébrales). Dans nos interfaces graphiques, telles que GTK, on retrouve des ersatz de boutons : interrupteurs On/Off, boutons radio (quand on presse sur l’un, l’autre ressort), commutateurs (switches), etc. Mais tout ça manque de relief !

Sur les lecteurs de K7, on pouvait avoir des boutons poussoir qui remettaient à zéro le compteur (mécanique). Et également des boutons qu’on poussait vers le bas et qui restaient bloqués (lecture) ou non (éjection). Press the Eject and Give Me the Tape est par exemple le titre d’un album live du groupe britannique Bauhaus sorti en 1982.

Figure 5 - Un magnétophone : appuie sur Eject et file-moi la K7 ! [Source : Wikimedia, domaine public]

Sur une chaîne Hi-Fi, on trouve de bons gros boutons cylindriques que l’on peut prendre à pleine main. Ils peuvent être continus (par exemple pour le volume), c’est-à-dire que ce sont des potentiomètres rotatifs, ou à crans (par exemple pour sélectionner une source). Ces gros boutons ont été longtemps également utilisés pour sélectionner les fréquences des stations de radio et ils faisaient bouger un curseur au-dessus des graduations. Sur nos chaînes, on peut aussi avoir des boutons de type manette, avec deux positions ou plus. Sur les radio-K7 on pouvait également rencontrer des potentiomètres linéaires pour régler le volume ou la tonalité. On les utilise aussi sur les égaliseurs, comme ci-dessous.

Figure 6 - Une éruption de boutons divers et variés, sensations garanties [source : Wikimedia, licence : CC0].

Dans la suite de cette dépêche, on va surtout évoquer les boutons poussoir (qu’ils restent bloqués ou non) car ce sont ceux que l’on rencontre le plus dans les interfaces tactiles. Mais le discours serait similaire pour les autres types de boutons.

Ça change quoi ? Un bouton c’est un bouton, non ?

Le problème de l’écran tactile, c’est que c’est l’écran qui est tactile, qui touche, qui sent notre doigt. Le doigt, quant à lui, sent juste qu’il a touché une surface, mais il ne sait pas s’il est au bon endroit. L’écran est soi-disant tactile, mais c’est avant tout un écran, ce qui implique la vue. Lorsque l’on touche le bouton avec son doigt, on le cache. Pour savoir s’il on a bien appuyé sur le bouton il faut donc retirer son doigt et regarder à nouveau si le bouton virtuel a changé d’état.

Du point de vue de l’utilisateur, on a donc plutôt affaire à des « boutons visuels » plutôt qu’à un « écran tactile ». Tout au plus l’émission d’un clic électronique ou d’une vibration non localisée confirmera qu’on a appuyé sur un bouton (parmi d’autres).

Avec de vrais boutons, c’est du 3D. Si on a mémorisé leur disposition, on peut s’en sortir sans la vue, uniquement au toucher. Intéressant quand on conduit par exemple, les doigts se promènent par exemple sur les six boutons pour choisir la station de radio et trouvent sans problème le troisième bouton. Une personne aveugle sera bien démunie face à un écran tactile. Un bouton mécanique est quant à lui vraiment tactile, c’est-à-dire que les doigts le sentent : le toucher prédomine alors sur la vision. D’ailleurs en français, les « boutons » d’un clavier, qu’il soit musical ou informatique, s’appellent des touches.

On peut aussi noter que les vrais boutons sont généralement en nombre limité (car ça prend de la place et ça coûte). Ils permettent donc d’effectuer les actions les plus courantes. Les écrans permettent de créer des menus, pour des choix plus complexes. Mais cela peut être redoutable pour certaines personnes âgées, qui n’ont pas été habituées à ces technologies, ou dont les fonctions cérébrales déclinent. Ne parlons même pas des mises à jours logiciels incessantes qui changent l’aspect et la disposition des menus.
Le pire étant le manque de performance (c'est rarement temps réel) qui nous force souvent à ré-apppuyer pour se retrouver avec un comportement que l'on avait pas prévu quand ça se débloque.

Autre problème, on a parfois besoin de protéger ses doigts avec des gants, qu’il fasse froid ou qu’on soit en train de faire une activité dangereuse pour les mains. Un bon vieux bouton reste généralement utilisable. Même avec des moufles, on pourra encore y arriver si les boutons ne sont pas trop rapprochés !

Figure 7 - Parfois on doit travailler avec des gants, ce qui entraîne une perte au niveau tactile. Il y a vraiment là de quoi faire la moue. [Source : Wikimedia, domaine public]

Revenons sur le son. Les boutons sur lesquels on appuie émettent souvent un son qui constitue un retour sensoriel supplémentaire qui nous indique si nous les avons correctement enfoncés. Au point que l’on parle de « cliquer » sur le bouton d’une souris plutôt que d’appuyer dessus. On a donc à la fois un retour tactile (une certaine résistance ou vibration) et un retour sonore, en plus de l’éventuel retour visuel si on regarde le bouton.

Avec un écran dit tactile, le retour tactile est justement bien maigre, on ne fait qu’effleurer les choses : la pression exercée importe peu, la résistance opposée par l’écran sera la même si j’appuie sur le soit-disant bouton ou à côté ! Et le vibreur de mon téléphone fera vibrer tout le téléphone au lieu de ne faire vibrer que l’endroit où j’ai appuyé. Triste topique…

Le patch de Colombia

Les constructeurs d'ordiphone s'échinent à virer les boutons de leurs appareils ? Qu'à cela ne tienne, des étudiants de l'Université de Colombia proposent une coque pour en remettre !

Sans aucune connexion électrique, ces étudiants proposent de faire vibrer le téléphone au moyen de clapet et ressort et de les détecter en utilisant l'accéléromètre.

Le type de vibration reçue permet à un logiciel de traitement du signal de détecter le type de bouton actionné et ainsi récupérer la fonctionnalité perdue.

C'est intéressant, mais pourquoi ne pas tout simplement nous rendre nos boutons !

L’urgence ergonomique

Nous savons bien que les temps changent, mais il ne faut pas céder à la mode sans raison. L’écran tactile peut être adapté à certaines machines ou situations et pas à d’autres. Faut-il vraiment « être absolument moderne », juste pour le plaisir ? Non, il faut être absolument ergonomique. Alors, si vous ne voulez pas vous faire appeler Arthur, rendez-nous nos bons vieux boutons là où ils sont parfaitement adaptés à nos besoins ! Rouvrons les portes de la perception !

Figure 8 - Un adolescent peut aussi avoir des boutons au niveau de son gilet. De plus, en voilà un qui ne sourit pas et n’a pas l’air niais. Ce qui finalement justifie peut-être le refus de ChatGPT en haut de cette dépêche. [Source : Wikimedia, Étienne Carjat (1871), domaine public]

Bibliographie

• Gwendolyn Rak, « Touchscreens Are Out, and Tactile Controls Are Back - Rachel Plotnick’s “re-buttonization” expertise is in demand », IEEE Spectrum, 3 nov. 2024.
• Rachel Plotnick, « At the Interface: The Case of the Electric Push Button, 1880–1923 », Technology and Culture 53 (4): 815‑45, 2012.
• Dans Wikipedia : Bouton (électricité), Interrupteur, Push-button.
• Entrée Bouton dans le dictionnaire TLFi.

Dans le cadre des 20 ans de Fedora-fr (et du Projet Fedora en lui-même), nous – Charles-Antoine Couret (Renault) et Nicolas Berrehouc (Nicosss) – avons souhaité poser des questions à des contributeurs francophones du Projet Fedora et de Fedora-fr.

Grâce à la diversité des profils, cela permet de voir le fonctionnement du Projet Fedora sous différents angles pour voir le projet au-delà de la distribution mais aussi comment il est organisé et conçu. Notons que sur certains points, certaines remarques restent d’application pour d’autres distributions.

N’oublions pas que le Projet Fedora reste un projet mondial et un travail d’équipe ce que ces entretiens ne permettent pas forcément de refléter. Mais la communauté francophone a la chance d’avoir suffisamment de contributeurs de qualité pour permettre d’avoir un aperçu de beaucoup de sous projets de la distribution.

Chaque semaine un nouvel entretien sera publié sur le forum Fedora-fr.org, LinuxFr.org et le blog de Renault.

L’entretien du jour concerne Remi Collet (pseudo remi), empaqueteur du Projet Fedora en particulier concernant l’écosystème PHP.

Sommaire

• Conclusion

Peux-tu présenter brièvement ton parcours ?

40 ans, c’est long !

J’ai découvert l’informatique à une époque préhistorique où l’on travaillait sur des terminaux (texte) connectés à de gros systèmes avec des langages oubliés (Cobol…). Ensuite j’ai eu la chance de voir les choses changer.

Travaillant pendant 20 ans dans une grande administration française, et parallèlement dans une université à la gestion du matériel pédagogique. J’ai vu arriver les ordinateurs personnels, les premiers réseaux locaux, GNU, Linux, Windows, Internet… Rapidement à l’université (veille technologique) et progressivement dans le monde professionnel. Les solutions OpenSource ont toujours été au cœur de mon activité, et la contribution un but personnel.

Au départ développeur, je suis aussi devenu administrateur système et réseau.

Je travaille désormais chez Red Hat comme développeur, principalement chargé de PHP.

Peux-tu présenter brièvement tes contributions au Projet Fedora ?

Lorsque j’ai migré mon ordinateur personnel sous Linux il y a plus de 20 ans, j’ai passé beaucoup de temps sur les forums, pour apprendre des autres et aider les nouveaux.
Cela a été très formateur.

Ensuite je me suis investi dans la maintenance de paquets RPM pour mes besoins et pour partager. Et je me suis concentré sur le monde PHP.

Qu’est-ce qui fait que tu es venu sur Fedora et que tu y es resté ?

J’ai commencé avec Red Hat Linux 5 (1997), qui est devenu Fedora Core, puis Fedora. Au départ c’est le hasard d’un serveur livré avec un CD. Et depuis j’ai toujours été fidèle à l’une des premières distributions majeures.

Pourquoi contribuer à Fedora en particulier ?

Parce que c’est “la” distribution où les choses changent.

Peux-tu préciser les éléments qui confirment cela de ton point de vue ?

L’exemple le plus marquant est sans doute “systemd” qui a provoqué lors de sa sortie un débat technique très vif, mais qui est désormais sur toutes les distributions (ou presque).

Contribues-tu à d’autres Logiciels Libres ? Si oui, lesquels et comment ?

Principalement PHP et de nombreux projets autour (extensions, bibliothèques, applications…).

Utilises-tu Fedora dans un contexte professionnel ? Et pourquoi ?

Oui, depuis 1997 avec l’installation d’un serveur d’accès à Internet. Et aujourd’hui sur tous mes serveurs et postes de travail.

Tu as été recruté par Red Hat alors que tu étais déjà dans la communauté de Fedora, comment cela s’est passé ?

Depuis la fusion de Fedora Core + extras (2007), j’étais devenu le mainteneur du paquet PHP. Donc quand Red Hat a cherché à recruter un mainteneur spécifique pour PHP (2012), j’étais le mieux placé.

Ils t’ont contacté ou tu as postulé ?

Ils m’ont contacté (cooptation), ce qui tombait bien puisque je cherchais un nouvel emploi.

Est-ce que la contribution à Fedora a été un élément déterminant dans le processus ?

Clairement oui, ainsi que mon implication dans PHP, en amont.

Est-ce que tes contributions dans Fedora se font entièrement dans le cadre de ton travail ? Si non, pourquoi ?

Non.
Je contribuais au Projet Fedora avant de rejoindre Red Hat, et si j’ai la chance de pratiquer ma passion (l’OpenSource) dans mon travail, je continue aussi en dehors. Ma position m’a aussi permis d’augmenter mes contributions sur les autres projets.

Par contre, aujourd’hui je cherche à maintenir un équilibre afin de garder une vie privée et sociale saine.

Est-ce que être employé Red Hat te donne d’autres droits ou opportunités au sein du Projet Fedora ?

Non (en dehors du temps), et heureusement. Fedora est avant tout un projet communautaire.

Tu es actif au sein de SIG PHP, quel est le rôle de cette équipe de travail et de ton activité dans cette équipe ?

Ce groupe n’a jamais été très actif, et je suis désormais pratiquement seul.

Tu es également contributeur au sein du projet PHP lui-même, quelle est la nature de ton travail pour ce projet ?

Je contribue régulièrement au code, surtout sur des corrections de défauts rapportés par les utilisateurs de mon dépôt, de Fedora ou de RHEL. Je maintiens aussi quelques extensions (zip, mailparse, rpminfo…). Je participe aussi activement au processus de publication des nouvelles versions (QA avant annonce).

Quels bénéfices retires-tu de travailler sur les deux aspects du projet PHP à savoir upstream mais aussi sur la conception de ces paquets ?

Il me semble indispensable de communiquer entre l’amont (le projet PHP) et l’aval (le Projet Fedora). Être impliqué dans les 2 projets simplifie énormément les choses. Et évidement, il est plus facile de faire évoluer un projet lorsqu’on y contribue activement.

Quelles simplifications cela comporte plus en détail selon toi ?

Lorsqu’un utilisateur de Fedora (ou de mon dépôt) signale un bug, il est plus simple de le corriger en étant contributeur, soit directement, soit par le dialogue avec les autres développeurs.

De même pour les évolutions de la distribution qui peuvent avoir un impact sur PHP (exemple: l’intégration à systemd).

Et la réciproque est vraie pour les évolutions du projet qui peuvent affecter la distribution (exemple: la suppression d’extension ou l’ajout de nouvelles fonctionnalités nécessitant de nouveaux outils).

Être actif dans une communauté permet d’être connu et reconnu et donc d’être écouté.

Tu as aussi l’un des dépôts externes les plus populaires et actifs de Fedora centré sur PHP, pourquoi as-tu créé ce dépôt ? Pourquoi tu continues à l’alimenter alors que le projet Fedora fourni déjà PHP ?

Ce dépôt existe depuis 2005 et me permettait de partager mon travail avant de contribuer à Fedora.

Aujourd’hui c’est là que je prépare les évolutions avant qu’elles soient intégrées dans Fedora (puis dans CentOS Stream, puis dans RHEL). Par exemple PHP 8.3 présent dans Fedora 40 était dans mon dépôt depuis presque 1 an (Juin 2023, version 8.3.0alpha1)

Alors que Fedora fournit une seule version de PHP et une cinquantaine d’extensions, mon dépôt propose 5 versions (même 10 pour EL), ~150 extensions et 2 modes d’installation.

Pourquoi ne pas utiliser le système de COPR pour ce travail ?

Copr est très intéressant pour les petits projets. Dans mon cas, ce sont des milliers de paquets. Et Copr n’est pas adapté pour les modules, ni pour les quelques paquets non libres que je maintiens (ex: Oracle).

Peux-tu expliquer l’importance du mainteneur de paquet dans la distribution ? Quels choix il faut effectuer, les difficultés techniques rencontrées, etc.

C’est celui qui essai de coordonner les projets amont / aval et les utilisateurs en essayant de satisfaire des besoins parfois incompatibles de stabilité, de compatibilité, d’innovation.

Les “Modules” de Fedora étaient censés être un pilier de Fedora.next pour fournir différentes versions des piles technologiques, comme PHP, pour une version donnée de Fedora. Maintenant que c’est abandonné, peux-tu expliquer les raisons derrière cet échec ? Pour un empaqueteur, quelles ont été les difficultés derrière ?

https://blog.remirepo.net/post/2024/03/29/DNF-5-and-Modularity. Je retiendrais que ce projet répondait avant tout à un besoin de distribution entreprise qui n’est pas vraiment utile à Fedora avec un cycle de version très rapide (6 mois).

La complexité du système de construction a peut-être été une raison de son échec.

Tu as aussi écrit la documentation française pour faire ses propres paquets RPM et tu as aidé de nombreux francophones à réaliser leurs premiers paquets, qu’est-ce qui t’intéresse à guider les débutants dans cette activité ?

Le partage.
Accompagner un débutant est toujours passionnant, humainement et techniquement. Cela permet aussi de répondre à des questions qu’on ne se pose pas forcément, et donc de se remettre en cause.

Les paquets traditionnels ne sont plus l’unique voie d’avoir un logiciel qui tourne sous Fedora. Avec Flatpak, Snap ou des solutions tels que Docker / Podman cela devient possible de s’en affranchir. Comment vois-tu l’évolution des paquets au sein d’une distribution dans Fedora ? Que penses-tu de ces évolutions ?

Avant on cherchait à créer une distribution cohérente ou chaque composant était partagé et utilisé par les autres (une sorte de Lego).

Aujourd’hui, et je le regrette, beaucoup ont abandonné cet objectif et beaucoup de projets préfèrent embarquer tous les composants qu’ils utilisent.

C’est le cas de PHP avec “composer”, de langages comme Rust où la notion de bibliothèques partagées n’existe même plus. Flatpack / Snap n’en sont qu’un développement extrême.

N’est-ce pas aussi parce que cela résout certaines problématiques liées à la rigidité des paquets qui rendent notamment la cohabitation de versions différentes délicates ou de rendre l’environnement de travail plus modulaire ?

Je pense que cela ne résout rien. On sait parfaitement installer plusieurs versions d’une bibliothèque simultanément.

Disons que c’est la solution de facilité, on n’essaie même plus de faire propre. Sans parler des projets qui embarquent des copies modifiées, sans que les modifications soient reversées ou discutées.

Si tu avais la possibilité de changer quelque chose dans la distribution Fedora ou dans sa manière de fonctionner, qu’est-ce que ce serait ?

La communauté Fedora est composée de gens passionnés. La passion entraine parfois des positions excessives et des discussions sans consensus possible.
La communauté des contributeurs a tué de beaux projets, comme les « Softwares Collections » ou les “modules”. Je trouve cela dommage.

Peux-tu expliquer ce que sont les Software Collections et pourquoi cela n’a pas abouti ? Quelles différences avec les modules notamment ?

Les Software Collections permettent une méthode standard d’installation de plusieurs versions d’une application sans conflit espace de nom différent, installation sous /opt et sans risque d’altération du système de base.

Le projet ayant été développé par Red Hat pour les besoins de sa distribution Entreprise il a provoqué un vif débat technique (ex: non respect de la FHS, ce qui a été corrigé par la suite) et a même provoqué l’épuisement et le départ de 2 membres du FPC.

La complexité d’utilisation (activation de la SCL) a aussi été des raisons de leur détestation.

Ce besoin étant quasi inexistant pour Fedora, personne n’a eu la force d’améliorer la solution qui a été abandonnée.

Les modules permettent de fournir plusieurs versions alternatives d’une application, mais sans permettre une installation simultanée. Fonctionnellement c’est comme si chaque version est disponible dans un dépôt différent qu’il suffit d’activer.

À l’inverse, est-ce qu’il y a quelque chose que tu souhaiterais conserver à tout prix dans la distribution ou le projet en lui-même ?

La passion justement, qui reste un moteur indispensable. S’il n’y a plus de passion, plus de plaisir, autant arrêter (j’ai abandonné quelques projets pour cela).

Que penses-tu de la communauté Fedora-fr que ce soit son évolution et sa situation actuelle ? Qu’est-ce que tu améliorerais si tu en avais la possibilité ?

La communauté Fedora est surtout composée de contributeurs. D’autres distributions ont une communauté d’utilisateurs et sont excellentes pour leur promotion.

Je n’ai malheureusement pas d’idée magique pour augmenter la communauté Fedora-Fr.

Je pense aussi que les contributeurs français sont souvent actifs dans la communauté globale (en anglais) plutôt que dans la communauté française.

Trouves-tu que c’est spécifique à la communauté francophone ?

Je ne sais pas, je ne connais pas trop les autres communautés, mais je rencontre beaucoup de nationalités différentes dans la communauté anglophone.

Merci Remi pour ta contribution !

Conclusion

Nous espérons que cet entretien vous a permis d’en découvrir un peu plus sur l’empaquetage de Fedora.

Si vous avez des questions ou que vous souhaitez participer au Projet Fedora ou Fedora-fr, ou simplement l’utiliser et l’installer sur votre machine, n’hésitez pas à en discuter avec nous en commentaire ou sur le forum Fedora-fr.

À dans 10 jours pour un entretien avec Emmanuel Seyman, ancien président de Borsalinux-fr et actuel empaqueteur dans l’écosystème du langage Perl.

Les méandres de l'espace de rédaction sont parfois mystérieux. La rédaction de certaines dépêches s'étalent parfois sur de long mois, parfois sans même comprendre pourquoi la dépêche ne part pas vers le stade de la publication. C'est ce qui est arrivé à cette dépêche qui ne suit donc pas autant qu'elle aurait pu l'actualité de la sortie de la nouvelle mouture de la microcarte de la Fondation Raspberry Pi, qui porte le nom très original de Raspberry Pi 5. Cette dépêche - qui nous offre une comparaison de cette nouvelle édition avec son illustre ancêtre ainsi qu'une investigation de ses nouveautés - reste substantielle et il nous a semblé qu'il valait mieux la publier même tardivement plutôt que de la plonger dans l'oubli éternel.

Sommaire

• Comparaison entre Raspberry Pi 4 et Raspberry Pi 5
• Détail des améliorations de la Raspberry Pi 5
  • Raspberry Pi 5 : Nouveau South Bridge RP1 vs Raspberry Pi 4
    • Architecture du South Bridge RP1
    • Sources des informations sur le RP1
  • Impacts du RP1
  • Évolution des performances
    • performances des I/O
    • Interfaces USB et Ethernet
    • Interfaces MIPI CSI/DSI
• Les points discutables/discutés
  • Le réarrangement de la carte
  • Le non réarrangement de la carte
  • Les limites du format carte de crédit

Cette dépêche ne traitera pas de l’ensemble de ce que l’on peut faire, la précédente dépêche sur les SoC faite pour la sortie de la Raspberry Pi 4 est toujours d’actualité en ce qui concerne ces sujets.

Comparaison entre Raspberry Pi 4 et Raspberry Pi 5

Sorti en 2019, le RPi4 avait fait forte impression—mais quasiment en constante pénurie entre 2020 et 2023, il commençait par accuser le coup par rapport à la concurrence du Rockchip RK3588 (Quad-core Cortex-A76 + Quad-core Cortex-A55).

Aussi, la Raspberry Pi 5 introduit des avancées significatives par rapport à la Raspberry Pi 4, dont le Tableau 1 présente une synthèse des différences.

Composants	Raspberry Pi 4	Raspberry Pi 5
SoC	Broadcom BCM2711	Broadcom BCM2712
CPU	Quad-core Cortex-A72 (1.8 GHz)	Quad-core Cortex-A76 (2.4 GHz)
GPU	VideoCore VI (500 MHz)	VideoCore VII (800 MHz)
Mémoire	1, 2, 4, 8 GB LPDDR4-3200 SDRAM	4, 8 GB LPDDR4X-4267 SDRAM
Wi-Fi	Dual-band 802.11ac	Dual-band 802.11ac
Bluetooth	5.0, BLE	5.0, BLE
USB	2 USB 3.0, 2 USB 2.0, 1 Type-C port	2 USB 3.0, 2 USB 2.0, 1 Type-C port
Stockage	MicroSD	MicroSD (SDR104⟹R/W↗ˣ²) + ligne PCIe pour NVME M.2 SSD
Ethernet	Gigabit Ethernet	Gigabit Ethernet
Puissance	Jusqu’à 7.5 W	2 modes : jusqu’à 15 W et jusqu’à 25 W
Gestion HDMI	2 HDMI 2.0 (1 gérant 4k@60 Hz)	2 HDMI 2.0 (tous les deux gérant 4k@60 Hz)
Format vidéo	H.264 (AVC)	H.265 (HEVC)
PCIe	Non	1 lane PCIe pour périphériques haute performance
Bouton d’alimentation	Non	Oui

Tableau 1 : comparatif des Raspberry Pi 4 et 5

Détail des améliorations de la Raspberry Pi 5

La Raspberry Pi 5 introduit des avancées significatives par rapport à la Raspberry Pi 4, en particulier avec l’introduction du southbridge RP1. Voici une comparaison détaillée mettant en évidence les principales différences et l’impact du RP1 :

• Processeur : La Raspberry Pi 5 est équipée d’un CPU ARM Cortex-A76, une amélioration substantielle par rapport au Cortex-A72 trouvé dans la Raspberry Pi 4. Cette mise à niveau fait que la Pi 5 est deux à trois fois plus rapide que son prédécesseur.
• RAM : La Raspberry Pi 5 utilise de la LPDDR4X-4267 SDRAM, nettement plus rapide que la LPDDR4-3200 SDRAM utilisée dans la Pi 4. Cette amélioration offre plus de bande passante, contribuant à des performances globalement plus rapides.
• Puissance graphique : La Raspberry Pi 5 dispose d’un GPU VideoCore VII plus puissant, cadencé à 800 MHz et prenant en charge OpenGL ES 3.1 et Vulkan 1.2. C’est une avancée par rapport au GPU VideoCore VI de la Raspberry Pi 4, qui prend en charge OpenGL ES 3.1 et Vulkan 1.0. Le GPU de la Pi 5 comprend également un nouveau processeur de signal d’image pour la gestion des données des caméras.
• Chip RP1 Southbridge : La puce RP1 est une innovation majeure dans la Raspberry Pi 5. Elle agit comme un southbridge, gérant la plupart des fonctions I/O (entrée/sortie), réduisant ainsi la charge sur le CPU. Cela permet une augmentation de la bande passante I/O, bénéficiant aux dispositifs de stockage, USB et autres périphériques.
• Vitesse des cartes MicroSD : Le port microSD de la Pi 5 prend en charge le mode haute vitesse HDR 104 avec les cartes microSD UHS-1, offrant des vitesses de lecture de 80-90 Mbps, soit le double de la vitesse de 40-50 Mbps de la Pi 4.
• Ports USB : Dans la Raspberry Pi 5, chacun des deux ports USB 3.0 dispose d’une bande passante dédiée de 5 Gbps, grâce à la puce RP1. C’est une amélioration par rapport à la Pi 4, où les deux ports USB 3.0 partageaient la bande passante de 5 Gbps.
• Connecteur PCIe : La Pi 5 inclut un connecteur PCIe (PCI Express), une nouvelle addition répondant à la demande pour des interfaces plus rapides. Cependant, l’interface PCIe de la Pi 5 n’est pas un connecteur M.2 standard ; elle nécessite un câble ruban pour se connecter à un HAT, et le dispositif M.2 se connectera au HAT. Caractéristiques
• Un bouton marche/arrêt : Eh oui, on est quand même dans le 3ᵉ millénaire ;-)
• Alimentation : Tout comme la Raspberry Pi 4, la Raspberry Pi 5 utilise un connecteur d’alimentation au format USB Type-C. En revanche, doublement de la puissance oblige, la puissance nécessaire à son fonctionnement passe de 7.5 W à 15 W, il faudra donc une alimentation en 3A minimum pour être tranquille. À noter que si vous souhaitez utiliser des périphériques externes qui consomment beaucoup comme des disques durs ou SSD, il est conseillé d’avoir une alimentation de 25 W (5A). La Raspberry Pi détecte si l’alimentation fournit plus de puissance et passe la limite de consommation USB à 1,6A au lieu de 1,2A.

Raspberry Pi 5 : Nouveau South Bridge RP1 vs Raspberry Pi 4

Le RP1 est un contrôleur d’entrée/sortie (I/O) conçu pour le Raspberry Pi 5, représentant le programme d’ingénierie le plus complexe et coûteux entrepris par Raspberry Pi, avec un développement s’étendant sur plus de sept ans et ayant coûté environ 25 millions de dollars. Ce contrôleur est le premier produit phare de Raspberry Pi à utiliser une puce conçue en interne​.

Architecture du South Bridge RP1

— Description : Le RP1 est un southbridge de 12×12 mm avec un pas de 0.65 mm en BGA (Ball Grid Array), fournissant la majorité des capacités d’E/S pour la Raspberry Pi 5.
— Caractéristiques : Il comprend un point de terminaison PCIe 2.0 à 4 voies, un contrôleur Ethernet MAC Gigabit et deux contrôleurs hôtes USB 3.
— Améliorations : Plus du double de la bande passante USB utilisable par rapport à la Raspberry Pi 4.
— Documentation RP1 : RP1 Datasheet

Sources des informations sur le RP1

— L’article d’Eben Upton pour annoncer le RP1 : RP1 : the silicon controlling Raspberry Pi 5 (ce court article est accompagné d’une vidéo YT de 35 minutes à ce sujet, mais dont le contenu est reproduit textuellement en suivant un lien)
— Lien direct vers la vidéo YT : RP1 : the silicon controlling Raspberry Pi 5

Impacts du RP1

Le RP1 constitue une avancée importante, puisque les GPIOs “physiques” de la carte ne sont plus directement reliées aux GPIOs du microprocesseur et de leurs fonctions possibles (SPI/I2C/UART/I2S) attribuées par le fondeur dans le silicium.

1. Connectivité principale : Le RP1 se connecte à un processeur d’application (AP) via un bus PCIe 2.0 x4, consolidant de nombreux contrôleurs numériques et PHYs analogiques pour les interfaces externes du Raspberry Pi 5​​.
2. Contrôle du trafic : Le tissu interne du RP1 permet de prioriser le trafic en temps réel de la caméra et de l’affichage sur le trafic non en temps réel de l’USB et de l’Ethernet. Des signaux de qualité de service (QoS) sur le lien PCI Express soutiennent la priorisation dynamique entre le trafic provenant du RP1 et le trafic des maîtres de bus en temps réel et non en temps réel au sein de l’AP​​.
3. Fonctionnalités supplémentaires : Pour une flexibilité maximale des cas d’utilisation, le RP1 dispose de plusieurs fonctionnalités telles qu’un contrôleur DMA à huit canaux pour les périphériques à basse vitesse, trois PLL intégrées pour la génération d’horloges vidéo et audio indépendantes, un convertisseur analogique-numérique à cinq entrées, 64kB de SRAM partagée, et des générateurs de base temporelle pour le rythme de la DMA ou pour le debouncing des événements GPIO​​​​.
4. Gestion des contrôleurs de bus : Les modules de régulation intégrés à chaque port de contrôleur de bus permettent de surveiller ou de limiter leur comportement. Ces modules régulent le flux de données selon le nombre de transactions en attente, assurent le respect des limites d’adresses AXI et PCIe, et disposent de compteurs statistiques pour évaluer la qualité de service ou les performances.
5. Interfaces clés externes : Le RP1 fournit des interfaces externes clés telles que deux contrôleurs XHCI indépendants connectés à un seul PHY USB 3.0 et un seul PHY USB 2.0, deux contrôleurs de caméra MIPI CSI-2 et deux contrôleurs d’affichage MIPI DSI connectés à deux PHY transceivers MIPI DPHY à 4 voies partagées, et un contrôleur d’accès média (MAC) intégré pour l’Ethernet Gigabit​​​​.
6. Compatibilité et évolution : Le RP1 maintient la compatibilité avec la gamme de fonctions offerte sur le Raspberry Pi 4 Model B, tout en permettant une évolution vers des processus de géométrie réduite, sans avoir à reproduire tous les éléments analogiques du système. Cela pourrait permettre à changer plus facilement de fournisseur de SoC.

Évolution des performances

Afin de permettre de mieux visualiser les évolutions des performances Alasdair Allan a fait un benchmark complet dont certains éléments sont repris ici.

Tout d’abord une analyse des performances du CPU avec geekbench. Les Figures 1 et 2 montrent une augmentation des performances en single core d’approximativement 2.2x,

Figure 1. : Comparaison des performances single core entre RPi4 et 5

Figure 2. : Comparaison des performances multi core entre RPi4 et 5

Compilation de différents benchmarks entre RPi 4 et 5

Benchmark	Unités	Raspberry Pi 4	Raspberry Pi 5	Augmentation de Performance
Sysbench Mono-Thread	MBps	699	1041	x1,49
Sysbench Multi-Thread	MBps	2794	4165	x1,49
Stress-ng Mono-Thread	op/s	104,78	182,68	x1,74
Stress-ng Multi-Thread	op/s	413,12	737,21	x1,78
Bzip Mono-Thread	secondes	44,98	20,53	x2,19
Bzip Multi-Thread	secondes	28,59	14,36	x1,99
Gimp Redimensionner	secondes	67,01	29,95	x2,24
Gimp Rotation	secondes	77,24	32,77	x2,36
Gimp Niveaux Auto	secondes	80,52	34,64	x2,32
Gimp Masque Flou	secondes	115,16	49,71	x2,32
Speedometer 2.1	score	20,5	62,5	x3,05
Glmark2	score	97	202	x2,08
Openarena Timedemo	FPS	8,77	27,05	x3,08
RAMspeed Écriture	MBps	4391	29355	x6,69
RAMspeed Lecture	MBps	5902	27931	x4,73
HDparm Lecture	MBps	43,81	90,05	x2,06
dd Écriture	MBps	34,49	61,23	x1,78
Iozone 4 K Écriture RAND	MBps	9,38	15,22	x1,62
Iozone 4 K Lecture RAND	MBps	4,71	4,6	x0,98
Temps de démarrage	secondes	33,4	19,1	x1,74

performances des I/O

La Figure 3. issue du travail d’Adafruit permet de mettre à jour le graphique sur la vitesse performance de la commutation des I/O proposé dans la dépêche sur la RPi4. La Figure 4. quant à elle montre une légère amélioration de la performance par Watt sur le nouveau modèle.

Figure 3. Évolution de la vitesse de commutation d’une sortie numérique

Figure 4. Évolution de la performance en fonction de la puissance électrique

Interfaces USB et Ethernet

— Interfaces: Le RP1 fournit deux interfaces USB 3.0 et deux interfaces USB 2.0, ainsi qu’un contrôleur Ethernet Gigabit.
— Source: Circuit Digest – The New Raspberry Pi 5 is here

Le Gigabit Ethernet fourni par le RP1 est en tout point semblable à celui du RBPi4 (voir : RP1 : the silicon controlling Raspberry Pi 5:

Liam 13:21: So we’ve got the Ethernet MAC but not the PHY. So the Ethernet’s brought out to an RGMII interface, which then connects to an on-board Ethernet PHY.

Eben 13:35: And this is a fairly similar architecture to Raspberry Pi 4, except that in that case, the MAC was in the Broadcom device, but there was still an external – in fact exactly the same external – PHY, [BCM]54213. Cool. So that’s the overall structure of the design.

Interfaces MIPI CSI/DSI

Ces interfaces d’entrée/sortie vidéo peuvent être qualifiées d’historiques dans l’écosystème RaspberryPi puisqu’elles sont présentes depuis la version 1. Le RBPi5 apporte toutefois une nouveauté assez remarquable par rapport à ses prédécesseurs : au lieu d’avoir un port CSI (pour une caméra) et un port DSI (pour un écran), les ports du RBPi5 peuvent être configurés pour l’une ou l’autre fonction. Malheureusement, cela s’est traduit par des changements notables au niveau de la disposition des composants sur la carte, qui ne sont pas sans susciter quelques grincements de dents parmi les utilisateurs.

Les points discutables/discutés

Le réarrangement de la carte

— Le port audio a disparu, pour laisser sa place au port MIPI DSI (qui peut faire CSI à présent), lui-même remplacé, au-dessus du lecteur de carte microSD, par un connecteur FPC exposant les lignes PCIe.
— le port DSI est passé de 15 pins à 22 pins (comme sur la carte CMIo4)
— Et, encore une fois, les ports Ethernet et USB ont été inversés.

Si cela ne pose pas de problèmes particuliers pour un utilisateur lambda, de nombreux projets basés sur les cartes RasperryPi à la recherche de performance de calcul (et donc potentiellement intéressés par ce nouveau RBPi5) doivent entièrement revoir la conception de leur matériel.

Le non réarrangement de la carte

C’est un reproche que l’on peut trouver dans de nombreux témoignages : mettre un HAT (carte d’extension) sur un RBPi, juste au dessus du CPU, c’est un non-sens en termes de refroidissement (et ce, quelle que soit la version du RBPi).
Mais, pour relativiser, on peut dire la même chose de quasiment toutes les autres solutions alternatives au RBPi.

Les limites du format carte de crédit

Ce format (86x56 mm) est devenu une référence pour presque tous les acteurs du monde des SBC. Et donc, il s’agit là aussi d’un constat plus général, non spécifiquement adressé à RaspberryPi. Mais sachant que ce sont les locomotives du marché, peut être pourraient-ils initier une nouvelle approche…
Certes, ce format permet d’élaborer des solutions compactes, mais l’on peut constater :

— qu’augmenter la puissance et les fonctionnalités des puces embarquées tout en restant sur ce format conduit à un gaspillage inutile de ressources : il est en effet impossible d’implémenter toutes les fonctionnalités matérielles proposées par les puces sur une si petite surface, et par ailleurs il devient difficile de refroidir efficacement le système.
— pour exposer le port PCIe, RaspberryPi a supprimé le port audio, déplacé le port DSI ; mais pour alimenter le bouzin, il vous faut du 5V 4A. Ensuite un peu tout le monde se trouve planté là : débrouillez-vous.

Hyprland est un compositeur Wayland pavant (tiling) créé par Vaxri et placé sous licence BSD 3-Clause. Si vous n’avez aucune idée de ce que cela signifie, un compositeur inclut des fonctionnalités de gestion de fenêtres. D’autres compositeurs Wayland incluent GNOME, KDE et ceux basés sur wlroots.

Plus de détails dans la suite de la dépêche.

Sommaire

• Gestion des fenêtres
• Configuration, doc, outils
• Aspects techniques, conclusion
• Conclusion
• Commentaires du journal

Avant Hyprland, Vaxri avait créé Hypr, qui fonctionnait sous Xorg et utilisait XCB, tout en adoptant une philosophie similaire en matière de gestion des fenêtres. Revenons à Hyprland : c’est un « compositeur moderne avec du style » pour traduire leur formulation. La dernière version est la v0.47.2 (une mise à jour mineure), la v0.47 datant de janvier 2025. Il existe des paquets officiels pour Arch et NixOS, mais le site fournit des instructions pour l’installer ailleurs. Je l’ai testé sur Arch, j’ai voulu me faire une idée et j’ai trouvé que ça valait le coup de partager l’expérience (NdM: « Je » est l’auteur du journal, saltimbanque).

Notez que Hyprland est principalement un compositeur avec des fonctionnalités de gestion des fenêtres, mais pas un environnement de bureau complet. Plus de détails sur ça plus tard.

D’après le site officiel : « Hyprland fournit les dernières fonctionnalités de Wayland, un tiling dynamique, de nombreux effets visuels, des plugins puissants et bien plus, tout en restant léger et réactif ». Sans surprise, son créateur apprécie tout ce qui touche à l’esthétique graphique.

Ah, l’apparence !… a probablement beaucoup contribué à faire connaître Hyprland. D’après les sondages du créateur, r/unixporn a été l’un des principaux vecteurs de sa popularité. J’aime aussi, dans une certaine mesure, les effets visuels et j’apprécie l’effort fait en ce sens : de beaux espacements, des bordures, des animations. Nous avons tous joué avec Compiz quelques minutes… avant de le jeter à la poubelle car ça ne sert à rien. Heureusement, Hyprland ne se limite pas à l’esthétique et lorsque nous travaillons quotidiennement sur un ordinateur, nous pouvons apprécier son autre atout : la configurabilité. Vous pouvez utiliser plusieurs fichiers de configuration ou un seul, mais tout passe par fichier texte.

Petit détail : modifiez le fichier texte de config, enregistrez-le et votre configuration se recharge automatiquement à chaud. Simple détail, mais agréable. Si vous faites une erreur de syntaxe, un bandeau apparaîtra et affichera les erreurs qui empêchent le rechargement. Il vous suffira alors de corriger et de sauvegarder à nouveau.

Gestion des fenêtres

Pour comprendre la personnalisation, il faut d’abord comprendre les bases. Hyprland est un gestionnaire en mosaïque. Par défaut, il utilise la mise en page (layout) “Dwindle”, qui était déjà utilisé par le gestionnaire de fenêtres BSPWM. La description la plus courte de ce layout serait : « Pensez Fibonacci ! »

Bon appliqué à des fenêtres… voilà un extrait du README de BSPWM

                     a                          a                          a
                    / \                        / \                        / \
                   1   b         --->         1   c         --->         1   d
                      / \                        / \                        / \
                     2   3                      4   b                      5   c
                     ^                          ^  / \                     ^  / \
                                                  3   2                      b   4
                                                                            / \
                                                                           3   2

         +-----------------------+  +-----------------------+  +-----------------------+
         |           |           |  |           |           |  |           |           |
         |           |     2     |  |           |     4     |  |           |     5     |
         |           |     ^     |  |           |     ^     |  |           |     ^     |
         |     1     |-----------|  |     1     |-----------|  |     1     |-----------|
         |           |           |  |           |     |     |  |           |  3  |     |
         |           |     3     |  |           |  3  |  2  |  |           |-----|  4  |
         |           |           |  |           |     |     |  |           |  2  |     |
         +-----------------------+  +-----------------------+  +-----------------------+

                     X                          Y                          Z

Un autre layout standard est “Master”. Vous pouvez modifier votre fichier de configuration pour l’utiliser à la place ou même assigner une touche pour basculer entre eux. Le layout Master fonctionne avec une fenêtre occupant la moitié de l’écran, tandis que les autres s’empilent sur l’autre moitié. Vous pouvez également changer la fenêtre maîtresse.

Bon cette fois partageons les GIF enragés du wiki de Hyprland :

Hyprland offre aussi des fonctionnalités de gestion des fenêtres, communes aux différents layouts :

• plusieurs espaces de travail (avec placement manuel ou automatique des fenêtres),
• un espace de travail spécial,
• un système de “groupement”, permettant de regrouper et dégrouper des fenêtres,
• mode plein écran,
• fenêtres flottantes.

Hyprland propose aussi un système de plugins. Et devinez quoi, un plugin a été développé pour ajouter le layout de i3 (i3 étant un WM pavant sous Xorg, dont l’équivalent sous Wayland est Sway, qui est dév. par Drew DeVault). Ce plugin s’appelle hy3. Dans i3, il y a des conteneurs, en gros c’est un layout « manuel avec des découpages horizontaux/verticaux, très simple et efficace, et la doc i3 est très bien. Parce que la doc Sway, ce sont juste des man page, ok c’est très bien aussi passons… Bref, voilà, maintenant j’ai un compositeur i3 avec des gaps et de belles animations, vous vous souvenez de i3-gaps – qui a entre-temps été intégré à i3 ? Bref, hy3 c’est ça en mieux.

Configuration, doc, outils

Notez que d’autres plugins existent, pour les animations, pour changer des comportements. La communauté pourrait être un bel axe de développement maintenant que d’après l’auteur le code se calme.

À un moment un gestionnaire de plugins a été ajouté, hyprpm (pm pour package manager je suppose). Alors j’ai essayé d’installer hy3 avec, mais j’ai rencontré des soucis de versions me rappelant le bon vieux temps où les dév. de plugins gnome-shell hurlaient comme des putois quand une nouvelle version sortait. Bon bref j’ai compilé hy3 à la main à la place, mais sortez cpp et une bonne tasse de café, c’est pas juste un script Emacs en Lisp qui prend 3 secondes. Mais au moins ça a bien marché.

Sinon la configuration permet de personnaliser le layout clavier, la résolution d’écran, l’esthétique et les animations. Beaucoup de possibilités, par ex. pour les raccourcis on peut faire des “submap” (oui je sais, i3 aussi). On peut modifier plein de choses sans redémarrer.

On peut aussi utiliser la commande hyprctl pour communiquer avec hypr.

Côté documentation, l’API technique est très bien couverte, mais il manque une documentation simplifiée pour une prise en main rapide. Et puis de base ne vous attendez pas à plein de raccourcis claviers pré-configurés, vous allez devoir faire les vôtres.

Ou alors vous pouvez aussi utiliser des configurations préexistantes. On se croirait dans Doom Emacs !

Hyprland n’est pas un environnement de bureau complet. Il vous faudra un tableau de bord, un lanceur d’applications et d’autres outils. Quelques options populaires :

• barre d’état : Ashell (prêt à l’emploi) ou Waybar (très personnalisable). A noter qu’il y a maintenant des mini libs pour se faire ses barres facilement comme quickshell, astal ;
• lanceur d’applications : Wofi (simple, clavier + souris) ;
• ou le fait d’utiliser un tiling peut même vous donner envie de changer de terminal ? Foot, Kitty, Alacritty, etc.

Mais Awesome Hyprland vous listera bien plus de choses.

Je n’ai pas encore testé ibus, et je sais que je vais rencontrer des soucis avec cela, comme j’en aurai sous Sway… (Pas trop envie de passer sous fcitx mais on verra)

Aspects techniques, conclusion

Au cours du développement de Sway, Drew Devault a conçu une bibliothèque, wlroots, qui est devenue indépendante de Sway et utilisée par d’autres compositeurs wayland.

Hyprland a démarré en 2022. En 2024, la dépendance à wlroots, qui était inclus sous forme de « submodule git », a été abandonnée au profit de Aquamarine, un moteur de rendu en C++. L’abandon de wlroots, d’après l’auteur, tient au fait que

• wlroots est en C,
• wlroots manque de doc,
• faire évoluer wlroots prend du temps,
• et accessoirement parce qu’il a été banni ! (Bon là désolé je préfère passer du temps sur la revue de Hyprland que sur les feux de l’amour, voyez ici).

Mais Aquamarine n’est pas un compétiteur de wlroots.

Conclusion

Hyprland, comme d’autres, ça prend un max de temps à s’approprier. Il faut lire et configurer à tout-va, même si après-coup on se rend compte que c’était simple. Ce qui l’est moins, c’est de choisir sa manière de travailler.

J’adore jouer avec les gestionnaires de fenêtre en mosaïque et Hyprland est une belle découverte. J’avais peur d’un simple ensemble d’animations flashy, mais il offre bien plus que cela. J’aimerais voir un tableau de bord style “Activités” de GNOME pour visualiser toutes les fenêtres et espaces de travail en un coup d’œil. Peut-être qu’avec le temps, quelqu’un développera cette fonctionnalité… ou alors je finirai par coder un petit quelque chose moi-même ! j’ai déjà remarqué que quelqu’un a codé « hot corner », surprenant pour un tiling!

Commentaires du journal

Sources 1 et 2

• multi-écran possible
• définition des raccourcis et des règles.

Cloonix est un outil d’aide à la construction de réseau virtuel, sous AGPLV3 (inclus qemu-kvm, openvswitch, spice, crun et wireshark).

C'est pensé comme Docker, dont le succès provient de l'absence de tracasseries au moment de l'empaquetage, en mettant bibliothèques et binaires dans un espace de nommage (namespace). Docker est un produit de grande qualité mais il n'y a pas que sa méthode. Cloonix utilise les mêmes principes de namespace, sans infrastructure d'accueil pour faire tourner les conteneurs. Notez qu'un logiciel qui s'installe puis tourne avec les droits limités d'un utilisateur normal est la meilleure façon de décourager un pirate. Donc, pour essayer Cloonix 46, un fichier auto-extractible sans dépendance à la distribution qui l'héberge vous attend ! Téléchargez, cliquez…

Cloonix est un outil pour étudier les réseaux. Il permet de faire des scripts de scénarios avec plusieurs machines connectées, les machines étant soit des vraies machines virtuelles tournant avec kvm, soit des conteneurs tournant avec crun. Cette maquette simplifiée de réseaux avec leur visualisation permet de transmettre des démonstrations réseaux entre utilisateurs. J'ai présenté Cloonix plus largement dans mes dépêches précedentes.

ATELIER du lundi 31 mars de 11h30 à 13h30 à Paris (participation en ligne possible).

Etes-vous prêts pour les échéances de 2026 et 2027 du Cyber Resilience Act (CRA) ?

Le CRA est un dispositif adpoté par la Commission Européenne en 2024 pour répondre à la vulnérabilité accrue aux cyberattaques des entreprises et services publics européens,. Il vise à renforcer la cybersécurité et la cyberrésilience des produits logiciels (et matériels qui comportent des éléments numériques) connectés.

Le premier guide de conformité au CRA dédié aux acteurs de l’open source, proposé par le CNLL et inno³ a pour objectif de faciliter la compréhension du CRA et les effets attendus, et de proposer des recommandations concrètes.

N'attendez pas pour commencer à évaluer vos obligations nouvelles à venir et les adaptations nécéssaires de vos processus, rejoignez l'atelier du 31 mars !

📅 Quand ? Le 31 mars de 11h30 à 13h30, la rencontre sera suivie d'un buffet pour les personnes sur place.

📍 Où ? 137 Boulevard de Magenta 75010 Paris (nombre de places limité, participation en ligne possible).

L'objectif est de rendre la session de discussion la plus active possible, n'hésitez pas à lire d'un œil critique et intéressé le guide en amont. Vous pouvez même nous envoyer dès aujourd'hui vos diverses questions ou remarques afin de nous aider à préparer l'atelier : mission-cra-cnll@framagroupes.org.