C'est simpliste comme raisonnement. La question n'est pas celle de la responsabilité (évidemment que le composant qui a le bug est responsable, et doit être corrigé), mais du maintien des fonctionnalités: si il existe un moyen de faire marcher, aussi moche soit-il, il est normal que tout composant ne l'utilisant pas soit perçu comme fautif.
En gros, non il n'est pas normal de remplacer un composant qui marche par un autre qui marche moins sous prétexte qu'un tiers est pourri. La bonne démarche est de (faire) corriger les bugs, puis seulement de procéder au remplacement, et d'utiliser les contournements dans l'intervalle. Forcément ça prend plus de temps (notamment parce qu'on ne peut pas mettre la pression sur le composant fautif par le biais d'utilisateurs frustrés), mais au moins il n'y a pas de dommages collatéraux.
Sinon en allant par là on pourrait aussi estimer que les applis n'ont pas à contourner les bugs des libs, les libs n'ont pas à contourner les bugs des drivers, les drivers n'ont pas à contourner les bugs du noyau, le noyau n'a pas à contourner les bugs du compilateur, et le compilateur n'a pas à contourner les bugs du CPU (et du reste du matos d'ailleurs). Alors oui, à la fin on aurait sans doute un système très élégant où tout le monde fait exactement ce qu'il doit...
Ou alors peut-être qu'on n'aurait rien du tout parce que tout le monde serait en train d'attendre qu'un fondeur produise le CPU parfait, alors qu'aucun fondeur ne survit plus de 3 mois puisque virtuellement personne n'achète de CPU (pourquoi faire quand on n'a même pas de compilo fonctionnel?)
Bref, sans pragmatisme on ne va pas très loin. Ou, dit autrement, le fantasme de la réécriture complète qui va corriger tous les problèmes par la pureté architecturale n'est que ça, un fantasme. De ce point de vue la gestion de l'introduction de PA était un désastre: pas d'un point de vue "scientifique", mais d'un point de vue d'ingénieur.
La seule raison pour laquelle c'est "passé", c'est que ce n'était "que" de l'audio.
C'est un fait, en matière d'informatique le monde entier tourne sur des workarounds dégueu.
[^] # Re: Mwai
Posté par Yann Hodique (site web personnel) . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 7.
C'est simpliste comme raisonnement. La question n'est pas celle de la responsabilité (évidemment que le composant qui a le bug est responsable, et doit être corrigé), mais du maintien des fonctionnalités: si il existe un moyen de faire marcher, aussi moche soit-il, il est normal que tout composant ne l'utilisant pas soit perçu comme fautif.
En gros, non il n'est pas normal de remplacer un composant qui marche par un autre qui marche moins sous prétexte qu'un tiers est pourri. La bonne démarche est de (faire) corriger les bugs, puis seulement de procéder au remplacement, et d'utiliser les contournements dans l'intervalle. Forcément ça prend plus de temps (notamment parce qu'on ne peut pas mettre la pression sur le composant fautif par le biais d'utilisateurs frustrés), mais au moins il n'y a pas de dommages collatéraux.
Sinon en allant par là on pourrait aussi estimer que les applis n'ont pas à contourner les bugs des libs, les libs n'ont pas à contourner les bugs des drivers, les drivers n'ont pas à contourner les bugs du noyau, le noyau n'a pas à contourner les bugs du compilateur, et le compilateur n'a pas à contourner les bugs du CPU (et du reste du matos d'ailleurs). Alors oui, à la fin on aurait sans doute un système très élégant où tout le monde fait exactement ce qu'il doit...
Ou alors peut-être qu'on n'aurait rien du tout parce que tout le monde serait en train d'attendre qu'un fondeur produise le CPU parfait, alors qu'aucun fondeur ne survit plus de 3 mois puisque virtuellement personne n'achète de CPU (pourquoi faire quand on n'a même pas de compilo fonctionnel?)
Bref, sans pragmatisme on ne va pas très loin. Ou, dit autrement, le fantasme de la réécriture complète qui va corriger tous les problèmes par la pureté architecturale n'est que ça, un fantasme. De ce point de vue la gestion de l'introduction de PA était un désastre: pas d'un point de vue "scientifique", mais d'un point de vue d'ingénieur.
La seule raison pour laquelle c'est "passé", c'est que ce n'était "que" de l'audio.
C'est un fait, en matière d'informatique le monde entier tourne sur des workarounds dégueu.