Vue lecture

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

Soirée Open Networking le 26 septembre 2024 avec un cas d'usage à Rennes

Invitation de la 1ʳᵉ session technique sur l’Open Networking animé par Ouest Network : jeudi 26 septembre 2024 18h00 à Rennes (Siège d’Icodia).

  • 18h00 : Ouverture / Accueil des participants, moment d’échange convivial

  • 18h45 : Introduction Antoine Nivard Président Ouest Network

  • 19h00 : Témoignage d’Icodia : l’OpenNetworking en datacenter

  • 19h30 : Présentation de support OpenNetworking par l'intégrateur Pine Networks

  • 20h00 : Témoignage d’Icodia : présentation d’EndiGuard.VAC, solution de VAC algorithmique

  • 20h30 : Présentation de Ruijie Networks / Micas Networks et de leurs solutions réseaux Open Networking (SONiC).

  • 21h00 : Conclusion Antoine Nivard Président Ouest Network

  • 21h05 : Apéritif dînatoire / échanges

  • 22h00 : Clôture

L’objectif de la soirée
Faire découvrir l’approche et la solution OpenNetworking est production et démontrer que cette solution est prête pour toutes les entreprises.

L’Open Networking, c’est quoi : c’est d’abord séparer le matériel du logiciel/firmware. Cela veut dire que le matériel est « banalisé », standardisé.
Pour la partie logiciel/firmware, vous avez le choix entre plusieurs « distributions » selon vos besoins. Vous pouvez aller assez loin via des fonctions de Software Defined Network (SDN).
C’est le Libre pour le réseau !

Ouest Network c’est quoi : c’est une association a but lucratif qui gère le point d’échange de Nantes et qui gère cet événement. Nous regroupons une quinzaine de structures et nous sommes reliés au point d’échange de Rennes/Bretagne : Breizh-IX qui est partenaire de l’opération.

Icodia est un gros hébergeur rennais qui a des compétences particulières et qui utilisent principalement que des solutions « Libres ».

NdM  : les événements à portée locale et/ou sans diffusion en ligne ont vocation à être annoncés par l'Agenda du Libre (AdL), que nous relayons une fois par semaine. Cet événement n’étant pas actuellement déclaré dans l’AdL d’une part, et étant le premier sur un sujet qui n’est pas si fréquemment évoqué sur LinuxFr.org, la modération a choisi de diffuser l’annonce en dépêche. On aimerait bien plus de dépêches portant sur OpenDaylight, Open vSwitch, Sylva, etc.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Recommandations de lecture: RE2020, CSTB, STD, ACV, FDES, INIES, HQE, coup de gueule et FOSS

En passant dernièrement dans l’espace de rédaction de LinuxFr.org, au sujet de FreeCad 1.0 (dépêche en cours de rédaction, mais la RC1 est pour dans quelques jours), un intervenant parle de Gestion du Cycle de Vie d'un Produit.

Dans le domaine du bâtiment / BTP, on est en plein dedans et depuis quelque temps déjà. Effectivement, un logiciel libre comme FreeCad pourrait, à priori, tout à fait trouver sa place dans ce domaine, mais les obstacles sont nombreux et pour certains, très difficiles à surmonter.

Je vous propose un petit tour parmi ces acronymes pour vous en convaincre.

Et en commençant par un petit rappel à la loi si vous ne suivez pas l’actualité :)

    Sommaire

    La RE2020 est en vigueur

    RE2020

    C’est l'arrêté du 4 août 2021 qui a définitivement activé la Réglementation Environnementale 2020.

    Depuis le 1ᵉʳ janvier 2022, tous les nouveaux projets de construction de bâtiment doivent être conformes à la RE2020. Elle reprend dans son volet « Énergie » l’esprit de la Réglementation Thermique RT2012 (et des Réglementations Thermiques précédentes, RT2008, RT2004) en vigueur jusqu’à cette date. Elle y ajoute à présent un volet « bilan Carbone » sur le cycle de vie de l’ouvrage (50 ans minimum).

    Je vous recommande ce guide plutôt complet de 93 pages (à ouvrir et à garder sous le coude pour la suite ;).

    Remarque: Ce document (2.2 page 26/93) contextualise la RE2020 par rapport à la précédente RT2012.
    L’objectif initial des RT était (et est toujours) de réduire les pertes d’énergie entre l’intérieur et l’extérieur. Une bonne idée, tout le monde en convient.
    Les RT2004 et RT2008 étaient plutôt « prescriptives » (« obligation de moyens » dans le jargon du BTP) tandis que la RT2012 impose une « obligation de résultats » suivant des critères qui lui sont propres.

    Sur le site du Ministère du Développement durable, on peut trouver énormément d’infos utiles et ces liens spécifiques à la suite du propos :

    Bien que le mot logiciel ait attisé votre curiosité, parlons de la référence en matière de bâtiment en France: le CSTB.

    Le Centre Scientifique et Technique du Bâtiment (CSTB)

    Présentation

    Le Centre Scientifique et Technique du Bâtiment a été créé en 1947 et fonctionne aujourd’hui sous le statut d’Établissement Public à caractère Industriel et Commercial (EPIC). Son existence est entérinée dans le Code de la Construction et de l’Habitat, (en particulier, ses missions dans l’article 121-1)

    I.
    - réaliser ou faire réaliser des recherches touchant à la technique, l’économie, l’environnement, la performance énergétique, la qualité sanitaire, la sociologie et, plus largement, au développement durable dans la construction et l’habitat ;
    - réaliser, pour le compte des services du ministre chargé de la construction et des autres ministères, des études contribuant à la définition, la mise en œuvre ou l’évaluation des politiques publiques dans le champ de la construction et de l’habitat. En particulier, il participe aux travaux d’une commission, constituée auprès du ministre chargé de la construction par arrêté de ce ministre, et chargée de formuler les avis techniques et les documents techniques d’application sur des procédés, matériaux, éléments, ou équipements utilisés dans la construction, lorsque leur nouveauté ou celle de l’emploi qui en est fait nécessite une expertise collective pour en apprécier l’aptitude à l’emploi.

    Il contribue à la diffusion et à la valorisation des connaissances scientifiques et techniques en matière d’habitation et de construction durable produites dans le cadre de ses recherches et études, par des publications et toutes autres mesures appropriées, dont la normalisation. Il participe également, en liaison avec les services intéressés et sous le contrôle du ministre chargé de la construction, aux activités de coopération technique internationale concernant l’habitation et la construction. Il peut se voir confier toutes missions ayant trait à ces mêmes matières dans le domaine international.

    II. - Parallèlement à ses missions d’intérêt général décrites à l’article L. 121-1, le Centre scientifique et technique du bâtiment apporte son concours aux organismes, groupements, collectivités et personnes physiques ou morales qui le sollicitent pour des missions se rattachant à l’objet de ses activités, notamment par la réalisation de prestations d’études et de conseil, d’essais, et la délivrance de certifications.

    C’est donc un acteur incontournable dans le domaine de la construction tant son champ d’intervention est vaste.

    En particulier, en ce qui nous intéresse, il lui revient la responsabilité d’évaluer la conformité d’une application destinée à faire une étude RE2020.
    Cet audit par le CSTB dure de 3 à 7 mois et se réalise suivant des règles.

    En voici un extrait (page 14/16):

    12 TARIFS
    Tarif pour l’évaluation d’un logiciel thermique : 5 700 € HT, dont 700 € HT de frais administratifs.
    Tarif pour l’évaluation d’un logiciel environnement : 4 000 € HT

    Ce n’est pas donné, mais supposons que je sois riche et venons-en enfin à nos logiciels.

    Calculs « Partie énergie »

    C’est peut-être la partie la plus simple à priori puisqu’il n’y a pas de moteur de calcul à programmer. Il n’y en a qu’un seul et il est fourni par le CSTB en version compilée appliquant les règles dites « Th-BCE 2020 ».

    Cela tombe bien car l’annexe III le pavé décrivant les modalités du calcul fait plus de 1800 pages.

    La figure 1 sur la page 5 du règlement d’évaluation (voir ci-dessus) présente l’architecture globale d’une application. Elle consiste à arranger des données synthétiques sur l’ouvrage, dans un format XML en entrée du moteur et à présenter convenablement les synthèses des résultats en sortie.

    Ainsi, toutes les applications « pro » ne différent que par leur interface utilisateur. FreeCad est tout à fait adapté à agréger les données pour générer le XML attendu en entrée par le moteur de calcul. Le module « Schedule » de l’atelier « BIM » pourrait être une bonne base de départ.

    Mais il n’y a ni accès direct à ce moteur de calcul (distribué en tant que *.dll semble-t-il !), ni a sa documentation.

    Toutefois, le CSTB met gratuitement à disposition l’application (sous Windows donc) COMETH. Il faut ouvrir cette plaquette PDF de 2 pages pour trouver l’adresse mél à qui écrire pour savoir comment accéder à l’application.

    Th-BCE != STD

    À noter que les règles Th-BCE utilisées par le moteur de calcul et présentées dans l’annexe III demandent la saisie d’un nombre assez conséquent d’informations. Pourtant, à quelques modifications près, rien de nouveau sous le soleil, car ce sont sensiblement les mêmes que pour la RT2012.

    Elles permettent de qualifier, après un passage à la moulinette logicielle, la performance de l’enveloppe du bâtiment (grosso modo: isolation+fenêtres/portes+étanchéité à l’air) avec un Bbio, une consommation en énergie avec un Cep, etc qui devront respecter certains seuils (voir 4.1 page 49/93 du guide RE2020) pour avoir le certificat.

    C’est une méthode approchée qui n’a rien d’une Simulation Thermique Dynamique.

    Ainsi, concernant les scénarios d’occupation, pour les règles Th-BCE (voir page 10/93 du guide RE2020)

    …, il s’agit toujours de scénarios conventionnels et de profils moyens, de sorte que les résultats ne peuvent être utilisés comme outil de prédiction des consommations.

    Une STD prendra en compte les « vrais cas d’usage » en fonction de scénarios bien plus précis (comme la variation journalière et saisonnière de la fréquentation, de l’utilisation des équipements, des apports naturels solaires etc).

    Pour cela, le CSTB vend le logiciel TRNSYS v18 en 1ʳᵉ installation à 4 500 € HT.

    Calculs « partie Carbone »

    C’est un grand changement réglementaire qu’introduit la RE2020. L’objectif affiché par le législateur est celui de la lutte contre le réchauffement climatique et pour cela considère que le « bilan carbone sur le cycle de vie » est un bon indicateur.
    En vérité, le seul terme « Carbone » est un peu réducteur. Si le « bilan Carbone » est bien l’unique critère environnemental qu’il faudra respecter selon les termes de la RE2020, l’étude porte en elle-même sur 36 données environnementales (voir page 39/93 du guide RE2020):

    Le calcul réglementaire réalise donc simultanément le calcul de 36 indicateurs
    correspondant aux 36 indicateurs inclus dans les données environnementales

    NDR: tout est en place pour une prise en compte ultérieure par le législateur d’autres critères environnementaux (eutrophisation des sols, impacts sur l’eau…)

    Le calcul est on ne peut plus simple: récupérer les quantités des différents types de produits et les multiplier par les données environnementales correspondantes (à peu de choses près, voir illustration 12 page 56/93 du guide RE2020).

    Avant de quitter brièvement le CSTB et de partir à la recherche de ces « données environnementales », je signale que son logiciel COMENV fait ces calculs d’impact « Carbone ». Il faut ouvrir cette plaquette PDF de 2 pages pour savoir qu’il vous en coûtera 100 € HT/an et pour trouver l'adresse du formulaire de contact (mais il y a une erreur de certificat) !

    L’Analyse du Cycle de Vie (ACV)

    Si vous avez lu Gestion du Cycle de Vie d’un Produit, vous n’apprendrez pas grand-chose de plus en lisant la page Wikipedia pour l'Analyse du Cycle de Vie.

    Il s’agit du même concept: évaluer suivant différents indicateurs l’impact environnemental d’un produit sur l’ensemble de sa durée de vie.

    Les grandes étapes du cycle de vie d’un produit

    Dans notre cas il faut distinguer deux types d’ACV.

    ACV Globale

    C’est ce que fait la RE2020 (voir 4.2 page 53/93 du guide) en ventilant l’impact « carbone » sur les différentes étapes du cycle de vie de l’ouvrage et sur des indicateurs Ic.. hybrides décrivant la part des composants, du chantier, de l’énergie en exploitation, de l’eau en exploitation (page 39/93).

    ACV Unitaire

    Comme on l’a vu, la RE2020 s’appuie sur des quantités (que FreeCad pourrait provisionner) et des données environnementales unitaires pour un produit donné (ou d’un type, d’une gamme). Par exemple 1 m³ de béton, 1 m² de placo BA13, 1 kg de colle à placo, etc. Dans le jargon de l’ACV, c’est une UF, Unité Fonctionnelle.

    Ces données environnementales, dans le cadre d’une étude RE2020 proviennent de plusieurs sources tel que précisé dans cette note explicative page 3/10.

    L’esprit est que si le fabricant n’a pas fourni de données environnementales pour son produit, des valeurs par défaut ou forfaitaires sont prises en compte dans le calcul. Ces valeurs sont volontairement défavorables pour inciter les acteurs de la fourniture de « composants » à publier des FDES.
    (voir également page 43/93 et l’organigramme page 44/93 du guide RE2020)

    Les FDES

    Les Fiches de Déclaration Environnementale et Sanitaire sont donc la base d’une étude RE2020 sur son aspect environnemental.

    Pour plus d’info sur les FDES

    Elles doivent répondre aux exigences de la Norme NF EN 15804+A2 (Contribution des ouvrages de construction au développement durable - Déclarations environnementales sur les produits - Règles régissant les catégories de produits de construction), à retrouver sur la boutique de l’AFNOR.
    Oui, ce n’est pas donné pour à peu près 25 pages franchement pertinentes sur un total de 51.

    La Loi n’impose pas aux fabricants des produits utilisés dans une opération de construction à publier une FDES mais, comme on l’a vu, cherche à les y inciter.

    Pour faire établir une FDES, il faut passer par un organisme agréé comme le CSTB: https://www.cstb.fr/nos-offres/toutes-nos-offres/declaration-environnementale-fdes

    Le ticket d’entrée est à partir de 6 500 € HT d’après cette plaquette PDF.

    Exemple de FDES pour un complexe plaque de plâtre 13 mm + isolant de 140 mm:
    https://www.base-inies.fr/iniesV4/dist/infos-produit/40016

    Les 36 données environnementales sont dans l’onglet « indicateurs » et sont ordonnées de la manière suivante:

    • en catégories: Impacts environnementaux, Consommation des ressources, Déchets, Flux sortants, Stockage du carbone
    • et chaque indicateur est détaillé pour chaque étape de son cycle de vie.

    Le lecteur perspicace aura relevé dans les adresses la chaîne de caractères inies, alors allons-y.

    L’INIES

    La base de données environnementales

    Appelée INIES, elle permet de consulter les FDES. Elle est déclarée en accès libre. https://www.base-inies.fr/ vous renvoie l’erreur 403 de l’Apache « Tomcat » pas content, il faut aller librement sur https://www.base-inies.fr/iniesV4/dist/consultation.html .

    Pas mal de changements depuis mes dernières visites il y a 10 ans au moins.

    • l’interface s’est modernisée (javascript) pour le meilleur. Ça marche très bien.
    • il y a beaucoup plus de produits référencés.
    • il y a maintenant des « configurateurs »
    • mais malgré tout, en connaissant la diversité de l’offre, il reste plein de trous dans la raquette: https://www.inies.fr/la-re2020-booster-de-la-production-des-fdes-et-des-pep/ (fin 2023: 3630 FDES et 961 PEP seulement)
    • et puis comment utiliser tout ça dans le cadre de l’ACV Globale pour pouvoir vérifier la conformité à la RE2020 ?

    Le webservice de l’INIES

    Par un service web bien entendu: https://www.inies.fr/programmes-et-services/le-webservice-des-donnees-numerisees/

    Il faut d’abord demander l’accès au service: https://www.inies.fr/ressource/formulaire-de-demande-dacces-au-webservice/

    Dans ce formulaire, le cas du logiciel libre est envisagé.
    Mais il faudra passer l’examen de la demande par le CSIB (d’après les CGV):

    Le Conseil de surveillance de la base INIES (CSIB) : désigne les membres constitutifs de ce comité qui définissent la politique générale en matière de contenu de la base INIES et approuvent les demandes d’accès au webservice.

    Plus d’informations sur la base INIES, son utilisation (stats et logiciels qui l’utilisent), les configurateurs de FDES, les PEP et l’ICV dans cette présentation synthétique de 35 pages.

    L’organisme INIES

    Organisation INIES

    Source: https://www.inies.fr/inies-et-ses-donnees/qui-sommes-nous/

    l’Alliance HQE-GBC a un rôle central aux côtés de l’AFNOR, du CSTB, de l’ADEME, de la FFB, de la CAPEB…

    HQE

    Logo marque HQE

    Source: https://www.hqegbc.org/qui-sommes-nous-alliance-hqe-gbc/usage-de-la-marque-hqe/

    Obtenir un label HQE est une démarche volontaire de la part du Maître d’Ouvrage (celui qui paye). Cela nécessite une certification délivrée par l’alliance HQE-GBC.

    J’en ai entendu parler (par la presse spécialisée) quand les premières certifications ont eu lieu vers 2005/2006

    https://www.hqegbc.org/qui-sommes-nous-alliance-hqe-gbc/notre-histoire-alliance-hqe-gbc/

    Quand soudain, patatras,

    Le coup de gueule de Rudy Riccioti

    Le bonhomme

    Résidence Argo

    Résidence Argo, Source: https://rudyricciotti.com/

    RR (son acronyme ;) est un architecte plutôt connu, qui aime le béton et a le verbe haut des gens du midi. Un sacré numéro.

    Comme d’autres qui ne sont pas du tout débordés dans leur vie de tous les jours (Ministre, moule de LinuxFr.org, etc), il aime aussi écrire: 14 bouquins pour sa part (!) dont

    La trilogie « HQE »

    Les liens sont vers le site Babelio

    1. HQE Transbordeurs (22/03/2007)
    2. HQE les renards du temple Al Dante (21/11/2009)
    3. HQE - La HQE brille comme ses initiales sur la chevalière au doigt Le Gac Press (25/04/2013) Le Gac Press (25/04/2013)

    Citations de Babelio aussi:

    « La HQE, véritable privilège des pays riches de niquer davantage la nature en paraissant vertueux. »
    R.R., conférence 12.07.27, Palembang

    « Le sigle le plus démagogue jamais inventé protège ses initiales, confirmant là ce désir de pouvoir sur un territoire d’intérêt public… »

    Ce que j’en pense

    C’est un pamphlet pas bien épais. Le numéro 2 est une version revue et légèrement augmentée du 1 (pour répondre à la polémique sans doute ;) et le troisième reprend les deux premiers en y ajoutant un épilogue.
    Comme conseil de lecture je dirais de prendre le trois.

    Le ton est incisif et rentre dedans jusqu’à parfois paraître outrancier. Mais sur le fond, l’essentiel du propos me semblait pertinent à l’époque: HQE, un lobby technico-scientifico-économique a mis la main sur une usine à gaz (qu’il va construire et imposer) qui demande à « numériser » l’acte de construire et à en décomposer le moindre élément constitutif (FDES, ACV).

    J’y ai vu « pff, encore plus d’informatique quoi ». La RT2012 (obligatoire contrairement à une labellisation HQE) étant dans les tuyaux à cette époque-là, il y avait déjà de quoi faire. RR y voit un appauvrissement des savoirs et de la créativité par des règles aux origines douteuses qui produiront des solutions technico-économiques toutes faites pour des résultats médiocres en tous points.

    RR a raison

    Source: https://qualiteconstruction.com/ressource/batiment/decollement-ite-renovation/

    Conseil de lecture: N’hésitez pas à visiter ce site, il regorge d’excellentes fiches techniques.

    Sur ce point, il est vrai que l’on voit pas mal d’immeubles de 10/15 ans d’âge dans un état assez pitoyable. C’est plutôt rageant.

    Ce qui est paradoxal dans le propos de RR, c’est que l’industrie du béton (qui pèse très lourd), son matériau de prédilection, a été en pointe sur ce sujet. Les premières FDES en étaient toutes issues (parpaing, bordure de trottoir, prédalle…) suivie par les plaques de plâtre et les isolants.
    Pour le premier concerné, le bilan carbone est au centre de ses préoccupations au vu des quantités astronomiques mises en œuvre et du mode de production du ciment, très énergivore. Être au plus près des faiseurs de lois était une décision naturelle. Avec ses gros moyens elle a pu s’adapter sans trop de mal à cette nouvelle donne.

    Aujourd’hui de quelques adhérents à HQE (c’est une association, rapport moral et activité 2023 en date de juin 2024) le panel s’est bien diversifié et on y trouve tous les aspects du métier.

    La base INIES s’est bien diversifiée et (cela m’intéresse) j’ai eu la bonne surprise de trouver cette FDES:

    https://www.base-inies.fr/iniesV4/dist/consultation.html?id=28898

    Mur en Adobe (Terre crue + paille + granulats éventuels)

    UF: Assurer la fonction de mur porteur sur 1 m² de paroi, pour une épaisseur comprise entre 14,5 et 35 cm, une conductivité thermique comprise entre 0,4 et 0,6, et une durée de vie de référence (DVR) de 100 ans.

    Cette FDES (que je vous recommande de lire si le(s) sujet(s) vous intéress(ent), elle est dans l’onglet « Documents ») est générique pour toute opération mettant en œuvre cette technique en France. Ce qui est remarquable.
    Elle est à l’initiative de la Confédération Nationale de Construction en Terre Crue.

    Une FDES doit être renouvelée et affinée, ils continuent donc de collecter des données relatives aux chantiers auprès des acteurs de la filière

    Lien vers le questionnaire

    Bravo les gars, avec peu de moyens ils ont fait rentrer une méthode de construction ancestrale et à l’impact carbone très faible dans l’ère de la numérisation à tout-va.

    Sur ces bonnes nouvelles, passons à

    La suite et la fin

    Formats ouverts IFC, BCF, le BIM, les BET, la MOE, et autres acronymes

    Dans une prochaine dépêche sans doute. On y retrouvera FreeCad. Il n’a pas dit son dernier mot.

    Et le logiciel pour faire l’étude et émettre des attestations RE2020 ?

    Aux problèmes d’accès aux ressources et services qui ont été abordés, il faut ajouter que les cahiers des charges sont bien entendu plus touffus que ce qui a été présenté et surtout, que la RE2020 évolue régulièrement. Par exemple ce qui y est intégré au fur et à mesure au nom du titre V (des systèmes: VMC, PAC… 66 à ce jour, chacun avec sa façon d’être pris en charge par la RE2020 pour calculer les différents Ic..)

    https://rt-re-batiment.developpement-durable.gouv.fr/titre-v-r322.html

    Question bonus

    https://mdegd.dimn-cstb.fr/tickets

    Il y a un lien avec le propos ci-dessus, lequel ?

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    Comment l’archéologie entre progressivement dans l’ère du logiciel libre

    L’archéologie est un domaine qui, depuis ses débuts, s’attache au catalogage, à la structuration et l’archivage de données issues de fouilles. Sur le terrain, elle a longtemps reposé sur la création de fiches, la collecte manuelle d’information sur papier, et le dessin à la main, retranscrit lors des phases d’étude sur support numérique. Ce n’est que récemment que certains archéologues ont lancé le mouvement de la fouille « tout numérique ». Je vous propose de raconter ici l’histoire de la numérisation de l’archéologie, qui, comme vous allez le voir, repose en partie sur le logiciel libre.

    Sommaire

    Qu’est-ce qu’un chantier de fouilles ?

    L’archéologie française se divise en deux branches principales : l’archéologie préventive, qui intervient lors de projets de construction, et l’archéologie programmée, menée sur des sites choisis pour répondre à des problématiques de recherche. Supervisées par les Services Régionaux de l’Archéologie du Ministère de la Culture, ces activités sont réalisées par différents organismes : opérateurs publics et privés pour l’archéologie préventive, et associations, CNRS ou universitaires pour l’archéologie programmée. Cette dernière mobilise souvent des bénévoles, notamment des étudiants, leur offrant une formation pratique complémentaire.

    Pour l’archéologue, la fouille est un outil, et non un but en soi. Ce que l’archéologue cherche, c’est de l’information. En substance, il s’agit de comprendre l’histoire d’un site, son évolution, ses habitants à travers les éléments qu’ils ont laissés derrière eux, que ce soit les ruines de leurs habitats, de leurs activités artisanales ou leurs sépultures. Ceci est d’autant plus important que la fouille est un acte destructeur, puisque l’archéologue démantèle son sujet d’étude au fur et à mesure de la fouille.

    Pour être exploitée, l’information archéologique doit être organisée selon des principes bien établis. Le premier concept clé est la couche sédimentaire (Unité Stratigraphique - US), qui témoigne d’une action humaine ou d’un phénomène naturel. L’étude de l’agencement de ces couches révèle la chronologie du site, la succession des évènements qui s’y sont déroulés. Ces couches peuvent être regroupées en faits archéologiques : fossés, caves, sépultures, sont en effet des regroupements de couches qui définissent un élément spécifique. Enfin, les objets trouvés dans ces couches, ou mobiliers, sont catalogués et identifiés par leur couche d’origine, fournissant des indications chronologiques et culturelles cruciales.

    chantier mastraits
    Le chantier de fouilles de la Nécropole des Mastraits, à Noisy-le-Grand (93).

    Les actions menées par l’archéologue tout au long du chantier sont également enregistrées. En effet, l’archéologue procède à des sondages, réalise des tranchées, mais fait aussi de nombreuses photos, ou des dessins de tout ce qu’il découvre au fur et à mesure de l’avancement du chantier. La documentation produite peut être pléthorique, et un catalogage indispensable.

    Cette information descriptive est complétée par une information spatiale, le plan des vestiges mis au jour étant essentiel pour l’analyse et la présentation des résultats. L’étude de ce plan, associée aux informations descriptives et chronologiques, met en évidence les grandes évolutions du site ou des détails spécifiques. Sa réalisation est généralement confiée à un topographe en collaboration avec les archéologues.

    À l’issue de la phase de terrain, une phase d’analyse des données collectées est réalisée. Cette phase dite de post-fouille permet de traiter l’ensemble des informations recueillies, d’en réaliser la description complète, d’effectuer les études nécessaires à la compréhension du site en faisant appel à de nombreux spécialistes : céramologues, anthropologues, archéozoologues, lithiciens, carpologues, anthracologues, spécialistes de la paléométallurgie, etc.

    Cette phase de post-fouille aboutit dans un premier temps à la réalisation d’un rapport d’opération, compte rendu le plus exhaustif possible du site et de son évolution. Ces rapports sont remis au ministère de la Culture qui en juge la qualité. Ils ne sont pas destinés à être largement diffusés, mais sont normalement accessibles à toute personne qui en fait la demande auprès de l’administration concernée. Ils sont une base de travail importante pour l’ensemble de la communauté scientifique.

    Sur la base de ce rapport, la publication d’articles dans des revues spécialisées permet de présenter les résultats de l’opération plus largement, parfois en fonction de certaines thématiques ou problématiques spécifiques.

    Pratique de l’archéologie : exemple dans le préventif

    L’utilisation de très nombreux listings papier est une constante. Ces listings permettent de tenir à jour l’enregistrement de la donnée sous forme de tableaux d’inventaire des couches, des faits, des sondages, des photos, etc. Des fiches d’enregistrement spécifiques sont également utilisées dans de nombreuses spécialités de l’archéologie, telle que l’anthropologie funéraire.

    Sur le terrain, les éléments mis au jour sont encore pour une très grande majorité dessinés à la main, sur papier calque ou millimétré, qu’il s’agisse d’un plan de vestiges ou des nombreux relevés de coupe stratigraphique. Ceci demande bien entendu un temps important, en particulier en cas de vestiges complexes.
    L’utilisation de tachéomètres électroniques, puis du GPS différentiel a permis de se passer des décamètres, ou des systèmes de carroyage, lors de la fouille des sites. Des topographes, spécifiquement formés, ont alors commencé à intervenir sur site pour la réalisation des plans généraux.

    La collection documentaire obtenue à l’issue d’un chantier de fouille est particulièrement précieuse. Il s’agit là des seuls éléments qui permettront de restituer l’histoire du site, en croisant ces données avec le résultat des études réalisées. La crainte de la disparition de ces données, ou de leur utilisation par autrui du fait d’une découverte remarquable, est un sentiment souvent partagé au sein de la communauté archéologique. L’archéologue peut se sentir dépositaire de cette information, voire exprimer un sentiment de possession qui va tout à fait à l’encontre de l’idée de science partagée et ouverte. L’idée que l’ouverture de la donnée est le meilleur moyen de la protéger est loin d’être une évidence.

    fiche de conservation, illustrant le coloriage manuel des parties de squelette retrouvées
    Fiche de conservation, illustrant le coloriage manuel des parties de squelette retrouvées

    Exemple de fiche descriptive d’une couche archéologique
    Exemple, parmi tant d’autres, de fiche descriptive vierge d’une couche archéologique

    Le début de la numérisation

    C’est essentiellement après la phase terrain que les outils numériques ont été apprivoisés par les archéologues.

    En post-fouille, la documentation papier est encore souvent une base documentaire fondamentale pour l’analyse du site. L’irruption de l’informatique au milieu des années 80 a conduit les archéologues à transcrire cette donnée sous forme numérique, afin de faciliter son analyse et sa présentation. Bien que les logiciels aient évolué, le processus est pratiquement le même aujourd’hui, avec une numérisation de la documentation sous de nombreux formats.

    Les listings peuvent être intégrés à des bases de données (le plus souvent propriétaires tel MS Access, FileMaker ou 4D) ou des tableurs. De nombreuses bases ont été développées en interne, localement, par les archéologues eux-mêmes. Uniquement attributaires, elles se sont progressivement mises en réseau et adaptées au support, permettant d’envisager un usage sur le terrain, sans que ceci ne soit largement déployé.

    Base de données
    Exemple d’une base de données au tournant des années 2000

    Toute la documentation dessinée sur le terrain est amenée à être redessinée au propre sur support numérique, dans des logiciels de dessin vectoriel, très souvent Adobe Illustrator, parfois Inkscape.
    Les données en plan, levées par le topographe, sont réalisées sous Autocad et étaient exportés en .dxf ou .dwg avant d’être remis au propre sous Adobe illustrator, ce qui est le cas également des dessins réalisés sur le terrain.
    Le mobilier est confié à des spécialistes qui le décrivent, le dessinent, en dressent l’inventaire, le plus souvent dans des tableurs. Leurs dessins sont là encore scannés et remis au propre numériquement.

    Avec le recul, nous constatons que les outils numériques sont majoritairement utilisés comme des outils de mise au propre de l’information collectée sur le terrain. Bien des tableurs ne sont ainsi que la stricte transcription des tableaux papier utilisés par les archéologues, auquel on ajoutera quelques totaux, moyennes ou médianes. Les dessins réalisés sur papier, sont décalqués dans des logiciels de vectorisation pour plus de lisibilité et les plus-values scientifique sont finalement assez limitées.

    Il en résulte une documentation numérique relativement disparate, avec l’usage de nombreux outils propriétaires, des formats fermés, et une séparation très forte entre l’information spatiale et l’information descriptive (ou attributaire).

    L’usage progressif des bases de données a cependant permis d’agglomérer certaines données et de rassembler et mettre en relation l’information. Des travaux universitaires ont également permis d’alimenter la réflexion sur la structuration des données archéologiques et de former de nombreux archéologues, permettant d’adopter des pratiques plus vertueuses.

    Le mouvement tout numérique

    Jusqu’à présent, passer au tout numérique dans le cadre archéologique semblait relativement utopique. Il a fallu que de nouvelles technologies apparaissent, que des supports portables et simples d’usage se mettent en place, que les réseaux se développent, et que les archéologues s’emparent de ces nouveaux outils.

    Le collectif Ramen (Recherches Archéologiques en Modélisation de l’Enregistrement Numérique) est né des échanges et des expériences de divers archéologues de l’Institut National De Recherches Archéologiques Préventives (Inrap) qui se sont regroupés autour de la réalisation de la fouille programmée de la nécropole médiévale de Noisy-Le-Grand, fouille gérée par l’association Archéologie des Nécropoles et confiée à la direction scientifique de Cyrille Le Forestier (Inrap). Cette fouille programmée a permis de lancer une expérimentation sur la complète dématérialisation de la donnée archéologique en se basant sur la photogrammétrie, le SIG, et une base de données spatiale.

    Principe général

    Si le topographe intervient bien toujours pour la prise de points de référence, le relevé détaillé des vestiges est assuré, pour cette expérimentation, par la mise en œuvre de la photogrammétrie de manière systématique. Cette méthode permet, par la réalisation de multiples photos d’un objet ou d’une scène, de réaliser un modèle 3D précis, et donc exploitable à postériori par l’archéologue en post fouille. La photogrammétrie constitue à Noisy l’unique outil de relevé, remplaçant purement et simplement le dessin sur papier. En effet, à partir de ce nuage de points 3D, il est possible d’extraire de multiples supports en 2D et d’ajouter la géométrie ou des informations supplémentaires dans la base de données: contours de la sépulture, représentation du squelette in situ, profils, mesures, altitudes, etc.

    Relevé photogrammétrique d’une sépulture
    Relevé photogrammétrique d’une sépulture

    L’enregistrement des données est assuré par l’utilisation d’une base de données relationnelles et spatiales dont l’interface est accessible dans QGIS, mais également via une interface web directement sur le terrain, sans passer par des inventaires ou listing papier. L’interface web a été réalisée grâce à SQLPage, serveur web qui utilise un langage à base de SQL pour la réalisation de l’interface graphique, sans avoir à passer par les langages de programmation plus complexes classiquement utilisés pour la création d’applications web, tel PHP.

    Bien entendu, cette démarche se poursuit également en laboratoire lors de l’étape d’analyse du site.

    Logiciels et formats libres

    Mais l’abandon du support papier nécessite de nous poser la question de la pérennité des fichiers et des données qu’ils contiennent.

    En effet, dans un processus de dématérialisation complet, la mémoire du site n’est plus contenue sur des centaines de fiches manuscrites, mais dans des fichiers numériques dont nous ignorons à priori si nous pourrons les conserver sur le long terme. L’impossibilité d’accéder à cette donnée avec d’autres logiciels que ceux originellement utilisés lors de leur création équivaut à leur destruction. Seuls les formats standards peuvent répondre à cette problématique, et ils sont particulièrement utilisés par les logiciels libres. Pour la photogrammétrie, les formats .ply et .obj, qui sont implémentés dans de nombreux logiciels, libres et propriétaires, ont été choisis. Pour la donnée attributaire et spatiale, elle est enregistrée dans des bases de données relationnelles libres (Spatialite et Postgis), et facilement exportable en .sql, qui est un format standardisé et reconnu par de très nombreuses bases de données.

    Malheureusement, le logiciel libre reste peu utilisé dans notre quotidien archéologique, et les logiciels propriétaires sont souvent très bien implantés. Le libre souffre encore aujourd’hui d’a priori et d’une mauvaise image au sein de la communauté archéologique, qui le trouve plus compliqué, moins joli, moins efficace, etc.

    Le libre a cependant fait une incursion majeure avec l’arrivée du Système d’Information Géographique (SIG) libre QGIS, qui a permis d’installer un SIG sur tous les postes des agents de l’institut et de l’envisager comme un outil d’analyse à l’échelle d’un site archéologique. Par un accompagnement et la mise en place d’un plan de formation adéquat, de nombreux archéologues ont été formés à l’usage du logiciel au sein de l’Institut.

    QGIS a véritablement révolutionné nos pratiques en permettant l’interrogation immédiate de la donnée attributaire par la donnée spatiale (quel est ce vestige que je vois sur le plan ?) ou, à l’inverse, de localiser un vestige par sa donnée attributaire (où se trouve la sépulture 525 ?). Il est cependant très fréquent d’avoir encore d’un côté la donnée attributaire dans des tableurs ou des bases de données propriétaires, et la donnée spatiale dans QGIS, l’interrogation des deux reposant sur des jointures.

    Bien entendu, QGIS permet aussi l’analyse des données, la création de plans thématiques ou chronologiques, indispensables supports à nos réflexions. Nous pouvons, à partir de ces éléments, réaliser les très nombreuses figures du rapport d’opération, sans passer par un logiciel de dessin vectoriel, en plan comme en coupe (représentation verticale de la stratigraphie). Il permet de normaliser les figures par l’emploi des styles, et, par l’usage de l’outil Atlas, de réaliser des catalogues complets, pour peu que la donnée soit rigoureusement structurée.

    analyse spatiale
    Exemple d’analyse dans Qgis de répartition des rejets de céramique sur un site gaulois

    Dans le cadre de l’expérimentation sur la nécropole des Mastraits, Si Qgis est bien un des piliers du système, quelques logiciels propriétaires sont encore employés.

    Le logiciel de traitement utilisé pour la photogrammétrie est propriétaire. L’objectif à terme est de pouvoir utiliser un logiciel libre, MicMac, développé par l’IGN, étant un possible candidat. Il manque cependant encore d’une interface pleinement intuitive pour que les archéologues puissent s’approprier l’outil de manière autonome.

    De même, les enthousiasmantes dernières évolutions du projet Inkscape devraient nous inciter à nous tourner davantage vers ce logiciel et à utiliser de manière systématique le .svg. L’usage de Scribus pour la PAO devrait également être sérieusement envisagée.

    Le logiciel libre et ses indéniables avantages prend ainsi doucement place, essentiellement via QGIS, dans la chaîne de production de nos données archéologiques. Nous ne pouvons qu’espérer que cette place grandira. Le chemin paraît encore long, mais la voie libre…

    Badass, spatial et attributaire réunis

    Le développement de la Base Archéologique de Données Attributaires et SpatialeS a eu comme objectif d’intégrer, au sein d’une seule et même base de données, les informations attributaires renseignées par les archéologues et les informations spatiales recueillies par le topographe. Il s’agit même de rassembler, au sein des tables dédiées, les informations attributaires et spatiales, garantissant ainsi l’intégrité de la donnée.
    Son principe s’appuie sur le fonctionnement de la chaine opératoire en archéologie, à savoir l’identification et l’enregistrement par l’archéologue des vestiges mis au jour, auquel succède le relevé tridimentionnel réalisé par le topographe. Ce dernier dispose, dans la base de données, de tables spécifiques dans laquelle il peut verser la géométrie et des données attributaires minimales (numéro, type). Des triggers vont ensuite alimenter les tables renseignées par les archéologues avec la géométrie, selon leur identifiant et leur type.

    La base est ainsi l’unique dépositaire de l’information attributaire et spatiale tout au long de l’opération, du terrain à la post fouille.

    Le format de la base de données est à l’origine SpatiaLite. Mais la masse documentaire produite par la nécropole des Mastraits nous a conduit à la porter sous PostGIS. Nombre d’opérations archéologiques ne nécessitent cependant qu’une petite base SpatiaLite, qui permet en outre à l’archéologue d’avoir la main sur son fichier de données. Seuls quelques gros chantiers peuvent avoir besoin d’une solution PostgreSQL, par ailleurs utilisée pour le CAtalogue de VIsualisation ARchéologique (Caviar) qui a vocation à accueillir les données spatiales et attributaires produites à l’institut.

    Naturellement, Badass a été couplée à un projet QGIS proposant déjà des styles par défaut, mais aussi quelques requêtes ou vues communément utilisées lors d’une étude archéologique. Une extension QGIS a été développée par plusieurs étudiants afin de permettre la génération automatique du projet et de la base de données.

    Pour entrer dans Badass : la Bad’Mobil

    Il restait la question de la portabilité de ce système. QGIS est un logiciel demandant beaucoup de ressource et dont l’interface est inadaptée aux petits écrans, appréciés pour leur portabilité sur le terrain (téléphones et tablettes).

    Choisir d’utiliser une base SpatiaLite ou PostGIS permettait d’envisager dès le départ une interface web, qui pourrait alors être utilisée sur n’importe quel terminal. Il avait d’abord été envisagé de lancer un développement en PHP/HTML/CSS avec un serveur web Apache. Mais ceci nécessitait de disposer d’un serveur web, et de programmer toute une interface. Il restait aussi à répondre à quelques questions d’infrastructure : où l’héberger, quels financements pour cela, et qui pour administrer l’ensemble ?

    C’est ici même, sur LinuxFR, que l’un des membres du collectif a découvert SQLPage. Ce logiciel libre, développée par lovasoa, permet de disposer d’un serveur web très simple, et la réalisation d’une application de type CRUD avec une interface dont le développement ne repose que sur du SQL.

    SQLPage repose sur un fichier exécutable, qui, lancé sur un poste informatique, transforme celui-ci en serveur web. Un fichier de configuration permet de définir notamment l’emplacement de la base de données qui sera interrogée. Pour chaque page web de l’interface, on écrit un fichier .sql pour définir les données à aller chercher ou modifier dans la base, et les composants d’interface qui permettront de l’afficher (tableaux, formulaires, graphiques…). L’accès à cette interface se fait dans un navigateur web. Si le poste est en réseau, l’adresse IP du poste permet d’y accéder à distance, avec une adresse comme http://192.168.1.5:8080 par exemple. L’utilisation d’un VPN nous permet d’utiliser le réseau de téléphonie mobile, ce qui nous dispense de toute mise en place d’un réseau local avec routeur, antennes, etc.

    principe
    Principe de fonctionnement général

    Ainsi, l’installation de l’ensemble est très simple et ne repose que sur une arborescence de fichiers à déployer sur le poste serveur : la base de donnée, et un répertoire contenant le binaire SQLPage et les fichiers constituant les pages web.

    En nous appuyant sur la documentation (et en posant parfois des questions à l’auteur du logiciel), nous avons pu développer seuls une interface très complète répondant bien à nos besoins sur le terrain. Nommée Bad’Mobil, l’interface web permet d’accéder à l’ensemble des données attributaires renseignées par les archéologues et permet désormais, grâce aux évolutions constantes de développement de SQLPage, de visualiser la donnée spatiale. La documentation produite au cours du chantier peut également être consultée si les fichiers (photos, dessins scannés, etc.) sont placés au bon endroit dans l’arborescence. Les pages se composent principalement de formulaires de création ou de modification, ainsi que de tableaux listant les éléments déjà enregistrés. La visualisation de la géométrie permet de se repérer spatialement sur le terrain, en particulier en cas de chantier complexe, et d’interagir avec la donnée attributaire.

    L’interface de BadMobil, avec SQLPage
    L’interface de BadMobil, avec SQLPage

    Cas d’utilisation et bénéfices concrets

    Première expérience aux Mastraits

    Le chantier de fouille de la Nécropole des Mastraits a été le chantier test de ces développements. L’importante quantité de données récoltées, mais également son statut de fouille programmée permet de mettre en place ce genre d’expérimentation avec un impact bien moindre que dans une fouille préventive où les délais sont particulièrement contraints.

    La mise en place de l’interface SQLPage a permis la dématérialisation complète de l’enregistrement attributaire, et se révèle très performante. Il s’agit d’un changement majeur de nos pratiques et va nous permettre gagner un temps extrêmement important lors du traitement des données.

    Ceci permet également de centraliser l’information, de travailler à plusieurs personnes en même temps sans attendre la disponibilité des classeurs d’enregistrement traditionnellement utilisés, et de guider les archéologues au cours du processus d’enregistrement, évitant les oublis et les erreurs. Grâce à une interface simplifiée, la saisie peut se faire de manière très intuitive sans réelle nécessité de formation approfondie.

    L’homogénéité de la donnée saisie est ainsi meilleure, et les possibilités d’interrogation bien plus importantes.

    Perspectives d’avenir

    À l’issue du développement de Badass et Bad’mobil sur la nécropole des Mastraits, il nous a paru possible d’envisager son déploiement dans le cadre de l’archéologie préventive. Si la question de l’infrastructure réseau nécessaire au fonctionnement de cette solution peut se poser (nécessité de disposer d’une alimentation électrique stable sur des chantiers perdus en pleine campagne, disponibilité des tablettes, couverture réseau…), les bénéfices en termes d’homogénéité des données et de facilité de saisie sont très importants. Quelques chantiers d’archéologie préventive ont ainsi pu tester le système, la plupart du temps sur des sites de petite ampleur, en bénéficiant de l’accompagnement des membres du collectif.

    Les développements futurs s’orienteront sans doute vers l’intégration de nouveaux formulaires, ou de nouveaux outils de suivi. Actuellement, Badass permet de recueillir les observations communes à tous les sites archéologiques, ainsi que les observations anthropologiques du fait de son utilisation au sein de la nécropole des Mastraits.
    Nous pourrions ainsi envisager d’intégrer les nombreuses spécialités de l’archéologie, mais il est probable que nous obtenions alors une énorme machine dont la maintenance pourrait s’avérer complexe. Nous restons donc prudents à ce sujet.

    Conclusion

    Petit à petit, l’emploi des outils numériques s’est généralisé dans les métiers de l’archéologie. Après les traitements de texte et tableurs des années 90 (souvent sous mac), les premiers dessins vectoriels numérisés sous Adobe Illustrator, et les bases de données sous Filemaker, Access ou 4D, les outils numériques sont aujourd’hui en mesure d’être utilisés au cours de toute la chaîne d’acquisition de la donnée.

    L’apport des logiciels et des formats libres est majeur pour cette nouvelle étape.

    QGIS a fondamentalement révolutionné la pratique archéologique en offrant au plus grand nombre l’accès au SIG, permettant de relier et de manipuler les données attributaires et spatiales. Il a ouvert la voie à de nouvelles évolutions, et à l’intégration de technologies jusque-là peu utilisées par l’archéologie (notamment l’utilisation de bases de données relationnelles et spatiales au format SQL).
    SQLpage nous a permis d’offrir à l’archéologue une interface complète et simple afin d’accéder à une base de données en réseau. Si son développement nécessite une connaissance certaine du SQL et du fonctionnement d’un site web, son déploiement et sa maintenance sont tout à fait abordables.
    SQLPage répond à un réel besoin sur le terrain. Pour les archéologues, il permet de simplifier leur pratique tout en répondant à la complexité grandissante face à la masse documentaire à traiter, et à l’accroissement de l’exigence qualitative des rendus.

    L’association de QGIS, des bases de données spatiales et relationnelles et d’une interface web parfaitement adaptée au terrain comblent désormais le manque constaté d’un outil efficace et fiable d’enregistrement archéologique à l’échelle de l’opération. À ce titre, Badass associée à Bad‘Mobil comblent totalement les attentes des archéologues qui les ont expérimentés.

    Si les logiciels libres ont, ces dernières années, entamé une timide percée chez de nombreux opérateurs d’archéologie (certains les ont pleinement adoptés), des réticences restent présentes, que ce soit des utilisateurs, mais aussi parfois des DSI des administrations publiques, qui peuvent préférer opter pour un service tout-en-un doté d’un support technique.

    Mais la persistance des usages des logiciels propriétaires n’est pas sans poser de réels problèmes quant à la pérennité des données archéologiques et les archéologues commencent juste à découvrir le problème. Leur attachement à leurs données — si elle va parfois à l’encontre du principe de la science ouverte — devrait cependant les inciter à opter pour des formats dont la pérennité apparaît certaine, garantissant par là même l’accès à ces données dans le futur, quel que soit le logiciel ou le système d’exploitation utilisé, s’ils ne veulent pas que leur travail tombe dans l’oubli…

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    Systemd v256

    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

    L’informatique sans écran

    Lors d’un Noël de ma tendre jeunesse pré-adolescente est arrivé un « ordinateur » dans le foyer. Ce PC (Intel 386) a été installé dans le bureau et a vite dégénéré en console de jeux. Puis les années passant c’est devenu une formidable source d’expérimentation informatique pour un geek en devenir. À cette époque on sensibilisait la jeunesse à ne pas passer trop de temps devant la télévision et la console de jeux, puis devant l’ordinateur et les jeux vidéo violents. Mais on ne parlait pas vraiment de l’écran.

    Aujourd’hui les messages de sensibilisation se résument aux écrans :

    • « pas d’écran avant trois ans »
    • « nos jeunes passent leurs temps sur leurs écrans » (comme si les « vieux » n’y étaient pas non plus)
    • « attention les écrans fabriquent une génération de crétins »
    • « les écrans, les écrans, les écrans…»

    Il est vrai qu’aujourd’hui l’informatique ne se résume presque plus qu’à un écran. De l’ordinateur avec clavier+souris+écran, voire crayon optique, on est passé aux tablettes et ordiphones qui n’ont plus que l’écran (tactile quand même).

    Pour prendre le contre-pied de cette obsession des écrans, je me demandais donc s’il existait encore une informatique « sans écran ». La formidable multiplicité des activités que l’on peut avoir sur un ordinateur pourrait-elle se faire sans écran ? Dans quelle mesure peut-on coder, surfer sur le web, lire/envoyer des mails sans écran ? Cette informatique fantasmée par notre ex-ministre de l’éducation est elle une réalité ?

      Sommaire

      L’informatique, une histoire d’abord sans écran

      Si l’on date la naissance de l’ère de l’informatique avec Ada Lovelace, et qu’on estime l’arrivée des ordinateurs avec écrans à la fin des années 1970, alors on peut aisément dire que l’informatique a été plus longtemps sans écran qu’avec.

      Peinture d’Ada LovelaceMalgré son look cosplay de manga elle n’a pas subi trop d’écrans dans son enfance, elle.

      De même, il est raisonnable de considérer l’ordinateur comme l’outil principal pour faire de l’informatique. Il fut largement sans écran à ses débuts.

      Ken Thompson (assis) et Dennis Ritchie (debout) manipulant un DEC PDP-11
      Pas d’écran pour ces deux geeks qui ont développé UNIX et le langage C (source)

      L’altair8800, sorti en 1975 et sur lequel Microsoft a écrit son BASIC, se programmait avec des rubans perforées, voire avec des commutateurs, et l’affichage se faisait avec quelques diodes (DEL) en face avant.
      Les cartes à trous étant plutôt utilsées avec les gros ordinateurs (aka Big Iron).

      Vue de face de l’Altair8800Difficile de considérer ces deux lignes de diodes rouges comme l’écran de l’Altair8800

      L’écran ≠ la vue

      Pour faire sans écran, on pense instinctivement à utiliser d’autres sens que la vue comme l’ouïe ou le toucher (pour le goût ou l’odorat difficile d’imaginer la chose). Mais l’histoire de l’informatique nous montre que les premières interfaces homme-machine ne fonctionnaient pas avec des écrans, et pourtant utilisaient la vue (lumière, LED, imprimante, position mécanique…).

      Mais qu’appelle-t-on écran ?

      D’après la définition de Wikipédia, « un écran d’ordinateur est un périphérique de sortie vidéo d’ordinateur. Il affiche les images générées par la carte graphique de l’ordinateur. Grâce au taux de rafraîchissement d’écran élevé, il permet de donner l’impression de mouvement. »

      Donc si l’on s’en tient à wikipédia, un écran d’ordinateur c’est :

      • des images générées par une carte graphique d’ordinateur. Exit la télé cathodique avec un tuner analogique (qui devient rare aujourd’hui avec la TNT).
      • avec un taux de rafraîchissement élevé. Exit les liseuses et autres appareils utilisant un affichage type «  papier électronique ».
      • pas d’indication de résolutions.

      On peut sans doute rajouter les écrans (comme les télés) qui ne sont pas raccordés à une carte graphique dans la catégorie écran.

      Cela serait donc la résolution (définition et taille…) et le rafraîchissement (fréquence de balayage) du périphérique de sortie vidéo qui font un écran.

      La matrice 5 × 5 d’un micro:bit ne correspond pas à un critère de résolution suffisant, pas plus que les deux poussoirs ne pourraient prétendre à être un clavier.
      micro:bit Pourtant il affiche bien une « image » de cœur <3 !

      Les afficheurs 7 segments ne peuvent pas être considérés comme des écrans. Ils n’affichent que des chiffres et quelques symboles. Difficile de créer une impression de mouvement avec seulement des segments.
      Afficheur 7 segmentsEn faisant un effort, on arrive à reconstituer quelques lettres.

      En doublant le nombre de segments, on arrive à afficher l’ensemble des lettres de l’alphabet latin
      Afficheur 14 segmentsSans diacritiques, faut pas pousser

      Un « panel » LCD 20×4 et ses caractères de 8 pixels sur 5 forme un écran de 100 pixels sur 32, la résolution est déjà meilleure, même s’il est toujours prévu pour n’afficher que du texte. Néanmoins on se rapproche de l’idée que l’on se fait d’un « écran ».

      Du papier électronique ne peut pas être un écran. La résolution peut être excellente mais le rafraîchissement reste insuffisant.

      Finalement la définition de Wikipédia n’est guère rigoureuse ni efficace, entre l’unique LED du panneau de contrôle et l’écran haute résolution, il y a un continuum de périphériques de sortie utilisant des signaux lumineux pour former des images. Il faut peut-être alors chercher les systèmes informatiques qui, dans leur usage normal, utilisent d’autres périphériques de sortie ou pas de périphériques de sortie du tout.

      L’embarquée, une informatique massivement sans écran

      Bien sûr il faut définir le mot « informatique ». Si l’on se réfère à la définition de Wikipédia :

      L’informatique est un domaine d’activité scientifique, technique, et industriel concernant le traitement automatique de l’information numérique par l’exécution de programmes informatiques hébergés par des dispositifs électriques-électroniques : des systèmes embarqués, des ordinateurs, des robots, des automates, etc.

      Avec cette définition, le moindre dispositif électronique embarqué est de l’informatique. Lancer une machine à laver, programmer son four ou préparer une cafetière pour le lendemain est donc une forme de manipulation informatique… qu’on peut envisager sans écran.

      Cependant dès que vient le besoin de développer un système embarqué ou même de le réparer/déverminer, l’écran revient au galop. On a rapidement besoin d’un écran pour y connecter son environnement de développement et sa sonde de debug. Et même l’oscilloscope ou l’analyseur logique que l’on branche pour « voir » les signaux dispose d’un écran.

      En usage normal donc, certains dispositifs informatiques sont conçus pour ne pas nécessiter d’écran parce qu’ils disposent d’un autre périphérique de sortie. Certains centres commerciaux, certaines gares proposent des distributeurs d’histoires courtes : trois boutons comme périphérique d’entrée et une imprimante thermique comme périphérique de sortie. Appuyez et vous aurez de la lecture pour une, trois ou cinq minutes.

      Distributeur d’histoires courtes en gare de Lyon-PerracheSoyons optimistes : il n’y aura pas plus de cinq minute d’attente !

      Plus courant, une box Internet domestique est aussi un dispositif informatique sans écran.

      Livebox 6- Il est où l’écran ? - Dans ton… navigateur

      Il faut reconnaître que si l’usage courant, la connexion à l’Internet, ne nécessite pas d’écran sur la box, son paramétrage en utilise bien un : celui de l’ordinateur sur lequel tourne votre navigateur préféré.

      Les assistants vocaux sont des ordinateurs sans écran. Les principaux périphériques d’entrée comme de sortie sont audio : commande vocale, réponse également. Radio France fait d’ailleurs la publicité pour son offre pour enfants, une histoire et… Oli, sur cette absence d’écran, jouant, sans trop le dire, sur cette peur parentale des écrans.

      Pourrait-on pousser l’utilisation de ces ordinateurs pour faire du développement et «coder en vocal» ? Possible, il est tout à fait possible de programmer l’ouverture de ses volets, la lecture d’une musique ou le thermostat de sa chaudière avec. Mais ça n’est pas du développement.

      L’éducation numérique mais sans écran

      Il est largement possible d’apprendre l’informatique sans écran, et même sans ordinateur.

      La robotique pédagogique se développe depuis l’apparition de la tortue Logo. Actuellement, pour les plus jeunes dès l’école maternelle, c’est une abeille qui est proposée comme initiation à la programmation.

      Bee-Bot en actionSi, si, je suis bien un ordinateur

      La Bee-Bot se programme à l’aide de sept touches et les périphériques de sortie sont les moteurs de déplacement, un petit haut-parleur et en option un porte-crayon. Avec une interface HommeEnfant-Machine aussi simple, il s’agit plutôt d’une mémorisation de séquences de mouvements que de programmation à proprement parler et pour en utiliser toutes les capacités, un interfaçage avec une application ou un ordinateur plus conventionnel est possible, mais on y retrouve un écran ! De nombreux autres robots pédagogiques, un peu plus complexes et performants, existent mais ceux-ci utilisent un écran classique pour accéder à l’interface de programmation.

      Quitte à supprimer les écrans autant aller au bout de la démarche et supprimer l’ordinateur dans son ensemble. Des pédagogues ont ainsi inventé l’informatique déconnectée. Un papier, un crayon, ni écran ni matériel comme le jeu du robot idiot. Les esprits chagrins pourraient y voir une solution au manque de matériel des établissements scolaires.
      Plus que d’informatique il s’agit en fait d’initiation à l’algorithmie.

      Mais peut-on se passer d’écran pour développer ?

      Les plages braille

      Il existe une catégorie de population qui est contrainte de se passer d’écran pour se servir d’un ordinateur : les aveugles.

      Les personnes aveugles peuvent pourtant se servir d’ordinateur, notamment grâce à un clavier spécifiquement développé pour eux nommé « plage braille ». Grâce à ces plages brailles, les aveugles peuvent lire les caractères en braille en touchant une ligne munie de petites pointes pilotés.

      Le prix de ces appareils est assez prohibitif pour quelqu’un qui voudrait jouer avec sans en avoir réellement besoin (un geek quoi). C’est pourtant une bonne manière de faire de l’informatique sans écran. Pour le codage informatique, on utilise un braille à huit points au lieu des six habituels ce qui permet d’avoir 256 combinaisons, soit autant que la table ASCII. La table braille informatique actuelle a été approuvée à l’unanimité en 2007 par la Commission Évolution du Braille Français, elle porte le numéro TBFR2007.

      Que vaudrait un jeu vidéo développé pour une plage braille ? Et pourrait-on l’appeler jeu vidéo ?

      Avec du papier et un stylo/machine à écrire/carte perforé puis scanner

      On peut également faire beaucoup de choses un papier un crayon/stylo/pinceau puis le scanner pour qu’il soit utilisé dans l’ordinateur. Ça reste généralement qu’une étape du développement les programmes ne sont pas plus réalisés intégralement sur papier avant d’être intégré à l’ordinateur.

      Pour conclure

      Avec des écrits comme « la fabrique du crétin digital » et des propos comme ceux de notre ex-ministre de l’éducation, les écrans sont devenus la bête noire de tous les pédagogos.

      Mais l’important n’est-il pas de savoir ce que l’on fait avec un écran ? Faut-il vraiment s’acharner à s’en passer ?

      Sans doute pas.

      Il serait cependant intéressant d’apprendre à se servir d’outils réservés aux aveugles par exemple. Si nous n’avons plus besoin de la vue pour coder, nous pourrions être un peu plus multi-tâches et coder tout en… regardant la télé !

      Commentaires : voir le flux Atom ouvrir dans le navigateur

      ❌