Personnellement, je pense qu'il y a de très bonnes idées dans systemd, les plus importantes étant :
suivi des processus (via les cgroups) permettant de faire de la supervision de daemons
gestion fine des dépendances et parallélisme.
gestion des évènements et démarrage de services conditionnels
Le problème c'est que je n'aime pas l'implémentation. Dire que systemd est découpé plein d'outils est très partiellement vrai. Un des plus gros problèmes c'est que systemd est écrit en C. Je trouve incroyable qu'on écrire un logiciel si gros en C de nos jours. Du coup, il me semble qu'un tel logiciel devrait vraiment être simplifié et découpé en plusieurs processus. Parce que systemd est gros. Presque un million de ligne de code en regardant tout ses composants.
Par exemple, le code pour parser les fichiers de conf tourne dans l'init, en mode privilégié, alors que ça pourrait très bien être un utilitaire séparé. De même, systemd sait monter des systèmes de fichier, alors que du code montant des systèmes de fichier existe déjà : il serait bon de le réutiliser, en faisant appel à un utilitaire séparé. Il en va de même pour le code de monitoring des processus, qui pourrait tourner dans un daemon distinct. L'overhead en communication n'est pas ce qui va ralentir l'éxécution de manière dommageable, je pense.
Pour résumer, je pense que le coeur d'init devrait n'ếtre capabable que de gérer des noms de service et garder la trace de ceux qui sont lancés, ainsi qu'une structure de donnée représentant les relations de dépendance (qui peut même être conservée sur le disque, sur le FS). Quand il veut lancer un service, il délègue au bon daemon (mountd, netd, ...) et recevoir les événements de daemons de monitoring ( (u)devd, netd, mountd, monitord, pour regarder quels process meurent, etc).
La surface d'attaque est grandement diminuée, et si un des daemons plantes, tout les processus du système ne meurent pas. La tolérance au bug est beaucoup plus forte, ainsi que la ré-utilisation de code. Il est ainsi possible de démarer en mode dégradé dans n'importe quelle condition.
[^] # Mon opinion sur systemd
Posté par Enj0lras . En réponse à la dépêche Entretien avec François Tigeot, développeur DragonFly BSD. Évalué à -2.
Personnellement, je pense qu'il y a de très bonnes idées dans systemd, les plus importantes étant :
Le problème c'est que je n'aime pas l'implémentation. Dire que systemd est découpé plein d'outils est très partiellement vrai. Un des plus gros problèmes c'est que systemd est écrit en C. Je trouve incroyable qu'on écrire un logiciel si gros en C de nos jours. Du coup, il me semble qu'un tel logiciel devrait vraiment être simplifié et découpé en plusieurs processus. Parce que systemd est gros. Presque un million de ligne de code en regardant tout ses composants.
Par exemple, le code pour parser les fichiers de conf tourne dans l'init, en mode privilégié, alors que ça pourrait très bien être un utilitaire séparé. De même, systemd sait monter des systèmes de fichier, alors que du code montant des systèmes de fichier existe déjà : il serait bon de le réutiliser, en faisant appel à un utilitaire séparé. Il en va de même pour le code de monitoring des processus, qui pourrait tourner dans un daemon distinct. L'overhead en communication n'est pas ce qui va ralentir l'éxécution de manière dommageable, je pense.
Pour résumer, je pense que le coeur d'init devrait n'ếtre capabable que de gérer des noms de service et garder la trace de ceux qui sont lancés, ainsi qu'une structure de donnée représentant les relations de dépendance (qui peut même être conservée sur le disque, sur le FS). Quand il veut lancer un service, il délègue au bon daemon (mountd, netd, ...) et recevoir les événements de daemons de monitoring ( (u)devd, netd, mountd, monitord, pour regarder quels process meurent, etc).
La surface d'attaque est grandement diminuée, et si un des daemons plantes, tout les processus du système ne meurent pas. La tolérance au bug est beaucoup plus forte, ainsi que la ré-utilisation de code. Il est ainsi possible de démarer en mode dégradé dans n'importe quelle condition.