Pour cette journée Ada Lovelace, on vous invite à la conquête de l’espace, une histoire qui n’aurait peut-être pas pu se faire sans les femmes. Pas uniquement parce que ce sont des femmes : les anonymes qui ont tressé les mémoires en tore de ferrite des missions Apollo, ou les plus connues qui ont voyagé dans l’espace. Mais aussi parce qu’elles ont calculé ou codé les explorations spatiales. Et comme c’est un sujet vaste, il s’agit, pour l’instant, de la première partie consacrée à trois femmes afro-américaines qui ont travaillé au NACA puis à la NASA : Dorothy Vaughan (1910 – 2008), Katherine Johnson (1919-2020) et Mary Jackson (1921 – 2005). Les portraits de ces trois femmes sont précédés d’une chronologie de la conquête de l’espace.

Sommaire

• Préambule
• La conquête de l’espace en quelques dates
• Le NACA (National Advisory Committee for Aeronautics, en français, Comité consultatif National pour l’Aéronautique), prédécesseur de la NASA
• Dorothy Vaughan (1910 – 2008), mathématicienne et informaticienne
• Katherine Johnson (1918 – 2020), la calculatrice humaine
• Mary Jackson (1921 – 2005), l’ingénieure
• Remarques incidentes

Préambule

La journée Ada Lovelace (en) (Ada Lovelace Day ou ALD en anglais) est une journée internationale consacrée aux réalisations des femmes en science, technologie, ingénierie et mathématiques (STIM ou STEM en anglais). Elle a lieu le deuxième mardi du mois d’octobre. En 2023, cette journée avait été, pour LinuxFr.org, l’occasion d’évoquer Lorinda Cherry, membre de l’équipe de conception d’Unix, Evi Nemeth et la première hackeuse Judith Milhon. Et c’est, on l’aura peut-être compris, surtout un prétexte pour parler de l’histoire de l’informatique.

Cette dépêche et sa suivante sont malheureusement américano-centrées. Et ce pour la bonne et simple raison que, s’il est facile de trouver de l’information sur les cosmonautes russes, en trouver sur les informaticiennes est beaucoup plus ardu. En fait, on n’en a pas trouvé d’autre que Rozetta Zhilina (en), 1933 – 2003, qui a plutôt travaillé dans un contexte militaire et dont la spécialité était les algorithmes en balistique et Ekaterina Samoutsevitch, née en 1982, membre du groupe de punk-rock féministe les Pussy Riot. C’est d’autant plus regrettable que l’URSS avait une réelle avance en matière de conquête de l’espace. Avance que la Russie a toujours sur certains points. Par exemple, le côté russe de la station spatiale internationale a des toilettes prévues pour que les femmes puissent avoir leur règles et changer ainsi leurs protections hygiéniques.

Les portraits des trois femmes qui figurent ci-dessous peuvent sembler assez idylliques. Dans la réalité elles ont dû affronter beaucoup de difficultés du fait de leur groupe ethnique et de leur genre : méprisées par les hommes blancs, peu valorisées, Dorothy Vaughan n’aura pas eu la promotion à laquelle elle pouvait prétendre du fait de ses fonctions, Mary Jackson verra sa carrière bloquée, et souvent pas assez outillées pour leur travail. Par exemple, Katherine Johnson n’aura pas toujours accès à l’intégralité des données dont elle avait besoin dans le cadre de son travail pour le « SpaceTask Group ».

Les portraits des femmes seront donnés dans l’ordre chronologique de leur naissance.

La conquête de l’espace en quelques dates

La conquête de l’espace a été d’abord marquée par la lutte entre les deux grands blocs : Est contre Ouest, la « Course à l’espace » (Race for Space en anglais). La Russie soviétique ayant conservé pendant plusieurs années son avance sur les USA. Une chronologie qui s’arrête à la fin du programme Apollo et qui est centrée sur les réalisations des deux géants.

Un rendu un peu plus visuel des dates qui sont données ci-après, la Russie est dans la colonne de gauche, les USA dans celle de droite. Le document est téléchargeable au format fichier pdf hybride et nettement plus lisible.

1957 : la Russie envoie dans l’espace le Spoutnik 1, premier satellite artificiel en octobre. En novembre c’est la chienne Laïka qui s’envole, c’est le premier animal vivant à réaliser une orbite dans l’espace.

1958 : création de la NASA.

1960 : les deux chiennes, Belka et Strelka que la Russie soviétique avait envoyées dans l’espace reviennent vivantes de leur vol orbital, ainsi que le lapin et les souris qui les accompagnaient.

1961 : en janvier, la NASA envoie le chimpanzé Ham accomplir un vol orbital. En avril c’est le Russe Youri Gagarine qui s’envole et devient le premier homme à avoir accompli un voyage dans l’espace, ainsi que la coqueluche des foules. Dix mois après les Russes, le 20 février 1962, les USA envoient John Glenn pour accomplir un vol orbital. La même année, en décembre, la sonde Mariner 2 survole Vénus. Le Royaume-uni et le Canada envoient leur premier satellite en orbite.

1963 : la cosmonaute russe Valentina Terchkova est la première femme à aller dans l’espace et, à ce jour, la seule à y avoir effectué une mission en solo. Le 18 mars 1965, le cosmonaute soviétique Alexeï Leonov effectue la première sortie dans l’espace. En juillet, la sonde américaine Mariner 4 survole Mars. La même année, la France lance la fusée-sonde LEX, l’Italie un satellite. La sonde russe Luna 9 se pose sur la Lune le 3 février 1966. Luna 10, quant à elle, se placera en orbite autour du satellite de la Terre.

1968 : septembre dans le cadre de la mission russe Zond 5, un vaisseau habité par des tortues survole la lune. Décembre, c’est au tour de la NASA d’envoyer un vaisseau habité vers la lune. Elle envoie un équipage en orbite lunaire, mission Apollo 8.

Juillet 1969 : tandis que les Russes lancent leur première navette spatiale, BOR-2, elle servira au programme Bourane, la mission Apollo 11 envoie Neil Armstrong et Buzz Aldrin sur la Lune.

1971 : en avril, les Russes lancent Saliout 1, première station spatiale habitée. En novembre, la sonde américaine Mariner 9 orbite autour de Mars. En décembre, la sonde russe Mars 3 se pose en douceur sur Mars.

1972 : Apollo 17 dernière mission lunaire du programme Apollo. La conquête de l’espace entre dans une autre phase peu après.

Le NACA (National Advisory Committee for Aeronautics, en français, Comité consultatif National pour l’Aéronautique), prédécesseur de la NASA

Le NACA est une agence fédérale états-unienne créée en 1915.

Comme son nom le suggère, l’objectif du NACA était de favoriser la recherche en aéronautique, un secteur qui commençait à se développer et sur lequel les États-Unis étaient en retard par rapport à l’Europe. Le centre de recherche Langley du NACA était basé à Hampton en Virginie. Dans cette Amérique ségrégationniste, les zones de travail entre Blancs et Noirs sont séparées, celle de l’unité de calcul de la zone ouest (West Area Computing Unit) étant réservées aux personnes afro-américaines où travailleront les trois héroïnes de cette dépêche. Quand le NACA disparaîtra en 1958 pour faire place à la NASA, les secteurs raciaux disparaîtront également et il n’y sera plus fait, sur le plan des locaux, de distinction entre les personnes selon leur couleur de peau ou selon leur sexe.

On doit au NACA (et peut-être même en partie à Mary Jackson) un type de prise d’air la prise d’air NACA qu’on verra par la suite sur à peu près toutes les voitures à partir de 1956.

Dorothy Vaughan (1910 – 2008), mathématicienne et informaticienne

Dorothy Vaughan naît en 1910. Elle obtient un Bachelor of Arts (l’équivalent d’une licence) de mathématique à l’université de Wilberforce (Ohio) en 1929, elle a dix-neuf ans. À la suite de ça, elle va enseigner les mathématiques dans un lycée afro-américain de Farmville (Virginie).

Arrive la deuxième guerre mondiale, le gouvernement états-unien fait appel aux travailleurs et travailleuses pour soutenir l’effort de guerre, le NACA recrute. Elle candidate au poste de « calculateur » à Langley. Elle est recrutée en décembre 1943 et affectée à l’unité de calcul de la zone ouest dont l’objet était de faire des calculs mathématiques pour les ingénieurs qui se livraient à des expériences aéronautiques. Pour cela, point d’ordinateur (le premier ordinateur reconnu comme tel date de 1942), mais des règles à calcul, des calculatrices mécaniques (merci Pascal), et le visionnage de films. Elles fournissaient ainsi aux ingénieurs les paramètres techniques en matière de vol et de soufflerie.

Au départ, les chefs de sa section seront des hommes, blancs. Finalement, elle sera promue à la tête de l’unité informatique de la zone ouest qu’elle dirigera de 1949 à 1958. Elle aura été la première femme afro-américaine à diriger un département du NACA tout en étant une mathématicienne aux compétences respectées. Il arrivait ainsi qu’on lui demande personnellement d’effectuer certains calculs complexes. Pendant cette période, elle co-écrira avec deux autres mathématiciennes, Sara Bullock et Vera Huckel, un manuel de méthodes algébriques pour les machines à calculer utilisées dans le groupe. Elle participera à la « Course à l’espace », cette période où les USA et l’URSS luttaient pour avoir la suprématie dans le domaine spatial.

Arrive 1958, le NACA est dissout remplacé par la NASA. Elle rejoint le « Numerical Techniques Branch » (section des techniques numériques) et acquiert une expertise en FORTRAN. Elle contribuera au programme de développement des lanceurs de fusée Scout. Elle continuera pendant toute sa carrière à apprendre les nouvelles technologies informatiques. Elle formera d’ailleurs ses collègues à ces disciplines.

Elle quitte la NASA en 1971.

Après sa mort, survenue en 2008, elle reçoit à titre posthume la Médaille d’or du congrès pour son travail pour la NASA.

Katherine Johnson (1918 – 2020), la calculatrice humaine

Katherine Johnson est née en 1918. Elle fait ses études au West Virginia State College, qui deviendra l’université d’État de Virginie occidentale (West Virginia State University). Elle en sort en 1937 avec un diplôme de mathématiques et de français. Elle intègre en 1939, avec deux autres étudiants afro-américains, l’université de Virginie occidentale qui accueille ainsi ses tout premiers étudiants afro-américains. Elle obtiendra un doctorat (PhD) de mathématiques.

Elle est recrutée en juin 1953 par le NACA où elle intègre la section de calcul de Langley. Elle fait partie des calculateurs humains noirs dans cette Amérique qui pratique encore la ségrégation raciale, plus précisément des calculatrices car la section était purement féminine. Deux semaines après son entrée en fonction, Dorothy Vaughan l’assigne à un projet dans la branche des charges de manœuvre (Maneuver Loads Branch) de la division des Recherches en vol (the Flight Research Division) pérennisant ainsi son poste. Elle effectuera toute sa carrière à la NASA qu’elle quittera en 1986.

L’année 1957 est une année charnière dans sa carrière et dans la conquête l’espace : la Russie, on l’a vu, y envoie le Spoutnik 1, premier satellite artificiel d’une famille de dix qui marque le début de la « course à l’espace ». Elle fournit une partie des calculs des « Notes on Space Technology (en) » de 1958. Ces notes font partie d’un cours de technologie spatiale donné à la division des Recherches en vol du NACA. Elle intègre ainsi le « SpaceTask Group » (groupe de travail de l’espace). Quand le NACA sera dissout pour faire place à la NASA, elle suivra naturellement le chemin.

Elle effectuera les analyses de trajectoire pour la capsule spatiale Freedom 7 d’Alan Shepard en mai 1961, premier Américain dans l’espace pour un vol suborbital. En 1960 elle co-écrit avec l’ingénieur Ted Skopinski la note technique « Determination of Azimuth Angle at Burnout for Placing a Satellite Over a Selected Earth Position (en) » qui expose les équations décrivant un vol spatial orbital dans lequel la position d’atterrissage du vaisseau spatial est spécifiée. Elle sera la première femme de la division des Recherches en vol du NACA à être créditée comme auteur.

En 1962, préparation du vol orbital de John Glenn : elle est appelée à y participer. C’est une opération complexe, qui entraîne des calculs complexes eux aussi. Les ordinateurs étaient programmés pour contrôler la trajectoire de la capsule Friendship 7. Cependant, les astronautes étaient réticents à l’idée de confier leur vie à des machines susceptibles de tomber en panne ou de subir des coupures de courant.

Dans le cadre de la liste de contrôle avant le vol, Glenn avait demandé aux ingénieurs de « demander à la fille » (Johnson) d’exécuter les mêmes nombres dans les mêmes équations que celles programmées dans l’ordinateur, mais à la main, sur sa machine à calculer mécanique de bureau. « Si elle dit qu’ils sont bons », se souvient Katherine Johnson, « alors je suis prêt à partir ». Le vol de Glenn fut un succès et marqua un tournant dans la compétition entre les États-Unis et l’Union soviétique dans l’espace.¹

Elle aura aussi calculé la synchronisation du module lunaire d’Apollo 11 avec le module de commande et de service en orbite lunaire, ce qu’elle considérait comme sa plus grande contribution à la conquête de l’espace. Elle a travaillé aussi sur les navettes spatiales (Space Shuttle) et sur le programme d’observation de la Terre à des fins civiles Landsat (en).

En 2015, Barack Obama la décore de la plus haute décoration américaine : la médaille présidentielle de la Liberté.

Mary Jackson (1921 – 2005), l’ingénieure

Mary Jackson naît le 9 avril 1921 à Hampton, Virginie où elle passera toute sa vie. En 1942 elle obtient un BS en mathématiques et sciences physiques au Hampton Institute. Elle commence sa carrière professionnelle comme ses deux collègues en tant qu’enseignante dans un établissement d’enseignement pour enfants noirs. Après d’autres emplois (réceptionniste, comptable, secrétaire militaire), elle est embauchée par le NACA et rejoint la section de calcul de la zone ouest en 1951 dirigée par Dorothy Vaughan.

Deux ans après, elle reçoit une proposition de travail pour l’ingénieur aéronautique Kazimierz Czarnecki (en) (qui a un homonyme polonais et althérophile) sur la soufflerie supersonique. Il lui suggère de suivre une formation pour devenir ingénieure. Ce qu’elle fera avec succès, non sans avoir eu à obtenir une autorisation spéciale de la ville de Hampton pour suivre les cours car ils se déroulaient dans l’école secondaire, blanche, de la ville. Elle deviendra la première ingénieure afro-américaine de la NASA en 1958. Elle écrira aussi, avec Czarnecki, cette même année « Effects of Nose Angle and Mach Number on Transition on Cones at Supersonic Speeds » (en). Dans ses fonctions d’ingénieure aérospatiale, son travail portera sur l’analyse des données des expériences en souffleries et en vol à des vitesses supersoniques.

De 1958 à 1975, elle aura écrit en tout douze documents techniques pour le NACA et la NASA.

Elle change d’orientation en 1976 (avec diminution de salaire), sa carrière étant bloquée pour œuvrer en faveur de l’embauche et de la promotion de la nouvelle génération d’ingénieures, de mathématiciennes et scientifiques de la NASA. Elle prendra sa retraite en 1985. Mary Jackson meurt le 11 février 2005.

Le siège de la NASA à Washington DC est rebaptisé a sa mémoire en 2020 et s’appelle désormais le « Mary W. Jackson NASA Headquarters ».

Remarques incidentes

Les trois femmes ainsi portraiturées ont fait l’objet d’un film sorti en 2016 : «Hidden Figures » (Les Figures de l’ombre). Dans les pages qui leur sont consacrées sur le site de la NASA (en), le nom de l’actrice associée à chaque rôle dans le film est ajouté. Je me suis beaucoup inspirée de ces pages d’ailleurs. Il y a aussi, probablement, dans tout cela une excellente affaire de marketing dont on n’a pas l’équivalent pour la Russie qui a une histoire politique plus compliquée.

Ceci n’était que le premier volet, celui des calculatrices humaines. Le prochain consacrera une partie à l’environnement informatique, tant aux USA qu’en Russie. Il y aura aussi des portraits de femmes (américaines, mais si vous avez des noms et des liens d’informaticiennes russes à suggérer…) dont, évidemment Margaret Hamilton.

Cette dépêche ne saurait se terminer sans remercier vmagnin et Benoît Sibaud d’avoir pensé à mes longues soirées d’automne en m’ouvrant d’autres portes parce qu’en fait ce texte aurait dû n’être qu’en une seule partie et plus court.

Les deux parties précédentes ont présenté les principales évolutions dans le code de Haiku. Mais le code ne fait pas tout.

Cette troisième (et dernière) partie présente les nouveautés dans la documentation, ainsi qu’un court aperçu du rapport financier et aux dons qui permettent à Haiku d’employer un développeur à plein temps de façon durable.

Enfin, elle présente la participation au Google Summer of Code et les travaux réalisés par les cinq étudiants encadrés par Haiku cette année.

Sommaire

• Documentation
  • Documentation d’API
  • Documentation interne
• Un point sur le financement
• Google Summer of Code
  • Calisto Mathias — Re-design de la fenêtre de recherche de fichiers
  • Daniel Martin — Virtualisation matérielle accélérée avec NVMM
  • Diego Roux — Pilote pour les cartes sons virtuelles VirtIO
  • trungnt2910 — Portage de GDB
  • Zardshard — Migration du navigateur web WebPositive vers WebKit2

Documentation

La documentation de Haiku se découpe en 3 parties principales : un manuel de l’utilisateur, une documentation d’API, et une documentation interne pour les développeurs qui travaillent sur les composants du système.

Ces documents sont complétés par de nombreuses pages et articles sur le site Internet, et deux livres pour apprendre à programmer en C++ avec Haiku, ou encore un document de référence pour la conception d’interfaces graphiques et un autre pour le style graphique des icônes.

Documentation d’API

La documentation d’API de BeOS était assez complète et de bonne qualité. L’entreprise Access Co Ltd qui a hérité de la propriété intellectuelle de BeOS a autorisé le projet Haiku à la réutiliser et à la redistribuer. Malheureusement, cette autorisation est faite avec une licence Creative Commons n’autorisant pas les modifications. Cette documentation ne peut donc pas être mise à jour, ni pour corriger les erreurs, ni pour ajouter des informations sur toutes les nouvelles fonctions ajoutées par Haiku ou les différences entre les deux systèmes.

Il est donc nécessaire de réécrire une nouvelle documentation à partir de zéro. Ce travail est assez ingrat lorsqu’il s’agit de re-décrire ce qui est déjà très bien expliqué dans la documentation existante. La nouvelle documentation a donc tendance à se concentrer sur les nouvelles fonctions, et il faut souvent jongler entre les deux documentations, le contenu des fichiers .h, et des exemples de code d’applications existantes pour découvrir toutes les possibilités offertes.

Il ne semble pas utile de lister chaque fonction ou méthode qui a été documentée. On peut mentionner une page d’explications sur la bibliothèque C standard, comprenant des liens vers les spécifications POSIX qui documentent déjà la plupart des choses, et quelques détails sur les différences avec d’autres systèmes.

Une autre nouvelle page documente les primitives de synchronisation qui sont disponibles pour le code s’exécutant dans le noyau.

Documentation interne

La documentation interne était à l’origine simplement une accumulation de fichiers dans divers format dans un dossier « docs » du dépôt Git de Haiku. Depuis 2021, ces fichiers ont été rassemblés et organisés à l’aide de Sphinx, qui permet de mettre à disposition une version navigable en HTML et de donner une meilleure visibilité à ces documents.

D’autres pages sont petit à petit migrées depuis le site web principal de Haiku, qui n’est pas un très bon support pour de la documentation, et bénéficiera un jour d’une refonte pour être plus tourné vers les utilisateurs que vers les développeurs.

Quelques nouvelles pages ajoutées cette année:

• Une documentation sur l’utilisation de divers outils de complétion de code automatique avec le code source de Haiku
• Une page présentant l’organisation du code source et les principaux dossiers et sous-dossiers
• La documentation de l’outil rc utilisé pour compiler les « resources » attachées aux exécutables a été intégrée
• Le système de fichier FAT a reçu également une page de documentation à l’occasion de sa réécriture

Un point sur le financement

L’association Haiku inc qui gère le compte en banque de Haiku publie chaque année un rapport financier.

Le financement provient principalement de dons des utilisateurs et soutiens de Haiku. Le projet reçoit également une compensation financière de Google pour le temps passé à encadrer les participants du Google Summer of Code (voir le paragraphe suivant). La contribution de Google cette année est de 3 300$.

Les plateformes de don les plus utilisées sont Paypal et Github sponsor. Ce dernier est recommandé car, pour les dons reçus via Github, c’est Microsoft qui paie les frais bancaires de la transaction. 100% de l’argent donné arrive donc sur le compte de Haiku. Tous les autres opérateurs ont un coût, soit fixe lors des retraits, soit un pourcentage de chaque don, soit un mélange des deux.

En 2023, l’association a reçu 25 422$ de dons et a dépensé 24 750$. Elle dispose d’une réserve confortable de 100 000$ (accumulés avant 2021, alors qu’il n’y avait pas de développeur salarié) ainsi que d’environ 150 000$ en cryptomonnaies.

Les dons en cryptomonnaies sont pour l’instant bloqués sur un compte Coinbase suite à des problèmes administratifs (le compte n’est pas correctement déclaré comme appartenant à une association, il faudrait donc payer un impôt sur le revenu lors de la conversion en vraie monnaie). Il semble difficile de contacter Coinbase pour régler ce problème.

Du côté des dépenses, le poste le plus important est le paiement de 21 000$ à Waddlesplash, développeur employé par Haiku inc pour faire avancer le projet Haiku. Il travaille à temps partiel et avec un salaire très bas par rapport au marché, comme cela a été fait pour les précédents contrats entre Haiku inc et d’autres développeurs. Les finances de l’association ne permettent pas encore d’assurer un emploi à plein temps avec un salaire correct sur le long terme (c’est faisable sur le court ou moyen terme à condition de puiser dans les réserves de trésorerie).

Le reste des dépenses concerne principalement le paiement de l’infrastructure (serveurs pour le site Internet, l’intégration continue, hébergement cloud pour les dépôts de paquets) pour environ 3 000$.

Il faut enfin compter environ 500$ de frais Paypal, puis quelques dépenses administratives (déclaration de changement d’adresse de l’association, déclaration d’embauche) pour des montants négligeables (moins de 10$ au total).

En 2024, l’objectif fixé en janvier était de récolter 20 000$ de dons supplémentaires. Cet objectif a été atteint dès le mois de juillet, et a donc été révisé pour tenter d’atteindre les 30 000$. Cela permettra de rémunérer Waddlesplash pour un plus grand nombre d’heures cette année, ou bien d’envisager l’embauche d’une deuxième personne si un ou une candidate se présente parmi les personnes contribuant au projet (l’embauche d’une personne extérieure ne se fera pas tant que l’association ne peut pas se permettre de proposer une rémunération raisonnable).

Google Summer of Code

Haiku participe au Google Summer of Code depuis 2007. Il s’agit d’un programme où des étudiants (et d’autres participants pas forcément étudiants, ces dernières années) sont payés par Google pendant deux mois pour découvrir la contribution à des projets de logiciels libres.

Ce programme a été monté par « l’Open source program office » de Google. Leur intérêt est de défendre leur image d’entreprise sympathique (bien mise à mal ces dernières années, c’est devenu un géant de la publicité en ligne et de l’aspiration des données personnelles), et de contribuer à la richesse d’un écosystème de logiciels libres dont ils bénéficient beaucoup. Cela permet aussi d’encourager des personnes à s’essayer au développement logiciel, facilitant indirectement le recrutement chez Google en augmentant le nombre de candidats. Ces justifications peuvent sembler hypothétiques ou très indirectes, mais elles ont convaincu Google d’attribuer un budget de quelques millions de dollars à ce programme.

Une équipe de Google choisit les projets de logiciel libres participants parmi de nombreuses candidatures. Chaque projet participant propose une liste « d’idées » (un peu sous la forme d’un sujet de stage) et a ensuite la responsabilité de choisir parmi les candidats qui ont répondu à cette offre (en respectant les critères de non-discrimination imposées par Google ainsi que les embargos imposés par les USA), et d’assurer l’encadrement des personnes sélectionnées. Google rémunère les participants, et dédommage les projets participants pour le temps investi.

Cette année les développeurs de Haiku encadrent cinq participants :

Calisto Mathias — Re-design de la fenêtre de recherche de fichiers

Le système de fichier BFS utilisé par Haiku permet l’exécution de requêtes (comme une base de données) exploitant les attributs étendus des fichiers, qui peuvent être indexés.

Ce système permet de faire beaucoup de choses, et la fenêtre de recherche du navigateur de fichier essaie d’en tirer parti. Cependant, l’interface résultante est trop complexe, et peu de personnes prennent le temps de concevoir des requêtes améliorant leur façon de travailler, se cantonnant aux quelques exemples fournis.

L’objectif de ce projet est de refondre l’interface de cette fenêtre pour obtenir quelque chose de plus intuitif, et également d’afficher en temps réel les résultats de la requête dès qu’elle est modifiée, pour encourager les utilisateurs à expérimenter avec des requêtes plus complexes.

Daniel Martin — Virtualisation matérielle accélérée avec NVMM

Haiku n’est pas encore parfait, et certaines tâches nécessitent encore l’utilisation d’autres systèmes d’exploitation. Une partie des utilisateurs ont donc une configuration en double boot, ou bien lancent Haiku dans une machine virtuelle.

L’objectif de ce projet est de permettre d’utiliser Haiku comme système principal, et de lancer les autres systèmes dans des machines virtuelles. Cela sera réalisé à l’aide d’un portage de NVMM, qui a été développé à l’origine par NetBSD et Dragonfly BSD. Cette bibliothèque a l’avantage d’être bien documentée et conçue pour faciliter son adaptation vers d’autres systèmes.

NVMM sera complétée par l’utilisation de QEMU qui pourra fournir un « front-end » à cette mécanique.

Diego Roux — Pilote pour les cartes sons virtuelles VirtIO

Pour les personnes utilisant Haiku dans une machine virtuelle, il est intéressant d’utiliser autant que possible la famille de périphériques VirtIO.

Il s’agit de périphériques virtuels conçus sans s’inspirer de matériel existant, et plutôt pour avoir l’interface la plus simple possible entre la machine virtualisée et son hôte.

Haiku dispose déjà d’un jeu de pilote Virtio relativement complet (réseau, stockage de masse, affichage graphique). Le but de ce projet est de compléter cet ensemble avec un pilote pour les cartes son VirtIO.

trungnt2910 — Portage de GDB

Haiku dispose de son propre débugger (appelé Debugger, de façon assez peu originale). Ce dernier présente une interface graphique confortable, mais une interface en ligne de commande beaucoup plus limitée. Il souffre également de quelques problèmes de performances et d’un manque de prise en charge des fichiers exécutables et bibliothèques compilés avec autre chose que GCC. Il est également incapable de faire du debug à distance ou de s’intégrer dans une interface graphique existante (par exemple au sein d’un IDE).

L’objectif de ce projet est de ressusciter la version de GDB ciblant Haiku. Cette version très ancienne était utilisée avant l’apparition du Debugger natif. Le projet est en bonne voie, le code d’interfaçage a été entièrement réécrit pour s’adapter aux versions modernes de GDB, et plusieurs évolutions et corrections ont été intégrées dans le système de debugging de Haiku (par exemple, pour mettre en pause tous les threads nouvellement créés afin que le debugger puisse les intercepter).

Zardshard — Migration du navigateur web WebPositive vers WebKit2

Le navigateur WebPositive utilise le moteur de rendu webKit. Actuellement, il s’interface avec ce moteur via l’API WebKitLegacy. Cette API exécute tout le moteur de rendu web dans un seul processus, et ne fournit pas les garanties d’isolation nécessaires pour les navigateurs web modernes (que ce soit en termes de sécurité, ou en termes de fiabilité).

L’objectif de ce projet est de reprendre les travaux déjà entamés en 2019 pour migrer WebPositive vers la nouvelle API « WebKit2 », et bénéficier d’une séparation entre l’interface graphique, la communication réseau, et le rendu HTML/CSS/JavaScript dans des applications séparées. Ainsi, un crash d’un de ces composants peut être récupéré de façon transparente sans faire disparaître toute l’application (et les données non enregistrées de l’utilisateur avec).

Le projet est également en bonne voie, un navigateur de test permet déjà d’afficher quelques pages ce qui montre que les bases sont en place. Il reste à régler de nombreux problèmes de rendu de texte, ainsi qu’à implémenter la gestion des entrées (clavier et souris) pour avoir un navigateur web utilisable. Il faudra ensuite migrer WebPositive vers ces nouvelles APIs.

Cette revue de presse sur Internet fait partie du travail de veille mené par l’April dans le cadre de son action de défense et de promotion du logiciel libre. Les positions exposées dans les articles sont celles de leurs auteurs et ne rejoignent pas forcément celles de l’April.

• [clubic.com] Les meilleurs logiciels libres et open source en 2024
• [ouest-france.fr] Quimper. La distribution d’ordinateurs continue tout l’été au Centre des Abeilles
• [Le Monde.fr] Google condamné pour pratiques anticoncurrentielles avec son moteur de recherche
• [atlantico] Mettre l'IA de Meta/Facebook en open source: le pari (faussement) audacieux de Mark Zuckerberg
• [LeMagIT] L'UE laisse planer le doute sur le financement des projets open source
• [Le Temps] La Suisse championne du code source ouvert? Quand les internautes se passionnent pour une loi fédérale

[clubic.com] Les meilleurs logiciels libres et open source en 2024

✍ Naïm Bada, le mercredi 7 août 2024.

L’open-source est un mouvement né dans les années 80 avec le projet GNU qui donnera plus tard naissance à Linux. Avec le web et la facilitation de la collaboration en ligne dans les années 2000, de nombreux développeurs ont lancé des projets plus ou moins ambitieux dans l’optique de concurrencer les logiciels propriétaires. Aujourd’hui, le libre et l’open-source sont plus populaires que jamais!

[ouest-france.fr] Quimper. La distribution d’ordinateurs continue tout l’été au Centre des Abeilles

Le mercredi 7 août 2024.

Pas de pause en août 2024 pour les bénévoles du Centre des Abeilles et de Linux Quimper. La distribution d’ordinateurs de bureau sous Linux continue!

[Le Monde.fr] Google condamné pour pratiques anticoncurrentielles avec son moteur de recherche

Le lundi 5 août 2024.

Le géant américain, reconnu coupable d’avoir imposé, par défaut, son logiciel de recherche sur des appareils, a annoncé sa volonté de faire appel.

Et aussi:

• [Le Monde.fr] Google essuie une importante défaite judiciaire, cette fois aux Etats-Unis (€)

[atlantico] Mettre l'IA de Meta/Facebook en open source: le pari (faussement) audacieux de Mark Zuckerberg

✍ Atlantico, le lundi 5 août 2024.

Le 23 juillet, Mark Zuckerberg a publié un manifeste exposant les arguments commerciaux en faveur de l’IA open source.

Et aussi:

• [www.usine-digitale.fr] GenAI: Apple surfe sur la vague open source avec un LLM à près de 7 milliards de paramètres
• [ICTjournal] Meta prône l'IA open source mais ses LLM ne sont pas tout à fait ouverts
• [l'Opinion] Pour le patron de Meta, Mark Zuckerberg, «l’IA open source est la voie à suivre»

[LeMagIT] L'UE laisse planer le doute sur le financement des projets open source

✍ Gaétan Raoul, le mercredi 31 juillet 2024.

Plus de 150 associations et organisations, dont le Conseil National du Logiciel Libre, OW2, OpenStreeMap France et Framasoft, s’inquiètent pour le devenir des projets open source financés par l’initiative Next Generation Internet (NGI) inscrit au programme de la Commission européenne, Horizon Europe.

Et aussi:

• [ZDNET] Fin des programmes NGI? De nombreuses organisations alertent sur l'impact pour les logiciels libres

[Le Temps] La Suisse championne du code source ouvert? Quand les internautes se passionnent pour une loi fédérale

Le samedi 27 juillet 2024.

Une disposition légale impose à la Confédération de publier le code source des logiciels qu’elle développe. Un média américain a surinterprété la mesure et a suscité des réactions enthousiastes sur les réseaux sociaux, y compris d’Elon Musk

Sailfish OS est un système d'exploitation basé sur le noyau Linux et développé par la société finlandaise Jolla. Il vise surtout le marché des appareils mobiles (smartphones, tablettes).

Dans la suite de la dépêche, vous découvrirez les dernières nouvelles concernant Jolla et Sailfish OS.

Sommaire

• Introduction
• Nouveautés depuis Sailfish OS 4.4
  • Version 4.5 - Struven Ketju
  • Version 4.6 - Sauna
  • Nouveaux modèles pris en charge
• Contributions communautaires
• Les applications natives
• Nouveau modèle économique pour Sailfish OS
• Jolla et le logiciel libre
• Restructuration
• Conclusion

Introduction

Après une période turbulente, Jolla est enfin prête à attaquer cette nouvelle année sereinement. En attendant les répercussions de cette nouvelle ère, petit tour d'horizon des dernières nouveautés dans Sailfish OS depuis la dépêche d'octobre 2022 et des annonces survenues lors du Jolla Love Day 2.

Basée sur la distribution GNU/Linux MeeGo, initialement développée par Nokia et Intel, Sailfish a le principal avantage de fournir une couche supplémentaire nommée AppSupport basée sur Android AOSP. AppSupport s'exécute dans un container LXC et permet d'installer des applications Android, compensant ainsi l'absence de certaines applications ou services natifs. Cela positionne Sailfish comme une réelle alternative à Android, sans pour autant être handicapé par le peu d'applications natives.

Pour la petite histoire, en 2011, Nokia opère un choix stratégique consistant à passer à Windows Phone pour tous ses modèles. Cela a abouti au démantèlement de la division en charge de MeeGo et du Nokia N9, qui était aussi à l'origine du Nokia N900 sous Maemo.
En raison de ces turbulences, plusieurs employés décident de fonder Jolla afin de continuer le développement de MeeGo et de concevoir leur propre matériel. En 2013, leur premier modèle — le Jolla 1 — est dévoilé et sera maintenu jusqu'en septembre 2020.

Par la suite, la société Jolla a développé une tablette mais pour diverses raisons, notamment de fabrication, sa commercialisation a dû être arrêtée et seule une partie des commandes a été livrée. Enfin, il y a eu une nouvelle tentative pour un second smartphone dédié aux développeurs dont nous parlerons dans la suite de cette dépêche.

C'est après cet échec, que Jolla a décidé de se concentrer sur le système d'exploitation en s'appuyant entre autres sur le programme «Sony Open Devices». La première version du programme Sailfish X est publiée en 2017 pour le Xperia X.

Il y a eu par la suite le Xperia XA2 (32bits), toujours maintenu, puis le Xperia 10 II et enfin le 10 III (64bits).

Nouveautés depuis Sailfish OS 4.4

Chaque nouvelle version apporte sa grosse nouveauté. L'occasion aussi de stabiliser l'OS et mettre à niveau les différentes dépendances. Toutes les modifications sont listées dans les notes de version de chaque mise à jour.

Version 4.5 - Struven Ketju

Cette mise à jour sortie le 09 février 2023 est nommée en l'honneur de l'arc géodésique de Struve.

Elle apporte la mise à niveau d'Android vers la version 11, tout comme diverses contributions pour stabiliser et améliorer l'expérience utilisateur tant au niveau d'Android qu'au niveau de Sailfish OS.
Dans les principales améliorations, notons :

• une meilleure intégration d'Android au sein de Sailfish OS ;
• une connectivité (Wi-Fi, réseau mobile) plus stable ;
• une amélioration lorsque l'utilisateur active le Bluetooth et cherche de nouveaux appareils ;
• ou encore la possibilité d'utiliser une phrase de passe. Précisions de taille, cela sert à déchiffrer la partition, déverrouiller le système ou encore à obtenir les droits root lorsque c'est nécessaire.

Cette mise à jour est aussi l'occasion d'ouvrir l'accès à plusieurs API. Comme aux bibliothèques QtLocation, BluezQt ou encore Sailfish.media. Cette dernière permettant d'intégrer le lecteur audio dans une application. Voir la liste de toutes les nouvelles API dans la note de version struven ketju 4.5.0-16 pour l'énumération complète.

Autre nouveauté apportée, cette fois-ci par dcaliste : en plus de la vue « à la semaine » l'application calendrier offre une vue « au mois » ainsi qu'une autre vue « au jour ». dcaliste en a aussi profité pour améliorer la synchronisation avec les divers comptes en lignes.

Dernier point, l'ajout d'une option native arrêtant la charge pour réduire l'impact sur la batterie.

Au fil de l'année, plusieurs mises à jour mineures ont été déployées afin de corriger divers bugs introduit par la 4.5.0.16.
La 4.5.0.19 publiée le 23 mars 2023 apporte la gestion de CLAT à ConnMan, permettant d'utiliser les données mobiles sur les réseaux IPv6.

En mars 2024 est publiée une mise à jour mineure modifiant les conditions générales d'utilisation. Ceci afin de marquer le changement de propriétaire et donc le renouveau de Sailfish.

Version 4.6 - Sauna

À l'occasion du Jolla Love Day 2, la version 4.6.0.11 a été publiée pour les utilisateurs aguerris ayant activé le mode « Early Access ». La version définitive sera rendue publique lorsque les bugs découverts durant la seconde phase de test seront corrigés.

Parmi les principales nouveautés, l'apport de la 5G pour le Sony Xperia X10 III. Le précédent modèle, en l'occurrence le X10 II en étant dépourvu, il n'y a pour l'instant qu'un seul appareil compatible. Précision de taille, l'apport de la 5G est intimement lié au matériel malgré l'adaptation de ConnMann et oFono pour gérer la 5G.

Autre changement de taille, le partage de connexion par Bluetooth est désormais implémenté.

À nouveau, calendrier est l'une des principales applications à recevoir une nouvelle fonctionnalité l'améliorant grandement avec la possibilité de rechercher des événements.

Le 06 juin, la version 4.6.0.13 a été déployée aux abonnés « Early Access » et corrige certains bugs introduits précédemment.

Nouveaux modèles pris en charge

De nombreuses rumeurs mentionnaient la prise en compte de nouveaux appareils. En suivant divers dépôt Github, il a été possible de déduire quel était le futur appareil Sony géré par Jolla. Le 18 avril, la lettre d'information met enfin un terme aux diverses spéculations et confirme le portage de Sailfish sur les Sony X10 IV et Sony X10 V. D'autres portages toutefois non-officiels sont en cours de développement, comme pour le Fairphone 5.

Suite au Jolla Love Day 2, un nouvel appareil officiel limité à 1 000 unités est annoncé. À savoir le Jolla Community Phone aussi nommé Jolla C2 et développé en collaboration avec le constructeur turc Reeder.

Pour rappel, le premier appareil dédié à la communauté était le Jolla C. Ce modèle a été développé sur la base du Intex Aquafish du constructeur indien Intex Technologies. D'ailleurs il était relativement facile, pour ceux et celles qui n'avaient pu obtenir le Jolla C de convertir l'Intex Aquafish en Jolla C. Il en reste encore des traces dans le forum. Le Jolla C et l'IntexAquafish « as a Jolla C » sont encore maintenus, mais la version 4.6 sera la dernière mise à jour. Le Jolla C étant sorti en 2016, et l'Intex Aquafish quelques mois plus tard, nous pouvons considérer que c'est une bonne durée de maintenance et équivalente à celle du Jolla 1.

Contributions communautaires

Sailfish OS n'est certes pas entièrement libre, cela n'empêche pas d'avoir une communauté d'utilisateurs active contribuant aux parties libres de la distribution. Ce faisant, Sailfish OS fait ainsi partie des solutions alternatives aux deux autres grands systèmes du marché que sont iOS et Android.

Historiquement, pour le navigateur natif, Sailfish OS a toujours utilisé Gecko comme moteur de rendu, en utilisant l'adaptation Qt (QtMozEmbed) pour ce dernier. Maintenir cette adaptation pour un logiciel tel que Gecko est une tâche ardue et chronophage, raison pour laquelle Sailfish Browser utilise encore la version ESR 78. Un ancien employé de Jolla, flypig, a pris en main la mise à niveau du moteur de rendu à la version Gecko 91.
Ce travail titanesque est entièrement documenté dans un journal. La lecture en vaut d'ailleurs la chandelle !

En ce qui concerne oFono, un autre contributeur de Sailfish, piggz, a entrepris de gommer les divergences avec la version maintenue par Jolla. piggz est également connu pour ses portages, principalement sur le PinePhone. Suite à l'initiative de flypig de documenter son projet, l'avancement de son projet est documenté dans un journal.

La nouvelle n'a pas encore eu d'énormes répercussions, mais une équipe d'utilisateurs a entrepris de porter Flutter sur Sailfish OS. Pour l'instant, seule une application est disponible.

Les plus téméraires d'entre vous pourront également installer le gestionnaire de paquets nix sur SailfishOS. Le développeur qui s'est lancé dans cette aventure a eu droit à un bel entretien dans le Community News de décembre 2023.

Entre le 26 et 30 septembre 2024 se tiendra le second Hackathon organisé par la communauté d'utilisateur. L'événement étant en cours d'organisation les informations suivront prochainement.

Les applications natives

Il est évident que la liste des applications natives est moins fournie que les OS concurrents dominant le marché. Pour autant, l'essentiel est disponible ! Chaque 2 semaines lors du « Community News », les dernières applications actualisées sont mis en évidence dans cette lettre de diffusion. Par exemple — et outre le calendrier déjà évoqué — voici de manière non exhaustive quelques applications tierces natives :

• Pure Maps : associée avec OSMScoutServer, offre un système de navigation hors-ligne performant. Certes, il n'y a pas toutes les informations que l'on peut trouver dans les applications concurrentes, mais son usage reste très confortable ;
• Barcode, anciennement Codereader, un lecteur de codes-barres et de codes QR. Disponible dans Openrepos et Chum. Parfait pour récupérer les codes QR des timbres postes en lettre suivie. A noter également que l'auteur de Barcode a publié une application pour utiliser une Yubikey disponible dans Chum.
• Paketti : une application de suivi de courrier et de colis ;
• Chum : magasin d'applications fonctionnant dans les mêmes principes que F-Droid. Il est possible d'installer aisément via https://chumrpm.netlify.app/. Voir aussi cet article de blog du Nico's blog au sujet de Chum ;
• ownKeepass : application capable d'emporter avec vous votre fichier .kdbx Application et offre toutes les fonctions basiques présentes dans KeepassX. Malheureusement le développement d'ownKeepass s'est arrêté, ce qui n'empêche pas qu'un jour le développement soit repris par quelqu'un d'autre :

• SeaPrint : pour imprimer sur une imprimante réseau des images et des PDF via le protocole IPP. SeaPrint est développé par attah ;
• Mentionnons gPodder qui vient de sortir en version 4.16 pour les podcasts ;
• Une liste complète des applications est accessible sur les sites suivants :
  • https://openrepos.net/
  • https://sailfishos-chum.github.io/

Si l'utilisateur ne trouve pas son bonheur, grâce au Android AppSupport il sera toujours possible d'installer Fdroid et Aurora Store. A noter aussi que microG peut également être installé assez facilement, notamment pour permettre l'usage de certaines applications bancaires.

Ainsi, le magasin d'applications fourni par Jolla permet de trouver le magasin F-droid ou encore Aptoide. C'est depuis F-droid qu'il sera possible d'installer Aurora Store.

Rappelons que parmi les limitations, le Bluetooth n'est opérationnel que pour le son dans les applications Android. A ce jour, seuls certains modèles de montres assez spécifiques sont capables de communiquer avec le smartphone grâce à l'application native Amazfish développé par piggz, toutes les autres montres ne pouvant pas se connecter en Bluetooth au smartphone en raison de cette limitation du Bluetooth.
Pour en savoir plus, vous pourrez lire cet article du Nico's blog. Il en est exactement de même pour le NFC. Implémenter une interface entre Android et Sailfish requiert malheureusement énormément de ressources, mais nous pourrions espérer qu'un jour cela finisse par arriver. Principalement depuis que l'industrie automobile s'intéresse à la prise en charge d'Android.

Nouveau modèle économique pour Sailfish OS

Suite à l'échec de la tablette Jolla et du modèle « commerce entre entreprises et particuliers », une politique de licence régionale a été mise en place dès 2017 avec un partenariat dans plusieurs pays. Cela s'est concrétisé avec l'Intex Aquafish en Inde, qui a servi de base pour le Jolla C. En Amérique Latine, un accord de licence a été signé avec l'entreprise bolivienne Jala sous la marque Accione et enfin avec Rostelcom en Russie, certainement lors de son entrée au capital de Jolla.

Pour des raisons douanières et administratives, Jolla ne commercialisait ses licences qu'au sein de l'Union européenne ainsi que dans l'Association européenne de libre-échange (AELE). Suite au « Brexit », la commercialisation avec la Grande-Bretagne n'a repris qu'en 2021.

Lors du Jolla Love Day 2, un nouveau modèle économique a été présenté. Les appareils apparus avant les Sony X10 IV et Sony X10 V sont livrés avec une licence perpétuelle. Les nouveaux modèles eux sont utilisables avec un abonnement mensuel, voire annuel. La documentation sur les licences sera mise à jour lors de la commercialisation des licences pour les X10 IV, V et Jolla C2. Quelle que soit la licence payante (perpétuelle pour X10 II et X10 III ou à abonnement pour le X10 IV et X10 V et aussi le J2), les services fournis demeurent les mêmes :

• Les mises à jour logiciel OTA ;
• L'accès au support client tant que l'appareil est garanti ;
• La possibilité d'installer les extensions suivantes :
  • Android AppSupport ;
  • Support Microsoft Exchange ;
  • Saisie prédictive.

Petite particularité du Jolla Community 2, l'abonnement valide une année est inclus dans le prix d'achat.

En dehors du Jolla Community 2, où Sailfish OS est flashé par défaut, tous les autres modèles nécessitent d'être manipulé par l'utilisateur pour changer l'OS. Les instructions en anglais sont fournies pour tous les modèles et rédigées pour être exécutées depuis Linux, Mac OS ou encore Windows.

Jolla et le logiciel libre

Jolla a toujours été ouvert à l'idée de libérer les sources, il est dommage que depuis 2013 certaines parties comme le compositeur Lipstick restent encore propriétaires. Un bref instant, une vague de projets a été libéré. Malheureusement, cela a été de courte durée. Cela n'empêche pas que Jolla reste un contributeur au logiciel libre et qu'il a libéré les sources de certaines applications comme le navigateur ou encore le lecteur de document. La grosse partie du backend est lui libre. Avec un changement radical dans leur modèle économique, les choses pourraient changer.

Récemment, quelques nouvelles bibliothèques ont été développées avec une licence open-source, comme une exportation vers le QML de l'interface MPRIS.

Autre point intéressant à noter, Jolla a grandement contribué à l'essor de Linux sur les téléphones portables avec le développement du projet libhybris.

Voici une liste non exhaustive des projets auxquels Jolla contribue ou a libéré les sources :

• amber-web-authorization qui permet de faire de l’authentification OAuth en QML ;
• sailfish-secrets qui est un projet ambitieux, permettant de chiffrer / déchiffrer depuis le QML en choisissant son backend (principalement OpenSSL, mais aussi GnuPG), mais qui permet aussi de stocker des informations chiffrées sur le téléphone, un peu comme un kwallet ;
• messagingframework, hérité de l’ère Nokia et hébergé par le projet Qt. C’est un quadriciel de gestion des courriels ;
• KCalendarCore, un « framework » KDE pour la gestion du calendrier.

Et bien sûr tout l’héritage de MeeGo, directement maintenu par Jolla, également utilisé par d’autres projets comme LuneOS ou encore AsteroidOS :

• tous les bindings QML ;
• les bibliothèques d’intégrations, comme la gestion de l’historique des communications ou la gestion de la synchronisation ;
• la gestion des capteurs ;
• la gestion du clavier virtuel.

Notons aussi que Jolla participe régulièrement à FOSDEM. Si vous souhaitez lire à ce sujet : https://www.ncartron.org/jolla-and-sailfish-os-at-fosdem-23.html

Restructuration

Cette restructuration s'est opérée dans le cadre du droit finlandais. L'objectif était notamment de restructurer le capital et faire sortir l'actionnaire russe Rostelcom. Pour ce faire, et comme vraisemblablement les négociations amiables n'ont pas dû aboutir, les dirigeants de Jolla ont demandé à la justice de placer l'entreprise dans le cadre d'une procédure que nous pourrions comparer en droit français à la procédure de sauvegarde.

Cette procédure a fini par aboutir et — selon notre compréhension — cela s'est traduit par la création d'une nouvelle entité : l'entreprise Jollyboys Ltd.

Jollyboys a repris ainsi tous les actifs de Jolla, y compris la marque, les noms de domaines et bien entendu Sailfish OS.
Nous comprenons, selon les planches qui furent publiées pendant le Jolla Love Day 2, que les entreprises Jolla/Jollyboys Ltd et Seafarix ont été rachetées par le personnel dirigeant de l'entreprise Jolla.
Chaque technologie est séparée dans une structure juridique différente :

• Seafarix pour ce qui concerne l'automobile ;
• Jollyboys pour Sailfish OS ;
• VenhoAI pour les produits relatifs à l'IA.

La réorganisation de l'entreprise Jolla a suscité l'objet de beaucoup de discussions sur le forum.
Nous comprenons également que la marque Jolla et le nom de domaine jolla.com sont la propriété de la société Jollyboys.

Conclusion

Lors du Jolla Love Day 2, une feuille de route pour la version 5 a été dévoilée.
Une séparation de Sailfish est planifiée avec une partie nommée Sailfish Core et dévouée à l'embarqué et une autre conçue pour les téléphones portables, tablettes et autres appareils.

À voir ce que donnera le nouveau modèle de financement, mais il est réjouissant de voir du changement. L'année prochaine nous confirmera si cette nouvelle voie est la bonne. Le développement logiciel étant coûteux, offrir la possibilité d'y contribuer financièrement en tant qu'utilisateur donne plus de garantie de survie et de développement.

Si vous souhaitez suivre Sailfish, des comptes rendu des réunions de la communauté organisés par Jolla sont également accessibles. Il existe un blog officiel et une lettre de diffusion qui parait toutes les deux semaines et dont le numéro du 6 juin est précisément consacré à la 4.6 - Sauna.

Systemd est une suite logicielle primordiale du monde GNU/Linux. Elle peut être présente du début à la fin de l'allumage du système, permettant de gérer de manière fine la vie des autres services.

Systemd est sorti en 2010, en a énervé certains notamment en raison de l'approche audacieuse et intégrée, et a séduit une grande majorité de systèmes GNU/Linux à partir de 2015. Aujourd'hui il est possible de voir Systemd dans la plupart des grandes distributions, gérant les arcanes du système en s'appuyant sur les mécanismes noyau de cgroup, dbus et namespace notamment.

La version 256 succède à la v255 sortie en décembre 2023, où vous trouverez encore d'énormes évolutions et encore plus d'intégration afin de proposer un écosystème cohérent, le plus automatique possible, compatible avec chacun des autres systèmes, et cherchant à offrir de la sécurité par défaut associé à une granularité de configuration et d'isolation.

Il peut être intéressant de remarquer qu'au moins, à ma connaissance, deux développeurs fortement actifs, sont des salariés de Microsoft, travaillant autant sur systemd qu'à la normalisation d'un certain standard Linux par le truchement du groupe UAPI. Ce sont Lennart Poettering et Luca Boccassi, mais peut être en connaissez vous d'autres ?

Je vous invite également à vous pencher sur casync et mkosi (maintenu par Daan De Meyer, de chez Meta), deux nouvelles marottes de ces développeurs fous mais qui semblent avoir réussi le pari, qu'en pensez-vous ?

NdM : La dépêche qui suit est une traduction en français des nouveautés de la version 256.

Sommaire

• Une nouvelle version de systemd v256 est sortie
  • Modifications depuis la version précédente v255
    • Annonces de futures suppressions de fonctionnalités et de modifications incompatibles
  • Modifications générales et nouvelles fonctionnalités v256
    • Sur la gestion des services
    • Journalisation et autres gestions d'erreurs
    • À propos de la gestion des périphériques
    • systemd-hostnamed offre divers manières de modifier le nom et la description du système
    • La gestion du réseau avec systemd
    • À propos de systemd-nspawn, l'alternative sécurisée et fine de chroot
    • À propos du multi résolveur systemd-resolved, qui peut remplacer dnsmasq, Avahi & libnss-mdns
    • Une intégration fine de SSH
      • Recommandations aux distributions, afin que les choses fonctionnent correctement :
    • systemd-boot et systemd-stub et outils associés, une alternative minimale & ukify à grub
    • systemd-run/run0, une alternative sécurisée à sudo
    • Outillages en ligne de commande
    • systemd-vmspawn, permet de générer un système d'exploitation dans une machine virtuelle
    • systemd-repart, pour retailler un disque à la volée
    • Bibliothèques autours du monde systemd
    • systemd-cryptsetup systemd-cryptenroll, où l'aide au chiffrement de disque
    • systemd-homed systemd-logind, systemd-userdbd
    • systemd-creds, mécanisme de gestion des authentifications, pour arrêter de balancer du mot de passe en clair partout
    • De quoi mettre en veille et mettre en veille prolongée
    • Espaces de noms utilisateurs non privilégiés et gestion des montages de disques
    • Divers changements
    • Documentations
    • Contributeurs

Une nouvelle version de systemd v256 est sortie

Modifications depuis la version précédente v255

Annonces de futures suppressions de fonctionnalités et de modifications incompatibles

• La prise en charge du vidage automatique des caches de la base de données des utilisateurs/groupes nscd sera abandonnée dans une prochaine version.

• La prise en charge du groupe de contrôle cgroupv1 (hiérarchies « héritées » et « hybrides ») est désormais considérée comme obsolète, et systemd refusera par défaut de démarrer sous celui-ci. Pour réactiver de force la prise en charge de cgroup v1, SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1 doit être défini sur la ligne de commande du noyau. L'option Meson 'default-hierarchy=' est également obsolète, c'est-à-dire que seul le groupe cgroup v2 (hiérarchie unifiée) peut être sélectionné comme valeur par défaut au moment de la compilation.

• La prise en charge des scripts de service System V est à présent obsolète et sera supprimé dans une prochaine version. Veuillez vous assurer de mettre à jour votre logiciel maintenant pour inclure un fichier d'unité systemd natif au lieu d'un héritage de scripts System V, afin conserver la compatibilité avec les futures versions de systemd.

• La prise en charge de la variable EFI SystemdOptions est à présent obsolète. bootctl systemd-efi-options émettra un avertissement lorsqu'il sera utilisé. Il semble que cette fonctionnalité soit peu utilisée et qu'il soit préférable d'utiliser des approches alternatives comme les informations d'identification et les contextes. Le plan est d'abandonner complètement le support ultérieurement, mais cela pourrait être réexaminé en fonction des commentaires des utilisateurs.

• Le commutateur --expand-environment= de systemd-run, qui est actuellement désactivé par défaut lorsqu'il est combiné avec --scope, sera modifié dans une prochaine version pour être activé par défaut.

• Auparavant, systemd-networkd ne supprimait explicitement aucun ID de VLAN de pont attribué sur le maître de pont et les ports. Depuis la version 256, si un fichier .network pour une interface possède au moins un paramètre valide dans la section [BridgeVLAN], alors tous les ID de VLAN attribués sur l'interface qui ne sont pas configurés dans le fichier .network sont supprimés.

• Le paramètre IPForward= dans le fichier .network est obsolète et remplacé par les paramètres IPv4Forwarding= et IPv6Forwarding=. Ces nouveaux paramètres sont pris en charge à la fois dans le fichier .network et dans networkd.conf. S'ils sont spécifiés dans un fichier .network, ils contrôlent les paramètres correspondants par lien. S'ils sont spécifiés dans networkd.conf, ils contrôlent les paramètres globaux correspondants. Notez qu'auparavant IPv6SendRA= et IPMasquerade= impliquaient IPForward=, mais maintenant ils impliquent les nouveaux paramètres par lien. L'un des moyens les plus simples de migrer les configurations, qui fonctionnait comme un routeur avec la version précédente, consiste à activer à la fois IPv4Forwarding= et IPv6Forwarding= dans networkd.conf. Voir systemd.network(5) et networkd.conf(5) pour plus de détails.

• systemd-gpt-auto-generator arrêtera de générer des unités pour les partitions ESP ou XBOOTLDR s'il trouve des entrées de montage pour ou en dessous des hiérarchies /boot/ ou /efi/ dans /etc/fstab. Cela permet d'éviter que le générateur n'interfère avec les systèmes dans lesquels l'ESP est explicitement configuré pour être monté sur un chemin, par exemple /boot/efi/ (ce type de configuration est obsolète, mais reste courant).

• Le comportement de systemd-sleep et systemd-homed a été mis à jour pour geler les sessions utilisateur lors de l'entrée dans les différents modes de veille ou lors du verrouillage d'une zone d'accueil gérée par homed. Ceci est connu pour causer des problèmes avec les pilotes propriétaires NVIDIA. Les conditionneurs des pilotes propriétaires NVIDIA peuvent souhaiter ajouter des fichiers de configuration déroulants qui définissent SYSTEMD_SLEEP_FREEZE_USER_SESSION=false pour systemd-suspend.service et les services associés, et SYSTEMD_HOME_LOCK_FREEZE_SESSION=false pour systemd-homed.service.

• systemd-tmpfiles et systemd-sysusers, lorsqu'ils reçoivent un chemin de fichier de configuration relatif (avec au moins un séparateur de répertoire /), ouvriront le fichier directement, au lieu de rechercher le chemin partiel donné dans les emplacements standard. L'ancien mode n'était pas utile car la configuration tmpfiles.d/ et sysusers.d/ a une structure plate sans sous-répertoires sous les emplacements standard et ce changement facilite le travail avec des fichiers locaux avec ces outils.

• systemd-tmpfiles applique désormais correctement la configuration imbriquée aux strophes (stanzas) « R » et « D ». Par exemple, avec la combinaison de « R /foo » et « x /foo/bar », /foo/bar sera désormais exclu de la suppression.

• systemd.crash_reboot et les paramètres associés sont obsolètes au profit de systemd.crash_action=.

Modifications générales et nouvelles fonctionnalités v256

• Divers programmes tenteront désormais de charger le fichier de configuration principal à partir d'emplacements situés sous /usr/lib/, /usr/local/lib/ et /run/, et pas seulement sous /etc/. Par exemple, systemd-logind recherchera /etc/systemd/logind.conf, /run/systemd/logind.conf, /usr/local/lib/systemd/logind.conf et /usr/lib/systemd/logind.conf et utilise le premier fichier trouvé. Cela signifie que la logique de recherche pour le fichier de configuration principal et pour les drop-ins est désormais la même.

  • De même, l'installation du noyau recherchera les fichiers de configuration dans /usr/lib/kernel/ et dans les autres emplacements de recherche, et prend désormais également en charge les drop-ins.
  • systemd-udevd prend désormais en charge les drop-ins pour udev.conf.

• Un nouveau binaire systemd-vpick a été ajouté. Il implémente le nouveau protocole vpick, dans lequel un répertoire *.v/ peut contenir plusieurs fichiers dont les versions (suivant la spécification du format de version UAPI) sont intégrées dans le nom du fichier. Les fichiers sont classés par version et la plus récente est sélectionnée.

  • systemd-nspawn --image=/--directory=, systemd-dissect, systemd-portabled et les paramètres RootDirectory=, RootImage=, ExtensionImages= et ExtensionDirectories= pour les unités prennent désormais en charge le protocole vpick et permettent d'utiliser la dernière version sélectionnée automatiquement si un répertoire *.v/ est spécifié comme source.

• Les informations d'identification du service chiffrées peuvent désormais être rendues accessibles aux utilisateurs non privilégiés. systemd-creds a obtenu de nouvelles options --user/ --uid= pour chiffrer/déchiffrer les informations d'identification d'un utilisateur spécifique.

• Le nouvel outil de ligne de commande importctl pour télécharger, importer et exporter des images disque via systemd-importd est ajouté avec les verbes suivants : pull-tar, pull-raw, import-tar, import-raw, import-fs, export-tar, export-raw, list-transfers et cancel-transfer. Cette fonctionnalité était auparavant disponible dans machinectl, où elle était utilisée exclusivement pour les images machine. Le nouveau importctl généralise cela pour les images de service sysext, confext et portables.

• Les sources systemd peuvent désormais être compilées proprement avec toutes les dépréciations d'OpenSSL 3.0 supprimées, y compris la logique du moteur OpenSSL désactivée.

Sur la gestion des services

• Un nouveau paramètre de gestionnaire système ProtectSystem= a été ajouté. C'est analogue au réglage de l'unité, mais s'applique à l'ensemble du système. Il est activé par défaut dans le fichier initrd.

  • Notez que cela signifie que le code exécuté dans initrd ne peut pas être naïvement attendu à ce qu'il puisse écrire dans /usr/ pendant le démarrage. Cela affecte dracut <= 101, lequel écrit un crochet ("hooks") dans /lib/dracut/hooks/. src.

• Un nouveau paramètre d'unité WantsMountsFor= a été ajouté. Il est analogue à RequiresMountsFor=, mais crée une dépendance Wants= au lieu de Requires=. Cette nouvelle logique est désormais utilisée à divers endroits où des montages ont été ajoutés en tant que dépendances pour d'autres paramètres (WorkingDirectory=-…, PrivateTmp=yes, lignes cryptsetup avec nofail).

• Le nouveau paramètre d'unité MemoryZSwapWriteback= peut être utilisé pour contrôler le nouveau bouton de groupe de contrôle memory.zswap.writeback ajouté dans le noyau 6.8.

• Le gestionnaire a acquis une méthode D-Bus org.freedesktop.systemd1.StartAuxiliaryScope() pour déléguer certains processus d'un service vers une nouvelle portée.

  • Cette nouvelle étendue restera en cours d'exécution, même lorsque l'unité de service d'origine est redémarrée ou arrêtée. Cela permet à une unité de service de diviser certains processus de travail qui doivent continuer à s'exécuter. Les propriétés du groupe de contrôle de la nouvelle étendue sont copiées à partir de l'unité d'origine, de sorte que diverses limites sont conservées.

• Les unités exposent désormais les propriétés EffectiveMemoryMax=, EffectiveMemoryHigh= et EffectiveTasksMax=,

  • qui signalent la limite la plus stricte dont systemd a connaissance pour l'unité donnée.

• Un nouveau spécificateur de fichier d'unité %D

  • correspondra à $XDG_DATA_HOME pour les services utilisateur
  • ou correspondra à /usr/share/ pour les services système

• AllowedCPUs= prend désormais en charge l'extension du spécificateur.

• Le paramètre What= dans les unités .mount et .swap accepte désormais les identifiants de style fstab, par exemple UUID=… ou LABEL=….

• RestrictNetworkInterfaces= prend désormais en charge les noms d'interface réseau alternatifs.

• PAMName= implique désormais SetLoginEnvironment=yes.

• systemd.firstboot=no peut être utilisé sur la ligne de commande du noyau pour désactiver les requêtes interactives,

  • mais autoriser d'autres configurations de premier démarrage en fonction des informations d'identification.

• Le nom d'hôte du système peut être configuré via les informations d'identification système systemd.hostname.

• Le binaire systemd ne chargera plus en chaîne le binaire telinit de sysvinit lorsqu'il est appelé sous le nom init/telinit sur un système qui n'est pas démarré avec systemd.

  • Cela a déjà été pris en charge pour garantir qu'une distribution sur laquelle les deux systèmes d'initialisation sont installés peut raisonnablement passer de l'un à l'autre via un simple redémarrage. Les distributions ont apparemment perdu tout intérêt pour cela, et la fonctionnalité n'a pas été prise en charge sur la distribution principale à laquelle elle était encore destinée depuis longtemps, et a donc été supprimée maintenant.

• Un nouveau concept appelé capsules a été introduit.

  • Les capsules enveloppent des gestionnaires de services supplémentaires par utilisateur, dont les utilisateurs sont transitoires et ne sont définis que tant que le gestionnaire de services est en cours d'exécution.
  • (Ceci est implémenté via DynamicUser=1), permettant à un gestionnaire d'utilisateurs d'être utilisé pour gérer un groupe de processus sans avoir besoin de créer un compte utilisateur réel.
  • Ces gestionnaires de services fonctionnent avec les répertoires personnels de /var/lib/capsules/<capsule-name>
    • et peuvent contenir des services réguliers et d'autres unités.
  • Une capsule est démarrée via un simple systemctl start capsule@<name>.service.
  • Consultez la page de manuel capsule@.service(5) pour plus de détails.
  • Divers outils systemd (y compris, et surtout, systemctl et systemd-run) ont été mis à jour pour interagir avec les capsules via le nouveau commutateur --capsule=/-C.

• Les unités .socket ont obtenu un nouveau paramètre PassFileDescriptorsToExec=, prenant une valeur booléenne.

  • S'ils sont définis sur true, les descripteurs de fichiers que l'unité de socket encapsule sont transmis à ExecStartPost=, ExecStopPre=, ExecStopPost= en utilisant l'interface $LISTEN_FDS habituelle.
  • Cela peut être utilisé pour effectuer des initialisations supplémentaires sur les sockets une fois qu'elles sont allouées. (Par exemple, pour y installer un programme eBPF supplémentaire).

• Le paramètre .socket MaxConnectionsPerSource= (qui imposait jusqu'à présent une limite aux connexions simultanées par IP dans les unités de socket Accept=yes),

  • a désormais également un effet sur les sockets AF_UNIX 
    • il limitera le nombre de connexions simultanées à partir du même UID source (tel que déterminé via SO_PEERCRED).
  • Ceci est utile pour implémenter les services IPC dans un simple mode Accept=yes.

• Le gestionnaire de services maintiendra désormais un compteur des cycles de redémarrage logiciel effectués par le système.

  • Il peut être interrogé via les API D-Bus.

• La logique d'exécution de systemd prend désormais en charge la nouvelle API pidfd_spawn() introduite par la glibc 2.39,

  • qui nous permet d'invoquer un sous-processus dans un groupe de contrôle cible et de récupérer un pidfd en une seule opération.

• systemd/PID 1 enverra désormais un message sd_notify() supplémentaire à son VMM ou gestionnaire de conteneur superviseur signalant le nom d'hôte sélectionné (X_SYSTEMD_HOSTNAME=) et l'ID de la machine (X_SYSTEMD_MACHINE_ID=) au démarrage.

  • De plus, le gestionnaire de services enverra des messages sd_notify() supplémentaires (X_SYSTEMD_UNIT_ACTIVE=) chaque fois qu'une unité cible est atteinte.
  • Cela peut être utilisé par les VMM/gestionnaires de conteneurs pour planifier précisément l’accès au système.
  • Par exemple, dès qu'un système signale que ssh-access.target est atteint, un gestionnaire VMM/conteneur sait qu'il peut désormais se connecter au système via SSH.
  • Enfin, un nouveau message sd_notify() (X_SYSTEMD_SIGNALS_LEVEL=2) est envoyé au moment où le PID 1 a terminé avec succès l'installation de ses différents gestionnaires de signaux de processus UNIX (c'est-à-dire le moment où SIGRTMIN+4 envoyé au PID 1 commencera à avoir pour effet d'arrêter proprement le système).
  • X_SYSTEMD_SHUTDOWN= est envoyé peu de temps avant l'arrêt du système et contient une chaîne identifiant le type d'arrêt, c'est-à-dire poweroff, halt, reboot.
  • X_SYSTEMD_REBOOT_PARAMETER= est envoyé en même temps et porte la chaîne passée à systemctl --reboot-argument= s'il y en avait une.

• Les nouvelles propriétés D-Bus ExecMainHandoffTimestamp et ExecMainHandoffTimestampMonotonic sont désormais publiées par unités de services.

  • Cet horodatage est considéré comme la toute dernière opération avant de transférer le contrôle aux binaires invoqués. Ces informations sont disponibles pour d'autres types d'unités qui exécutent des processus (c'est-à-dire les unités de montage, d'échange, de socket), mais actuellement uniquement via systemd-analyze dump.

• Un horodatage supplémentaire est désormais pris par le gestionnaire de service lorsqu'une opération d'arrêt du système est lancée. Il peut être interrogé via D-Bus pendant la phase d'arrêt. Il est transmis lors des redémarrages logiciels à l'invocation suivante du gestionnaire de services, qui l'utilisera pour enregistrer le temps de « grisage » global de l'opération de redémarrage logiciel, c'est-à-dire l'heure à laquelle l'arrêt a commencé jusqu'à ce que le système soit à nouveau complètement opérationnel.

• systemctl status affichera désormais l'ID d'invocation dans sa sortie habituelle, c'est-à-dire l'ID de 128 bits attribué de manière unique au cycle d'exécution actuel de l'unité.

  • L'ID est pris en charge depuis longtemps, mais il est désormais affiché de manière plus visible, car il s'agit d'un identifiant très utile pour un appel spécifique d'un service.

• systemd génère désormais une nouvelle chaîne taint unmerged-bin pour les systèmes qui ont /usr/bin/ et /usr/sbin/ séparés.

  • De nos jours, il est généralement recommandé de faire de ce dernier un lien symbolique vers le premier.

• Une nouvelle option de ligne de commande kernel systemd.crash_action= a été ajoutée qui configure ce qu'il faut faire après le crash du gestionnaire système (PID 1).

  • Cela peut également être configuré via CrashAction= dans systemd.conf.

• systemctl kill prend désormais en charge --wait qui fera attendre la commande jusqu'à ce que les services signalés se terminent.

Journalisation et autres gestions d'erreurs

• systemd-journald peut désormais transférer les entrées de journal vers un socket (AF_INET, AF_INET6, AF_UNIX ou AF_VSOCK).

  • Le socket peut être spécifié dans journald.conf via une nouvelle option ForwardAddress= ou via les informations d'identification journald.forward_address.
  • Les enregistrements de journaux sont envoyés au format d'exportation du journal.
  • Un paramètre associé MaxLevelSocket= a été ajouté pour contrôler les niveaux de journalisation maximum pour les messages envoyés à ce socket.

• systemd-journald lit désormais également les informations d'identification de journal.storage lorsque cherche où stocker les fichiers journaux.

• systemd-vmspawn a obtenu une nouvelle option --forward-journal= pour transmettre les entrées de journal de la machine virtuelle à l'hôte.

  • Cela se fait via un socket AF_VSOCK, c'est-à-dire qu'il ne nécessite pas de mise en réseau dans l'invité.

• journalctl a obtenu l'option -i comme raccourci pour --file=.

• journalctl a gagné une nouvelle option -T/--exclude-identifier= pour filtrer certains identifiants syslog.

• journalctl a gagné une nouvelle option --list-namespaces.

• systemd-journal-remote accepte désormais également les sockets AF_VSOCK et AF_UNIX : il peut donc être utilisé pour recevoir les entrées transmises par systemd-journald.

• systemd-journal-gatewayd permet de restreindre la plage horaire des entrées récupérées avec un nouveau paramètre d'URL realtime=[<since>]:[<until>].

• systemd-cat a gagné une nouvelle option --namespace= pour spécifier l'espace de noms du journal cible auquel la sortie doit être connectée.

• systemd-bsod a gagné une nouvelle option --tty= pour spécifier le TTY de sortie

À propos de la gestion des périphériques

• /dev/ contient désormais des liens symboliques qui combinent des informations by-path & by-{label,uuid}:

  • /dev/disk/by-path/<chemin>/by-<label|uuid|…>/<label|uuid|…>
  • Cela permet de distinguer les partitions avec un contenu identique sur plusieurs périphériques de stockage.
  • Ceci est utile, par exemple, lors de la copie du contenu brut du disque entre périphériques.

• systemd-udevd crée désormais des liens symboliques /dev/media/by-path/ persistants pour les contrôleurs multimédias.

  • Par exemple, le pilote uvcvideo peut créer /dev/media0 qui sera lié en tant que /dev/media/by-path/pci-0000:04:00.3-usb-0:1:1.0-media-controller.

• Une nouvelle unité systemd-udev-load-credentials.service a été ajoutée pour récupérer les drop-ins udev.conf et les règles udev à partir des informations d'identification.

• Une liste d'autorisation/liste de refus peut être spécifiée pour filtrer les attributs sysfs utilisés lors de la création des noms d'interface réseau.

  • Ces listes sont stockées sous forme d'entrées hwdb
    • ID_NET_NAME_ALLOW_<sysfsattr>=0|1
    • et ID_NET_NAME_ALLOW=0|1
    • L'objectif est d'éviter des modifications inattendues des noms d'interface lorsque le noyau est mis à jour et que de nouveaux attributs sysfs deviennent visibles.

• Une nouvelle unité tpm2.target a été ajoutée pour fournir un point de synchronisation pour les unités qui s'attendent à ce que le matériel TPM soit disponible.

  • Un nouveau générateur systemd-tpm2-generator a été ajouté qui insérera cette cible chaque fois qu'il détectera que le micrologiciel a initialisé un TPM, mais que Linux n'a pas encore chargé de pilote pour celui-ci.

• systemd-backlight prend désormais correctement en charge les périphériques numérotés créés par le noyau pour éviter les collisions dans le sous-système LED.

• L'opération de mise à jour systemd-hwdb peut être désactivée avec une nouvelle variable d'environnement SYSTEMD_HWDB_UPDATE_BYPASS=1.

systemd-hostnamed offre divers manières de modifier le nom et la description du système

• systemd-hostnamed expose désormais l'ID de la machine et l'ID de démarrage via D-Bus.

  • Il expose également les hôtes AF_VSOCK CID, si disponible.

• systemd-hostnamed fournit désormais une interface Varlink de base.

• systemd-hostnamed exporte les données complètes dans os-release(5) et machine-info(5) via D-Bus et Varlink.

• hostnamectl affiche désormais l'UUID du produit du système et le numéro de série du matériel s'il est connu.

La gestion du réseau avec systemd

• systemd-networkd fournit désormais une interface Varlink de base.

• La prise en charge du proxy ARP de systemd-networkd a gagné une nouvelle option pour configurer une variante de VLAN privé du proxy ARP pris en charge par le noyau sous le nom IPv4ProxyARPPrivateVLAN=.

• systemd-networkd exporte désormais les propriétés NamespaceId et NamespaceNSID via D-Bus et Varlink.

  • qui exposent l'inode et le NSID de l'espace de noms réseau géré par l'instance networkd)

• systemd-networkd prend désormais en charge les paramètres IPv6RetransmissionTimeSec= et UseRetransmissionTime= dans les fichiers .network pour configurer le temps de retransmission pour les messages de sollicitation de voisin IPv6.

• networkctl a acquis de nouveaux verbes « mask » et « unmask » pour masquer les fichiers de configuration réseau tels que les fichiers .network.

• networkctl edit --runtime permet de modifier la configuration volatile sous /run/systemd/network/.

• La mise en œuvre derrière le paramètre réseau TTLPropagate= a été supprimée, et ce paramètre est désormais ignoré.

• systemd-network-generator récupérera désormais la configuration situé dans .netdev/.link/.network/networkd.conf à partir des informations d'identification du système.

• systemd-networkd récupérera désormais les secrets de wireguard depuis les informations d'identification (credentials).

• L'API Varlink de systemd-networkd prend désormais en charge l'énumération des homologues LLDP.

• Les fichiers .link prennent désormais en charge les nouveaux champs Property=, ImportProperty=, UnsetProperty= pour définir les propriétés udev sur un lien.

• Les différents fichiers .link fournis par systemd pour les interfaces censées être gérées uniquement par systemd-networkd portent désormais une propriété udev ID_NET_MANAGED_BY=io.systemd.Network garantissant que les autres solutions de gestion de réseau honorant cette propriété udev n'entrent pas en conflit avec networkd, en essayant de gérer ces interfaces.

• Les fichiers .link prennent désormais en charge un nouveau paramètre ReceiverPacketSteeringCPUMask=

  • pour configurer les processeurs vers lesquels diriger les paquets entrants.

• La section [Réseau] des fichiers .network a gagné un nouveau paramètre UseDomains=,

  • qui est un bouton générique unique pour contrôler les paramètres du même nom dans [DHCPv4], [DHCPv6] et [IPv6AcceptRA].

• Le fichier 99-default.link que nous livrons par défaut

  • (qui définit la politique pour tous les périphériques réseau auxquels aucun autre fichier .link ne s'applique)
  • répertorie désormais mac parmi AlternativeNamesPolicy=.
  • Cela signifie que les interfaces réseau recevront désormais par défaut un nom de périphérique alternatif supplémentaire basé sur l'adresse MAC. (c'est-à-dire enx…)

À propos de systemd-nspawn, l'alternative sécurisée et fine de chroot

• systemd-nspawn fournit désormais un répertoire /run/systemd/nspawn/unix-export/ dans lequel la charge utile du conteneur peut exposer les sockets AF_UNIX pour leur permettre d'y accéder de l'extérieur.

• systemd-nspawn teintera l'arrière-plan du terminal des conteneurs d'une couleur bleuâtre. Cela peut être un contrôleur avec le nouveau commutateur --background=.

• systemd-nspawn a obtenu la prise en charge de l'option owneridmap pour les montages --bind= afin de mapper le propriétaire du répertoire cible depuis l'intérieur du conteneur vers le propriétaire du répertoire lié au système de fichiers hôte.

• systemd-nspawn prend désormais en charge le déplacement des périphériques réseau Wi-Fi dans un conteneur, tout comme les autres interfaces réseau.

À propos du multi résolveur systemd-resolved, qui peut remplacer dnsmasq, Avahi & libnss-mdns

• systemd-resolved lit désormais les codes d'erreur RFC 8914 EDE fournis par les services DNS en amont.

• systemd-resolved et solvectl prennent désormais en charge les enregistrements RFC 9460 SVCB et HTTPS, ainsi que les enregistrements RFC 2915 NAPTR.

• solvectl a acquis une nouvelle option --relax-single-label= pour permettre d'interroger des noms d'hôtes en une seule partie via DNS unicast pour chaque requête.

• L'interface Varlink IPC de systemd-resolved prend désormais en charge la résolution des services DNS-SD ainsi qu'une API pour résoudre les RR DNS bruts.

• Les fichiers de description de service .dnssd DNS_SD de systemd-resolved prennent désormais en charge les sous-types DNS-SD via le nouveau paramètre SubType=.

• La configuration de systemd-resolved peut désormais être rechargée sans redémarrer le service, c'est-à-dire que systemctl reload systemd-resolved est désormais pris en charge.

Une intégration fine de SSH

• Un drop-in de configuration sshd pour permettre aux clés ssh acquises via userdbctl (par exemple exposées par des comptes de type systemd-homed) d'être utilisées pour l'autorisation des connexions SSH entrantes.

• Un petit nouveau générateur d'unités systemd-ssh-generator a été ajouté. Il vérifie si le binaire sshd est installé. Si tel est le cas, il le lie via l'activation de socket par connexion à différentes sockets en fonction du contexte d'exécution :

  • Si le système est exécuté sur une VM prenant en charge AF_VSOCK, il lie automatiquement sshd au AF_VSOCK port 22 .
  • Si le système est invoqué en tant que conteneur OS complet et que le gestionnaire de conteneur pré-monte un répertoire /run/host/unix-export/, il liera sshd à un socket AF_UNIX /run/host/unix-export/ssh. L'idée est que la liaison du gestionnaire de conteneur monte également le répertoire à un endroit approprié sur l'hôte, de sorte que le socket AF_UNIX puisse être utilisé pour se connecter facilement de l'hôte au conteneur.

• sshd est également lié à un socket AF_UNIX /run/ssh-unix-local/socket, qui consiste à utiliser ssh/sftp à la manière de sudo pour accéder aux ressources d'autres utilisateurs locaux.

• Via l'option de ligne de commande du noyau systemd.ssh_listen= et les informations d'identification système ssh.listen, sshd peut être lié à des options supplémentaires explicitement configurées, notamment les ports AF_INET/AF_INET6.

• En particulier, les deux premiers mécanismes devraient faciliter grandement la gestion des machines virtuelles locales et des conteneurs de système d'exploitation complets, car les connexions SSH fonctionneront basiquement à partir de l'hôte – même si aucun réseau n'est disponible.

• systemd-ssh-generator génère optionnellement un fichier de service d'activation de socket par connexion en encapsulant sshd. Ceci n'est fait que si la distribution n'en fournit pas elle-même sous le nom de sshd@.service. L'unité générée ne fonctionne correctement que si le répertoire de séparation des privilèges SSH privsep existe. Malheureusement, les distributions varient & placent ce répertoire de manière très variable. Voici une liste incomplète :

  • /usr/share/empty.sshd/ (nouveau sous Fedora)
  • /var/empty/
  • /var/empty/sshd/
  • /run/sshd/ (debian/ubuntu ?)

Si le répertoire SSH privsep est placé sous /var/ ou /run/, il faut veiller à ce que le répertoire soit créé automatiquement au démarrage si nécessaire, car ces répertoires peuvent être ou sont toujours vides. Cela peut être fait via un drop-in tmpfiles.d/. Vous pouvez utiliser l'option meson sshdprivsepdir fournie par systemd pour configurer le répertoire, au cas où vous souhaiteriez que systemd crée automatiquement le répertoire selon vos besoins, si votre distribution ne le couvre pas de manière native.

Recommandations aux distributions, afin que les choses fonctionnent correctement :

• Veuillez fournir un fichier de service SSH par connexion sous le nom sshd@.service.
• Veuillez déplacer le répertoire SSH privsep dans /usr/
* afin qu'il soit véritablement immuable sur les systèmes d'exploitation basés sur des images
* qu'il soit strictement sous le contrôle du gestionnaire de paquets
* et qu'il ne nécessite jamais de recréation si le système démarre avec un répertoire /run/ ou /var vide.
• Dans le prolongement de ceci : veuillez envisager de suivre l'exemple de Fedora ici et d'utiliser /usr/share/empty.sshd/ pour minimiser les différences inutiles entre les distributions.
• Si votre distribution insiste pour placer le répertoire dans /var/ ou /run/ alors veuillez au moins fournir un drop-in tmpfiles.d/ pour le recréer automatiquement au démarrage, afin que le binaire sshd fonctionne correctement, quel que soit le contexte dans lequel il se trouve appelé.

• Un petit outil systemd-ssh-proxy a été ajouté, censé faire office de pendant de systemd-ssh-generator. C'est un petit plug-in pour le client SSH (via ProxyCommand/ProxyUseFdpass) pour lui permettre de se connecter aux sockets AF_VSOCK ou AF_UNIX. Exemple : ssh vsock/4711 se connecte à une VM locale avec le cid 4711, ou ssh unix/run/ssh-unix-local/socket pour se connecter à l'hôte local via le socket AF_UNIX /run/ssh-unix-local/socket.

systemd-boot et systemd-stub et outils associés, une alternative minimale & ukify à grub

• La prise en charge des mesures PCR TPM 1.2 a été supprimée de systemd-stub. Le TPM 1.2 est obsolète et – en raison de la faiblesse (selon les normes actuelles) des algorithmes cryptographiques qu'il ne prend en charge – n'offre pas réellement les avantages en matière de sécurité qu'il est censé offrir. Étant donné que le reste de la base de code de systemd n'a jamais pris en charge TPM 1.2, la prise en charge a également été supprimée de systemd-stub.

• systemd-stub mesurera désormais sa charge utile via les nouvelles API EFI Confidential Computing (CC), en plus des mesures préexistantes du TPM.

• Les confextes (cf [systemd-sysext](https://www.freedesktop.org/software/systemd/man/latest/systemd-sysext.html)) sont également chargés par systemd-stub depuis l'ESP.

• kernel-install a obtenu le support de --root= pour le verbe list.

• bootctl fournit désormais une interface Varlink de base et peut être exécuté en tant que service(démon) via une unité modèle.

• systemd-measure a obtenu de nouvelles options --certificate=, --private-key= et --private-key-source= pour permettre l'utilisation des moteurs ou fournisseurs d'OpenSSL comme mécanisme de signature à utiliser lors de la création de valeurs de mesure signées PCR TPM2

• ukify a obtenu la prise en charge de la signature des signatures PCR via les moteurs et fournisseurs OpenSSL.

• ukify prend désormais en charge les noyaux zboot.

• systemd-boot prend désormais en charge la transmission de commutateurs de ligne de commande de noyau supplémentaires aux noyaux invoqués via une chaîne SMBIOS Type #11 io.systemd.boot.kernel-cmdline-extra. Ceci est similaire à la prise en charge préexistante de cela dans systemd-stub, mais s'applique également aux entrées de spécification du chargeur de démarrage de type n°1.

• La prise en charge automatique de l'inscription SecureBoot par systemd-boot prend également en charge l'inscription dbx (auparavant, seule l'inscription db/KEK/PK était prise en charge). Il prend également désormais en charge le mode UEFI « Personnalisé ».

• La politique pcrlock est enregistrée dans un fichier d'informations d'identification non chiffré pcrlock.<entry-token>.cred sous XBOOTLDR/ESP dans le répertoire /loader/credentials/. Il sera récupéré au démarrage par systemd-stub et transmis à initrd, où il pourra être utilisé pour déverrouiller le système de fichiers racine.

• systemd-pcrlock a obtenu une option --entry-token= pour configurer le jeton d'entrée.

• systemd-pcrlock fournit désormais une interface Varlink de base et peut être exécuté en tant que démon via une unité modèle.

• La politique d'accès au TPM nvindex de systemd-pcrlock a été modifiée

  • cela signifie que les politiques pcrlock précédentes stockées dans nvindexes sont invalidées.
  • Ils doivent être supprimés (systemd-pcrlock remove-policy) et recréés (systemd-pcrlock make-policy).
  • Pour le moment, systemd-pcrlock reste une fonctionnalité expérimentale, mais elle devrait devenir stable dans la prochaine version, c'est-à-dire la v257.

• Le commutateur --recovery-pin= de systemd-pcrlock prend désormais trois valeurs : hide, show, query. Si « afficher » est sélectionné, le code PIN de récupération généré automatiquement est affiché à l'utilisateur. Si « requête » est sélectionné, le code PIN est demandé à l'utilisateur.

• sd-stub prend désormais en charge la nouvelle section PE .ucode dans les UKI, qui peut contenir des données de microcode CPU. Lorsque le contrôle est transféré au noyau Linux, ces données sont ajoutées au début de l'ensemble des initrds transmis.

systemd-run/run0, une alternative sécurisée à sudo

• systemd-run est désormais un binaire multi-appels. Lorsqu'il est invoqué en tant que run0, il fournit une interface similaire à sudo, tous les arguments commençant au premier paramètre non-option étant traités comme la commande à invoquer en tant que root.

  • Contrairement à « sudo » et aux outils similaires, il n'utilise pas de binaires setuid ou d'autres méthodes d'élévation de privilèges
  • mais exécute à la place la commande spécifiée comme une unité transitoire
  • Elle est démarrée par le gestionnaire de services système, de sorte que les privilèges sont supprimés plutôt que gagnés.
  • Cela met ainsi en œuvre un modèle de sécurité beaucoup plus robuste et sûr.
  • Comme d'habitude, l'autorisation est gérée via Polkit.

• systemd-run/run0 teintera désormais l'arrière-plan du terminal sur les terminaux pris en charge :

  • dans un ton rougeâtre lors de l'appel d'un service racine
  • dans un ton jaunâtre sinon.
  • Cela peut être contrôlé et désactivé via le nouveau commutateur --background=.

• systemd-run a gagné une nouvelle option --ignore-failure pour supprimer les échecs de commandes.

Outillages en ligne de commande

• systemctl edit --stdin permet la création de fichiers d'unité et de drop-ins avec du contenu fourni via l'entrée standard.

  • Ceci est utile lors de la création d’une configuration par programme ; l'outil se charge de déterminer le nom du fichier, de créer les répertoires éventuels et de recharger ensuite le gestionnaire.

• systemctl disable --now et systemctl mask --now fonctionnent désormais correctement avec les modèles d'unités.

• systemd-analyze architectures répertorie les architectures CPU connues.

• systemd-analyze --json=… est pris en charge pour les architectures, capability, exit-status

• systemd-tmpfiles --purge purgera (supprimera) tous les fichiers et répertoires créés via la configuration tmpfiles.d.

• systemd-id128 a gagné de nouvelles options --no-pager, --no-legend et -j/ --json=.

• hostnamectl a gagné -j comme raccourci pour --json=pretty ou --json=short

• loginctl prend désormais en charge -j/ --json=.

• resolvectl prend désormais en charge -j/ --json= pour --type=.

• systemd-tmpfiles a gagné une nouvelle option --dry-run pour simuler ce qui serait fait sans réellement agir.

• varlinkctl a obtenu un nouveau commutateur --collect pour collecter toutes les réponses d'un appel de méthode qui prend en charge plusieurs réponses et le transforme en un seul tableau JSON.

• systemd-dissect a acquis une nouvelle option --make-archive pour générer un fichier d'archive (tar.gz et similaire) à partir d'une image disque.

systemd-vmspawn, permet de générer un système d'exploitation dans une machine virtuelle

• systemd-vmspawn a gagné

  • une nouvelle option --firmware= pour configurer ou lister les définitions de firmware pour Qemu
  • une nouvelle option --tpm= pour activer ou désactiver l'utilisation d'un TPM logiciel
  • une nouvelle option --linux= pour spécifier un noyau binaire pour le démarrage direct du noyau
  • une nouvelle option --initrd= pour spécifier un initrd pour le démarrage direct du noyau
  • une nouvelle option -D/--directory pour utiliser un répertoire simple comme système de fichiers racine
  • une nouvelle option --private-users similaire à celle de systemd-nspawn
  • de nouvelles options --bind= et --bind-ro= pour lier une partie de la hiérarchie du système de fichiers de l'hôte à l'invité
  • une nouvelle option --extra-drive= pour attacher du stockage supplémentaire
  • et -n/--network-tap/--network-user-mode pour configurer le réseau.

• Un nouveau systemd-vmspawn@.service peut être utilisé pour lancer systemd-vmspawn en tant que service.

• systemd-vmspawn a obtenu les nouveaux commutateurs --console= et --background= qui contrôlent la manière d'interagir avec la VM.

  • Comme auparavant, une interface de terminal interactive est fournie par défaut, mais désormais avec un fond teinté d'une teinte verdâtre.

• systemd-vmspawn peut désormais enregistrer ses VM auprès de systemd-machined, contrôlé via le commutateur --register=.

• La commande start de machinectl (et associée) peut désormais appeler des images

  • soit en tant que conteneurs via systemd-nspawn (le commutateur est --runner=nspawn, la valeur par défaut)
  • soit en tant que VM via systemd-vmspawn (le commutateur est --runner=vmspawn , ou court -V).

• systemd-vmspawn prend désormais en charge deux commutateurs --pass-ssh-key= et --ssh-key-type= pour configurer éventuellement des clés SSH transitoires à transmettre aux machines virtuelles invoquées afin de pouvoir y accéder en SSH une fois démarrées.

• systemd-vmspawn activera désormais diverses options sur les VMs

  • HyperV enlightenments"
  • et le VM Generation ID

• Une nouvelle variable d'environnement $SYSTEMD_VMSPAWN_QEMU_EXTRA peut contenir des options de ligne de commande qemu supplémentaires à transmettre à qemu.

• systemd-machined a acquis une nouvelle méthode D-Bus GetMachineSSHInfo() qui est utilisé par systemd-vmspawn pour récupérer les informations nécessaires pour se connecter au système.

  • systemd-machined a acquis une nouvelle interface Varlink qui est utilisée par systemd-vmspawn pour enregistrer les machines avec diverses informations & métadonnées supplémentaires.

systemd-repart, pour retailler un disque à la volée

• systemd-repart a obtenu de nouvelles options --generate-fstab= et --generate-crypttab=

  • pour écrire les fichiers fstab et crypttab correspondant aux partitions générées.

• systemd-repart a obtenu une nouvelle option --private-key-source=

  • pour permettre d'utiliser les moteurs ou fournisseurs d'OpenSSL comme mécanisme de signature à utiliser lors de la création de partitions de signature Verity.

• systemd-repart a obtenu un nouveau paramètre DefaultSubvolume= dans les drop-ins repart.d/

  • qui permettent de configurer le sous-volume btrfs par défaut pour les systèmes de fichiers btrfs nouvellement formatés.

Bibliothèques autours du monde systemd

• libsystemd a obtenu un nouvel appel sd_bus_creds_new_from_pidfd()

  • pour obtenir un objet d'informations d'identification pour un pidfd
  • et sd_bus_creds_get_pidfd_dup() pour récupérer le pidfd à partir d'un objet d'informations d'identification.

• La logique d'identification de sd-bus acquerra désormais également les listes de groupes UNIX du homologue

  • et le pidfd du homologue si pris en charge et demandé.

• La macro RPM %_kernel_install_dir a été ajoutée avec le chemin d'accès au répertoire des plugins d'installation du noyau.

• Les dépendances liblz4, libzstd, liblzma, libkmod, libgcrypt ont été modifiées

  • de dépendances de bibliothèque partagée habituelles en dépendances basées sur dlopen().
  • Notez que cela signifie que ces bibliothèques pourraient ne pas être automatiquement récupéré lorsque les dépendances ELF sont résolues. En particulier le manque de libkmod peut causer des problèmes de démarrage. Cela affecte le dracut <= 101

• Les binaires systemd ELF qui utilisent des bibliothèques via dlopen() sont maintenant construits avec une nouvelle section de note d'en-tête ELF, suite à une nouvelle spécification définie à
  docs/ELF_DLOPEN_METADATA.md, qui fournit des informations sur lesquels le sonames sont chargés et utilisés s'ils sont trouvés au moment de l'exécution. Cela permet aux outils et packagers pour découvrir par programme la liste des éléments facultatifs
  dépendances utilisées par tous les binaires systemd ELF. Un analyseur avec packaging les outils d'intégration sont disponibles sur git

• L'API sd-journal a obtenu un nouvel appel sd_journal_stream_fd_with_namespace()

  • qui ressemble à sd_journal_stream_fd() mais crée un flux de journaux ciblé sur un espace de noms de journal spécifique.

• L'API sd-id128 a obtenu un nouvel appel d'API sd_id128_get_invocation_app_special()

  • pour acquérir un ID spécifique à l'application dérivé de l'ID d'appel de service.

• L'API sd-event a obtenu un nouvel appel d'API sd_event_source_get_inotify_path()

  • qui renvoie le chemin du système de fichiers pour lequel une source d'événement inotify a été créée.

systemd-cryptsetup systemd-cryptenroll, où l'aide au chiffrement de disque

• L'argument du nœud de périphérique pour systemd-cryptenroll est désormais facultatif.

  • S'il est omis, il sera automatiquement déduit du périphérique de bloc de support de /var/
    • (qui est très probablement le même que le système de fichiers racine, ce qui signifie effectivement que si vous ne spécifiez rien, sinon l'outil enregistrera désormais par défaut une clé dans périphérique LUKS du système de fichiers racine).

• systemd-cryptenroll peut désormais s'inscrire directement avec une clé publique PKCS11 (au lieu d'un certificat).

• systemd-cryptsetup systemd-cryptenroll peuvent désormais verrouiller un disque avec une clé EC fournie par PKCS#11

  • (auparavant, il ne prenait en charge que RSA).

• systemd-cryptsetup prend en charge l'option crypttab link-volume-key=

  • pour lier la clé du volume au jeu de clés du noyau lorsque le volume est ouvert.

• systemd-cryptenroll n'activera plus la protection contre les attaques par dictionnaire (c'est-à-dire activer NO_DA) pour les inscriptions TPM qui n'impliquent pas de code PIN.

  • DA ne devrait pas être nécessaire dans ce cas (puisque l'entropie de la clé est suffisamment élevée pour rendre cela inutile),
  • mais un risque un verrouillage accidentel en cas de modifications inattendues du PCR.

• systemd-cryptenroll prend désormais en charge l'inscription d'un nouvel emplacement tout en déverrouillant l'ancien emplacement via TPM2

  • (auparavant, le déverrouillage ne fonctionnait que via un mot de passe ou FIDO2).

systemd-homed systemd-logind, systemd-userdbd

• systemd-homed prend désormais en charge le déverrouillage des répertoires personnels lors de la connexion via SSH.

  • Auparavant, les répertoires personnels devaient être déverrouillés avant toute tentative de connexion SSH.

• Les enregistrements utilisateur au format JSON ont été étendus avec une zone de stockage publique distincte appelée « Répertoires binaires des enregistrements utilisateur » ("User Record Blob Directories").

  • Ceci est destiné à stocker l'image d'arrière-plan de l'utilisateur, l'image de l'avatar et d'autres éléments similaires qui sont trop volumineux pour tenir dans l'enregistrement utilisateur lui-même.
  • systemd-homed, userdbctl et homectl prennent désormais en charge les répertoires binaires.
    
  • homectl a gagné --avatar= et --login-background=
    • pour contrôler deux éléments spécifiques des répertoires binaires.
  • Un nouveau champ additionalLanguages a été ajouté aux enregistrements utilisateur JSON (tel que pris en charge par systemd-homed et systemd-userdbd),
    • qui est étroitement lié au preferredLanguage préexistant, et permet de spécifier plusieurs langues supplémentaires pour le compte utilisateur.
    • Il est utilisé pour initialiser la variable d'environnement $LANGUAGES lorsqu'elle est utilisée.

• Une nouvelle paire de champs preferredSessionType et preferredSessionLauncher a été ajoutée aux enregistrements utilisateur JSON,

  • qui peuvent être utilisées pour contrôler le type de session de bureau à activer de préférence lors des connexions de l'utilisateur.

• homectl a gagné un nouveau verbe firstboot, et une nouvelle unité systemd-homed-firstboot.service

  • ce verbe est utilisé pour créer des utilisateurs dans un environnement de premier démarrage,
    • soit à partir des informations d'identification du système
    • soit en interrogeant de manière interactive.

• systemd-logind prend désormais en charge une nouvelle classe de session background-light qui n'envoie pas l'unité user@.service.

  • Ceci est destiné aux sessions automatisées, type cron, sans nécessiré d'interactions utilisateurs
  • Cela rend l'ouverture plus légère et rapide.

• Le gestionnaire de services par utilisateur sera désormais suivi comme un type de session « gestionnaire » (manager) distinct parmi les sessions de connexion de chaque utilisateur.

• homectl prend désormais en charge un mode --offline,

  • grâce auquel certaines propriétés du compte peuvent être modifiées sans déverrouiller le répertoire personnel.

• systemd-logind a acquis une nouvelle méthode org.freedesktop.login1.Manager.ListSessionsEx()

  • qui fournit des métadonnées supplémentaires par rapport à ListSessions().
  • loginctl l'utilise pour lister des champs supplémentaires dans les sessions de liste.

• systemd-logind a gagné une nouvelle méthode org.freedesktop.login1.Manager.Sleep()

  • qui redirige automatiquement vers SuspendThenHibernate(), Suspend(), HybridSleep() ou Hibernate(),
    • selon ce qui est pris en charge et configuré,
      • une nouvelle paramètre de configuration SleepOperation=,
      • ainsi qu'une méthode d'assistance associée org.freedesktop.login1.Manager.CanSleep()
      • et une propriété org.freedesktop.login1.Manager.SleepOperation.
      • systemctl sleep appelle la nouvelle méthode pour mettre automatiquement la machine en veille de la manière la plus appropriée.

• systemctl sleep appelle une nouvelle méthode pour mettre automatiquement la
  machine dans le mode sommeil de la manière la plus appropriée.

systemd-creds, mécanisme de gestion des authentifications, pour arrêter de balancer du mot de passe en clair partout

• systemd-creds fournit désormais une API Varlink IPC pour chiffrer et déchiffrer les informations d'identification.

• La sélection de clé tpm2-absent de systemd-creds a été renommée en null, puisque c'est ce qu'elle fait réellement :

  • chiffrer et signer avec une clé nulle fixe.
  • --with-key=null ne doit être utilisé que dans des cas très spécifiques,
  • car il n'offre aucune protection en matière d'intégrité ou de confidentialité.
  • c'est-à-dire qu'il n'est sûr à utiliser comme solution de secours que dans des environnements dépourvus à la fois d'un TPM et d'un accès au système de fichiers racine pour utiliser la clé de chiffrement de l'hôte, ou lorsque l'intégrité est assurée d'une autre manière.

• systemd-creds a obtenu un nouveau commutateur --allow-null.

  • S'il est spécifié, le verbe decrypt décodera les informations d'identification chiffrées qui utilisent la clé null
  • Par défaut, cela est refusé, car l'utilisation de la clé null annule le cryptage authentifié normalement effectué.

De quoi mettre en veille et mettre en veille prolongée

• Le fichier de configuration sleep.conf a obtenu un nouveau paramètre MemorySleepMode=

  • pour configurer le mode veille plus en détail.

• Un nouveau petit service systemd-hibernate-clear.service a été ajouté

  • qui efface les informations d'hibernation de la variable EFI HibernateLocation,
    • au cas où le périphérique de reprise disparaîtrait.
    • Normalement, cette variable est censée être nettoyée par le code qui lance l'image de reprise depuis l'hibernation.
    • Mais lorsque le périphérique est manquant et que ce code ne s'exécute pas,
    • ce service effectuera désormais le travail nécessaire, garantissant qu'aucune information d'image d'hibernation obsolète ne reste lors des démarrages suivants.

Espaces de noms utilisateurs non privilégiés et gestion des montages de disques

• Un nouveau petit service systemd-nsresourced.service a été ajouté.

  • Il fournit une API Varlink IPC qui attribue une plage UID/GID de 64 Ko gratuite et allouée de manière transitoire à un espace de noms d'utilisateur non initialisé fourni par un client. Il peut être utilisé pour implémenter des gestionnaires de conteneurs sans privilèges et d'autres programmes nécessitant des plages d'ID utilisateur dynamiques. Il fournit également des interfaces pour déléguer ensuite des descripteurs de fichiers de montage, des groupes de contrôle et des interfaces réseau aux espaces de noms utilisateur configurés de cette manière.

• Un nouveau petit service systemd-mountfsd.service a été ajouté.

  • Il fournit une API Varlink IPC pour monter des images DDI et renvoyer un ensemble de descripteurs de fichiers de montage pour celles-ci. Si un espace de noms utilisateur fd est fourni en entrée, alors les montages sont enregistrés avec l'espace de noms utilisateur. Pour garantir la confiance dans l'image, elle doit fournir des informations Verity (ou bien une authentification polkit interactive est requise).

• L'outil systemd-dissect peut désormais accéder aux DDI sans aucun privilège en utilisant systemd-nsresourced/systemd-mountfsd.

• Si le gestionnaire de services s'exécute sans privilèges (c'est-à-dire systemd --user),

  • il prend désormais en charge RootImage= pour accéder aux images DDI, également implémenté via systemd-nsresourced/systemd-mountfsd.

• systemd-nspawn peut désormais fonctionner sans privilèges,

  • si un DDI approprié est fourni via --image=, encore une fois implémenté via systemd-nsresourced/systemd-mountfsd.

Divers changements

• timedatectl et machinectl ont obtenu l'option -P,
  • un alias pour --value --property=….

• Divers outils permettant d'imprimer joliment les fichiers de configuration mettront désormais en évidence les directives de configuration.

• varlinkctl a obtenu le support du transport ssh:.

  • Cela nécessite OpenSSH 9.4 ou plus récent.

• systemd-sysext a obtenu la prise en charge de l'activation des extensions système de manière mutable,

  • où un répertoire supérieur inscriptible est stocké sous /var/lib/extensions.mutable/,
  • et une nouvelle option --mutable= pour configurer ce comportement.
  • Un mode « éphémère » n'est pas non plus pris en charge lorsque la couche mutable est configurée pour être un tmpfs qui est automatiquement libéré lorsque les extensions système sont rattachées.

• Les coredumps sont désormais conservés pendant deux semaines par défaut (au lieu de trois jours comme auparavant).

• Le paramètre portablectl --copy= a obtenu un nouvel argument mixte,

  • qui entraînera la liaison des ressources appartenant au système d'exploitation
  • (par exemple : les profils portables) mais aux ressources appartenant à l'image portable à copier (par exemple les fichiers unitaires et les images elles-mêmes).

• systemd enregistrera désormais les types MIME de ses divers types de fichiers

  • (par exemple, fichiers journaux, DDI, informations d'identification cryptées…) via l'infrastructure d'informations mime partagées XDG.
  • (Les fichiers de ces types seront ainsi reconnus comme leur propre élément dans les gestionnaires de fichiers de bureau tels que les fichiers GNOME.)

• systemd-dissect affichera désormais la taille de secteur détectée d'un DDI donné dans sa sortie par défaut.

• systemd-portabled génère désormais des messages de journal structurés reconnaissables chaque fois qu'un service portable est attaché ou détaché.

• La vérification de la signature Verity dans l'espace utilisateur (c'est-à-dire la vérification par rapport aux clés /etc/verity.d/) lors de l'activation des DDI peut désormais être activée/désactivée

  • via une option de ligne de commande du noyau systemd.allow_userspace_verity=
  • et une variable d'environnement SYSTEMD_ALLOW_USERSPACE_VERITY=.

• La gestion des quotas du système de fichiers ext4/xfs a été retravaillée,

  • de sorte que quotacheck et quotaon soient désormais invoqués en tant que services basés sur un modèle par système de fichiers
  • (par opposition à des singletons uniques à l'échelle du système), de style similaire à la logique fsck, growfs, pcrfs.
  • Cela signifie que les systèmes de fichiers avec quota activé peuvent désormais être raisonnablement activés au moment de l'exécution du système, et pas seulement au démarrage.

• systemd-analyze dot affichera désormais également les dépendances BindsTo=.

• systemd-debug-generator a acquis la possibilité d'ajouter des unités arbitraires en fonction de leur transmission via les informations d'identification du système.

• Une nouvelle option de ligne de commande du noyau systemd.default_debug_tty= peut être utilisée pour spécifier le TTY pour le shell de débogage, indépendamment de son activation ou de sa désactivation.

• portablectl a obtenu un nouveau commutateur --clean qui efface les données d'un service portable (cache, logs, state, runtime, fdstore) lors de son détachement.

Documentations

• La documentation restante qui se trouvait sur https://freedesktop.org/wiki/Software/systemd/ a été déplacée vers https://systemd.io/.

• Un nouveau laïus décrivant les interfaces virtuelles d'intégration de systemd a été ajouté :

• La page de manuel sd_notify() contient des exemples de code C et Python qui montrent comment implémenter l'interface dans ces langages sans impliquer libsystemd.

Contributeurs

Contributions from: A S Alam, AKHIL KUMAR,
Abraham Samuel Adekunle, Adrian Vovk, Adrian Wannenmacher,
Alan Liang, Alberto Planas, Alexander Zavyalov, Anders Jonsson,
Andika Triwidada, Andres Beltran, Andrew Sayers,
Antonio Alvarez Feijoo, Arthur Zamarin, Artur Pak, AtariDreams,
Benjamin Franzke, Bernhard M. Wiedemann, Black-Hole1, Bryan Jacobs,
Burak Gerz, Carlos Garnacho, Chandra Pratap, Chris Simons,
Christian Wesselhoeft, Clayton Craft, Colin Geniet, Colin Walters,
Costa Tsaousis, Cristian Rodríguez, Daan De Meyer,
Damien Challet, Dan Streetman, David Tardon, David Venhoek,
Diego Viola, Dionna Amalie Glaze, Dmitry Konishchev,
Edson Juliano Drosdeck, Eisuke Kawashima, Eli Schwartz,
Emanuele Giuseppe Esposito, Eric Daigle, Evgeny Vereshchagin,
Felix Riemann, Fernando Fernandez Mancera, Florian Schmaus,
Franck Bui, Frantisek Sumsal, Friedrich Altheide,
Gabríel Arthúr Pétursson, Gaël Donval, Georges Basile Stavracas Neto,
Gerd Hoffmann, GNOME Foundation, Guido Leenders,
Guilhem Lettron, Göran Uddeborg, Hans de Goede, Harald Brinkmann,
Heinrich Schuchardt, Henry Li, Holger Assmann, Ivan Kruglov,
Ivan Shapovalov, Jakub Sitnicki, James Muir, Jan Engelhardt,
Jan Macku, Jeff King, JmbFountain, Joakim Nohlgård,
Jonathan Conder, Julius Alexandre, Jörg Behrmann, Keian, Kirk,
Kristian Klausen, Krzesimir Nowak, Lars Ellenberg,
Lennart Poettering, Luca Boccassi, Ludwig Nussel, Lukáš Nykrýn,
Luna Jernberg, Luxiter, Maanya Goenka, Mariano Giménez,
Markus Merklinger, Martin Ivicic, Martin Srebotnjak,
Martin Trigaux, Martin Wilck, Matt Layher, Matt Muggeridge,
Matteo Croce, Matthias Lisin, Max Gautier, Max Staudt, MaxHearnden,
Michael Biebl, Michal Koutný, Michal Sekletár, Mike Gilbert,
Mike Yuan, Mikko Ylinen, MkfsSion, MrSmör, Nandakumar Raghavan,
Nick Cao, Nick Rosbrook, Norbert Lange, Ole Peder Brandtzæg,
Ondrej Kozina, Oğuz Ersen, Pablo Méndez Hernández,
Pierre GRASSER, Piotr Drąg, QuonXF, Rafaël Kooi, Raito Bezarius,
Rasmus Villemoes, Reid Wahl, Renjaya Raga Zenta, Richard Maw,
Roland Hieber, Ronan Pigott, Rose, Ross Burton, Sam Leonard,
Samuel BF, Sarvajith Adyanthaya, Sergei Zhmylev, Sergey A, Shulhan,
SidhuRupinder, Simon Fowler, Sludge, Stuart Hayhurst, Susant Sahani,
Takashi Sakamoto, Temuri Doghonadze, Thilo Fromm, Thomas Blume,
TobiPeterG, Tobias Fleig, Tomáš Pecka, Topi Miettinen,
Tycho Andersen, Unique-Usman, Usman Akinyemi, Vasiliy Kovalev,
Vasiliy Stelmachenok, Vishal Chillara Srinivas, Vitaly Kuznetsov,
Vito Caputo, Vladimir Stoiakin, Werner Sembach, Will Springer,
Winterhuman, Xiaotian Wu, Yu Watanabe, Yuri Chornoivan,
Zbigniew Jędrzejewski-Szmek, Zmyeir, aslepykh, chenjiayi,
cpackham-atlnz, cunshunxia, djantti, hfavisado, hulkoba, ksaleem,
medusalix, mille-feuille, mkubiak, mooo, msizanoen, networkException,
nl6720, r-vdp, runiq, sam-leonard-ct, samuelvw01, sharad3001, sushmbha,
wangyuhang, zzywysm, İ. Ensar Gülşen, Łukasz Stelmach,
Štěpán Němec, 我超厉害, 김인수

— Edinburgh, 2024-06-11

Vous êtes invité à télécharger l'archive tar ici si vous souhaitez le compiler vous-même.

Le collectif « Convergences Numériques », qui regroupe dix organisations professionnelles du numérique françaises, dont Numeum et le Cigref (mais pas le CNLL), avait organisé jeudi dernier une soirée pour à la fois présenter un « manifeste » concernant la politique européenne du numérique, et pour auditionner 7 représentants des listes candidates aux élections européennes de juin prochain.

Sur les 10 pages du manifeste, une seule proposition concerne le logiciel libre: « Encourager l’Europe à soutenir l’open source : largement adopté par les entreprises et administrations françaises, l’open source est un atout majeur pour répondre aux défis de l’indépendance technologique et de la transition écologique. » C'est peu, compte-tenu notamment du fait que le logiciel libre représente plus de 10% du chiffre d'affaire annuel de la filière informatique (logiciels et services) en France et un peu moins de 10% en Europe (source: étude Markess 2022 pour le CNLL, Numeum et Systematic), et que la stratégie de la Commission pour l'Open Source s'arrête à 2023.

Lors des auditions, seuls deux candidats ont parlé du logiciel libre, y consacrant chacun l'essentiel de leur temps de parole: Sven Franck, co-tête de liste du parti Volt, et Pierre Beyssac, numéro 2 de la liste du Parti Pirate. Sven Franck a notamment présenté l'intérêt du logiciel libre pour la souveraineté et la compétitivité européennes, et Pierre Beyssac l'importance d'une forme de souveraineté numérique « personnelle » en plus d'une vision plus « étatique » de la souveraineté.

Notons enfin que le CNLL a publié en mars un questionnaire adressés aux partis politiques qui souligne l'importance stratégique du logiciel libre pour la souveraineté numérique, l'innovation et les valeurs démocratiques de l'Europe. Il invite les candidats à partager leur vision et leurs propositions sur un large éventail de sujets liés au logiciel libre, notamment la gouvernance numérique, l'éducation et la formation, le soutien aux PME, l'innovation, les politiques spécifiques et la collaboration. Les questions portent sur des aspects concrets tels que la promotion du logiciel libre dans l'administration publique, l'accès aux marchés pour les PME, les programmes de financement, l'interopérabilité, l'inclusion sociale et la durabilité numérique.

À ce jour, aucune réponse n'a été reçue (malgré de multiples relances), et seuls Volt et le Parti Pirate se sont engagés à répondre. Notons pour finir que des propositions en faveur du logiciel libre sont détaillées dans leurs programmes (cliquez sur "lire la suite" pour en savoir un peu plus).

À propos des programmes des partis

Les propositions relatives au logiciel libre du programme du Parti Pirate se trouvent sur cette page et celles de Volt dans ce PDF (p. 73).

Les deux partis vont dans le même sens d'un soutien affirmé au logiciel libre, mais le Parti Pirate entre davantage dans les détails et propose un programme plus exhaustif et radical de transition vers l'open source, là où Volt en reste à des propositions plus générales. Les motivations mises en avant diffèrent également en partie.

Convergences

Les programmes de Volt et du Parti Pirate concernant le logiciel libre présentent plusieurs points de convergence:

1. Les deux partis soutiennent la publication sous licence open source des logiciels développés grâce à des fonds publics, afin de garantir leur transparence et leur réutilisation.
2. Ils souhaitent tous deux promouvoir l'utilisation de logiciels libres et formats ouverts dans l'administration publique.
3. Ils proposent de soutenir financièrement le développement de l'écosystème du logiciel libre et des technologies open source.
4. Ils veulent éviter de rendre de facto obligatoire l'usage de formats propriétaires dans les communications avec l'administration.

Différences

1. Le Parti Pirate va plus loin dans les détails et les mesures concrètes proposées (migration du secteur public vers le libre, création d'OSPO dans les États membres, licences copyleft, compatibilité multi-plateformes des logiciels publics, accès aux données publiques…).
2. Le Parti Pirate insiste davantage sur les enjeux de transparence, d'autonomie et de vie privée des utilisateurs, tandis que Volt met plus l'accent sur la pérennité de l'écosystème.
3. Le Parti Pirate veut éviter de soumettre le développement de logiciel libre aux mêmes contraintes que le logiciel propriétaire, point qui n'est pas abordé par Volt.
4. Volt propose de responsabiliser les intégrateurs sur la conformité des logiciels libres déployés, ce qui n'apparaît pas dans le programme du Parti Pirate.

Les propositions des autres partis

À ce jour, et malgré des dizaines de courriels envoyés aux autres partis, nous n'avons pas identifié de propositions concernant le logiciel libre dans les programmes des autres partis. Si vous avez des contacts au sein de ces partis, n'hésitez pas à relayer cette information. Une nouvelle dépêche sera publiée si nous arrivons à obtenir des réponses.

Cloonix est un outil d’aide à la construction de réseau virtuel. Il est basé sur Open vSwitch pour l’émulation du réseau constitué de switchs et LANs virtuels, sur crun et les namespaces pour la gestion de conteneurs et sur KVM pour ce qui concerne l’émulation des machines complètes.
Cloonix peut être considéré comme un hyperviseur qui permet de lancer des scénarios de démonstration impliquant des réseaux connectant de nombreuses machines virtuelles ou conteneurs. Ce logiciel open source permet d’automatiser et de rejouer des scénarios complets.

FRR est le logiciel open source qui permet de transformer une machine Linux en l’équivalent d’un routeur professionnel, ce logiciel implémente tous les protocoles de routage classique.

Podman est exactement comme Docker, un gestionnaire de conteneur.

Le but de cette dépêche est de présenter une démonstration qui tourne dans un podman et qui met en œuvre un réseau d’une soixantaine de conteneurs et qui peut être lancé en tant qu’utilisateur simple sans les droits root.

Il y a le lien « demo » qui montre une vidéo un peu accélérée de cette démonstration qui démarre les machines, les configure et les met en réseau. On peut ensuite y voir la convergence du protocole OSPF.

Il y a quelques années, je vous avais présenté TuxMake, un utilitaire pour faciliter la (cross-)compilation du noyau Linux supportant une grande variété de toolchains différentes : TuxMake et le noyau Linux.

TuxMake facilitant la compilation du noyau Linux, nous nous sommes alors attaqués à rendre l’exécution de ces noyaux plus aisée : ainsi est né TuxRun.

Exemples

TuxRun propose une interface en ligne de commande simple pour exécuter un noyau dans QEMU. TuxRun se charge de fournir un environnement suffisant pour démarrer le noyau avec QEMU.

tuxrun --device qemu-arm64 \
       --kernel https://example.com/arm64/Image

TuxRun va alors télécharger le noyau et un système de fichier compatible avec ARM64 puis lancer qemu-system-arm64 avec les bons arguments et afficher les logs du boot.

La ligne de commande de qemu générée par TuxRun est la suivante :

/usr/bin/qemu-system-aarch64 \
    -cpu max,pauth-impdef=on \
    -machine virt,virtualization=on,gic-version=3,mte=on \
    -nographic -nic none -m 4G -monitor none -no-reboot -smp 2 \
    -kernel /.../Image \
    -append "console=ttyAMA0,115200 rootwait root=/dev/vda debug verbose console_msg_format=syslog systemd.log_level=warning earlycon" \
    -drive file=/.../rootfs.ext4,if=none,format=raw,id=hd0 \
    -device virtio-blk-device,drive=hd0

Il est également possible de lancer une suite de tests directement depuis la ligne de commande :

tuxrun --device qemu-arm64 \
       --kernel https://example.com/arm64/Image \
       --tests ltp-smoke

Les résultats de la suite de test seront analysés par TuxRun et la valeur de retour de TuxRun sera 0 uniquement si la suite de tests passe intégralement. Ceci permet d’utiliser TuxRun pour valider qu’une suite de tests donnée fonctionne toujours correctement sur un nouveau noyau.

Architectures

QEMU

Grâce à QEMU, TuxRun supporte de nombreuses architectures:
- ARM: v5/v7/v7be/64/64be
- Intel/AMD: i386/x86_64
- MIPS: 32/32el/64/64el
- PPC: 32/64/64le
- RISCV: 32/64
- sh4, sparc64, …

La liste complète est disponible dans la documentation.

FVP

Il est également possible d’utiliser FVP, le simulateur de ARM pour simuler un processeur ARMv9. FVP est un simulateur bien plus précis que QEMU au prix d’un temps d’exécution bien supérieur.

FVP permettant de configurer et simuler de nombreux composants du processeur, TuxRun propose une configuration permettant de démarrer et tester Linux dans un temps raisonnable.

tuxrun --device fvp-aemva \
       --kernel https://example.com/arm64/Image \
       --tests ltp-smoke \
       --image tuxrun:fvp

ARM ne permettant pas (pour le moment) de redistribuer les binaires FVP, il faut construire localement le container tuxrun:fvp.

Système de fichiers

Par défaut, TuxRun télécharge et utilise un système de fichier compatible avec l’architecture cible. TuxRun fournit donc 20 systèmes de fichiers différents, un pour chaque architecture disponible.

Ces systèmes de fichiers sont basés sur buildroot et comportent les outils nécessaires pour faire tourner la majorité des suites de tests supportés par TuxRun. La liste complète est disponible dans la documentation.

Il est également possible d’utiliser un autre système de fichiers :

tuxrun --device qemu-arm64 \
       --kernel https://example.com/Image \
       --rootfs https://example.com/rootfs.ext4.zst

Runtimes

TuxRun télécharge et utilise un container que nous maintenons. Ce container inclut l’ensemble des binaires nécessaires ainsi que QEMU. Par défaut, TuxRun utilise toujours la dernière version du container disponible.

Il est cependant possible de spécifier une version particulière afin de reproduire plus facilement une erreur. Les nouvelles versions de QEMU introduisent quelques fois des régressions dans les suites de tests. Il est alors nécessaire d’utiliser exactement la même image pour reproduire le problème.

Reproduire un test

TuxRun est utilisé, via tuxsuite notre service de compilation et de test dans le cloud, par le projet LKFT (Linux Kernel Functional Testing) de Linaro. Lorsqu’une régression est détectée, il suffit de fournir la ligne de commande TuxRun pointant sur les artefacts utilisés pour pouvoir reproduire le problème.

Les développeurs du noyau sont alors à même de reproduire et de corriger les régressions détectées par LKFT. TuxRun simplifie ainsi énormément la reproduction du test.

Un exemple parmi tant d’autres : selftests: sigaltstack: sas…

Installation

TuxRun étant un programme Python, il est possible de l’installer depuis pypi :

python3 -m pip install tuxrun

Nous fournissons également un paquet Debian, et un rpm.

TuxMake et Tuxrun

Dans un prochain article, je vous montrerai comment combiner TuxMake et TuxRun pour automatiquement trouver le commit responsable de la régression dans le noyau.

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

Malgré les risques concernant la stabilité d’une version Beta, il est important de la tester ! En rapportant les bogues maintenant, vous découvrirez les nouveautés avant tout le monde, tout en améliorant la qualité de Fedora Linux 40 et réduisant du même coup le risque de retard. Les versions en développement manquent de testeurs et de retours pour mener à bien leurs buts.

La version finale est pour le moment fixée pour le 16 ou 23 avril.

Sommaire

• Expérience utilisateur
• Gestion du matériel
• Internationalisation
• Administration système
• Développement
• Projet Fedora
• Tester

Expérience utilisateur

• Passage à GNOME 46 ;
• L'environnement de bureau KDE Plasma change de version majeure avec sa nouvelle version 6 ;
• Le fichier firefox.desktop est renommé en org.mozilla.firefox.desktop pour permettre son utilisation dans la barre de recherche de GNOME.

Gestion du matériel

• Fourniture de ROCm 6 pour améliorer la prise en charge de l'IA et le calcul haute performance pour les cartes graphiques AMD ;
• Passage à l'étape 2 de la prise en charge du noyau unifié nommée UKI (donc unifiant noyau, initrd, ligne de commande du noyau et signature) pour les plateformes avec UEFI mais rien ne change par défaut à ce sujet.

Internationalisation

• Le gestionnaire d'entrée de saisie IBus passe à la version 1.5.30 ;
• Mise à jour de ibus-anthy 1.5.16 pour la saisie du japonais.

Administration système

• NetworkManager tente de détecter par défaut les conflits d'usage d'adresse IPv4 avec le protocole Address Conflict Detection avant de l'attribuer à la machine ;
• NetworkManager va utiliser une adresse MAC aléatoire par défaut pour chaque réseau Wifi différent, et cette adresse sera stable pour un réseau donné. Cela permet de concilier vie privée et confort d'utilisation ;
• Les unités système de systemd vont utiliser par défaut beaucoup d'options pour améliorer la sécurité des services ;
• Les entrées des politiques SELinux qui font référence au répertoire /var/run font maintenant référence au répertoire /run ;
• L'outil SSSD ne prend plus en charge les fichiers permettant de gérer les utilisateurs locaux ;
• DNF ne téléchargera plus par défaut la liste des fichiers fournie par les différents paquets ;
• L'outil fwupd pour mettre à jour les firmwares va utiliser passim comme cache pour partager sur le réseau local les métadonnées liées aux mises à jour disponibles pour les firmwares ;
• Les systèmes Fedora Silverblue et Kinoite disposent de bootupd pour la mise à jour du chargeur de démarrage ;
• Le paquet libuser est marqué en voie de suppression pour Fedora 41 alors que le paquet passwd est supprimé ;
• Le paquet cyrus-sasl-ntlm a été supprimé ;
• La gestion des droits utilisateurs pam_userdb passe de la base de données BerkeleyDB à GDBM ;
• Le filtre antispam bogofilter utilise SQLite au lieu de BerkeleyDB pour gérer sa base de données interne ;
• Le serveur LDAP 389 passe de la version 2.4.4 à la version 3.0.0 ;
• Le paquet iotop est remplacé par iotop-c ;
• L'orchestrateur de conteneurs Kubernetes évolue de la version 1.28 à la version 1.29 ;
• Par ailleurs ses paquets sont restructurés ;
• Pendant que podman est mis à jour vers la version 5 ;
• Le paquet wget2 remplace le paquet wget en fournissant une nouvelle version ;
• Le gestionnaire de base de données PostgreSQL migre vers sa 16e version ;
• Les paquets MySQL et MariaDB sont remaniés et mis à jour vers la version 10.11.

Développement

• Mise à jour de la suite de compilation GNU : GCC 14.0, binutils 2.41, glibc 2.39 et gdb 14.1 ;
• La suite de compilateurs LLVM est mise à jour à la version 18 ;
• Mise à jour de la bibliothèque C++ Boost à la version 1.83 ;
• Le langage Go passe à la version 1.22 ;
• Le JDK de référence pour Java passe de la version 17 à 21 ;
• Mise à jour du langage Ruby 3.3 ;
• Le langage PHP utilise la version 8.3 ;
• La boîte à outils pour le machine learning PyTorch fait son entrée dans Fedora ;
• Le paquet python-sqlalchemy utilise la nouvelle branche majeure 2.x du projet, le paquet python-sqlalchemy1.4 est proposé pour garder la compatibilité ;
• La bibliothèque de validation des données Pydantic utilise dorénavant la version 2 ;
• La bibliothèque Thread Building Blocks passe du fil 2020.3 au fil 2021.8 ;
• La bibliothèque OpenSSL 1.1 est supprimée ne laissant que la dernière version de la branche 3.x ;
• Les bibliothèques zlib et minizip utilisent leur variante zlib-ng et minizip-ng dorénavant ;
• Le langage Python ne bénéficie plus de la version 3.7.

Projet Fedora

• L'édition Cloud sera construite avec l'utilitaire Kiwi dans Koji ;
• Tandis que l'édition Workstation aura son ISO générée avec l'outil Image Builder ;
• L'image minimale ARM sera construite avec l'outil OSBuild ;
• Fedora IoT bénéficiera d'images Bootable Containers ;
• Il bénéficiera également des images Simplified Provisioning ;
• Et le tout sera construit en utilisant rpm-ostree unified core ;
• Fedora sera construit avec DNF 5 en interne ;
• Les macros forge passent du paquet redhat-rpm-config à forge-srpm-macros ;
• La construction des paquets échouera si l'éditeur de lien détecte certaines classes de vulnérabilité dans le binaire en construction ;
• Phase 3 de l'usage généralisé des noms abrégés de licence provenant du projet SPDX pour la licence des paquets plutôt que des noms du projet Fedora ;
• Clap de fin pour la construction des mises à jour au format Delta RPM ;
• Suite du projet de ne générer les JDKs qu'une fois, et les rempaqueter ainsi à toutes les variantes du système ;
• Compilation des paquets en convertissant plus d'avertissements comme erreurs lors de la compilation des projets avec le langage C ;
• Les images immuables comme Silverblue seront nommées sous la dénomination Atomic pour éviter la référence au terme immuable qui est confus pour les utilisateurs.

Tester

Durant le développement d'une nouvelle version de Fedora Linux, comme cette version Beta, quasiment chaque semaine le projet propose des journées de tests. Le but est de tester pendant une journée une fonctionnalité précise comme le noyau, Fedora Silverblue, la mise à niveau, GNOME, l’internationalisation, etc. L'équipe d'assurance qualité élabore et propose une série de tests en général simples à exécuter. Il suffit de les suivre et indiquer si le résultat est celui attendu. Dans le cas contraire, un rapport de bogue devra être ouvert pour permettre l'élaboration d'un correctif.

C'est très simple à suivre et requiert souvent peu de temps (15 minutes à une heure maximum) si vous avez une Beta exploitable sous la main.

Les tests à effectuer et les rapports sont à faire via la page suivante. J'annonce régulièrement sur mon blog quand une journée de tests est planifiée.

Si l'aventure vous intéresse, les images sont disponibles par Torrent ou via le site officiel.

Si vous avez déjà Fedora Linux 39 ou 38 sur votre machine, vous pouvez faire une mise à niveau vers la Beta. Cela consiste en une grosse mise à jour, vos applications et données sont préservées.

Nous vous recommandons dans les deux cas de procéder à une sauvegarde de vos données au préalable.

En cas de bogue, n'oubliez pas de relire la documentation pour signaler les anomalies sur le BugZilla ou de contribuer à la traduction sur Weblate. N'oubliez pas de consulter les bogues déjà connus pour Fedora 40.

Bons tests à tous !

Suite à la dépêche Comparatif : GrapheneOS vs LineageOS, je souhaitais faire part d’un retour d’expérience sur l’utilisation de GrapheneOS sur un téléphone Android Pixel 7a. Ce commentaire est repris ici sous forme de dépêche.

Sommaire

• PixelOS
  • Installation
  • Interface
  • Fonctionnalités spécifiques/avancées de PixelOS
• GrapheneOS
  • Installation
  • Interface
  • Applications et « stores »
  • Gestion des autorisations
  • Séparation des usages
  • Détail des approches suivies
    • 1ʳᵉ approche
    • 2ᵉ approche (test en cours)
    • 3ᵉ approche (d’ici une semaine)
  • Détails : utilisation sans les services Google
    • Synchronisation des contacts & agendas
    • Quid des applications non libres hébergées sur le play store
  • Détails : Utilisation avec les services Google
    • Dans un profil séparé
    • Via la fonction « work profile » d’Android
• Conclusion, cas d’usages et « threat model » (modèle de menace)
  • Sécurité
  • Vie privée
  • Facilité d’utilisation
  • Note : l’impact du matériel (« hardware ») sur la vie privée

Le point de départ est celui d’un utilisateur sensible aux logiciels libres mais qui utilise un téléphone Android Samsung « comme tout le monde », avec :

• Utilisation du Google Play Store, avec un compte Google personnel
• Utilisation d’un compte Google professionnel
• Utilisation du Samsung store, avec un compte Samsung
• Utilisation d’une montre connectée Samsung avec appli Samsung health

L’utilisateur a déjà expérimenté par le passé les solutions suivantes :

• UbuntuOS (abandonné rapidement par manque d’applications)
• LineageOS, avec Micro-G + « signature spoofing » pour permettre l’installation des applications bancaires

PixelOS

Installation

La mise en œuvre du système « stock » installé sur le smartphone est très facile et simple d’utilisation. Les téléphones Pixel proposent des fonctionnalités « avancées » spécifiques qui sont proposées au démarrage, avec à chaque fois le jeu de « voulez-vous activer cette fonctionnalité ? Si oui, acceptez le contrôle des données suivantes… »
On est dans un environnement full google, donc avec quelques habitudes à changer me concernant venant d’un environnement Samsung (la surcouche de l’OS est différente).

Interface

Launcher Pixel avec une barre de recherche Google qui ne peut pas être enlevée (The search bar cannot be removed from the bottom of the home screen, it's part of the Pixel Launcher https://support.google.com/pixelphone/thread/133065648/is-there-any-way-to-remove-the-google-search-bar-from-the-home-screen?hl=en), sinon tout est fluide / "beau"

Fonctionnalités spécifiques/avancées de PixelOS

• Déblocage du téléphone par reconnaissance faciale (probablement un cauchemar en termes de privacy, mais je pourrais comprendre pourquoi une personne lambda souhaiterait activer ce service)
• « Double tap » au dos du téléphone pour lancer une action (dans mon cas : la lampe torche)
  • On peut utiliser Torchie pour une fonctionnalité proche (https://f-droid.org/fr/packages/in.blogspot.anselmbros.torchie/)
  • Les fonctions d’urgence « avancées » fournies par l’application « sécurité personnelle » (https://play.google.com/store/apps/details?id=com.google.android.apps.safetyhub&hl=fr&gl=US)
  • L’application est disponible sur le playstore mais ne fonctionne pas sur GrapheneOS
  • Il existe une fonction d’urgence « de base » dans GrapheneOS (AOSP ?) (appuyer 5x sur power pour lancer un appel d’urgence vers le 112)
  • Dans PixelOS, il y a un conflit de raccourcis entre « appuyer 5x sur power pour lancer un appel d’urgence » et l’option « appuyer 2x pour lancer l’appareil photo » (quand les deux sont activées : l’appareil photo prend le dessus)
• Paiements NFC (non accessibles sur GrapheneOS)
  • Certaines applications de paiement autres que Google Wallet peuvent fonctionner (par ex. Paylib)
• Fonctionnalité « bien être numérique », notamment le fait de passer l’écran en noir & blanc à partir d’une certaine heure pour tenter de limiter le temps devant les écrans. L’application existe dans le Play Store (https://play.google.com/store/apps/details?id=com.google.android.apps.wellbeing&hl=fr&gl=US) mais impossible à retrouver depuis le client Play Store sur le téléphone.
  • Il existe probablement des alternatives

GrapheneOS

Installation

Procédure d’installation web très simple et rassurante. C’est la première fois que je me verrai recommander ce type d’install à un utilisateur non technique (alors que la procédure d’install de LineageOS - à l’époque ou j’ai essayé - est complexe et obscure, avec le risque de se planter à plusieurs étapes).

Interface

• Le bureau par défaut est très minimaliste et pas très accueillant (je sais que cela peut paraître peu important, mais le fond noir + icônes en noir & blanc peut rebuter / n’est pas aussi accueillant que le système de base).
  • Possibilité d’utiliser un launcher alternatif : j’ai fini sur Lawnchair après en avoir testé plusieurs
  • Possibilité de changer le fond d’écran : Muzei (https://f-droid.org/fr/packages/net.nurik.roman.muzei/) / Walman (https://apt.izzysoft.de/fdroid/index/apk/com.colorata.wallman)
• Le clavier par défaut m’a dérangé (après des années à utiliser le clavier Gboard), surtout pour l’écriture « swipe » (que je pratique souvent quand j’écris un message à une main).
  • Possibilité d’utiliser un clavier alternatif : Home:FlorisBoard (https://f-droid.org/fr/packages/dev.patrickgold.florisboard/) est pas mal, il inclut une fonction « swipe » mais qui n’est pas aussi précise

Applications et « stores »

• Le « store » par défaut « Apps » contient le minimum vital.
  • Pour le compléter, je suis passé par l’application Droid-Ify (https://droidify.eu.org/ ou https://github.com/Droid-ify/client) dans lequel j’ai activé les dépôts F-droid et Home:IzzyOnDroid

Pour le Store Google, il est possible d’installer plusieurs « briques » de l’éco-système :

• Google Services Framework (GSF), dont dépendent :
  • Google Play services + Google Play Store (interdépendants) On peut donc choisir : rien du tout, GSF pour les applis qui en dépendent, ou les trois.

Gestion des autorisations

• Les possibilités sont très fournies = positif (permet de limiter les accès réseau, les accès stockage)
• Les possibilités sont très fournies = complexe à gérer : il faut se poser des questions / passer du temps à configurer les choses.
  • Exemple : la synchronisation des contacts Google ne se fait pas sans la permission « Contacts » dans l’appli « Google Services Framework ».

Séparation des usages

Il existe deux approches possibles de séparation des usages :

• Utilisation d’un « user profile » : il s’agit d’un profil complètement distinct. On peut passer de l’un à l’autre assez facilement. Les deux profils ne peuvent pas se parler, sauf via les notifications croisées (https://www.youtube.com/watch?v=WjrANjvrSzw)
• Utilisation d’un « work profile » : ici on utilise un seul profil, mais à l’intérieur duquel on vient activer la fonctionnalité « work profile » d’Android pour séparer les usages (via une application tierce telle que Shelter, https://www.youtube.com/watch?v=20C0FD7mGDY pour une explication détaillée)

Détail des approches suivies

1ʳᵉ approche

• Profil « owner » avec Shelter
  • Profil « Personnel » = pas de services Google
  • Profil « Professionnel » = Services Google avec compte personnel
• 2ᵉ Profil « Travail » = Services Google avec compte professionnel

Ce qui bloque : je voulais utiliser la fonctionnalité « work profile » d’Android avec Shelter pour isoler mon compte Google personnel. Hors c’est ce compte qui jusqu’ici synchronise les contacts. Les applications par défaut de GrapheneOS ne gèrent pas cette synchro (autrement que via import/export manuel, ou alors je n’ai pas trouvé comment). Si on veut quelque chose qui s’intègre tout seul il faut passer par les applications Google de Téléphone/Contacts/Calendrier. Hors ces applications ne peuvent pas devenir « applications par défaut » (pour remplacer celles existantes de GrapheneOS) dans le « work profile », c’est le profil personnel qui gère cette configuration.

2ᵉ approche (test en cours)

• Profil « owner » (unique, sans Shelter) = Services Google avec compte personnel
• 2ᵉ Profil « Travail » (unique, sans Shelter) = Services Google avec compte professionnel

Ce qui bloque : j’utilise le téléphone à la fois pour le pro & perso, sauf que le fait d’avoir deux profils implique de jongler systématiquement entre les deux profils. Trop compliqué au quotidien.

3ᵉ approche (d’ici une semaine)

• Profil « owner » avec Shelter
  • Profil « standard » = Services Google avec compte personnel
  • Profil « work » = Services Google avec compte personnel

Détails : utilisation sans les services Google

Synchronisation des contacts & agendas

La première problématique c’est la synchro des contacts et des agendas. Pour se passer de Google sur ce point, il faut mettre en place au préalable un service de partage de contact / agenda :

• Nextcloud + DAVx⁵
• https://www.etesync.com/
• https://www.chatons.org/
• NAS Synology + leurs applications (mais uniquement accessibles sur Google Play Store…)

Bref c’est un projet en tant que tel, pas forcément à la portée de tous

Quid des applications non libres hébergées sur le play store

À ce stade, pour accéder à d’éventuelles applications uniquement présentes sur le Play Store, il est possible de :

• passer par l’application Aurora
• passer par apkmirror pour les télécharger une à une

Cependant, de nombreuses applications du Play Store requièrent l’installation du Google Services Framework (« GSF ») pour fonctionner.

Me concernant, j’ai la liste suivante d’applications que j’ai pu récupérer par ce biais (et qui fonctionnent sans GSF) :

• Appli Banque (SG)
• Paiement NFC via Paylib (pas encore testé « en vrai » mais l’appli s’installe sans broncher)
• Deezer (musique)
• Somfy (alarme)
• NetAtmo (thermostat connecté)
• Doctolib (Santé)
• Appli mutuelle (Alan)
• Freebox connect (utilitaire freebox)
• Wifiman (utilitaire réseau)

Certaines applications nécessitent le GSF, c’est le cas notamment de :

• Whatsapp (pour les notifications « push » et pour transfèrer l’historique des messages)
  • Il semble que des transferts « locaux » soient possibles
    • https://faq.whatsapp.com/6181521285295518/?helpref=hc_fnav&cms_platform=android
    • https://faq.whatsapp.com/209942271778103/?helpref=hc_fnav&cms_platform=android
• Bose connect (gestion casque bluetooth Bose qui indique l’erreur « Services Google Play manquants »)
  • Le casque peut fonctionner en bluetooth sans l’application

Détails : Utilisation avec les services Google

Dans un profil séparé

J’ai mis du temps à comprendre / trouver comment activer la fonctionnalité de profils multiples (alors que c’est simple) : Paramètres > Système > Utilisateurs multiples > Autoriser plusieurs utilisateurs (https://www.youtube.com/watch?v=SZ0PKtiXTSs)

Le profil séparé à l’avantage d’être comme un « deuxième téléphone ». C’est aussi un inconvénient pour les personnes qui ne sont pas prêtes à faire cet « effort » (passer de l’un à l’autre), même si les notifications « cross profile » aident sur ce point.
Il faut reproduire sur chacun des profils toutes les « custo » faites (changement de launcher, de clavier, configurations diverses, etc).

Via la fonction « work profile » d’Android

La fonction work profile fournit une séparation moins forte, mais c’est aussi plus « pratique » au quotidien car toutes les applications (et les comptes) sont dans un seul profil. J’ai testé via l’application Shelter.

Avantages :

• Tout est accessible dans le même profil
• Dans le tiroir d’application, on retrouve deux « onglets » séparant les applications « perso » et « pro ».

Inconvénients :

• Comme pour le profil séparé, il y a une « double maintenance »
  • Ex: en cas d’utilisation de deux profils Google Play (profil perso + pro), il faut faire les mises à jour « des deux côtés »
• Il faut bien choisir dans quel contexte on souhaite installer chaque application
• Je n’ai pas trouvé comment faire pour 1. Synchroniser mon compte Google perso dans le « work profile » de Shelter et 2. faire remonter ces informations dans les applications « contacts » et « téléphone » par défaut de GrapheneOS. C’est le profil « Personnel » qui va dicter quelles applications par défaut sont utilisées.

Conclusion, cas d’usages et « threat model » (modèle de menace)

J’ai passé beaucoup plus de temps que prévu à comprendre GrapheneOS, tester différentes solutions et configurer les options / trouver des alternatives. Je suis bien conscient que plusieurs « problèmes » remontés pourraient tout simplement être résolus si j’acceptais de faire les choses différemment. Cela me pousse à m’interroger sur le compromis à choisir entre sécurité / respect de la vie privée / facilité d’utilisation ? Cette question dépend bien sur du modèle de menace (« threat model ») de chacun.

Sécurité

GrapheneOS répondrait parfaitement à des contraintes de sécurité « forte » pour des personnes étant journaliste / activiste / lanceur d’alerte / député. Dans ce cas d’usage, le coût de la sécurité est accepté.

Vie privée

GrapheneOS apporte un choix indéniable permettant à chacun de trouver le meilleur usage possible.

Facilité d’utilisation

Dans mon cas d’usage, je trouve que la fonction de profil séparé apporte trop de friction au quotidien, et je suis prêt à tout rassembler au sein du même profil. L’utilisation de deux téléphones différents (un perso / un pro) pourrait être une alternative. De la même manière, je n’ai pas encore passé le pas de me séparer de mon compte Google (pour la synchro des contacts / agendas), donc pour le moment je continue d’utiliser le Play Store. À terme, j’essaierai de ne plus en dépendre.

Note : l’impact du matériel (« hardware ») sur la vie privée

• Un casque Bluetooth Bose nécessite l’app « Bose Connect » qui dépend de GSF/Play Store
• Un casque Bluetooth Samsung Buds2 Pro nécessite l’app Samsung qui demande la création d’un compte cloud chez eux
• L’application Google Wallet me permet de régler mes courses via paiement NFC, mais donne accès par ce biais à un pan entier de données personnelles

À chaque fois la question est : est-ce utile ou pas ? Puis-je facilement m’en passer ?

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

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

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

Origines de la distribution

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

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

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

Au-delà du besoin initial

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

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

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

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

Philosophie

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

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

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

Synthèse

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

Elle se destine à :

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

Et après…

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

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

Note : cette dépêche est une traduction de l'annonce officielle de la sortie de GIMP 2.99.18 du 21 février 2024 (en anglais).

Voici enfin la dernière version de développement avant GIMP 3 ! Bien que la sortie de la version 2.99.18 soit un peu en retard par rapport au planning espéré, celle-ci contient un certain nombre de fonctionnalités et d'améliorations que nous sommes ravis de pouvoir partager avec vous.

⚠️ ☢️ Nous vous rappelons qu'une version de développement sert à présenter les travaux en cours, mais vous permet aussi de détecter et signaler les problèmes au plus tôt. En d'autres termes, cette version est instable et nous ne recommandons pas son usage en production. Utilisez-là parce que vous voulez aider à améliorer GIMP en signalant des bogues.

En particulier, cette version 2.99.18 est peut-être l'une des versions les plus instables de la série 2.99 à cause du projet « space invasion » (NDT : « invasion venue de l'espace », un jeu de mots avec l'anglais colorspace signifiant espace de couleurs). Cela est parfaitement attendu et normal. ⚠️ ☢️

Sommaire

• L'invasion de l'espace (des couleurs) !
• Amélioration des algorithmes de couleur
• Édition non-destructive, première mouture
• Amélioration de la prise en charge des polices de caractères
• Expansion automatique des calques
• Nouvelles options d'alignement
• Thèmes
• Boîte de dialogue de bienvenue
• Formats de fichiers
  • DDS
  • GIF
  • HEIF et JPEG-XL
  • OpenEXR
  • PDF
  • PNG
  • PSD
  • PSP
  • Nouveaux formats d'image pris en charge : Farbfeld, Esm Software PIX, HEJ2
  • Nouveau format de palette pris en charge : Swatchbooker
• Interactions avec les pads de tablettes graphiques sous Wayland
• Mise à jour de l'API
• GEGL et babl
• Statistiques de sortie
• Nouvelles de l'équipe et procédure de sortie
• Autour de GIMP
  • Des nouvelles des miroirs
  • GIMP sous Windows/ARM
• Télécharger GIMP 2.99.18
• Et ensuite ?

Cette dépêche présente les changements les plus notables et les plus visibles. En particulier, elle ne contient pas de liste exhaustive des correctifs de bogues ou des améliorations un peu moins importantes. Pour une liste plus complète des changements, nous vous invitons à consulter le fichier NEWS ou à jeter un coup d’œil à l'historique du dépôt Git.

L'invasion de l'espace (des couleurs) !

Nous avons travaillé dur sur le projet Space Invasion, qui est — comme vous vous en rappelez peut-être — le nom de code que nous avons donné au projet visant à rendre GIMP plus correct en ce qui concerne les couleurs.

Ces derniers temps, nous avons réalisé le portage des anciennes structures de couleurs utilisées en interne (GimpRGB, GimpCMYK, GimpHSV…) dont nous nous servions pour stocker les informations de couleurs vers GeglColor. Cet objet générique peut contenir n'importe quelle donnée de couleur, quel que soit le modèle colorimétrique, la précision ou l'espace, du moment que ceux-ci sont pris en charge par babl, notre moteur pour l'encodage des pixels.

En ce qui concerne la justesse des couleurs, cela signifie que nous ferons maintenant les conversions de couleurs uniquement si cela est nécessaire (conversions à la dernière minute), ce qui permettra de ne pas perdre d'information lorsque cela peut être évité. Par exemple, imaginons que vous utilisiez la pipette à couleurs sur une image : si nous convertissions cette couleur vers un format intermédiaire avant de l'utiliser sur une autre image (qui peut avoir le même format de couleurs ou un format différent), deux conversions auraient lieu. Cela augmente les possibilités de perte de précision. Ce problème est encore plus flagrant si les formats d'entrée et de sortie sont les mêmes (autrement dit, lorsqu'aucune conversion n'est nécessaire). Et cela sera encore plus problématique lorsque le modèle CMJN sera pris en charge nativement (nous voulons éviter à tout prix de faire un aller-retour entre un format intermédiaire et le CMJN, qui n'a pas de relation bijective avec la plupart des autres modèles de couleurs, même en travaillant sans bornes et en ignorant les problèmes de précision).

Définition d'un espace non borné (ajout par rapport à la dépêche originelle) : lorsque la précision est entière, l'espace est toujours borné (par exemple [0-255] en 8-bit). Par contre, en flottant, où l'espace de travail standard est [0, 1], on peut décider d'accepter les valeurs négatives et supérieures à 1. Cela rend les conversions entre beaucoup d'espaces de couleurs bijectives, aux erreurs de précisions près. Notamment, les conversions entre deux espaces RVB, ou même un espace RVB et divers autres modèles, deviennent bijectives. Ce n'est pas le cas entre RVB et CMJN, même en espace de couleurs infini.

Nous sommes également en train de migrer le stockage des données de couleur vers ce type d'objet générique. Cela signifie entre autres que les palettes de couleurs pourront comporter des couleurs au format CMJN, CIELAB ou bien encore dans tout autre modèle pris en charge (et pas seulement ces couleurs après une étape de conversion vers le sRVB non borné - « unbounded sRGB »).

Une conséquence pour la maintenance logicielle est qu'il sera beaucoup plus facile de gérer les conversions de couleurs au sein de notre code, étant donné que cette structure comprend à la fois les données et leur « signification ». Cela rend la gestion des couleurs beaucoup moins susceptible d'introduire des bogues par rapport à l'approche précédente, qui consistait à faire suivre les deux types d'information séparément.

Finalement, nous travaillons à faire apparaître l'information concernant l'espace de couleurs à plusieurs endroits de l'interface où cela est pertinent, par exemple lorsque des données RVB, CMJN, TSL ou TSV sont affichées ou peuvent être choisies. Les valeurs brutes dans ces modèles de couleurs en l'absence de la connaissance de l'espace de couleurs associé n'ont pratiquement aucun sens. L'affichage dans l'interface de valeurs RVB sans autre précision est un reliquat du passé, lorsque cela signifait le plus souvent sRVB. Cela n'est plus vrai dans un contexte graphique moderne et l'interface devrait être claire à ce sujet.

La vidéo ci-dessous montre quelques aspects de ce travail sur l'interface, par exemple le fait que les modèles RVB, TSV ou CMJN affichent à tout instant l'espace de couleurs dans lequel les valeurs sont considérées (ce qui très souvent correspond au nom du profil ICC). Cela est déjà fait pour la pipette à couleurs, les échantillons de couleurs, l'ancrable des couleurs de premier/d'arrière plan, la boîte de dialogue « Changer la couleur de premier/d'arrière plan », ainsi qu'à d'autres endroits.

Non seulement cela, mais lorsque les gens sélectionnent un profil d’épreuve sur écran et activent l'épreuve sur écran (par exemple grâce à la nouvelle bascule de simulation qui a été ajoutée dans GIMP 2.99.12), nous afficherons également non seulement la zone hors gamme de l'espace colorimétrique de l'image, mais également celle de l'espace d’épreuve.

Invasion de l'espace dans l'interface - GIMP 2.99.18 (cliquez sur l'image pour voir la vidéo sur le compte Peertube de GIMP)

Avertissement très important : il s'agit encore une fois d'un portage énorme dans notre base de code, ce qui a impacté littéralement des milliers de lignes de code. Ce travail est inachevé mais il devra être terminé avant la première version candidate. Des instabilités ou des bugs sont à prévoir dans cette mise à jour donc si vous rencontrez un problème, nous recommandons de le rapporter.

Amélioration des algorithmes de couleur

Øyvind Kolås a amélioré quelques algorithmes internes :

• Les pixels achromatiques de l'outil Teinte-Saturation sont désormais un cas spécial afin que les pixels en niveaux de gris (saturation de 0) ne soient modifiés que par le réglage principal, pas par le réglage rouge.
• Les dégradés en niveaux de gris restent désormais achromatiques même avec "Tramage" coché dans l'outil Dégradé.

Au fur et à mesure que le projet space invasion avance, obtenir des résultats cohérents devient plus facile dans divers algorithmes liés aux couleurs, nous permettant ainsi de découvrir rapidement les problèmes et de les résoudre.

Édition non-destructive, première mouture

Un domaine dans lequel nous sommes « en avance sur le planning » est l'édition non destructive, qui était très demandée ! Les fondations de ces fonctionnalités ont été mises en place par de nombreux développeurs au cours de nombreuses années, depuis l'introduction de GEGL dans GIMP. Bien qu'initialement prévue pour la feuille de route de la version 3.2, une première implémentation a vu le jour en tant que continuation d'un projet Google Summer of Code. Si vous n'êtes pas familier avec ce terme, « édition non destructive » implique notamment que des effets de filtres tels qu'un effet de flou sont stockés séparément des pixels du calque. Cela signifie que si vous désirez plus tard modifier un réglage, réarranger ou même retirer le filtre, vous pouvez le faire très facilement sans affecter le reste de l'image. Jusqu'à présent, GIMP utilisait une procédure d'édition destructive où les effets étaient immédiatement appliqués sur le calque, c'est donc un changement majeur !

Toute opération GEGL munie d'une interface graphique est désormais appliquée aux calques de manière non destructive. (Les effets non destructifs pour les masques de calques et les canaux sont prévus pour les versions ultérieures.) Cela inclut les greffons GEGL tiers et les opérations personnalisées créées avec notre outil GEGL Graph. Ces effets peuvent être sauvegardés et chargés via les fichiers de projet .xcf, bien que toutes les propriétés GEGL ne soient pas encore prises en charge dans la version actuelle.

Une fois qu'un filtre a été appliqué, vous pouvez continuer à interagir avec lui en cliquant sur l'icône de filtre dans l'ancrable des calques. Cela ouvrira une boîte de dialogue montrant tous les filtres actuellement appliqués au calque. À partir de là, vous pouvez alterner l'état de visibilité du filtre, modifier ses réglages, réordonner les filtres et retirer les effets un à un. Vous pouvez aussi fusionner tous les filtres et les appliquer à l'image pour retrouver une procédure d'édition destructive.

Effets non destructifs - GIMP 2.99.18 (cliquez sur l'image pour voir la vidéo sur le compte Peertube de GIMP)

Notez bien que tout cela est seulement une première implémentation, et beaucoup de travail reste à faire pour disposer d'une édition non destructive complète et riche. Nous allons continuer à affiner les fonctionnalités existantes pour la sortie de la version 3.0 en nous basant sur les tests et les retours des utilisateurs, et nous les développerons davantage par la suite. L'interface elle-même ne correspond pas à notre vision idéale de cette fonctionnalité, et un premier jet de spécifications a été écrit pour définir un processus d'édition bien plus intégré.

La capture d'écran ci-dessous est une maquette réalisée à partir de ces premières spécifications. Elle montre les effets de calque placés au sein de la liste principale des calques, partageant les mêmes boutons « œil » et « cadenas », mais également avec leurs propres masques faciles à éditer :

Maquette des spécifications : les effets de calque sont visibles directement dans la liste des calques, avec leur propres masques

Néanmoins, l'implémentation de cette nouvelle interface sera un défi en elle-même et nous avons donc décidé de la remettre à après la sortie de GIMP 3 et de proposer cette première mouture en premier lieu.

N'hésitez pas à partager vos opinions dans les forums de discussion et dans le suivi des incidents !

Amélioration de la prise en charge des polices de caractères

Idriss Fekir, un autre étudiant du GSoC 2023, a travaillé avec Liam Quinn, un développeur de longue date, sur l'amélioration de la prise en charge des polices de caractères par GIMP. Une grande partie de ce travail concerne le code interne de GIMP afin d'améliorer sa capacité à gérer les futures mises à jour de polices et de texte. Certains changements plus visibles sont par exemple :

• GIMP n'a plus besoin que les noms des polices de caractères soient uniques pour pouvoir les distinguer les unes des autres. Cela signifie qu'il n'ajoutera plus « #1 », « #2 » et ainsi de suite, mais gardera à présent les noms originaux dans la liste de sélection des polices. Malgré des noms apparemment identiques, deux polices avec le même nom fonctionneront désormais correctement.
• GIMP peut maintenant charger des polices avec des styles personnalisés (en contournant l'utilisation de Pango qui n'est pas capable de les charger).
• Nous pouvons à présent charger davantage de types de polices qu'auparavant. Si jamais nous ne prenons pas encore en charge une police donnée (ou si elle est inexistante), nous sommes mieux à même de le détecter et nous pouvons nous replier sur une police par défaut. Cela permet d'améliorer la prise en charge d'un fichier .xcf créé sur un autre ordinateur avec différentes polices disponibles.
• Sous Windows, nous forçons le moteur Pango à toujours utiliser l'anticrénelage. Cela augmente la lisibilité du texte des menus sous ce système d'exploitation, en particulier lorsqu'un thème sombre est utilisé.
• Le code pour la sauvegarde au format XCF stocke désormais les informations concernant les polices de manière bien plus précise, ce qui aide à éviter de charger une police incorrecte lors de la réouverture d'un fichier XCF.
• L'alignement du texte dans les calques de texte pour les langues écrites de la droite vers la gauche est maintenant plus cohérent avec la manière dont cela fonctionne dans d'autres programmes (par exemple LibreOffice et Scribus).

Ces changements sont beaucoup moins voyants que certaines autres fonctionnalités et pourraient sembler moins importants, mais ils constituent en fait les fondations qui permettront d'avoir une gestion du texte bien plus fiable dans GIMP. Notre vision pour le futur est d'avoir une édition de texte plus simple tout en étant plus puissante et plus riche en fonctionnalités (en particulier les fonctionnalités OpenType qui sont quelques-unes des améliorations majeures que nous espérons ajouter un jour ou l'autre).

Expansion automatique des calques

Le troisième projet GSoC de l'été dernier par l'étudiant Shubham Daule a apporté une fonctionnalité demandée depuis longtemps : l'expansion automatique de calques ! Les outils de peinture ont désormais une option supplémentaire « Étendre les calques ». Lorsque cette case est cochée, peindre au-delà des limites des calques les fera s'étendre automatiquement afin que vous n'ayez pas à gérer vous-même la taille du calque. Si vous souhaitez étendre le calque au-delà de la taille actuelle du canevas, vous devrez également cocher l'option « Afficher tout » dans le menu Affichage.

Calques à expansion automatique - GIMP 2.99.18 (cliquez sur l'image pour voir la vidéo sur le compte Peertube de GIMP)

L'option d'expansion des calques comporte également des paramètres supplémentaires lorsqu'elle est sélectionnée. Vous pouvez décider dans quelle mesure vous souhaitez que les limites du calque s'étendent chaque fois que le pinceau les atteint. Il existe également des options pour spécifier comment les nouvelles zones du calque et du masque de calque doivent être remplies une fois étendues.

Nouvelles options d'alignement

Le nouveau contributeur mr. fantastic a développé deux nouvelles options pour aligner les calques sur le canevas. Avec « Snap to Bounding Boxes » (« Aligner sur les boîtes englobantes ») activé, des guides dynamiques s'afficheront désormais pour vous montrer quand le calque que vous déplacez est aligné avec le centre ou les côtés des autres. Le calque actif s'alignera également sur ces bordures pour vous aider à les organiser correctement. La deuxième option, « Snap to Equidistance » (« Aligner à équidistance »), vous permet un alignement entre trois calques équidistants les uns des autres.

Nouvelles options d'alignement automatique - GIMP 2.99.18 (cliquez sur l'image pour voir la vidéo sur le compte Peertube de GIMP)

Thèmes

Nous avons continué à améliorer l'interface utilisateur et le style de cette version. L’une des améliorations les plus importantes concernait la gestion des « fuites de thèmes système ». Il existe des styles qui n'ont pas été spécifiquement définis dans nos thèmes, donnant ainsi l'opportunité aux règles de style du thème système de "fuiter" de manière conflictuelle dans notre interface. Avec l’aide et les retours de plusieurs contributeurs et utilisateurs, nous avons beaucoup progressé dans la définition de ces styles afin que tous aient une expérience cohérente !

Récemment, Jehan a travaillé sur la réorganisation et la simplification de notre système de thèmes. Dans les versions de développement précédentes, nous avions cinq thèmes différents : Par Défaut, Gris, Système, Plus Sombre et Compact (chacun avec des options claires et sombres). Ceux-ci ont été simplifiés dans le thème Système et un seul thème par défaut avec trois états possibles : clair, foncé et gris. De même, nos quatre thèmes d'icônes distincts ont été condensés dans l'ensemble Legacy et un thème d'icôns par défaut avec des variantes couleur et symbolique. Nous pensons que ces changements réduiront la confusion des utilisateurs et leur permettront de trouver plus facilement leur apparence d'interface préférée.

De plus, sous Windows, la barre de titre principale (et la plupart des barres de titre des boîtes de dialogue) s'ajuste désormais au mode clair ou sombre en fonction du thème sélectionné.

Boîte de dialogue de bienvenue

La boîte de dialogue de bienvenue a été étendue pour fournir un accès rapide à un certain nombre de fonctionnalités et d'options utiles. Elle comporte ainsi quatre nouvelles sections :

• Personnaliser : Plusieurs options de personnalisation nécessitent de fouiller dans la boîte de dialogue des Préférences pour être modifiées. À présent, vous pouvez facilement modifier les thèmes de couleurs et d'icônes, la langue et la taille de la police de l'interface utilisateur, ainsi que certains réglages en fonction du système d'exploitation.
• Créer : Cette section affiche les huit images que vous avez ouvertes en dernier et vous permet de les rouvrir rapidement. Des boutons pour créer une nouvelle image ou pour en charger une existante sont également présents. À l'instar d'autres programmes, vous pouvez demander à ce que cet écran apparaisse automatiquement au démarrage de GIMP pour un accès direct à ces fonctionnalités.
• Contribuer : Nous avons réuni ici quelques-unes des nombreuses façons dont vous pouvez participer au développement de GIMP. Cette section comporte des liens pour le signalement de bogues, pour écrire du code, pour aider aux traductions ou pour faire un don.
• Notes de version : Précédemment, le lien vers ces notes étaient affichées dans la moitié inférieure de la boîte de dialogue de bienvenue. À présent, nous avons un onglet entier dédié à ces notes pour une lecture plus aisée.

Formats de fichiers

Comme cela était déjà le cas avec les versions précédentes, nous avons amélioré la prise en charge de formats de fichiers déjà existants et nous avons ajouté la prise en charge de l'importation et de l'exportation pour de nouveaux formats.

DDS

Stayd, un nouveau contributeur, a travaillé avec notre développeur Jacob Boerema pour apporter de nombreuses améliorations au greffon DDS. Pour commencer, les fonctions d'importation ont été écrites afin d'être plus simples et plus faciles à étendre dans le futur. Les mises à jour supplémentaires incluent également :

• Le chargement d'images DDS RVBA 16 et 32 bits/canal est maintenant possible.
• Le filtre cubique Catmull-Rom a été ajouté pour la génération de mipmaps, et tous les calculs pour générer les mipmaps sont effectués avec une précision de 32 bits.
• Les images DDS aux formats R8G8, R16 et R16G16 peuvent maintenant également être chargées.
• Une option pour renverser verticalement les images DDS lors de l'importation a été ajoutée pour faire écho à l'option d'exportation correspondante, étant donné que certaines images de jeux stockent leurs données de cette manière.

GIF

Par le passé, écraser un fichier GIF à la sauvegarde (plutôt que de l'exporter) le convertissait systématiquement en un fichier avec une seule image. Désormais nous vérifions lors du chargement si le fichier GIF est une animation, de manière à également sauvegarder une animation lors de l'écrasement.

HEIF et JPEG-XL

Les deux greffons utilisent maintenant leurs bibliothèques respectives (libheif et libjxl) pour le chargement des métadonnées. Cela nous a permis de retirer notre code maison chargé d'interpréter l'orientation des images et d'utiliser à la place les informations fournies par ces bibliothèques.

OpenEXR

Le format OpenEXR permet aux canaux d'avoir des noms personnalisés, outre le type de couleur. Dans ce cas, nous considérons maintenant toute image à un seul canal avec un nom non conventionnel comme étant en niveaux de gris. Lors de l'importation, nous affichons une notification afin que les utilisateurs soient prévenus de cette conversion.

PDF

L'option d'exportation « Calques en tant que pages » fonctionne maintenant même s'il y a un seul groupe de calques. Auparavant, cette option n'était pas disponible car le greffon vérifiait seulement s'il y avait plus d'un « calque » sans examiner s'il s'agissait d'un groupe de calques avec de multiples sous-calques.

PNG

Les fragments de fichiers PNG qui sont « copiables sans risque » (« safe-to-copy chunks ») sont maintenant préservés lors de l'importation et inclus dans l'image exportée. Un autre souci qui existait lors de l'exportation de PNGs indexés avec transparence (et qui nous avait été souvent signalé) a été résolu. Désormais les couleurs indexées devraient être affichées correctement après exportation.

PSD

Jacob Boerema a poursuivi son travail d'amélioration du greffon PSD. En plus d'avoir résolu des bogues, par exemple dans l'ordre des calques lors de l'importation, il a aussi clarifié l'avertissement présenté lors de l'exportation et concernant la compatibilité des modes de calques entre GIMP et Photoshop.

PSP

Le greffon Paintshop Pro peut maintenant importer davantage de caractéristiques depuis un fichier projet, comme par exemple le profil de couleurs ICC, les guides, les grilles, et la sélection active lors de la sauvegarde. Les failles de sécurité ZDI-CAN-22096 et ZDI-CAN-22097 ont également été corrigées dans cette version.

Nouveaux formats d'image pris en charge : Farbfeld, Esm Software PIX, HEJ2

Nous avons récemment ajouté la prise en charge de l'importation et de l'exportation pour le format Farbfeld, un format d'image sRVB conçu pour être facile à lire, à envoyer dans des pipes et à compresser avec des outils tiers.

Nous avons aussi ajouté la prise en charge de l'importation seule pour les nouveaux formats suivants :

• Esm Software PIX : Un format JPEG modifié utilisé exclusivement par l'entreprise Esm Software pour stocker leurs images propres. Cela a été implementé en réponse à un signalement de bogue qui avait confondu ce format avec le format Alias PIX que nous prenions déjà en charge.
• HEJ2 : Un ajout à notre greffon HEIF déjà existant fourni par Daniel Novomeský qui permet d'importer des images JPEG 2000 compressées.

Nouveau format de palette pris en charge : Swatchbooker

Swatchbooker est un programme libre de création et de conversion de palettes de couleurs qui prend en charge de nombreux formats. Bien que le programme lui-même n'ait pas été mis à jour depuis de nombreuses années, son format de palette propre .sbz est le plus complet de tous ceux que nous prenons en charge actuellement. Parmi ses nombreuses fonctionnalités, on peut citer la possibilité de définir des couleurs dans plusieurs modèles de couleurs pour chaque entrée d'une palette, des noms et des descriptions régionalisables, et la prise en charge de profils de couleurs ICC différents pour chaque entrée.

Via notre travail sur la prise en charge de son importation, nous avons pu fournir des informations qui ont conduit à un correctif de bogue dans la prise en charge de Swatchbooker par Krita. C'est toujours sympa quand des projets peuvent collaborer et s'entraider !

Interactions avec les pads de tablettes graphiques sous Wayland

Carlos Garnacho, un contributeur GNOME de longue date, a ajouté la prise en charge de l'interaction directe des boutons de tablettes graphiques (pad) avec GIMP. Quand une tablette est branchée, vous pouvez désormais assigner différentes actions aux contrôles de la tablette depuis la boîte de dialogue « Périphériques d'entrée » dans le menu Édition.

Assigner des actions aux boutons d'une tablette graphique - GIMP 2.99.18

Ce travail a aussi impliqué le portage de fonctionnalités vers GTK 3, la boîte à outils utilisée par GIMP pour son interface graphique. Notez que cette fonctionnalité est seulement disponible sous Wayland pour le moment.

Mise à jour de l'API

L'interface de programmation d'application (API), destinée aux créateurs de greffons, est régulièrement retravaillée dans le cadre de la refonte de GIMP 3. Une partie de ce travail est de migrer l'API vers l'utilisation de GeglColor lorsque les couleurs sont impliquées, ce qui entre dans le cadre plus général du projet Space Invasion. Malgré tout, ce n’est qu’une petite partie de l’ensemble des améliorations de l’API.

Nous nous orientons également vers plus de classes pour représenter les différentes ressources gérées par GIMP (pinceaux, polices, motifs, etc.) au lieu de les représenter uniquement par des noms (ce qui était une limitation historique alors qu'il est tout à fait possible à 2 créateurs de ressources de choisir le même nom et le fait est que nous voyons de tels cas dans la nature — par exemple, 2 polices créées indépendamment peuvent avoir le même nom).

Un autre grand pas consiste à remplacer le GimpValueArray représentant les arguments ordonnés d'une procédure d'un greffon par un GimpProcedureConfig qui contient les arguments par nom plutôt que par ordre. Cela permet une utilisation beaucoup plus sémantique des procédures de greffon (surtout lorsqu'elles ont une longue liste d'arguments) et facilitera également l'amélioration des greffons à l'avenir, avec des arguments nouveaux ou réorganisés sans créer de nouvelles procédures, car l'ordre et le nombre des arguments comptent beaucoup moins. Cela signifie que l'ajout de nouveaux arguments dans le futur ne brisera plus les scripts déjà existants qui dépendaient des versions antérieures de ces greffons (les auteurs de greffons devront toujours choisir des valeurs par défaut appropriées pour les nouveaux arguments afin que cela soit vrai, bien sûr).

En parallèle, nous continuons d'améliorer la capacité de création automatique d'interfaces graphiques offerte aux greffons, rendant la création de boîtes de dialogue plus simple que jamais. Cela inclut (parmi de nombreuses autres améliorations) un nouveau type d'argument de procédure nommé GimpChoice qui est une liste de choix sous forme de chaînes de caractères qui peut être présentée aux créateurs sous forme de widgets de liste déroulante dans la boîte de dialogue de votre greffon.

Nous prévoyons d'écrire et de publier un didacticiel pour les rédacteurs de greffons dans la section Développement de ressources de notre site Web pour développeur en même temps que la sortie de GIMP 3, ou peu de temps après.

GEGL et babl

Cette version de GIMP est accompagnée de nouvelles versions de GEGL et babl, qui contribuent toutes deux au projet (Color) Space Invasion.

babl 0.1.108 apporte une nouvelle fonction babl_space_is_rgb pour nous aider à confirmer directement qu'un espace colorimétrique est RVB (plutôt que de faire plusieurs tests pour voir s'il n'est pas CMJN ou niveaux de gris). Plusieurs améliorations ont également été apportées au processus de compilation et à l'outil d'interface de ligne de commande de babl.

GEGL 0.4.48 fournit plusieurs mises à jour de l'objet GeglColor qui prend désormais en charge une grande partie des opérations de couleur de GIMP. Les améliorations spécifiques incluent la possibilité d'obtenir et de définir directement les valeurs de couleur CMJN, ainsi que l'attribution de l'espace colorimétrique lors de la définition des couleurs RVB(A).

Un crash dans le filtre gegl:voroni existant a été corrigé, et un bogue de longue date avec le filtre gegl:dropshadow qui empêchait l'effet de rétrécir a également été corrigé.

Enfin, un nouveau filtre gegl:shuffle-search a été ajouté à l'atelier. Il mélange les pixels voisins pour créer un effet de tramage plus optimisé.

Statistiques de sortie

Hormis la première version de la série (2.99.2), GIMP 2.99.18 est clairement la plus grosse mise à jour à bien des égards. Depuis la version 2.99.16 :

• 238 rapports ont été clôturés comme CORRIGÉS.
• 201 demandes de fusion ont été acceptées.
• 1358 commits ont été poussés.
• 26 traductions ont été mises à jour : allemand, basque, biélorusse, portugais brésilien, bulgare, catalan, chinois (Chine), danois, espagnol, espéranto, finnois, géorgien, grec, hongrois, islandais, italien, lituanien, norvégien nynorsk, persan, polonais, russe , slovène, suédois, turc, ukrainien, vietnamien.

60 personnes ont apporté des modifications ou des correctifs à la base de code de GIMP 2.99.18 (l'ordre est déterminé par le nombre de commits; certaines personnes apparaissent dans plusieurs groupes) :

• 23 développeurs pour le code principal : Jehan, Alx Sa, Shubham, Jacob Boerema, Idriss Fekir, bootchk, Anders Jonsson, Carlos Garnacho, mr.fantastic, Stanislav Grinkov, lillolollo, Øyvind Kolås, Sabri Ünal, programmer_ceds, Lukas Oberhuber, programmer-ceds, James Golden, Luca Bacci, Massimo Valentini, Niels De Graef, Zander Brown, psykose, sonia.
• 17 développeurs de greffons ou de modules : Jehan, Alx Sa, Jacob Boerema, bootchk, Anders Jonsson, Stayd, Zander Brown, Bruno Lopes, Daniel Novomeský, Sabri Ünal, programmer_ceds, Kamil Burda, Mark, Michael Schumacher, Stanislav Grinkov, programmer-ceds, sonia.
• 31 traducteurs : Yuri Chornoivan, Martin, Ekaterine Papava, Luming Zh, Sabri Ünal, Anders Jonsson, Rodrigo Lledó, Jordi Mas, Alan Mortensen, Vasil Pupkin, Asier Sarasua Garmendia, Kolbjørn Stuestøl, Boyuan Yang, Víttor Paulo Vieira da Costa, dimspingos, Alexander Shopov, Alexandre Prokoudine, Aurimas Černius, Balázs Úr, Marco Ciampa, Sveinn í Felli, Danial Behzadi, Ngọc Quân Trần, Jürgen Benvenuti, Piotr Drąg, Timo Jyrinki, Andre Klapper, Kristjan SCHMIDT, MohammadSaleh Kamyab, Rafael Fontenelle, Tim Sabsch.
• 9 créateurs de ressources (icônes, thèmes, curseurs, splash screen, métadonnées…) : Alx Sa, Jehan, Ferry Jérémie, Stanislav Grinkov, Anders Jonsson, Bruno Lopes, Jacob Boerema, Sabri Ünal, mr.fantastic.
• 5 contributeurs à la documentation : Jehan, Bruno Lopes, Jacob Boerema, Alx Sa, Anders Jonsson.
• 14 contributeurs pour la compilation, l'empaquetage ou l'intégration continue : Jehan, Bruno Lopes, bootchk, Alx Sa, Zander Brown, Jacob Boerema, Jacob Boerema, Stayd, Carlos Garnacho, Heiko Becker, mr.fantastic, Daniel Novomeský, U-YGGDRASIL\ender, lillolollo.

Contributions à d'autres dépôts du GIMPverse (l'ordre est déterminé par le nombre de commits) :

• babl 0.1.108 est composé de 17 commits par 6 contributeurs : Jehan, Øyvind Kolås, John Marshall, Andre Klapper, John, sid.
• GEGL 0.4.48 est composé de 77 commits par 20 contributeurs : Øyvind Kolås, Jehan, Anders Jonsson, Jacob Boerema, Yuri Chornoivan, Alan Mortensen, Sabri Ünal, Andre Klapper, Ekaterine Papava, Jan Tojnar, Jordi Mas, Luming Zh, Martin , Piotr Drąg, Víttor Paulo Vieira da Costa, Asier Sarasua Garmendia, Marco Ciampa, Rodrigo Lledó, dimspingos, woob.
• ctx a eu 308 commits depuis la version 2.99.14 par 1 contributeur : Øyvind Kolås.
• La version gimp-macos-build (scripts d'empaquetage macOS) est composée de 32 commits par 1 contributeur : Lukas Oberhuber.
• La version flatpak est composée de 15 commits par 3 contributeurs : Jehan, Daniel Novomeský et Hubert Figuière.
• Notre site Web principal a eu 31 commits depuis la sortie du 2.10.36 par 6 contributeurs : Jehan, Alx Sa, Sabri Ünal, Anders Jonsson, Bruno Lopes, Jonathan Demeyer.
• Notre site Web des développeurs a eu 30 commits depuis la version 2.10.36 par 5 contributeurs : Bruno Lopes, Jehan, Alx Sa, bootchk, Robin Swift.
• Notre documentation 3.0 a enregistré 247 commits depuis la version 2.99.16 par 17 contributeurs : Andre Klapper, Jacob Boerema, Yuri Chornoivan, Alx Sa, Jordi Mas, Alan Mortensen, Dimspingos, Anders Jonsson, Boyuan Yang, Sabri Ünal, Víttor Paulo Vieira da Costa, Juliano de Souza Camargo, Rodrigo Lledó, Kolbjørn Stuestøl, Marco Ciampa, Danial Behzadi, Emin Tufan Çetin.

N'oublions pas de remercier toutes les personnes qui nous aident à faire le tri dans Gitlab, rapportent des bogues et discutent avec nous d'éventuelles améliorations. Notre communauté est également profondément reconnaissante envers les guerriers d'Internet qui gèrent nos différents canaux de discussion ou comptes de réseaux sociaux tels que Ville Pätsi, Liam Quin, Michael Schumacher et Sevenix !

Remarque : compte tenu du nombre de pièces qui composent GIMP et son environnement, et de la manière dont nous obtenons des statistiques via des scripts git, des erreurs peuvent se glisser dans ces statistiques. N'hésitez pas à nous dire si nous avons manqué ou mal catégorisé certains contributeurs ou contributions.

Nouvelles de l'équipe et procédure de sortie

Les droits d'accès au dépôt git ont été récemment accordés à Bruno Lopes (qui a été très actif dans l'amélioration de notre processus de compilation et de l'empaquetage pour Windows).

Plusieurs développeurs ou empaqueteurs de longue date ou plus récents qui ont commencé à contribuer au nouveau site Web des développeurs ont également reçu l'accès au dépôt git associé.

De plus en plus de contributeurs participent désormais activement aux tests des versions et du processus d'empaquetage, et c'est la première dépêche depuis des années (NDT : cela désigne la news originale sur le site de GIMP) que Jehan n'a pas écrite presque entièrement ! Merci beaucoup à Alx Sa (alias Nikc ou CmykStudent) d'avoir entamé la rédaction collaborative de la nouvelle !

Il est clair que nous consolidons jour après jour une solide équipe de contributeurs et cela se voit dans notre processus de publication, avec de plus en plus de retours à chaque version.

Nous sommes également particulièrement heureux et fiers que les 4 projets GSoC que nous avons eus, depuis que nous avons recommencé à souscrire à ce programme de mentorat, aient tous été couronnés de succès et ont fini par être fusionnés avec la branche principale du code au plus tard six mois après la fin du stage.

Autour de GIMP

Des nouvelles des miroirs

Depuis la dernière dépêche, un nouveau miroir a été apporté à GIMP par :

• Sahil Dhiman, à Nuremberg, en Allemagne, comme projet personnel.

Cela nous amène à un total de 46 miroirs répartis dans le monde.

Les miroirs sont importants car ils aident le projet en partageant la charge de dizaines de milliers de téléchargements quotidiens. De plus, en disposant de miroirs répartis à travers le monde, nous garantissons que tout le monde puisse avoir un accès rapide au téléchargement de GIMP.

GIMP sous Windows/ARM

Depuis notre annonce d'une version expérimentale sur Windows pour l'architecture ARM 64 bits (en anglais), nous avons reçu l'aide de Hernan Martinez, contributeur bien connu du projet MSYS2, qui a hébergé notre tout premier runner pour l'intégration continue (CI) pour Windows sur l'architecture Aarch64. Bien que cela n'ait été qu'une configuration temporaire (littéralement une machine de compilation dans le salon de quelqu'un) en attendant une situation plus stable, nous sommes extrêmement reconnaissants envers Hernan qui nous a aidés à faire notre deuxième pas sur cette plateforme (la première étape a été effectuée par Jernej, qui a créé notre premier installateur expérimental), s'est assuré que notre processus de compilation automatique fonctionne sur cette machine, et plus encore.

Depuis lors, la situation plus stable est arrivée : Arm Ltd. eux-mêmes se sont mobilisés et ont officiellement contribué trois runners pour notre processus d'intégration continue dans Gitlab ! Arm Ltd. a également sponsorisé un kit de développement Windows pour l'un de nos développeurs.

Bien que nous considérions toujours cette version comme expérimentale, en raison du manque de tests et du fait que seuls 2 contributeurs disposent actuellement d'une machine capable de l'exécuter, le plus gros facteur bloquant a été supprimé et nous sommes heureux d'annoncer que notre programme d'installation Windows universel pour GIMP 2.99.18 contient GIMP pour les 3 plates-formes (x86 32 et 64 bits, et maintenant ARM 64 bits) !

Télécharger GIMP 2.99.18

Vous trouverez toutes nos versions officielles sur le site officiel de GIMP (gimp.org) :

• Flatpaks Linux pour x86 et ARM (64 bits)
• Installateur Windows universel pour x86 (32 et 64 bits) et pour ARM (64 bits)
• Paquets macOS DMG pour le matériel Intel
• Paquets macOS DMG pour le matériel Apple Silicon

D'autres paquets réalisés par des tiers devraient évidemment suivre (paquets des distributions Linux ou *BSD, etc.).

Et ensuite ?

Alors que nous sommes maintenant entrés dans un gel des fonctionnalités, notre attention s'est déplacée vers la correction des bogues, le nettoyage et la préparation de la première version candidate 3.0.

Nous pensons en effet qu'il s'agit de la dernière version de développement puisqu'aucune nouvelle fonctionnalité ne sera introduite désormais, du moins au niveau de l'interface utilisateur (l'API est encore en évolution jusqu'à la première version candidate). Donc, ce que vous voyez maintenant est essentiellement ce que vous devriez obtenir dans GIMP 3.0.0, en termes de fonctionnalités.

C'est pourquoi nous avons sorti cette version même si nous savons qu'elle est assez instable. C'est l'heure des commentaires de dernière minute ! C'est aussi le moment de signaler et de corriger les bogues comme si demain n'existait pas. Nous espérons pouvoir bientôt livrer une RC1 et elle devrait être aussi dépourvue de bogue que possible.

Nous espérons actuellement pouvoir publier GIMP pour le prochain Libre Graphics Meeting du 9 au 12 mai. Pour être honnête, ce n’est pas un objectif facile et nous ne sommes donc pas sûrs de pouvoir l’atteindre. Ce qui est sûr, c'est que même si nous n'y parvenons pas à temps, cela ne devrait pas arriver trop longtemps après. En particulier, nous ne publierons pas simplement parce que nous avons fixé une date limite. Nous voulons offrir la meilleure expérience possible, ce qui signifie que si nous découvrons des bogues bloquants de dernière minute, nous retarderons la sortie jusqu'à ce qu'ils soient corrigés.

N'oubliez pas que vous pouvez faire un don et financer personnellement les développeurs de GIMP, c'est un moyen de donner en retour et d'accélérer le développement de GIMP. L’engagement communautaire permet au projet de se renforcer ! 💪🥳