init -> peu de dépendances
systemd -> plus de dépendances.
Certes. Mais il n'y a pas que ça qui rentre dans la balance. Surtout que les dépendances peuvent se choisir lors de la compilation, et que toutes ne sont pas obligatoires.
SysV -> pas de standard entre les distributions. Langage de script qui est difficile à maitriser (notamment au niveau de la sécurité), bavard, et qui est inadapté. Inefficace : pour chaque script d'init, une instance de sh est lancée. N'est pas compatible BSD mais ne tire pour autant pas partie des fonctionnalités du kernel linux (cgroups, notamment). On est jamais sûr de tuer un service proprement (processus zombie, fichier PID à effacer à la main parce que le service n'a pas pu le faire, etc...). Pas de parallélisation. Pas moyen de lancer/arrêter un service à la demande (exemple : pas besoin de CUPS lorsque l'imprimante a été débranchée)...
systemd -> un seul fichier unit par service pour toutes les distributions. Moins de code, moins de chances d'erreurs, moins d'usage mémoire, meilleure maintenabilité. Utilisation mémoire comparable à celle de SysV. Fichier à-la-ini standardisé et documenté et facile à remplir. API entièrement documentée, aussi. Tire partie des capacités du kernel qui sont présentes depuis des années. On est sûr de tuer un service quand il y a besoin sans devoir redémarrer la machine. Le PID 1 n'est pas plus bloated que celui de SysV, vu que systemd est livré avec une soixantaine de binaires, remplaçables, indépendant les uns des autres (penser aux base-utils GNU : on est loin de toutes les utiliser, c'est pas pour autant que c'est bloated). Est compatible avec les shell scripts (et les quelques incompatibilités sont documentées). Est scriptable via DBus (qui a des bindings avec beaucoup de langages). Offre un journal centralisé, standardisé (par exemple au niveau des dates). Tout est fichier (cgroupfs). On peut réduire les fonctionnalités de systemd à la compilation (on peut faire en sorte que ce soit juste un système d'init et rien de plus : c'est prévu)...
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: C'est plus facile de travailler salement...
Posté par xcomcmdr . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 5.
Certes. Mais il n'y a pas que ça qui rentre dans la balance. Surtout que les dépendances peuvent se choisir lors de la compilation, et que toutes ne sont pas obligatoires.
SysV -> pas de standard entre les distributions. Langage de script qui est difficile à maitriser (notamment au niveau de la sécurité), bavard, et qui est inadapté. Inefficace : pour chaque script d'init, une instance de sh est lancée. N'est pas compatible BSD mais ne tire pour autant pas partie des fonctionnalités du kernel linux (cgroups, notamment). On est jamais sûr de tuer un service proprement (processus zombie, fichier PID à effacer à la main parce que le service n'a pas pu le faire, etc...). Pas de parallélisation. Pas moyen de lancer/arrêter un service à la demande (exemple : pas besoin de CUPS lorsque l'imprimante a été débranchée)...
systemd -> un seul fichier unit par service pour toutes les distributions. Moins de code, moins de chances d'erreurs, moins d'usage mémoire, meilleure maintenabilité. Utilisation mémoire comparable à celle de SysV. Fichier à-la-ini standardisé et documenté et facile à remplir. API entièrement documentée, aussi. Tire partie des capacités du kernel qui sont présentes depuis des années. On est sûr de tuer un service quand il y a besoin sans devoir redémarrer la machine. Le PID 1 n'est pas plus bloated que celui de SysV, vu que systemd est livré avec une soixantaine de binaires, remplaçables, indépendant les uns des autres (penser aux base-utils GNU : on est loin de toutes les utiliser, c'est pas pour autant que c'est bloated). Est compatible avec les shell scripts (et les quelques incompatibilités sont documentées). Est scriptable via DBus (qui a des bindings avec beaucoup de langages). Offre un journal centralisé, standardisé (par exemple au niveau des dates). Tout est fichier (cgroupfs). On peut réduire les fonctionnalités de systemd à la compilation (on peut faire en sorte que ce soit juste un système d'init et rien de plus : c'est prévu)...
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)