La communication par Twitter est un problème en soi. Mais par contre c’est Asahi l’upstream ici, donc si quelqu’un a un intérêt dans ce que produit Asahi, c’est à lui de contacter Asahi, pas l’inverse. C’est ça l’essentiel du message à la base malgré la forme du tweet/
Pour se faire une idée d’à quel point "expérimental" veut dire dans ce contexte, on peut donner cet exemple : récemment une personne contribuant à Asahi a publié une vidéo titrée « ÇA MARCHE! GNOME, Firefox, applications KDE, tout !!!! ». Et effectivement à première vue ça marche... SAUF QUE de ce que j’ai lu à droite et à gauche, il y a un énorme HACK qui est utilisé pour contourner un gros bug, et ce hack ce serait d’éteindre et rallumer le GPU à chaque frame. Quelqu’un qui livrerait ça ce serait un peu comme livrer une voiture qui, pour pouvoir être conduite par des tiers et rouler y compris à 120 sur l’autoroute, le démarreur doit être maintenu continuellement en marche et le frein jamais touché. Si Manjaro livre des choses expérimentales d’Asahi sans concertation avec Asahi, les utilisateurs sont à risque de recevoir ce genre de choses, et peut-être pire.
Quand on développe, on peut avoir des situations où les choses commencent à prendre vraiment forme, suffisamment pour en faire des démos, mais en sachant qu’il y a des trucs bien sales voire des choses super risquées qu’il ne faut pas du tout faire. Le développeur qui fait la démo peut faire exprès de ne PAS faire ci ou ça, ne PAS cliquer là, etc. Mais dans une démo contrôlée pour communiquer sur l’avancement (ce sont déjà des succès énorme, chaque bug après l’autre) on ne peut pas tout dire, et parfois le développeur n’a que des intuitions sur ce qui serait super risqué de faire sur la base de ce qu’il sait avoir grossièrement dégrossi à l’arrache.
Ça peut donc être très préoccupant pour un développeur de voir son patch se retrouver en prod alors qu’il n’est public que par amour de l’open source, méthode de travail, transparence, communication, toussa, ou même rien que pour se faire mousser, et se dire « merde ça peut flinguer le matos des gens il y a que moi qui le sait et ce gus il a pris mon code et il leur a donné sans même me demander s’il y avait un risque 😱️ ».
Là récemment je suis de près le travail sur rusticl, un nouveau pilote OpenCL pour Mesa. Le développeur a publié une copie d’écran de LuxMark fonctionnant avec une carte Radeon, puis que le pilote "passait la conformité OpenCL 3.0 CTS", j’ai démontré la capacité à utiliser plusieurs GPUs en même temps et la couverture large des générations de matériel, puis j’ai montré que Darktable fonctionnait. Vu comme ça c’est super excitant. Ça a l’air de marcher et tout. Certains pourraient être tentés de livrer ça sur la base de ces images et autres témoignages. En fait il y a d’énormes limitations, par exemple le compilateur ne sait pas encore gérer les appels de fonctions donc toutes les fonctions sont "inlinées". Le premier benchmark de LuxMark marche parce que le code est simple, mais prend le deuxième et 20h après le compilateur OpenCL compile encore sur ton Ryzen de compétition et le process te bouffe 70Go de mémoire. Alors ici ça va peut-être pas flinguer ton matos (mais qui sait?), mais tu vas possiblement paniquer ton kernel ou juste voir ton PC planter par manque de ressource. Mais qui sait tout ça ? Le développeur qui sait précisément là où il en est dans son code, et là où il n’est pas. Comment moi je sais ça ? Parce que je discute avec le développeur, je teste ce qu’il produit, lui fait des rapports sur mes tests, il corrige en fonction de mes rapports, etc.
J’imagine que les gens d’Asahi ont aussi plein de trucs qu’on ne peut pas savoir si on n’est pas avec eux à chaque étape. Ils font des jolies démos, ils montrent le travail accompli, et PAF ils voient leur code hautement expérimental qui n’est pas beaucoup plus qu’une preuve de concept être distribué par un tiers comme un produit "releasé", et sans même s’être enquit d e quoi que ce soit avant... Et ce tiers est genre un inconnu qu’ils ne voient jamais ? Comment pourrait-il savoir ce qu’il fait ? Il ne peut pas savoir ce qu’il fait, c’est impossible.
Il y a des arguments intéressant. Ils précisent bien qu’il n’y a pas de problème à ce que les gens aient envie d’essayer des trucs.
Mais là on a des gens qui font essayer à d’autre ce qu’ils n’ont pas développés et les autres (ceux qui essaient) n’ont pas l’initiative de l’essai. Les testeurs n’ont ni l’initiative du développement ni l’initiative du test. Et celui qui livre le travail du développeur au testeur ne communique pas avec le développeur sur les risques et les manières de livrer ça au testeur, et il n’est pas clair dans sa communication auprès du testeur non-plus (à part dire que c’est tout neuf tout beau).
Un des arguments avancés c’est notamment que les projets amonts qui souffrent de la mauvaise réputation que font les utilisateurs trahis par les intermédiaires. Ceci peut pousser les développeurs à cessent de travailler de manière ouverte et transparente.
Et au delà de ça il y a un vrai problème concernant le fait que, non, s’il y a une vidéo, une copie d’écran, un tweet d’émerveillement concernant une étape atteinte dans un produit en cours de développement, non ce n’est pas livrable.
Je donne un autre exemple : Le moteur Dæmon qui propulse le jeu Unvanquished est un descendant du moteur XreaL. Il y a dix ans, les développeurs d’XreaL avaient montré des vidéos excitantes de fonctions en cours de développement. Depuis, il y a quelqu’un qui passe de temps en temps pour nous cracher à la gueule en disant que les développeurs ne savent pas ce qu’ils font, qu’ils gâchent tout, etc. Qu’ils retirent des fonctionnalités, et que c’est bien la preuve de leur incompétence car ça montrent qu’ils ne savent pas comment ça marche ni le maintenir, etc. La réalité, c’est qu’XreaL était une preuve de concept. Un tas de preuve de concepts posées à côté les unes des autres (parfois même pas empilées les unes sur les autres). Chaque fonctionnalité que l’on voit dans les vieilles vidéos, en gros elle marchent mais une à la fois. T’en active deux ça pète. Aucun produit fini n’a jamais existé avec ces fonctionnalités. J’ai moi-même terminé l’implémentation d’un code qui avait été incorporé à l’état de brouillon il y a dix ans et jamais touché depuis : le code des "heightmaps". Un point qui montre que c’était une preuve de concept c’est que la carte codait la hauteur si la donnée était stockée dans un fichier à part et codait la profondeur si la même donnée était stockée dans un fichier stockant d’autres données. Et si on activait la fonctionnalité, toute absence de canal alpha dans une image était interprétée comme une profondeur maximum (!!!), ce qui avait poussé le développeur de la preuve de concept à implémenter un mot-clé (à écrire pour chaque image !!!) pour « empêcher de lire l’absence de canal alpha » (lol) pour contourner le bug du bug du bug. Bref. Les copies d’écrans et vidéos étaient séduisantes. Mais entre le jour où les vidéos ont été faites (ou même des démos jouables distribuées) et le jour 10 ans plus tard où j’ai transformé le code depuis l’état « preuve de concept qui pour marcher demande d’enregistrer les données de manière incorrectes et de configurer chaque données pour dire au moteur de faire une autre erreur qui annule la première » en implémentation correcte, j’ai pourtant été témoin années après années des plaintes disant que les développeurs étaient incompétents et qu’ils supprimaient des fonctionnalités qui marchaient avant, que tout marchait avant, etc.
Et d’ailleurs pendant dix ans j’ai vu quelqu’un promettre ce genre de tas de preuve de concept à des gens en leur vantant monts et merveilles, pour les laisser dans la désillusion amère quelques années plus tard, recommençant la montagne russe émotionnelle avec des nouvelles victimes toutes les X années. Il y a des gens comme ça, qui se placent entre les développeurs amonts et les utilisateurs, qui ont d’ailleurs assez de compétence pour être un développeur amont s’ils voulaient travailler en équipe (mais ce serait inconcevable), et qui utilisent surtout ces compétences pour vendre du rêve à des victimes toujours renouvelées. Parfois ils arrivent quand même à livrer des choses vraiment intéressantes avec des gens satisfaits quand même, parfois ils ne laissent que de la souffrance, et dans tous les cas les développeurs amonts sont dénigrés, ignorés, voire calomniés avec des ribambelles d’utilisateurs indirects biberonnés à du dénigrement, si ce n’est de la haine ou du mensonge envers les développeurs amont.
Je ne connais pas Manjaro, je ne sais rien de plus que le fait qu’ils auraient distribués une preuve du concept sans concertation avec le projet amont, je ne dis pas qu’il y a plus grave comme ce que j’ai dit avoir vu dans d’autres projets. Mais je comprends tout à fait que cet évènement cristallise les souffrances de plein de gens, et pas forcément à cause de leur implication dans les projets en question, mais aussi à cause de leur propre expérience dans d’autres projets. Et ça ressemble quand même au schéma de l’équipe qui vend du rêve sur le travail des autres en se plaçant comme intermédiaire opaque et mettant ses utilisateurs à risque (ne serait-ce qu’au risque de la déception, du découragement et autres poisons émotionnels).
En général quand il y a quelqu’un qui livre à des utilisateurs le travail d’un autre sans concertation avec un autre et que ça devient constitutif de la méthode de travail, il y a rapidement d’autres trucs bien toxiques qui couvent et font surface de façon pas très honnêtes. Par exemple, l’absence de communication avec l’amont, si elle s’installe, devient du passif-agressif, passif-agressif qui devra être rationalisé pour être supportable par son acteur, et donc rationalisé en calomnies ou en haine ou autres choses justifiant a postériori l’absence de communication. Quand bien même à la base l’absence de communication n’était motivée que pour se présenter comme un sauveur et satisfaire un besoin narcissique par exemple, sans aucune haine ni calomnie ni malveillance initiale envers les autres.
Des gens qui vivent ce genre d’expérience, il y en a beaucoup en fait. Peut-être que Manjaro paie pour les autres, à cause du motif, du "pattern". Mais ça ne m’étonne pas que ce petit fait divers soit en train de popper dans plusieurs de mes flux d’informations à la fois. Marmite, vapeur, pression, toussa. Ça aurait pu être un autre déclencheur.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: twit ?
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal ManjaroARM se fait épingler par Asahi Linux. Évalué à 10.
La communication par Twitter est un problème en soi. Mais par contre c’est Asahi l’upstream ici, donc si quelqu’un a un intérêt dans ce que produit Asahi, c’est à lui de contacter Asahi, pas l’inverse. C’est ça l’essentiel du message à la base malgré la forme du tweet/
Pour se faire une idée d’à quel point "expérimental" veut dire dans ce contexte, on peut donner cet exemple : récemment une personne contribuant à Asahi a publié une vidéo titrée « ÇA MARCHE! GNOME, Firefox, applications KDE, tout !!!! ». Et effectivement à première vue ça marche... SAUF QUE de ce que j’ai lu à droite et à gauche, il y a un énorme HACK qui est utilisé pour contourner un gros bug, et ce hack ce serait d’éteindre et rallumer le GPU à chaque frame. Quelqu’un qui livrerait ça ce serait un peu comme livrer une voiture qui, pour pouvoir être conduite par des tiers et rouler y compris à 120 sur l’autoroute, le démarreur doit être maintenu continuellement en marche et le frein jamais touché. Si Manjaro livre des choses expérimentales d’Asahi sans concertation avec Asahi, les utilisateurs sont à risque de recevoir ce genre de choses, et peut-être pire.
Quand on développe, on peut avoir des situations où les choses commencent à prendre vraiment forme, suffisamment pour en faire des démos, mais en sachant qu’il y a des trucs bien sales voire des choses super risquées qu’il ne faut pas du tout faire. Le développeur qui fait la démo peut faire exprès de ne PAS faire ci ou ça, ne PAS cliquer là, etc. Mais dans une démo contrôlée pour communiquer sur l’avancement (ce sont déjà des succès énorme, chaque bug après l’autre) on ne peut pas tout dire, et parfois le développeur n’a que des intuitions sur ce qui serait super risqué de faire sur la base de ce qu’il sait avoir grossièrement dégrossi à l’arrache.
Ça peut donc être très préoccupant pour un développeur de voir son patch se retrouver en prod alors qu’il n’est public que par amour de l’open source, méthode de travail, transparence, communication, toussa, ou même rien que pour se faire mousser, et se dire « merde ça peut flinguer le matos des gens il y a que moi qui le sait et ce gus il a pris mon code et il leur a donné sans même me demander s’il y avait un risque 😱️ ».
C’est un variante de « si c’est sur Internet c’est pour être utilisé » : « si c’est sur Internet c’est que c’est prêt pour la production ».
Là récemment je suis de près le travail sur rusticl, un nouveau pilote OpenCL pour Mesa. Le développeur a publié une copie d’écran de LuxMark fonctionnant avec une carte Radeon, puis que le pilote "passait la conformité OpenCL 3.0 CTS", j’ai démontré la capacité à utiliser plusieurs GPUs en même temps et la couverture large des générations de matériel, puis j’ai montré que Darktable fonctionnait. Vu comme ça c’est super excitant. Ça a l’air de marcher et tout. Certains pourraient être tentés de livrer ça sur la base de ces images et autres témoignages. En fait il y a d’énormes limitations, par exemple le compilateur ne sait pas encore gérer les appels de fonctions donc toutes les fonctions sont "inlinées". Le premier benchmark de LuxMark marche parce que le code est simple, mais prend le deuxième et 20h après le compilateur OpenCL compile encore sur ton Ryzen de compétition et le process te bouffe 70Go de mémoire. Alors ici ça va peut-être pas flinguer ton matos (mais qui sait?), mais tu vas possiblement paniquer ton kernel ou juste voir ton PC planter par manque de ressource. Mais qui sait tout ça ? Le développeur qui sait précisément là où il en est dans son code, et là où il n’est pas. Comment moi je sais ça ? Parce que je discute avec le développeur, je teste ce qu’il produit, lui fait des rapports sur mes tests, il corrige en fonction de mes rapports, etc.
J’imagine que les gens d’Asahi ont aussi plein de trucs qu’on ne peut pas savoir si on n’est pas avec eux à chaque étape. Ils font des jolies démos, ils montrent le travail accompli, et PAF ils voient leur code hautement expérimental qui n’est pas beaucoup plus qu’une preuve de concept être distribué par un tiers comme un produit "releasé", et sans même s’être enquit d e quoi que ce soit avant... Et ce tiers est genre un inconnu qu’ils ne voient jamais ? Comment pourrait-il savoir ce qu’il fait ? Il ne peut pas savoir ce qu’il fait, c’est impossible.
Récemment j’ai découvert cette page : https://dont-ship.it/
Il y a des arguments intéressant. Ils précisent bien qu’il n’y a pas de problème à ce que les gens aient envie d’essayer des trucs.
Mais là on a des gens qui font essayer à d’autre ce qu’ils n’ont pas développés et les autres (ceux qui essaient) n’ont pas l’initiative de l’essai. Les testeurs n’ont ni l’initiative du développement ni l’initiative du test. Et celui qui livre le travail du développeur au testeur ne communique pas avec le développeur sur les risques et les manières de livrer ça au testeur, et il n’est pas clair dans sa communication auprès du testeur non-plus (à part dire que c’est tout neuf tout beau).
Un des arguments avancés c’est notamment que les projets amonts qui souffrent de la mauvaise réputation que font les utilisateurs trahis par les intermédiaires. Ceci peut pousser les développeurs à cessent de travailler de manière ouverte et transparente.
Et au delà de ça il y a un vrai problème concernant le fait que, non, s’il y a une vidéo, une copie d’écran, un tweet d’émerveillement concernant une étape atteinte dans un produit en cours de développement, non ce n’est pas livrable.
Je donne un autre exemple : Le moteur Dæmon qui propulse le jeu Unvanquished est un descendant du moteur XreaL. Il y a dix ans, les développeurs d’XreaL avaient montré des vidéos excitantes de fonctions en cours de développement. Depuis, il y a quelqu’un qui passe de temps en temps pour nous cracher à la gueule en disant que les développeurs ne savent pas ce qu’ils font, qu’ils gâchent tout, etc. Qu’ils retirent des fonctionnalités, et que c’est bien la preuve de leur incompétence car ça montrent qu’ils ne savent pas comment ça marche ni le maintenir, etc. La réalité, c’est qu’XreaL était une preuve de concept. Un tas de preuve de concepts posées à côté les unes des autres (parfois même pas empilées les unes sur les autres). Chaque fonctionnalité que l’on voit dans les vieilles vidéos, en gros elle marchent mais une à la fois. T’en active deux ça pète. Aucun produit fini n’a jamais existé avec ces fonctionnalités. J’ai moi-même terminé l’implémentation d’un code qui avait été incorporé à l’état de brouillon il y a dix ans et jamais touché depuis : le code des "heightmaps". Un point qui montre que c’était une preuve de concept c’est que la carte codait la hauteur si la donnée était stockée dans un fichier à part et codait la profondeur si la même donnée était stockée dans un fichier stockant d’autres données. Et si on activait la fonctionnalité, toute absence de canal alpha dans une image était interprétée comme une profondeur maximum (!!!), ce qui avait poussé le développeur de la preuve de concept à implémenter un mot-clé (à écrire pour chaque image !!!) pour « empêcher de lire l’absence de canal alpha » (lol) pour contourner le bug du bug du bug. Bref. Les copies d’écrans et vidéos étaient séduisantes. Mais entre le jour où les vidéos ont été faites (ou même des démos jouables distribuées) et le jour 10 ans plus tard où j’ai transformé le code depuis l’état « preuve de concept qui pour marcher demande d’enregistrer les données de manière incorrectes et de configurer chaque données pour dire au moteur de faire une autre erreur qui annule la première » en implémentation correcte, j’ai pourtant été témoin années après années des plaintes disant que les développeurs étaient incompétents et qu’ils supprimaient des fonctionnalités qui marchaient avant, que tout marchait avant, etc.
Et d’ailleurs pendant dix ans j’ai vu quelqu’un promettre ce genre de tas de preuve de concept à des gens en leur vantant monts et merveilles, pour les laisser dans la désillusion amère quelques années plus tard, recommençant la montagne russe émotionnelle avec des nouvelles victimes toutes les X années. Il y a des gens comme ça, qui se placent entre les développeurs amonts et les utilisateurs, qui ont d’ailleurs assez de compétence pour être un développeur amont s’ils voulaient travailler en équipe (mais ce serait inconcevable), et qui utilisent surtout ces compétences pour vendre du rêve à des victimes toujours renouvelées. Parfois ils arrivent quand même à livrer des choses vraiment intéressantes avec des gens satisfaits quand même, parfois ils ne laissent que de la souffrance, et dans tous les cas les développeurs amonts sont dénigrés, ignorés, voire calomniés avec des ribambelles d’utilisateurs indirects biberonnés à du dénigrement, si ce n’est de la haine ou du mensonge envers les développeurs amont.
Je ne connais pas Manjaro, je ne sais rien de plus que le fait qu’ils auraient distribués une preuve du concept sans concertation avec le projet amont, je ne dis pas qu’il y a plus grave comme ce que j’ai dit avoir vu dans d’autres projets. Mais je comprends tout à fait que cet évènement cristallise les souffrances de plein de gens, et pas forcément à cause de leur implication dans les projets en question, mais aussi à cause de leur propre expérience dans d’autres projets. Et ça ressemble quand même au schéma de l’équipe qui vend du rêve sur le travail des autres en se plaçant comme intermédiaire opaque et mettant ses utilisateurs à risque (ne serait-ce qu’au risque de la déception, du découragement et autres poisons émotionnels).
En général quand il y a quelqu’un qui livre à des utilisateurs le travail d’un autre sans concertation avec un autre et que ça devient constitutif de la méthode de travail, il y a rapidement d’autres trucs bien toxiques qui couvent et font surface de façon pas très honnêtes. Par exemple, l’absence de communication avec l’amont, si elle s’installe, devient du passif-agressif, passif-agressif qui devra être rationalisé pour être supportable par son acteur, et donc rationalisé en calomnies ou en haine ou autres choses justifiant a postériori l’absence de communication. Quand bien même à la base l’absence de communication n’était motivée que pour se présenter comme un sauveur et satisfaire un besoin narcissique par exemple, sans aucune haine ni calomnie ni malveillance initiale envers les autres.
Des gens qui vivent ce genre d’expérience, il y en a beaucoup en fait. Peut-être que Manjaro paie pour les autres, à cause du motif, du "pattern". Mais ça ne m’étonne pas que ce petit fait divers soit en train de popper dans plusieurs de mes flux d’informations à la fois. Marmite, vapeur, pression, toussa. Ça aurait pu être un autre déclencheur.
ce commentaire est sous licence cc by 4 et précédentes