Il prétend remplir tous les points qui me séduisent chez runit, et que runit remplis la plupart, à un gros détail près:
Supervision suites should provide a basis for high-level service management.
Ici, je bloque.
De l'aveu de l'auteur du document, c'est le seul avantage par rapport à runit, qui est le successeur des daemontools (au sens unix du terme, pas windowsien, ou c'est juste un outil pour simuler un CD).
Mais justement, ce que moi j'apprécie, et qui est le tort de systemd à mon sens, c'est justement le fait qu'un système d'initialisation ne devrait pas contenir de code complexe, il doit être léger et prédictible.
Donc, pas «haut niveau» au sens administration système du terme.
Il reproche à runit d'être basé sur un système de polling? C'est un détail d'implémentation, de ce que j'ai vu du code, si ça pose problème, patcher ça pour un autre système ne serait pas trop long: reste à en voir l'intérêt? Parce que, pour moi, «polling» évoque l'appel système «poll», qui justement permets de faire de l'asynchrone bloquant sans multi-thread et en standard POSIX. Donc, ou est le problème?
Les scripts doivent être écrits pour chaque service? C'est justement un point que j'apprécie. Le problème potentiel que je vois ici, c'est que ces scripts vont partager du code, code dupliqué, le mal absolu. C'est vrai. Sauf que rien n'empêche d'écrire des binaires, qui utiliseraient la même lib partagée: le code serait pas dupliqué, il serait partagé, il serait compilé (donc plus rapide), il serait de plus haut niveau.
Pourquoi ne pas le faire? Parce que ça ne semble pas valoir le coup. J'ai lu les scripts d'init de la seule distrib que je connaisse qui s'en serve par défaut: remplacer un script de 10 lignes maximum pour pouvoir partager le code me paraît overkill.
La solution fournie par s6, c'est de faire dépendre directement, par l'ABI, du système d'init. C'est justement un truc que je regrette pour systemd.
Ceci dit, on va pas troller, c'est pas encore le jour, ton document est plutôt intéressant, même s'il semble un peu déprécié (j'aurai aimé quelques comparaisons avec systemd, justement, l'acteur majeur du moment) malgré que le manque de date empêche d'en être sûr.
[^] # Re: autre: sv restart <service>
Posté par freem . En réponse au sondage Pour redémarrer un service, vous êtes plutôt ?. Évalué à 2.
Oui et non.
Il prétend remplir tous les points qui me séduisent chez runit, et que runit remplis la plupart, à un gros détail près:
Ici, je bloque.
De l'aveu de l'auteur du document, c'est le seul avantage par rapport à runit, qui est le successeur des daemontools (au sens unix du terme, pas windowsien, ou c'est juste un outil pour simuler un CD).
Mais justement, ce que moi j'apprécie, et qui est le tort de systemd à mon sens, c'est justement le fait qu'un système d'initialisation ne devrait pas contenir de code complexe, il doit être léger et prédictible.
Donc, pas «haut niveau» au sens administration système du terme.
Il reproche à runit d'être basé sur un système de polling? C'est un détail d'implémentation, de ce que j'ai vu du code, si ça pose problème, patcher ça pour un autre système ne serait pas trop long: reste à en voir l'intérêt? Parce que, pour moi, «polling» évoque l'appel système «poll», qui justement permets de faire de l'asynchrone bloquant sans multi-thread et en standard POSIX. Donc, ou est le problème?
Les scripts doivent être écrits pour chaque service? C'est justement un point que j'apprécie. Le problème potentiel que je vois ici, c'est que ces scripts vont partager du code, code dupliqué, le mal absolu. C'est vrai. Sauf que rien n'empêche d'écrire des binaires, qui utiliseraient la même lib partagée: le code serait pas dupliqué, il serait partagé, il serait compilé (donc plus rapide), il serait de plus haut niveau.
Pourquoi ne pas le faire? Parce que ça ne semble pas valoir le coup. J'ai lu les scripts d'init de la seule distrib que je connaisse qui s'en serve par défaut: remplacer un script de 10 lignes maximum pour pouvoir partager le code me paraît overkill.
La solution fournie par s6, c'est de faire dépendre directement, par l'ABI, du système d'init. C'est justement un truc que je regrette pour systemd.
Ceci dit, on va pas troller, c'est pas encore le jour, ton document est plutôt intéressant, même s'il semble un peu déprécié (j'aurai aimé quelques comparaisons avec systemd, justement, l'acteur majeur du moment) malgré que le manque de date empêche d'en être sûr.