Bah, l'implémentation d'upstrart est pourrie, et ?
et ça fait 5 ans qu'elle est pourrie. Que dire de plus à part que visiblement, personne n'a revu le truc dans le détail ?
Sinon je peux continuer pour te dire pourquoi le protocole est pourri et pas juste l'implémentation. Prends par exemple un soft comme couchdb en erlang. Comme c'est de l'erlang, il faut lancer via erl avec souvent un script bash qui va mettre divers variables, etc. Du coup, comme un processus ne peut surveiller que son fils, il se passe quoi dans le cas d'un soft comme le dit couchdb qui fait pas forcément un exec à la fin ( ie, le cas très précis de couchdb avec l'option pour relancer automatiquement le soft quand il se gauffre, cf /usr/bin/couchdb ) ?
Soit le script fait le SIGSTOP mais il va faire ça avant que couchdb soit prêt, soit erl le fait, mais personne ne va le surveiller.
On peut tenter le coup aussi avec un soft qui lance 2 softs ( genre miredo-client, qui va se relancer avec moins de priviléges ). Celui qui est surveiller (le premier) est pas celui qui fait le taf (le 2eme).
Et on peut généraliser le cas avec apache, php-fpm. Du coup, le code passe de "je fait raise(sigstop) + un if" à "je mets en place un canal de comm entre le fils et moi pour que le fils me signal son état, et que moi ensuite je fasse un SIGSTOP pour signaler à mon propre père.
Avec le protocole de systemd, on se contente juste de passer la variable et le file descriptor. Le travail est beaucoup plus simple. Et point bonus, tu peux faire plus que juste dire "je suis prêt".
alors toi tu n'as pas du faire beaucoup d'empaquetage de
logiciels.
Je ne suis pas sur qu'il soit sage d'user d'un argument de ce genre sans avoir fait un minimum de vérification et vérifier avant de supposer. ( mais je reconnais que depuis que j'utilise que mon pseudo sur linuxfr, c'est beaucoup plus dur de vérifier qui je suis quand on n'a pas plus de choses pour une recherche google ). mais je te laisse le soin de vérifier quand je te dit que ça doit bien faire 10 ans que je fait des paquets rpms, que j'ai codé sur des softs comme rpmlint, que j'ai participé à divers distros voir forké une distro et bosser sur la mise en place de son systéme de build entre autres choses.
Quand tu fais réellement de l'intégration, ajouter une
dépendance n'est pas du tout anodin.
Si il y a que ça, tu peux aussi prendre les fichiers .c et .h prévu pour ça depuis le code de systemd. Moi, je trouve ça dégeu, mais si upstream insiste à pas rajouter de lien, c'est son code.
Aprés, je dit pas que c'est insurmontable, mais c'est ajouter
des milliers de fois
une charge qui pourrait être évitée (enfin, très réduite) si
systemd l'implémentait.
Encore une fois, il y a 2 logiciels dans tout debian qui supporte le dit protocole. Donc il faudrait :
1) rajouter le dit protocole dans systemd de façon correcte ( ce qui est déjà pas le cas chez upstart )
2) rajouter le support sur les milliers de paquets en question 3) patcher la documentation des milliers de paquets.
Et bien sur, résoudre les cas épineux tels que j'ai énoncé ( et sans trop me forcer )
Ensuite, c'est pas comme si Debian avait déjà fait des milliers de patchs pour tout un tas de trucs ( GFDL et la DGSF, le portage sur le Hurd, le portage pour kfreebsd ). C'est pas comme si les packageurs de Fedora ou d'autres distros doivent régulièrement faire des patchs pour tel nouvelle version de gcc ou tel options de gcc, tel lib qui a été mise à jours et qui changent 2/3 trucs.
Enfin, je continue à dire qu'il n'y a pas vraiment besoin de rajouter de protocole de notification pour la plupart des softs. Il y a plus d’intérêt à faire du on-demand avec les sockets par exemple.
[^] # Re: Mini précision, variable d'environnement
Posté par Misc (site web personnel) . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 10.
et ça fait 5 ans qu'elle est pourrie. Que dire de plus à part que visiblement, personne n'a revu le truc dans le détail ?
Sinon je peux continuer pour te dire pourquoi le protocole est pourri et pas juste l'implémentation. Prends par exemple un soft comme couchdb en erlang. Comme c'est de l'erlang, il faut lancer via erl avec souvent un script bash qui va mettre divers variables, etc. Du coup, comme un processus ne peut surveiller que son fils, il se passe quoi dans le cas d'un soft comme le dit couchdb qui fait pas forcément un exec à la fin ( ie, le cas très précis de couchdb avec l'option pour relancer automatiquement le soft quand il se gauffre, cf /usr/bin/couchdb ) ?
Soit le script fait le SIGSTOP mais il va faire ça avant que couchdb soit prêt, soit erl le fait, mais personne ne va le surveiller.
On peut tenter le coup aussi avec un soft qui lance 2 softs ( genre miredo-client, qui va se relancer avec moins de priviléges ). Celui qui est surveiller (le premier) est pas celui qui fait le taf (le 2eme).
Et on peut généraliser le cas avec apache, php-fpm. Du coup, le code passe de "je fait raise(sigstop) + un if" à "je mets en place un canal de comm entre le fils et moi pour que le fils me signal son état, et que moi ensuite je fasse un SIGSTOP pour signaler à mon propre père.
Avec le protocole de systemd, on se contente juste de passer la variable et le file descriptor. Le travail est beaucoup plus simple. Et point bonus, tu peux faire plus que juste dire "je suis prêt".
Je ne suis pas sur qu'il soit sage d'user d'un argument de ce genre sans avoir fait un minimum de vérification et vérifier avant de supposer. ( mais je reconnais que depuis que j'utilise que mon pseudo sur linuxfr, c'est beaucoup plus dur de vérifier qui je suis quand on n'a pas plus de choses pour une recherche google ). mais je te laisse le soin de vérifier quand je te dit que ça doit bien faire 10 ans que je fait des paquets rpms, que j'ai codé sur des softs comme rpmlint, que j'ai participé à divers distros voir forké une distro et bosser sur la mise en place de son systéme de build entre autres choses.
Si il y a que ça, tu peux aussi prendre les fichiers .c et .h prévu pour ça depuis le code de systemd. Moi, je trouve ça dégeu, mais si upstream insiste à pas rajouter de lien, c'est son code.
Encore une fois, il y a 2 logiciels dans tout debian qui supporte le dit protocole. Donc il faudrait :
1) rajouter le dit protocole dans systemd de façon correcte ( ce qui est déjà pas le cas chez upstart )
2) rajouter le support sur les milliers de paquets en question 3) patcher la documentation des milliers de paquets.
Et bien sur, résoudre les cas épineux tels que j'ai énoncé ( et sans trop me forcer )
Ensuite, c'est pas comme si Debian avait déjà fait des milliers de patchs pour tout un tas de trucs ( GFDL et la DGSF, le portage sur le Hurd, le portage pour kfreebsd ). C'est pas comme si les packageurs de Fedora ou d'autres distros doivent régulièrement faire des patchs pour tel nouvelle version de gcc ou tel options de gcc, tel lib qui a été mise à jours et qui changent 2/3 trucs.
Enfin, je continue à dire qu'il n'y a pas vraiment besoin de rajouter de protocole de notification pour la plupart des softs. Il y a plus d’intérêt à faire du on-demand avec les sockets par exemple.