Comme d'hab, ça n'est pas que je n'aime pas systemd (il y a plein de bonnes idées dedans), mais la manière dont c'est fait et présenté. Mes quelques remarques :
systemd est constitué de plus de 70 binaires (NdT : 72 sur ma machine !) clairement séparés.
Qui ont leur propres standards d'options et ne réutilisent pas l'existant. Être modulaire, c'est une chose, mais généralement quand on dit ça c'est qu'on interagit bien avec le reste de l'écosystème. Ça va dans le sens du « il faut tout réapprendre », qui peut parfois être nécessaire, certes, mais là c'est vraiment « on refait tout sans utiliser l'existant ». Pourquoi pas, mais de là à se vanter de séparer ses modules et de se dire modulaire au sens d'UNIX... Busybox fait ça, de manière un peu moins « je remplace tout » puisqu'il remplace tout, mais avec des commandes qui respectent scrupuleusement la syntaxe de celles d'origine.
Par exemple, l’idée d’UNIX du « tout est fichier » trouve son jumeau dans systemd où tous les services sont exposés au lancement dans un système de fichiers du noyau, le cgroupfs.
Dommage, cette idée vient d'être foutue en l'air pour les prochaines version de systemd, cf http://lists.freedesktop.org/archives/systemd-devel/2013-June/011521.html : tout devra passer par l'API dbus désormais. On pourra éventuellement, pour la lecture, passer par cgroupfs, mais je vous laisse déguster la syntaxe de la nouvelle hiérarchie (la compatibilité ascendante c'est pour les nuls), par exemple ici présentée dans le projet libvirt : http://libvirt.org/cgroups.html
Ensuite, la façon dont notre projet est géré (c'est-à-dire maintenir la majeure partie du cœur de l’OS dans un unique dépôt git) est plus proche du modèle BSD (qui est un vrai UNIX, pas comme Linux) dans la façon de faire (où la plus grande partie du cœur de l’OS est conservé dans un seul répertoire CVS/SVN) que de la façon de faire de Linux.
Ça, effectivement, c'est quelque chose de vraiment embêtant je trouve.
systemd n’est pas la mafia. C’est un logiciel libre, vous pouvez en faire ce que vous voulez, ce qui inclut ne pas l’utiliser. C’est plutôt l’opposé de « forcer ».
C'est tellement hypocrite... les devs du kernel ont même fait des rustines spéciales pour udev, c'est dire s'ils n'ont pas été « forcés ».
Un but de systemd est d’unifier un peu le paysage dispersé de Linux. Nous essayons de nous débarrasser de beaucoup des différences inutiles entre distributions dans différents domaines du cœur de l’OS.
Voilà, ça c'est plus honnête. J'aimerais bien que les devs avouent juste ça : on veut essayer de faire une nouvelle « API » de l'OS, devenir la nouvelle couche d'abstraction des services (voire plus), et ça sera forcément moins UNIX que l'était System V (franchement, du XML c'est pas très UNIX...). Encore une fois, pourquoi pas, mais il faut arrêter de jouer les vierges effarouchées quand on vous le renvoie dans la figure.
Faux, vous pouvez désactiver et remplacer à peu près n’importe quel bout de systemd, à de très rares exceptions près.
Sauf que systemd couvre tellement de choses qu'il est impossible pour des libristes bénévoles d'espérer rattraper ça.
Après, c'est peut-être ça l'avenir du Libre : ça devient plus professionnel, et les petits bénévoles ne pourront plus suivre le développement des composants au cœur du système. Je ne sais pas si c'est un bien ou un mal.
# À mon tour
Posté par benoar . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 10.
Comme d'hab, ça n'est pas que je n'aime pas systemd (il y a plein de bonnes idées dedans), mais la manière dont c'est fait et présenté. Mes quelques remarques :
Qui ont leur propres standards d'options et ne réutilisent pas l'existant. Être modulaire, c'est une chose, mais généralement quand on dit ça c'est qu'on interagit bien avec le reste de l'écosystème. Ça va dans le sens du « il faut tout réapprendre », qui peut parfois être nécessaire, certes, mais là c'est vraiment « on refait tout sans utiliser l'existant ». Pourquoi pas, mais de là à se vanter de séparer ses modules et de se dire modulaire au sens d'UNIX... Busybox fait ça, de manière un peu moins « je remplace tout » puisqu'il remplace tout, mais avec des commandes qui respectent scrupuleusement la syntaxe de celles d'origine.
Dommage, cette idée vient d'être foutue en l'air pour les prochaines version de systemd, cf http://lists.freedesktop.org/archives/systemd-devel/2013-June/011521.html : tout devra passer par l'API dbus désormais. On pourra éventuellement, pour la lecture, passer par cgroupfs, mais je vous laisse déguster la syntaxe de la nouvelle hiérarchie (la compatibilité ascendante c'est pour les nuls), par exemple ici présentée dans le projet libvirt : http://libvirt.org/cgroups.html
Ça, effectivement, c'est quelque chose de vraiment embêtant je trouve.
C'est tellement hypocrite... les devs du kernel ont même fait des rustines spéciales pour udev, c'est dire s'ils n'ont pas été « forcés ».
Voilà, ça c'est plus honnête. J'aimerais bien que les devs avouent juste ça : on veut essayer de faire une nouvelle « API » de l'OS, devenir la nouvelle couche d'abstraction des services (voire plus), et ça sera forcément moins UNIX que l'était System V (franchement, du XML c'est pas très UNIX...). Encore une fois, pourquoi pas, mais il faut arrêter de jouer les vierges effarouchées quand on vous le renvoie dans la figure.
Sauf que systemd couvre tellement de choses qu'il est impossible pour des libristes bénévoles d'espérer rattraper ça.
Après, c'est peut-être ça l'avenir du Libre : ça devient plus professionnel, et les petits bénévoles ne pourront plus suivre le développement des composants au cœur du système. Je ne sais pas si c'est un bien ou un mal.