Tu aurais aussi pu cliquer sur le premier, qui pointe sur le 3eme. ( et vers d'autres articles de qualités comme "apt vs yum, what is the best one", et sans doute d'autres )
Le 3eme date de 2011, donc ça reste un document qui parle des premières versions de systemd, et qui n'abordent pas les features rajoutés par la suite ( genre les fonctions de sécurités de coupure du réseau, systemd-nspawn, etc).
Donc les arguments techniques ( car on va éviter ceux sur "propagande de RH avec tout son argent" en pointant la doc de systemd sur freedesktop , ç'est assez peu convaincant ) sont les suivants suivi de mon rebuttal :
L'argument est assez mal construit. Soit il veut dire qu'il y a déjà des outils come monit/runit, et auquel cas, je dirais que /bin/init le fait aussi, soit il veut dire que la feature est déjà utilisé avant, et auquel cas je dirait qu'il s'agit juste de coder ce qui est utilisé.
"collecting information on daemon crashes". C'est vrai, init ne le fait pas, et dans la philosophie d'avant, c'est fait par le kernel sous la forme de la création d'un coredump quelque part sur le FS. Ce que systemd fait, c'est d'enregistrer le coredump dans journald, et de sauver divers infos. Et ça n'implique pas de ne pas faire les choses à coté si quelqu'un le veux aussi, tout comme systemd n'implique pas de retirer les appels à chroot et/ou setuid bien que le faisant également ( appels parfois mal fait par les daemons, quand le logiciel ne fait pas de chdir avant ou d'initgroups, mais bon, on le saurait si la réécriture du code sans arrêt implique de faire des erreurs de temps en temps )
keeping control with cgroups. L'argument est faible, car pour lui, on a pas besoin d'utiliser les cgroups car on peut juste utiliser les cgroups. Je suppose qu'il veut dire "y a pas besoin d'utiliser les cgroups dans le binaire d'init car on peut juste demander à tout les scripts de le faire directement". Mais la, curieusement, il ne dit pas "good luck making the author conform to a single standard", alors que visiblement, c'est ce qui arriverais.
delayed on demand. La, l'auteur dit que ça sert à rien ( car la ram sur sa workstation est suffisante et/ou la swap sert à ça ), et si jamais ça venait à servir, on peut déjà le faire via xinetd ( car soyons sérieux, inetd est un peu merdique à utiliser, et je mentirais si je faisait la comparaison en le prenant comme base ). Le fait que par exemple xinetd ne supporte pas les sockets unix, le fait que ça supporte pas les scripts d'init classiques, c'est des détails d'implémentation. Détail que personne n'a codé depuis que xinetd existe mais sans doute parce que ça sert à rien ( le fait que cups s'en serve, que X11 sur mac s'en serve et que j'ai une dizaine d'autres trucs sur mon laptop montre peut être que ça sert pas à rien ). L'auteur loupe aussi que ç'est pas juste "économiser de la ram", mais surtout assurer la parallélisation par design.
"dependency based service management". La, le mec semble vivre dans un monde à part, car "on range les choses dans un ordre arbitraire", ça n'a rien à voir avec la gestion de dépendance. Par exemple, la gestion de dépendance, ça implique que la transaction échoue si une dep échoue. Chose que sysvinit ne fait pas. Mais je peux reconnaitre que je voit fort peu d'usage en local ( à part "postfix a besoin que ldap soit up sinon il rejette les mails" et ce genre de choses ). Et bien sur, le mec n'a pas lu la doc de systemd, car l'option --ignore-dependencies existe. Donc la partie sur "l'admin doit pouvoir faire ce qu'il veut" est factuellement incorrect.
la partie sur autofs est light sur les détails. Je ne pige pas exactement ce qu'il veut dire, car je voit moi que les unités sont pour la plupart lancé après local-fs.target, donc le souci ne semble pas vraiment se poser dans mon cas d'usage. Mais bon, je ne m'y connais pas en autofs, à part que autofs sur linux fait jurer mon coloc à intervalles régulier. Je vais donc laisser le bénéfice du doute.
listening on hardware change. Que je sache, ç'est fait via udev. Et donc ça rentre dans "c'est déjà fait ailleurs". Donc c'est un peu creux comme argument, surtout parce qu'il est pas détaillé des masses. Au passage, upstart va bien plus loin que systemd et gère les choses de façons bien plus poussé, comme le montre un des développeurs : http://ifdeflinux.blogspot.fr/2013/04/upstart-user-sessions-in-ubuntu-raring.html ( c'est vers la fin ).
enfin, l'argument qui tue : "dbus, c'est orienté desktop, car c'est dans le nom". Il y a aucun example de ce qu'il propose de mieux comme les sunrpc de nfs, java rmi, ou faire ça en xml-rpc par dessus le réseau, en soap ? Je suis pas sur que ça soit mieux, tout le monde rale sur soap, sunrpc est inutilisé ( et semble un peu compliqué à utiliser ). Mais encore une fois, sans argument, j'aurais tendance à dire que c'est un détail. Après tout, d'autres composants ( nm, upstart, bluez, wpa_supplicant pour ne citer qu'eux) passent aussi par dbus donc ça a une certaine logique de se baser sur ce que les autres font.
Donc au final, les arguments sont très discutables. Certains sont incorrects ( le 5 ), d'autres sont assez peu explicites ( le 6, le 8, le 1 ), d'autres sont pas très clairs car ça demande à réutiliser des choses existantes ce qui est le cas ( le 3, le 7 ). Il reste donc le 2 et le 4, à savoir la gestion des crashs, qui n'obligent à rien ( et qui reste une feature pour journald, donc hors du pid 1 ) et la partie sur le démarrage à la demande.
[^] # Re: GNU/SystemD/Linux
Posté par Misc (site web personnel) . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 8.
Tu aurais aussi pu cliquer sur le premier, qui pointe sur le 3eme. ( et vers d'autres articles de qualités comme "apt vs yum, what is the best one", et sans doute d'autres )
Le 3eme date de 2011, donc ça reste un document qui parle des premières versions de systemd, et qui n'abordent pas les features rajoutés par la suite ( genre les fonctions de sécurités de coupure du réseau, systemd-nspawn, etc).
Donc les arguments techniques ( car on va éviter ceux sur "propagande de RH avec tout son argent" en pointant la doc de systemd sur freedesktop , ç'est assez peu convaincant ) sont les suivants suivi de mon rebuttal :
L'argument est assez mal construit. Soit il veut dire qu'il y a déjà des outils come monit/runit, et auquel cas, je dirais que /bin/init le fait aussi, soit il veut dire que la feature est déjà utilisé avant, et auquel cas je dirait qu'il s'agit juste de coder ce qui est utilisé.
"collecting information on daemon crashes". C'est vrai, init ne le fait pas, et dans la philosophie d'avant, c'est fait par le kernel sous la forme de la création d'un coredump quelque part sur le FS. Ce que systemd fait, c'est d'enregistrer le coredump dans journald, et de sauver divers infos. Et ça n'implique pas de ne pas faire les choses à coté si quelqu'un le veux aussi, tout comme systemd n'implique pas de retirer les appels à chroot et/ou setuid bien que le faisant également ( appels parfois mal fait par les daemons, quand le logiciel ne fait pas de chdir avant ou d'initgroups, mais bon, on le saurait si la réécriture du code sans arrêt implique de faire des erreurs de temps en temps )
keeping control with cgroups. L'argument est faible, car pour lui, on a pas besoin d'utiliser les cgroups car on peut juste utiliser les cgroups. Je suppose qu'il veut dire "y a pas besoin d'utiliser les cgroups dans le binaire d'init car on peut juste demander à tout les scripts de le faire directement". Mais la, curieusement, il ne dit pas "good luck making the author conform to a single standard", alors que visiblement, c'est ce qui arriverais.
delayed on demand. La, l'auteur dit que ça sert à rien ( car la ram sur sa workstation est suffisante et/ou la swap sert à ça ), et si jamais ça venait à servir, on peut déjà le faire via xinetd ( car soyons sérieux, inetd est un peu merdique à utiliser, et je mentirais si je faisait la comparaison en le prenant comme base ). Le fait que par exemple xinetd ne supporte pas les sockets unix, le fait que ça supporte pas les scripts d'init classiques, c'est des détails d'implémentation. Détail que personne n'a codé depuis que xinetd existe mais sans doute parce que ça sert à rien ( le fait que cups s'en serve, que X11 sur mac s'en serve et que j'ai une dizaine d'autres trucs sur mon laptop montre peut être que ça sert pas à rien ). L'auteur loupe aussi que ç'est pas juste "économiser de la ram", mais surtout assurer la parallélisation par design.
"dependency based service management". La, le mec semble vivre dans un monde à part, car "on range les choses dans un ordre arbitraire", ça n'a rien à voir avec la gestion de dépendance. Par exemple, la gestion de dépendance, ça implique que la transaction échoue si une dep échoue. Chose que sysvinit ne fait pas. Mais je peux reconnaitre que je voit fort peu d'usage en local ( à part "postfix a besoin que ldap soit up sinon il rejette les mails" et ce genre de choses ). Et bien sur, le mec n'a pas lu la doc de systemd, car l'option --ignore-dependencies existe. Donc la partie sur "l'admin doit pouvoir faire ce qu'il veut" est factuellement incorrect.
la partie sur autofs est light sur les détails. Je ne pige pas exactement ce qu'il veut dire, car je voit moi que les unités sont pour la plupart lancé après local-fs.target, donc le souci ne semble pas vraiment se poser dans mon cas d'usage. Mais bon, je ne m'y connais pas en autofs, à part que autofs sur linux fait jurer mon coloc à intervalles régulier. Je vais donc laisser le bénéfice du doute.
listening on hardware change. Que je sache, ç'est fait via udev. Et donc ça rentre dans "c'est déjà fait ailleurs". Donc c'est un peu creux comme argument, surtout parce qu'il est pas détaillé des masses. Au passage, upstart va bien plus loin que systemd et gère les choses de façons bien plus poussé, comme le montre un des développeurs :
http://ifdeflinux.blogspot.fr/2013/04/upstart-user-sessions-in-ubuntu-raring.html ( c'est vers la fin ).
enfin, l'argument qui tue : "dbus, c'est orienté desktop, car c'est dans le nom". Il y a aucun example de ce qu'il propose de mieux comme les sunrpc de nfs, java rmi, ou faire ça en xml-rpc par dessus le réseau, en soap ? Je suis pas sur que ça soit mieux, tout le monde rale sur soap, sunrpc est inutilisé ( et semble un peu compliqué à utiliser ). Mais encore une fois, sans argument, j'aurais tendance à dire que c'est un détail. Après tout, d'autres composants ( nm, upstart, bluez, wpa_supplicant pour ne citer qu'eux) passent aussi par dbus donc ça a une certaine logique de se baser sur ce que les autres font.
Donc au final, les arguments sont très discutables. Certains sont incorrects ( le 5 ), d'autres sont assez peu explicites ( le 6, le 8, le 1 ), d'autres sont pas très clairs car ça demande à réutiliser des choses existantes ce qui est le cas ( le 3, le 7 ). Il reste donc le 2 et le 4, à savoir la gestion des crashs, qui n'obligent à rien ( et qui reste une feature pour journald, donc hors du pid 1 ) et la partie sur le démarrage à la demande.