Je suis bien d'accord, et c'était justement mon point.
D'ailleurs, il faut savoir qu'une instance de runsv compilée avec musl (ou gcc en statique) consomme 4Kio de mémoire résidente, contre pas loin de 765 pour glibc (de debian 10), idem pour svlogd.
J'ai fait mes mesures, parce que ça m'amuse, surtout.
Et malgré ce 1.5Megs par daemon géré par runit, il faut plusieurs 10aines de daemon pour arriver au même niveau de consommation mémoire que systemd, une fois celle-ci divisée par le nombre de processus.
Je trouve aussi plus fiable, d'un point de vue architecture logicielle, d'avoir les daemons et leurs logs gérés par 1 ou 2 processus par daemon que l'approche de systemd, qui gère toutes ces instances dans le PID1: au moindre problème, PID1 de systemd pourrais mener à un kernel panic (plus d'init), ce qui est bien moins probable avec l'empilement de processus générés par runit (et les autres daemontools).
L'inconvénient de runit, comparé à systemd, c'est que 1) faut connaître un peu le shell (bon, sur 5-10 lignes, souvent, ça va...) et 2) "thundering herd problem", pas de vraie gestion des dépendances, et ça, c'est très chiant. En vrai, c'est la seule force non-contestable de systemd, je pense, vu que le côté déclaratif (systemd) vs un langage de script simple (runit avec dash) voire un DSL (nosh), c'est je pense assez subjectif (même si l'approche de systemd me plaît bien!).
[^] # Re: moi c'est l'inverse
Posté par freem . En réponse au journal Linux ne m'intéresse plus. Évalué à 4.
Je suis bien d'accord, et c'était justement mon point.
D'ailleurs, il faut savoir qu'une instance de runsv compilée avec musl (ou gcc en statique) consomme 4Kio de mémoire résidente, contre pas loin de 765 pour glibc (de debian 10), idem pour svlogd.
J'ai fait mes mesures, parce que ça m'amuse, surtout.
Et malgré ce 1.5Megs par daemon géré par runit, il faut plusieurs 10aines de daemon pour arriver au même niveau de consommation mémoire que systemd, une fois celle-ci divisée par le nombre de processus.
Je trouve aussi plus fiable, d'un point de vue architecture logicielle, d'avoir les daemons et leurs logs gérés par 1 ou 2 processus par daemon que l'approche de systemd, qui gère toutes ces instances dans le PID1: au moindre problème, PID1 de systemd pourrais mener à un kernel panic (plus d'init), ce qui est bien moins probable avec l'empilement de processus générés par runit (et les autres daemontools).
L'inconvénient de runit, comparé à systemd, c'est que 1) faut connaître un peu le shell (bon, sur 5-10 lignes, souvent, ça va...) et 2) "thundering herd problem", pas de vraie gestion des dépendances, et ça, c'est très chiant. En vrai, c'est la seule force non-contestable de systemd, je pense, vu que le côté déclaratif (systemd) vs un langage de script simple (runit avec dash) voire un DSL (nosh), c'est je pense assez subjectif (même si l'approche de systemd me plaît bien!).