Re: Debian Fork ?
Le mercredi 22 octobre 2014, 13:06:27 BERTRAND Joël a écrit :
>[…]
> > — parallélisation du boot ;
>
> La question est toujours la même. À quel besoin est-ce que
> ça répond. Le seul que je vois est un démarrage plus rapide en
> complexifiant à mort la gestion du parallélisme (avec tous
> les effets de bord que cela implique).
La bataille contre le boot parallèle est déjà perdue : insserv
le fait (ou essaie de le faire) et est installé par défaut
(comme dépendance de sysv-rc).
Et insserv n’est pas moins compliqué.
>[…]
> > — gestion des dépendances entre scripts d’init ;
>
> Idem. Debian gérait très bien cela avec SysV.
D’abord, Debian _continue_ de gérer ça avec sysV.
Ensuite, « très bien » : haha. C’est une bidouille qui n’est
pas exempte de problèmes.
>[…]
> Le bricolage est indépendant de l'outil.
Certains outils sont plus propices au bricolage.
> D'ailleurs, bizarrement, systemd récupère les scripts dans
> /etc/init.d.
Ça n’est pas « bizarre », ça s’appelle la compatibilité.
>[…]
> > http://wiki.debian.org/systemd
> > http://en.wikipedia.org/wiki/Systemd
> > http://0pointer.de/blog/projects/why.html
>
> Je ne parle pas de cela.
Tu dis avoir cherché des raisons pour systemd. Ces sites
donnent des réponses et des liens vers des réponses.
Si les réponses ne te satisfont pas, c’est un autre problème
mais les buts et justifications de systemd sont étalés un peu
partout.
>[…]
> SVC est moisi parce qu'il embarque une base sql pour gérer
> les daemons, parce qu'il fait un tas de choses dans le dos de
> l'utilisateur et sait mieux que lui ce qui est bon pour lui.
> SVC est pourri parce que les logs sont aussi en partie
> binaire. Bizarrement, SVC me semble la source d'inspiration
> de systemd.
Je ne vois pas de BD dans systemd. (Et les logs en binaire de
systemd sont une option et on peut très bien continuer
d’utiliser un syslogd.)
>[…]
> dbus et propre dans la même phrase, je n'aurais vraiment pas
> osé.
Dbus est plus propre que pas mal de moyens de communication ad
hoc. Il a l’avantage de définir l’interface.
> C'est peut-être de l'éprouvé, mais c'est parfaitement
> inutile sauf si l'on part du principe qu'il faille au moins 1
> Go de mémoire pour démarrer un système.
Comme dit l’adage : « Le coût du matériel décroît rapidement
tandis que le coût de développement du logiciel ne cesse de
croître. » :oP
>[…]
> Et il n'y a aucune raison pour que systemd soit plus
> maintenable que SysV.
Les scripts sysV ne sont pas vraiment maintenables. Chaque
script répète ce que tous les scripts répètent, souvent mal et
de façon non facilement adaptable aux idiosyncrasies des
distributions.
> >> Avec systemd, on mélange allègrement le démarrage du
> >> système
> >> et son fonctionnement une fois démarré, ce qui est un autre
> >> problème. et qui devrait être traité différemment.
> >>
> > N’importe quoi (moi aussi, je peux être péremptoire).
>
> Tu peux, mais il n'empêche que c'est le cas. Tu l'as même
> écrit toi-même un peu plus haut.
Ce qui est « n’importe quoi », c’est que systemd n’aie pas à
s’occuper de la vie des services.
Il les lance, il les termine, il n’est pas illogique qu’il
*puisse* (c’est une option) vérifier qu’ils sont vivants et
qu’il *puisse* les relancer *quand c’est possible* .
Je préfère ça à des solutions ad hoc qui consistent la plupart
en une tâche cron qui cherche un fichier pid et à vérifie que le
processus correspondant existe encore.
>[…]
> Parce qu'on refuse de séparer le démarrage de l'OS et son
> fonctionnement une fois lancé. On en revient toujours à la
> même chose. C'est même très exactement pour cela qu'il y a eu
> un fork de systemd (useless).
Pas vraiment, non. uselessd, c’est le projet d’un gars tout
seul qui pense de GNU est une bande de hippies communistes (ce
qui n’est tout à fait faux ni très important), qui a trouvé que
systemd avait de bonnes idées (notamment la supervision des
processus) et qui veut les mettre en œuvre sur des systèmes non
glibc.
>[…]
--
Sylvain Sauvage
Reply to: