Re: Debian Fork ?
Sylvain L. Sauvage a écrit :
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 ;
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).
— activation à la demande des démons (p.ex. via udev, inotify,
accès socket, demande dbus, timer, etc.) ;
Il n'y a pas besoin d'une telle usine à gaz pour cela.
— gestion des dépendances entre scripts d’init ;
Idem. Debian gérait très bien cela avec SysV.
— suivi des processus via les cgroups ;
Là, je veux bien, mais était-ce utile d'inventer un tel truc pour
régler juste ce point ?
Et tout ça avec des fichiers de configuration courts, simples
et maintenables, pas des usines à gaz shell bricolées à la va-
vite.
Le bricolage est indépendant de l'outil. D'ailleurs, bizarrement,
systemd récupère les scripts dans /etc/init.d. Je m'en suis aperçu parce
que j'ai un script écrit à la va-vite pour monter un routage particulier
qui a été repris tel quel. Systemd n'est donc pas la garantie d'avoir
des scripts propres. Si on veut quelque chose de propre, on s'oriente
vers un système de démarrage à la BSD. Quelques variables dans chaque
script /etc/rc.d et c'est plié.
(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
Je ne parle pas de cela.
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.
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.
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).
dbus et propre dans la même phrase, je n'aurais vraiment pas osé. 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.
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 ?
Il y a longtemps qu'on ne gère plus les ordres de démarrage à la main.
Et il n'y a aucune raison pour que systemd soit plus maintenable que SysV.
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.
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.
Sauf qu'avec init, il y a une séparation des espaces mémoire. Un
segfault quelque part ne fait pas planter init au contraire de ce que
j'ai déjà pu observer avec systemd.
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).
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).
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.
On ne parle vraiment pas de la même chose. Par ailleurs, c'est
casse-gueule. Lorsqu'un daemon fait un segfault au démarrage, il est
juste ridicule de le lancer trois fois de suite et de cracher avec un
beau message d'erreur. Il est plus judicieux d'essayer de démarrer et de
corriger le problème sur un OS quasiment fonctionnel.
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 ?
Je ne t'ai pas attendu. Problème de dépendance dans systemd et bogue
sur les relances des services. J'ajoute que ne pas récupérer un segfault
est assez amusant pour un PID 1.
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.
SysV n'est pas un point unique de plantage.
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…
Oui, et ? La question est de savoir si SysV est plus fiable que Systemd
ou non. Je me contrefiche de savoir si SysV est bon ou mauvais dans
l'absolu. Adopter systemd parce qu'il est nouveau est la pire des
choses. On adopte quelque chose parce qu'elle est meilleure que
l'existant. Aujourd'hui, il n'a pas fait ses preuves. C'est même pour
cela que j'ai voté contre la proposition debian de l'adopter par défaut.
Et j'ai voté contre en toute connaissance de cause.
JKB
Reply to: