Le fait est qu'il est plus facile de faire tout proprement en integrant toute la chaine que de diviser le tout en 25 projets differents qui n'auront pas autant de traction et en dispersant les forces.
C'est marrant, ya quelques temps on me balançait l'argument contraire : systemd est super modulaire, il est bien divisé, il y a plein d'outils « indépendants »... Mais en fait, quand on creuse, non, tout est intégré à tout, et on a beau avoir des commandes séparées, elles utilisent leurs conventions légèrement différentes d'Unix, leur format spécifique, etc. Mais bon, ça a été clairement annoncé par Lennart, donc au moins on ne peut pas lui reprocher de cacher ses ambitions.
Dernière critique en date sur laquelle je suis tombé : http://lists.busybox.net/pipermail/busybox/2014-January/080379.html
(de Denys Vlasenko, lead developer de busybox, qui est ironiquement aussi un truc « tout en un » mais qui essaye de le faire en respectant les standards Unix, lui).
Et c'est marrant ton argument sur la « traction » d'un projet unique, sans « disperser » les forces : le LL en général est quand même plutôt basé sur un ensemble de projets indépendants, ou en tous cas un ensemble de développeurs indépendants, qui mettent leur travail ensemble. Là, prendre tous les devs qui sont chez Red Hat (même si je sais que RH n'est pas une boîte comme les autres qui ne va pas complètement pouvoir imposer sa vue à tous les devs qu'elle embauche) pour bosser sur un truc unique qui va « révolutionner » le Libre, je trouve ça dangereux, au contraire. Je pense qu'une des réussites du Libre, c'est de faire travailler ensemble des gens qui ont des objectifs différents, mais qui s'en accommodent. Si on commence à avoir une armée de devs à la botte d'une seule boîte, aussi bienveillante soit-elle (en général j'aime bien tout ce que fait RH, j'avoue que systemd est un des seuls trucs qui me picote un peu), ça peut facilement partir en sucette par la suite.
Integrer ca aide clairement a faire bouger les choses, un seul projet dans lequel ameliorer les choses, impactant toutes les distributions moderne de linux, pas de probleme de synchronisation de version, ...
On dirait le discours de Shutlleworth... Non, je pense qu'il est impossible d'arriver à synchroniser tout, et même si c'est moins efficace, c'est mieux comme ça. Un peu comme une démocratie est vachement moins « efficace » qu'une dictature : oui, il faut mettre tout le monde d'accord pour avancer, au lieu de juste écouter un mec, mais c'est pour le mieux de tous. Pour info, je « viens » plutôt du monde Debian, où le truc important ça n'est pas tant le code, mais la constitution (le mot n'est pas anodin).
C'est ceux qui codent qui font la direction, Redhat a certe un certain nombre de dev, mais ils n'ont pas le pouvoir d'imposer leur solution. De meme pour Ubuntu.
Oui, ceux qui codent font la direction, et RH a une bonne partie des devs systemd, udev, etc, il me semble. Ubuntu, eux, ils ont quelques mecs important mais j'ai toujours eu une impression de lacune technique globale, quand même : il ont débauchés quelques balèzes, mais globalement ça donne une résultat très bof, pas réfléchi. RH, au contraire, quand je vois leurs projets, je suis toujours assez impressionné. Là je bosse pas mal sur libvirt, et tu vois que c'est un putain de truc bien réfléchi. Pour parler du même domaine, tu vois rapidement qu'OpenStack c'est un gros bordel ; pourtant, tu as un paquet de monde qui bosse dessus. RH s'est « plié » commercialement à s'intégrer dans OpenStack, mais techniquement, tu vois bien qu'ils maîtrisent libvirt, et qu'ils font du OpenStack parce que ça marche commercialement, mais ils gardent la maîtrise technique de leurs outils.
C'était juste un exemple, mais c'était pour dire que chez RH, la domination des codeurs permet d'imposer leurs solutions car ils sont mieux « organisés », ou je ne sais pas trop pourquoi, mais en tous cas ils sont forts. Je connais peu d'autres boîtes qui sont capables de ça, c'est pour ça que d'un côté, je les admire, mais de l'autre (pour systemd), ils me font peur.
Il y a une raison pour que Systemd progresse bien plus vite et couvre bien plus de cas d'usage que Upstart...
Parce que ça a été architecturé et développé par des mecs plus balèzes, mieux organisés. Même si niveau expertise technique, je pense que Lennart part beaucoup trop sur l'approche « table rase ».
[^] # Re: Mini précision, variable d'environnement
Posté par benoar . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 3.
C'est marrant, ya quelques temps on me balançait l'argument contraire : systemd est super modulaire, il est bien divisé, il y a plein d'outils « indépendants »... Mais en fait, quand on creuse, non, tout est intégré à tout, et on a beau avoir des commandes séparées, elles utilisent leurs conventions légèrement différentes d'Unix, leur format spécifique, etc. Mais bon, ça a été clairement annoncé par Lennart, donc au moins on ne peut pas lui reprocher de cacher ses ambitions.
Dernière critique en date sur laquelle je suis tombé : http://lists.busybox.net/pipermail/busybox/2014-January/080379.html
(de Denys Vlasenko, lead developer de busybox, qui est ironiquement aussi un truc « tout en un » mais qui essaye de le faire en respectant les standards Unix, lui).
Et c'est marrant ton argument sur la « traction » d'un projet unique, sans « disperser » les forces : le LL en général est quand même plutôt basé sur un ensemble de projets indépendants, ou en tous cas un ensemble de développeurs indépendants, qui mettent leur travail ensemble. Là, prendre tous les devs qui sont chez Red Hat (même si je sais que RH n'est pas une boîte comme les autres qui ne va pas complètement pouvoir imposer sa vue à tous les devs qu'elle embauche) pour bosser sur un truc unique qui va « révolutionner » le Libre, je trouve ça dangereux, au contraire. Je pense qu'une des réussites du Libre, c'est de faire travailler ensemble des gens qui ont des objectifs différents, mais qui s'en accommodent. Si on commence à avoir une armée de devs à la botte d'une seule boîte, aussi bienveillante soit-elle (en général j'aime bien tout ce que fait RH, j'avoue que systemd est un des seuls trucs qui me picote un peu), ça peut facilement partir en sucette par la suite.
On dirait le discours de Shutlleworth... Non, je pense qu'il est impossible d'arriver à synchroniser tout, et même si c'est moins efficace, c'est mieux comme ça. Un peu comme une démocratie est vachement moins « efficace » qu'une dictature : oui, il faut mettre tout le monde d'accord pour avancer, au lieu de juste écouter un mec, mais c'est pour le mieux de tous. Pour info, je « viens » plutôt du monde Debian, où le truc important ça n'est pas tant le code, mais la constitution (le mot n'est pas anodin).
Oui, ceux qui codent font la direction, et RH a une bonne partie des devs systemd, udev, etc, il me semble. Ubuntu, eux, ils ont quelques mecs important mais j'ai toujours eu une impression de lacune technique globale, quand même : il ont débauchés quelques balèzes, mais globalement ça donne une résultat très bof, pas réfléchi. RH, au contraire, quand je vois leurs projets, je suis toujours assez impressionné. Là je bosse pas mal sur libvirt, et tu vois que c'est un putain de truc bien réfléchi. Pour parler du même domaine, tu vois rapidement qu'OpenStack c'est un gros bordel ; pourtant, tu as un paquet de monde qui bosse dessus. RH s'est « plié » commercialement à s'intégrer dans OpenStack, mais techniquement, tu vois bien qu'ils maîtrisent libvirt, et qu'ils font du OpenStack parce que ça marche commercialement, mais ils gardent la maîtrise technique de leurs outils.
C'était juste un exemple, mais c'était pour dire que chez RH, la domination des codeurs permet d'imposer leurs solutions car ils sont mieux « organisés », ou je ne sais pas trop pourquoi, mais en tous cas ils sont forts. Je connais peu d'autres boîtes qui sont capables de ça, c'est pour ça que d'un côté, je les admire, mais de l'autre (pour systemd), ils me font peur.
Parce que ça a été architecturé et développé par des mecs plus balèzes, mieux organisés. Même si niveau expertise technique, je pense que Lennart part beaucoup trop sur l'approche « table rase ».