En l’occurrence, dans le cas de pulseaudio, je vois pas en quoi ça impacte les sysadmins. Si le souci est de devoir revalider, je pense que le sysadmin 1) fait soit déjà le taf pour tout le reste de la stack qui bouge ( surtout le kernel ) 2) fait soit faire ça par un fabricant ( Novell, Red hat, etc ).
Ensuite, non, le système d'init basé sur des scripts shells est sous optimal :
- soft à la con qui gére mal le concept ( genre bind, qu'il faut éteindre de façon asynchrone avec un outil en cli, genre apache avec des process forkés qui sont pas toujours tués, voir non géré dans le cas de cgi ). L'usage des cgroups permet de tuer proprement tout ça.
aucun foutu standard pour les scripts d'init, donc le code est dupliqué à qui mieux mieux
ce qui implique aucune API haut niveau potable pour connaitre l'etat d'un process ( et je parle pas des erreurs subtiles liés à par exemple la gestion des fichiers de pid ). Systemd gére ça via une API dbus, ce qui permet d'avoir une véritable sémantique plus propice à l'automatisation et sans faire X forks/exec.
des problémes de maintenances à la con dés que tu veux toucher à un script d'init, vu que c'est pas de la config, mais traité comme tel par certain ssysadmins. Systemd permet l'utilisation de template propre, et d'utiliser 2 fichiers, un pour les modifs, un pour la distrib.
Le reste ( limitation d'io, du cpu, montage de chroot/namespace privé ), c'est bonus. Mais pour moi, le systéme d'init à base de script était fondamentalement moisi du point de vue d'une distribution et d'un sysadmin. C'est pour rien que Gentoo a refait un truc à sa sauce, que Solaris et Apple ont pris cette voie, et que Ubuntu a commencé à bosser sur upstart. Le script de démarrage d'une distro basé sur RH/sysV est quand même un monstre en shell, bloated et qui fait le café, et c'est faire preuve d'un mauvais gout que de vouloir garder ça.
Debian a un repertoire /etc/rcS.d/ ce qui permet d'avoir moins de souci, mais qui ne règle pas les autres points ( vu que update-rc.d ou chkconfig, c'est kifkif ).
[^] # Re: Syndrome de la compatibilité ascendante
Posté par Misc (site web personnel) . En réponse au journal Que faut-il penser de Lennart qui casse tout ?. Évalué à 7.
En l’occurrence, dans le cas de pulseaudio, je vois pas en quoi ça impacte les sysadmins. Si le souci est de devoir revalider, je pense que le sysadmin 1) fait soit déjà le taf pour tout le reste de la stack qui bouge ( surtout le kernel ) 2) fait soit faire ça par un fabricant ( Novell, Red hat, etc ).
Ensuite, non, le système d'init basé sur des scripts shells est sous optimal :
- soft à la con qui gére mal le concept ( genre bind, qu'il faut éteindre de façon asynchrone avec un outil en cli, genre apache avec des process forkés qui sont pas toujours tués, voir non géré dans le cas de cgi ). L'usage des cgroups permet de tuer proprement tout ça.
aucun foutu standard pour les scripts d'init, donc le code est dupliqué à qui mieux mieux
ce qui implique aucune API haut niveau potable pour connaitre l'etat d'un process ( et je parle pas des erreurs subtiles liés à par exemple la gestion des fichiers de pid ). Systemd gére ça via une API dbus, ce qui permet d'avoir une véritable sémantique plus propice à l'automatisation et sans faire X forks/exec.
des problémes de maintenances à la con dés que tu veux toucher à un script d'init, vu que c'est pas de la config, mais traité comme tel par certain ssysadmins. Systemd permet l'utilisation de template propre, et d'utiliser 2 fichiers, un pour les modifs, un pour la distrib.
Le reste ( limitation d'io, du cpu, montage de chroot/namespace privé ), c'est bonus. Mais pour moi, le systéme d'init à base de script était fondamentalement moisi du point de vue d'une distribution et d'un sysadmin. C'est pour rien que Gentoo a refait un truc à sa sauce, que Solaris et Apple ont pris cette voie, et que Ubuntu a commencé à bosser sur upstart. Le script de démarrage d'une distro basé sur RH/sysV est quand même un monstre en shell, bloated et qui fait le café, et c'est faire preuve d'un mauvais gout que de vouloir garder ça.
Debian a un repertoire /etc/rcS.d/ ce qui permet d'avoir moins de souci, mais qui ne règle pas les autres points ( vu que update-rc.d ou chkconfig, c'est kifkif ).