et les seuls qui ne veulent pas sont ceux qui n'aiment pas le changement et veulent garder le "bohneur" de la maintenance pourrie de ce qui existe avant.
Euh.... Même si il y a énormément de trolls contre systemd, il y a des raisons parfaitement valides d'être contre. Le fait de ne pas vouloir autant de dépendances dans un système d'init est un point tout à fait valide. L'init c'est la première chose que va faire le système, si ca merde à ce moment là vous ne pouvez rien faire pour corriger le tir. Vouloir le garder aussi maigre que possible n'est pas fondamentalement idiot.
Ensuite à l'heure actuelle il existe un certains nombres de matériels que l'on ne peut (toujours) pas initialiser proprement avec systemd. Typiquement les matériels multi-étage. Par exemple si vous devez initialiser une architecture crossbar sur laquelle est posée un émulateur réseau matériel (grosse station sun typiquement) systemd ne verra pas les cartes réseaux au moment de l'initialisation du réseau, et quand il les verra enfin pleins de services se seront déjà vautrés parce qu'il aura voulu anticiper l'ouverture des ports sur des cartes qu'il ne connait que plus tard. Idem pour les pinpad, si vous avez besoin de taper un code sur un clavier externe (ie pas le clavier de la machine) pour débloquer votre disque dur, à l'heure actuelle vous ne disposez d'aucun moyen de booter avec systemd à l'heure actuelle.
Autre problème, systemd n'est pas turing complet et décide tout seul dans quel scope il se lance (essayez d'altérer les cgroups de lancement de systemd pour rire - surtout si c'est pour rajouter des restrictions en plus du taging). Mur assuré. Si vous avez déjà vos politiques cgroups et selinux, vous pouvez prier qu'elles soient compatibles avec systemd, parceque l'alternative est probablement de redéfinir des politiques à partir de 0... Certains logiciels (dont l'excellent HAProxy) ne peuvent tout simplement être lancés par systemd. En cas de reload systemd va interpréter l'arrêt du logiciel comme une panne et va tenter de le relancer avec les paramètres qu'il a en mémoire et dans le scope qu'il juge bon. Moralité vous êtes bon pour écrire des wrappers à la pelle ou à ne plus jamais utiliser de restart (sur un proxy c'est très emmerdant).
Mais le truc qui m'emmerde le plus personnellement ce sont les templates d'une pourritude rare. Avec sysVinit ou bsdinit il est très facile de faire un script qui va prendre en paramètre une flopée de commandes et/ou de variables et me démarrer un service en fonction de ces variables. Par exemple pour créer un réseau virtuel avec un dhcp sur un segment IP donnée dynamiquement ca me prend une demi ligne de code. Je n'ai pas encore trouvé comment faire ça avec systemd. Il faut créer un service à la volée, l'enregistrer puis l'initialiser , savoir dès le début si on compte le relancer ou pas (sinon il faut faire un script pour le désinscrire au cas ou). ca devient d'une complexité démentielle de créer dynamiquement trois VM et de les mettre en réseau.
Systemd a des idées géniales et de très bons cotés, mais dans le travail que je fais en ce moment il n'est pas adapté. Et par pas adapté je ne vaux par dire "j'ai pas envie de tout réécrire et d'apprendre systemd" je veux dire "Systemd m'empêche sciemment et volontairement de mettre en place les outils dont j'ai absolument besoin pour travailler".
Mon point de vue est le suivant : systemd rend la vie de 95% des gens plus facile dans 95% des cas, c'était aussi le cas d'internet explorer 5.0
[^] # Re: GNU/SystemD/Linux
Posté par Kaane . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 10.
et les seuls qui ne veulent pas sont ceux qui n'aiment pas le changement et veulent garder le "bohneur" de la maintenance pourrie de ce qui existe avant.
Euh.... Même si il y a énormément de trolls contre systemd, il y a des raisons parfaitement valides d'être contre. Le fait de ne pas vouloir autant de dépendances dans un système d'init est un point tout à fait valide. L'init c'est la première chose que va faire le système, si ca merde à ce moment là vous ne pouvez rien faire pour corriger le tir. Vouloir le garder aussi maigre que possible n'est pas fondamentalement idiot.
Ensuite à l'heure actuelle il existe un certains nombres de matériels que l'on ne peut (toujours) pas initialiser proprement avec systemd. Typiquement les matériels multi-étage. Par exemple si vous devez initialiser une architecture crossbar sur laquelle est posée un émulateur réseau matériel (grosse station sun typiquement) systemd ne verra pas les cartes réseaux au moment de l'initialisation du réseau, et quand il les verra enfin pleins de services se seront déjà vautrés parce qu'il aura voulu anticiper l'ouverture des ports sur des cartes qu'il ne connait que plus tard. Idem pour les pinpad, si vous avez besoin de taper un code sur un clavier externe (ie pas le clavier de la machine) pour débloquer votre disque dur, à l'heure actuelle vous ne disposez d'aucun moyen de booter avec systemd à l'heure actuelle.
Autre problème, systemd n'est pas turing complet et décide tout seul dans quel scope il se lance (essayez d'altérer les cgroups de lancement de systemd pour rire - surtout si c'est pour rajouter des restrictions en plus du taging). Mur assuré. Si vous avez déjà vos politiques cgroups et selinux, vous pouvez prier qu'elles soient compatibles avec systemd, parceque l'alternative est probablement de redéfinir des politiques à partir de 0... Certains logiciels (dont l'excellent HAProxy) ne peuvent tout simplement être lancés par systemd. En cas de reload systemd va interpréter l'arrêt du logiciel comme une panne et va tenter de le relancer avec les paramètres qu'il a en mémoire et dans le scope qu'il juge bon. Moralité vous êtes bon pour écrire des wrappers à la pelle ou à ne plus jamais utiliser de restart (sur un proxy c'est très emmerdant).
Mais le truc qui m'emmerde le plus personnellement ce sont les templates d'une pourritude rare. Avec sysVinit ou bsdinit il est très facile de faire un script qui va prendre en paramètre une flopée de commandes et/ou de variables et me démarrer un service en fonction de ces variables. Par exemple pour créer un réseau virtuel avec un dhcp sur un segment IP donnée dynamiquement ca me prend une demi ligne de code. Je n'ai pas encore trouvé comment faire ça avec systemd. Il faut créer un service à la volée, l'enregistrer puis l'initialiser , savoir dès le début si on compte le relancer ou pas (sinon il faut faire un script pour le désinscrire au cas ou). ca devient d'une complexité démentielle de créer dynamiquement trois VM et de les mettre en réseau.
Systemd a des idées géniales et de très bons cotés, mais dans le travail que je fais en ce moment il n'est pas adapté. Et par pas adapté je ne vaux par dire "j'ai pas envie de tout réécrire et d'apprendre systemd" je veux dire "Systemd m'empêche sciemment et volontairement de mettre en place les outils dont j'ai absolument besoin pour travailler".
Mon point de vue est le suivant : systemd rend la vie de 95% des gens plus facile dans 95% des cas, c'était aussi le cas d'internet explorer 5.0