Je pense que le reproche principal qu'on peut faire à systemd est que c'est quelque-chose qui s'éloigne complètement de l'esprit Unix:
Faux. systemd c'est une soixantaine de binaire, tous remplaçables et on peut tous éviter de les utiliser (sauf le coeur, évidemment), voire de les compiler.
petits composants logiciels qui font une seule chose et la font bien
Voir au dessus.
communication entre ces composants pour obtenir des choses plus complexes
Voir au dessus.
utilisation de fichiers texte directement lisibles et modifiables par les utilisateurs
On peut éviter d'utiliser ces binaires pour modifier la config et modifier les fichiers texte cibles à la main à la place.
Systemd ne se contente pas d'être un remplaçant à init et de gérer le démarrage du système et des divers démons, il vise aussi à remplacer syslog,
Non, c'est journald qui remplace syslog.
gérer automatiquement les devices dans /dev,
Non, ça reste le rôle de udev.
etc...
etc quoi ?
Qui plus est, il fait cela en remplaçant des fichiers texte par des fichiers binaires qui ont ensuite besoin de programmes spéciaux pour être manipulés. Comme modifier /etc/locale.conf au lieu d'appeler localtcl.
Seul le journal est binaire.
Fini les commandes tail -f /var/log/messages ou le grep dans maillog.
En même temps, journald fournit tout ce qu'il faut pour analyser le journal (man journalctl). Et il fournit un journal au format standardisé (fini les 26 formats de dates différents, par exemple).
Et on peut toujours reverser le contenu du journal de journald sous forme texte vers syslog (ça reverse dans les deux sens, en fait, avec le daemon approprié).
Fini le débugage de scripts de démarrage avec vi.
Tant mieux :
Myth: systemd is not debuggable.
False. Some people try to imply that the shell was a good debugger. Well, it isn't really. In systemd we provide you with actual debugging features instead. For example: interactive debugging, verbose tracing, the ability to mask any component during boot, and more. Also, we provide documentation for it.
It's certainly well debuggable, we needed that for our own development work, after all. But we'll grant you one thing: it uses different debugging tools, we believe more appropriate ones for the purpose, though.
Et puis les unit files sont bien plus simples, et ils sont uniformisés (idéalement, l'unit file provient de l'upstream du projet, et non pas de la distribution)
On se retrouve avec une usine à gaz qui met en l'air 30 ans de pratiques industrielles et je ne suis pas sûr qu'on gagne quelque-chose en échange.
On y gagne énormément en échange. Quelques exemples :
* Hotplug support
* Démarrage bien plus rapide
* Compatibilité avec les shellscripts
* Support du multi-seat
* systemd est scriptable ( systemctl, loginctl, timedatectl, hostnamectl, localectl , ...)
* Arrêt bien plus fiable des services (fini les zombies) grâce aux cgroups du kernel
* Intégration avec Linux (comme l'init BSD est fait pour BSD)
* unification des unit files (plutôt que d'avoir 36 variantes du script d'init pour un même logiciel, un par distrib'...)
* unification des runlevels (fini les différences à ce niveau entre les distributions)
* on ne réinvente pas la roue : systemd utilise linux, udev, d-bus, tout ce qui existait déjà.
[^] # Re: C’est du propre
Posté par xcomcmdr . En réponse à la dépêche Entretien avec François Tigeot, développeur DragonFly BSD. Évalué à 10. Dernière modification le 26 octobre 2013 à 17:26.
Faux. systemd c'est une soixantaine de binaire, tous remplaçables et on peut tous éviter de les utiliser (sauf le coeur, évidemment), voire de les compiler.
:)
Voir au dessus.
Voir au dessus.
On peut éviter d'utiliser ces binaires pour modifier la config et modifier les fichiers texte cibles à la main à la place.
Non, c'est journald qui remplace syslog.
Non, ça reste le rôle de udev.
etc quoi ?
Seul le journal est binaire.
En même temps, journald fournit tout ce qu'il faut pour analyser le journal (man journalctl). Et il fournit un journal au format standardisé (fini les 26 formats de dates différents, par exemple).
Et on peut toujours reverser le contenu du journal de journald sous forme texte vers syslog (ça reverse dans les deux sens, en fait, avec le daemon approprié).
Tant mieux :
Et puis les unit files sont bien plus simples, et ils sont uniformisés (idéalement, l'unit file provient de l'upstream du projet, et non pas de la distribution)
On y gagne énormément en échange. Quelques exemples :
* Hotplug support
* Démarrage bien plus rapide
* Compatibilité avec les shellscripts
* Support du multi-seat
* systemd est scriptable ( systemctl, loginctl, timedatectl, hostnamectl, localectl , ...)
* Arrêt bien plus fiable des services (fini les zombies) grâce aux cgroups du kernel
* Intégration avec Linux (comme l'init BSD est fait pour BSD)
* unification des unit files (plutôt que d'avoir 36 variantes du script d'init pour un même logiciel, un par distrib'...)
* unification des runlevels (fini les différences à ce niveau entre les distributions)
* on ne réinvente pas la roue : systemd utilise linux, udev, d-bus, tout ce qui existait déjà.
Bref, tu devrais lire ceci :
http://0pointer.de/blog/projects/the-biggest-myths.html
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)