Quand je vois la simplicité d'un fichier de config systemd pour l'immense majorité des cas (limite un unit file d'un daemon simple c'est 3 lignes, le nom du service, le binaire à lancer, et l'utilisateur) et les critiques style "mais ça casse mon script d'init de 1500 lignes pour mon usine à gaz ignoble", je dirais que c'est tout le contraire.
Il existe des systèmes d'initialisation on ne peut plus simple, comme runit, ou minit par exemple. La aussi c'est une histoire de moins de 10 lignes. Ce qui est important de comprendre, c'est que 10 lignes pour systemd et 10 lignes pour runit n'ont pas la même complexité lorsque l'on regarde le système dans son ensemble.
Systemd, c'est pas moins dans 270 000 ligne de C1, dont 44 000 pour la gestion des services2. Le code de minit ne dépasse pas les 1700 lignes, et celui de runit, 6500 (ou 3400 lorsque l'on ne compte pas la réimplantation partielle de la lib C3). C'est sans compter le fait que systemd définit plus de 60 services et bibliothèques4 qui sortent complètement du champs d'un système d'init.
Enfin systemd fait tout pour ce placer entre le noyau et un programme utilisateur. Ce qui ajoute un deuxième point critique au système, le premier étant le noyau (monolithique, lui aussi). Tout ceci montre que systemd est d'une complexité beaucoup plus grande que ce qui est nécéssaire, comme le montre les alternatives fonctionnelles. De plus cette complexité ce retrouve au cœur du système et envahit l'espace utilisateur. C'est pourquoi il est fallacieux de qualifier systemd de « simple », et présumer qu'une alternative est nécessairement complexe (« 1500 lignes »). La situation actuelle tend à montrer l'inverse, systemd étant complexe, et les alternatives en moyenne sont assez simples.
1: En ne considérant que les fichiers du répertoire src.
2: Systemd étant un énorme monolithe, on ne peut pas séparer uniquement la partie du code qui gère les services. Ainsi, on obtient le chiffre de 44 000 lignes de code en ne comptant que le code dans src/core et src/systemctl.
4:ls systemd/src | wc -l, qui donne 76. Résultat duquel il faut soustraire au moins trois fichiers, le Makefile, src/core et src/systemctl, plus une bonne demi-douzaine pour des dossiers qui ne définissent ni services, ni bibliothèques.
[^] # Re: systemd, le nouveau Multics
Posté par needs . En réponse au journal Attention avec systemd, Tmux ne survit plus après la fermeture de la session.. Évalué à 10. Dernière modification le 03 juin 2016 à 18:11.
Il existe des systèmes d'initialisation on ne peut plus simple, comme runit, ou minit par exemple. La aussi c'est une histoire de moins de 10 lignes. Ce qui est important de comprendre, c'est que 10 lignes pour systemd et 10 lignes pour runit n'ont pas la même complexité lorsque l'on regarde le système dans son ensemble.
Systemd, c'est pas moins dans 270 000 ligne de C1, dont 44 000 pour la gestion des services2. Le code de minit ne dépasse pas les 1700 lignes, et celui de runit, 6500 (ou 3400 lorsque l'on ne compte pas la réimplantation partielle de la lib C3). C'est sans compter le fait que systemd définit plus de 60 services et bibliothèques4 qui sortent complètement du champs d'un système d'init.
Enfin systemd fait tout pour ce placer entre le noyau et un programme utilisateur. Ce qui ajoute un deuxième point critique au système, le premier étant le noyau (monolithique, lui aussi). Tout ceci montre que systemd est d'une complexité beaucoup plus grande que ce qui est nécéssaire, comme le montre les alternatives fonctionnelles. De plus cette complexité ce retrouve au cœur du système et envahit l'espace utilisateur. C'est pourquoi il est fallacieux de qualifier systemd de « simple », et présumer qu'une alternative est nécessairement complexe (« 1500 lignes »). La situation actuelle tend à montrer l'inverse, systemd étant complexe, et les alternatives en moyenne sont assez simples.
1: En ne considérant que les fichiers du répertoire
src.2: Systemd étant un énorme monolithe, on ne peut pas séparer uniquement la partie du code qui gère les services. Ainsi, on obtient le chiffre de 44 000 lignes de code en ne comptant que le code dans
src/coreetsrc/systemctl.3:
runit/src $ cloc chpst.c runit-init.c runit.c runsv.c runsvchdir.c runsvctrl.c runsvdir.c runsvstat.c sv.c svlogd.c svwaitdown.c svwaitup.c utmpset.c4:
ls systemd/src | wc -l, qui donne 76. Résultat duquel il faut soustraire au moins trois fichiers, leMakefile,src/coreetsrc/systemctl, plus une bonne demi-douzaine pour des dossiers qui ne définissent ni services, ni bibliothèques.