Mais systemd n'est pas un bloc monolithique, c'est un ensemble de petits outils qui se concentrent sur une chose et qui fonctionnent bien ensemble. Du coup, de ce point de vue, ça respecte la philosophie unix. Je ne commente pas l'aspect "bien" de "faire une seule chose bien", on peut subjectivement trouver qu'ils ne font pas bien le taf.
Le pid 1 de systemd est peut-être plus complexe que le reste, peut-être qu'on peut discuter cet aspect, en vérifiant que les alternatives ne sont pas aussi complexes de toute façon, à fonctionnalités comparables.
On peut regretter que journald ne soit pas optionnel (pid 1 l'est probablement, je suppose qu'on peut utiliser la plupart des outils systemd sans, à vérifier), donc la modularité a ses limites, mais pareil, est-ce plus modulaire ailleurs ? Vrai question, je ne suis pas trop familier avec les alternatives.
Enfin, on peut regretter que journald stocke les journaux en binaire. Question de goût, je suppose que c'est pour des questions de robustesse et d'efficacité. Je comprends qu'on n'aime pas trop, en même temps ça ne m'est jamais arrivé de m'en rendre compte parce que je trouve journalctl très agréable à utiliser pour manipuler les logs.
En résumé, qu'est-ce qui n'est pas unix pour toi dans systemd, et quels inconvénients cela apporte en ptatique ? (Après avoir lu les contre-arguments aux critiques usuelles là : http://0pointer.de/blog/projects/the-biggest-myths.html_ en particulier les points 1 et 10)
Je note l'inaccessibilité des logs sans utiliser un binaire systemd, j'entends, avec les réserves que j'ai émises dans l'autre commentaire.
Sinon j'entends aussi l'argument de n'être pas familier avec la solution, en vrai c'est une vraie bonne raison.
Concernant ta question sur la modularité et si quelqu'un a essayé en pratique, je n'ai pas trop essayé à part utiliser ou non systemd-networkd, nspawn et leur solution pour remplacer cron (?). Je dirais que c'est à la critique de montrer que ce n'est pas modulaire.
Mais en vrai, la philosophie unix, je m'en fiche un peu, ce qui m'importe c'est que ce soit efficace, clair et si possible élégant. Un argument plus fort pour moi serait la présentation d'une alternative dont la fonctionnalité principale n'est pas "n'est pas systemd", mais des arguments convaincants sur pourquoi c'est mieux. Sachant que pour moi, l'arrivée de systemd a été une grosse amélioration. Écrire un service par exemple, largement plus simple et plus compréhensible qu'un script shell parce que c'est en mode déclaratif et c'est très conscis. C'était déjà le cas avec upstart, qui était pas mal, mais pour moi systemd est juste un meilleur upstart, avec si j'ai bien compris un peu d'inspiration du côté de launchd avec l'activation par socket (qui semble être une excellente idée, pour avoir accès à des fonctionnalité sans tout devoir lancer en avance).
[^] # Re: C'est pas que je veuille cramer systemd, mais ...
Posté par raphj (site web personnel) . En réponse au lien 14 ans de systemd. Évalué à 3. Dernière modification le 18 février 2025 à 23:42.
Mais systemd n'est pas un bloc monolithique, c'est un ensemble de petits outils qui se concentrent sur une chose et qui fonctionnent bien ensemble. Du coup, de ce point de vue, ça respecte la philosophie unix. Je ne commente pas l'aspect "bien" de "faire une seule chose bien", on peut subjectivement trouver qu'ils ne font pas bien le taf.
Le pid 1 de systemd est peut-être plus complexe que le reste, peut-être qu'on peut discuter cet aspect, en vérifiant que les alternatives ne sont pas aussi complexes de toute façon, à fonctionnalités comparables.
On peut regretter que journald ne soit pas optionnel (pid 1 l'est probablement, je suppose qu'on peut utiliser la plupart des outils systemd sans, à vérifier), donc la modularité a ses limites, mais pareil, est-ce plus modulaire ailleurs ? Vrai question, je ne suis pas trop familier avec les alternatives.
Enfin, on peut regretter que journald stocke les journaux en binaire. Question de goût, je suppose que c'est pour des questions de robustesse et d'efficacité. Je comprends qu'on n'aime pas trop, en même temps ça ne m'est jamais arrivé de m'en rendre compte parce que je trouve journalctl très agréable à utiliser pour manipuler les logs.
En résumé, qu'est-ce qui n'est pas unix pour toi dans systemd, et quels inconvénients cela apporte en ptatique ? (Après avoir lu les contre-arguments aux critiques usuelles là : http://0pointer.de/blog/projects/the-biggest-myths.html_ en particulier les points 1 et 10)
Je note l'inaccessibilité des logs sans utiliser un binaire systemd, j'entends, avec les réserves que j'ai émises dans l'autre commentaire.
Sinon j'entends aussi l'argument de n'être pas familier avec la solution, en vrai c'est une vraie bonne raison.
Concernant ta question sur la modularité et si quelqu'un a essayé en pratique, je n'ai pas trop essayé à part utiliser ou non systemd-networkd, nspawn et leur solution pour remplacer cron (?). Je dirais que c'est à la critique de montrer que ce n'est pas modulaire.
Mais en vrai, la philosophie unix, je m'en fiche un peu, ce qui m'importe c'est que ce soit efficace, clair et si possible élégant. Un argument plus fort pour moi serait la présentation d'une alternative dont la fonctionnalité principale n'est pas "n'est pas systemd", mais des arguments convaincants sur pourquoi c'est mieux. Sachant que pour moi, l'arrivée de systemd a été une grosse amélioration. Écrire un service par exemple, largement plus simple et plus compréhensible qu'un script shell parce que c'est en mode déclaratif et c'est très conscis. C'était déjà le cas avec upstart, qui était pas mal, mais pour moi systemd est juste un meilleur upstart, avec si j'ai bien compris un peu d'inspiration du côté de launchd avec l'activation par socket (qui semble être une excellente idée, pour avoir accès à des fonctionnalité sans tout devoir lancer en avance).