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.

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.

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:

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?

Il faut comprendre que MPD construit une base de données de fichiers musicaux qui peuvent être interrogés via un client en local mais aussi (et ça, je trouve ça super!) à distance. La première chose à faire (après avoir installé le soft et lu le man) est de remplir le fichier de configuration personnel. Il se nomme ~/.mpdconf . Rien de sorcier, voici le mien pour vous en convaincre:

C’est tout. Notez que j’étais tellement pressé d’écouter ma musique que je n’ai même pas pris la peine de prévoir une sortie audio. J’ai copié dans un dossier Mystery_Boy tout les fichiers ogg concernées et ensuite j’ai tapé « mpd » et j’ai regardé. Voici le résultat:

J’ai beaucoup aimé la dernière phrase: j’aime quand on fait le travail pour moi

Bien j’avais un spool de fichiers qui semblait prêt, il ne restait plus qu’à l’écouter! J’ai décidé d’utiliser mpc car ça va bien dans screen avec irssi, je peux même l’appeler sous Vim, donc c’est parfait.
Après un détour par la page de man, j’ai tapé:

Ca avait l’air de fonctionner, je ne savais toujours pas comment écouter mon disque mais…mpc ls m’a confirmé que tout était là. J’ai donc simplement tapé mpc play et ça a commencé….J’étais bien content de pouvoir lire mon cd comme je le voulais.

So I ask google and I fall on that. It was the first link and looks nice. I was too lazy to go further so go on with that stuff
I d/l it and try to compile it on my box which is a amd64 one with FreeBSD 6.0 on it. I read the lightweight readme and install files and start with autogen and configure. At the make moment I got an error in tutor.c:

Sounds bad. Look at the code (ah that’s a nice thing that looking at the code to correct it!). I just notice that one header is missing: locale.h was not include so it prevents from compile right. I add that and re-make.
New complain: exactly the same but in plot.c

I had the header reremake and got feared at the end by:

I suppose that the matter is coming from my box here I should do a ld and check my libs more carefully
I install it and try to handle it. I should give u a pic from my desk. It works but I could not got it in french: see my term on the pics. Oh btw It could be great if this output could be redirect in /var/log for example (it sounds it’s there coz I’m launching it by the shell.
I try « normally » and for example I cant see message error like:
** Message: trans_read_text() --> couldn't open the data file: fr_FR_basic_intro.txt
in my logs however they are important to understand for example why I cant have it in french (I’m not very good in english and making an effort to understand etc…such a pain).
Here it is
If I got some time (and courage!) I will do a port for freebsd. Klavaro sounds in a good way to become a good soft but the code needs to be « polish » by some careful and riguourous hands. So an open-project which seems searching what we could call a « second souffle »