Que veut dire «proposé par defaut», est ce que cela sera c omme gnome
par exemple (avec la possibilité d'installer XFCE en 3s et 2 touches
claviers), si c'est le cas, c'est un faux débat...
Que veut dire «proposé par defaut», est ce que cela sera c omme gnome
par exemple (avec la possibilité d'installer XFCE en 3s et 2 touches
claviers), si c'est le cas, c'est un faux débat...
Que veut dire «proposé par defaut», est ce que cela sera c omme gnome
par exemple (avec la possibilité d'installer XFCE en 3s et 2 touches
claviers), si c'est le cas, c'est un faux débat...
’soir,
[Je réponds à ce courrier-ci parce que j’ai déjà effacé les
autres mais c’est une réponse globale.]
Il y en a quelques uns qui se plaignent de systemd.
Il y en a quelques uns qui voudraient que sys-V soit une
alternative viable.
Bizarrement, il y en a beaucoup moins pour faire quelque
chose, comme p.ex. maintenir sys-V (et non, on n’est pas dans le
cas « ne pas réparer ce qui n’est pas en panne », on est dans le
cas « c’est du bricolage qui ne fait pas tout ce qu’on veut »)
ou proposer du code (ou du pognon, en tout cas pas seulement des
jérémiades) pour faire ce que *les* *programmes* (et oui,
pluriel) qui composent systemd proposent (logind, consoled,
udevd, sytemd lui-même, etc.).
Le mardi 21 octobre 2014, 15:10:56 a
écrit :On Tuesday 21 October 2014 14:41:16 Montherlant wrote:
Tiens, il a ressuscité ? ;o)
’soir,
[Je réponds à ce courrier-ci parce que j’ai déjà effacé les
autres mais c’est une réponse globale.]
Il y en a quelques uns qui se plaignent de systemd.
Il y en a quelques uns qui voudraient que sys-V soit une
alternative viable.
Bizarrement, il y en a beaucoup moins pour faire quelque
chose, comme p.ex. maintenir sys-V (et non, on n’est pas dans le
cas « ne pas réparer ce qui n’est pas en panne », on est dans le
cas « c’est du bricolage qui ne fait pas tout ce qu’on veut »)
ou proposer du code (ou du pognon, en tout cas pas seulement des
jérémiades) pour faire ce que *les* *programmes* (et oui,
pluriel) qui composent systemd proposent (logind, consoled,
udevd, sytemd lui-même, etc.).
Le mardi 21 octobre 2014, 15:10:56 andre_debian@numericable.fr a
écrit :
On Tuesday 21 October 2014 14:41:16 Montherlant wrote:
Tiens, il a ressuscité ? ;o)
’soir,
[Je réponds à ce courrier-ci parce que j’ai déjà effacé les
autres mais c’est une réponse globale.]
Il y en a quelques uns qui se plaignent de systemd.
Il y en a quelques uns qui voudraient que sys-V soit une
alternative viable.
Bizarrement, il y en a beaucoup moins pour faire quelque
chose, comme p.ex. maintenir sys-V (et non, on n’est pas dans le
cas « ne pas réparer ce qui n’est pas en panne », on est dans le
cas « c’est du bricolage qui ne fait pas tout ce qu’on veut »)
ou proposer du code (ou du pognon, en tout cas pas seulement des
jérémiades) pour faire ce que *les* *programmes* (et oui,
pluriel) qui composent systemd proposent (logind, consoled,
udevd, sytemd lui-même, etc.).
Le mardi 21 octobre 2014, 15:10:56 a
écrit :On Tuesday 21 October 2014 14:41:16 Montherlant wrote:
Tiens, il a ressuscité ? ;o)
Et pour ceux qui veulent essayer systemd, il est dans _testing_
et _unstable_. Donc, oui, il peut y avoir des bogues, des
problèmes d’intégration, des cas peu courants (v.p.ex.
http://changelog.complete.org/archives/9241-update-on-the-systemd-issue), mais c’est à ça que servent testing et unstable,
non ?
Et pour ceux qui veulent essayer systemd, il est dans _testing_
et _unstable_. Donc, oui, il peut y avoir des bogues, des
problèmes d’intégration, des cas peu courants (v.p.ex.
http://changelog.complete.org/archives/9241-update-on-the-systemd-issue), mais c’est à ça que servent testing et unstable,
non ?
Et pour ceux qui veulent essayer systemd, il est dans _testing_
et _unstable_. Donc, oui, il peut y avoir des bogues, des
problèmes d’intégration, des cas peu courants (v.p.ex.
http://changelog.complete.org/archives/9241-update-on-the-systemd-issue), mais c’est à ça que servent testing et unstable,
non ?
Le nouvel installateur Debian Jessie permet (enfin) de choisir
simplement le bureau en cochant une case dans tasksel.
Avant ce n'était pas si compliqué mais il fallait ajouter desktop=xfce
dans la ligne de commande, c'était moins cool pour un utilisateur de
base et moins visiblement documenté.
Le nouvel installateur Debian Jessie permet (enfin) de choisir
simplement le bureau en cochant une case dans tasksel.
Avant ce n'était pas si compliqué mais il fallait ajouter desktop=xfce
dans la ligne de commande, c'était moins cool pour un utilisateur de
base et moins visiblement documenté.
Le nouvel installateur Debian Jessie permet (enfin) de choisir
simplement le bureau en cochant une case dans tasksel.
Avant ce n'était pas si compliqué mais il fallait ajouter desktop=xfce
dans la ligne de commande, c'était moins cool pour un utilisateur de
base et moins visiblement documenté.
2/ Je ne vois pas à quel besoin répond systemd (sauf à un besoin
irrépressible d'innovation), pourtant, j'ai bien cherché. 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).
3/ Plus je creuse le problème systemd, plus je suis convaincu que c'est
un bloatware et une usine à gaz avec des fuites. J'aimerais bien être
démenti.
4/ Je ne vois pas en quoi un démarrage SysV (ou BSD) ne ferait pas ce
que l'on veut. 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.
5/ [...]
2/ Je ne vois pas à quel besoin répond systemd (sauf à un besoin
irrépressible d'innovation), pourtant, j'ai bien cherché. 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).
3/ Plus je creuse le problème systemd, plus je suis convaincu que c'est
un bloatware et une usine à gaz avec des fuites. J'aimerais bien être
démenti.
4/ Je ne vois pas en quoi un démarrage SysV (ou BSD) ne ferait pas ce
que l'on veut. 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.
5/ [...]
2/ Je ne vois pas à quel besoin répond systemd (sauf à un besoin
irrépressible d'innovation), pourtant, j'ai bien cherché. 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).
3/ Plus je creuse le problème systemd, plus je suis convaincu que c'est
un bloatware et une usine à gaz avec des fuites. J'aimerais bien être
démenti.
4/ Je ne vois pas en quoi un démarrage SysV (ou BSD) ne ferait pas ce
que l'on veut. 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.
5/ [...]
[â¦]
> 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.
2/ Je ne vois pas à quel besoin répond systemd
(sauf à un besoin irrépressible d'innovation), pourtant, j' ai
bien cherché.
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érie l,
ce qui réduit les risques de configuration rigolote et
plantogène).
3/ Plus je creuse le problème systemd, plus je suis convaincu
que c'est un bloatware et une usine à gaz avec des fuites.
J'aimerais bien être démenti.
4/ Je ne vois pas en quoi un démarrage SysV (ou BSD) ne ferait
pas ce que l'on veut.
Avec systemd, on mélange allègrement le démarrage du s ystème
et son fonctionnement une fois démarré, ce qui est un autre
problème. et qui devrait être traité différemment .
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.
Le principe même du SysV évite ce genre de gag.
Mais il est vrai que SysV, c'est has been, plus lent et ça ne
fait pas le café.
[â¦]
> 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.
2/ Je ne vois pas à quel besoin répond systemd
(sauf à un besoin irrépressible d'innovation), pourtant, j' ai
bien cherché.
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érie l,
ce qui réduit les risques de configuration rigolote et
plantogène).
3/ Plus je creuse le problème systemd, plus je suis convaincu
que c'est un bloatware et une usine à gaz avec des fuites.
J'aimerais bien être démenti.
4/ Je ne vois pas en quoi un démarrage SysV (ou BSD) ne ferait
pas ce que l'on veut.
Avec systemd, on mélange allègrement le démarrage du s ystème
et son fonctionnement une fois démarré, ce qui est un autre
problème. et qui devrait être traité différemment .
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.
Le principe même du SysV évite ce genre de gag.
Mais il est vrai que SysV, c'est has been, plus lent et ça ne
fait pas le café.
[â¦]
> 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.
2/ Je ne vois pas à quel besoin répond systemd
(sauf à un besoin irrépressible d'innovation), pourtant, j' ai
bien cherché.
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érie l,
ce qui réduit les risques de configuration rigolote et
plantogène).
3/ Plus je creuse le problème systemd, plus je suis convaincu
que c'est un bloatware et une usine à gaz avec des fuites.
J'aimerais bien être démenti.
4/ Je ne vois pas en quoi un démarrage SysV (ou BSD) ne ferait
pas ce que l'on veut.
Avec systemd, on mélange allègrement le démarrage du s ystème
et son fonctionnement une fois démarré, ce qui est un autre
problème. et qui devrait être traité différemment .
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.
Le principe même du SysV évite ce genre de gag.
Mais il est vrai que SysV, c'est has been, plus lent et ça ne
fait pas le café.
Le Wed, 22 Oct 2014 09:57:39 +0200
BERTRAND Joël a écrit:2/ Je ne vois pas à quel besoin répond systemd (sauf à un besoin
irrépressible d'innovation), pourtant, j'ai bien cherché. 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).
Si j'ai bien compris, avoir un démarrage rapide et surtout non bloqué en cas
de manquement d'un des services.
En se chargeant de la création des sockets
unix (me dire si je dis des c......es, c'est probable), systemd ne bloque pas
les processus en attente d'un service. Ça me permettre à un systèmle de
démarrer même si l'un des services flanchent.
Le Wed, 22 Oct 2014 09:57:39 +0200
BERTRAND Joël <joel.bertrand@systella.fr> a écrit:
2/ Je ne vois pas à quel besoin répond systemd (sauf à un besoin
irrépressible d'innovation), pourtant, j'ai bien cherché. 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).
Si j'ai bien compris, avoir un démarrage rapide et surtout non bloqué en cas
de manquement d'un des services.
En se chargeant de la création des sockets
unix (me dire si je dis des c......es, c'est probable), systemd ne bloque pas
les processus en attente d'un service. Ça me permettre à un systèmle de
démarrer même si l'un des services flanchent.
Le Wed, 22 Oct 2014 09:57:39 +0200
BERTRAND Joël a écrit:2/ Je ne vois pas à quel besoin répond systemd (sauf à un besoin
irrépressible d'innovation), pourtant, j'ai bien cherché. 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).
Si j'ai bien compris, avoir un démarrage rapide et surtout non bloqué en cas
de manquement d'un des services.
En se chargeant de la création des sockets
unix (me dire si je dis des c......es, c'est probable), systemd ne bloque pas
les processus en attente d'un service. Ça me permettre à un systèmle de
démarrer même si l'un des services flanchent.
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.html2/ 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…
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…
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.html2/ 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…
[...] 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é.
[...] 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é.
[...] 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é.
Cher Liste,
On Wed, Oct 22, 2014 at 01:06:27PM +0200, BERTRAND Joël wrote:[...] 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é.
Ben justement... Sous Linux, ce n'est pas facile à trouver :-/
Mes recherches en la matière, à deux reprises à 2-3 ans d'intervalle,
ont échoué (après des détours par quelques projets qui semblaient
prometteurs, mais pas au point ou toujours trop compliqués : upstart,
runit, minit, etc. ) : jamais moyen de trouver un truc simple pour
démarrer le système, à la BSD justement.
Le plus proche que j'ai trouvé sous Debian est file-rc. Je l'utilise
avec plus ou moins de satisfaction selon les machines, mais étant
entendu que l'idéal serait quand même de pouvoir se passer
complètement des « niveaux d'exécution ». (Ici, ce n'est pas le cas ;
c'est juste une autre manière de les configurer.)
Si quelqu'un avait une idée, je serais preneur, bien que j'avais fini
par me dire que ça n'existait pas sous Linux...
Cher Liste,
On Wed, Oct 22, 2014 at 01:06:27PM +0200, BERTRAND Joël wrote:
[...] 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é.
Ben justement... Sous Linux, ce n'est pas facile à trouver :-/
Mes recherches en la matière, à deux reprises à 2-3 ans d'intervalle,
ont échoué (après des détours par quelques projets qui semblaient
prometteurs, mais pas au point ou toujours trop compliqués : upstart,
runit, minit, etc. ) : jamais moyen de trouver un truc simple pour
démarrer le système, à la BSD justement.
Le plus proche que j'ai trouvé sous Debian est file-rc. Je l'utilise
avec plus ou moins de satisfaction selon les machines, mais étant
entendu que l'idéal serait quand même de pouvoir se passer
complètement des « niveaux d'exécution ». (Ici, ce n'est pas le cas ;
c'est juste une autre manière de les configurer.)
Si quelqu'un avait une idée, je serais preneur, bien que j'avais fini
par me dire que ça n'existait pas sous Linux...
Cher Liste,
On Wed, Oct 22, 2014 at 01:06:27PM +0200, BERTRAND Joël wrote:[...] 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é.
Ben justement... Sous Linux, ce n'est pas facile à trouver :-/
Mes recherches en la matière, à deux reprises à 2-3 ans d'intervalle,
ont échoué (après des détours par quelques projets qui semblaient
prometteurs, mais pas au point ou toujours trop compliqués : upstart,
runit, minit, etc. ) : jamais moyen de trouver un truc simple pour
démarrer le système, à la BSD justement.
Le plus proche que j'ai trouvé sous Debian est file-rc. Je l'utilise
avec plus ou moins de satisfaction selon les machines, mais étant
entendu que l'idéal serait quand même de pouvoir se passer
complètement des « niveaux d'exécution ». (Ici, ce n'est pas le cas ;
c'est juste une autre manière de les configurer.)
Si quelqu'un avait une idée, je serais preneur, bien que j'avais fini
par me dire que ça n'existait pas sous Linux...
