Ça me semble dur car ça me semble prévu par design.
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é.
Ça me semble dur car ça me semble prévu par design.
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é.
Ça me semble dur car ça me semble prévu par design.
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é.
Le 05 Jun 2020 14:35:06 GMT,
Stéphane CARPENTIER écrivait :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.
Mais je me contrefous royalement du fait qu'il peut ne pas être
néfaste sur un poste de travail.
Si systemd était _juste_ un système
de démarrage, je n'aurais a priori rien contre s'il était bien
ficelé.
Le problème est qu'il n'est pas que cela et que
de plus en plus de soft s'appuient sur systemd pour tourner. Et là,
c'est assez catastrophique parce que, soit tu es contraint de te
taper l'insertion dans d'autres systèmes d'init, soit tu es obligé
de faire avec systemd même si tu n'en veux pas.
Si tu veux tourner sur un arm, tu as bien plus intérêt à prendre une
debian armhf qu'une distribution pour l'embarqué (sauf cas très
spéciaux avec des ressources très limitées ou des composants
scabreux).
Pourquoi ? Parce que ces distributions ont beaucoup plus
d'utilisateurs et les bugs sont remontés bien plus vite et corrigés.
Dans les distributions pour l'embarqué, tu peux avoir des bugs qui
traînent des années (j'ai des souvenirs cuisants avec les Mips et
les iMX-6).
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.
On sait faire cela sans systemd, faut pas exagérer !
Ça, si je comprends ce que tu veux dire, c'est pour permettre le
plug-and-play.
Non. Il y a des cas très drôles d'ordre de montage de disques qui
aboutissaient une fois sur deux à un blocage au boot (un vrai, seul
moyen de s'en tirer, le bouton reset !). Rien à voir avec le
plug'n-play.
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.
Et c'est justement le problème.
Une explosion de consommation de ressources, de PID...
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.
En quoi est-ce une bonne chose ?
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.
Pourquoi ne pas faire juste une seule fois le boulot ?
Le 05 Jun 2020 14:35:06 GMT,
Stéphane CARPENTIER <sc@fiat-linux.fr> écrivait :
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.
Mais je me contrefous royalement du fait qu'il peut ne pas être
néfaste sur un poste de travail.
Si systemd était _juste_ un système
de démarrage, je n'aurais a priori rien contre s'il était bien
ficelé.
Le problème est qu'il n'est pas que cela et que
de plus en plus de soft s'appuient sur systemd pour tourner. Et là,
c'est assez catastrophique parce que, soit tu es contraint de te
taper l'insertion dans d'autres systèmes d'init, soit tu es obligé
de faire avec systemd même si tu n'en veux pas.
Si tu veux tourner sur un arm, tu as bien plus intérêt à prendre une
debian armhf qu'une distribution pour l'embarqué (sauf cas très
spéciaux avec des ressources très limitées ou des composants
scabreux).
Pourquoi ? Parce que ces distributions ont beaucoup plus
d'utilisateurs et les bugs sont remontés bien plus vite et corrigés.
Dans les distributions pour l'embarqué, tu peux avoir des bugs qui
traînent des années (j'ai des souvenirs cuisants avec les Mips et
les iMX-6).
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.
On sait faire cela sans systemd, faut pas exagérer !
Ça, si je comprends ce que tu veux dire, c'est pour permettre le
plug-and-play.
Non. Il y a des cas très drôles d'ordre de montage de disques qui
aboutissaient une fois sur deux à un blocage au boot (un vrai, seul
moyen de s'en tirer, le bouton reset !). Rien à voir avec le
plug'n-play.
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.
Et c'est justement le problème.
Une explosion de consommation de ressources, de PID...
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.
En quoi est-ce une bonne chose ?
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.
Pourquoi ne pas faire juste une seule fois le boulot ?
Le 05 Jun 2020 14:35:06 GMT,
Stéphane CARPENTIER écrivait :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.
Mais je me contrefous royalement du fait qu'il peut ne pas être
néfaste sur un poste de travail.
Si systemd était _juste_ un système
de démarrage, je n'aurais a priori rien contre s'il était bien
ficelé.
Le problème est qu'il n'est pas que cela et que
de plus en plus de soft s'appuient sur systemd pour tourner. Et là,
c'est assez catastrophique parce que, soit tu es contraint de te
taper l'insertion dans d'autres systèmes d'init, soit tu es obligé
de faire avec systemd même si tu n'en veux pas.
Si tu veux tourner sur un arm, tu as bien plus intérêt à prendre une
debian armhf qu'une distribution pour l'embarqué (sauf cas très
spéciaux avec des ressources très limitées ou des composants
scabreux).
Pourquoi ? Parce que ces distributions ont beaucoup plus
d'utilisateurs et les bugs sont remontés bien plus vite et corrigés.
Dans les distributions pour l'embarqué, tu peux avoir des bugs qui
traînent des années (j'ai des souvenirs cuisants avec les Mips et
les iMX-6).
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.
On sait faire cela sans systemd, faut pas exagérer !
Ça, si je comprends ce que tu veux dire, c'est pour permettre le
plug-and-play.
Non. Il y a des cas très drôles d'ordre de montage de disques qui
aboutissaient une fois sur deux à un blocage au boot (un vrai, seul
moyen de s'en tirer, le bouton reset !). Rien à voir avec le
plug'n-play.
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.
Et c'est justement le problème.
Une explosion de consommation de ressources, de PID...
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.
En quoi est-ce une bonne chose ?
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.
Pourquoi ne pas faire juste une seule fois le boulot ?
Stéphane CARPENTIER , dans le message
, a écrit :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é.
C'est optionnel et configurable, donc ceux qui prétendent que c'est un bug
sont de mauvaise foi.
Stéphane CARPENTIER , dans le message
<slrnrdkm0q.7b7l.sc@scarpet42p.localdomain>, a écrit :
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é.
C'est optionnel et configurable, donc ceux qui prétendent que c'est un bug
sont de mauvaise foi.
Stéphane CARPENTIER , dans le message
, a écrit :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é.
C'est optionnel et configurable, donc ceux qui prétendent que c'est un bug
sont de mauvaise foi.
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.
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.
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.
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.
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
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
attentivement ce que systemd fera parce que là encore, d'une
une autre, il ne se comporte pas forcément de la même manière.
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.
Le problème n'est pas là. Lorsque je veux utiliser un script
/etc/init.d,
systemd n'a pas à intérférer là-dedans pour utiliser un bout de
/etc/systemd ou /lib/systemd (sans le dire, sinon, ce n'est pas
Point barre. Il ne sait pas mieux que moi ce que je veux faire.
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
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
attentivement ce que systemd fera parce que là encore, d'une
une autre, il ne se comporte pas forcément de la même manière.
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.
Le problème n'est pas là. Lorsque je veux utiliser un script
/etc/init.d,
systemd n'a pas à intérférer là-dedans pour utiliser un bout de
/etc/systemd ou /lib/systemd (sans le dire, sinon, ce n'est pas
Point barre. Il ne sait pas mieux que moi ce que je veux faire.
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
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
attentivement ce que systemd fera parce que là encore, d'une
une autre, il ne se comporte pas forcément de la même manière.
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.
Le problème n'est pas là. Lorsque je veux utiliser un script
/etc/init.d,
systemd n'a pas à intérférer là-dedans pour utiliser un bout de
/etc/systemd ou /lib/systemd (sans le dire, sinon, ce n'est pas
Point barre. Il ne sait pas mieux que moi ce que je veux faire.
Le 05-06-2020, JKB a écrit :Le 05 Jun 2020 14:35:06 GMT,
Stéphane CARPENTIER écrivait :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.
Mais je me contrefous royalement du fait qu'il peut ne pas être
néfaste sur un poste de travail.
Pas moi, parce que c'est ce que j'utilise. La guerre contre systemd
n'est pas une guerre contre systemd sur le serveur mais global. Les
sites internet critiquant systemd disent que personne ne doit l'utiliser
parce que c'est le mal absolu. Mais que ce soit le mal absolu pour les
serveurs ou pour l'embarqué n'est pas mon problème. Moi, c'est sur un
poste de travail que je l'utilise.
Si systemd était _juste_ un système
de démarrage, je n'aurais a priori rien contre s'il était bien
ficelé.
Je ne sais pas à quel point il est mal ficelé. Moi ce que je sais, c'est
que ça marche bien chez moi.
Ce que je vois, c'est que, ce après quoi tu
râles, j'ai l'impression que ça se résume en trois trucs :
- le manque de fiabilité des montés de versions. Quand tu me parles des
fichiers de configuration mal gérés par debian, je me demande à quel
point le sujet ne vient pas plus de debian que de systemd. Parce que
si les options des fichiers de conf que tu ne modifies pas sont
changées à chaque montée de version, ceci peut expliquer cela.
- le mélange entre les confs de SysV et de systemd. Pareil, quand c'est
sorti, systemd devait probablement bien avoir besoin de certaines
parties de SysV, mais depuis j'ai tendance à croire que systemd n'a
absolument plus besoin de SysV.
Donc, si les deux se marchent sur les
pieds, c'est peut-être parce que debian essaye de les faire cohabiter
tant bien que mal. Pareil, si c'est le cas, c'est pas de la faute de
systemd si debian n'arrive pas à les faire cohabiter, surtout si c'est
pas utile.
- tu as quand mêmes des besoins particulièrement spécifiques. Si debian
a du mal à gérer la cohabitation entre systemd et SysV, je ne suis pas
surpris qu'ils n'aient pas testés tes cas particulier. Pareil, c'est
pas non plus de la faute de systemd si c'est debian qui n'a pas testé
tes cas particuliers.
Le problème est qu'il n'est pas que cela et que
de plus en plus de soft s'appuient sur systemd pour tourner. Et là,
c'est assez catastrophique parce que, soit tu es contraint de te
taper l'insertion dans d'autres systèmes d'init, soit tu es obligé
de faire avec systemd même si tu n'en veux pas.
Je ne suis pas trop sûr de comprendre. Les cas que tu m'as montrés sont
des exemples super particuliers. Tu veux dire que tu as généralisé ces
cas particuliers ?
Si tu veux tourner sur un arm, tu as bien plus intérêt à prendre une
debian armhf qu'une distribution pour l'embarqué (sauf cas très
spéciaux avec des ressources très limitées ou des composants
scabreux).
Ça, c'est peut-être une partie du problème. Avant, l'embarqué, ils
développaient tout parce que les ressources étaient limités. Maintenant,
on met un Linux dedans parce que les ressources ont augmentés et c'est
plus facile. Après, que les distributions grand public ne soient pas
prévues pour faire de l'embarqué, oui, je veux bien te croire.
Pourquoi ? Parce que ces distributions ont beaucoup plus
d'utilisateurs et les bugs sont remontés bien plus vite et corrigés.
Dans les distributions pour l'embarqué, tu peux avoir des bugs qui
traînent des années (j'ai des souvenirs cuisants avec les Mips et
les iMX-6).
Oui, quand le satellite est dans l'espace, c'est plus dur de faire une
mise à jour. Sur un avion ou sur un train, il suffit d'attendre qu'il
arrive au contrôle. Mais normalement, l'avantage d'un truc au petits
oignons pour de l'embarqué, c'est que tas moins de composants et moins
de bugs.
J'en connais un qui a fait des tests sur des radars pour aéroport. Les
tests ça rigole pas, c'est pas des tests de Windows. Les tests sont
faits en double, dans deux langages de programmation. Et il y a un
logiciel qui fait des tests automatique puis un autre logiciel pour
tester le logiciel qui lance les tests. Ça m'étonnerait que dans son cas
il y ait eu un bug critique non corrigé pendant des années. J'ai vu des
mecs qui programment en ADA pour de l'embarqué et c'est pareil, il était
pas inquiet pour les bugs. La difficulté c'était la compilation.
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.
On sait faire cela sans systemd, faut pas exagérer !
J'ai pas dit que c'est sytemd qui l'a inventé. À partir du moment où
rien n'est centralisé pour le gérer, chaque matériel doit être géré
à l'unité (éventuellement en groupe par exemple CUPS pour les
imprimantes).
À partir du moment où c'est pris en charge en central, ça
simplifie la vie de celui qui fabrique un matériel (il n'a qu'à définir
comment il doit être initialisé) et de celui qui l'utilise.Ça, si je comprends ce que tu veux dire, c'est pour permettre le
plug-and-play.
Non. Il y a des cas très drôles d'ordre de montage de disques qui
aboutissaient une fois sur deux à un blocage au boot (un vrai, seul
moyen de s'en tirer, le bouton reset !). Rien à voir avec le
plug'n-play.
OK, ça c'est bizarre. Que systemd ne gère pas bien l'ordre de démarrage,
je le veux bien, que systemd soit responsable du blocage, je suis moins
sûr.
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.
Et c'est justement le problème.
Problème pour serveur et embarqué, je veux bien. Pour poste de travail,
je n'ai rien vu.
Une explosion de consommation de ressources, de PID...
Pour les ressources, je ne sais pas. Une fois que tout est démarré, le
noyau libère son cache et les ressources sont libérées.
Pour le nombre de PID, faut se mettre d'accord. Soit c'est la
philosophie Unix de la séparaion des tâches et ça donne une augmentation
des PID. Soit on a un truc monolithique qui fait tout avec un seul PID.
Une augmentation du nombre de PID est plutôt une bonne nouvelle pour
moi, ça veut dire que c'est moins monolithique que ce qui est annoncé.
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.
En quoi est-ce une bonne chose ?
En gros, je ne sais pas si j'ai vu un shell sh une fois dans ma vie.
C'est possible, mais c'est très vieux et je n'y avais pas fait
attention.
Depuis de nombreuses années, le /bin/sh, c'est un lien vers autre chose.
J'ai vu dash, bash, il doit y en avoir d'autres. Or, c'est quasiment
tout le temps, défini comme un script sh. Ce qui fait qu'avec un
développeur propre et consciencieux, il reste dans les limites du sh.
Mais quelqu'un de moins rigoureux va rajouter des basheries ou des
dasheries (je ne sais pas s'il y a autant de spécificité que pour bash)
ou des ce que tu veux dans son script. Et quand il va rajouter des
spécificité sans s'en rendre compte, il va les distribuer. Et tant que
tout le monde a le même shell par défaut, ça marche. Mais si pour une
raison quelconque, tu changes il y a des effets de bord que tu ne vas
pas comprendre. Si des mainteneurs de distribution veulent changer leur
shell par défaut, il y a plein de trucs à prendre en compte qui n'ont
pas lieu d'être.
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.
Pourquoi ne pas faire juste une seule fois le boulot ?
D'abord, ce ne sont pas forcément les mêmes qui vont faire la deuxième
étape (s'il y en a une, je ne suis pas visionnaire c'est une
possibilité). Les premiers n'ont pas forcément prévu de basculer.
Ensuite, Ça peut être plus facile de procéder par étape.
Enfin, il y a toujours une partie retour d'expérience. C'est facile une
fois que le boulot est fini de voir comment il aurait fallu faire. C'est
rarement tout bon ou tout mauvais. Mais c'est quand on a fini qu'on peut
voir les amélioration : en apprenant de ses erreurs.
Le 05-06-2020, JKB <jkb@koenigsberg.invalid> a écrit :
Le 05 Jun 2020 14:35:06 GMT,
Stéphane CARPENTIER <sc@fiat-linux.fr> écrivait :
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.
Mais je me contrefous royalement du fait qu'il peut ne pas être
néfaste sur un poste de travail.
Pas moi, parce que c'est ce que j'utilise. La guerre contre systemd
n'est pas une guerre contre systemd sur le serveur mais global. Les
sites internet critiquant systemd disent que personne ne doit l'utiliser
parce que c'est le mal absolu. Mais que ce soit le mal absolu pour les
serveurs ou pour l'embarqué n'est pas mon problème. Moi, c'est sur un
poste de travail que je l'utilise.
Si systemd était _juste_ un système
de démarrage, je n'aurais a priori rien contre s'il était bien
ficelé.
Je ne sais pas à quel point il est mal ficelé. Moi ce que je sais, c'est
que ça marche bien chez moi.
Ce que je vois, c'est que, ce après quoi tu
râles, j'ai l'impression que ça se résume en trois trucs :
- le manque de fiabilité des montés de versions. Quand tu me parles des
fichiers de configuration mal gérés par debian, je me demande à quel
point le sujet ne vient pas plus de debian que de systemd. Parce que
si les options des fichiers de conf que tu ne modifies pas sont
changées à chaque montée de version, ceci peut expliquer cela.
- le mélange entre les confs de SysV et de systemd. Pareil, quand c'est
sorti, systemd devait probablement bien avoir besoin de certaines
parties de SysV, mais depuis j'ai tendance à croire que systemd n'a
absolument plus besoin de SysV.
Donc, si les deux se marchent sur les
pieds, c'est peut-être parce que debian essaye de les faire cohabiter
tant bien que mal. Pareil, si c'est le cas, c'est pas de la faute de
systemd si debian n'arrive pas à les faire cohabiter, surtout si c'est
pas utile.
- tu as quand mêmes des besoins particulièrement spécifiques. Si debian
a du mal à gérer la cohabitation entre systemd et SysV, je ne suis pas
surpris qu'ils n'aient pas testés tes cas particulier. Pareil, c'est
pas non plus de la faute de systemd si c'est debian qui n'a pas testé
tes cas particuliers.
Le problème est qu'il n'est pas que cela et que
de plus en plus de soft s'appuient sur systemd pour tourner. Et là,
c'est assez catastrophique parce que, soit tu es contraint de te
taper l'insertion dans d'autres systèmes d'init, soit tu es obligé
de faire avec systemd même si tu n'en veux pas.
Je ne suis pas trop sûr de comprendre. Les cas que tu m'as montrés sont
des exemples super particuliers. Tu veux dire que tu as généralisé ces
cas particuliers ?
Si tu veux tourner sur un arm, tu as bien plus intérêt à prendre une
debian armhf qu'une distribution pour l'embarqué (sauf cas très
spéciaux avec des ressources très limitées ou des composants
scabreux).
Ça, c'est peut-être une partie du problème. Avant, l'embarqué, ils
développaient tout parce que les ressources étaient limités. Maintenant,
on met un Linux dedans parce que les ressources ont augmentés et c'est
plus facile. Après, que les distributions grand public ne soient pas
prévues pour faire de l'embarqué, oui, je veux bien te croire.
Pourquoi ? Parce que ces distributions ont beaucoup plus
d'utilisateurs et les bugs sont remontés bien plus vite et corrigés.
Dans les distributions pour l'embarqué, tu peux avoir des bugs qui
traînent des années (j'ai des souvenirs cuisants avec les Mips et
les iMX-6).
Oui, quand le satellite est dans l'espace, c'est plus dur de faire une
mise à jour. Sur un avion ou sur un train, il suffit d'attendre qu'il
arrive au contrôle. Mais normalement, l'avantage d'un truc au petits
oignons pour de l'embarqué, c'est que tas moins de composants et moins
de bugs.
J'en connais un qui a fait des tests sur des radars pour aéroport. Les
tests ça rigole pas, c'est pas des tests de Windows. Les tests sont
faits en double, dans deux langages de programmation. Et il y a un
logiciel qui fait des tests automatique puis un autre logiciel pour
tester le logiciel qui lance les tests. Ça m'étonnerait que dans son cas
il y ait eu un bug critique non corrigé pendant des années. J'ai vu des
mecs qui programment en ADA pour de l'embarqué et c'est pareil, il était
pas inquiet pour les bugs. La difficulté c'était la compilation.
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.
On sait faire cela sans systemd, faut pas exagérer !
J'ai pas dit que c'est sytemd qui l'a inventé. À partir du moment où
rien n'est centralisé pour le gérer, chaque matériel doit être géré
à l'unité (éventuellement en groupe par exemple CUPS pour les
imprimantes).
À partir du moment où c'est pris en charge en central, ça
simplifie la vie de celui qui fabrique un matériel (il n'a qu'à définir
comment il doit être initialisé) et de celui qui l'utilise.
Ça, si je comprends ce que tu veux dire, c'est pour permettre le
plug-and-play.
Non. Il y a des cas très drôles d'ordre de montage de disques qui
aboutissaient une fois sur deux à un blocage au boot (un vrai, seul
moyen de s'en tirer, le bouton reset !). Rien à voir avec le
plug'n-play.
OK, ça c'est bizarre. Que systemd ne gère pas bien l'ordre de démarrage,
je le veux bien, que systemd soit responsable du blocage, je suis moins
sûr.
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.
Et c'est justement le problème.
Problème pour serveur et embarqué, je veux bien. Pour poste de travail,
je n'ai rien vu.
Une explosion de consommation de ressources, de PID...
Pour les ressources, je ne sais pas. Une fois que tout est démarré, le
noyau libère son cache et les ressources sont libérées.
Pour le nombre de PID, faut se mettre d'accord. Soit c'est la
philosophie Unix de la séparaion des tâches et ça donne une augmentation
des PID. Soit on a un truc monolithique qui fait tout avec un seul PID.
Une augmentation du nombre de PID est plutôt une bonne nouvelle pour
moi, ça veut dire que c'est moins monolithique que ce qui est annoncé.
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.
En quoi est-ce une bonne chose ?
En gros, je ne sais pas si j'ai vu un shell sh une fois dans ma vie.
C'est possible, mais c'est très vieux et je n'y avais pas fait
attention.
Depuis de nombreuses années, le /bin/sh, c'est un lien vers autre chose.
J'ai vu dash, bash, il doit y en avoir d'autres. Or, c'est quasiment
tout le temps, défini comme un script sh. Ce qui fait qu'avec un
développeur propre et consciencieux, il reste dans les limites du sh.
Mais quelqu'un de moins rigoureux va rajouter des basheries ou des
dasheries (je ne sais pas s'il y a autant de spécificité que pour bash)
ou des ce que tu veux dans son script. Et quand il va rajouter des
spécificité sans s'en rendre compte, il va les distribuer. Et tant que
tout le monde a le même shell par défaut, ça marche. Mais si pour une
raison quelconque, tu changes il y a des effets de bord que tu ne vas
pas comprendre. Si des mainteneurs de distribution veulent changer leur
shell par défaut, il y a plein de trucs à prendre en compte qui n'ont
pas lieu d'être.
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.
Pourquoi ne pas faire juste une seule fois le boulot ?
D'abord, ce ne sont pas forcément les mêmes qui vont faire la deuxième
étape (s'il y en a une, je ne suis pas visionnaire c'est une
possibilité). Les premiers n'ont pas forcément prévu de basculer.
Ensuite, Ça peut être plus facile de procéder par étape.
Enfin, il y a toujours une partie retour d'expérience. C'est facile une
fois que le boulot est fini de voir comment il aurait fallu faire. C'est
rarement tout bon ou tout mauvais. Mais c'est quand on a fini qu'on peut
voir les amélioration : en apprenant de ses erreurs.
Le 05-06-2020, JKB a écrit :Le 05 Jun 2020 14:35:06 GMT,
Stéphane CARPENTIER écrivait :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.
Mais je me contrefous royalement du fait qu'il peut ne pas être
néfaste sur un poste de travail.
Pas moi, parce que c'est ce que j'utilise. La guerre contre systemd
n'est pas une guerre contre systemd sur le serveur mais global. Les
sites internet critiquant systemd disent que personne ne doit l'utiliser
parce que c'est le mal absolu. Mais que ce soit le mal absolu pour les
serveurs ou pour l'embarqué n'est pas mon problème. Moi, c'est sur un
poste de travail que je l'utilise.
Si systemd était _juste_ un système
de démarrage, je n'aurais a priori rien contre s'il était bien
ficelé.
Je ne sais pas à quel point il est mal ficelé. Moi ce que je sais, c'est
que ça marche bien chez moi.
Ce que je vois, c'est que, ce après quoi tu
râles, j'ai l'impression que ça se résume en trois trucs :
- le manque de fiabilité des montés de versions. Quand tu me parles des
fichiers de configuration mal gérés par debian, je me demande à quel
point le sujet ne vient pas plus de debian que de systemd. Parce que
si les options des fichiers de conf que tu ne modifies pas sont
changées à chaque montée de version, ceci peut expliquer cela.
- le mélange entre les confs de SysV et de systemd. Pareil, quand c'est
sorti, systemd devait probablement bien avoir besoin de certaines
parties de SysV, mais depuis j'ai tendance à croire que systemd n'a
absolument plus besoin de SysV.
Donc, si les deux se marchent sur les
pieds, c'est peut-être parce que debian essaye de les faire cohabiter
tant bien que mal. Pareil, si c'est le cas, c'est pas de la faute de
systemd si debian n'arrive pas à les faire cohabiter, surtout si c'est
pas utile.
- tu as quand mêmes des besoins particulièrement spécifiques. Si debian
a du mal à gérer la cohabitation entre systemd et SysV, je ne suis pas
surpris qu'ils n'aient pas testés tes cas particulier. Pareil, c'est
pas non plus de la faute de systemd si c'est debian qui n'a pas testé
tes cas particuliers.
Le problème est qu'il n'est pas que cela et que
de plus en plus de soft s'appuient sur systemd pour tourner. Et là,
c'est assez catastrophique parce que, soit tu es contraint de te
taper l'insertion dans d'autres systèmes d'init, soit tu es obligé
de faire avec systemd même si tu n'en veux pas.
Je ne suis pas trop sûr de comprendre. Les cas que tu m'as montrés sont
des exemples super particuliers. Tu veux dire que tu as généralisé ces
cas particuliers ?
Si tu veux tourner sur un arm, tu as bien plus intérêt à prendre une
debian armhf qu'une distribution pour l'embarqué (sauf cas très
spéciaux avec des ressources très limitées ou des composants
scabreux).
Ça, c'est peut-être une partie du problème. Avant, l'embarqué, ils
développaient tout parce que les ressources étaient limités. Maintenant,
on met un Linux dedans parce que les ressources ont augmentés et c'est
plus facile. Après, que les distributions grand public ne soient pas
prévues pour faire de l'embarqué, oui, je veux bien te croire.
Pourquoi ? Parce que ces distributions ont beaucoup plus
d'utilisateurs et les bugs sont remontés bien plus vite et corrigés.
Dans les distributions pour l'embarqué, tu peux avoir des bugs qui
traînent des années (j'ai des souvenirs cuisants avec les Mips et
les iMX-6).
Oui, quand le satellite est dans l'espace, c'est plus dur de faire une
mise à jour. Sur un avion ou sur un train, il suffit d'attendre qu'il
arrive au contrôle. Mais normalement, l'avantage d'un truc au petits
oignons pour de l'embarqué, c'est que tas moins de composants et moins
de bugs.
J'en connais un qui a fait des tests sur des radars pour aéroport. Les
tests ça rigole pas, c'est pas des tests de Windows. Les tests sont
faits en double, dans deux langages de programmation. Et il y a un
logiciel qui fait des tests automatique puis un autre logiciel pour
tester le logiciel qui lance les tests. Ça m'étonnerait que dans son cas
il y ait eu un bug critique non corrigé pendant des années. J'ai vu des
mecs qui programment en ADA pour de l'embarqué et c'est pareil, il était
pas inquiet pour les bugs. La difficulté c'était la compilation.
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.
On sait faire cela sans systemd, faut pas exagérer !
J'ai pas dit que c'est sytemd qui l'a inventé. À partir du moment où
rien n'est centralisé pour le gérer, chaque matériel doit être géré
à l'unité (éventuellement en groupe par exemple CUPS pour les
imprimantes).
À partir du moment où c'est pris en charge en central, ça
simplifie la vie de celui qui fabrique un matériel (il n'a qu'à définir
comment il doit être initialisé) et de celui qui l'utilise.Ça, si je comprends ce que tu veux dire, c'est pour permettre le
plug-and-play.
Non. Il y a des cas très drôles d'ordre de montage de disques qui
aboutissaient une fois sur deux à un blocage au boot (un vrai, seul
moyen de s'en tirer, le bouton reset !). Rien à voir avec le
plug'n-play.
OK, ça c'est bizarre. Que systemd ne gère pas bien l'ordre de démarrage,
je le veux bien, que systemd soit responsable du blocage, je suis moins
sûr.
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.
Et c'est justement le problème.
Problème pour serveur et embarqué, je veux bien. Pour poste de travail,
je n'ai rien vu.
Une explosion de consommation de ressources, de PID...
Pour les ressources, je ne sais pas. Une fois que tout est démarré, le
noyau libère son cache et les ressources sont libérées.
Pour le nombre de PID, faut se mettre d'accord. Soit c'est la
philosophie Unix de la séparaion des tâches et ça donne une augmentation
des PID. Soit on a un truc monolithique qui fait tout avec un seul PID.
Une augmentation du nombre de PID est plutôt une bonne nouvelle pour
moi, ça veut dire que c'est moins monolithique que ce qui est annoncé.
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.
En quoi est-ce une bonne chose ?
En gros, je ne sais pas si j'ai vu un shell sh une fois dans ma vie.
C'est possible, mais c'est très vieux et je n'y avais pas fait
attention.
Depuis de nombreuses années, le /bin/sh, c'est un lien vers autre chose.
J'ai vu dash, bash, il doit y en avoir d'autres. Or, c'est quasiment
tout le temps, défini comme un script sh. Ce qui fait qu'avec un
développeur propre et consciencieux, il reste dans les limites du sh.
Mais quelqu'un de moins rigoureux va rajouter des basheries ou des
dasheries (je ne sais pas s'il y a autant de spécificité que pour bash)
ou des ce que tu veux dans son script. Et quand il va rajouter des
spécificité sans s'en rendre compte, il va les distribuer. Et tant que
tout le monde a le même shell par défaut, ça marche. Mais si pour une
raison quelconque, tu changes il y a des effets de bord que tu ne vas
pas comprendre. Si des mainteneurs de distribution veulent changer leur
shell par défaut, il y a plein de trucs à prendre en compte qui n'ont
pas lieu d'être.
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.
Pourquoi ne pas faire juste une seule fois le boulot ?
D'abord, ce ne sont pas forcément les mêmes qui vont faire la deuxième
étape (s'il y en a une, je ne suis pas visionnaire c'est une
possibilité). Les premiers n'ont pas forcément prévu de basculer.
Ensuite, Ça peut être plus facile de procéder par étape.
Enfin, il y a toujours une partie retour d'expérience. C'est facile une
fois que le boulot est fini de voir comment il aurait fallu faire. C'est
rarement tout bon ou tout mauvais. Mais c'est quand on a fini qu'on peut
voir les amélioration : en apprenant de ses erreurs.
Le Fri, 05 Jun 2020 10:21:44 +0000, Stéphane CARPENTIER a écrit :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.
Ah bah désolé... :)
Personnellement quand arch est passé à systemd j'ai appris quelques
commandes, arrêté d'utiliser "/etc/rc.d/service restart" au profit de
"systemctl restart service" et ça s'est un peu arrêté là...
J'ai suivi quelques discussions sur systemd mais pour ce que j'en fais ça
ne change pas grand chose à ma vie.
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.
Mais au moment de l'installation d'arch, tu suis la page d'installation
et pas celle de systemd, non ? Qu'est-ce que tu as besoin de savoir sur
systemd quand tu fais une installation arch ?
Pour moi quand tu fais ton installation archlinux sans savoir exactement
où tu vas ni connaître les outils, tu suis la procédure sans trop en
dévier et ça te permet de savoir un peu que telle ou telle partie se
configure à tel ou tel endroit (et aussi d'avoir une machine
fonctionnelle).
Le Fri, 05 Jun 2020 10:21:44 +0000, Stéphane CARPENTIER a écrit :
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.
Ah bah désolé... :)
Personnellement quand arch est passé à systemd j'ai appris quelques
commandes, arrêté d'utiliser "/etc/rc.d/service restart" au profit de
"systemctl restart service" et ça s'est un peu arrêté là...
J'ai suivi quelques discussions sur systemd mais pour ce que j'en fais ça
ne change pas grand chose à ma vie.
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.
Mais au moment de l'installation d'arch, tu suis la page d'installation
et pas celle de systemd, non ? Qu'est-ce que tu as besoin de savoir sur
systemd quand tu fais une installation arch ?
Pour moi quand tu fais ton installation archlinux sans savoir exactement
où tu vas ni connaître les outils, tu suis la procédure sans trop en
dévier et ça te permet de savoir un peu que telle ou telle partie se
configure à tel ou tel endroit (et aussi d'avoir une machine
fonctionnelle).
Le Fri, 05 Jun 2020 10:21:44 +0000, Stéphane CARPENTIER a écrit :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.
Ah bah désolé... :)
Personnellement quand arch est passé à systemd j'ai appris quelques
commandes, arrêté d'utiliser "/etc/rc.d/service restart" au profit de
"systemctl restart service" et ça s'est un peu arrêté là...
J'ai suivi quelques discussions sur systemd mais pour ce que j'en fais ça
ne change pas grand chose à ma vie.
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.
Mais au moment de l'installation d'arch, tu suis la page d'installation
et pas celle de systemd, non ? Qu'est-ce que tu as besoin de savoir sur
systemd quand tu fais une installation arch ?
Pour moi quand tu fais ton installation archlinux sans savoir exactement
où tu vas ni connaître les outils, tu suis la procédure sans trop en
dévier et ça te permet de savoir un peu que telle ou telle partie se
configure à tel ou tel endroit (et aussi d'avoir une machine
fonctionnelle).
Si c'est très compliqué à
configurer (j'en sais rien) ça peut ne pas être agréable.
Si c'est très compliqué à
configurer (j'en sais rien) ça peut ne pas être agréable.
Si c'est très compliqué à
configurer (j'en sais rien) ça peut ne pas être agréable.
Si je n'arrive pas à croire que tout est mieux que systemd sans raison,
j'ai du mal à croire que la cabale contre systemd soit aussi totalement
dénuée de raison.
Si je n'arrive pas à croire que tout est mieux que systemd sans raison,
j'ai du mal à croire que la cabale contre systemd soit aussi totalement
dénuée de raison.
Si je n'arrive pas à croire que tout est mieux que systemd sans raison,
j'ai du mal à croire que la cabale contre systemd soit aussi totalement
dénuée de raison.
Le 05 Jun 2020 22:05:39 GMT, Stéphane CARPENTIER
écrivait :Pas moi, parce que c'est ce que j'utilise. La guerre contre systemd
n'est pas une guerre contre systemd sur le serveur mais global. Les
sites internet critiquant systemd disent que personne ne doit
l'utiliser parce que c'est le mal absolu. Mais que ce soit le mal
absolu pour les serveurs ou pour l'embarqué n'est pas mon problème.
Moi, c'est sur un poste de travail que je l'utilise.
Remarque bien, il n'y a aucune raison que les problèmes rencontrés
ailleurs que sur un poste de travail ne finissent pas par arriver
sur un poste de travail.
Je ne sais pas à quel point il est mal ficelé. Moi ce que je sais,
c'est que ça marche bien chez moi.
Ce n'est pas parce que ça marche chez toi que ça marche partout. La
preuve est mince.
Problème pour serveur et embarqué, je veux bien. Pour poste de travail,
je n'ai rien vu.
Ce n'est pas parce que tu n'as rien vu que ces problèmes n'existent
pas.
Pour le nombre de PID, faut se mettre d'accord. Soit c'est la
philosophie Unix de la séparaion des tâches et ça donne une
augmentation des PID. Soit on a un truc monolithique qui fait tout
avec un seul PID. Une augmentation du nombre de PID est plutôt une
bonne nouvelle pour moi, ça veut dire que c'est moins monolithique
que ce qui est annoncé.
Là encore, je me contrefiche du nombre de PID dans l'absolu. Le
problème de l'explosion des PID, c'est la consommation des
ressources (nombre de fichiers ouverts, temps CPU au sens temps
système et non utilisateur...).
Le 05 Jun 2020 22:05:39 GMT, Stéphane CARPENTIER <sc@fiat-linux.fr>
écrivait :
Pas moi, parce que c'est ce que j'utilise. La guerre contre systemd
n'est pas une guerre contre systemd sur le serveur mais global. Les
sites internet critiquant systemd disent que personne ne doit
l'utiliser parce que c'est le mal absolu. Mais que ce soit le mal
absolu pour les serveurs ou pour l'embarqué n'est pas mon problème.
Moi, c'est sur un poste de travail que je l'utilise.
Remarque bien, il n'y a aucune raison que les problèmes rencontrés
ailleurs que sur un poste de travail ne finissent pas par arriver
sur un poste de travail.
Je ne sais pas à quel point il est mal ficelé. Moi ce que je sais,
c'est que ça marche bien chez moi.
Ce n'est pas parce que ça marche chez toi que ça marche partout. La
preuve est mince.
Problème pour serveur et embarqué, je veux bien. Pour poste de travail,
je n'ai rien vu.
Ce n'est pas parce que tu n'as rien vu que ces problèmes n'existent
pas.
Pour le nombre de PID, faut se mettre d'accord. Soit c'est la
philosophie Unix de la séparaion des tâches et ça donne une
augmentation des PID. Soit on a un truc monolithique qui fait tout
avec un seul PID. Une augmentation du nombre de PID est plutôt une
bonne nouvelle pour moi, ça veut dire que c'est moins monolithique
que ce qui est annoncé.
Là encore, je me contrefiche du nombre de PID dans l'absolu. Le
problème de l'explosion des PID, c'est la consommation des
ressources (nombre de fichiers ouverts, temps CPU au sens temps
système et non utilisateur...).
Le 05 Jun 2020 22:05:39 GMT, Stéphane CARPENTIER
écrivait :Pas moi, parce que c'est ce que j'utilise. La guerre contre systemd
n'est pas une guerre contre systemd sur le serveur mais global. Les
sites internet critiquant systemd disent que personne ne doit
l'utiliser parce que c'est le mal absolu. Mais que ce soit le mal
absolu pour les serveurs ou pour l'embarqué n'est pas mon problème.
Moi, c'est sur un poste de travail que je l'utilise.
Remarque bien, il n'y a aucune raison que les problèmes rencontrés
ailleurs que sur un poste de travail ne finissent pas par arriver
sur un poste de travail.
Je ne sais pas à quel point il est mal ficelé. Moi ce que je sais,
c'est que ça marche bien chez moi.
Ce n'est pas parce que ça marche chez toi que ça marche partout. La
preuve est mince.
Problème pour serveur et embarqué, je veux bien. Pour poste de travail,
je n'ai rien vu.
Ce n'est pas parce que tu n'as rien vu que ces problèmes n'existent
pas.
Pour le nombre de PID, faut se mettre d'accord. Soit c'est la
philosophie Unix de la séparaion des tâches et ça donne une
augmentation des PID. Soit on a un truc monolithique qui fait tout
avec un seul PID. Une augmentation du nombre de PID est plutôt une
bonne nouvelle pour moi, ça veut dire que c'est moins monolithique
que ce qui est annoncé.
Là encore, je me contrefiche du nombre de PID dans l'absolu. Le
problème de l'explosion des PID, c'est la consommation des
ressources (nombre de fichiers ouverts, temps CPU au sens temps
système et non utilisateur...).
