Ou « comment Arch Linux est-elle devenue une distro Linux comme les autres? »
Systemd est un nouveau système d’amorçage pour les systèmes Linux. En fait au démarrage il existe un premier processus qui est l’ancêtre de tous les processus du système. Le PID 1, init. Il est lancé par le noyau et c’est lui qui est chargé de vous amener à bon port vers un système utilisable en lançant les processus utiles. Son importance est donc capitale.
Systemd est une tentative pour améliorer ce qui se faisait avant, c’est-à -dire les SysVinit. Ou les initscripts sous Arch Linux. Je dois dire que j’étais plutôt sceptique au début en particulier concernant les diverses contraintes techniques qui, au final, ne se justifiaient que pour une chose: une grande rapidité de boot, voire faciliter la vie des développeurs upstream. Moi je ne cherche pas vraiment la rapidité, je trouvai ça rapide d’ailleurs avec initscripts, mais plutôt le contrôle pointilleux des daemons lancés. Ce principe très Unix qui veut que par défaut aucun service ne soit lancé, sauf ceux dont on a explicitement souhaité le lancement dans un fichier plain-text. Ce qui est très simple. Plus simple à mon sens que d’utiliser chkconfig ou systemctl.
C’est pour cela que j’aimais tellement Arch Linux: cela m’offrait les avantages de Free BSD (un rc.conf pour mes daemons + un système de paquets fiable et efficace) sans les inconvénients (temps de compilation pour obtenir via les ports des paquets « edge »). Sans compter que l’approche DiY couplée à la philosophie KISS qui n’était pas sans me rappeler Slackware me convenaient plutôt pas mal. Bref, j’avais trouvé chaussure à mon pied, et je coulais depuis des jours années très heureuses.
Alors là voir débarquer ce logiciel monolithique sans ficher de configuration unique mais avec plein de fichiers « units » et des liens symboliques dans tous les sens. Voir les dépendances précoces comme dbus ou encore le rc.conf devenir « DEPRECATED ». Ca m’a mis un coup, pour dire le moins. Notez que je suis pas le seul…
Néanmoins avant de jeter l’anathème, il faut tester. Se faire sa propre opinion. Je viens de faire un premier test d’une « mixed installation » à la Arch et, franchement, la rapidité de boot est à première vue stupéfiante. Sur ma machine de bureau où beaucoup de daemons sont lancés en background, via @, dans mon rc.conf. A la maison, cela ne change quasiment rien quant au temps de boot, par contre, j’ai retrouvé ce pour quoi je n’utilisais plus les distros mainstream habituelles (Debian, Mandriva etc…). Ce qui m’agaçait au plus haut point: des services qui sont démarrés alors que je ne l’ai JAMAIS demandé et que je ne les utiliserai jamais. C’est ainsi qu’au premier boot de ma machine perso sous systemd j’ai vu le daemon « colord » pour la détection des scanners qui s’est lancé. Je n’ai jamais eu de scanners sur cette machine et n’en aurait jamais. Alors il faut faire une systemctl disable comme sous Debian je faisais un chkconfig stop … Il va me falloir _lire_ les logs pour _désactiver_ ce dont je n’ai pas besoin. Plutôt que d’éditer un fichier pour _préciser_ ce que _je veux_. Et ça je n’aime pas, j’aime qu’on me demande ce que je veux directement, plutôt que de devoir perdre du temps à l’obtenir…
Seulement voilà , le journal de systemd se veut totalement innovant comme le reste.
"system.journal" may be a binary file. See it anyway?
Eh oui, les logs sont stockés par défaut au format binaire. Voilà le truc vachement pratique pour faire une p’tit fgrep ni vu ni connu.
Fichier binaire system.journal concordant
C’est là que l’on réalise toute la portée de cette phrase: « Write programs to handle text streams, because that is a universal interface. » Bref, pour cela il faut passer par journalctl:
Oct 21 14:04:59 mnemosyne kernel: ata1.00: ATA-8: SAMSUNG HM160HC, LQ100-10...00
Oct 21 14:05:02 mnemosyne systemd[1]: Found device SAMSUNG_HM160HC.
Oct 21 14:05:02 mnemosyne systemd[1]: Found device SAMSUNG_HM160HC.
Oct 21 14:05:02 mnemosyne systemd[1]: Found device SAMSUNG_HM160HC.
Bon c’est pas si mal…Et il est même possible d’utiliser une bidouille en plus pour retrouver syslog et les logs unix plain-text facilement greppable. Mais bon…
Mon avis est donc mitigé sur systemd, j’avoue que je suis attaché aux vieux principes Unix comme le fait de tout fermer pour n’ouvrir qu’au besoin (au boot comme au firewall!), ou encore le fait d’avoir principalement des fichiers plain-text tout à fait manipulables. Ceci dit, la rapidité de boot est visible, la transition de service/chkconfig est transparente et les units sont simples et bien construites. Systemd est un très bon logiciel, c’est juste que ce n’est pas la façon dont j’aime concevoir mon boot. Mais je pense vraiment que ça vaut le coup de se pencher dessus et de faire des efforts pour apprendre à s’en servir.
C’est son adoption par Arch Linux qui me fait noircir le tableau de systemd. Je suis TRES déçu de voir que cette distro’ a bradé son originalité et ce qui, pour moi, faisait tout son intérêt. Elle s’est banalisée en revenant sur certains de ses principes fondateurs plus orienté vers BSD. Au final, aujourd’hui, je peux tout aussi bien installer une Mandriva, je n’aurai pas de rc.conf (qui a été vidé de sa substance sous Arch) et je n’aurai pas besoin (encore!) d’apprendre les commandes systemd, bien que cela me semble utile puisque toutes les distros l’adoptent…
Il y a de fortes chances que je teste Crux ou encore, carrément, NetBSD. Oui, peut-être est-il carrément temps pour moi de retourner sous BSD…Mieux vaut l’original que la copie non?