Le 14/12/2016 17:42, Mrjk a écrit :
Sur ce point ci, je vais mettre en avant l'idée de convergence plutôt que de parler de l'implémentation technique de systemd en tant que tel.
Ma réponse: Oui, et non. Je ne sais pas si le parallèle est juste, mais essayons: Mettons que tu remettes en cause les GNU Coreutils, as-tu une alternative viable équivalente sur ta distro préférée? (je ne compte pas les busybox, et dérivés ...) Je ne pense pas, et je ne crois pas que personne s'en plaigne. Les GNU Coreutils sont maintenant en standard sur la plupart des distro, et personne ne remet en cause ce fait là; mais ça n'a pas empêché chacune de ces distro de vivre dans son coin, avec sa propre philosophie, et ses propres manières de faire.
TRÈS mauvaise analogie : 1/ Il y a des alternatives et tu en cites toi-même (mais tu refuses de les prendre en compte parce que... ?) 2/ Les shells le réimplémentent en grande partie en builtins (man bash, man zshbuiltins, etc.) 3/ Chaque binaire est indépendant, contrairement à systemd. Il y a plusieurs voix qui se sont élévées pour indiquer que l'intégration de Debian/Ubuntu qui n'utilisent que la partie "init" de systemd est mauvaise parce que ça a des effets de bords contrairement à Arch/Fedora pour qui l'intégration à 100% mène à un système plus stable. On notera que les développeurs de systemd crient pourtant à qui veut l'entendre que leur init est très modulaire.
Les coreutils sont clairement moins essentiels que tu l'indiques au fonctionnement du système (à plus forte raison si tu utilises systemd) et finalement, les produits qui reposent dessus sont plutôt peu nombreux (genre... les autres systèmes d'init).
Et si tout le monde utilise les GNU coreutils c'est parce que : 1/ La licence est correcte (les BSD coreutils sont.... sous licence BSD quoi) 2/ Ils ont prouvé leur fiabilité
Les distributions utilisant GNU coreutils ou la GNU libc ne le font pas parce que "c'est standard" mais parce que c'est celui qui convient le mieux, sinon il y a d'autres distribs qui en utilisent d'autres parce qu'elles visent des besoins spécifiques.
systemd n'est que l'init qui convient le mieux aux distributions qui veulent packager Gnome comme environnement par défaut. Et c'est dommage que plus de distributions ne fassent pas plutôt le choix de se débarasser de cette UI plutôt que de forcer systemd qui ne convient pas à de nombreux usages.
Bien que systemd mange toute la différenciation sur les couches basses et essentielles du système, je l'imagine un peu comme les coreutils, qui sera considéré à terme comme outils intrinsèquement lié à Linux. La différenciation des distros se fera sur autre chose que des scripts d'init fait maison (et tout ce que Systemd peut englober). C'est une histoire de timing tout ça, mais bon GNU/Linux ne s'est pas fait en un jour non plus, et les standards peuvent mettre du temps à s'installer.
Le problème est que systemd englobe trop de choses, justement, et profite de la mainmise de Red Hat sur de nombreux projets pour ne pas laisser le choix aux autres distributions. Le mail de Lennart Poettring parlant du merge de udev dans systemd est symptomatique de ça[1]. Et comme les devs de Busybox le disent si bien[2] : "systemd people are not willing to play nice with the rest of the world. Therefore there is no reason for the rest of the world to cooperate with them."
[1] https://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html [2] https://git.busybox.net/busybox/commit/?id=accd9eeb719916da974584b33b1aeced5...