Où l’on s’essaie à dresser un panorama des logiciels comptables libres. À l’origine de cette dépêche, une recherche d’un logiciel de paye libre où il a semblé que cela pouvait être utile.

Il s’agit bien de logiciels de comptabilité pour un usage professionnel ou associatif, pas de gestion de finances personnelles qui ont fait l’objet d’une autre dépêche il y a quelque temps. Évidemment, il n’y a aucune prétention à l’exhaustivité, mais plus à donner un panel de logiciels avec quelques idées pour choisir le vôtre, le cas échéant. N’hésitez pas à les essayer quand c’est possible et à croiser les informations pour vous faire votre opinion. Les fiches sont succinctes, mais c’est l’occasion pour vous d’écrire plein de nouvelles dépêches puisque la plupart de ces logiciels n’ont pas eu de présentations récentes sur LinuxFr.org.

Sommaire

• Compta.libremen.com
• Diacamma
• Dolibarr
• Ekyagri
• ENDI
• ERPNext / Dokos
• Frappebook
• Galette
• GnuCash
• Grisbi
• Laurux
• Ledger
• Noalyss (autrefois PHPCompta)
• Odoo
• OpenConcerto
• Paheko (ex Garradin)
• Tryton
• D’autres listes, d’autres articles
• Alors, un logiciel de comptabilité pour quoi faire ?
  • Note sur les ERP ou PGI
• Quel logiciel de comptabilité adopter ?
  • Quel logiciel sélectionner pour sa comptabilité ? Ça dépend.
  • Quel logiciel sélectionner pour sa comptabilité ? Ça dépend. Bis.
  • Attention aux obligations fiscales françaises (utilisées lors d’un contrôle fiscal)
    • Format Fichier des Écritures Comptables (FEC)
    • Les points de vente
• La gestion de la paie

Entrons tout de suite dans le vif du sujet. Voici des courtes présentations avec des points forts et des points faibles qui se dégagent des expériences des rédacteurs et rédactrices. Pour vous aider à faire un choix, cette liste est suivie d’explications plus générales.

Compta.libremen.com

Compta libremen com est un logiciel de compta en partie double, simple et efficace. Il utilise une interface web sans fioritures. Le logiciel est écrit en Perl et s’appuie sur Postgresql et mod_Perl, avec un serveur Apache. Un fork amical fournit une image Docker et quelques améliorations. Libremen propose une offre en ligne.
Commentaires de l’auteur recueillis par courriel : on a un peu d’aide à la saisie, il y a les raccourcis claviers (calcul du numéro de pièce, recopie de la ligne précédente) et aussi les fenêtres déroulantes pour les numéros de compte, plus le fait que le navigateur enregistre les dernières saisies ; je crois avoir documenté toutes les fonctions, la documentation est dite “minimum”, le logiciel est minimaliste par essence, donc la doc aussi :-)

• Points forts : simple et efficace, raccourcis clavier, très léger, sans fioritures, quand on connaît la compta, on peut tout faire sans la souris, ça fonce, j’adore.
• Points faibles : comme les points forts, si vous n’y connaissez rien, ça peut-être intimidant.
• Licence : CeCILL-C
• Site : https://compta.libremen.com/
• Site du fork : https://github.com/picsou83/compta.libremen.com

Diacamma

Le logiciel existe en deux versions, Diacamma Asso pour les associations et Diacamma Syndic pour les copropriétés. Diacamma utilise une interface web, avec un serveur intégré. Un installeur est fourni pour Windows, macOSX et Linux (Debian conseillée). Le CHATONS Sleto propose une offre en ligne.

• Points forts : le facturier qui permet aussi de faire des statistiques des ventes et d’éditer des factures et des reçus, le récapitulatif à gauche de l’écran, une vision comptable par « journaux auxiliaires ».
• Points faibles : les fenêtres modales pour les écritures, la saisie par « journal auxiliaire » qui alourdit le processus, le vocabulaire pas très adapté au secteur.
• Licence : GNU General Public License 3
• Site : https://www.diacamma.org/

Dolibarr

Dolibarr est un puissant ERP pour tous types d’entreprises et d’associations. Il existe des pré-sélections des modules nécessaires à votre activité. Dolibarr utilise une interface web avec des serveurs web et SQL. Un installeur est fourni pour Windows et des paquets pour plusieurs distributions Linux. Beaucoup d’offres d’hébergement existent. Il réunit une forte communauté, surtout francophone. Le développement est très actif.
Notez qu’on parle souvent de Dolibarr sur LinuxFr.org et qu’un journal sur une migration d’ERP a produit des interventions de haut niveau.

• Points forts : il est possible d’ajouter des extensions avec le magasin d’application, le dolistore. Dolibarr est également disponible chez certains hébergeurs à travers Softaculous. Une gestion fine des droits par groupe d’utilisateurs et par utilisateurs. Avec certains droits réservés aux utilisateurs internes c’est-à-dire ceux qui ne sont ni client ni fournisseur.
• Points faibles : l’aspect « usine à gaz » de Dolibarr et sa prise en main qui peut être ardue.
• Licence : GNU GPL V3 et plus
• Site : http://www.dolibarr.org
• Dolibarr sur LinuxFr.org.

Ekyagri

Une solution en ligne de gestion d’exploitation agricole.

• Points forts : la facilité de la saisie des écritures, la gestion des immobilisations, sa conception bien pensée pour le secteur. L’aide est bien faite, elle indique notamment des niveaux de difficultés des tâches. On peut la télécharger au format PDF.
• Points faibles : le site n’est pas très clair sur la récupération des données. On n’a pas de module de recherche sur l’aide en ligne et rien n’est indiqué sur les sauvegardes.
• Licence : AGPL v3
• Site : https://ekylibre.com/ekyagri/

ENDI

• Points forts : la documentation complète
• Points faibles :
• Licence : GNU General Public Licence version 3
• Site : https://endi.coop/fonctionnalites
• Code source : https://framagit.org/endi/endi

ERPNext / Dokos

Un puissant ERP créé en Inde, le fork Dokos est la version française. Écrit en Python et JavaScript au-dessus d’une base Postgresql. Modulaire, il se positionne comme Odoo (voir ci-dessous). Comparons-les : l’interface est plus austère, la renommée moindre entraîne peu de contributeurs tiers à proposer des modules, l’équipe est plus petite, mais tout aussi dynamique, ERPNext évolue vite, il est basé sur le framework FRAPPÉ qui est stable et permet d’extraire les applications de l’ERP, l’ensemble est intégralement libre.

• Points forts : L’interface est uniformisée, ergonomique et soignée
• Points faibles : Tout ce blanc est un peu austère
• Licence : GNU General Public Licence version 3
• Site : https://erpnext.com/ et https://dokos.io/
• Code source : https://github.com/frappe/erpnext

Frappebook

Même équipe qu’ERPNext. C’est juste le morceau comptable d’ERPNext, refait en application de bureau et portable par dessus SQLite. Pour les petites entreprises.

• Points forts : Application portable, on peut l’emmener sur sa clef USB. L’interface est sobre et bien finie.
• Points faibles : au lancement on se retrouve dans une compta anglo-saxonne, il faut paramétrer pour avoir une compta “européenne”.
• Licence : GNU General Public Licence version 3
• Site : https://frappebooks.com/
• Code source : https://github.com/frappe/books

Galette

Sous le nom sympathique et tarabiscoté de Galette (Gestionnaire d’Adhérents en Ligne Extrêmement Tarabiscoté mais Tellement Efficace) se cache un logiciel à destination des associations.

• Points forts : Il est très facile à prendre en main, en comptabilité simple ou double. Il y a une aide en ligne copieuse ainsi qu’une liste d’entraide. Le logiciel propose plusieurs plans comptables (Au moins deux pour les plans comptables français et d’autres pour la plupart des pays européens). On peut aussi ajouter son propre plan comptable. Il offre des fonctionnalités de comptabilité analytique. On peut utiliser sa propre instance, récupérer la base de données ou exporter la comptabilité sous divers formats (CSV, FEC, ODS et XLSX). Il est possible d’importer une comptabilité dans ces formats. Le logiciel est en constante évolution, avec un développeur très réactif. Des modules permettent de gérer aussi les paiements en ligne (puisque c’est aussi un logiciel de gestion de facturations et de clients). Il y a un module PdV (point de vente, caisse).
• Points faibles :
• Licence : GNU General Public Licence version 3
• Site : https://galette.eu/site/fr/
• Code source : https://github.com/galette/galette
• Galette sur linuxFr.org.

GnuCash

GnuCash figure dans la bibliothèque logicielle de la plupart des distributions Linux. C’est un logiciel qui fait aussi bien la comptabilité personnelle que la comptabilité professionnelle. Il propose des fonctionnalités de CRM de base : gestion des adresses des clients et des fournisseurs.

• Points forts : on peut paramétrer des écritures répétitives (paiements mensuels par exemple) et le logiciel vous le rappelle dans des délais fixés par vous à l’ouverture. Sa bibliothèque de rapports (ou états) est riche : bilan, comptes de résultat, portefeuille d’action, facture, quittance, graphiques. Et c’est personnalisable souvent. Les rapprochements bancaires se font avec pré-affectation des comptes grâce à de l’inférence bayésienne.
• Points faibles : Il n’y a pas de plan comptable intégré, il faut l’ajouter. Ni de fonctionnalité d’import d’un plan comptable (ou alors, je n’ai pas trouvé), pas de comptabilité analytique, non plus. Il n’est pas complètement traduit en français et la traduction est un peu étonnante parfois. La prise en main n’est pas évidente.
• Systèmes d’exploitation : Windows, MacOS, GNU/Linux, Unixes
• Interface : graphique
• Licence : GNU General Public License Version 2 ou Version 3
• Site : https://gnucash.org/
• Code source : https://sourceforge.net/projects/gnucash/
• GnuCash sur linuxFr.org (dépêches anciennes).

Grisbi

Un logiciel qui fonctionne tout seul et qui est souvent fourni dans les distributions Linux. Il est surtout utilisable pour les finances personnelles, mais il propose un mode comptabilité libérale et peut être utilisé par des micro-entreprises.

• Points forts : il n’est pas compliqué à installer, on peut importer des fichiers au format CSV (évidemment) mais aussi aux formats QIF, OFX et Gnucash. Pour les rapprochements bancaires, soit dit en passant, choisir le format QIF c’est encore celui qui fait le mieux le travail. Et on peut l’exporter au format QIF ou CSV. Deux formats souvent utilisés par les logiciels de comptabilité. Il propose un pratique simulateur de crédit. Il est assez facile à prendre en main. Quand on fait un rapprochement bancaire, pour une comptabilité personnelle, en bout de course, on a une bonne partie des écritures comptables qui sont saisies.
• Points faibles : pas de comptabilité analytique, pas de compte de résultat ni de bilan et, évidemment, il n’est pas possible d’éditer des factures. L’interface GTK avait quelques bugs sous Windows (il y a plusieurs années, peut-être corrigés depuis), comme des menus déroulants qui empêchent de valider un formulaire tant qu’on a pas cliqué à côté pour les fermer.
• Logiciel inspiré de l’ex MsMoney (qui n’est plus vendu par Microsoft)
• Licence : GNU General Public License Version 2
• Site : https://fr.grisbi.org/
• Code source : https://github.com/grisbi/grisbi
• Grisbi sur LinuxFr.org.

Laurux

Laurux intègre les outils classiques de gestion d’entreprise : comptabilité, facturation, gestion de stock et tous les composants nécessaires aux prises de décisions cohérentes. Développé en Gambas avec Qt à destination des PME, son auteur a aussi voulu créer un logiciel simple d’installation et d’utilisation livré avec toute la documentation utile. L’auteur fournit une attestation individuelle de conformité, obligatoire dans la loi française. Son forum communautaire est accueillant.

• Points forts : Logiciel multiposte performant et fiable. Gestion de la compta, des stocks et achats/devis/factures très simples. Se prend en mains sans trop de complication. Et des développeurs présents, c’est hyper important de souligner le travail de Patrick et Damscot. Pour être plus large, j’ai, par le passé, utilisé Adicom, EBP, l’AS400 (une usine à gaz de fou ce logiciel), et un autre système dans le négoce également. Avec Laurux, je retrouve les avantages de l’AS400 sans avoir les complications d’utilisation.
• Points faibles :
• Licence : GNU General Public Licence version 3
• Site : https://www.laurux.fr/
• Code source :
  • https://github.com/PatrickMag/Laurux (la branche active est v3.69pat)
  • https://github.com/damscot/Laurux
• Laurux sur LinuxFr.org.

Ledger

Ledger est un outil en ligne de commande, qu’on nourrit avec de simples fichiers textes. La puissance de la ligne de commande en fait tout l’intérêt. Développé en C++ il a été porté sur de nombreux autres langages. Ledger ne fait que la comptabilité en partie double. Plusieurs extensions facilitent son utilisation, sans entraver la rapidité de saisie.

• Points forts : Adapté pour les compte-rendus, donc en complément d’un autre logiciel. Il est super puissant car facilement scriptable.
• Points faibles : Par contre, il a très peu de garde-fous. On peut mettre n’importe quelle transaction, il ne dira rien. J’avais dans l’idée de faire des scripts pour automatiser/sécuriser des transactions classiques (dépenses sur une clef, vente d’un lot, etc.) mais j’ai arrêté d’être syndic bénévole avant de le faire (marre de courir après les impayés d’un copropriétaire)
• Licence : BSD
• Site : https://www.ledger-cli.org/
• Code source : https://github.com/ledger/ledger

Noalyss (autrefois PHPCompta)

Au départ centré sur la compta, Noalyss est devenu un logiciel de gestion d’entreprise très complet. Noalyss utilise une interface web avec des serveurs web et Postgresql. Des paquets et une procédure d’installation existent pour Linux, Windows et MacOSX. Activement développé en Belgique, sa communauté importante est conviviale.

• Points forts :
• Points faibles :
• Licence : GNU General Public Licence version 2
• Site : https://www.noalyss.eu/
• Code source : https://wiki.noalyss.eu/doku.php?id=developpement (plusieurs liens à partir de cette page)
• Noalyss sur LinuxFr.org.

Odoo

Odoo est un puissant ERP, modulaire, utilisé par des micro-entreprises comme des multinationales. L’entreprise Odoo connaît une croissance rapide depuis vingt ans, et emploie plus de 2000 personnes dans le monde. Le fondateur d’Odoo poste régulièrement des dépêches annonçant les nouvelles versions d’Odoo sur LinuxFr.org, et un journal sur une migration d’ERP a produit des interventions de haut niveau. Odoo est écrit en Python et utilise Postgresql, son interface est écrite en XML et Javascript. Il est facile à installer.

• Points forts : L’interface est uniformisée, ergonomique et soignée. Le développement est intense depuis plus de vingt ans, appuyé sur l’entreprise Odoo et une large communauté d’intervenants et d’utilisateurs. Des milliers de modules sont disponibles. Documentation facile à lire, complétée par un forum et un grand nombre de sites, vidéos et livres. Énormément d’intégrations à des services d’État ou privés. La communauté s’est regroupée dans l’OCA Odoo Community Association qui maintient les anciennes versions et développe des centaines de modules libres de haute qualité. L’OCA propose aussi un outil de montée de versions.
• Points faibles : L’Apps Store Odoo est de qualité très diverse, certains modules ne sont pas libres, pour installer la comptabilité libre française, il faut s’y retrouver entre plusieurs modules. C’est plus simple pour les pays anglo-saxons.
• Licence : GNU General Public Licence version 3 et propriétaire
• Site : https://www.odoo.com
• Code source : https://github.com/odoo/odoo
• Odoo sur LinuxFr.org.

OpenConcerto

OpenConcerto est un progiciel de gestion intégrée (PGI ou ERP). Sa cible : les entreprises, grandes ou petites. C’est une application java à installer sur chaque poste utilisateur. Guillaume Maillard, son auteur, est un vieil habitué de LinuxFr.org.

• Points forts : la comptabilité est facile à prendre en main. Il y a une version pour macOS (ce qui est à relever compte tenu de la rareté des logiciels comptables pour ce système d’exploitation). S’agissant d’un progiciel de gestion intégrée : il y a aussi des fonctionnalités de gestion commerciale, de suivi des stocks et de préparation des commandes. Plusieurs modules complémentaires existent comme un module d’OCR qui permet, à partir d’une facture numérisée, de la saisir automatiquement dans le logiciel, ou bien un module de paye (seul module payant) : fiches de paye, journaux de paye et déclarations.
• Points faibles : c’est très complet et donc un peu complexe pour une micro-entreprise. Certaines fonctionnalités manquent de clarté et d’exemples d’utilisation. La lecture du guide de démarrage ou du manuel (79€) est conseillée. L’équipe de développement manque de temps pour discuter sur les évolutions mais répond généralement aux questions qu’on lui pose sur le forum. Les données ne sont pas stockées de la même manière entre la version monoposte (un fichier H2) et multiposte (Postgresql). Bien choisir au début, sinon il sera difficile de changer.
• Licence : GNU General Public Licence version 3
• Site : https://www.openconcerto.org
• Code source : https://code.openconcerto.org/listing.php?repname=OpenConcerto
• OpenConcerto sur LinuxFr.org.

Paheko (ex Garradin)

Un logiciel principalement destiné aux associations, qui peut aussi être utilisé par des micro-entreprises. On l’utilise via un navigateur, il y a même une application pour mobile. C’est un logiciel complet de gestion d’association : membres, cotisation, comptabilité, communication.

• Points forts : il est très facile à prendre en main, il y a une aide en ligne copieuse ainsi qu’une liste d’entraide. Le logiciel propose cinq plans comptables (associatif 1999 et 2018, Plan Comptable Général (PCG), Comités Sociaux et Économiques, copropriétés et plan comptable belge). On peut aussi ajouter son propre plan comptable. Il offre des fonctionnalités de comptabilité analytique. On peut utiliser sa propre instance, récupérer la base de données ou exporter la comptabilité sous divers formats (CSV, FEC, ODS et XLSX). Il est possible d’importer une comptabilité dans ces formats. Et, il est en constante évolution avec un développeur très réactif.
• Points faibles : pas de lettrage, pas de gestion directe des écritures périodiques.
• Licence : GNU Alfredo General Public Licence version 3
• Site : https://paheko.cloud
• Code source : https://fossil.kd2.org/paheko/doc/trunk/doc/index.md
• Paheko sur LinuxFr.org, cherchez aussi à Garradin.

Tryton

Tryton est un puissant ERP pour entreprises de toutes tailles. Il est accessible via un client Web, une application native ou bien une ligne de commande en Python. L’application cliente est dispo pour Windows, Mac et Linux, le serveur est empaqueté pour plusieurs distributions Linux. Comme Odoo dont il est un fork, Tryton est basé sur une architecture trois tiers écrite en Python (et un peu de ECMAScript version 6) avec PostgreSQL comme base de données. Les auteurs nous parlent régulièrement de Tryton sur LinuxFr.org.

• Points forts : L’interface est uniformisée, une fois comprise on s’y retrouve quel que soit le module. Un grand choix de modules permet de couvrir tout type d’activité. On peut tout paramétrer, ajouter des champs, en masquer, adapter des modules… Le développement est très actif, la fondation Tryton rassemble beaucoup d’entreprises et de projets, dont GNU Health. Les montées de version sont prises en charge automatiquement.
• Points faibles : L’interface est austère, il y a un très grand nombre d’options. C’est difficile à prendre en main sans être accompagné (mais c’est normal).
• Licence : GNU General Public Licence version 3
• Site : https://www.tryton.org/
• Code source : https://www.tryton.org/download#source
• Tryton sur LinuxFr.org.

D’autres listes, d’autres articles

Bien entendu, il manque plein de logiciels. On s’est limité à ceux qu’on a pu tester. Si ce petit résumé ne vous suffit pas ou n’est plus à jour, voici des sites avec des listes complémentaires (merci d’indiquer en commentaire si vous en connaissez d’autres).

• Les listes maintenues par l’April
  • Pour les entreprises
  • Pour les associations
• Sur Framalibre, le tag comptabilité
• Plain text accounting, comme son nom l’indique
• Après plusieurs mois d’enquêtes, de recueil d’avis et de tests, le journal en ligne Linux Weekly News (ou LWN.net) a fini par adopter GNUCash pour sa comptabilité en mai 2023. L’article est instructif : GNUCash n’est pas le choix parfait, mais pragmatique. Les articles précédents sur leur recherche sont consultables à partir de l’article.
• Sur Wikipédia Comparison of free and open source accounting software

Alors, un logiciel de comptabilité pour quoi faire ?

Avant tout pour faciliter la saisie comptable, fastidieuse quand elle est faite sur du papier (ou des tablettes de cire à l’origine !). Toutes les formes de comptabilité demandent une rigueur, des connaissances, du calcul et du temps — c’est un métier. Le logiciel comptable facilite tout ça.
Mais aussi pour l’automatisation du suivi comptable, c’est-à-dire la production automatique de synthèses lisibles et compréhensibles. Vous pensez peut-être au bilan, mais on a couramment besoin de consulter toutes les dépenses électriques ou toutes les recettes de pub sur LinuxFr.org. On a aussi besoin d’envoyer périodiquement ces synthèses à l’administration, comme la transmission des recettes de TVA.
Enfin, la comptabilité enregistre toutes sortes d’opérations, produites par d’autres logiciels spécialisés (salaires, fabrication, factures, etc.). Intégrer tout cela dans un même outil permet de gagner du temps et d’éviter les fautes de frappe (une facture génère automatiquement les écritures comptables correspondantes). Ça donne des logiciels plus ou moins touffus, certains intégrant toute la gestion d’entreprise, voire tous les outils de travail de l’entreprise — on les nomme ERP (ou PGI en français).

Note sur les ERP ou PGI

Quand SAP et les AS400 régnaient en maître sur ce domaine, les ERP étaient exclusivement de très gros logiciels intégrant non seulement la gestion et la comptabilité, mais aussi la production, la vente, le décisionnel, etc. La forte adaptation aux processus de l’entreprise via un paramétrage puissant, était leur gros atout et justifiait un coût d’installation très élevé. On en est même venu à appeler «SAP» ce type de logiciels.
La langue évoluant sans cesse, de nos jours on appelle ERP tout logiciel intégrant la gestion, le point de vente, la compta et deux trois outils de moindre importance, tandis qu’on les nommait autrefois «logiciels de gestion». Mais la puissance n’est pas la même (le besoin de formation non plus !). On a donc essayé de distinguer dans la liste un puissant ERP paramétrable et adaptable aux processus de l’entreprise, d’un logiciel intégrant les outils de gestion.

Quel logiciel de comptabilité adopter ?

Comme on va le voir, il y a beaucoup de critères, des vérifications, des questions à se poser. Les articles déjà mentionnés de LWN.net montrent assez bien les implications de vos choix. Si vous avez de quoi faire adapter l’outil à vos besoins, choisissez un ERP, puissant ou non.

Quel logiciel sélectionner pour sa comptabilité ? Ça dépend.

Ça dépend de votre statut fiscal, lequel est déterminé par votre chiffre d’affaires sauf dans certains cas précisés par la loi, et ça dépend si vous voyez la comptabilité comme un outil de gestion ou une obligation fiscale. Vous pouvez donc tenir une comptabilité pour des raisons fiscales, pour des raisons légales ou pour des raisons pratiques (ou les trois). Mais pour les mêmes raisons, vous pouvez tenir différentes formes de comptabilité :

1. une comptabilité dite recettes-dépenses, semblable à votre budget familial, très courante dans les associations regroupant des bénévoles et ne vendant rien (un cahier suffit) ;
2. une comptabilité simplifiée, dite de trésorerie, à peu près semblable à la première : vous classez les opérations bancaires, et vous rentrez les factures de vos fournisseurs, elle est classiquement permise par l’administration pour de faibles chiffres d’affaires ;
3. une comptabilité en partie double, fiable et difficile, inventée par les marchands il y a quelques millénaires pour mieux gérer leurs entreprises ;
4. une comptabilité analytique, qui complique les deux précédentes, mais permet de suivre très précisément les dépenses et recettes affectées à une opération, et perfectionne donc la gestion.

Sauf la première, ces comptabilités s’appuient sur une classification conventionnelle des opérations qu’on appelle le [plan comptable]]. Celui-ci varie selon les pays et votre statut juridique. L’utilisation du Plan comptable permet de produire les synthèses mentionnées plus haut — du calcul de la TVA au Bilan d’exercice.
Il y a des plans comptables tout prêts, adaptés à des activités particulières (comme les associations), mais tous dérivent d’un Plan comptable plus général. Votre logiciel doit permettre d’importer ou de créer le Plan comptable souhaité.

En passant, sachez qu’il y a des types de comptabilité, et que leur choix ne permet pas de suivre les mêmes choses. Par exemple, le monde anglo-saxon suit plutôt les finances tandis que le Vieux Continent suit plutôt les biens. Mais là, on rentre dans des débats de professionnels qu’il n’est pas nécessaire d’aborder, d’autant que les frontières (comptables) bougent en ce moment. Vérifiez ce qui est permis auprès de l’administration. Reposons notre question préalable en y répondant du point de vue pratique :

Quel logiciel sélectionner pour sa comptabilité ? Ça dépend. Bis.

Rappelons que beaucoup de logiciels ne se limitent pas à la comptabilité pure, mais intègrent d’autres outils utiles à la gestion (graphiques des recettes, gestion de cotisations, édition de factures, transmission automatisée aux administrations, etc.). Et attention, les écrans de saisie proposés dans les logiciels sont des aides dont un utilisateur expérimenté se passe très bien.

La comptabilité est une obligation, c’est peut-être obscur, fastidieux, vous la faites à reculons, mais la vie est ce qu’elle est, nous sommes dans le système, il faut donc y passer, chaque jour, semaine, année… Alors le meilleur choix, passe aussi par la facilité d’installation, les couleurs, la facilité de prise en main, etc.

Tout dépend donc surtout de vous :

• si vous avez besoin d’aides à la saisie ou non,
• si vous préférez des outils intégrés,
• si un outil intégré dédié à votre activité est un plus pour vous,
• si votre statut fiscal impose une compta en partie double,
• si vous la faites régulièrement pour la gestion de votre structure,
• si vous avez besoin d’exporter les données pour votre expert-comptable (vérifiez les formats possibles avec lui),
• si vous voulez un outil en réseau, voire en ligne sur internet,
• si vous avez déjà utilisé un logiciel et que vous vous y retrouvez.

NB Si qui peut le plus, peut le moins, sachez toutefois rester modestes si vous manquez de temps et de compétences, parce que les outils intégrés demandent une certaine maîtrise. Eh oui ! plus vous intégrez de trucs, plus il faut remplir et paramétrer les trucs avant d’utiliser la partie comptable. Par exemple, sur le cas simple d’une vente, avec un outil intégré il faudra avoir créé les produits, leurs taxes, le client, son bon de commande et les moyens de paiements avant d’attaquer la partie comptable.

Attention aux obligations fiscales françaises (utilisées lors d’un contrôle fiscal)

En application du 3° bis du I de l'article 286 du Code général des impôts (CGI), toute personne assujettie à la taxe sur la valeur ajoutée (TVA) qui effectue des livraisons de biens et des prestations de services à destination de clients particuliers et qui enregistre les règlements reçus en contrepartie au moyen d’un logiciel ou d’un système de caisse, est tenue d’utiliser un logiciel ou un système qui satisfasse aux conditions d’inaltérabilité, de sécurisation, de conservation et d’archivage des données en vue du contrôle de l’administration fiscale.

Tous les détails dans l’article du Bulletin Officiel des Finances Publiques - Impôts (BOFIP) TVA - Régimes d’imposition et obligations déclaratives et comptables - Obligations d’ordre comptable - Obligation d’utilisation de logiciels ou systèmes de caisse sécurisés

Format Fichier des Écritures Comptables (FEC)

Fichier texte tabulaire de 18 champs délimités par barres verticales ou par tabulations, ayant un nommage et un encodage précis ou éventuellement au format XML. Ce format est utilisé par la DGFiP pour pouvoir faire un contrôle automatisable de la comptabilité. Elle fournit un utilitaire de validation de format pour Windows.

Les points de vente

En France, la loi « anti-fraude » de 2016 et l’article 286 du Code des impôts imposent une certification des logiciels de caisse (c’est-à-dire des points de vente qui collectent des espèces) pour éviter les trucages de la comptabilité via modifications du code-source. Ah ben alors fini le libre ? Mais non mon bon, les logiciels libres sont autorisés, on en a beaucoup parlé sur LinuxFr.org. Toutes les structures n’y sont pas tenues, typiquement il faut être assujetti à la TVA.
NB Depuis la loi de finance 2018, article 105, les logiciels de comptabilité n’ont pas à être certifiés.

Si vous avez encore des doutes, consultez la FAQ en français facile écrite par l’équipe de Dolibarr.

La gestion de la paie

On n’en a pas beaucoup parlé alors que cette dépêche a commencé avec la recherche d’un logiciel de paie libre. Disons tout de suite qu’il est préférable de s’appuyer sur des professionnels, en effet la gestion de la paye repose sur trois piliers :

1. la fiche de paie et les déclarations afférentes
2. l’émission et la conservation sécurisée de la fiche de paie
3. la saisie comptable

Certains logiciels ont des modules de gestion des payes (OpenConcerto pour la paie française, Odoo pour plusieurs pays…). L’avantage est de faciliter les écritures comptables. Mais attention, la gestion de la paye impose un suivi juridique et un suivi des taux des cotisations, car le cadre légal varie selon les professions, les salaires et varie aussi dans le temps. Cette actualisation permanente est faite par les professionnels (comptables et experts comptables). Sauf à bien connaître votre profession ou à être dans un cadre relativement simple (par exemple celui des intermittents du spectacle en France), vous gagnerez du temps, de l’argent et de la « légalité » en passant par des professionnels. Les options les plus courantes sont de choisir un cabinet d’expertise comptable ou un service en ligne (nettement moins cher). Lisez ou relisez les commentaires du forum.

S’agissant de la saisie et du traitement comptable de la paie, n’importe quel logiciel de comptabilité peut le faire, les logiciels de paye étant souvent susceptibles de mâcher le travail à ce niveau-là.

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

Sommaire

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

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

Comparaison entre Raspberry Pi 4 et Raspberry Pi 5

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

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

Tableau 1 : comparatif des Raspberry Pi 4 et 5

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

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

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

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

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

Architecture du South Bridge RP1

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

Sources des informations sur le RP1

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

Impacts du RP1

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

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

Évolution des performances

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

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

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

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

Compilation de différents benchmarks entre RPi 4 et 5

performances des I/O

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

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

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

Interfaces USB et Ethernet

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

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

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

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

Interfaces MIPI CSI/DSI

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

Les points discutables/discutés

Le réarrangement de la carte

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

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

Le non réarrangement de la carte

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

Les limites du format carte de crédit

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

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

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

Sommaire

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

Préambule

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

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

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

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

La conquête de l’espace en quelques dates

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

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

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

1958 : création de la NASA.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Elle quitte la NASA en 1971.

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

Katherine Johnson (1918 – 2020), la calculatrice humaine

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Remarques incidentes

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

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

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

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

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

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

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

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

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

Sommaire

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

Une nouvelle version de systemd v256 est sortie

Modifications depuis la version précédente v255

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sur la gestion des services

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

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

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

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

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

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

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

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

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

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

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

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

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

• PAMName= implique désormais SetLoginEnvironment=yes.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Journalisation et autres gestions d'erreurs

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

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

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

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

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

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

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

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

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

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

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

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

À propos de la gestion des périphériques

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

La gestion du réseau avec systemd

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Une intégration fine de SSH

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

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

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

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

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

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

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

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

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

Recommandations aux distributions, afin que les choses fonctionnent correctement :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Outillages en ligne de commande

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• systemd-vmspawn a gagné

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

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

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

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

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

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

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

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

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

  • HyperV enlightenments"
  • et le VM Generation ID

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

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

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

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

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

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

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

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

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

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

Bibliothèques autours du monde systemd

• libsystemd a obtenu un nouvel appel sd_bus_creds_new_from_pidfd()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

systemd-homed systemd-logind, systemd-userdbd

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Divers changements

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

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

• varlinkctl a obtenu le support du transport ssh:.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Documentations

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

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

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

Contributeurs

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

— Edinburgh, 2024-06-11

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

Face aux risques que fait peser GitHub sur le monde des logiciels libres suite à son rachat par Microsoft en 2018, une alternative semble avoir percé. Cette dépêche propose un tour d'horizon des problèmes posés par GitHub et expose comment Codeberg pourrait y répondre.

Sommaire

• • Les points forts de Codeberg
  • La problématique du tout GitHub
  • Des alternatives possibles
  • Pour vous faire venir sur Codeberg
    • Premières impressions
    • Fonctionnalités avancées
  • Projets ayant migré ou ayant un miroir sur Codeberg
  • Comment migrer vers Codeberg ?
  • Conclusion
  • Sources / Liens
    • Controverse GitHub
    • Forges diverses
    • Codeberg

Les points forts de Codeberg

L'association Codeberg e.V. ¹ et son projet Codeberg.org ont été fondés en janvier 2019, suite au rachat par Microsoft de GitHub. En plus d'un statut associatif à but non lucratif, ce qui limite les risques de disparition du jour au lendemain, Codeberg est basé en Europe (à Berlin), ce qui est un plus pour nos données personnelles.

Son logo représente un sommet enneigé sur fond de ciel bleu. En effet, en Allemand, der Berg veut dire la montagne et on pourrait donc traduire Codeberg par une « montagne de code ». Et effectivement, la communauté compte fin avril 2024 plus de 102 000 utilisateurs et plus de 129 000 projets y sont hébergés. L'association qui dirige le projet compte plus de 400 membres. Le financement s'effectue par les dons (déductible des impôts en Allemagne) et/ou contributions aux projets sous-jacents à la forge.

La forge est basée sur Forgejo, logiciel libre sous licence MIT, dont le nom vient de l'Esperanto forĝejo, ce qui est cohérent avec l'attention portée à la langue de l'utilisateur et aux problèmes de traduction (service Weblate). Comme avec GitLab, la licence libre implique qu'un projet peut posséder sa propre instance s'il le souhaite. On notera que Forgejo est un fork de Gitea, lui-même fork de Gogs, et est donc écrit en langage Go, langage sous licence BSD avec un brevet. Le projet Forgejo, évidemment hébergé sur Codeberg, est très actif avec plus de 900 Pull Requests acceptées depuis un an.

La problématique du tout GitHub

GitHub, lancé en 2008, est devenu la plus grosse plateforme d'hébergement de codes sources, utilisée par un grand nombre de projets majeurs du monde du libre (Firefox, Matrix, Yunohost…). Ce qui par effet d'attraction — et de réseau centralisant, contraire au choix de git décentralisé par nature — conduit souvent à faire de Github un choix par défaut, facilitant les interactions avec les autres projets et permettant d'accéder à une large base de contributeurs potentiels. Quand on cite une URL GitHub dans un réseau social, on peut d'ailleurs voir apparaître ce genre de message :

Contribute to Someone/my_project development by creating an account on GitHub.

Cependant, si ce service fourni par Microsoft est actuellement encore gratuit, il est soumis à son bon-vouloir, avec le risque de voir se répéter l'épisode SourceForge (publicités trompeuses, installateurs modifiés, usurpation d'identité de projets partis ailleurs, etc.).

Par ailleurs, derrière une communication favorable à l'open source, le code de la forge GitHub est volontairement fermé. Vous ne pouvez donc pas avoir votre propre instance de GitHub. En outre, cela laisse un flou sur l'exploitation de nos données (au sens large, le code lui-même et nos données personnelles, l'hébergement étant délégué). Avec l'arrivée du projet Copilot, il est cependant certain que nos codes servent à alimenter un outil d'IA, permettant à Microsoft de monétiser des suggestions de code en faisant fi des questions de licence. Une partie d'un code sous licence libre pourrait potentiellement se retrouver injectée dans un projet avec une licence incompatible et de surcroît sans citation de l'auteur.

Des alternatives possibles

On pense tout d'abord à GitLab, logiciel lancé en 2011, qui permet d'avoir sa propre instance serveur pour maîtriser l'ensemble (client et serveur sont libres). Parmi les grands projets libres, on trouve en particulier GNOME et Debian qui utilisent leur propre instance GitLab CE (Community Edition), logiciel sous licence MIT. Mais il faut nuancer : la forge GitLab.com utilise GitLab EE (Enterprise Edition) qui est propriétaire et propose des fonctionnalités supplémentaires. GitLab suit donc un modèle dit open core. GitLab compterait plus de 30 millions d'utilisateurs inscrits et l'entreprise GitLab Inc., lancée en 2014, génère plusieurs centaines de millions de dollars de revenus. On notera enfin qu'en 2018, le site migre de Microsoft Azure à Google Cloud Platform (USA), ce qui a posé des problèmes d'accès dans certains pays.

Autres projets de forges libres plus modestes :

• Codingteam.net (une initiative française, service clôturé en 2019).
• SourceHut http://sr.ht (et https://sourcehut.org/), initié par Drew DeVault.
• Disroot basé sur Forgejo comme Codeberg, mais il ne semble pas avoir attiré de projets d'envergure (le portail, sorte de Framasoft néerlandais, est néanmoins à recommander).
• Chez un Chaton (GitLab ou Gitea pour la plupart).
• L'auto-hébergement : chez-vous, dans un fablab, en datacenter sur serveur dédié…

Pour vous faire venir sur Codeberg

Premières impressions

La page principale est accueillante et annonce que Codeberg.org ne vous piste pas et n'utilise pas de cookies tiers. Les statistiques actuelles sont affichées : nombre de projets, d'utilisateurs et de membres de l'association. Chose agréable, vous avez la possibilité de choisir le français parmi les nombreuses langues proposées pour l'interface. Petite icône qui attire l'attention : l'activité de chaque dépôt peut être suivie grâce à un flux RSS. Sinon, l'organisation générale est très semblable à celle de GitHub ou GitLab et la prise en main de Codeberg se fait donc sans effort.

Fonctionnalités avancées

• Codeberg pages : permet de disposer d'un site web statique pour le projet
• Forgejo actions : pour dérouler automatiquement les actions nécessaires à l'intégration continue (CI/CD)
• Weblate : pour gérer les traductions de votre projet. On peut d'ailleurs y constater que parmi les traductions de Forgejo, le Français est dans le peloton de tête.

Projets ayant migré ou ayant un miroir sur Codeberg

Un certain nombre de projets importants utilisent désormais Codeberg, ce qui est à la fois un gage de confiance et assure une base de contributeurs a minima :

• libreboot : remplacement libre de BIOS/UEFI.
• Conversations : le client majeur XMPP sur Android.
• WideLands : jeu libre basé sur le concept de Settlers II.
• LibreWolf : fork de Firefox axé sur la vie privée.
• F-Droid : magasin d'applications libres pour Android.
• FreeBSD : miroir de https://cgit.freebsd.org/
• FreeCAD : miroir officiel.
• Forgejo : fork communautaire de Gitea suite à la privatisation de celui-ci en 2022.
• Fedilab : client Android pour le Fediverse.
• irssi : client IRC.
• Peppermint OS : une distribution Linux avec bureau minimaliste.
• DivestOS : un fork de LineageOS orienté sur la protection de la vie privée.
• VeggieKarte : un service pour trouver des restaurants végétariens/végétaliens.
• …

Comment migrer vers Codeberg ?

Migrer le code source et l'éventuel Wiki associé ne devrait pas poser de problème particulier. Il suffit de configurer git pour pusher vers la nouvelle forge. Cette page décrit comment migrer l'ensemble de votre projet (incluant les issues, le wiki, les Pull Request, etc.) vers Codeberg : https://docs.codeberg.org/advanced/migrating-repos/

Concernant les Workflows (CI), bien qu'il n'y ait pas de garantie de compatibilité avec les Actions Github, la syntaxe se veut similaire pour faciliter la transition : https://forgejo.org/2023-02-27-forgejo-actions/

Au-delà de l'aspect technique, il reste aussi à faire migrer la communauté d'utilisateurs (la présence fortement suivie sur Mastodon peut être un avantage).

Conclusion

Codeberg est un outil prometteur. Il reste pour la communauté du logiciel libre à le faire grandir. Rappelons les statistiques : 100 millions de développeurs sur GitHub, 30 millions utilisant GitLab et 100 000 pour Codeberg. Le potentiel est grand, l'un des enjeux est de financer l'association pour accompagner la croissance de la communauté, tout en faisant monter en puissance l'infrastructure informatique.

Sources / Liens

Controverse GitHub

• Sonnette d'alarme activée dès 2016 (fr).
• Pourquoi abandonner Github (en) : la campagne Give Up GitHub! a été lancée en juin 2022 suite à la controverse sur GitHub Copilot.
• Please don’t upload my code to GitHub (en) : résumé des problèmes posés en particulier par Copilot (IA GitHub).
• https://en.wikipedia.org/wiki/GitHub_Copilot#Licensing_controversy

Forges diverses

• https://en.wikipedia.org/wiki/GitLab
• Synthèse LinuxFR sur l'autohébergement (2018) (fr).

Codeberg

• Parcourir les projets hébergés sur Codeberg (en)
• Suivre Codeberg sur Mastodon (en) : 12000 abonnés.
• Le blog de Codeberg (en)
• Instances, projets et ressources autour de Forgejo (en)
• https://en.wikipedia.org/wiki/Codeberg