LinuxFr.org a déjà publié quelques articles à propos de systemd, sans entrer trop dans les détails des améliorations techniques.

On trouve en particulier un entretien avec son auteur, Lennart Poettering, et un journal contestant la qualité et les dépendances du code.

L’arrivée de systemd provoque pas mal de remous, justifiés ou non. On peut citer l’objectif « Linux only » affiché par l’auteur, les multiples dépendances et en particulier celle de D-Bus, la personnalité de l’auteur et la qualité de ses réalisations précédentes, le périmètre de responsabilité de systemd (gdm) et probablement de nombreux autres points.

Cet article a pour objectif de passer en revue les évolutions techniques et les objectifs de systemd. Les autres questions citées ci‐dessus ne sont pas injustifiées (en tout cas, pas toutes), mais sont en dehors du périmètre fixé.

L’article se base essentiellement sur les présentations de Lennart Poettering publiées sur son site en particulier, certains paragraphes sont des traductions un peu condensées de sa présentation initiale.

Merci aux relecteurs : Davy, Spack, npa.

systemd est un gestionnaire du système et de services (aussi appelé « PID 1 », car c’est le premier processus à être lancé) pour Linux, compatible avec SysV et les scripts d’init LSB. systemd a des capacités de parallélisation énergiques. Il utilise les sockets et l’activation par D-Bus pour démarrer les services, permettant le démarrage à la demande des démons. Il surveille et commande les processus avec les groupes de contrôle (cgroups) Linux. Il prend en charge la construction d’instantanés et la restauration de l’état du système. Il maintient les points de montage et d’auto-montage, et implémente une logique de contrôle transactionnelle élaborée fondée sur les dépendances entre services.

systemd ne fait pas partie du projet freedesktop.org, bien qu’hébergé sur le site. Il est codé en langage C et publié sous licence GNU GPL 2.1+. Il a été lancé par Lennart Poettering, auteur de PulseAudio et d'Avahi entre autres, et est maintenant activement développé par plusieurs dizaines de développeurs.

La dernière dépêche concernant systemd a suscité de nombreuses réactions et certaines d'entre elles montraient une méconnaissance de ce logiciel : la dépêche se contentait, pour la majeure partie il est vrai, de traduire les notes de versions.

Je vais donc faire un point sur systemd, histoire d’en finir une bonne fois pour toutes avec les discussions sans fin sur systemd (l’espoir fait vivre).

PulseAudio est un serveur de son multiplate-forme en réseau, publié sous licence LGPL 2.1. Son développement a été commencé par Lennart Poettering, ce développeur est aujourd'hui reconnu pour ses nombreuses contributions à l'écosystème Linux, même si celles-ci ne font pas toujours l'unanimité. Le rôle principal d'un serveur PulseAudio au sein d'un système d'exploitation est d'effectuer le mixage des différents canaux audio en provenance des diverses applications et sources d'entrée, puis leur lecture sur des périphériques audio tels que des cartes sons locales ou distantes.

Merci à solstice, patrick_g, liberforce, Nils Ratusznik, PierreLM, moi1392, tankey, Bruno, Xavier Claude, Strash, Benoît et Enjolras pour avoir participé à la rédaction de cet article.

Lennart Poettering est un développeur Red Hat/Fedora connu pour être remarquablement prolifique. Après Avahi et Pulseaudio c'est maintenant le démon d'init systemd qui l'occupe depuis plusieurs mois et qui a fait une entrée tonitruante dans le monde du libre.

Lennart ne déguise pas sa pensée et il ne craint pas de choquer en dévoilant ses opinions. Il est d'avis que seuls les systèmes basés sur Linux peuvent vraiment concurrencer les OS propriétaires et, en conséquence, ses choix techniques ne tiennent pas compte des autres systèmes libres.
Son franc-parler a parfois provoqué des batailles homériques sur les listes de discussion des différents projets et les gens du GCU-Squad sont à deux doigts de lancer un tueur à gages à ses trousses.

Pour toutes ces raisons, il est sans doute bon de faire le point avec lui et de l'interroger calmement sur ses projets et sur sa vision du libre.
LinuxFr a donc effectué un entretien avec Lennart, dont vous trouverez une traduction en seconde partie de la dépêche.

Encore une fois les anglophones sont incités à lire la version originale de l'entretien qui est postée en commentaire de la dépêche.

Ces dernières semaines les personnes clés des principales distributions se sont réunies pour discuter des problèmes liés aux données d'exécution (runtime data) utilisées lors de la phase de démarrage et surtout de leurs emplacements.

Lors du démarrage d'un système GNU/Linux différents programmes (initscripts, dracut, mdadm, etc) ont besoin de stocker leurs données d'exécution dans l'arborescence et cela avant les éventuels montages annexes (/home, /usr ou /var). Ces données sont aussi utilisées par les programmes et daemons lors du fonctionnement du système.

Actuellement, les distributions utilisent différents subterfuges pour stocker ce type de données dans des dossiers cachés : /dev/.mdadm, /dev/.mount, /dev/.systemd, /dev/.udev, etc. Elles utilisent pour la plupart le répertoire /dev pour stocker les premières données, ce dossier est de type tmpfs et est disponible dès les premiers instants du démarrage.

À la suite des derniers montages (/home, /usr ou /var) les daemons sont lancés, ils utilisent principalement le dossier /var/run pour leurs données et cherchent les données liées au démarrage dans les différents dossiers /dev/.xxx ou autres selon les distributions.

Pour en finir avec cette cacophonie, les principales distributions ont décidé d'ajouter le dossier "run" à la racine. Ce dossier fera partie de l'arborescence initiale des prochaines versions, il contiendra les données contenues auparavant dans les dossiers /dev/.xxx, /var/run, /var/lock, /lib/init/rw, etc.

Cette décision est techniquement simple et simplifie la liaison entre les données liées au démarrage et les programmes, elle a souvent été envisagée mais repoussée pour des raisons politiques, des craintes d'intense flameware et la rupture avec la LSB/FHS.

Les développeurs de dracut, udev et systemd ont déjà mis à jour ces logiciels. Les distributions utiliseront le répertoire /run de façon progressive avec, dans un premier temps, des montages de type bind des anciens répertoires vers /run.

Lennart Poettering (Pulseaudio, avahi, systemd) a rédigé un mail pour faire le point sur cette réunion, annoncer le changement et les phases de mise en place.

Alors, LSB/FHS outragée, LSB/FHS brisée, LSB/FHS martyrisée… crouch, touch, pause, engage !

N. D. M. : Les principales distributions impliquées sont Debian, SuSE, Ubuntu et Fedora.

La sortie de la dernière version de PulseAudio coïncide avec celle de trois nouvelles versions de systemd, c’est donc l’occasion de faire une dépêche spéciale Lennart Poettering !

photo de Harald Hoyer sous CC-BY-SA-3.0

« Le FHS du LSB est bien, mais “ / ” est un sacré bordel, il faut tout de même l’avouer. » Ceux qui auront compris cette phrase seront certainement d’accord. Pour les autres, LSB signifie Linux Standard Base, cela définit tout un ensemble de standards autour de GNU/Linux, dont… le FHS, qui est le Filesystem Hierarchy Standard, qui définit l’emplacement des fichiers.

À la racine, c’est‐à‐dire la base du système de fichiers, notée « / », on range notamment les données et les programmes statiques dans « /usr », bien. Ensuite, on range les binaires dans « /bin » et « /sbin », et les bibliothèques dans « /lib » et « /lib64 ». Oui, mais voilà, on range aussi des binaires dans « /usr/bin » et « /usr/sbin », et des bibliothèques dans « /usr/lib » et « /usr/lib64 ».

La proposition vient de Harald Hoyer et Kay Sievers, deux développeurs Red Hat, et est soutenue par Lennart Poettering. L’héritage de 30 ans d’UNIX est clairement à simplifier. Le but est de :

• fusionner « /bin », « /sbin » et « /usr/sbin » dans « /usr/bin » ;
• déplacer le contenu de « /lib » dans « /usr/lib » ;
• déplacer le contenu de « /lib64 » dans « /usr/lib64 » ;
• créer des liens symboliques pour rester compatible :
  • « /bin » vers « /usr/bin »,
  • « /sbin » vers « /usr/bin »,
  • « /lib » vers « /usr/lib »,
  • « /lib64 » vers « /usr/lib64 ».

Facile à retenir : « sbin », c’est has been ! Hum.

Ceci faciliterait grandement le montage et démontage des systèmes de fichiers, le démarrage du système, les instantanés (snapshots), la virtualisation, etc..