Archlinux et systemd

Publié le : dim. 19 août 2012

Tags : #linux, #humeur

ATTENTION : ARTICLE TOUCHANT UN SUJET HAUTEMENT TROLLIFÈRE

Mon avis personnel sur l'évolution d'Archlinux.

J'insiste LOURDEMENT sur le fait ce que n'est que mon avis personnel.

Toute personne consultant régulièrement la ML d'Archlinux ou DLFS (Die Linux Französische Seite) aura pu constater que la distribution GNU/Linux Archlinux fait l'objet d'une guerre de clochers, encore plus énorme que l'éternel débat « vi contre emacs ».

D'abord, un peu d'histoire (sur lequel, je vais tenter d'être neutre). J'ai vérifié mes sources diverses et je ne pense pas me tromper. Les approximations rencontrées sont dues au fait que je tente de résumer (ou « vulgariser »).

Avant 2003 : Création de GNU/Linux, architecture type unix, lsb, blablabla, écosystème bordélique, chacun implémentant les choses comme il le veut, création de distributions majeures, telles que red hat, debian, gentoo, slackware…
2000 : Sortie de KDE 2. Parmi les nouveautés, il faut noter un système de communication entre applications nommé DCOP. [1]
2003 : Création des spécifications de D-Bus.
2003 : Création d'udev, pour gérer (correctement) les périphériques d'un ordinateur.
2004 : Création de polypaudio [2], un serveur de sons, similaire à ESD (Enlightened Sound Daemon).
2006 : Changement du nom de polypaudio. Ce démon s'appelle désormais "Pulse Audio" [3].
2006 : Intégration des "conteneurs à processus" dans le noyau GNU/Linux, puis renommé par la suite en "CGroups". Proposé au départ par des développeurs travaillant pour Google, ces outils permettent d'isoler l'exécution d'applications.
2008 : Intégration de Pulse Audio dans Ubuntu. Problème : l'intégration est bancale, pour ne pas dire désastreuse, car PA n'est pas encore pleinement utilisable. Il faut noter que la gestion du son sous Linux a toujours été « bordélique », et ce qui marchait plus ou moins bien s'est mis à ne plus fonctionner du tout. Le développeur principal ayant un avis plutôt tranché sur l'univers Linux, cf. entretien de 2011 [4], cela n'aide pas à la compréhension du projet. Certains le qualifient (PA) de « bloatware »[5].
2010 : Création d'une bidouille[6], dénomée "sched_autogroup", se basant sur les cgroups, et permettant d'avoir une machine toujours fonctionnelle, même en cas d'application plantée et consommant toutes les ressources.

Par exemple, compiler un noyau linux sur une machine mono-core avec un make -j 128. Cela lance 128 processus de compilation, donc, 128 concurrents pour prendre le contrôle du processeur pour s'exécuter. Sans cette bidouille, la machine devient inutilisable, par exemple, impossible d'utiliser mozilla firefox. Avec cette bidouille, les ressources sont divisées de manière "équitable", où les processus sont regroupés par "lieu d'utilisation" (console graphique, console texte, pty…). Cependant, certains administrateurs système considéraient cette bidouille comme n'étant pas suffisamment souple (du au groupement), ils commencèrent à bidouiller les cgroups par « démon unix» (comme apache, ou les outils de virtualisation.)

2010 : Création de systemd (system daemon). Cet outil est un énième "remplaçant" au SystemV d'Unix [7].
2011 : sortie de Gnome 3. L'évolution majeure de l'environnement de bureau Gnome tranche radicalement les avis des utilisateurs. Épuré pour certains, inutilisable pour d'autres, car trop de fonctionnalités retirées. Tout comme systemd et PA, il ne laisse pas indifférent. Il suffit de voir les forks qui eurent lieu, notamment Mate ou MGSE, voire carrément le remplacement de Gnome par XFCE [8].
Sans date précise, mais entre 2004 et 2008: Création de ConsoleKit et de PolicyKit (pour répondre à une problématique étant « À définir » [9]), remplacement de dcop par d-bus…
2012 : Intégration de systemd dans la plupart des distributions majeures, remplaçant tous les systèmes de démarrage existant (casse de la compatibilité).
2012 : Udev est désormais intégré dans systemd (ce ne sont plus des projets indépendants, systemd a "absorbé" udev).

Ces projets semblent bien distincts, mais il ne faut pas oublier quelques détails. En effet, une partie de ces projets sont créés ou maintenus, en partie par des développeurs de Red Hat (Red Hat, Fedora), notamment PA, systemd et gnome.

Ok, tout ce blabla est bien beau, mais quel rapport avec le titre : "Archlinux et systemd" ? Et c'est quoi cette histoire de guerre de clochers ?

Archlinux a été créé en 2003, avec pour philosophie : "Keep It Simple and Stupid" (KISS, garder les choses simples et claires).

Les principaux atouts d'Archlinux furent donc :

Patcher au minimum les sources des logiciels (versions dites "vanilla")
Fournir une distribution GNU/Linux optimisée i686 (en 2003, optimisée pour Intel Pentium MMX ou PII, à l'époque où la plupart étaient compilées pour le i486, donc gain de performances pour les machines récentes, au détriment de la compatibilité).
Utiliser un gestionnaire de paquets simple (pacman).
Permettre aux utilisateurs de créer facilement leurs propres paquets logiciels, et de les proposer à la communauté Archlinux (AUR/ABS)
Mise à jour en continu. Pas de version "truc.machin", les logiciels disponibles sont toujours à la dernière version, et non, comme pour la plupart des distributions GNU/Linux, des versions figées jusqu'à la mise à jour "majeure" de la distribution. Un peu comme le dépot "Experimental" de Debian, les risques de casser le système en moins.
Facile à configurer (la plupart des éléments de base se trouvant dans /etc/rc.conf).
Un init « à la BSD »[10], avec des scripts simples et clairs, faciles à écrire.
Une architecture (/etc, /home, /usr…) simple et découlant de la tradition "Unix".
Un support utilisateur simple et rapide (irc, pages de documentation complètes).
Similaire au "rolling release" (mise à jour en continu), l'intégration rapide des nouveautés.

Et voilà, nous y sommes : "intégration rapide des nouveautés".

Cette petite phrase, semblant anodine révèle les raisons de la guerre des clochers énoncée tout au début.

L'intégration rapide des nouveautés, ici, systemd, divise les utilisateurs d'archlinux en deux groupes : Ceux qui sont contents, et ceux qui ne sont pas contents.

Point de vue de ceux qui sont contents :

Démarrage plus rapide.
Organisation des fichiers de configuration "logique", la configuration du réseau doit être dans le répertoire "réseau", l'affichage dans "affichage", la disposition du clavier dans "clavier", etc…
Cela rendra uniforme la manière de démarrer un système Linux, que ça soit maegia/mandriva, Archlinux, Fedora/Red Hat…
Il n'y a plus de scripts shell d'exécutés, les directives sont dans des fichiers décrivant le "service", ainsi que ses dépendances.
Une gestion automatique des "dépendances". Par exemple, ça sert à rien de démarrer le serveur web si le réseau n'est pas actif.
La gestion simple du "respawn". Si un process plante, il faut le relancer aussitôt.
Utilisation "intelligente" des cgroup
Archlinux, du fait de sa mise à jour en continu ne DOIT PAS être installé sur un serveur en production.

Point de vue de ceux qui ne sont pas contents :

Osef du démarrage plus rapide. On ne passe pas son temps à redémarrer son ordi toutes les 10 minutes, et en dualboot, Linux est tout de même plus rapide à démarrer que Windows.
La configuration était simple, puisque les fonctionnalités de base sont présentes en un seul endroit (non, faire en sorte que l'ordinateur joue la « marche slave » (de Tchaikovski) quand un email arrive n'est pas considéré comme étant une fonctionnalité de base). Je caricature à peine avec cet exemple, certains utilisateurs voulaient pouvoir configurer le wifi et autres joyeusetés dans le rc.conf.
Afin de permettre la compatibilité avec systemd, on est en train de détruire le rc.conf, en collant les paramètres un peu partout dans /etc.
On arrive déjà pas à compiler une application pour qu'elle fonctionne sur plusieurs distributions. Mettre un init et une configuration exactement identique à toutes les distributions ne sert qu'à détruire le rôle des distributions. Pourquoi s'emm*** à utiliser Archlinux alors que Fedora fournit exactement la même chose, la même config, et est soutenue par une entreprise majeure du monde Linux.
Les scripts shells sont faciles à écrire.
Les dépendances sont relativement faciles à résoudre, via le paramètres "DAEMONS" dans le rc.conf, puis qu'ils sont exécutés dans l'ordre.
Si un service plante, ce n'est pas sans raison (on est pas sous Windows). Vaut-il mieux garder un serveur apache "vautré" plutôt que de tenter de le relancer en permanence, et d'entrer dans une boucle (démarrage -> crash -> redémarrage -> crash…).
Archlinux, pas sur un serveur ? Pourtant, Gentoo, étant également en "mise à jour en continu" fonctionne très bien depuis de nombreuses années sur des serveurs en production.

Parmi les "pas contents", certains ont des arguments plus discutables, notamment :

Point de vue "Logique" : Doit-on laisser un logiciel à peine mature, s'occupant de 36 000 choses différentes, n'étant pas forcément de son ressort, remplacer un service hautement critique qu'est l'init ? Rappel : tout problème dans le processus init se résume à un "Kernel Panic", donc un plantage total de la machine, sans possibilité de récupération.
Point de vue "Politique" : Doit-on remplacer par la force (via son intégration extrêmement poussée dans les logiciels, notamment Gnome) un système qui fonctionne par un nouveau système n'ayant pas fait ses preuve et n'étant pas considéré comme "mature" ?
Point de vue "Philosophie" : systemd casse totalement la tradition "unix". Non modulaire, monolitique, s'occupant de 36 000 choses différentes et non d'une seule (une seule, et correctement), sachant que son créateur affiche ouvertement qu'il se fout complètement de cette philosophie, et qu'il ne s'encombre pas de la compatibilité *bsd.
Point de vue "Conception" : dépendance à D-Bus notamment. D-Bus n'est pas indispensable sur un serveur. Il ne faut pas oublier que Linux n'est pas utilisé QUE pour faire tourner un bureau Gnome. Il peut être utilisé sur un serveur en production.
Point de vue "Système" : systemd ne supporte pas le fait que la partition /usr soit séparé de la partition /. À quand la même chose pour les partitions /var et /home ?
/!\TROLL Les produits Red-Hat ne sont pas KISS (penser à Network-Manager) *TROLL/!*

De mon point de vue personnel :

Nous sommes à un tournant important de l'histoire d'Archlinux.

Mes déconvenues ont commencé avec le déplacement de /lib (librairies de base , utilisées par les outils de base, quand /usr n'est pas encore monté) dans /usr/lib.

Comme je compile à la main mes noyaux GNU/Linux (obligé de patcher certains pilotes de périphérique, dernièrement, le driver wacom, en plus du pilote synaptics, pour les faire fonctionner sur ma machine), la mise à jour de la libc, déplaçant /lib dans /usr/lib a échoué, et au redémarrage, je me suis retrouvé avec un système linux complètement planté, inutilisable (puisque cherchant ses modules dans /lib). Ça m'a fait revenir à l'utilisation de Windows 7, présent sur la même machine, en dualboot, pendant deux semaines. Cependant, c'est un peu de ma faute aussi, vu que je suis en archlinux- testing, et pourtant, j'ai lu la note sur le retrait de /lib.

Le fait de passer systemd « en force », sous prétexte que « c'est mieux », désolé, mais ça, je n'accepte pas. Pourquoi aucun autre init déjà existant n'a été implémenté par toutes les distributions en remplacement d'InitV, c'est peut être parce que chaque distribution a une orientation particulière. Plus orienté "Bureau", plus "Serveur", plus "utilisateur Gourou"…

La destruction progressive de ce que je considérais comme étant un point essentiel : la configuration centralisée de la base dans /etc/rc.conf, afin d'être compatible systemd, et surtout, compatible avec des outils de configuration graphique (mais WTF ?)

Casser la philosophie Unix, ayant plus de 30 ans d'héritage, ça se discute. Je suis attaché à cette tradition (un outil = une tâche). Je ne vais pas me mettre à utiliser un couteau suisse à 36 fonctions (tournevis, lampe de poche, couverts) pour remplacer mes tournevis (qui ne servent qu'à un seul type de vis), ni l'utiliser comme marteau, sachant que ce "couteau" ne fera pas correctement usage de marteau :D

Philosophie… Tradition… le mot « Religion » est proche. D'où l'utilisation du terme « guerre de clochers » en début d'article. Je pense que cela peut expliquer pourquoi cette guéguerre est si virulente. À croire qu'il n'y a que deux possibilités : accepter systemd ou refuser systemd. Je pencherais plus pour une troisième voie : systemd est là, ok, des utilisateurs veulent l'utiliser ; comme des~~moutons~~Apple Addict attendent le dernier iPhone super trop à la mode et la tablette iPad qui est trop une tuerie. Faire avec, soit, mais faire en sorte que son impact soit réduit au minimum. En effet, rien ne garanti que systemd ne sera qu'un effet de mode, et que, comme toute mode, cela ne s'essouffle au bout de quelque temps, ou pire, qu'il se révèlera désastreux sur le long terme.

Je ne parlerai pas du créateur de systemd. Je n'ai rien contre lui, il participe au développement de l'écosystème Linux. Son approche peut être considérée comme étant "extrême", tout comme les fortes personnalités du monde libre (sur d'autres points de vue, notamment au niveau licences, au niveau ouverture du matériel…). Le fait que systemd soit développé par x, y ou z, à vrai dire, je m'en moque complètement. Si un logiciel est bien conçu, je l'utilise. Si j'estime que le logiciel ne correspond pas à mes attentes, je ne l'utilise pas. POINT ! Par exemple, pulse-audio ne me convient pas, je ne l'utilise pas. POINT !

Nous voilà donc à mon dernier point de vue : Si cela correspond à mes attentes, j'utilise. Sinon, j'utilise autre chose. En 12 ans, j'ai utilisé plusieurs distributions. Notamment Mandrake 7.2, puis Mandrake 8.0, 8.1, 8.2. Puis j'ai testé diverses distributions, avant de me fixer sur Debian (Woody je crois). Puis, utilisation en parallèle (sur des ordinateurs différents) de Gentoo et d'Ubuntu (Dapper Drake). Retour d'Ubuntu vers Debian, après le passage rapide à fedora, et un peu plus long à Suse, puis passage de Gentoo à Archlinux.

Ce qui m'a plu dans Archlinux, ce sont les raisons énumérées en haut. Cela correspondant pas mal à mes attentes d'une distribution Linux « moderne ».

Cependant, les orientations prises ces derniers mois me conviennent de moins en moins. J'ai commencé par bloquer les initscript, bloquer netcfg. La gestion du noyau Linux étant bloquée dès le début, grâce à un paquet créé de toute pièce, faisant croire à pacman que j'utilise la version 3.99 du noyau :D, afin de ne pas être embêté. La fusion de systemd et d'udev (composant critique à mes yeux) ne me plait pas du tout, car rien n'empêche une future évolution d'udev pour n'être compatible qu'avec systemd. Je suis peut être paranoïaque sur ce point là, mais ce n'est pas impossible que ça arrive dans un futur plus ou moins proche.

À présent, je me demande que faire :

Gérer moi-même les initscript ?
Passer à systemd et "à-dieu-vat" ?
Changer de distrib (genre, slackware) ?

Pour le moment, le système reste "utilisable", avec les blocages effectués, mais je pense sérieusement migrer vers Slackware (ou une de ses dérivées, comme Salix). J'ai déjà installé Salix sur une autre partition, histoire de me mettre dans le bain, et de voir une nouvelle approche (autre que celles que je connais déjà, comme gentoo, arch, debian ou suse).

« Le chemin est long, mais la voie est libre. »

1 : À noter un "équivalent" sous Gnome : Bonobo, basé sur CORBA.

2 : http://www.freedesktop.org/wiki/Software/PulseAudio/OldNews tout en bas de la page.

3 : Même page que pour [1].

4 : Se référer à l'entretien pour LinuxFr. http://linuxfr.org/news/un-entretien-avec-lennart-poettering.

5 : « Les termes boufficiel, inflagiciel et obésiciel tentent de traduire le terme anglais bloatware désignant tantôt un logiciel utilisant une quantité excessive de ressources système, tantôt un logiciel accumulant une quantité importante de fonctionnalités disparates. » Source : http://fr.wikipedia.org/wiki/Bloatware

6 : Je devrais parler de "hack", mais dans l'esprit des gens, « hack = piratage », et « hackeur = pirate informatique ne souhaitant que destruction et récupération des numéro de carte de crédit ». Tout comme la définition de « geek », qui définissait au départ un passionné (de LEGO, de littérature, de cinéma), puis qui a été assimilé à « passionné d'informatique ». Désormais, « geek » signifie soit « j'ai un compte facebook et j'utilise twitter », soit « j'ai passé 12 heures à farmer sur WoW, je suis trop un geek ! ».

7 : Avant lui, il y a eu : SystemV, Upstart, initng, launchd… consulter la page (en anglais) http://en.wikipedia.org/wiki/Init#Replacements_for_init

8 : Cf. http://www.phoronix.com/scan.php?page=news_item&px=MTE1NTk

9 : Oui, : « À définir ». En tout cas, c'est ce qu'indique la page de desciption du projet sur freedesktop. http://www.freedesktop.org/software/ConsoleKit/doc/ConsoleKit.html#id312242

10 : Plus d'informations (en anglais) sur http://en.wikipedia.org/wiki/Init#BSD-style" et https://wiki.archlinux.org/index.php/Arch_Boot_Process, en espérant que cette page ne soit pas supprimée rapidement, suite au passage à systemd.