❌

Vue lecture

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

Une histoire de formats : il n’y a pas que la taille qui compte

✇LinuxFr.org
Par : Ysabeau 🧶 🧦 Benoît Sibaud patrick_g dourouc05

Dans cette nouvelle excursion dans le temps et dans l’espace du Transimpressux, nous allons rendre une rapide visite à Théotiste Lefevbvre (1798 - 1887) prote d’imprimerie et à quelques-uns de ses confrères ainsi que dans les magasins de quelques bibliothèques. Nous passerons aussi, un grand moment du côté de la Silicon Valley et de Redmond dans l’État de Washington, bien obligé puisqu’on parlera beaucoup de formats numériques, sans oublier d’aller dire bonjour à Donald Knuth, Tim Berners-Lee et John Gruber. On terminera notre exploration quelque part dans les archives numériques de la Bibliothèque nationale de France (BnF).

La climatisation du Transimpressux a été entièrement révisée et le bar rechargé en boissons fraîches et glaces en tous genres. On vous souhaite un bon voyage.

Le transimpressux

Sommaire

Préambule

Cette dépêche ne se veut pas exhaustive sur les formats en tous genres ni très technique sur les formats informatiques. Pour les formats d’image, qui ne sont pas traités ici, je vous renvoie à l’excellente dépêche de Tanguy Ortolo qui a fait le tour de la question et au journal de Glandos sur l’intégration du JPEG XL dans les navigateurs.

Les formats matériels, entre coût et rangement

Encore aujourd’hui, le format matériel d’un document, spécialement, s’il s’agit d’un livre, est important pas uniquement pour des questions de coût. Mais aussi à cause d’eux. C’est parce que le papier coûtait cher qu’Alde Manuce a créé l’italique au début du 16e siècle. L’italique prenant moins de place que les autres styles de caractères, il devenait possible d’imprimer des livres en petit format qui pouvaient ainsi être achetés par une clientèle impécunieuse.

Une pile de livres
Des différences de taille et de tailles. Image retravaillée avec le filtre « Pencil Portrait » de Q’mic-Qt (et un peu Inkscape).

Les rouleaux, volumen ou rotulus

La taille de ces rouleaux varie beaucoup. Ils peuvent atteindre plusieurs mètres de long (ou de large, selon le sens de lecture). Témoin cette remarque d’Auguste Molinier, chartiste et bibliothécaire, en 1892 :

On a étudié récemment la longueur des volumina antiques. En Égypte, elle paraît avoir été illimitée ; un rouleau trouvé à Thèbes a 43 m. 50, ce qui est excessif ; il est vrai que le moyen âge a eu des rouleaux de parchemin, plus solides, mais encore plus lourds et infiniment plus longs. Pour les œuvres littéraires grecques et latines, un érudit moderne, M. Birt, a évalué à 12 mètres la longueur extrême des volumina.1

Ces longueurs démesurées ne sont pas propres aux Égyptiens. Les Archives nationales de Paris possèdent un parchemin d’une longueur d’une vingtaine de mètres. Daté de 1307, ce rouleau consigne les aveux, obtenus sous la torture, de cent-trente-huit Templiers. Il va sans dire que leur longueur et leur ancienneté rend les rouleaux très difficiles à manipuler, une difficulté que la numérisation élimine.

Des formats des livres

Les noms des formats des livres en imprimerie traditionnelle sont liés au nombre de pages que l’on imprimait sur une feuille. Le mot « format » lui-même pourrait venir des châssis, ou « formes » dans lesquels on plaçait les pages à imprimer. Ce procédé s’appelait l’imposition.

Les formats les plus usuels, du plus grand au plus petit :

  • in-folio : soit quatre pages par feuille, la taille la plus grande de livre,
  • in-quarto, huit pages,
  • in-octavo, seize pages,
  • in-douze, vingt-quatre pages,
  • in-dix-huit, trente-six pages.

La répartition des pages sur la feuille était à la fois importante et délicate puisqu’une fois imprimée, la feuille était pliée. Il fallait donc veiller non seulement à la bonne répartition des pages sur la feuille, mais aussi à leur sens. Dans son Guide pratique du compositeur d’imprimerie, Théotiste Lefebvre consacre plus d’un quart de son livre (119 pages sur 440) à cette délicate question. Dans son petit guide sur la Typographie, Charles-Félicien Huart y consacre aussi plusieurs pages.

Un exemple de répartition des pages2 pour un volume in-douze, « côté de première » indique le recto, « côté de seconde », le verso. La feuille est pliée en trois dans le sens de la hauteur et deux dans la largeur.

répartition
Recto : deux séries de pages tête en bas, pages 12, 13, 16 et 9 (1re série) et 8, 17, 20 et 5 (2e série) et, en dessous pages 1, 24, 21 et 4. Verso : deux séries de pages tête en bas, pages 10, 15, 14 et 11 (1re série) et 6, 19,18 et 7 (2e série) et 3, 22, 23 et 2 en dessous.

Cette différence de tailles peut amener les bibliothèques dont le fond n’est pas directement accessible au public à opter pour un classement matériel des livres basés sur le format. On aura ainsi des côtes du genre « in12-numéro d’inventaire ». C’est un système très efficace et qui évite d’avoir un petit livre (littéralement) perdu au milieu de livres nettement plus grands.

Les formats actuels, livre et papier

L’indication de format à partir du nombre de pages imprimées sur une feuille ne donne pas d’information précise sur la taille effective des livres. Il faut signaler que les dimensions changent en fonction de celles de la feuille d’origine. Les appellations actuelles, côté édition, du style Livre de poche (environ 10,5 cm x 17,5 cm), livre broché ou encore grand format, utilisées en lieu et place d’in-folio, in-octavo, etc. réservés plutôt au livre ancien ne sont pas plus précises.

En, revanche, la taille des feuilles de papier les plus utilisées a fait l’objet d’une norme, la norme ISO 216. Elle concerne les formats A, dont le fameux A4 qui est celui des feuilles standard des imprimantes de bureau et le format B. Le principe : plus le numéro est élevé, plus la feuille est petite. La numérotation commence à 0 qui fait un mètre carré (84,1 cm x 118,9 cm) pour le format A. La taille de la feuille du numéro supérieur devant être égale à la moitié de celle du numéro inférieur qui la précède. En d’autres termes : le format A3 égal deux fois le format A4 qui, lui-même, est deux fois plus grand que le format A5. Il en va de même avec le format B. Cela explique au passage pourquoi le format A4 mesure 21 x 29,7 cm et pas 21 x 30 cm.

Les formats de texte

Jusque dans les années 1990, il y avait un nombre très important d’outils et de formats de textes. Writer de LibreOffice, d’après mes comptes, peut ouvrir jusqu’à quarante-quatre formats de fichier différents, hors modèles et hors web, mais n’enregistre que dans des formats qui sont ceux encore utilisés à l’heure actuelle. Ce qui réduit la liste à treize formats incluant les modèles et l’HTML.

Sur cette frise chronologique, on a, en haut, des formats de texte avec leur date de naissance plus ou moins approximative et, en dessous, des langages de balisage avec leur date de naissance également.

Formats de texte et langages de balisage
Les formats de texte : 1977 Texte brut, 1987-2007 RTF, 1990-2007 DOC, 2005 ODT, 2007 DOCX. Ils ont été choisis parce qu’ils sont les plus connus, voire, les plus utilisés. Dans cette liste deux formats ne sont plus maintenus, les formats RTF et DOC. Mais il existe encore des amas de fichiers dans ces deux formats.

Le texte brut, .txt

Le texte brut, nait à une date imprécise. Probablement vers la fin des années 1950 ou au début des années 1960. Le premier RFC3 qui définit un standard de protocole pour des messages en texte brut (Standard for the Format of Arpa Network Text Messages) date de 1977, il porte le numéro 733 et a été rédigé par l’agence américaine pour les projets de recherche avancée de défense (DARPA pour Defense Advanced Research Projects Agency).

Au début, le format n’acceptait que l’Ascii, à savoir les vingt-six lettres de l’alphabet, les chiffres, les ponctuations de base et les caractères de commande Ascii. Ce qui en fait un format simple, mais très pauvre. L’Ascii est codé sur 7 bits, ce qui ne permet d’avoir que cent-vingt-huit caractères, en fait quatre-vingt-dix imprimables et trente-huit pour les codes de commande4. Il accepte, depuis, l’Unicode. Depuis quand ? Difficile à préciser, mais la première mention d’Unicode qui figure sur le site rfc-editor remonte à juillet 1994 (en), RFC 1641, à titre expérimental. On peut supposer, en tout cas, que le consortium Unicode qui réunit la fine fleur de l’informatique a dû très tôt faire en sorte que son standard puisse être accepté dans le format texte brut.

Ce format se révèle assez vite insuffisant de part sa simplicité même, confinant à la pauvreté : pas d’enrichissement typographique, pas de notion de style ni de hiérarchie des paragraphes, pas de possibilité d’avoir des images. Il est, de fait, plutôt inférieur à ce que l’on peut avoir sur du papier. Il reste néanmoins très utilisé et par toutes les applications qui traitent du texte : éditeurs de texte, bureautique, etc. Il a pour lui l’avantage d’être simple, léger et interopérable. C’est le format, par exemple, avec lequel la BnF Gallica délivre les documents « bruts de numérisation » (il faut copier-coller le texte ailleurs pour le garder et le retravailler), et c’est, bien évidemment, celui des RFC.

Il y a des personnes qui recommandent de conserver le texte en texte brut, compte tenu des limitations du format, ce n’est pas franchement conseillé pour des documents un peu complexes étant donné qu’il y aura énormément de pertes d’information.

Le RTF

En 1987, Microsoft lance le Rich Text Format (RTF) qui permettait d’avoir du texte « enrichi » avec des attributs : gras, italique, souligné et de dépasser le cadre du texte brut. C’est un format qui a été pendant un certain temps, un standard d’échange de fait pour ce type de fichiers. Il était au moins lu par beaucoup de logiciels sur nombre de systèmes d’exploitation. C’était un format pratique d’échange, notamment à une époque où le PDF n’était pas encore un format ouvert et ne pouvait être généré que via le (cher) logiciel d’Adobe. Et aussi parce que c’était l’époque de la « grande démocratisation » de l’informatique, et, qu’à vrai dire, les utilisateurices finaux ne savaient pas trop comment, surtout sous quelle forme et ce qui se passait quand on échangeait des fichiers.

Aussi pratique que soit le format RTF, outre son absence de légèreté, il était néanmoins très limité : pas de texte structuré autrement que sur un plan purement visuel, par exemple. Microsoft arrêtera de le maintenir en 2008 (il aura tenu vingt ans tout de même !). C’est donc un format mort.

Le .doc, un format propriétaire incontournable

Quand Microsoft lance sa suite bureautique dans les années 1990 (la date sur la chronologie n’est pas tout à fait exacte), il adopte pour le traitement de texte, Word, l’extension .doc qui avait été aussi celle de WordPerfect. Word avait pour lui de montrer le rendu du texte immédiatement : le fameux WYSIWYG pour « What you see is what you get » (ce que vous voyez est ce que vous obtenez).

La suite finit par devenir quasiment incontournable et le format DOC de Word devenir un « standard de fait ». Microsoft abandonnera le DOC en 2007 pour le DOCX basé sur l’Office Open XML. On produira encore longtemps après des fichiers en .doc en vertu du « tout le monde n’a pas la version de MsOffice 2007 ». On trouve encore sur internet des modèles de fichiers à ce format à télécharger.

Il était reproché au format son poids, lourd, des problèmes de confidentialité (on pouvait, par exemple, retrouver du texte effacé avant l’enregistrement ou le modèle de l’imprimante5) et sa faiblesse devant les virus. Et, bien entendu, c’était un format propriétaire et pas interopérable. Un autre défaut majeur du format était qu’il était modifié à chaque nouvelle version de Word ce qui impliquait de devoir acheter la nouvelle version du logiciel pour pouvoir travailler sur les nouveaux fichiers en .doc.

Microsoft délivrera les sources du format en 2006, mais les spécifications semblent ne plus figurer sur le site de la firme. Le code source de la version d’origine de Word, quant à lui, a été rendu public et versé au musée américain de l’histoire de l’ordinateur (en).

Le .doc peut encore être ouvert et travaillé d’un grand nombre de logiciels. Abiword par exemple ouvre les .doc mais pas les .docx. En revanche, il est de moins en moins possible de générer des fichiers à ce format, et c’est une bonne chose. On ne saurait que trop vous suggérer de transformer tous les fichiers en .doc qui traîneraient encore dans vos ordinateurs en ODT (ou de faire le ménage). Il en va de même pour le format de modèle .dot.

L’ODT : un format ouvert

En 2005 apparaît un format bien intéressant : le format ODT, qui est une des composantes du plus général OpenDocument Format (ODF) avec le O d’Open, le D de Document et le T de Texte, l’extension OTT étant pour les modèles avec le premier T pour Template (modèle en anglais). L’ODF est géré par le consortium OASIS, pour Organization for the Advancement of Structured Information Standards (Organisation pour l’avancement des normes d’informations structurées).

OASIS est une structure à but non-lucratif autorisée par l’ISO (International Standard Organization, l’organisation dont l’objectif social est l’élaboration et la publication de normes mondiales de produits et services), à publier des standards dont les spécifications sont publiquement disponibles sans passer par les fourches caudines de l’ISO. Le consortium a été créé en 1993, il s’appelait à l’époque SGML Open. Il était constitué de fournisseurs et d’utilisateurs d’outils informatique, son but était le développement de lignes directrices pour l’interopérabilité de logiciels utilisant le langage de balisage SGML. Il change de nom en 1998 pour devenir OASIS qui reflète mieux les travaux du consortium. Parmi les cent-seize membres (l’adhésion est payante) : à peu près toutes les grandes entreprises de l’informatique américaine et quelques chinoises ou japonaises (Alibaba, Hitachi, Huawei, Fujitsu…) mais aussi des organismes tels que le Parlement européen, l’Office des publications européennes, le Ministère français de l’Intérieur, le FBI, des universités (Brno, Milan, Luxembourg, Oslo, Westminster, MIT, etc.), la Biblioteca del Congreso Nacional du Chili, TheDocumentFoundation, etc. Il existe en outre une fondation européenne à but non lucratif OASIS Open Europe (en) affiliée au consortium et dont l’objectif est de soutenir le rôle de l’Europe dans le développement de l’open source et des normes ouvertes.

La version 1.0 du format OpenDocument (ODF) pour les applications bureautiques a été approuvée le 1er mai 2005 à l’unanimité des soixante-dix-huit membres ayant voté. La version 1.0 des directives pour l’accessibilité du format ODF, quant à elle a été approuvée à l’unanimité des onze membres ayant voté le 1ᵉʳ mai 2008. La dernière version du format ODF est la 1.3 (en), approuvée le 27 avril 2021. LibreOffice l’a intégré à partir des versions 7, pratiquement à la sortie de la norme, c’est le format d’enregistrement par défaut. La norme ODF 1.3 a mis notamment l’accent sur la signature et le chiffrage des documents.

Le format ODF est basé sur le XML. C’est un fichier « compressé » qui en contient plusieurs6 :

  • le fichier meta.xml contient des informations au sujet du document (l’auteur, la date de la dernière sauvegarde),
  • le fichier styles.xml contient les styles utilisés dans le document,
  • le fichier content.xml contient le contenu principal du document (texte, tableaux, éléments graphiques…),
  • le fichier settings.xml, en général spécifique à une application, contient certains paramètres tels que l’imprimante sélectionnée…,
  • les fichiers META-INF/manifest.xml contiennent des informations supplémentaires sur les autres fichiers (comme le type MIME ou le chiffrement).

Plus des dossiers : Pictures, Thumbnails, etc.

Ce format est le format natif notamment de LibreOffice, OpenOffice7, Calligra, Collabora Online, GoogleDocs, Zoho, il est aussi ouvert, travaillé et enregistré par des logiciels tels que MsOffice depuis 2007 (2016 pour la version pour MacOS), Office365, OnlyOffice ou AbiWord (listes non limitatives).

L’une de ses très grandes forces est, qu’à l’instar du format HTML, toute la mise en forme repose sur des styles. Ce qui rend très évolutifs et adaptables les documents au format ODT (pour peu qu’ils le soient avec un logiciel qui le gère bien).

En France, le format ODF est le seul format bureautique recommandé par le référentiel général d’interopérabilité. Le format ODT étant mentionné comme format à privilégier par nombre d’administrations de par le monde.

Le format DOCX et son OOXML

L’année 2007 est celle qui « révolutionne » la suite bureautique de Microsoft. En effet, la firme abandonne les vieux formats pour en adopter des nouveaux basés sur le XML d’où le X de l’extension. Mais pas n’importe quel XML, le XML maison appelé Office Open XML (OOXML pour faire court). Il est fort probable que, ce faisant, l’idée était de court-circuiter le standard ODF. Microsoft a d’ailleurs livré une guerre féroce pour que son OOXML soit accepté par l’ISO en s’y reprenant à deux fois. La norme, adoptée le 17 aout 2008, porte le numéro ISO/IEC DIS 29500. Il est possible (probable ?) également que, Word étant ce qu’il est, se baser sur le XML de l’ODT aurait vraisemblablement nécessité un grand travail de refonte du logiciel. Il existe deux « variantes » de DOCX, le premier, celui de la version 2007 et celui de 2010. En effet, la norme ISO/IEC DIS 29500 n’est pas compatible avec Office 2007.

Sur le plan technique, il est reproché à l’OOXML sa complexité qui en rend difficile la mise en œuvre. À tel point qu’il se dit que Microsoft lui-même ne l’implémente pas correctement. La dernière version d’OOXML est actuellement la référence ISO/IEC 29500-1:2016 (en) de novembre 2016 (elle fait 5024 pages).

Sur le plan juridique, le caractère libre de la norme est flou, il en ressort une certaine instabilité sur ce plan. Avec les spécifications, Microsoft a distribué :

un document promettant de ne pas poursuivre les auteurs de l’utilisation d’Office Open XML dans un autre logiciel que ceux de Microsoft. Cette promesse de non-poursuite elle-même laisse certains flous, notamment :
• s’appliquant à la norme ECMA en l’état, s’applique-t-elle à une éventuelle version finale de l’ISO ?
• s’applique-t-elle à tous les brevets logiciels nécessaires à la mise en œuvre de la norme ?
• s’applique-t-elle également aux extensions du format OOXML ?
La licence d’utilisation de OpenXML est incompatible avec les programmes sous la licence GPL.8

À l’instar des fichiers ODF, le DOCX est un fichier compressé qui en contient plusieurs. On en trouvera l’anatomie (en) par exemple sur le site Office Open XML (en).9

Il est actuellement ouvert, voire travaillé et enregistré, de la plupart des suites bureautiques.

Des langages de balisages

Parler des formats de texte sans évoquer les langages de balisage serait assez inepte puisque les formats modernes sont basés dessus. Pour rappel, un langage de balisage est un langage servant à définir et à structurer les informations dans un document.

Il en existe de nombreux, mais on n’évoquera que ceux qui semblent les plus connus ou les plus utilisés.

TeX le grand ancien

TeX fait figure de grand ancien, puisque la première version du langage de balisage date de 1978. Cela dit, on devrait peut-être plutôt parler « d’écosystème » car c’est à la fois un format, le langage de balisage utilisé par LaTeX et un logiciel libre de composition. TeX a été créé par Donald E. Knuth, professeur émérite à l’Université de Stanford et considéré comme l’un des pionniers de l’algorithmique. L’objectif de Donald E. Knuth en créant TeX était d’avoir des documents scientifiques et techniques de bonne qualité typographique, ce qu’il n’était pas possible d’obtenir avec les logiciels d’édition de l’époque. Le principe du langage TeX est la séparation du contenu de et la forme, ce qui était innovant.

TeX est complété par LaTeX qui est « un ensemble de macros permettant de faire beaucoup de choses »10, et, bien sûr, par le langage de composition de polices vectorielles Metafont. LaTeX a été développé par Leslie Lamport. La première version est sortie en 1983.

Ce n’est pas un traitement de texte, l’idée étant que l’auteur ou l’autrice :

puisse mettre son énergie à rédiger le contenu sans être distrait par l’apparence de son document. En écrivant en langage LaTeX, l’utilisateur doit donc définir sémantiquement le contenu de son document plutôt que visuellement. DMS, Université de Montréal.

On peut générer des fichiers TeX soit directement avec un éditeur de texte, soit avec des logiciels comme Lyx ou encore Overleaf qui est un éditeur LaTeX en ligne et collaboratif. Mais, pour en voir le rendu, il faudra soit faire un PDF, si on utilise un éditeur de texte, soit passer par le visualiseur, quand il existe, dans un logiciel tel que Lyx.

À ma connaissance la plupart des suites bureautiques ne l’acceptent pas, pas plus que Calibre d’ailleurs.

La dernière version de TeX, 3,143.141592653 date de janvier 2021. Le format est géré par le groupe des utilisateurs de TeX ou TUG (en). LaTeX quant à lui est géré par le projet LaTeX (en). La dernière version date de juin 2024.

Le SGML et ses petits

Le SGML, S pour Standard, G pour Generalized, M pour Markup et L pour Langage (langage de balisage généralisé normalisé) possède le numéro de norme ISO 8879:1986. 1986 étant l’année d’obtention du numéro ISO, la première version du SGML étant sortie en 1978. Produit de l’industrie de l’édition, il a adopté, comme TeX, le principe de la séparation complète du fond et de la forme. C’est, en fait, une norme permettant de définir des langages de balisage génériques pour des documents. SGML sera, dès 1984, le format standard des publications officielles des Communautés européennes.

Ce qui caractérise un document SGML : il doit posséder une « définition du type de document » (DTD ou doctype en anglais). Cette DTD sert à indiquer la structure du document. Et, évidemment le système de balises que l’on va retrouver chez les membres de la famille.

HTML, sans lequel, possiblement, LinuxFr.org ne serait pas

Le langage HTML, pour HyperText Markup Language, est un langage de balisage pour l’hypertexte, cette fonctionnalité qui permet de naviguer sur internet. Il a été créé, ou plutôt lancé au début des années 1990 par Tim Berners-Lee qui en a profité pour concevoir au passage la forme des adresses Web que nous connaissons (les URL) et le protocole de communication HTTP.

Le format HTML est géré par le World Wide Web Consortium (W3C) fondé en 1994 par Tim Berners-Lee. L’objectif du W3C : émettre des normes et des recommandations pour le web.

La première version de HTML était très limitée : cela n’allait pas plus loin que la structure du texte avec les balises de titres et de listes, et les liens hypertextes.

En 1999, sort la version 4 (en) qui deviendra une norme ISO en 2000. La norme HTML 4 supporte pleinement le langage de mise en forme CSS (Cascading Style Sheet ou feuilles de style en cascade). Le HTML 4 existe en trois variantes, si on peut dire :

  • le HTML strict qui exclut les éléments de « présentation » puisque qu’il revient au CSS de faire le travail de mise en forme,
  • le HTML transitionnel accepte quelques balises de présentation obsolètes héritées du HTML 3,
  • frameset qui normalise les jeux de cadre, les «frames ».

La dernière version de HTML est le HTML 5 publié en 2012. Il ne remplace pas le HTML 4.1 : les deux standards coexistent. HTML 5 apporte en plus des fonctionnalités d’animations complexes, multimédia avec de l’audio et de la vidéo, etc. jusque-là assurées notamment par le logiciel privateur Flash. HTML 5 s’est aussi éloigné du SGML.

XML le futur du HTML

C’est, en tout cas, ainsi que s’intitulait en 1998 un article (en) de Todd Freter (en) directeur de programme chez Sun Microsystem. Défini comme un sous-ensemble de SGML, « le XML a été conçu pour être facile à mettre en œuvre et interopérable avec SGML et HTML »11. De fait les syntaxes HTML et XML sont les mêmes. L’une des différences fondamentales entre les deux était, au départ, qu’il était possible de définir ses propres balises avec XML, mais pas avec HTML. Un comportement qui a été modifié en 2014 pour HTML avec les Web Components (en).

XML (eXtensible Markup Language) a été développé par un groupe de travail piloté par le W3C à partir de 1996, avec, comme président, Jon Bosak (en) de Sun Microsystems. Les objectifs, à sa sortie en 1998, étaient les suivants selon la Recommandation du W3C du 10 février 1998 :

  1. XML devrait pouvoir être utilisé sans difficulté sur Internet ;
  2. XML devrait soutenir une grande variété d’applications ;
  3. XML devra être compatible avec SGML ;
  4. Il devrait être facile d’écrire des programmes traitant les documents XML ;
  5. Le nombre d’options dans XML doit être réduit au minimum, idéalement à aucune ;
  6. Les documents XML devraient être lisibles par l’homme et raisonnablement clairs ;
  7. La conception de XML devrait être préparée rapidement ;
  8. La conception de XML sera formelle et concise ;
  9. Il devrait être facile de créer des documents XML ;
  10. La concision dans le balisage de XML est de peu d’importance.

Qu’en est-il aujourd’hui de ces principes ?

En fonction de la syntaxe XML du document, s’il est transmis avec le type MIME text/html, il est vu par les navigateurs comme un fichier HTML. En revanche, s’il est transmis avec un type XML MIME, il sera traité comme un document XML. Dans le deuxième cas de figure, des erreurs de syntaxe même mineures empêcheront un document étiqueté XML d’être correctement restitué alors qu’elles seraient ignorées dans la syntaxe HTML. L’objectif 1, n’est donc pas atteint et XML ne remplace définitivement pas HTML. En revanche, XML est effectivement très utilisé : outre les formats ODF et OOXML, c’est le langage sur lequel est basé le format SVG (Scalable Vector Graphics, ou, en français graphique vectoriel adaptable) et c’est le format de référence pour l’échange de données. Mais, pour ce qui est de la lisibilité du format par des yeux humains, elle n’est pas toujours au rendez-vous.

XML est maintenu par le W3C. La dernière version (en) porte le numéro 1.1, elle est sortie le 29 septembre 2006.

Langages de balisage léger

Les langages de balisage léger sont conçus pour être facile à utiliser avec un éditeur de texte. La syntaxe en est simple.

Le MarkDown, peut-être le plus connu d’entre eux, a été créé en 2004 par le programmeur américain John Gruber; aidé d’Aaron Swartz. Il n’a pas subi d’évolution importante depuis. En revanche, il en existe des variantes. John Gruber le définit comme :

un outil de conversion de texte en HTML destiné à la rédaction Web. Markdown vous permet d’écrire en utilisant un format de texte brut facile à lire et à écrire, puis de le convertir en XHTML (ou HTML) structurellement valide. Daring Fireball (en).

Pour en savoir plus sur la syntaxe MarkDown, on peut, très profitablement, se référer au wiki de LinuxFr.org.

Il en existe d’autres comme txt2tags créé en 2001 ou encore AsciiDoc (en) dont la première version date de 2002. Txt2tags (en) est un logiciel générateur de documents écrit en Python et qui utilise un langage de balisage léger comme source. Quant à AsciiDoc, il se veut un langage particulièrement adapté à la rédaction de documentations techniques. Il existe aussi le langage de balisage du CMS (gestion de contenu web) SPIP, né en 2001.

L’archivage et la conservation des textes

Il est ici, évidemment question des formats d’archivage des textes, avec ou sans images, tableaux, formules de mathématiques, etc. Avant d’aborder cette question : une définition s’impose. Il ne s’agit pas des formats dits d’archives de type .zip, .rar, .tar etc. Archiver les textes c’est, dans ce contexte, pouvoir les conserver et y accéder sans avoir besoin de l’application qui a servi à les générer. Et ce soit en conservant la mise en page d’origine, comme pour le PDF, soit en laissant à l’outil de lecture la main pour la mise en page. Chaque format a ses spécificités. Mais de toute façon :

un bon format de préservation, c’est un bon format tout court. Outils open source nombreux, métadonnées internes bien foutues, démarche collective de normalisation… Bertrand Caron, archiviste numérique à la BnF, janvier 2024.

EPUB

L’EPUB, pour Electronic PUBlication, est un format de document numérique qui n’est pas destiné à l’impression. L’une de ses spécificités est, notamment, de laisser à l’utilisatrice ou l’utilisateur le choix du rendu du fichier. Il existe, toutefois, un mode « fixed-layout » qui fige la mise en forme de l’EPUB. Ce mode a été conçu pour les publications qui nécessitent que la mise en page soit respectée, comme certaines publications scolaires. Mais cela réclame une mise en page adaptée aux tailles des écrans des appareils de lecture.

EPUB a succédé au format OeB (Open eBook). Au départ, géré par l’International Digital Publishing Forum (IDPF) qui sera intégré au W3C en 2017. La première version sort en 2007, suivie, en 2010 par l’EPUB2 et, en 2011, par l’EPUB3. Il a été très vite adopté. Aujourd’hui les deux versions coexistent, l’EPUB2 prédominant encore sur l’EPUB3. Le format est basé sur XML et sur HTML. Un fichier EPUB est un fichier zip qui contient plusieurs fichiers et répertoires dont un dossier META-INF qui contient un fichier container.xml, ce dossier n’apparait pas quand on génère un fichier à partir de Sigil d’ailleurs. Les fichiers de texte sont au format XHTML.

Qu’apporte l’EPUB3 par rapport à l’EPUB2 ? Les évolutions concernent principalement l’accessibilité et l’intégration de contenus audio ou vidéo. Ainsi les formules de mathématiques qui, en EPUB2 sont converties en images, donc illisibles sans yeux, sont gardées en tant que telles avec EPUB3. Les liseuses ne supportent pas forcément toutes les fonctions, notamment multimédias.

Il est possible d’y ajouter différents types de marquage ou de verrous : les DRM Adobe, chères et complexes, les DRM LCP, très pratiques pour le prêt des livres en bibliothèque ou encore des filigranes qui n’imposent aucune limitation aux EPUB. L’apposition d’une DRM a un EPUB est, en principe, une décision éditoriale. Il semble néanmoins que certaines librairies éprouvent le besoin d’en rajouter. Il convient donc d’être vigilant quand on achète un EPUB si on veut éviter d’avoir un livre avec une DRM. Le livre numérique représente 10,1 % du chiffre d’affaires de l’édition française en 2023, ce qui inclut les EPUB et les PDF.

La version la plus récente du format EPUB et l’EPUB3.3 sortie en mai 2023. Elle est devenue une Recommandation W3C (en).

PDF

L’objectif du format PDF a contrario de celui de l’EPUB est le respect de la mise en page du fichier qui a servi à le générer. De ce fait, il n’est pas très lisible sur une liseuse ou sur un téléphone.

La naissance du PDF remonte à 1991 et elle est due à John Warnock cofondateur d’Adobe. La première version de ce format est sortie en 1992. À l’époque c’était assez fou de pouvoir accéder à un fichier avec sa mise en page d’origine sans qu’il soit nécessaire d’avoir l’application qui avait servi à le générer. Il deviendra un standard ouvert géré par l’ISO en 2008, numéro ISO 32000.

En fait il n’existe pas un, mais plusieurs formats PDF dont :

  • PDF/A pour l’archivage,
  • PDF/E pour les documents techniques,
  • PDF/X pour l’impression,
  • PDF/UA pour l’accessibilité universelle,
  • ou encore des formulaires FDF.

La version PDF/A-3 permet d’incorporer le fichier d’origine au PDF : dans l’export PDF de LibreOffice, cela s’appelle un PDF hybride. Cela donne un fichier qui pèse deux fois plus lourd, grosso modo, minus le poids des polices embarquées, que le PDF « simple ». Et, si on ouvre le PDF à partir de l’application qui a servi à le créer, ou si on clique sur « Cliquer pour les afficher » (ou équivalent) dans un lecteur de PDF qui le permet, ici Okular, on ouvre le fichier d’origine. Mais, évidemment, quand on le modifie ça ne modifie pas le PDF. Il faut soit générer un nouveau PDF soit l’écraser.

À savoir, il n’y a que quatorze polices standard PDF, en fait seulement cinq fontes différentes avec leurs variantes, gras, italiques : Courrier, Helvetica, Times Roman, Symbol et Zapf Dingbats. Il est donc très important, quand on génère un PDF d’incorporer les polices au fichier à condition que cela soit permis par la licence des polices. Pour ne pas alourdir le fichier, il est suggéré de n’incorporer que les polices utilisées dans le document. Avec LibreOffice, vous pouvez configurer cela soit en générant le PDF, soit, de préférence, la première fois que vous enregistrez le fichier, c’est dans l’onglet « Police » des propriétés dudit fichier. Si vous utilisez un modèle, la case peut avoir été cochée dans le modèle et il ne sera pas nécessaire de le faire.

Kurinto une histoire de chasses

La chasse, en typographie, est l’encombrement d’un caractère : largeur plus approche (espace autour). Pour un même corps de caractère (sa hauteur), elle peut varier selon les polices, ce qui, évidemment, peut changer, voire, chambouler, complètement un document créé avec une police et pour lequel on a changé la typographie. La collection de polices Kurinto (en) a été dessinée à la fois pour couvrir un large éventail de langues et de systèmes d’écriture et dans l’optique de pouvoir remplapcer les polices Microsoft avec des glyphes qui ont la même chasse.

Si vous cherchez des polices au dessin élégant pour remplacer des fontes comme le couple Arial/Times New Roman, avoir aussi des typographies à chasse fixe ou légèrement fantaisie, l’ensemble de polices Kurinto est un bon choix qui offre en prime une bonne cohérence entre les diverses polices. Elles sont sous licence SIL.

Déclinaison des noms des polices Kurinto permettant de voir leurs chasses respectives

Les textes et documents qui ont servi à alimenter cette dépêche

Les références sont données à peu près dans leur ordre d’apparition dans le texte. Ils sont tous accessibles en ligne et, de préférence, en français. Volontairement, il y a un minimum de références à Wikipédia. Ce n’est pas tout à fait exhaustif, mais ça vous fera déjà pas mal de lecture. Par exemple, je n’ai pas cité le blog de Stéphane Bortzmeyer qui m’a bien servi à défricher le terrain.

Les formats matériels

  • Sur les rouleaux notamment leur rangement. Le site Rotulus est consacré aux rouleaux médiévaux.
  • Guide pratique du compositeur d’imprimerie, Théotiste Lefèvre, un guide considéré longtemps comme une, si pas LA, référence en matière de typographie et d’imprimerie. Paru en 1855, il fera l’objet de multiples éditions, les dernières en 2000. Aujourd’hui encore, ses pages sur la typographie peuvent servir de références. Théotiste Lefèvre était le fils d’un apprenti compositeur. Il commencera comme ouvrier en imprimerie pour devenir une figure clé du secteur. Sa fille deviendra correctrice. La version du guide donnée en téléchargement sur le site archive.org est d’assez mauvaise qualité. De toute façon, avec le texte brut ou la piètre qualité de la reconnaissance des caractères on perd absolument tout ce qui fait l’intérêt du livre qui donne beaucoup d’exemples.
  • Sur les formats A. Le site donne les dimensions des feuilles de papier en centimètres et en pixels.

Les formats numériques (texte et archivage)

La police

Postambule

La prochaine dépêche de la série devrait être moins longue (pas difficile) et portera sur le code avant Unicode. Elle parlera donc aussi de football. Comme toujours, vos suggestions sont appréciées.

  1. MOLINIER A. « Les manuscrits et les miniatures », BnF Gallica: Librairie Hachette, 1892. Disponible sur : BnF Gallica en PDF ou en texte brut. ↩

  2. L’exemple est reproduit à partir du petit guide de Charles-Lucien Huard La Typographie. ↩

  3. Pour rappel, un RFC (Request For Comments) est un document qui définit les normes techniques sur les lesquelles s’appuient le réseau Internet. ↩

  4. ANDRÉ Jacques, « Caractères, codage et normalization. De Chappe à Unicode », Document numérique, 2002/3-4 (Vol. 6), p. 13-49. DOI : 10.3166/dn.6.3-4.13-49.. ↩

  5. Les formats de texte, archives. ↩

  6. Wiki de LibreOffice. ↩

  7. À noter qu’OpenOffice, compte tenu de son absence d’évolution ne supporte pas la norme ODF 1.3. ↩

  8. Office Open XML – Définition. ↩

  9. Pour tout dire, mon gestionnaire d’archives Engrampa est incapable d’ouvrir un fichier .docx et l’explication du site, qui n’est pas un site officiel, me semble très touffue. ↩

  10. Littéralement : « set of macros to let you do many things ».What is the difference between TeX and LaTeX? (en). ↩

  11. Langage de balisage extensible (XML) 1.0, Recommandation du W3C, 10 février 1998. ↩

Commentaires : voir le flux Atom ouvrir dans le navigateur

↗️

S.M.A.R.T. badblocks badblocks2

✇LinuxFr.org
Par : admru1 Ysabeau 🧶 🧦 patrick_g bobble bubble Benoît Sibaud palm123

S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) est un système de surveillance intégré aux disques durs modernes et aux disques SSD. Il évalue en continu le bien-être du périphérique tout en anticipant les éventuels dysfonctionnements. Il utilise une réserve de secteurs de rechange pour réparer quand il détecte un secteur en anomalie.
Le programme Linux badblocks teste les blocs d’un média par écriture+relecture+comparaison. À l’origine il servait à mettre les blocs mauvais en liste noire dans le file-system.

Est-il utile de nos jours de vérifier ses médias ?
Comment se situe S.M.A.R.T. par rapport à l’outil badblocks ?
Comment vérifier un média en tenant compte de sa surveillance par S.M.A.R.T. ?

C'est ce que nous allons voir dans la suite de la dépêche.

smart-drive

Sommaire

Préambule

Quelle précaution prendre vis-à-vis du risque de mauvaise qualité du stockage, quand je viens d’acheter un média (disque SSD, disque rotatif, clé USB, carte SD) ou un appareil sous Linux équipé d’un espace de stockage dont j’ignore la technologie ?
Sans être parano, je me dis qu’avant d’envoyer des données précieuses sur l’espace de stockage, c’est le moment de faire certaines vérifications. Mais quelles vérifications ? Qu’est-il possible de faire ?

Sur un média connectable, tout est possible.
Sur un appareil neuf sans système ni données, tout est possible en utilisant une distrib Live.
Sur les autres, ça dépend, il y en a où on n’a même pas un accès root pour lancer une vérification « dure » ou « molle » (Android, routeur…).

En écrivant cet article, je me suis rendu compte que je ne me suis jusqu’ici jamais posé de questions sur l’opportunité de vérifier les espaces de stockage de mes téléphones, PC portables, routeurs, box… bref tous les appareils vendus prêts à être utilisés. Pourtant, que sais-je de la vérification faite par celui qui a installé le système ? Rien, et j’utilise, sans penser que l’espace de stockage de l’appareil n’est ni plus ni moins robuste que celui du PC Linux que j’ai installé dernièrement, mais que j’ai vérifié consciencieusement.

S.M.A.R.T.

S.M.A.R.T. est un système de surveillance intégré aux disques durs modernes et aux disques SSD. Il évalue en continu le bien-être du périphérique tout en anticipant les éventuels dysfonctionnements. Il surveille un maximum de paramètres (température, temps de fonctionnement, vitesse de rotation pour les disques magnétiques, nombre de démarrages et d’arrêts…) et dépend de l’expérience du fabricant. La réparation de secteurs utilise une réserve de secteurs et le mapping entre secteurs logiques et secteurs physiques.

On pourrait se dire que, de nos jours, les supports sont fiables et testés par les intégrateurs. D’autres considèrent que la technologie S.M.A.R.T. suffit… et c’est bien commode de ne plus se soucier de la fiabilité des supports de stockage. Mais à la première galère due à un média défaillant, tu évolueras dans ta confiance.

Sais-tu seulement sur lesquels de tes médias S.M.A.R.T. est installé et actif ?
Si tu utilises un RaspberryPi, ton média système est… une carte SD. Elle n’a pas S.M.A.R.T.. Idem pour l’extension de mémoire que tu as ajoutée à ton téléphone.

Je t’invite à lire la page Wikipedia sur S.M.A.R.T. et son paragraphe « Standard, implémentation et limitations ». Que fait et que ne fait pas le S.M.A.R.T. qui fonctionne sur le disque du PC qui te permet de lire cet article ? Difficile de savoir. Comment est-il configuré ? Fais un sondage autour de toi à ce sujet et tu seras pris pour un parano.

Sur ton PC, sais-tu qu’il y a une option S.M.A.R.T. dans le BIOS (ou UEFI) ? Sais-tu qu’il y a un service smartd dans ton Linux ? As-tu compris aussi qu’avec du RAID il n’est pas toujours opportun d’activer S.M.A.R.T. ? Les communications entre S.M.A.R.T. RAID et l’O.S. peuvent se passer plus ou moins bien selon la qualité de ces éléments. Il te faut bien comprendre ce qu’il est possible de paramétrer et deviner comment ça marche derrière.

Si tu demandes une vérification à S.M.A.R.T. par smartctl, sais-tu ce qu’il fait ? Se contente-t-il de lire ou fait-il un test en écriture ?

Enfin, quand S.M.A.R.T. détecte qu’un secteur est devenu défectueux, il ne peut pas deviner quels bits sont défaillants, aussi il renseigne le secteur de secours avec ce qu’il peut, qui est l’état du secteur après défaillance. S.M.A.R.T. a ses limites, il répare comme il peut. S’il est configuré pour, il alerte quand il prévoit de la défaillance, mais sais-tu reconnaître ses alertes ? As-tu compris ce que tu dois faire en réponse aux alertes ?

Je t’invite à apercevoir la complexité de prise en main de S.M.A.R.T. en faisant quelques recherches sur ces listes de mots :

smartctl howto
smartctl configure self test
smartd howto

et tu verras que ce n’est pas simple à comprendre et à configurer.

Tu peux te dire naïvement que tout est bien configuré par défaut et que tes médias seront toujours impeccables. Sinon, il va falloir investir en temps et faire quelques essais. À toi de choisir.

S.M.A.R.T. est une belle avancée technologique, mais il est dangereux de lui attribuer des mérites indus.

BADBLOCKS

Le programme Linux badblocks a été créé en même temps que le paquetage e2fsprogs (mkfs.ext2, mkfs.ext3, mkfs.ext4, fsck.ext2…). À l’époque S.M.A.R.T. n’existait pas et il n’y avait pas de mapping entre les adresses logiques et physiques. C’est le file-system qui devait tout gérer quand il détectait un bloc défectueux, notamment la mise du bloc en liste noire. C’est pour cela que mke2fs et e2fsck lancent un badblocks « dur » quand on leur spécifie deux fois l’option -c. Cela dure trèèès longtemps car les paramètres par défaut ne sont plus bien optimisés.

Depuis l’arrivée de S.M.A.R.T., certains considèrent badblocks comme obsolète. Mais qui peut affirmer que TOUS les médias utilisés par TOUS les usages de Linux sont équipés de S.M.A.R.T. ?
Peut-être qu’au M.I.T. avec un réseau de classe A, on ne s’abaisse pas à utiliser une clé USB ou un RaspberryPi. Je me demande dans quel type de bulle vivent ceux qui pensent que S.M.A.R.T. est sur tous les médias de stockage.

Quand j’achète une clé USB, je lui passe badblocks dessus et s’il y a des mauvais blocs, je la rends et je me fais rembourser.
J’ai essayé d’interroger les fonctionnalités S.M.A.R.T. de diverses clés USB et je n’ai rien obtenu, comme si cette utilité n’y était pas installée :

# smartctl --scan-open
# smartctl -x /dev/sdc
# smartctl -i -d scsi -T verypermissive /dev/sdc

Mes recherches sur Internet n’ont abouti à rien qui me permette de voir une réponse de la part de clés USB. Peut-être que si j’achetais (cher) des clés USB de très haute qualité, j’y trouverais S.M.A.R.T. ?

Comme l’intervenant du message #25 de ce rapport de bug (en), je pense que badblocks est loin d’être obsolète.
J’ai envie d’imiter le message #20 juste au-dessus en disant : « Je dois demander --- ***pourquoi*** vous (et d’autres personnes) mettez de l’essence dans vos voitures en 2024 ? L’essence en tant que chose a commencé à devenir inutile pour les voitures vers 2011, lorsque la voiture électrique s’est répandue, et que les batteries sont devenues suffisamment énergétiques pour faire rouler des véhicules sur des centaines de km ».

Je t’invite aussi à une recherche sur la liste de mots « courbe en baignoire composants électroniques ». Le programme badblocks peut servir au déverminage. On sait en détail ce qu’il fait. Son résultat est clair, contrairement aux implémentations propriétaires de S.M.A.R.T..
Sans déverminage (rodage) on court le risque de subir trop tôt une réparation discrète incomplète : le secteur réparé sera physiquement bon mais son contenu sera corrompu. La conséquence peut être catastrophiquement discrète. Par exemple, un fichier LibreOffice est une archive zip (compressée), la corruption d’un seul bit y a des conséquences imprévisibles.

De mon côté, j’utilise badblocks pour tester les médias nouvellement acquis et pour effacer ceux bons à réformer. Ce programme permet aussi la chasse aux médias « fake-size », du genre carte SD de 1To qui accepte de recevoir 1To de fichiers, mais qui ne stocke en réalité que 8Go. On trouve de nos jours (juin 2024) des clés USB de 16To vendues au prix de 5 € ! L’application h2testw sous windows et son équivalent f3 sous linux sont spécialement conçus pour cette chasse. Le microprogramme de ces clés USB ou de ces disques a été détourné pour déclarer un espace de stockage falsifié. C’est de l’escroquerie.

BADBLOCKS2

Mon usage du badblocks du paquetage e2fsprogs-1.47.0 m’a amené à y caractériser un bug reproductible en novembre 2023. J’ai eu l’intention de remonter le bug aux équipes ad hoc de ma distribution (Mageia) mais je me suis d’abord mis à regarder le source.

J’y ai trouvé l’origine du bug, et j’ai trouvé d’autres bugs. En ajoutant des instructions de traçage et de simulation d’erreurs du média, j’ai mis en évidence encore d’autres bugs. De fil en aiguille, j’ai fini par retoucher profondément certains algorithmes, et j’ai appelé badblocks2 cette nouvelle version. J’y ai ajouté diverses options faciles à programmer et commodes à l’usage. J’ai copieusement testé.

Si tu veux essayer badblocks2 et/ou prendre connaissance de ma démarche, je livre tout sur mon site. Tu verras pourquoi je me suis rabattu sur la création d’une nouvelle version, plutôt que de faire remplacer l’ancienne (ce qui aurait profité à tous).
Tu peux te faire une idée des fonctionnalités ajoutées en consultant les *.8.txt .
Tu peux t’inspirer des tests décrits dans le fichier Alire.txt, tester diverses valeurs pour -c -t et voir l’effet sur la vitesse de traitement. Tu peux même jouer à arracher la clé en cours de test (Ctrl-C pour arrêter) !

J’espère que ce programme servira à d’autres que moi.

En pratique

Voici une suggestion d’actions à faire lors de l’acquisition d’un nouveau média (disque SSD, disque rotatif, clé USB, carte SD…). Les commandes doivent être lancées par l’opérateur root.
Avec cela, quand dans quelques années tu satureras le média, tu seras sûr que le dernier secteur utilisé aura été déverminé avant la mise en production.

ATTENTION : les usages de badblocks proposés sont destructifs pour les données présentes sur le média. Le mode non-destructif du badblocks actuel comporte des bugs (version e2fsprogs-1.47.0). Celui de badblocks2 a été corrigé.
ATTENTION : la liste des mauvais blocs renvoyée par le badblocks actuel est fausse (version e2fsprogs-1.47.0). Le nombre de mauvais blocs est correct. La liste renvoyée par badblocks2 est correcte.
ATTENTION : le paramètre device du média est supposé être /dev/sdc. Ne pas se tromper, au risque d’effacer un autre média en cours d’usage.

D’abord déterminer le block-size du noyau, c’est une bonne valeur à prendre comme block-size du file-system :

# blockdev --getbsz /dev/sdc

Dans ce qui suit, je suppose que la valeur 4096 a été renvoyée.

Ensuite déterminer si S.M.A.R.T. est sur le média :

# smartctl --scan-open
# smartctl -x /dev/sdc
# smartctl -i -d scsi -T verypermissive /dev/sdc

Si S.M.A.R.T. n’est pas sur le média

Passer badblocks2 pour voir s’il y a 0 ou peu de mauvais blocs :

# badblocks2 -b 4096 -c 32768 -wrrvvss -t r -t r -e 40 -o /tmp/sdc.bb /dev/sdc

L’option -e peut être supprimée ou modifiée selon la limite du nombre de mauvais blocs considérée acceptable ; les options -t peuvent être différentes selon la sévérité souhaitée (voir le man).

S’il y a trop de mauvais blocs, refuser d’utiliser le média (->garantie ?).

S’il y a 0 mauvais bloc on peut formater en toute tranquillité (partitionner éventuellement avant) :

# mkfs.ext? -b 4096 ... /dev/sdc

S’il y a quelques mauvais blocs, sans que la limite -e soit atteinte, on pourra formater en utilisant la liste sauvée de mauvais blocs :

# mkfs.ext? -b 4096 -l /tmp/sdc.bb ... /dev/sdc

Si l’on veut partitionner, il faudra recalculer la liste des mauvais blocs de chaque partition avant de formater (remplacer sdc par sdc1 dans les commandes badblocks2 et mkfs.ext? ci-dessus).

Si l’on veut formater en vfat exfat ou f2fs (clés USB en général), il n’est pas possible d’utiliser la liste des mauvais blocs détectés ; la seule solution est de refuser d’utiliser le média s’il y a des mauvais blocs (ou alors de restreindre l’usage à une zone saine… à localiser)

Si S.M.A.R.T. est sur le média

On peut vérifier son activation par smartctl :

# smartctl -i /dev/sdc

Ensuite, il faut interroger le média sur l’état et les capacités de son S.M.A.R.T. :

# smartctl -a /dev/sdc

Noter le nombre de réallocations faites et prévues :

# smartctl -a /dev/sdc | grep -i _sector

Puis faire une passe de déverminage, en écriture+lecture car on ne sait pas si l’écriture seule suffit ; ne pas utiliser l’option -p de badblocks ; les options -t peuvent être différentes selon la sévérité souhaitée (voir le man) :

# badblocks2 -b 4096 -c 32768 -wrvvss -t r -o /tmp/sdc.bb1 /dev/sdc

Faire une passe de vérification, il ne devrait plus y avoir de mauvais blocs :

# badblocks2 -b 4096 -c 32768 -wrvvss -t r -o /tmp/sdc.bb2 /dev/sdc

S’il y a encore des mauvais blocs, c’est soit que le déverminage n’est pas terminé, soit que le média et/ou son S.M.A.R.T. sont foireux (il ne détecte pas les mauvais secteurs vus par badblocks2 ou les secteurs de réserve sont mauvais ou… pire) ; relancer des passes une par une jusqu’à ce qu’il n’y ait plus de mauvais bloc détecté.

Re-interroger S.M.A.R.T. pour voir l’évolution des réallocations :

# smartctl -a /dev/sdc | grep -i _sector

Ensuite on peut formater (partitionner éventuellement avant) en considérant que le média a remappé tous ses mauvais secteurs et est donc impeccable pour l’utilisation :

# mkfs.ext? -b 4096 ... /dev/sdc

Par la suite, on pourra de temps en temps consulter l’état de santé du média en service :

# smartctl -H /dev/sda

Si on est courageux, on peut lancer de temps en temps un contrôle du média par son S.M.A.R.T.
Si on est encore plus courageux, on configurera smartd pour que ces vérifications soient automatiques et pour que les alertes soient envoyées par courriel.

Attention à la communication entre l’O.S., S.M.A.R.T. et RAID (niveau carte mère / niveau OS / contrôleurs bas de gamme), voir la page Wikipedia sur S.M.A.R.T..

Que l’esprit « aware » soit en toi, sur tes données et sur ton espace de stockage

Commentaires : voir le flux Atom ouvrir dans le navigateur

↗️

Sailfish OS, quoi de neuf en 2024 depuis octobre 2022 ?

✇LinuxFr.org
Par : TuxMips pherjung BAud patrick_g Damien Caliste Arkem Xavier Teyssier Benoît Sibaud

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

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.

Écran de verrouillage

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.
Struven Ketju
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.
Calendrier
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 :

Grille d'application

  • 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 :

ownKeepass

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 :

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.

Commentaires : voir le flux Atom ouvrir dans le navigateur

↗️

Systemd v256

✇LinuxFr.org
Par : ɹǝɓuᴉɹǝɐH ʅǝnuɐɯɯƎ-sᴉxǝʅⱯ L'intendant zonard patrick_g Arkem Benoît Sibaud cg BAud

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

  • 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

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.

Commentaires : voir le flux Atom ouvrir dans le navigateur

↗️

Projets libres ! Episode 26 : Odoo Community Association

✇LinuxFr.org
Par : Podcast Projets Libres ! Benoît Sibaud patrick_g

Pour ce nouvel épisode de Projets libres !, nous partons à la rencontre de l'association communautaire Odoo, l'OCA (Odoo Community Association).

Nous avons le plaisir de recevoir Joël Grand-Guillaume, son président.
Ensemble nous abordons les thèmes suivants :

  • les enjeux de sa création
  • son fonctionnement et sa gouvernance
  • son financement
  • les rapports avec l'éditeur Odoo et les évolutions de ce dernier
  • sa communauté
  • les grands défis de son avenir

L'épisode possède une transcription et une traduction en anglais.

Bonne écoute !

Commentaires : voir le flux Atom ouvrir dans le navigateur

↗️

Vidéos des dernières conférences

✇LinuxFr.org
Par : Benoît Sibaud Xavier Teyssier patrick_g

Le festival Pas Sage En Seine (société, internet, liberté) a eu du 31 mai au 2 juin 2024. Les vidéos ont été publiées (annonce des vidéos April).

L'April a publié treize transcriptions au mois de mai 2024, ce qui correspond à dix heures et trois minutes d’enregistrements audio ou de vidéos.

La « conférence pour l'éthique et la diversité dans la tech avec des crêpes et du cœur » MiXiT a eu lieu en avril. Les vidéos ont été publiées (une sélection par Frédéric Couchet).

L'OW2con 2024 a eu lieu les 11 et 12 juin 2024. Les vidéos ne sont pas encore disponibles (voir celles de 2023). Mise à jour : les vidéos 2024 sont désormais disponibles

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    ↗️

    GIMP 2.10.38 est sorti

    ✇LinuxFr.org
    Par : Jona L'intendant zonard Julien Jorge Benoît Sibaud patrick_g

    Note : cette dépêche est une traduction de l'annonce officielle de la sortie de GIMP 2.10.38 du 3 mai 2024 (en anglais).

    Cette (peut-être dernière) version stable de GIMP 2 apporte des rétroportages très demandés de GTK3, y compris une prise en charge améliorée des tablettes sous Windows. Un certain nombre de corrections de bugs et d’améliorations mineures sont également incluses dans cette version.

    Sommaire

    Cette actualité répertorie les changements les plus notables et visibles. En particulier, nous ne répertorions pas toutes les corrections de bogues ou améliorations mineures. Pour obtenir une liste plus complète des modifications, vous devez vous référer au fichier NEWS ou consulter l'historique des commits.

    Nouvelles fonctionnalités et améliorations

    Prise en charge améliorée des tablettes sous Windows

    Avant cette version, GIMP prenait uniquement en charge la connexion de tablettes sous Windows via les pilotes WinTab plutôt que les nouveaux pilotes Windows Ink. Pour cette raison, nous avons reçu un certain nombre de rapports concernant des tablettes présentant des problèmes avec des boutons qui ne répondent pas, une sensibilité à la pression incorrecte, un mouvement de brosse retardé et des changements de position à mi-course.

    Ces problèmes étaient dus à une limitation de GTK2, car la prise en charge de Windows Ink a été implémentée dans GTK3 par Luca Bacci, contributeur de longue date. Pour cette version, Luca a eu la gentillesse de rétroporter ce support vers GTK2. Vous pouvez désormais basculer entre les pilotes WinTab et Windows Ink (s’ils sont pris en charge par votre ordinateur) dans la boîte de dialogue Préférences sous les paramètres du périphérique d’entrée.

    Windows Pointer Input API option in GIMP 2.10.38
    Windows Pointer Input API peut être changé maintenant - GIMP 2.10.38

    Rétroportages d’autres fonctionnalités de GTK3

    Luca a également contribué à plusieurs autres fonctionnalités portées de GTK3 à GTK2. Certaines des améliorations rétroportées incluent la mise à jour de la taille de la boîte de dialogue d’impression afin que les boutons ne soient pas coupés, la résolution de problèmes avec les boîtes de dialogue contextuelles apparaissant derrière les précédentes et plusieurs correctifs concernant la saisie au clavier.

    Ces améliorations concernent principalement Windows et sont déjà incluses dans la version de développement 2.99. Cependant, nous sommes très heureux que ces améliorations de la qualité de vie soient désormais disponibles dans cette version stable de GIMP 2.10 !

    Corrections de bogues

    Crashs récents

    Deux crashs fréquemment signalés ont été corrigés. Un changement dans GLib 2.80 a exposé un bogue dans notre processus de fermeture et provoqué un crash à la sortie. Luca Bacci a une fois de plus conçu un correctif pour la version 2.10.38 et la prochaine version candidate 3.0. Un autre crash que certains utilisateurs rencontraient lors de très petites sélections a également été corrigé.

    Autres correctifs

    Un certain nombre d’autres petits bugs ont été corrigés dans cette version. Parmi eux :

    • Les PNG indexés avec transparence sont désormais exportés avec les bonnes couleurs
    • Anders Jonsson a corrigé les plages d’entrée de plusieurs filtres tels que Waves et Distort
    • Le champ de personnalisation de la barre de titre prend désormais en charge les caractères UTF-8
    • Les commentaires d’images existants ne « fuient » plus dans les images nouvellement créées

    Statistiques de sortie

    Depuis GIMP 2.10.36 :

    • 16 rapports ont été clos comme CORRIGÉS dans la version 2.10.38
    • 9 demandes de fusion ont été exécutées
    • 81 commits ont été poussés
    • 1 nouvelle traduction a été ajoutée : kabyle
    • 16 traductions ont été mises à jour : biélorusse, portugais brésilien, anglais britannique, danois, géorgien, allemand, grec, hongrois, islandais, italien, norvégien nynorsk, slovène, espagnol, suédois, turc, espagnol

    25 personnes ont apporté des modifications ou des correctifs à la base de code de GIMP 2.10.36 (l’ordre est déterminé par le nombre de commits) :

    • 7 développeurs : Alx Sa, Jehan, Luca Bacci, Jacob Boerema, Lukas Oberhuber, lillolollo, Øyvind Kolås
    • 19 traducteurs : Kolbjørn Stuestøl, Sabri Ünal, Bruce Cowan, Yuri Chornoivan, Vasil Pupkin, Anders Jonsson, Rodrigo Lledó, Jürgen Benvenuti, Sveinn í Felli, Andi Chandler, Juliano de Souza Camargo, Ekaterine Papava, Balázs Úr, Martin, Philipp Kiemle, Alan Mortensen, Dimitris Spingos, Marco Ciampa, Yacine Bouklif

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

    • La branche gimp-2-10 de gimp-macos-build (scripts de build macOS) a eu 30 commits depuis la version 2.10.36 par 2 contributeurs : Lukas Oberhuber, Bruno Lopes.
    • La version flatpak est composée de 11 commits par 3 contributeurs : Jehan, Hubert Figuière et Bruno Lopes.
    • Notre site Web principal a eu 42 commits depuis la sortie du 2.99.18 par 4 contributeurs : Jehan, Alx Sa, Andre Klapper et Lukas Oberhuber.
    • Notre site Web du développeur a enregistré 34 commits depuis la version 2.99.18 par 6 contributeurs : Bruno Lopes, Jehan, Alx Sa, bootchk, Alpesh Jamgade et Robin Swift.
    • Notre documentation 2.10 a eu 35 commits depuis la version 2.10.36 par 8 contributeurs : Alan Mortensen, Anders Jonsson, Rodrigo Lledó, Jacob Boerema, Kolbjørn Stuestøl, Marco Ciampa, Andi Chandler et Vittor Paulo Vieira da Costa.

    N’oublions pas de remercier toutes les personnes qui nous aident à trier dans Gitlab, rapportent des bugs 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 composants dans GIMP et son univers, et de la manière dont nous obtenons des statistiques via les 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 processus de publication

    Idriss, contributeur du GSoC 2023, a récemment obtenu un accès « développeur » sur le référentiel source principal, pour le travail formidable qu’il a continué depuis lors.

    Ville Pätsi, contributeur de très longue date (plus de 20 ans !), sur divers sujets (design, thématisation et plus) a obtenu l’accès « reporter » à Gitlab pour aider au tri et à l’organisation directement dans le tracker.

    Autour de GIMP

    Des nouvelles des miroirs

    Depuis nos dernières nouvelles, 3 nouveaux miroirs accueillent GIMP :

    • Clarkson Open Source Institute, États-Unis
    • FCIX, Suisse
    • Tomás Leite de Castro, Portugal

    Cela nous amène à un total de 49 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 tous aient un accès rapide au téléchargement de GIMP.

    Sponsors d’infrastructure et de matériel

    Nous avons amélioré la page sponsor avec 2 sections :

    • "Infrastructure Sponsors" répertorie les sponsors qui aident GIMP au niveau de l’infrastructure :

      • CircleCI et MacStadium rendent possible notre plateforme d’intégration continue macOS.
      • Arm Ltd. sponsorise et administre plusieurs exécuteurs « Aarch64 » sur Windows pour notre version ARM 64 bits pour Windows ; et Microsoft avait offert des frais uniques pour leur Microsoft Store.

    • "Hardware Sponsors" répertorie les sponsors qui ont fait don de matériel aux contributeurs pour les aider dans leur travail de développement :

      • Arm Ltd. a récemment fait don d’un kit de développement Windows 2023 pour prendre en charge notre récent support Aarch64/Windows.
      • Purism a fait don d’un Librem Mini en 2021.

    Télécharger GIMP 2.10.38

    Vous trouverez toutes nos builds 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 ?

    C’est clairement l’une des plus petites versions de la série 2.10, et elle pourrait être notre dernière. Nous verrons, même si nous savons aussi que certaines personnes restent bloquées plus longtemps que d’autres sur des séries plus anciennes (en particulier lors de l’utilisation des distributions Long Term Support (LTS) de systèmes d’exploitation de logiciels libres), si nous pourrions donc faire (si nous pensons que c’est nécessaire), une version 2.10.40 avec des corrections de bogues juste avant ou juste après la sortie de GIMP 3.0.0, en guise de conclusion.

    Dans tous les cas, nous arrêtons désormais le rétroportage des fonctionnalités de la série 2.10. Ces améliorations de la prise en charge des tablettes graphiques pour Windows sont suffisamment importantes pour qu’elles aient dû être intégrées ; mais à partir de maintenant, nous voulons nous concentrer uniquement sur la sortie de GIMP 3.0.0.

    Maintenant, vous vous demandez peut-être quand cela se produira-t-il ? Très bientôt ! Nous sommes sur le dernier sprint vers la release candidate. Cela inclut de nombreuses corrections de bugs, mais également des modifications de l’API en cours. Nous vous tiendrons au courant !

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

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    ↗️

    Sortie de GIMP 2.99.18 (version de développement)

    ✇LinuxFr.org
    Par : Jona Matthieu Jehan C138 orfenor Julien Jorge patrick_g Benoît Sibaud Arkem

    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

      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
      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
      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 pour l'application non-destructive d'effets de calque

      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 - démonstration de GIMP 2.99.18
      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.

      Aligner sur les boîtes englobantes et Aligner à équidistance - démonstration de GIMP 2.99.18
      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
      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 ! 💪🥳

      Commentaires : voir le flux Atom ouvrir dans le navigateur

      ↗️

      LibreOffice 24.2 : nouvelle année, nouvelle numérotation, nouvelle version

      ✇LinuxFr.org
      Par : Ysabeau patrick_g

      Une nouvelle version de la formidablement libre suite bureautique LibreOffice vient de sortir. Non contente de s’offrir une nouvelle numérotation pour la nouvelle année, elle nous offre surtout une accessibilité accrue, une meilleure internationalisation notamment pour les langues qui n’utilisent pas l’alphabet latin et une meilleure compatibilité avec l’Office Open XML (OOXML).

      On trouvera plus bas un bouquet choisi des évolutions de LibreOffice, les notes de version sont là pour l’exhaustivité.

      Logo de LibreOffice

      Sommaire

      Sur la nouvelle numérotation

      La question de ce changement de numérotation de LibreOffice a fait tourbillonner un bon paquet d’électrons sur LinuxFr. Dans un premier lien annonçant la sortie de la 7.6, puis un deuxième annonçant celle de la bêta 24.2 pour tests et enfin dans un journal (avec quelques erreurs) signalant en avant-première quelques fonctionnalités et améliorations.

      Mais un rappel peut s’avérer nécessaire. Donc la numérotation des versions de LibreOffice est passée d’un schéma de type SemVer (en) : numéro majeur de version. numéro mineur. patch, exemple 7.6.4 qui est la dernière à porter ce type de numérotation à un schéma de type CalVer (en). On a donc :

      • année de sortie de la version : 24
      • mois de sortie : 2
      • micro : 0.

      Les mises à jour de cette version, selon le calendrier de sortie porteront ainsi les numéros : 24.2.1, 24.2.2, 24.2.3, etc. jusqu’à la dernière 24.2.7 dont la sortie est prévue fin octobre 2024. La durée de vie d’une version de LibreOffice est de neuf mois.

      Pas de changement pour le reste : deux versions « vivantes » vont continuer à coexister, une seulement maintenue, l’actuelle 7.6.4 et une en pleine évolution, l’actuelle 24.2. Sans oublier les versions de développement et les archives.

      L’accessibilité enfin une priorité

      L’accessibilité n’a pas toujours été une priorité de LibreOffice, il semblerait qu’avec les dernières versions, cela change fort heureusement. Par exemple, les versions antérieures ont ajouté la possibilité de marquer comme décorative une illustration ou un cadre, ce qui signale aux lecteurs d’écran de les ignorer et allège la lecture pour des éléments qui n’apportent pas une information supplémentaire.

      La version 24.2 corrige beaucoup de défauts pour Windows, Mac, et Linux. On se contentera de relever ce qui concerne Linux :

      • les vues arborescentes comme celle de la configuration avancée, menu Outils → Options → LibreOffice → Avancé → Ouvrir la configuration avancée1 sont correctement annoncées, passant, lues correctement par les lecteurs d’écran ;
      • un paramètre système permet de réduire ou désactiver les animations est pris en compte par LibreOffice, permettant de désactiver les petits traits animés qui encadrent des cellules copiées dans Calc ;
      • dans Calc, signalement des étiquettes d’entête de lignes et colonnes en conformité avec la spécification ARIA, elles sont utilisées par le lecteur d’écran Orca pour annoncer les cellules ;
      • les lecteurs d’écran peuvent annoncer correctement le texte des éléments des éditions multilignes dont on trouve un exemple dans le menu Aide → Vérifier les mises à jours… ;
      • les barres d’état des boites de dialogues sont signalées avec le rôle accessible correct ;
      • les cases à cocher dans la boite de dialogue d’orthographe peuvent être activées avec la touche espace ;
      • dans Writer, les paragraphes de style « Bloc de citation » utilisent le modèle d’accessibilité du même nom qui permet aux lecteurs d’écran de les annoncer sous forme de citation entre guillemets ;
      • l’activation et la désactivation des boutons peut se faire à l’aide de l’action d’accessibilité correspondante ;
      • le lecteur d’écran Orca indique si le soulignement est actif ou non.

      Pour compléter, il est bon de rappeler ces deux logiciels qui facilitent l’utilisation de Linux, donc de LibreOffice : le logiciel de commandes vocales NoComprendo qui a fait l’objet de deux dépêches sur ce site. Il permet de lancer verbalement quelques raccourcis clavier (passant de soulager les articulations ou de suppléer à des problèmes de motricité) et le logiciel de dictée vocale Elograf développé pour Mageia.

      L’internationalisation parce qu’il n’y a pas que l’alphabet latin

      La meilleure prise en compte des langues qui utilisent d’autres systèmes d’écriture que l’alphabet latin fait partie également des points forts du développement des dernières versions de LibreOffice. The Document Foundation (TDF), la fondation qui chapeaute le projet a d’ailleurs lancé un appel à recrutement en novembre 2023 pour un poste de développeur. Il était plus particulièrement demandé aux candidats ou candidates des compétences linguistiques et sur Unicode.

      Dans Impress certains des modèles livrés avec LibreOffice avaient des polices incorrectes pour les systèmes d’écriture CJC qui est la qualification d’Unicode pour les écritures chinoises, japonaises et coréennes et CTL. CTL pour « Complex Text Layout » qui concerne le rendu de polices complexes. CTL qualifie un système d’écriture dans lequel la forme et la position d’un graphème dépend de ses relations avec les autres graphèmes, c’est le cas notamment du Devanagari ou de l’alphabet arabe dont le sens du texte peut être bidirectionnel. La version 24.2 a corrigé ce bogue.

      Des modèles avec les paramètres requis pour les textes japonais ont été ajoutés dans la catégorie « localisation »2 ce qui, en outre, améliore l’inter-opérabilité avec MsWord pour les personnes dont l’interface est en japonais.

      Math peut afficher les formules aussi bien dans le sens gauche-droite que droite-gauche (ça c’est nouveau). L’application accepte maintenant également les opérateurs et les symboles arabes et persans (juste retour des choses dans l’histoire de la science mathématique).

      L’interface, adieu les veuves et les orphelines

      Les changements peuvent être visuels ou concerner des intitulés, un choix parmi ce qui a été signalé dans les notes de version.

      La boite de dialogue des propriétés des fichiers, menu Fichier → Propriétés suit enfin le schéma du Dublin Core et ça passe bien dans les fichiers EPUB. Mais il faudra tout de même ajouter l’auteur, si ce n’est pas vous, dans SIGIL après la création de l’EPUB.

      La nouvelle boite de dialogue des propriétés des fichiers avec ses champs tout neufs

      À ce sujet : remplir lesdites propriétés devrait être une habitude, allez donc faire un tour dans le menu Outils → Options → Chargement/enregistrement → Général pour cocher la case « Éditer les propriétés du document avant l’enregistrement ». Elle apparaîtra au premier enregistrement, et pourra toujours être modifiée par la suite en passant par le menu Fichier → Propriétés.

      La récupération automatique des fichiers est cochée par défaut pour une première installation. Si vous ne l’avez pas fait sur votre LibreOffice, on ne saurait que trop vous conseiller de le faire : menu Outils → Options → Chargement/enregistrement → Général. Sur l’illustration, j’ai configuré 5 minutes. Cette récupération ne remplace pas l’enregistrement au fil de l’eau des fichiers. Elle permet seulement de récupérer le document après un arrêt intempestif de LibreOffice.

      Configuration de l’enregistrement automatique et des propriétés.

      Si vous voulez protéger un fichier (onglet sécurité des propriétés), LibreOffice affiche maintenant une barre indiquant la force du mot de passe : plus elle est grande plus il est fort. Et il devient impératif, ce qui n’est pas forcément une bonne chose : on peut vouloir simplement protéger un fichier des modifications intempestives sans plus.

      Apposer un mot de passe à un fichier

      Suggestion : les mots de passe des fichiers de LibreOffice sont quasiment incraquables (pas sans beaucoup de temps), si l’idée n’est que d’éviter des modifications involontaires notamment de formules de feuilles de calcul, pensez à mettre le mot de passe dans les commentaires des propriétés.

      Un autre changement sympathique : sur la barre d’outils l’icône qui représente un oméga, Ω, et qui ouvre un menu déroulant avec les caractères « spéciaux » favoris et les derniers utilisés. Cela affiche maintenant aussi la description du caractère et donc son numéro de code Unicode. Vous saurez ainsi que le numéro Unicode du manchot 🐧 est U+1f427.

      Choisir un caractère spécial

      Et si vous avez bien modifié votre barre d’outils et supprimé ce bouton, vous pouvez le remettre en passant par Outils → Personnaliser, onglet Menu, il s’appelle « symbole ».

      Cette version signe aussi le glas des veuves et des orphelines (format des paragraphes), remplacées par des scissions qu’on autorise (ou pas). D’ici là que la casse y passe aussi…

      Et, puisqu’on parle de Writer, une nouveauté qui en annonce peut-être d’autres : il est possible de styler les commentaires, un style existe pour ça. Les notes de version laissent présager que ce pourrait être l’amorce d’une plus grande variété de styles pour les commentaires.

      Modifier le style de commentaire

      Compatibilité OOXML et autre

      Au rythme où ça va, LibreOffice va finir par être plus compatible avec l’OOXML que la suite MsOffice elle-même 😉. Plus sérieusement outre ce qui a été dit plus haut sur le japonais, j’ai relevé deux innovations majeures pour Writer.

      LibreOffice utilise le style « Première page » pour récupérer l’entête et le pied de page d’un document au format DOCX sans plus créer un nouveau style de page.

      L’algorithme de coupure des lignes justifiées a été modifié, pour l’instant, seulement pour les fichiers au format DOCX, LibreOffice reprend celui implémenté par MsWord 2013. Par la suite il sera utilisé comme justification par défaut dans la prochaine version majeure de LibreOffice. L’algorithme permet de gagner jusqu’à 20 % d’espace.

      Et aussi, dans un autre domaine, Draw importe les fichiers TIFF multipages en plaçant une image par page.

      Pour compléter (peut-être)

      À la source de cette dépêche, j’ai écrit un premier article sur les nouveautés de LibreOffice 24. principalement pour avoir des illustrations. L’article a une structure différente et relève aussi d’autres nouveautés.

      On ne saurait terminer sans remercier les personnes qui font de LibreOffice une suite aussi formidable et agréable à utiliser, sans oublier celles et ceux qui ont ajouté à Mageia deux outils d’accessibilité indispensables.

      1. La traduction des notes de version ne correspond pas forcément à celle de l’interface de LibreOffice, je reprends ici celle de l’interface qui n’est pas encore entièrement traduite en français. ↩

      2. Notes de version (je n’ai pas pu vérifier cela pour la dépêche, et pour cause). ↩

      Commentaires : voir le flux Atom ouvrir dans le navigateur

      ❌