Pour ma part, je ne dis pas qu'il faut garder le système d'init sysV
Attention, on confond souvent sysVinit et rc.d. La vraie calamité, dans l'histoire, c'est rc.d, pas sysVinit, même si je trouve quand même que sysVinit en fait trop, notamment les runlevels, qui ne servent en pratique pas à grand chose à mon avis.
Cela dit, vu que sysVinit dispose de fonctionnalités inutiles, je suis également en faveur de le virer.
De mon côté, je cherche des solutions entre-deux.
J'ai adopté runit, mais je tombe au boulot dans certaines de ses limites (quand le fichier run est en exécution, le service est considéré up, alors que si ça se trouve, on essaie juste de vérifier les préconditions... ça se règlerait avec un bête signal à runsv, mais non. De plus, il faut parser la sortie de sv pour savoir si un service devrait tourner... c'est dommage) et je suis tombé récemment sur un outil nommé nosh, qui prétend résoudre certains de ces problèmes.
Accessoirement, nosh prétend être capable de convertir les units de systemd, et implémenter un DSL. Ce sont à la fois les points qui m'intéressent, et qui me font peur: j'ai été énormément déçu par systemd (oui, j'ai cru un jour que ce projet serait capable de faire juste ce qu'on lui demande: gérer les services, mais il continue de grossir et entraîne occasionnellement des failles de sécurité, je ne peux accepter ça d'un PID1) et uselessd à abandonné le suivi justement à cause de ce chaos.
D'un autre côté, pouvoir récupérer les config du PID1 à la mode, proposer un DSL qui évite les forks inutiles (bon, ok, il reste à prouver que les autres imposent l'usage de /bin/sh...) liés au shell scripting, et qui ne lance un service que si les préconditions sont remplies, c'est séduisant...
[^] # Re: systemd32.exe
Posté par freem . En réponse au journal [HS] Microsoft ♥ Linux - Episode IV L'attaque des clones. Évalué à 2.
Attention, on confond souvent sysVinit et rc.d. La vraie calamité, dans l'histoire, c'est rc.d, pas sysVinit, même si je trouve quand même que sysVinit en fait trop, notamment les runlevels, qui ne servent en pratique pas à grand chose à mon avis.
Cela dit, vu que sysVinit dispose de fonctionnalités inutiles, je suis également en faveur de le virer.
De mon côté, je cherche des solutions entre-deux.
J'ai adopté runit, mais je tombe au boulot dans certaines de ses limites (quand le fichier run est en exécution, le service est considéré up, alors que si ça se trouve, on essaie juste de vérifier les préconditions... ça se règlerait avec un bête signal à runsv, mais non. De plus, il faut parser la sortie de sv pour savoir si un service devrait tourner... c'est dommage) et je suis tombé récemment sur un outil nommé nosh, qui prétend résoudre certains de ces problèmes.
Accessoirement, nosh prétend être capable de convertir les units de systemd, et implémenter un DSL. Ce sont à la fois les points qui m'intéressent, et qui me font peur: j'ai été énormément déçu par systemd (oui, j'ai cru un jour que ce projet serait capable de faire juste ce qu'on lui demande: gérer les services, mais il continue de grossir et entraîne occasionnellement des failles de sécurité, je ne peux accepter ça d'un PID1) et uselessd à abandonné le suivi justement à cause de ce chaos.
D'un autre côté, pouvoir récupérer les config du PID1 à la mode, proposer un DSL qui évite les forks inutiles (bon, ok, il reste à prouver que les autres imposent l'usage de /bin/sh...) liés au shell scripting, et qui ne lance un service que si les préconditions sont remplies, c'est séduisant...