> sans souci de fournir un support de niveau professionnel.
Le support est une autre chose, j'y reviendrai, mais là on parlait de qualité. La formule « de niveau professionnel » c'est exactement l'idéologie que je présentai. Il y aurai une hiérarchie secrète avec un « niveau amateur » (de la merde, je suppose ?) et un « niveau professionel » (ok, t'a pas les sources, mais c'est vraiment bon) ? Dois-je te rappeler que, par exemple, Apache et le kernel Linux se sont longtemps développés sans le moindre support du monde « professionnel », et qu'ils se sont imposés den environnement serveur justement pour leur soucis de qualité ? Et qu'il en va de même de la majorité des projets libres ?
Soutenir que la qualité des solutions propriétaires, fermées et « professionnelles » dépasse nécessaire les projets sur sourceforge est un peu léger. Dois-je t'indiquer que quelques personnes pensent que plus il y a de paires d'yeux sur le code (il faut qu'il soit ouvert), meilleur est le code ?
> Non, ce n'est pas de l'ironie. Tu connais une API qui permet de faire du streaming audio/video bidirectionel, de gérer webcam et microphone, tout ça de façon transparente et correcte que l'on soit sous Windows, Linux et MacOS ?
Mais PLEIN ! Gstreamer, Xine, VLC, NIMM, ...
Il font très bien ce que tu décrit au-dessus, précisément. Ils ne font pas tout ce que Flash fait, mais ce n'est pas leur objectif (ils font d'autres choses mieux, par ailleurs). Dans le même ordre que Gstreamer pour le multimédia, si l'on parle de rendu 2D, Cairo est un modèle de qualité logicielle, qui n'a vraiment rien à envier à qui que ce soit, surtout à Flash. Le code source de Cairo, c'est de l'art.
Pour finir, désolé mais « sous Windows, Linux et MacOS », ce n'est pas vraiment ce que j'appelle la portabilité. La miriade de « micro-projets soutenus par un développeur unique » dont tu parle plus haut fait généralement bien mieux.
> Tu en parleras aux développeurs d'OpenSSL, de la liboil, etc. Des Jacky Windowsiens ?
Apparemment tu n'a pas lu ce que j'ai écris, ou tu fait semblant. Pour résumer j'ai répété que « premature optimisation is the root of all evil ».
J'ai rappelé que dans le monde du libre, les optimisations comptent, mais après la sécurité, la stabilité et la portabilité, dans la hiérarchie de la « qualité logicielle » (et on parle de logiciels desktop grand public). On optimise, certes, mais _après_. On prend le temps de faire une architecture logicielle où les optimisations trouvent naturellement leur place sans bloquer les autres priorités cités plus haut.
Là où très clairement Flash s'est vautré (en lisant le blog que tu cite, on voit dans un post précédent le pauvre développeur s'embrouiller dans ses jackyteries asm qu'il ne sait pas porter sur x86_64, et toute son appli est bloquée par ça ...).
Tu m'interroge sur OpenSSL et liboil. Pour liboil, cet objectif de qualité et d'architecture propre est tout simplement ... la cause originelle du projet (disjoindre la question des optimisations de l'implem de Flash ou d'autre chose), tout autant que la méthode du projet (fournir un code C, avec ou sans intrinsics, qui marche partout, et éventuellement y adjoindre des implems mmx/altivec/... utilisables lorsque l'environnement les supporte). Dans le cas d'OpenSSL c'est une évidence vitale : sur la portabilité tu ne trouvera rien à leur reprocher, surtout en comparaison avec flash, et sur la stabilité et la sécurité, tu pourra difficilement soutenir qu'il ne s'agit pas d'une priorité.
> Ah, finalement l'argument est bien mince : quand c'est la liboil qui fait des optimisations asm, c'est bien, quand c'est le lecteur Flash, ce sont des Jacky Windowsiens ?
Oui, et je maintien. Cf. ce que je dit juste avant (et que j'ai pourtant expliqué dans le post grand-parent). L'objectif de performances de liboil ne se fait jamais au détriment de la stabilité ni de la portabilité. C'es là qu'on reconnait la qualité de leur architecture, et du modèle opensource.
> Les autres sont "unsupported", c'est marqué texto en bas de la page
Ce qu'il y a de bien avec le libre, c'est que si tu nous fournis le source, on se débrouille sans ton « support » (support comment, d'ailleurs ?). C'est exactement ce que fait Mozilla : leur code marche sur un paquet de plateformes (y compris linux/arm, linux/mips, linux/amd64 etc.) et ça c'est déjà une grosse différence avec flash. Ensuite, ils ne peuvent pas le tester à fond partout. Et bien, qu'importe ? le support est assuré, notamment, par la communauté et les distros. Au final, l'utilisateur dispose d'un bon navigateur partout, supporté, et ça c'est aussi une grosse différence avec Flash.
> Et au moins il gère autre chose que le codec video obsolète de Theora
Lancer un troll codecs par dessus le marché, est-ce bien raisonnable ?
> (en passant, les codecs sont aussi un problème du lecteur Flash).
Je ne te le fait pas dire. Et c'est pour ça - au moins pour l'audio/vidéo - que la prescription d'une suite codec audio + codec video et conteneur libres et sans brevets par un organisme de standardisation serait une bonne chose.
> A moins que ce soit toi qui aies mal retranscrit la proposition.
Web Applications 1.0 (HTML5), Working Draft : http://www.whatwg.org/specs/web-apps/current-work/
« User agents should support Ogg Theora video and Ogg Vorbis audio, as well as the Ogg container format. »
Le problème (merci Apple !) étant que « should », c'est moins bien que «must ».
[^] # Re: Lecteur
Posté par herodiade . En réponse à la dépêche Adobe va libérer Flex. Évalué à 2.
Le support est une autre chose, j'y reviendrai, mais là on parlait de qualité. La formule « de niveau professionnel » c'est exactement l'idéologie que je présentai. Il y aurai une hiérarchie secrète avec un « niveau amateur » (de la merde, je suppose ?) et un « niveau professionel » (ok, t'a pas les sources, mais c'est vraiment bon) ? Dois-je te rappeler que, par exemple, Apache et le kernel Linux se sont longtemps développés sans le moindre support du monde « professionnel », et qu'ils se sont imposés den environnement serveur justement pour leur soucis de qualité ? Et qu'il en va de même de la majorité des projets libres ?
Soutenir que la qualité des solutions propriétaires, fermées et « professionnelles » dépasse nécessaire les projets sur sourceforge est un peu léger. Dois-je t'indiquer que quelques personnes pensent que plus il y a de paires d'yeux sur le code (il faut qu'il soit ouvert), meilleur est le code ?
> Non, ce n'est pas de l'ironie. Tu connais une API qui permet de faire du streaming audio/video bidirectionel, de gérer webcam et microphone, tout ça de façon transparente et correcte que l'on soit sous Windows, Linux et MacOS ?
Mais PLEIN ! Gstreamer, Xine, VLC, NIMM, ...
Il font très bien ce que tu décrit au-dessus, précisément. Ils ne font pas tout ce que Flash fait, mais ce n'est pas leur objectif (ils font d'autres choses mieux, par ailleurs). Dans le même ordre que Gstreamer pour le multimédia, si l'on parle de rendu 2D, Cairo est un modèle de qualité logicielle, qui n'a vraiment rien à envier à qui que ce soit, surtout à Flash. Le code source de Cairo, c'est de l'art.
Pour finir, désolé mais « sous Windows, Linux et MacOS », ce n'est pas vraiment ce que j'appelle la portabilité. La miriade de « micro-projets soutenus par un développeur unique » dont tu parle plus haut fait généralement bien mieux.
> Tu en parleras aux développeurs d'OpenSSL, de la liboil, etc. Des Jacky Windowsiens ?
Apparemment tu n'a pas lu ce que j'ai écris, ou tu fait semblant. Pour résumer j'ai répété que « premature optimisation is the root of all evil ».
J'ai rappelé que dans le monde du libre, les optimisations comptent, mais après la sécurité, la stabilité et la portabilité, dans la hiérarchie de la « qualité logicielle » (et on parle de logiciels desktop grand public). On optimise, certes, mais _après_. On prend le temps de faire une architecture logicielle où les optimisations trouvent naturellement leur place sans bloquer les autres priorités cités plus haut.
Là où très clairement Flash s'est vautré (en lisant le blog que tu cite, on voit dans un post précédent le pauvre développeur s'embrouiller dans ses jackyteries asm qu'il ne sait pas porter sur x86_64, et toute son appli est bloquée par ça ...).
Tu m'interroge sur OpenSSL et liboil. Pour liboil, cet objectif de qualité et d'architecture propre est tout simplement ... la cause originelle du projet (disjoindre la question des optimisations de l'implem de Flash ou d'autre chose), tout autant que la méthode du projet (fournir un code C, avec ou sans intrinsics, qui marche partout, et éventuellement y adjoindre des implems mmx/altivec/... utilisables lorsque l'environnement les supporte). Dans le cas d'OpenSSL c'est une évidence vitale : sur la portabilité tu ne trouvera rien à leur reprocher, surtout en comparaison avec flash, et sur la stabilité et la sécurité, tu pourra difficilement soutenir qu'il ne s'agit pas d'une priorité.
> Ah, finalement l'argument est bien mince : quand c'est la liboil qui fait des optimisations asm, c'est bien, quand c'est le lecteur Flash, ce sont des Jacky Windowsiens ?
Oui, et je maintien. Cf. ce que je dit juste avant (et que j'ai pourtant expliqué dans le post grand-parent). L'objectif de performances de liboil ne se fait jamais au détriment de la stabilité ni de la portabilité. C'es là qu'on reconnait la qualité de leur architecture, et du modèle opensource.
> Les autres sont "unsupported", c'est marqué texto en bas de la page
Ce qu'il y a de bien avec le libre, c'est que si tu nous fournis le source, on se débrouille sans ton « support » (support comment, d'ailleurs ?). C'est exactement ce que fait Mozilla : leur code marche sur un paquet de plateformes (y compris linux/arm, linux/mips, linux/amd64 etc.) et ça c'est déjà une grosse différence avec flash. Ensuite, ils ne peuvent pas le tester à fond partout. Et bien, qu'importe ? le support est assuré, notamment, par la communauté et les distros. Au final, l'utilisateur dispose d'un bon navigateur partout, supporté, et ça c'est aussi une grosse différence avec Flash.
> Et au moins il gère autre chose que le codec video obsolète de Theora
Lancer un troll codecs par dessus le marché, est-ce bien raisonnable ?
> (en passant, les codecs sont aussi un problème du lecteur Flash).
Je ne te le fait pas dire. Et c'est pour ça - au moins pour l'audio/vidéo - que la prescription d'une suite codec audio + codec video et conteneur libres et sans brevets par un organisme de standardisation serait une bonne chose.
> A moins que ce soit toi qui aies mal retranscrit la proposition.
Web Applications 1.0 (HTML5), Working Draft :
http://www.whatwg.org/specs/web-apps/current-work/
« User agents should support Ogg Theora video and Ogg Vorbis audio, as well as the Ogg container format. »
Le problème (merci Apple !) étant que « should », c'est moins bien que «must ».