Je doute que systemd soit écrit comme un goret, ta vision de l'usage des assertions est loin d'être universelle, et beaucoup de monde considère que la présence d'assertions est justement la marque d'un logiciel réfléchis. Tout le fonctionnement d'ADA beaucoup utilisé dans les systèmes critiques est justement basé sur des assertions.
Dans le cas du logiciel en général, et tout particulièrement dans le cas d'init, on souhaite premièrement avoir un logiciel sans bug. C'est cette qualité entre autre qui fait le succès du kernel Linux (dans lequel il y a des assertions). Et la chasse aux bugs se fait bien plus facilement en remontant les anomalies au plus tôt et en validant les données par des contraintes plutôt que de les utiliser naïvement en espérant que ça passera. Une anomalie non traitée va très certainement provoquer d'autres problèmes un peu plus loin, qui vont être plus compliqués à diagnostiquer et à traiter.
La tolérance aux bugs est un autre point qui concerne tout particulièrement init comme tu l'indiques. Comme il est a mon avis impossible de traiter tous les cas tordus qui risquent de se produire, et qui ne sont pas forcément liés à des bugs de l'exécutable, il serait préférable d'avoir un mécanisme capable de reprendre en cas d'erreur, par exemple en re-lançant le programme a son point de départ ou à un point connu. Ces mécanismes sont déjà utilisés dans un certain nombre de logiciels tel que bind, apache, syslog-ng... Ils ne corrigent pas magiquement tous les bugs et les erreurs, mais permettent juste d'assurer la continuité de service.
[^] # Re: gn
Posté par Sébastien Koechlin . En réponse au journal systemd est un "bloat". Évalué à 10.
Je doute que systemd soit écrit comme un goret, ta vision de l'usage des assertions est loin d'être universelle, et beaucoup de monde considère que la présence d'assertions est justement la marque d'un logiciel réfléchis. Tout le fonctionnement d'ADA beaucoup utilisé dans les systèmes critiques est justement basé sur des assertions.
Dans le cas du logiciel en général, et tout particulièrement dans le cas d'init, on souhaite premièrement avoir un logiciel sans bug. C'est cette qualité entre autre qui fait le succès du kernel Linux (dans lequel il y a des assertions). Et la chasse aux bugs se fait bien plus facilement en remontant les anomalies au plus tôt et en validant les données par des contraintes plutôt que de les utiliser naïvement en espérant que ça passera. Une anomalie non traitée va très certainement provoquer d'autres problèmes un peu plus loin, qui vont être plus compliqués à diagnostiquer et à traiter.
La tolérance aux bugs est un autre point qui concerne tout particulièrement init comme tu l'indiques. Comme il est a mon avis impossible de traiter tous les cas tordus qui risquent de se produire, et qui ne sont pas forcément liés à des bugs de l'exécutable, il serait préférable d'avoir un mécanisme capable de reprendre en cas d'erreur, par exemple en re-lançant le programme a son point de départ ou à un point connu. Ces mécanismes sont déjà utilisés dans un certain nombre de logiciels tel que bind, apache, syslog-ng... Ils ne corrigent pas magiquement tous les bugs et les erreurs, mais permettent juste d'assurer la continuité de service.