Stéphane CARPENTIER , dans le message
, a écrit :
C'est un autre débat, mais tu as raison, c'est quelque chose dont il
faut parler.
Stéphane CARPENTIER , dans le message
<slrnrdc91b.2ip.sc@scarpet42p.localdomain>, a écrit :
C'est un autre débat, mais tu as raison, c'est quelque chose dont il
faut parler.
Stéphane CARPENTIER , dans le message
, a écrit :
C'est un autre débat, mais tu as raison, c'est quelque chose dont il
faut parler.
Le 02/06/2020 à 13:02, Stéphane CARPENTIER a écrit :La question est surtout de savoir si j'aurai besoin de basculer de
moi-même en avance de phase ou si la migration sera faite avant que
j'en ai besoin. En supposant que j'en ai besoin, car ils peuvent
aussi améliorer systemd.
En attendant que la foule suive, "ils" ont aussi besoin des rapports
de bugs.
Le 02/06/2020 à 13:02, Stéphane CARPENTIER a écrit :
La question est surtout de savoir si j'aurai besoin de basculer de
moi-même en avance de phase ou si la migration sera faite avant que
j'en ai besoin. En supposant que j'en ai besoin, car ils peuvent
aussi améliorer systemd.
En attendant que la foule suive, "ils" ont aussi besoin des rapports
de bugs.
Le 02/06/2020 à 13:02, Stéphane CARPENTIER a écrit :La question est surtout de savoir si j'aurai besoin de basculer de
moi-même en avance de phase ou si la migration sera faite avant que
j'en ai besoin. En supposant que j'en ai besoin, car ils peuvent
aussi améliorer systemd.
En attendant que la foule suive, "ils" ont aussi besoin des rapports
de bugs.
Toutefois, j'ai lu qu'un des principaux développeurs de Arch travaille
chez IBM Redhat, chez qui œuvre aussi l'inventeur de systemd.
D'abord, Archlinux est une distribution à la fois minimale et bleeding
edge, ce que n'est vraiment pas Red Hat. Le gestionnaire de paquet n'a
rien à voir non plus. Les motivations ne sont vraiment pas les mêmes et
ça me surprendrait qu'il se focalise juste sur systemd pour
homogénéisation alors que tout le reste est différent.
Toutefois, j'ai lu qu'un des principaux développeurs de Arch travaille
chez IBM Redhat, chez qui œuvre aussi l'inventeur de systemd.
D'abord, Archlinux est une distribution à la fois minimale et bleeding
edge, ce que n'est vraiment pas Red Hat. Le gestionnaire de paquet n'a
rien à voir non plus. Les motivations ne sont vraiment pas les mêmes et
ça me surprendrait qu'il se focalise juste sur systemd pour
homogénéisation alors que tout le reste est différent.
Toutefois, j'ai lu qu'un des principaux développeurs de Arch travaille
chez IBM Redhat, chez qui œuvre aussi l'inventeur de systemd.
D'abord, Archlinux est une distribution à la fois minimale et bleeding
edge, ce que n'est vraiment pas Red Hat. Le gestionnaire de paquet n'a
rien à voir non plus. Les motivations ne sont vraiment pas les mêmes et
ça me surprendrait qu'il se focalise juste sur systemd pour
homogénéisation alors que tout le reste est différent.
De mémoire, Archlinux est passée à systemd parce que c'est le truc que
tout le monde utilisait et que pour un certain nombre de services les
mainteneurs d'Arch allait devoir commencer à maintenir eux-mêmes les
scripts à l'ancienne.
De mémoire, Archlinux est passée à systemd parce que c'est le truc que
tout le monde utilisait et que pour un certain nombre de services les
mainteneurs d'Arch allait devoir commencer à maintenir eux-mêmes les
scripts à l'ancienne.
De mémoire, Archlinux est passée à systemd parce que c'est le truc que
tout le monde utilisait et que pour un certain nombre de services les
mainteneurs d'Arch allait devoir commencer à maintenir eux-mêmes les
scripts à l'ancienne.
Autant les guerres contre Microsoft, Apple, Android, Google, Facebook,
Amazon et Uber (entre autres), j'ai vu plein d'arguments sérieux. Autant
la guerre contre systemd je n'ai rien vu.
Autant les guerres contre Microsoft, Apple, Android, Google, Facebook,
Amazon et Uber (entre autres), j'ai vu plein d'arguments sérieux. Autant
la guerre contre systemd je n'ai rien vu.
Autant les guerres contre Microsoft, Apple, Android, Google, Facebook,
Amazon et Uber (entre autres), j'ai vu plein d'arguments sérieux. Autant
la guerre contre systemd je n'ai rien vu.
Yliur , dans le message <rb6tbe$5dc$, a écrit :De mémoire, Archlinux est passée à systemd parce que c'est le truc que
tout le monde utilisait et que pour un certain nombre de services les
mainteneurs d'Arch allait devoir commencer à maintenir eux-mêmes les
scripts à l'ancienne.
Ça ne me semble pas très crédible. C'est de toutes façons le rôle d'une
distribution de faire l'infrastructure de lancement des services.
Yliur , dans le message <rb6tbe$5dc$1@dont-email.me>, a écrit :
De mémoire, Archlinux est passée à systemd parce que c'est le truc que
tout le monde utilisait et que pour un certain nombre de services les
mainteneurs d'Arch allait devoir commencer à maintenir eux-mêmes les
scripts à l'ancienne.
Ça ne me semble pas très crédible. C'est de toutes façons le rôle d'une
distribution de faire l'infrastructure de lancement des services.
Yliur , dans le message <rb6tbe$5dc$, a écrit :De mémoire, Archlinux est passée à systemd parce que c'est le truc que
tout le monde utilisait et que pour un certain nombre de services les
mainteneurs d'Arch allait devoir commencer à maintenir eux-mêmes les
scripts à l'ancienne.
Ça ne me semble pas très crédible. C'est de toutes façons le rôle d'une
distribution de faire l'infrastructure de lancement des services.
Le message en question :
https://bbs.archlinux.org/viewtopic.php?pid49530#p1149530
La page de wiki (pour la source) :
https://wiki.archlinux.org/index.php/Systemd
Le message en question :
https://bbs.archlinux.org/viewtopic.php?pid49530#p1149530
La page de wiki (pour la source) :
https://wiki.archlinux.org/index.php/Systemd
Le message en question :
https://bbs.archlinux.org/viewtopic.php?pid49530#p1149530
La page de wiki (pour la source) :
https://wiki.archlinux.org/index.php/Systemd
Le 04-06-2020, Yliur a écrit :Le message en question :
https://bbs.archlinux.org/viewtopic.php?pid49530#p1149530
Ah, ben non. Moi qui voulait détester systemd, tu vas finir par faire de
moi un défenseur.
Ce qui confirme ce que j'imaginais, c'est que les raisons d'avoir migré
sont un peu plus sérieuses que pour faire comme tout le monde.
Ce qui confirme aussi ce que j'imaginais, c'est que certains trucs me
perturbaient parce que je ne me suis pas plongé dans la doc. Il y a plus
de trucs intéressants que ce que j'avais remarqué.
Je comprends aussi pourquoi les machines sous-dimensionnées de JKB ont
du mal à démarrer.
Mais d'un autre côté, devoir attendre deux minutes
qu'un périphérique non vital soit reconnu sur ma machine pour pourvoir
l'utiliser parce que sinon, les serveurs qui ont 40 ans ne démarrent pas
me gêne.
Alors, OK, systemd est orienté desktop et pas serveur. Ça tome
bien bien, Archlinux est orienté desktop et j'ai un desktop.
En tous cas, ça me confirme qu'avant d'accepter que tout est mieux que
systemd, il me faudra des explications sur le pourquoi et pas sur le
quoi :
"I think there might be this other project that possibly is doing
something similar. I don't really know anything about it, but I'm pretty
sure it is better than systemd"La page de wiki (pour la source) :
https://wiki.archlinux.org/index.php/Systemd
Le problème de cette page en particulier, comme de ce wiki en général,
c'est que c'est plus une liste de recettes qu'une doc. Si tu connais
systemd, c'est très bien. Si tu découvres systemd en arrivant sur
archlinux, tu fais des devinettes en espérant que ça marche. Ils
t'expliquent comment faire, mais pas pourquoi. Et se plonger dans la doc
de systemd au moment de l'installation d'un OS est quand même très
contraignant.
Le 04-06-2020, Yliur <yliur@free.fr> a écrit :
Le message en question :
https://bbs.archlinux.org/viewtopic.php?pid49530#p1149530
Ah, ben non. Moi qui voulait détester systemd, tu vas finir par faire de
moi un défenseur.
Ce qui confirme ce que j'imaginais, c'est que les raisons d'avoir migré
sont un peu plus sérieuses que pour faire comme tout le monde.
Ce qui confirme aussi ce que j'imaginais, c'est que certains trucs me
perturbaient parce que je ne me suis pas plongé dans la doc. Il y a plus
de trucs intéressants que ce que j'avais remarqué.
Je comprends aussi pourquoi les machines sous-dimensionnées de JKB ont
du mal à démarrer.
Mais d'un autre côté, devoir attendre deux minutes
qu'un périphérique non vital soit reconnu sur ma machine pour pourvoir
l'utiliser parce que sinon, les serveurs qui ont 40 ans ne démarrent pas
me gêne.
Alors, OK, systemd est orienté desktop et pas serveur. Ça tome
bien bien, Archlinux est orienté desktop et j'ai un desktop.
En tous cas, ça me confirme qu'avant d'accepter que tout est mieux que
systemd, il me faudra des explications sur le pourquoi et pas sur le
quoi :
"I think there might be this other project that possibly is doing
something similar. I don't really know anything about it, but I'm pretty
sure it is better than systemd"
La page de wiki (pour la source) :
https://wiki.archlinux.org/index.php/Systemd
Le problème de cette page en particulier, comme de ce wiki en général,
c'est que c'est plus une liste de recettes qu'une doc. Si tu connais
systemd, c'est très bien. Si tu découvres systemd en arrivant sur
archlinux, tu fais des devinettes en espérant que ça marche. Ils
t'expliquent comment faire, mais pas pourquoi. Et se plonger dans la doc
de systemd au moment de l'installation d'un OS est quand même très
contraignant.
Le 04-06-2020, Yliur a écrit :Le message en question :
https://bbs.archlinux.org/viewtopic.php?pid49530#p1149530
Ah, ben non. Moi qui voulait détester systemd, tu vas finir par faire de
moi un défenseur.
Ce qui confirme ce que j'imaginais, c'est que les raisons d'avoir migré
sont un peu plus sérieuses que pour faire comme tout le monde.
Ce qui confirme aussi ce que j'imaginais, c'est que certains trucs me
perturbaient parce que je ne me suis pas plongé dans la doc. Il y a plus
de trucs intéressants que ce que j'avais remarqué.
Je comprends aussi pourquoi les machines sous-dimensionnées de JKB ont
du mal à démarrer.
Mais d'un autre côté, devoir attendre deux minutes
qu'un périphérique non vital soit reconnu sur ma machine pour pourvoir
l'utiliser parce que sinon, les serveurs qui ont 40 ans ne démarrent pas
me gêne.
Alors, OK, systemd est orienté desktop et pas serveur. Ça tome
bien bien, Archlinux est orienté desktop et j'ai un desktop.
En tous cas, ça me confirme qu'avant d'accepter que tout est mieux que
systemd, il me faudra des explications sur le pourquoi et pas sur le
quoi :
"I think there might be this other project that possibly is doing
something similar. I don't really know anything about it, but I'm pretty
sure it is better than systemd"La page de wiki (pour la source) :
https://wiki.archlinux.org/index.php/Systemd
Le problème de cette page en particulier, comme de ce wiki en général,
c'est que c'est plus une liste de recettes qu'une doc. Si tu connais
systemd, c'est très bien. Si tu découvres systemd en arrivant sur
archlinux, tu fais des devinettes en espérant que ça marche. Ils
t'expliquent comment faire, mais pas pourquoi. Et se plonger dans la doc
de systemd au moment de l'installation d'un OS est quand même très
contraignant.
Le 05 Jun 2020 10:21:44 GMT,
Stéphane CARPENTIER écrivait :Je comprends aussi pourquoi les machines sous-dimensionnées de JKB ont
du mal à démarrer.
Dans l'embarqué, tu ne te trimballes pas 4 Go de mémoire pour te
faire plaisir. Je ne vois pas en quoi avoir seulement 512 Mo de
mémoire est sous-dimensionné pour l'immense majorité des cas.
Par ailleurs, certains problèmes de systemd seraient acceptables si,
par exemple, on pouvait simplement lui demander de ne pas essayer de
tout lancer en parallèle.
Sauf erreur de je n'ai pas trouvé dans la doc un drapeau de
configuration permettant de dire à systemd "merci de ne pas forker
comme un goret et d'être gentil en lançant tout séquentiellement".
Mais d'un autre côté, devoir attendre deux minutes
qu'un périphérique non vital soit reconnu sur ma machine pour pourvoir
l'utiliser parce que sinon, les serveurs qui ont 40 ans ne démarrent pas
me gêne.
Ce qui me dérange plus, c'est l'attente infinie sur certains
périphériques non critiques.
Ou le simple fait que l'ordonnanceur ne soit pas fiable : ce qui
fonctionnait avec telle version de systemd est fichu de ne plus se
lancer dans le même ordre avec la version suivante.
Alors il est vrai que c'est sur des trucs comme des
disques iSCSI ou des choses bizarres qu'on ne retrouvera pas chez
madame Michu (enfin, normalement), mais lorsque tu redémarres une
machine, tu aimes bien que ça se comporte de manière prévisible
d'une version à l'autre. Avec systemd, ce n'est pas le cas. Ça
ressemble vraiment au démarrage de type Windows avec en plus un
petit air d'advienne que pourra.
Un autre truc m'énerve au plus haut point. Lorsqu'on choisit un
système de démarrage, on s'y tient ! Avec systemd, dans certains
cas, on ne sait plus ce qui démarre avec une compatibilité SysV en
réécrivant à la volée des modules systemd, ce qui démarre en vrai
SysV, ce qui est lancé depuis /lib/systemd/system ou /etc/systemd
voire /lib/systemd/user et /etc/systemd/user... Lorsque tu as à la
fois un module systemd et un script SysV, tu as intérêt de chercher
attentivement ce que systemd fera parce que là encore, d'une
versionà une autre, il ne se comporte pas forcément de la même
manière. J'ai pensé naïvement qu'il utilisait toujours en priorité
ses modules. Raté, ce n'est pas toujorus vrai (je n'ai pas cherché à
savoir si c'était un bug ou une fonctionnalité).
C'est un merdier sans nom d'autant plus que je suis tombé sur une
bizarrerie d'un paquet debian qui modifie /lib/systemd/system et...
qui est réécrasé à la prochaine mise à jour de systemd.
Pourquoi est-ce que les devs de systemd n'ont pas tout mis au même endroit
en retirant /etc/init.d de l'équation ?
Mais le résultat est qu'on a un truc qui explose en vol plus souvent
qu'à son tour.
Il y a aussi un truc étrange depuis quelques semaines. Lorsque mon
poste de travail (diskless avec swap en iSCSI) se met à swapper un
peu trop, systemd me ferme ma session graphique. C'est très gentil
de sa part et très pratique. Je suppose qu'il y a maintenant dans le
bouzin un genre de watchdog.
Dernière chose, et non des moindres. Les mises à jour de systemd
sont problématiques parce une nouvelle version de la chose prend
place sur une machine utilisant déjà systemd comme init (pid 1). Et
là, le redémarrage peut être problématique avec des processus
d'extinction qui ne finissent JAMAIS (attente infinie sur... rien
parce que la version du binaire a changé !).
En fait, avec systemd, on est arrivé à un état problématique. Plus
exactement, il est désespérant de voir que ce que les développeurs
de Linux il y a 20 ans reprochaient à Windows se retrouve tel quel
avec les mêmes inconvénients dans Linux.
Le problème de cette page en particulier, comme de ce wiki en
général, c'est que c'est plus une liste de recettes qu'une doc. Si tu
connais systemd, c'est très bien. Si tu découvres systemd en arrivant
sur archlinux, tu fais des devinettes en espérant que ça marche. Ils
t'expliquent comment faire, mais pas pourquoi. Et se plonger dans la
doc de systemd au moment de l'installation d'un OS est quand même
très contraignant.
Après aussi, remarque bien.
Systemd est piégeux, son développement n'a visiblement pas été plus
ou pas été mieux pensé que celui de PL/1. Nouveau besoin, nouveau
patch et, à la fin, on a une usine à gaz avec des fuites qui marche
dans 95% des cas. Tant pis pour toi si tu es dans les 5% restants.
Le 05 Jun 2020 10:21:44 GMT,
Stéphane CARPENTIER <sc@fiat-linux.fr> écrivait :
Je comprends aussi pourquoi les machines sous-dimensionnées de JKB ont
du mal à démarrer.
Dans l'embarqué, tu ne te trimballes pas 4 Go de mémoire pour te
faire plaisir. Je ne vois pas en quoi avoir seulement 512 Mo de
mémoire est sous-dimensionné pour l'immense majorité des cas.
Par ailleurs, certains problèmes de systemd seraient acceptables si,
par exemple, on pouvait simplement lui demander de ne pas essayer de
tout lancer en parallèle.
Sauf erreur de je n'ai pas trouvé dans la doc un drapeau de
configuration permettant de dire à systemd "merci de ne pas forker
comme un goret et d'être gentil en lançant tout séquentiellement".
Mais d'un autre côté, devoir attendre deux minutes
qu'un périphérique non vital soit reconnu sur ma machine pour pourvoir
l'utiliser parce que sinon, les serveurs qui ont 40 ans ne démarrent pas
me gêne.
Ce qui me dérange plus, c'est l'attente infinie sur certains
périphériques non critiques.
Ou le simple fait que l'ordonnanceur ne soit pas fiable : ce qui
fonctionnait avec telle version de systemd est fichu de ne plus se
lancer dans le même ordre avec la version suivante.
Alors il est vrai que c'est sur des trucs comme des
disques iSCSI ou des choses bizarres qu'on ne retrouvera pas chez
madame Michu (enfin, normalement), mais lorsque tu redémarres une
machine, tu aimes bien que ça se comporte de manière prévisible
d'une version à l'autre. Avec systemd, ce n'est pas le cas. Ça
ressemble vraiment au démarrage de type Windows avec en plus un
petit air d'advienne que pourra.
Un autre truc m'énerve au plus haut point. Lorsqu'on choisit un
système de démarrage, on s'y tient ! Avec systemd, dans certains
cas, on ne sait plus ce qui démarre avec une compatibilité SysV en
réécrivant à la volée des modules systemd, ce qui démarre en vrai
SysV, ce qui est lancé depuis /lib/systemd/system ou /etc/systemd
voire /lib/systemd/user et /etc/systemd/user... Lorsque tu as à la
fois un module systemd et un script SysV, tu as intérêt de chercher
attentivement ce que systemd fera parce que là encore, d'une
versionà une autre, il ne se comporte pas forcément de la même
manière. J'ai pensé naïvement qu'il utilisait toujours en priorité
ses modules. Raté, ce n'est pas toujorus vrai (je n'ai pas cherché à
savoir si c'était un bug ou une fonctionnalité).
C'est un merdier sans nom d'autant plus que je suis tombé sur une
bizarrerie d'un paquet debian qui modifie /lib/systemd/system et...
qui est réécrasé à la prochaine mise à jour de systemd.
Pourquoi est-ce que les devs de systemd n'ont pas tout mis au même endroit
en retirant /etc/init.d de l'équation ?
Mais le résultat est qu'on a un truc qui explose en vol plus souvent
qu'à son tour.
Il y a aussi un truc étrange depuis quelques semaines. Lorsque mon
poste de travail (diskless avec swap en iSCSI) se met à swapper un
peu trop, systemd me ferme ma session graphique. C'est très gentil
de sa part et très pratique. Je suppose qu'il y a maintenant dans le
bouzin un genre de watchdog.
Dernière chose, et non des moindres. Les mises à jour de systemd
sont problématiques parce une nouvelle version de la chose prend
place sur une machine utilisant déjà systemd comme init (pid 1). Et
là, le redémarrage peut être problématique avec des processus
d'extinction qui ne finissent JAMAIS (attente infinie sur... rien
parce que la version du binaire a changé !).
En fait, avec systemd, on est arrivé à un état problématique. Plus
exactement, il est désespérant de voir que ce que les développeurs
de Linux il y a 20 ans reprochaient à Windows se retrouve tel quel
avec les mêmes inconvénients dans Linux.
Le problème de cette page en particulier, comme de ce wiki en
général, c'est que c'est plus une liste de recettes qu'une doc. Si tu
connais systemd, c'est très bien. Si tu découvres systemd en arrivant
sur archlinux, tu fais des devinettes en espérant que ça marche. Ils
t'expliquent comment faire, mais pas pourquoi. Et se plonger dans la
doc de systemd au moment de l'installation d'un OS est quand même
très contraignant.
Après aussi, remarque bien.
Systemd est piégeux, son développement n'a visiblement pas été plus
ou pas été mieux pensé que celui de PL/1. Nouveau besoin, nouveau
patch et, à la fin, on a une usine à gaz avec des fuites qui marche
dans 95% des cas. Tant pis pour toi si tu es dans les 5% restants.
Le 05 Jun 2020 10:21:44 GMT,
Stéphane CARPENTIER écrivait :Je comprends aussi pourquoi les machines sous-dimensionnées de JKB ont
du mal à démarrer.
Dans l'embarqué, tu ne te trimballes pas 4 Go de mémoire pour te
faire plaisir. Je ne vois pas en quoi avoir seulement 512 Mo de
mémoire est sous-dimensionné pour l'immense majorité des cas.
Par ailleurs, certains problèmes de systemd seraient acceptables si,
par exemple, on pouvait simplement lui demander de ne pas essayer de
tout lancer en parallèle.
Sauf erreur de je n'ai pas trouvé dans la doc un drapeau de
configuration permettant de dire à systemd "merci de ne pas forker
comme un goret et d'être gentil en lançant tout séquentiellement".
Mais d'un autre côté, devoir attendre deux minutes
qu'un périphérique non vital soit reconnu sur ma machine pour pourvoir
l'utiliser parce que sinon, les serveurs qui ont 40 ans ne démarrent pas
me gêne.
Ce qui me dérange plus, c'est l'attente infinie sur certains
périphériques non critiques.
Ou le simple fait que l'ordonnanceur ne soit pas fiable : ce qui
fonctionnait avec telle version de systemd est fichu de ne plus se
lancer dans le même ordre avec la version suivante.
Alors il est vrai que c'est sur des trucs comme des
disques iSCSI ou des choses bizarres qu'on ne retrouvera pas chez
madame Michu (enfin, normalement), mais lorsque tu redémarres une
machine, tu aimes bien que ça se comporte de manière prévisible
d'une version à l'autre. Avec systemd, ce n'est pas le cas. Ça
ressemble vraiment au démarrage de type Windows avec en plus un
petit air d'advienne que pourra.
Un autre truc m'énerve au plus haut point. Lorsqu'on choisit un
système de démarrage, on s'y tient ! Avec systemd, dans certains
cas, on ne sait plus ce qui démarre avec une compatibilité SysV en
réécrivant à la volée des modules systemd, ce qui démarre en vrai
SysV, ce qui est lancé depuis /lib/systemd/system ou /etc/systemd
voire /lib/systemd/user et /etc/systemd/user... Lorsque tu as à la
fois un module systemd et un script SysV, tu as intérêt de chercher
attentivement ce que systemd fera parce que là encore, d'une
versionà une autre, il ne se comporte pas forcément de la même
manière. J'ai pensé naïvement qu'il utilisait toujours en priorité
ses modules. Raté, ce n'est pas toujorus vrai (je n'ai pas cherché à
savoir si c'était un bug ou une fonctionnalité).
C'est un merdier sans nom d'autant plus que je suis tombé sur une
bizarrerie d'un paquet debian qui modifie /lib/systemd/system et...
qui est réécrasé à la prochaine mise à jour de systemd.
Pourquoi est-ce que les devs de systemd n'ont pas tout mis au même endroit
en retirant /etc/init.d de l'équation ?
Mais le résultat est qu'on a un truc qui explose en vol plus souvent
qu'à son tour.
Il y a aussi un truc étrange depuis quelques semaines. Lorsque mon
poste de travail (diskless avec swap en iSCSI) se met à swapper un
peu trop, systemd me ferme ma session graphique. C'est très gentil
de sa part et très pratique. Je suppose qu'il y a maintenant dans le
bouzin un genre de watchdog.
Dernière chose, et non des moindres. Les mises à jour de systemd
sont problématiques parce une nouvelle version de la chose prend
place sur une machine utilisant déjà systemd comme init (pid 1). Et
là, le redémarrage peut être problématique avec des processus
d'extinction qui ne finissent JAMAIS (attente infinie sur... rien
parce que la version du binaire a changé !).
En fait, avec systemd, on est arrivé à un état problématique. Plus
exactement, il est désespérant de voir que ce que les développeurs
de Linux il y a 20 ans reprochaient à Windows se retrouve tel quel
avec les mêmes inconvénients dans Linux.
Le problème de cette page en particulier, comme de ce wiki en
général, c'est que c'est plus une liste de recettes qu'une doc. Si tu
connais systemd, c'est très bien. Si tu découvres systemd en arrivant
sur archlinux, tu fais des devinettes en espérant que ça marche. Ils
t'expliquent comment faire, mais pas pourquoi. Et se plonger dans la
doc de systemd au moment de l'installation d'un OS est quand même
très contraignant.
Après aussi, remarque bien.
Systemd est piégeux, son développement n'a visiblement pas été plus
ou pas été mieux pensé que celui de PL/1. Nouveau besoin, nouveau
patch et, à la fin, on a une usine à gaz avec des fuites qui marche
dans 95% des cas. Tant pis pour toi si tu es dans les 5% restants.
Le 05-06-2020, JKB a écrit :Le 05 Jun 2020 10:21:44 GMT,
Stéphane CARPENTIER écrivait :Je comprends aussi pourquoi les machines sous-dimensionnées de JKB ont
du mal à démarrer.
Dans l'embarqué, tu ne te trimballes pas 4 Go de mémoire pour te
faire plaisir. Je ne vois pas en quoi avoir seulement 512 Mo de
mémoire est sous-dimensionné pour l'immense majorité des cas.
OK, je croyais que c'étaient des vieux serveurs. Mais l'embarqué, si
c'est pas du serveur, c'est pas du poste de travail non plus.
OK, je ne faisais que la distinction serveur/desktop et effectivement,
l'embarqué est clairement une autre catégorie plus proche du serveur que
du poste de travail.Par ailleurs, certains problèmes de systemd seraient acceptables si,
par exemple, on pouvait simplement lui demander de ne pas essayer de
tout lancer en parallèle.
Ça me semble dur car ça me semble prévu par design. Et effectivement, ce
que j'ai vu de systemd n'est pas fait pour l'embarqué. Tu ne peux pas
dire qu'il suffit de lire le socket en attendant que le périphérique
soit prêt on ne sait pas trop quand. Enfin pas sur de l'embarqué, sur du
poste de travail, je ne vois pas le problème.
Ce n'est pas parce que systemd est vraiment orienté poste de travail
qu'il doit être considéré comme néfaste sur les postes de travail.
C'est
comme le gestionnaire de fenêtre, c'est super sur un poste de travail,
c'est plus discutable sur un serveur, sur de l'embarqué, j'ai encore
plus de mal à voir. Pourquoi le système d'initialisation devrait être le
seul composant du système d'exploitation qui devrait être identique
partout ?
Sauf erreur de je n'ai pas trouvé dans la doc un drapeau de
configuration permettant de dire à systemd "merci de ne pas forker
comme un goret et d'être gentil en lançant tout séquentiellement".
Je ne me suis pas plongé dedans, mais d'après ce que j'en comprends,
c'est by design et tu ne devrais rien trouver. Il faudrait que j'analyse
plus ce que ça fait quand j'ai dit à systemd qu'un service devait être
démarré après un autre.
Parce que par disgn, puisqu'à la place de lier directement deux
services, tu fais un socket (je ne sais plus je crois que ce n'est pas
le terme mais le principe). Du coup, tu n'as plus à t'énerver à savoir
dans quel ordre chaque composant doit se lancer, le noyau met en cache
en attendant que l'autre soit prêt. Du coup, tu lances tout en parallèle
et il n'y en a pas un qui ralenti l'autre.
Sauf que si tu es limité en mémoire avec un périphérique lent à
démarrer, la mise en cache du noyau peut saturer ta mémoire.
L'avantage, c'est que sur un poste de travail, tu peux venir avec ton
matériel et brancher et débrancher tes trucs à l'envie (je me souviens
de Windows NT où lorsque tu débranchais ta souris il fallait rebooter).
Mais c'est un avantage pour un poste de travail, sur un serveur ou un
matériel embarqué, le plug-and-play ont moins leur place.
Mais d'un autre côté, devoir attendre deux minutes
qu'un périphérique non vital soit reconnu sur ma machine pour pourvoir
l'utiliser parce que sinon, les serveurs qui ont 40 ans ne démarrent pas
me gêne.
Ce qui me dérange plus, c'est l'attente infinie sur certains
périphériques non critiques.
Ça, si je comprends ce que tu veux dire, c'est pour permettre le
plug-and-play.
Ou le simple fait que l'ordonnanceur ne soit pas fiable : ce qui
fonctionnait avec telle version de systemd est fichu de ne plus se
lancer dans le même ordre avec la version suivante.
D'après ce que je comprends de la conception, c'est que le but est
justement de ne pas avoir s'énerver avec l'ordonnanceur puisque tout est
lancé en même temps et si l'un est pas prêt, le noyau catch les messages
en attendant que l'autre soit prêt.
Du coup, je ne suis pas trop surpris que l'ordonnanceur ne soit pas
fiable. Pour moi, ça va surtout poser des problèmes sur l'embarqué ou
sur des serveurs, pas sur des postes de travail.
Alors il est vrai que c'est sur des trucs comme des
disques iSCSI ou des choses bizarres qu'on ne retrouvera pas chez
madame Michu (enfin, normalement), mais lorsque tu redémarres une
machine, tu aimes bien que ça se comporte de manière prévisible
d'une version à l'autre. Avec systemd, ce n'est pas le cas. Ça
ressemble vraiment au démarrage de type Windows avec en plus un
petit air d'advienne que pourra.
De ce que je comprends, oui, c'est le principe. Pas de lancer à la
Windows, mais de tout lancer en même temps et quand tout sera lancé tout
marchera. Si tu remarques qu'il y a un truc qui s'est bannané, tu
corriges le truc en question et tout ce qui en dépendait fonctionne (je
te parles de la théorie, là, hein, du principe, dans la vraie vie, ça
dépend : ça dépasse). Sur de l'embarqué, tu peux pas te le permettre.
Une fois que ton satellite est dans l'espace tu ne peux pas remarquer
que tu as un truc dans la main que tu as oublié de brancher. Mais sur un
poste de travail, ça a du sens.
Un autre truc m'énerve au plus haut point. Lorsqu'on choisit un
système de démarrage, on s'y tient ! Avec systemd, dans certains
cas, on ne sait plus ce qui démarre avec une compatibilité SysV en
réécrivant à la volée des modules systemd, ce qui démarre en vrai
SysV, ce qui est lancé depuis /lib/systemd/system ou /etc/systemd
voire /lib/systemd/user et /etc/systemd/user... Lorsque tu as à la
fois un module systemd et un script SysV, tu as intérêt de chercher
attentivement ce que systemd fera parce que là encore, d'une
versionà une autre, il ne se comporte pas forcément de la même
manière. J'ai pensé naïvement qu'il utilisait toujours en priorité
ses modules. Raté, ce n'est pas toujorus vrai (je n'ai pas cherché à
savoir si c'était un bug ou une fonctionnalité).
Là, oui, D'après ce que j'ai compris, le but est de permettre de
basculer en douceur de SysV à systemd. Le bon admin sys ou le bon
gestionnaire de distribution devrait donc dégager tout SysV et ne garder
que systemd. Pendant la phase de transition ou parce que quelqu'un a
décidé de garder des scripts SysV jusqu'au bout, oui, ça peut poser des
problèmes.
C'est un merdier sans nom d'autant plus que je suis tombé sur une
bizarrerie d'un paquet debian qui modifie /lib/systemd/system et...
qui est réécrasé à la prochaine mise à jour de systemd.
Mais là, si debian fait n'importe quoi avec sa gestion des
configurations, ce n'est pas un problème systemd. Il aurait pu faire
tomber n'importe quelle partie de ton système.
Pourquoi est-ce que les devs de systemd n'ont pas tout mis au même endroit
en retirant /etc/init.d de l'équation ?
Ça je ne sais pas, je ne me suis pas plongé dedans, mais quand j'ai
installé mon système, j'ai mangé pour savoir où étaient installés mes
trucs. Arriver sur systemd, c'est assez ardu, oui.Mais le résultat est qu'on a un truc qui explose en vol plus souvent
qu'à son tour.
Chez moi c'est stable mais c'est un poste de travail.Il y a aussi un truc étrange depuis quelques semaines. Lorsque mon
poste de travail (diskless avec swap en iSCSI) se met à swapper un
peu trop, systemd me ferme ma session graphique. C'est très gentil
de sa part et très pratique. Je suppose qu'il y a maintenant dans le
bouzin un genre de watchdog.
Le seul truc que j'ai vu sur les processus utilisateurs, c'est qu'il les
ferme sur des utilisateurs délogués. Certains considèrent que c'est un
bug, d'autre une fonctionnalité. Mais les processus utilisateurs logués,
je ne sais pas.Dernière chose, et non des moindres. Les mises à jour de systemd
sont problématiques parce une nouvelle version de la chose prend
place sur une machine utilisant déjà systemd comme init (pid 1). Et
là, le redémarrage peut être problématique avec des processus
d'extinction qui ne finissent JAMAIS (attente infinie sur... rien
parce que la version du binaire a changé !).
Je ne sais pas si j'ai eu des maj de systemd (je suppose quand même),
mais je n'ai jamais eu de problème. Lors des maj, je regarde juste s'il
y a eu des versions du noyau pour le recopier sur le répertoire de boot.En fait, avec systemd, on est arrivé à un état problématique. Plus
exactement, il est désespérant de voir que ce que les développeurs
de Linux il y a 20 ans reprochaient à Windows se retrouve tel quel
avec les mêmes inconvénients dans Linux.
Tu peux voir systemd comme une étape aussi. Là, on a un truc énorme qui
fait plus que de l'init. Mais d'abord, il permet de s'affranchir du
shell.
Ensuite, il oblige à une certaine homogénéisation : pour
s'interfacer il faut que les autres suivent un certain formalisme. Ce
qui fait peur à certains.
Mais à partir du moment où c'est un format
ouvert, c'est pas forcément choquant d'avoir une norme. Ensuite, une
fois que tout ce qui est initialisé au démarrage par systemd est
uniforme, il sera possible de remplacer systemd par un ou plusieurs
autres systèmes mieux conçus qui ne nécessiteront que les mêmes
interfaces.
Le problème de cette page en particulier, comme de ce wiki en
général, c'est que c'est plus une liste de recettes qu'une doc. Si tu
connais systemd, c'est très bien. Si tu découvres systemd en arrivant
sur archlinux, tu fais des devinettes en espérant que ça marche. Ils
t'expliquent comment faire, mais pas pourquoi. Et se plonger dans la
doc de systemd au moment de l'installation d'un OS est quand même
très contraignant.
Après aussi, remarque bien.
Peut-être, mais ça peut pas être pire qu'avant. Et j'ai moins de
contrainte après que pendant. Parce que pendant, il fallait aussi que je
découvre l'uefi par exemple. Entre autre.
Systemd est piégeux, son développement n'a visiblement pas été plus
ou pas été mieux pensé que celui de PL/1. Nouveau besoin, nouveau
patch et, à la fin, on a une usine à gaz avec des fuites qui marche
dans 95% des cas. Tant pis pour toi si tu es dans les 5% restants.
Je ne dis pas que c'est parfait systemd. Mais pour SysV c'est pas tout
rose non plus. Et pour les autres, à part dire que puisque c'est pas
systemd c'est forcément mieux, j'ai jamais vu d'explication sur leurs
points forts.
Mais pour moi, systemd, c'est un peu comme Android. Il y a des défauts,
mais ça fait son travail et je n'ai pas vu d'alternative valable.
Le 05-06-2020, JKB <jkb@koenigsberg.invalid> a écrit :
Le 05 Jun 2020 10:21:44 GMT,
Stéphane CARPENTIER <sc@fiat-linux.fr> écrivait :
Je comprends aussi pourquoi les machines sous-dimensionnées de JKB ont
du mal à démarrer.
Dans l'embarqué, tu ne te trimballes pas 4 Go de mémoire pour te
faire plaisir. Je ne vois pas en quoi avoir seulement 512 Mo de
mémoire est sous-dimensionné pour l'immense majorité des cas.
OK, je croyais que c'étaient des vieux serveurs. Mais l'embarqué, si
c'est pas du serveur, c'est pas du poste de travail non plus.
OK, je ne faisais que la distinction serveur/desktop et effectivement,
l'embarqué est clairement une autre catégorie plus proche du serveur que
du poste de travail.
Par ailleurs, certains problèmes de systemd seraient acceptables si,
par exemple, on pouvait simplement lui demander de ne pas essayer de
tout lancer en parallèle.
Ça me semble dur car ça me semble prévu par design. Et effectivement, ce
que j'ai vu de systemd n'est pas fait pour l'embarqué. Tu ne peux pas
dire qu'il suffit de lire le socket en attendant que le périphérique
soit prêt on ne sait pas trop quand. Enfin pas sur de l'embarqué, sur du
poste de travail, je ne vois pas le problème.
Ce n'est pas parce que systemd est vraiment orienté poste de travail
qu'il doit être considéré comme néfaste sur les postes de travail.
C'est
comme le gestionnaire de fenêtre, c'est super sur un poste de travail,
c'est plus discutable sur un serveur, sur de l'embarqué, j'ai encore
plus de mal à voir. Pourquoi le système d'initialisation devrait être le
seul composant du système d'exploitation qui devrait être identique
partout ?
Sauf erreur de je n'ai pas trouvé dans la doc un drapeau de
configuration permettant de dire à systemd "merci de ne pas forker
comme un goret et d'être gentil en lançant tout séquentiellement".
Je ne me suis pas plongé dedans, mais d'après ce que j'en comprends,
c'est by design et tu ne devrais rien trouver. Il faudrait que j'analyse
plus ce que ça fait quand j'ai dit à systemd qu'un service devait être
démarré après un autre.
Parce que par disgn, puisqu'à la place de lier directement deux
services, tu fais un socket (je ne sais plus je crois que ce n'est pas
le terme mais le principe). Du coup, tu n'as plus à t'énerver à savoir
dans quel ordre chaque composant doit se lancer, le noyau met en cache
en attendant que l'autre soit prêt. Du coup, tu lances tout en parallèle
et il n'y en a pas un qui ralenti l'autre.
Sauf que si tu es limité en mémoire avec un périphérique lent à
démarrer, la mise en cache du noyau peut saturer ta mémoire.
L'avantage, c'est que sur un poste de travail, tu peux venir avec ton
matériel et brancher et débrancher tes trucs à l'envie (je me souviens
de Windows NT où lorsque tu débranchais ta souris il fallait rebooter).
Mais c'est un avantage pour un poste de travail, sur un serveur ou un
matériel embarqué, le plug-and-play ont moins leur place.
Mais d'un autre côté, devoir attendre deux minutes
qu'un périphérique non vital soit reconnu sur ma machine pour pourvoir
l'utiliser parce que sinon, les serveurs qui ont 40 ans ne démarrent pas
me gêne.
Ce qui me dérange plus, c'est l'attente infinie sur certains
périphériques non critiques.
Ça, si je comprends ce que tu veux dire, c'est pour permettre le
plug-and-play.
Ou le simple fait que l'ordonnanceur ne soit pas fiable : ce qui
fonctionnait avec telle version de systemd est fichu de ne plus se
lancer dans le même ordre avec la version suivante.
D'après ce que je comprends de la conception, c'est que le but est
justement de ne pas avoir s'énerver avec l'ordonnanceur puisque tout est
lancé en même temps et si l'un est pas prêt, le noyau catch les messages
en attendant que l'autre soit prêt.
Du coup, je ne suis pas trop surpris que l'ordonnanceur ne soit pas
fiable. Pour moi, ça va surtout poser des problèmes sur l'embarqué ou
sur des serveurs, pas sur des postes de travail.
Alors il est vrai que c'est sur des trucs comme des
disques iSCSI ou des choses bizarres qu'on ne retrouvera pas chez
madame Michu (enfin, normalement), mais lorsque tu redémarres une
machine, tu aimes bien que ça se comporte de manière prévisible
d'une version à l'autre. Avec systemd, ce n'est pas le cas. Ça
ressemble vraiment au démarrage de type Windows avec en plus un
petit air d'advienne que pourra.
De ce que je comprends, oui, c'est le principe. Pas de lancer à la
Windows, mais de tout lancer en même temps et quand tout sera lancé tout
marchera. Si tu remarques qu'il y a un truc qui s'est bannané, tu
corriges le truc en question et tout ce qui en dépendait fonctionne (je
te parles de la théorie, là, hein, du principe, dans la vraie vie, ça
dépend : ça dépasse). Sur de l'embarqué, tu peux pas te le permettre.
Une fois que ton satellite est dans l'espace tu ne peux pas remarquer
que tu as un truc dans la main que tu as oublié de brancher. Mais sur un
poste de travail, ça a du sens.
Un autre truc m'énerve au plus haut point. Lorsqu'on choisit un
système de démarrage, on s'y tient ! Avec systemd, dans certains
cas, on ne sait plus ce qui démarre avec une compatibilité SysV en
réécrivant à la volée des modules systemd, ce qui démarre en vrai
SysV, ce qui est lancé depuis /lib/systemd/system ou /etc/systemd
voire /lib/systemd/user et /etc/systemd/user... Lorsque tu as à la
fois un module systemd et un script SysV, tu as intérêt de chercher
attentivement ce que systemd fera parce que là encore, d'une
versionà une autre, il ne se comporte pas forcément de la même
manière. J'ai pensé naïvement qu'il utilisait toujours en priorité
ses modules. Raté, ce n'est pas toujorus vrai (je n'ai pas cherché à
savoir si c'était un bug ou une fonctionnalité).
Là, oui, D'après ce que j'ai compris, le but est de permettre de
basculer en douceur de SysV à systemd. Le bon admin sys ou le bon
gestionnaire de distribution devrait donc dégager tout SysV et ne garder
que systemd. Pendant la phase de transition ou parce que quelqu'un a
décidé de garder des scripts SysV jusqu'au bout, oui, ça peut poser des
problèmes.
C'est un merdier sans nom d'autant plus que je suis tombé sur une
bizarrerie d'un paquet debian qui modifie /lib/systemd/system et...
qui est réécrasé à la prochaine mise à jour de systemd.
Mais là, si debian fait n'importe quoi avec sa gestion des
configurations, ce n'est pas un problème systemd. Il aurait pu faire
tomber n'importe quelle partie de ton système.
Pourquoi est-ce que les devs de systemd n'ont pas tout mis au même endroit
en retirant /etc/init.d de l'équation ?
Ça je ne sais pas, je ne me suis pas plongé dedans, mais quand j'ai
installé mon système, j'ai mangé pour savoir où étaient installés mes
trucs. Arriver sur systemd, c'est assez ardu, oui.
Mais le résultat est qu'on a un truc qui explose en vol plus souvent
qu'à son tour.
Chez moi c'est stable mais c'est un poste de travail.
Il y a aussi un truc étrange depuis quelques semaines. Lorsque mon
poste de travail (diskless avec swap en iSCSI) se met à swapper un
peu trop, systemd me ferme ma session graphique. C'est très gentil
de sa part et très pratique. Je suppose qu'il y a maintenant dans le
bouzin un genre de watchdog.
Le seul truc que j'ai vu sur les processus utilisateurs, c'est qu'il les
ferme sur des utilisateurs délogués. Certains considèrent que c'est un
bug, d'autre une fonctionnalité. Mais les processus utilisateurs logués,
je ne sais pas.
Dernière chose, et non des moindres. Les mises à jour de systemd
sont problématiques parce une nouvelle version de la chose prend
place sur une machine utilisant déjà systemd comme init (pid 1). Et
là, le redémarrage peut être problématique avec des processus
d'extinction qui ne finissent JAMAIS (attente infinie sur... rien
parce que la version du binaire a changé !).
Je ne sais pas si j'ai eu des maj de systemd (je suppose quand même),
mais je n'ai jamais eu de problème. Lors des maj, je regarde juste s'il
y a eu des versions du noyau pour le recopier sur le répertoire de boot.
En fait, avec systemd, on est arrivé à un état problématique. Plus
exactement, il est désespérant de voir que ce que les développeurs
de Linux il y a 20 ans reprochaient à Windows se retrouve tel quel
avec les mêmes inconvénients dans Linux.
Tu peux voir systemd comme une étape aussi. Là, on a un truc énorme qui
fait plus que de l'init. Mais d'abord, il permet de s'affranchir du
shell.
Ensuite, il oblige à une certaine homogénéisation : pour
s'interfacer il faut que les autres suivent un certain formalisme. Ce
qui fait peur à certains.
Mais à partir du moment où c'est un format
ouvert, c'est pas forcément choquant d'avoir une norme. Ensuite, une
fois que tout ce qui est initialisé au démarrage par systemd est
uniforme, il sera possible de remplacer systemd par un ou plusieurs
autres systèmes mieux conçus qui ne nécessiteront que les mêmes
interfaces.
Le problème de cette page en particulier, comme de ce wiki en
général, c'est que c'est plus une liste de recettes qu'une doc. Si tu
connais systemd, c'est très bien. Si tu découvres systemd en arrivant
sur archlinux, tu fais des devinettes en espérant que ça marche. Ils
t'expliquent comment faire, mais pas pourquoi. Et se plonger dans la
doc de systemd au moment de l'installation d'un OS est quand même
très contraignant.
Après aussi, remarque bien.
Peut-être, mais ça peut pas être pire qu'avant. Et j'ai moins de
contrainte après que pendant. Parce que pendant, il fallait aussi que je
découvre l'uefi par exemple. Entre autre.
Systemd est piégeux, son développement n'a visiblement pas été plus
ou pas été mieux pensé que celui de PL/1. Nouveau besoin, nouveau
patch et, à la fin, on a une usine à gaz avec des fuites qui marche
dans 95% des cas. Tant pis pour toi si tu es dans les 5% restants.
Je ne dis pas que c'est parfait systemd. Mais pour SysV c'est pas tout
rose non plus. Et pour les autres, à part dire que puisque c'est pas
systemd c'est forcément mieux, j'ai jamais vu d'explication sur leurs
points forts.
Mais pour moi, systemd, c'est un peu comme Android. Il y a des défauts,
mais ça fait son travail et je n'ai pas vu d'alternative valable.
Le 05-06-2020, JKB a écrit :Le 05 Jun 2020 10:21:44 GMT,
Stéphane CARPENTIER écrivait :Je comprends aussi pourquoi les machines sous-dimensionnées de JKB ont
du mal à démarrer.
Dans l'embarqué, tu ne te trimballes pas 4 Go de mémoire pour te
faire plaisir. Je ne vois pas en quoi avoir seulement 512 Mo de
mémoire est sous-dimensionné pour l'immense majorité des cas.
OK, je croyais que c'étaient des vieux serveurs. Mais l'embarqué, si
c'est pas du serveur, c'est pas du poste de travail non plus.
OK, je ne faisais que la distinction serveur/desktop et effectivement,
l'embarqué est clairement une autre catégorie plus proche du serveur que
du poste de travail.Par ailleurs, certains problèmes de systemd seraient acceptables si,
par exemple, on pouvait simplement lui demander de ne pas essayer de
tout lancer en parallèle.
Ça me semble dur car ça me semble prévu par design. Et effectivement, ce
que j'ai vu de systemd n'est pas fait pour l'embarqué. Tu ne peux pas
dire qu'il suffit de lire le socket en attendant que le périphérique
soit prêt on ne sait pas trop quand. Enfin pas sur de l'embarqué, sur du
poste de travail, je ne vois pas le problème.
Ce n'est pas parce que systemd est vraiment orienté poste de travail
qu'il doit être considéré comme néfaste sur les postes de travail.
C'est
comme le gestionnaire de fenêtre, c'est super sur un poste de travail,
c'est plus discutable sur un serveur, sur de l'embarqué, j'ai encore
plus de mal à voir. Pourquoi le système d'initialisation devrait être le
seul composant du système d'exploitation qui devrait être identique
partout ?
Sauf erreur de je n'ai pas trouvé dans la doc un drapeau de
configuration permettant de dire à systemd "merci de ne pas forker
comme un goret et d'être gentil en lançant tout séquentiellement".
Je ne me suis pas plongé dedans, mais d'après ce que j'en comprends,
c'est by design et tu ne devrais rien trouver. Il faudrait que j'analyse
plus ce que ça fait quand j'ai dit à systemd qu'un service devait être
démarré après un autre.
Parce que par disgn, puisqu'à la place de lier directement deux
services, tu fais un socket (je ne sais plus je crois que ce n'est pas
le terme mais le principe). Du coup, tu n'as plus à t'énerver à savoir
dans quel ordre chaque composant doit se lancer, le noyau met en cache
en attendant que l'autre soit prêt. Du coup, tu lances tout en parallèle
et il n'y en a pas un qui ralenti l'autre.
Sauf que si tu es limité en mémoire avec un périphérique lent à
démarrer, la mise en cache du noyau peut saturer ta mémoire.
L'avantage, c'est que sur un poste de travail, tu peux venir avec ton
matériel et brancher et débrancher tes trucs à l'envie (je me souviens
de Windows NT où lorsque tu débranchais ta souris il fallait rebooter).
Mais c'est un avantage pour un poste de travail, sur un serveur ou un
matériel embarqué, le plug-and-play ont moins leur place.
Mais d'un autre côté, devoir attendre deux minutes
qu'un périphérique non vital soit reconnu sur ma machine pour pourvoir
l'utiliser parce que sinon, les serveurs qui ont 40 ans ne démarrent pas
me gêne.
Ce qui me dérange plus, c'est l'attente infinie sur certains
périphériques non critiques.
Ça, si je comprends ce que tu veux dire, c'est pour permettre le
plug-and-play.
Ou le simple fait que l'ordonnanceur ne soit pas fiable : ce qui
fonctionnait avec telle version de systemd est fichu de ne plus se
lancer dans le même ordre avec la version suivante.
D'après ce que je comprends de la conception, c'est que le but est
justement de ne pas avoir s'énerver avec l'ordonnanceur puisque tout est
lancé en même temps et si l'un est pas prêt, le noyau catch les messages
en attendant que l'autre soit prêt.
Du coup, je ne suis pas trop surpris que l'ordonnanceur ne soit pas
fiable. Pour moi, ça va surtout poser des problèmes sur l'embarqué ou
sur des serveurs, pas sur des postes de travail.
Alors il est vrai que c'est sur des trucs comme des
disques iSCSI ou des choses bizarres qu'on ne retrouvera pas chez
madame Michu (enfin, normalement), mais lorsque tu redémarres une
machine, tu aimes bien que ça se comporte de manière prévisible
d'une version à l'autre. Avec systemd, ce n'est pas le cas. Ça
ressemble vraiment au démarrage de type Windows avec en plus un
petit air d'advienne que pourra.
De ce que je comprends, oui, c'est le principe. Pas de lancer à la
Windows, mais de tout lancer en même temps et quand tout sera lancé tout
marchera. Si tu remarques qu'il y a un truc qui s'est bannané, tu
corriges le truc en question et tout ce qui en dépendait fonctionne (je
te parles de la théorie, là, hein, du principe, dans la vraie vie, ça
dépend : ça dépasse). Sur de l'embarqué, tu peux pas te le permettre.
Une fois que ton satellite est dans l'espace tu ne peux pas remarquer
que tu as un truc dans la main que tu as oublié de brancher. Mais sur un
poste de travail, ça a du sens.
Un autre truc m'énerve au plus haut point. Lorsqu'on choisit un
système de démarrage, on s'y tient ! Avec systemd, dans certains
cas, on ne sait plus ce qui démarre avec une compatibilité SysV en
réécrivant à la volée des modules systemd, ce qui démarre en vrai
SysV, ce qui est lancé depuis /lib/systemd/system ou /etc/systemd
voire /lib/systemd/user et /etc/systemd/user... Lorsque tu as à la
fois un module systemd et un script SysV, tu as intérêt de chercher
attentivement ce que systemd fera parce que là encore, d'une
versionà une autre, il ne se comporte pas forcément de la même
manière. J'ai pensé naïvement qu'il utilisait toujours en priorité
ses modules. Raté, ce n'est pas toujorus vrai (je n'ai pas cherché à
savoir si c'était un bug ou une fonctionnalité).
Là, oui, D'après ce que j'ai compris, le but est de permettre de
basculer en douceur de SysV à systemd. Le bon admin sys ou le bon
gestionnaire de distribution devrait donc dégager tout SysV et ne garder
que systemd. Pendant la phase de transition ou parce que quelqu'un a
décidé de garder des scripts SysV jusqu'au bout, oui, ça peut poser des
problèmes.
C'est un merdier sans nom d'autant plus que je suis tombé sur une
bizarrerie d'un paquet debian qui modifie /lib/systemd/system et...
qui est réécrasé à la prochaine mise à jour de systemd.
Mais là, si debian fait n'importe quoi avec sa gestion des
configurations, ce n'est pas un problème systemd. Il aurait pu faire
tomber n'importe quelle partie de ton système.
Pourquoi est-ce que les devs de systemd n'ont pas tout mis au même endroit
en retirant /etc/init.d de l'équation ?
Ça je ne sais pas, je ne me suis pas plongé dedans, mais quand j'ai
installé mon système, j'ai mangé pour savoir où étaient installés mes
trucs. Arriver sur systemd, c'est assez ardu, oui.Mais le résultat est qu'on a un truc qui explose en vol plus souvent
qu'à son tour.
Chez moi c'est stable mais c'est un poste de travail.Il y a aussi un truc étrange depuis quelques semaines. Lorsque mon
poste de travail (diskless avec swap en iSCSI) se met à swapper un
peu trop, systemd me ferme ma session graphique. C'est très gentil
de sa part et très pratique. Je suppose qu'il y a maintenant dans le
bouzin un genre de watchdog.
Le seul truc que j'ai vu sur les processus utilisateurs, c'est qu'il les
ferme sur des utilisateurs délogués. Certains considèrent que c'est un
bug, d'autre une fonctionnalité. Mais les processus utilisateurs logués,
je ne sais pas.Dernière chose, et non des moindres. Les mises à jour de systemd
sont problématiques parce une nouvelle version de la chose prend
place sur une machine utilisant déjà systemd comme init (pid 1). Et
là, le redémarrage peut être problématique avec des processus
d'extinction qui ne finissent JAMAIS (attente infinie sur... rien
parce que la version du binaire a changé !).
Je ne sais pas si j'ai eu des maj de systemd (je suppose quand même),
mais je n'ai jamais eu de problème. Lors des maj, je regarde juste s'il
y a eu des versions du noyau pour le recopier sur le répertoire de boot.En fait, avec systemd, on est arrivé à un état problématique. Plus
exactement, il est désespérant de voir que ce que les développeurs
de Linux il y a 20 ans reprochaient à Windows se retrouve tel quel
avec les mêmes inconvénients dans Linux.
Tu peux voir systemd comme une étape aussi. Là, on a un truc énorme qui
fait plus que de l'init. Mais d'abord, il permet de s'affranchir du
shell.
Ensuite, il oblige à une certaine homogénéisation : pour
s'interfacer il faut que les autres suivent un certain formalisme. Ce
qui fait peur à certains.
Mais à partir du moment où c'est un format
ouvert, c'est pas forcément choquant d'avoir une norme. Ensuite, une
fois que tout ce qui est initialisé au démarrage par systemd est
uniforme, il sera possible de remplacer systemd par un ou plusieurs
autres systèmes mieux conçus qui ne nécessiteront que les mêmes
interfaces.
Le problème de cette page en particulier, comme de ce wiki en
général, c'est que c'est plus une liste de recettes qu'une doc. Si tu
connais systemd, c'est très bien. Si tu découvres systemd en arrivant
sur archlinux, tu fais des devinettes en espérant que ça marche. Ils
t'expliquent comment faire, mais pas pourquoi. Et se plonger dans la
doc de systemd au moment de l'installation d'un OS est quand même
très contraignant.
Après aussi, remarque bien.
Peut-être, mais ça peut pas être pire qu'avant. Et j'ai moins de
contrainte après que pendant. Parce que pendant, il fallait aussi que je
découvre l'uefi par exemple. Entre autre.
Systemd est piégeux, son développement n'a visiblement pas été plus
ou pas été mieux pensé que celui de PL/1. Nouveau besoin, nouveau
patch et, à la fin, on a une usine à gaz avec des fuites qui marche
dans 95% des cas. Tant pis pour toi si tu es dans les 5% restants.
Je ne dis pas que c'est parfait systemd. Mais pour SysV c'est pas tout
rose non plus. Et pour les autres, à part dire que puisque c'est pas
systemd c'est forcément mieux, j'ai jamais vu d'explication sur leurs
points forts.
Mais pour moi, systemd, c'est un peu comme Android. Il y a des défauts,
mais ça fait son travail et je n'ai pas vu d'alternative valable.