Re: Debian Fork ?
Le mercredi 22 octobre 2014, 09:57:39 BERTRAND Joël a écrit :
>[…]
> > Bizarrement, il y en a beaucoup moins pour faire quelque
> > chose[…]
>
> 1/ Si la remarque est censée être pour moi, je pense que je
> donne déjà assez de temps aux logiciels libres pour ne pas
> encore me coltiner systemd.
Pas particulièrement (susceptible ?). Je pense surtout à ceux
qui font du bruit au sein de Debian (GR en cours), à ceux qui
sont à l’origine du site, lui-même à l’origine du fil, et de
tous les commentaires non-informés (autrement appelés trolls)
qui fleurissent à chaque fois qu’il est question de systemd.
Personnellement, je ne suis pas un zélote de systemd (cf [1]
et le fil autour), encore moins de Poettering, mais les trolls
et les réponses automatiques « j’ai jamais installé systemd,
j’ai à peine lu ta question mais c’est sûrement la faute à
systemd » à chaque fois qu’il y a un truc qui plante, ça m’agace
un peu.
[1] https://lists.debian.org/debian-user-french/2014/04/msg00049.html
> 2/ Je ne vois pas à quel besoin répond systemd
Au hasard et sans ordre d’importance :
— parallélisation du boot ;
— activation à la demande des démons (p.ex. via udev, inotify,
accès socket, demande dbus, timer, etc.) ;
— gestion des dépendances entre scripts d’init ;
— suivi des processus via les cgroups ;
Et tout ça avec des fichiers de configuration courts, simples
et maintenables, pas des usines à gaz shell bricolées à la va-
vite.
> (sauf à un besoin irrépressible d'innovation), pourtant, j'ai
> bien cherché.
Bizarre, moi je trouve tout de suite :
http://wiki.debian.org/systemd
http://en.wikipedia.org/wiki/Systemd
http://0pointer.de/blog/projects/why.html
> Systemd serait plutôt une régression dans l'évolution (un peu
> comme svc sous Solaris pour exactement les mêmes raisons, sauf
> que Sun^WOracle maîtrise a priori le logiciel et le matériel,
> ce qui réduit les risques de configuration rigolote et
> plantogène).
Et comme tout le monde connaît forcément les raisons pour
lesquelles « svc sous Solaris » est tout pourri, il suffit juste
de dire « c’est tout pareil » pour que tout le monde comprenne
ce que tu reproches réellement à systemd.
> 3/ Plus je creuse le problème systemd, plus je suis convaincu
> que c'est un bloatware et une usine à gaz avec des fuites.
Il ne faut pas confondre systemd-le-système-d’init et systemd
+ logind + networkd + journald + consoled + … qui est un
ensemble de programmes. Chaque composant peut être remplacé (ok,
c’est peu probable, comme dans toutes les piles de
programmes/modules, mais étant donné que les interfaces sont
plutôt propres (D-bus), c’est vraiment faisable).
> J'aimerais bien être démenti.
Il me semble que tu inverses la nécessité de la preuve. Et
« je suis convaincu que » n’est pas un argument de culpabilité.
> 4/ Je ne vois pas en quoi un démarrage SysV (ou BSD) ne ferait
> pas ce que l'on veut.
Parce que les scripts SysV sont propres et maintenables ?
Parce que la gestion des dépendances via un programme qui lit un
ensemble de commentaires au début de chaque script, c’est propre
et maintenable ? Parce que gérer l’ordre de démarrage
complètement à la main, c’est propre et maintenable ?
> 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).
Init gère aussi la terminaison des services. (Ça n’a rien à
voir avec le fonctionnement du système une fois démarré, ça ?)
De plus, init est le parent de tous les processus. Il est donc
finalement responsable de leur bonne terminaison.
Init lance les services pour une raison. Avec sysV, la seule
raison est l’entrée dans un niveau d’init. Avec systemd, on a la
possibilité de lancer des services pour de multiples raisons
(cf. plus haut).
Donc, vu qu’il gère le lancement et la terminaison des
services, vu qu’il est le processus parent, je ne vois pas
pourquoi être responsable de relancer un service tombé
maladroitement lorsque c’est possible serait un mélange des
genres.
> 5/ J'ai adoré systemd qui m'a fait un core directement sur un
> serveur pourtant amd64 et tout à fait classique pas plus tard
> que la semaine passée. Heureusement que j'étais sur place,
> parce la seule façon de s'en sortir a été de coller un
> init=/bin/sh au noyau.
Et donc, étant en testing ou unstable, tu as fait un rapport
de bogue et essayé de creuser pour savoir si c’était systemd ou
un script init mal écrit ?
> Le principe même du SysV évite ce genre de gag.
Quel gag ?
Avoir un script init mal écrit qui fait planter le système, je
t’assure que c’est tout à fait possible avec sysV.
> Mais il est vrai que SysV, c'est has been, plus lent et ça ne
> fait pas le café.
« Réparer » ou améliorer l’init (et donc sysV) n’a pas
commencé avec systemd : upstart, openrc, insserv…
--
Sylvain Sauvage
Reply to: