Voila ce qu'en disait Thomas Vander Stichele, un core dev de GStreamer / Fludo (et accessoirement sympathisant des ambitions de PA) pas plus tard que la semaine dernière : http://thomas.apestaart.org/log/?p=1012
C'est aussi ce que je reproche le plus à PA. Il est affreusement buggué, certes.
Mais le problème n'est pas là ; comme tout logiciel très utilisés, il pourrait se bonifier rapidement et ne pas (trop) taper sur le système de ses utilisateurs s'il n'était pas si opaque, automagique et uber-complexe, tout ce qui fait que peu de gens rapportent les bugs qu'ils rencontrent, et peu de gens peuvent aussi les contourner ou trouver des workarounds. Aussi, la personnalité de Lennart Poettering n'aide pas forcément (à faire des rapports de bugs, à faire reconnaitre qu'un comportement donné est un bug, à faire admettre des workarounds pour avoir le son qui marche dans la vraie vie, celle des users de desktops)...
Un logiciel libre très utilisé qui donne à ses utilisateurs les moyens de faire des bons rapports de bugs, sinon de le fixer eux-même (doc interne, doc des interactions, messages d'erreurs clairs, aux bons endroits et bien formulés, modes verbose efficaces, etc) est promis à une stabilité irréprochable en un rien de temps. Après 5 ans d'existence PA ne devrait pas en être encore au stade du "je pers le controle de la carte son et je ne loggue rien".
Merde, même le noyau - et c'est pourtant pas facile à ce niveau du système - est incroyablement plus débugguable que PA (printk très pertinents, docs riches, myriades d'outils de traçage, profiling, débogguage des verroux, des problèmes mémoire, netconsole, autodocumentation des états internes via /proc et /sys ...) ! Résultat, les bugs sont corrigés. Et les développeurs kernel ne t'envoient pas chier parce que tu rencontre un bug en utilisant un logiciel proprio sur leur système, ou rejettent une solution réduisant drastiquement les problèmes parce qu'elle serait "moins pure" (voyez la récente aventure d'Alan Cox et des standards posix relatifs aux ttys).
Vous faites quoi, vous, quand PA décide, sur votre système, de ne plus sortir de son, ou crash silencieusement ? vous arrivez à trouver de quoi faire un rapport de bug ? perso je lance un strace en desespoir de cause (mais ça ne sert à rienà, puis le le "/etc/init.d/pulseaudio restart" (inutile aussi, visiblement PA ne doit pas être lancé ainsi), puis je reboot. Classe.
[^] # Re: Phonon était pas prêt
Posté par herodiade . En réponse au journal Qt/Phonon bientôt mort et remplacé. Évalué à 10.
Voila ce qu'en disait Thomas Vander Stichele, un core dev de GStreamer / Fludo (et accessoirement sympathisant des ambitions de PA) pas plus tard que la semaine dernière :
http://thomas.apestaart.org/log/?p=1012
C'est aussi ce que je reproche le plus à PA. Il est affreusement buggué, certes.
Mais le problème n'est pas là ; comme tout logiciel très utilisés, il pourrait se bonifier rapidement et ne pas (trop) taper sur le système de ses utilisateurs s'il n'était pas si opaque, automagique et uber-complexe, tout ce qui fait que peu de gens rapportent les bugs qu'ils rencontrent, et peu de gens peuvent aussi les contourner ou trouver des workarounds. Aussi, la personnalité de Lennart Poettering n'aide pas forcément (à faire des rapports de bugs, à faire reconnaitre qu'un comportement donné est un bug, à faire admettre des workarounds pour avoir le son qui marche dans la vraie vie, celle des users de desktops)...
Un logiciel libre très utilisé qui donne à ses utilisateurs les moyens de faire des bons rapports de bugs, sinon de le fixer eux-même (doc interne, doc des interactions, messages d'erreurs clairs, aux bons endroits et bien formulés, modes verbose efficaces, etc) est promis à une stabilité irréprochable en un rien de temps. Après 5 ans d'existence PA ne devrait pas en être encore au stade du "je pers le controle de la carte son et je ne loggue rien".
Merde, même le noyau - et c'est pourtant pas facile à ce niveau du système - est incroyablement plus débugguable que PA (printk très pertinents, docs riches, myriades d'outils de traçage, profiling, débogguage des verroux, des problèmes mémoire, netconsole, autodocumentation des états internes via /proc et /sys ...) ! Résultat, les bugs sont corrigés. Et les développeurs kernel ne t'envoient pas chier parce que tu rencontre un bug en utilisant un logiciel proprio sur leur système, ou rejettent une solution réduisant drastiquement les problèmes parce qu'elle serait "moins pure" (voyez la récente aventure d'Alan Cox et des standards posix relatifs aux ttys).
Vous faites quoi, vous, quand PA décide, sur votre système, de ne plus sortir de son, ou crash silencieusement ? vous arrivez à trouver de quoi faire un rapport de bug ? perso je lance un strace en desespoir de cause (mais ça ne sert à rienà, puis le le "/etc/init.d/pulseaudio restart" (inutile aussi, visiblement PA ne doit pas être lancé ainsi), puis je reboot. Classe.