Une nouvelle commande list-machines a été ajoutée à systemctl. Elle liste tous les systèmes d’exploitation dans un conteneur ainsi que leurs états (voir le point ci-dessus), si systemd est utilisé dans ces conteneurs.
Je ne connais pas encore suffisamment systemd pour avoir un avis tranché, je le découvre en ce moment sur ma Debian et à travers les récentes dépêches sur systemd pour les administrateurs (merci à leurs auteurs), mais, même si après tout pourquoi pas, je me demande quand même pourquoi systemd prend en charge cette fonctionnalité ?
Quel est l'intérêt ? Pourquoi ré-inventer une partie de quelque chose qui existe déjà (les outils fournis par lxc, l'api libvirt...) et l'intégrer à un projet qui de mon point de vue n'a pas grand chose à voir ? Je ne trouve pas logique de faire appel à un utilitaire de systemd pour gérer mes conteneurs (même si systemd gère les cgroup en arrière-plan et donc par extension, les-dits conteneurs).
Je lis beaucoup les commentaires sur les nombreuses discussions à propos de systemd et même si - je le répète - mon avis n'est pas fait, force est de constater que l'argument qui revient souvent à propos du fait que systemd cherche à tout faire (un futur remplaçant d'emacs peut-être ? :D) semble justifié.
Je ne dis pas que c'est une mauvaise chose pour autant, mais j'imagine que ça doit au moins faire plus de code à maintenir, plus de bug potentiels et donc plus de boulot.
Au final, même si du peu que j'en ai vu, j'aime bien ce qu'apporte systemd - la rapidité du boot notamment - j'ai l'impression de perdre aussi un peu de cette philosophie d'Unix qui disait que les programmes faisaient peu de choses mais le faisaient bien et que leurs combinaisons permettaient de faire des choses plus complexes.
# list-machines ?
Posté par madhatter (site web personnel) . En réponse à la dépêche systemd versions 212 à 215. Évalué à 6.
Salut,
Je ne connais pas encore suffisamment systemd pour avoir un avis tranché, je le découvre en ce moment sur ma Debian et à travers les récentes dépêches sur systemd pour les administrateurs (merci à leurs auteurs), mais, même si après tout pourquoi pas, je me demande quand même pourquoi systemd prend en charge cette fonctionnalité ?
Quel est l'intérêt ? Pourquoi ré-inventer une partie de quelque chose qui existe déjà (les outils fournis par lxc, l'api libvirt...) et l'intégrer à un projet qui de mon point de vue n'a pas grand chose à voir ? Je ne trouve pas logique de faire appel à un utilitaire de systemd pour gérer mes conteneurs (même si systemd gère les cgroup en arrière-plan et donc par extension, les-dits conteneurs).
Je lis beaucoup les commentaires sur les nombreuses discussions à propos de systemd et même si - je le répète - mon avis n'est pas fait, force est de constater que l'argument qui revient souvent à propos du fait que systemd cherche à tout faire (un futur remplaçant d'emacs peut-être ? :D) semble justifié.
Je ne dis pas que c'est une mauvaise chose pour autant, mais j'imagine que ça doit au moins faire plus de code à maintenir, plus de bug potentiels et donc plus de boulot.
Au final, même si du peu que j'en ai vu, j'aime bien ce qu'apporte systemd - la rapidité du boot notamment - j'ai l'impression de perdre aussi un peu de cette philosophie d'Unix qui disait que les programmes faisaient peu de choses mais le faisaient bien et que leurs combinaisons permettaient de faire des choses plus complexes.
There is no spoon...