Je me permets de répondre à sinma et à xcomcmdr dans le même commentaire, parce que mes éléments de réponse sont en partie liés.
sinma :
Maintenant on a un truc qui est utilisé par beaucoup plus de monde (Fedora, openSUSE, Arch Linux, Frugalware, etc) dont potentiellement moins bugué,
« Potentiellement », oui ; systemd est encore jeune. Peut-être atteint-il maintenant un stade assez mature, mais pas depuis très longtemps.
La version pourrie qui était sur la Fedora 17 causait des dysfonctionnement d’autofs.
Je sais que systemd a une fonctionnalité d’automontage, mais elle n’est pas à la hauteur d’autofs : pas de possibilité de charger les points de montage d’une table NIS ou d’un annuaire LDAP, ni d’auto-démonter après un certain temps sans utilisation.
xcomcmdr :
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.
Ça, c’est quand le bug est dans l’enchaînement du démarrage ou dans les composants eux-mêmes. Pour les dysfonctionnements d’autofs, qui impliquaient un traitement spécial au niveau de systemd lui-même (autofs est un service qui monte des répertoires pour d’autre utilisateurs que celui sous lequel il tourne ; apparemment, ça rentre mal dans les cases des cgroups), les développeurs de Fedora avaient marqué le bug en « fix next release ». Sachant que les versions plus récentes de systemd le corrigeaient, mais que les développeurs de Fedora conservaient sa version d’origine dans la 17 (probablement pour éviter des modifications trop importantes du système, les définitions des unités systemd ayant beaucoup évolué entre la version de Fedora 17 et celle qui corrigeait le problème ; c’est ce qui m’a dissuadé de résoudre le problème en remplaçant moi-même la version de systemd), il n’y avait pas d’issue.
sinma :
alors qu’avant c’était chacun son truc donc potentiellement plus bugué et surtout, il fallait réapprendre pour chaque distribution.
Ben c’est-à-dire que quand un script d’init de quelques dizaines de lignes était pourri, je pouvais le déboguer moi-même. S’il faut déboguer systemd (je parle bien de l’exécutable de systemd, pas des unités) pour un problème non trivial, c’est cuit.
Bon, maintenant, Fedora fait en sorte de mettre à jour systemd. Je ne sais pas dans quelle mesure ça leur fait un boulot important ou pas, mais c’est certainement plus raisonnable que d’essayer de backporter des modifications de systemd dans une version plus ancienne.
xcomcmdr :
On y gagne énormément en échange. Quelques exemples :
* Démarrage bien plus rapide
Ou pas. Sur mon portable sous Arch, avant systemd, je démarrais les quelques services dont dépendent vraiment les autres séquentiellement, puis quasiment tout en parallèle. Au début (quand systemd n’était que dans les contributions), systemd démarrait aussi rapidement, mais avec la multiplication des micro-unités et des fichiers de configuration, ça demande plus d’accès disques et c’est finalement plus lent.
À l’opposé, sur un serveur, le démarrage parallélisé, voire à la demande, rend plus difficile de vérifier que tous les services ont démarré correctement.
Compatibilité avec les shellscripts
C’est une fonctionnalité de systemd, mais pas un gain. Les systèmes de démarrage basés sur le shell n’avaient pas trop de problèmes de compatibilité avec les scripts shells.
Arrêt bien plus fiable des services (fini les zombies) grâce aux cgroups du kernel
C’est bien sur un serveur.
En pratique, sur un poste client que tu veux redémarrer, c’est moins clair.
Il arrive que des points de montage NFS restent après l’arrêt du réseau (léger souci dans l’enchaînement quand même... et ça, c’est sous Fedora 19 avec un systemd récent, sur les versions plus anciennes, ce genre de problème était plus fréquent et bien plus long) et alors systemd patine pendant un certain temps dessus... Alors que de toute façon, il ne se produira pas de miracle pour finir une hypothétique opération sur un système de fichier réseau sans le réseau, et que tout ce que tu veux, c’est redémarrer.
D’un autre côté, si on considère que l’alternative actuelle dans les distributions populaires, c’est upstart, finalement systemd fonctionne quand même plus facilement avec des services réseau...
Intégration avec Linux (comme l'init BSD est fait pour BSD)
Non, l’intégration avec le système, pour le meilleur (meilleure gestion du hotplug, que tu cites) ou le pire (quasiment plus possible d’éviter systemd), c’est une nouveauté de systemd.
Avec un Unix normal, le système d’init est globalement indépendant du noyau. Il suffit de voir la Slackware avec un init BSD ou la Debian/BSD avec un init System V.
unification des unit files (plutôt que d'avoir 36 variantes du script d'init pour un même logiciel, un par distrib'...)
Avec le bémol que la distribution la plus populaire n’a pas adopté systemd.
on ne réinvente pas la roue : systemd utilise linux, udev, d-bus, tout ce qui existait déjà.
Il remplace (hormis le système d’init) l’automontage (mal), la gestion de la veille (sans fournir toutes les fonctionnalités non plus), les journaux système...
Bref, systemd n’est pas dépourvu d’intérêt, mais tout n’est pas rose non plus.
Si tout ce que veulent les développeurs des *BSD, c’est un système d’init simple et fiable et pas autre chose, ils sont certainement mieux avec leur système actuel.
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone
[^] # Re: C’est du propre
Posté par Arthur Accroc . En réponse à la dépêche Entretien avec François Tigeot, développeur DragonFly BSD. Évalué à 10.
Je me permets de répondre à sinma et à xcomcmdr dans le même commentaire, parce que mes éléments de réponse sont en partie liés.
sinma :
« Potentiellement », oui ; systemd est encore jeune. Peut-être atteint-il maintenant un stade assez mature, mais pas depuis très longtemps.
La version pourrie qui était sur la Fedora 17 causait des dysfonctionnement d’autofs.
Je sais que systemd a une fonctionnalité d’automontage, mais elle n’est pas à la hauteur d’autofs : pas de possibilité de charger les points de montage d’une table NIS ou d’un annuaire LDAP, ni d’auto-démonter après un certain temps sans utilisation.
xcomcmdr :
Ça, c’est quand le bug est dans l’enchaînement du démarrage ou dans les composants eux-mêmes. Pour les dysfonctionnements d’autofs, qui impliquaient un traitement spécial au niveau de systemd lui-même (autofs est un service qui monte des répertoires pour d’autre utilisateurs que celui sous lequel il tourne ; apparemment, ça rentre mal dans les cases des cgroups), les développeurs de Fedora avaient marqué le bug en « fix next release ». Sachant que les versions plus récentes de systemd le corrigeaient, mais que les développeurs de Fedora conservaient sa version d’origine dans la 17 (probablement pour éviter des modifications trop importantes du système, les définitions des unités systemd ayant beaucoup évolué entre la version de Fedora 17 et celle qui corrigeait le problème ; c’est ce qui m’a dissuadé de résoudre le problème en remplaçant moi-même la version de systemd), il n’y avait pas d’issue.
sinma :
Ben c’est-à-dire que quand un script d’init de quelques dizaines de lignes était pourri, je pouvais le déboguer moi-même. S’il faut déboguer systemd (je parle bien de l’exécutable de systemd, pas des unités) pour un problème non trivial, c’est cuit.
Bon, maintenant, Fedora fait en sorte de mettre à jour systemd. Je ne sais pas dans quelle mesure ça leur fait un boulot important ou pas, mais c’est certainement plus raisonnable que d’essayer de backporter des modifications de systemd dans une version plus ancienne.
xcomcmdr :
Ou pas. Sur mon portable sous Arch, avant systemd, je démarrais les quelques services dont dépendent vraiment les autres séquentiellement, puis quasiment tout en parallèle. Au début (quand systemd n’était que dans les contributions), systemd démarrait aussi rapidement, mais avec la multiplication des micro-unités et des fichiers de configuration, ça demande plus d’accès disques et c’est finalement plus lent.
À l’opposé, sur un serveur, le démarrage parallélisé, voire à la demande, rend plus difficile de vérifier que tous les services ont démarré correctement.
C’est une fonctionnalité de systemd, mais pas un gain. Les systèmes de démarrage basés sur le shell n’avaient pas trop de problèmes de compatibilité avec les scripts shells.
C’est bien sur un serveur.
En pratique, sur un poste client que tu veux redémarrer, c’est moins clair.
Il arrive que des points de montage NFS restent après l’arrêt du réseau (léger souci dans l’enchaînement quand même... et ça, c’est sous Fedora 19 avec un systemd récent, sur les versions plus anciennes, ce genre de problème était plus fréquent et bien plus long) et alors systemd patine pendant un certain temps dessus... Alors que de toute façon, il ne se produira pas de miracle pour finir une hypothétique opération sur un système de fichier réseau sans le réseau, et que tout ce que tu veux, c’est redémarrer.
D’un autre côté, si on considère que l’alternative actuelle dans les distributions populaires, c’est upstart, finalement systemd fonctionne quand même plus facilement avec des services réseau...
Non, l’intégration avec le système, pour le meilleur (meilleure gestion du hotplug, que tu cites) ou le pire (quasiment plus possible d’éviter systemd), c’est une nouveauté de systemd.
Avec un Unix normal, le système d’init est globalement indépendant du noyau. Il suffit de voir la Slackware avec un init BSD ou la Debian/BSD avec un init System V.
Avec le bémol que la distribution la plus populaire n’a pas adopté systemd.
Il remplace (hormis le système d’init) l’automontage (mal), la gestion de la veille (sans fournir toutes les fonctionnalités non plus), les journaux système...
Bref, systemd n’est pas dépourvu d’intérêt, mais tout n’est pas rose non plus.
Si tout ce que veulent les développeurs des *BSD, c’est un système d’init simple et fiable et pas autre chose, ils sont certainement mieux avec leur système actuel.
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone