Mais c'est bien d'avoir des couches. Le but de ces couches est de mutualiser le travail, ne pas réinventer la roue, avoir des composants plus solides.
J'ai moinssé pour cette phrase précise, alors que je ne comptais pas intervenir dans un thread mort... mais la, non.
Dans le cas de systemd, ça reste discutable, honnêtement. Moi, je n'apprécie pas, avec probablement de mauvaises raisons, éventuellement de bonnes: par exemple, je pense qu'un PID 1 ne devrais que se contenter d'initialiser le système, et lancer un superviseur pour les logiciels qui ont besoin de l'être. J'ai l'impression, du haut de mon manque d'éducation, que systemd utilise le même processus, et donc le même fichier de code source, pour initialiser le système ET superviser les daemons.
Sur ce point, je trouve sysVinit mieux foutu dans le sens ou sysVinit ne supervise (sisi, il supervise un peu, prenez une distro avec lui, et mettez /bin/false à la place de /sbin/getty dans l'inittab...) que des outils peu intelligents: basiquement, il ne supervise que agetty sur une Debian. Il me semble donc plutôt capable de superviser un superviseur plus puissant, qui ne lance les services qu'à la demande et/ou que après que les pré-conditions soient remplies.
Le problème est qu'il n'offre aucun outil qui permette de le faire, et donc, chaque distro s'étant basé sur sysVinit, à bricolé son gestionnaire de daemons, à grand coups de bourne scripts plus ou moins bien ficelés... et le résultat est ingérable pour Debian (mon opinion).
Donc, dans le cas de systemd, je peux accepter cette phrase.
La raison pour laquelle j'ai moinssé, j'ai parce que, au taf, j'ai été confronté à npm. Hors, des... gens... probablement très intelligents... hum... oui, ça doit être ça... fournissent un module pour tester si un nombre est négatif. Ce module, s'appuie sur un module qui teste si un nombre est positif, et en inverse juste le résultat.
Penses-tu vraiment que c'est toujours bien d'avoir des couches? Ne penses-tu pas que le fait d'ajouter, et d'utiliser, une couche doit être réfléchi en fonction du cas d'usage?
L'exemple que j'ai pris est, franchement, extrêmement stupide (mais tristement réel), contrairement à systemd. Mais dans le cas de systemd, je pense que dans certains cas il ne se justifie pas, par exemple est-il utile d'avoir la complexité de systemd qui dépends de dbus et d'une implémentation maison de cron dans un système embarqué, ou la taille des binaires compte?
Dans cet exemple, je crois qu'il n'est pas bon d'avoir des couches, car ça complexifie le débogage (il faut déboguer toutes les couches alors que potentiellement juste attaquer le matos peut être plus simple) et à un coût non négligeable en bande passante réseau (corriger les failles de sécu sans trop impacter le forfait pas cher est parfois un voeu du chef).
Et bizarrement, il n'y a pas grand monde pour se bouger à maintenir les scripts init à l'ancienne, preuve que pas grande monde trouvait SysV si bien que cela à maintenir et à l'usage...
Je connais par l'usage au moins 2 distributions non basées sur systemd. L'une est voidlinux, basée sur runit, l'autre est devuan, et j'ai cru voir un article sur lwn disant que, justement, les tensions se calmeraient pour garder en vie le vieux sysV. Si ça se fait, compte tenu que devuan (que peu ici imaginaient faire le boulot nécessaire pour réussir à publier une version stable) compte passer à openrc (de ce que j'ai compris sur irc, hein), j'imagine qu'il n'est pas impossible qu'un jour, sysV soit lâché, mais d'avoir une alternative à systemd.
Je pense que la réalité est plus complexe que ce que ne veulent faire avaler les gens qui soutiennent absolument systemd. L'inverse est malheureusement vrai aussi.
[^] # Re: systemd32.exe
Posté par freem . En réponse au journal [HS] Microsoft ♥ Linux - Episode IV L'attaque des clones. Évalué à 2.
J'ai moinssé pour cette phrase précise, alors que je ne comptais pas intervenir dans un thread mort... mais la, non.
Dans le cas de systemd, ça reste discutable, honnêtement. Moi, je n'apprécie pas, avec probablement de mauvaises raisons, éventuellement de bonnes: par exemple, je pense qu'un PID 1 ne devrais que se contenter d'initialiser le système, et lancer un superviseur pour les logiciels qui ont besoin de l'être. J'ai l'impression, du haut de mon manque d'éducation, que systemd utilise le même processus, et donc le même fichier de code source, pour initialiser le système ET superviser les daemons.
Sur ce point, je trouve sysVinit mieux foutu dans le sens ou sysVinit ne supervise (sisi, il supervise un peu, prenez une distro avec lui, et mettez /bin/false à la place de /sbin/getty dans l'inittab...) que des outils peu intelligents: basiquement, il ne supervise que agetty sur une Debian. Il me semble donc plutôt capable de superviser un superviseur plus puissant, qui ne lance les services qu'à la demande et/ou que après que les pré-conditions soient remplies.
Le problème est qu'il n'offre aucun outil qui permette de le faire, et donc, chaque distro s'étant basé sur sysVinit, à bricolé son gestionnaire de daemons, à grand coups de bourne scripts plus ou moins bien ficelés... et le résultat est ingérable pour Debian (mon opinion).
Donc, dans le cas de systemd, je peux accepter cette phrase.
La raison pour laquelle j'ai moinssé, j'ai parce que, au taf, j'ai été confronté à npm. Hors, des... gens... probablement très intelligents... hum... oui, ça doit être ça... fournissent un module pour tester si un nombre est négatif. Ce module, s'appuie sur un module qui teste si un nombre est positif, et en inverse juste le résultat.
Penses-tu vraiment que c'est toujours bien d'avoir des couches? Ne penses-tu pas que le fait d'ajouter, et d'utiliser, une couche doit être réfléchi en fonction du cas d'usage?
L'exemple que j'ai pris est, franchement, extrêmement stupide (mais tristement réel), contrairement à systemd. Mais dans le cas de systemd, je pense que dans certains cas il ne se justifie pas, par exemple est-il utile d'avoir la complexité de systemd qui dépends de dbus et d'une implémentation maison de cron dans un système embarqué, ou la taille des binaires compte?
Dans cet exemple, je crois qu'il n'est pas bon d'avoir des couches, car ça complexifie le débogage (il faut déboguer toutes les couches alors que potentiellement juste attaquer le matos peut être plus simple) et à un coût non négligeable en bande passante réseau (corriger les failles de sécu sans trop impacter le forfait pas cher est parfois un voeu du chef).
Je connais par l'usage au moins 2 distributions non basées sur systemd. L'une est voidlinux, basée sur runit, l'autre est devuan, et j'ai cru voir un article sur lwn disant que, justement, les tensions se calmeraient pour garder en vie le vieux sysV. Si ça se fait, compte tenu que devuan (que peu ici imaginaient faire le boulot nécessaire pour réussir à publier une version stable) compte passer à openrc (de ce que j'ai compris sur irc, hein), j'imagine qu'il n'est pas impossible qu'un jour, sysV soit lâché, mais d'avoir une alternative à systemd.
Je pense que la réalité est plus complexe que ce que ne veulent faire avaler les gens qui soutiennent absolument systemd. L'inverse est malheureusement vrai aussi.