Re: À mon tour

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.

Quel existant? Plein de commandes de systemd n’existaient pas avant. En plus avec ces commandes peuvent facilement être utilisées dans des scripts par exemple.

Ou alors tu parles de SysV ou de l’init à la BSD d’Arch, et à ce moment-là c’est un peu con parce que justement un des buts de systemd c’était d’éliminer le code Bash exécuté au démarrage; à moins que tu ne parles d’Upstart qui a une conception très différente de systemd.

Du coup je ne comprends pas trop ce que tu reproches à systemd, est-ce que tu pourrais être plus précis?

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

Je ne vois pas ce qu’il y a de mal, systemd est en quelque sortes une couche d’abstraction du noyau; normal qu’il empêche les autres programmes de mettre le bazar et qu’il donne des API pour les programmes externes. Et la hiérarchie a l’air plutôt propre comme ça.

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.

En quoi?

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 ».

Non c’est pas hypocrite, c’est les autres projets qui sont venus se greffer à systemd, pas le contraire.

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...).

Il n’y a jamais eu de XML dans systemd, et même s’il y en avait le XML c’est pas un truc maléfique hein.

Encore une fois, pourquoi pas, mais il faut arrêter de jouer les vierges effarouchées quand on vous le renvoie dans la figure.

Bah systemd propose de nouvelles API et les gens les utilisent, c’est tout.

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.

Avant ils faisaient comment avec SysV et tout?

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.

Et genre les «petits bénévoles» avant ils modifiaient SysV ou Upstart? Non. De la même façon, les «petits bénévoles» ne vont pas faire de grosses modifications au cœur de Firefox.

Mais il reste beaucoup de petits projets qui manquent de bras aussi.

Écrit en Bépo selon l’orthographe de 1990