Aujourd’hui, je vous parle des contributions de quelqu’un qui a fait parler de lui, depuis que plusieurs distributions, dont Arch Linux, sont passées à systemd.
Il y a quelques années, je me contentais de le voir comme un auteur de middleware utilisé par des bloatware tels que GNOME.
Mais rien qui me concerne, jusqu’ici : j’utilisais tranquillement KDE 3.5, puis Openbox+tint2 pendant ces entrefaites.
Évoquons un peu ce sur quoi je cassais du sucre à l’instant.
pulseaudio
Mon premier contact avec pulseaudio, ce fut d’aider des utilisateurs pour qui le désinstaller résolvait le problème de son.
En effet, ALSA fait très bien tout le travail nécessaire pour gérer la sortie son dans le cas « je veux écouter de la musique / le son d’une vidéo ».
Personnellement, je n’écoute qu’un seul flux audio à la fois — un seul morceau de musique à la fois.
Je dis ça, mais ALSA vous permet bien entendu, “out of the box”, d’en écouter plusieurs en même temps, hein, pas de souci.
Et pour ceux qui veulent écouter plusieurs sources sonores en même temps, et trouvent que dmix a une qualité sonore merdique — c’est vrai, moi-même et mes amis l’entendons clairement — il y a Jack, qui est de toute façon installé car c’est une dépendance de mplayer et autres logiciels multimédia.
EDIT: mais encore plus simple, vous pouvez utiliser un meilleur rééchantillonnage que celui par défaut :
printf 'defaults.pcm.rate_converter "samplerate_medium"' >> /etc/asound.conf
Puis, même si ce n’est pas déjà installé sur votre machine, OSS4 est absolument génial (ça remplace ALSA).
Pour l’anecdote, j’avais aussi vu qu’à un moment, pulseaudio était suid root…
$ ls -l "$(which pulseaudio)" -rwsr-xr-x 1 root root 58600 2009-07-14 18:57 /usr/bin/pulseaudio
WHAT COULD POSSIBLY GO WRONG.
Oh, ben, trois fois rien…
Mais rassurez-vous, à l’heure actuelle pulseaudio n’est plus suid root et plus lancé en root.
Il a intérêt d’ailleurs, car pour moi, les seuls logiciels qui peuvent raisonnablement être suid root sont quelques binaires très éprouvés, tels que login et su.
avahi
Ce truc que pas mal d’applis traînent en dépendance pollue mon menu freedesktop et est remplacé avantageusement par IPv6.
systemd
C’est sûr que…
✗ Ça pète ma config
Ce n’est que des mois plus tard que j’ai réussi à ré-obtenir tant bien que mal ce qui marchait avant. Mais maintenant c’est au point, j’ai retrouvé les fonctionnalités d’avant, même avec systemd : voyez ici.
Ensuite. Ayant rapidement compris qu’il s’agissait de parallélisation du boot, j’ai vu plusieurs choses :
✔ Il y a gain de perf sur les SSD avec les grosses machines blink blink
(Ça m’indique que les développeurs ont ce genre de machine. C’est pas bien, de donner une machine puissante à un développeur : il teste dessus et c’est rapide. Mais sur ma vieille bécane…)
La parallélisation, ça ne dérange pas beaucoup les SSD : « ils ont autant de têtes que de blocs », pourrait-on dire, vu que c’est câblé en dur.
Donc comme ça exploite plus fort le CPU, on booste le temps de boot. Certes, on perd sur les changements de contexte, mais l’attente des entrées-sorties coûtant plus cher… normalement on gagne au final.
Mes tests le confirment. Pas de beaucoup, mais on y gagne bien.
On doit même gagner énormément, sur une install sysvinit mal configurée ou avec des surcouches d’abstraction à base de tonnes de scripts shell à n’en plus finir, comme Debian.
✗ Il y a perte de perf sur CD
…et donc mon live-CD en souffrira lors du boot sur CD.
En effet, qui dit parallélisation, dit ordre d’exécution imprévisible.
Et cela veut dire que je vais avoir du mal à placer les fichiers dans l’ISO dans l’ordre attendu de leur lecture au boot, pour limiter les déplacements de la tête…
~ Les disques durs, ça peut aller
On augmente l’accès aléatoire en stressant les entrées/sorties disque… conséquences ?
Évidemment, le résultat dépend entièrement de l’intelligence de l’ordonnanceur disque. Celui de linux doit être plutôt correct : j’ai été assez agréablement surpris de ne pas remarquer trop de baisse de temps de boot, par rapport à mon installation avant, avec SysVinit.
De ce côté, mes tests indiquent qu’on touche du bois.
✗ Lancer en parallèle, c’est bien… quand on a plein de RAM.
Hé oui !
Ce sont les machines avec très peu de RAM qui morflent. Le lancement en parallèle bouffe pas mal de mémoire très vite, et le noyau va alors disposer de moins de mémoire pour son cache disque — ce qui peut mener à relire des fichiers.
journald
Un des trucs qui font grincer des dents avec systemd, c’est qu’on ne peut pas le séparer de journald.
Voyons donc ce que ça vaut… et ce que ça donne.
Plein d’entrées-sorties
Partant du principe que c’est le stockage permanent qui est limitant pour les performances — notamment au boot — on s’est arrangé, d’une façon ou d’une autre, pour utiliser celui-ci à fond avec parallélisation du lancement.
Sauf que journald tient un journal qu’il synchronise sur le disque.
Et le souci là-dedans, c’est que ça force les entrées-sorties disque.
« Boah, ça peut pas être pire que ça »
…me disais-je.
En pratique :
- C’est la cause de la baisse de temps de boot dont je parlais plus haut — j’ai obtenu des temps de boot plus rapides que je n’en avais au mieux avec SysVinit, en désactivant l’écriture des logs journald.
- Avec journald, j’ai des délais de parfois 10-15 secondes, pendant lesquels le disque gratte à fond. Si je le fais écrire dans /dev/null, non.
Les images mémoire des processus qui plantent vont dans le journal, ça sature le disque et — comble de la rigolade — ça échoue presque à tous les coups.
Même pour l’image mémoire d'openbox, qui consomme moins de mémoire que journald. C’est d’ailleurs plutôt une indication de la gourmandise en mémoire de journald, un autre point de « détail » de ce logger.
La perte des logs texte
Lennart a l’air de trouver astronomiquement génial d’utiliser un format illisible binaire de base de donnée indexée pour les logs.
Je ne suis pas d’accord. Lui non plus (et pas que sur ça).
Soi-disant ça permet des recherches plus rapides dedans — en pratique pour moi, pas, c’est juste plus lent à écrire.
Mais surtout… avec les logs texte, on pouvait facilement nettoyer les lignes dedans quand un truc les floodait.
Exemple :
sed -i '/motif des lignes à enlever/d' /var/log/truc.logLe format journald étant “append-only” (on ajoute à la fin), ce n’est plus possible.
Ça, c’est ce que j’ai constaté moi-même en tant qu’utilisateur, content tant que ça marche. Mais d’autres vont plus loin — ici le concept de base est remis en cause.
Du coup…
Avant, j’avais des logs, et parfois je les regardais. La plupart du temps, ils ne m’embêtaient pas.
Maintenant, je les balance dans /dev/null parce que je ne supporte pas les ralentissements occasionnés. Quel magnifique progrès.
Le mot de la fin
Moi, utilisateur fainéant, j’en reste là.
Malgré tout ça, après que j’aie un peu embêté les développeurs systemd pour que l’option de limitation des logs fonctionne, et ça, et ça, une fois suffisament hacké, Arch Linux (re)marche.