Surtout qu'elle soulève un problème plus général: celui des technologies propriétaires qui puent et sont en position de monopôle.
Flash, techniquement, ça pue, surtout pour diffuser autre chose qu'une application: Un jeu en Flash, why not? Qu'il soit embarqué dans une page Web ou à télécharger en code natif, ça reste une appli "lourde" qui finalement n'a pas grand chose à voir avec la finalité du Web (échanger des informations).
Mais du texte en Flash, des menus en Flash, de la vidéo en Flash, des images en Flash, c'est nul et c'est 99% des applications de Flash.
Il y a d'autres technologies qui puent et sont largement utilisées: MSN pour l'IM en France, par exemple. SMB pour le partage réseau. .doc pour le texte mis en forme.
Et pour chacune de ces technologies, il existe un "équivalent" libre (comprendre: librement implémentable, et standardisé), qui présente certains avantages par rapport à la solution propriétaire, et également certains inconvénients.
XMPP pour MSN. NFS (ou autres) pour SMB. OpenDocument pour les .doc
Et à chaque fois, le libre est face à un choix:
- se rendre compatible avec le truc proprio largement utilisé.
Ça donne Gnash, swfdec, ça donne Kmess et aMSN, ça donne Samba.
L'avantage, c'est que madame Michu et les entreprises passent plus facilement au libre: ça reste compatible avec le monde propriétaire: on peut continuer à causer sur MSN, lire les .doc, accéder au partage SMB des autres PC encore sous Windows.
L'inconvénient, c'est que ça reste bien souvent du bricolage toujours en retard d'une guerre, qui contribue à donner du libre l'image d'un truc qui "marche moins bien" que le propriétaire: WLM est le seul client à gérer toutes les fonctions de MSN, on attend Samba 4 pour le support des GPO que Microsoft a déjà implémenté depuis belle lurette, la mise en page des .doc n'est pas toujours respectée.
- promouvoir la solution libre et intéropérable
Ça donne le support de HTML5 dans les navigateurs, les clients "only XMPP" de bonne qualité, NFS qui roxxe carrément bien.
L'avantage, c'est que le libre peut mettre en avant le fait qu'il propose des solutions aussi bien voire meilleurs que celles du monde propriétaire: des solutions fonctionnelles et techniquement intelligentes (la balise audio ça t'a une autre gueule que télécharger une appli .swf qui lit une vidéo) et intéropérables.
L'inconvénient, c'est que ça "coupe" le libre du monde propriétaire. Et dans un monde où madame Michu a 30 contacts "encore" sous Windows, où les entreprises migrent frileusement en testant Ubuntu sur un PC parmi un parc de 200, la "rupture" risque d'avoir comme conséquence l'abandon pur et simple de la solution libre car "pas compatible".
C'est un choix à faire, dans la mesure où on n'a que 24H dans une journée: se taper la conf et de NFS de Samba sur un serveur, c'est lourd. Envoyer et un .doc et un .odt, c'est lourd. Développer et un site en Flash et le même en HTML 5, c'est lourd. Soutenir et Gnash et (par exemple) l'implémentation de HTML5 dans Konqueror, c'est lourd.
Ce choix, on le fait aussi en tant qu'utilisateur: je formate ma clef USB en ext3, en NTFS ou je fais deux partitions (lourd)? J'ai un compte MSN, un compte XMPP ou les deux (lourd)?
Il y a d'un côté le risque d'être toujours "à la traine" derrière du propriétaire, de l'autre le risque de "casser" la progression du libre et ses efforts de séduction en direction de madame Michu et des entreprises.
La FSF semble avoir fait le premier choix: ça peut paraître raisonnable, dans la mesure où avec 1 ou 2% d'utilisateurs, si on joue aux "intégristes" sur le plan de la compatibilité, on risque de stagner et de disparaitre. D'ailleurs, ce choix est bien présent dès qu'on installe Gnome, le DE "officiel" de la FSF: ho, du swfdec par ci, du samba par là.. pour le NFS on repassera, par contre.
Le "message" de la FSF est "On fait tout pour être un maximum compatible avec la daube propriétaire existante, mais en gardant comme impératif le fait que le code soit libre".
Sauf que dans le cas de Gnash, ça parait un peu idiot comme choix, pour plusieurs raisons:
- il existe déjà une implémentation fonctionnelle de Flash pour Linux, j'ai nommé le plugin de Adobe. Bouh je sais, c'est pas libre. Ceci dit, les applis Flash qui trainent sur le Web ne le sont pas non plus, à de rares exceptions prêt.
Donc, si je suis un puriste qui tient à n'utiliser que du code libre sur ma machine, je ne vais pas accepter le méchant .swf du webmaster, qui est 99% du temps propriétaire et livré sans ses sources, et insister pour avoir un lien direct vers la vidéo afin de la faire mouliner à mon lecteur vidéo libre préféré. Gnash ou pas Gnash ça ne change rien.
Si je suis prêt à utiliser du proprio "pourvu que ça marche", alors la solution "appli .swf proprio sur Gnash libre" fonctionne, mais la solution "appli .swf proprio sur Adobe Flash proprio" fonctionne encore mieux, pour une différence minime, au point où j'en suis. Gnash ou pas Gnash ça ne change rien.
- il y a toujours le risque que Adobe rende totalement incompatible son Flash avec tout projet libre. En ne publiant plus ses spécifications, par exemple. Il suffit d'une API de DRM, et le seul moyen de lire du contenu sous DRM sera de passer par le plugin proprio de Adobe. Adobe peut aussi s'amuser à "libérer" les spécifications de Flash pour ensuite attaquer les projets qui les utilisent: http://linuxcentre.net/adobe-has-issued-a-dmca-removal-reque(...)
La FSF aurait l'air maline si Adobe attaquait le projet Gnash.
Ce risque est moins présent avec d'autres trucs propriétaires: dans le cas de SMB/Samba, Microsoft a été contraint par la justice de publier les spécifications, moyennant finances certes. Dans le cas des formats de bureautique, on a tous suivi la saga des normes et implémentations foireuses .doc/.docx/.odt, mais dans l'ensemble y'a du mieux par rapport à y'a 5 ans.
Tout ça pour dire que, sur ce point précis, j'ai du mal à comprendre le choix de la FSF: soutenir un projet que Adobe peut plomber, soit juridiquement, soit en se gardant une partie des spécifications de Flash, à la seule fin de compenser les conneries de webmasters qui compensent la bêtise d'utilisateurs qui subissent la fainéantise d'un éditeur qui profite de sa domination pour poser un navigateur tout pourri sur le Web.
Alors que, objectivement, les "garanties" juridiques et techniques données par Adobe au sujet de Flash sont bien moindres que celles données par Microsoft au sujet de Silverlight, la FSF a choisi de soutenir à 100% Gnash et a montré les dents au sujet de Moonlight. Je n'y vois qu'une seule explication: c'est le nom "Microsoft" qui fait peur, et pas celui de "Adobe".
Pourtant, le "grand méchant monopôle propriétaire", c'est peut-être Microsoft Windows avec ses 90% de parts de marché, mais c'est surtout Adobe Flash avec ses 98% de parts de marché, non?
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Utilité ?
Posté par Grunt . En réponse au journal Gnash: décodage fluide de vidéos Flash HD (H.264). Évalué à 10.
Surtout qu'elle soulève un problème plus général: celui des technologies propriétaires qui puent et sont en position de monopôle.
Flash, techniquement, ça pue, surtout pour diffuser autre chose qu'une application: Un jeu en Flash, why not? Qu'il soit embarqué dans une page Web ou à télécharger en code natif, ça reste une appli "lourde" qui finalement n'a pas grand chose à voir avec la finalité du Web (échanger des informations).
Mais du texte en Flash, des menus en Flash, de la vidéo en Flash, des images en Flash, c'est nul et c'est 99% des applications de Flash.
Il y a d'autres technologies qui puent et sont largement utilisées: MSN pour l'IM en France, par exemple. SMB pour le partage réseau. .doc pour le texte mis en forme.
Et pour chacune de ces technologies, il existe un "équivalent" libre (comprendre: librement implémentable, et standardisé), qui présente certains avantages par rapport à la solution propriétaire, et également certains inconvénients.
XMPP pour MSN. NFS (ou autres) pour SMB. OpenDocument pour les .doc
Et à chaque fois, le libre est face à un choix:
- se rendre compatible avec le truc proprio largement utilisé.
Ça donne Gnash, swfdec, ça donne Kmess et aMSN, ça donne Samba.
L'avantage, c'est que madame Michu et les entreprises passent plus facilement au libre: ça reste compatible avec le monde propriétaire: on peut continuer à causer sur MSN, lire les .doc, accéder au partage SMB des autres PC encore sous Windows.
L'inconvénient, c'est que ça reste bien souvent du bricolage toujours en retard d'une guerre, qui contribue à donner du libre l'image d'un truc qui "marche moins bien" que le propriétaire: WLM est le seul client à gérer toutes les fonctions de MSN, on attend Samba 4 pour le support des GPO que Microsoft a déjà implémenté depuis belle lurette, la mise en page des .doc n'est pas toujours respectée.
- promouvoir la solution libre et intéropérable
Ça donne le support de HTML5 dans les navigateurs, les clients "only XMPP" de bonne qualité, NFS qui roxxe carrément bien.
L'avantage, c'est que le libre peut mettre en avant le fait qu'il propose des solutions aussi bien voire meilleurs que celles du monde propriétaire: des solutions fonctionnelles et techniquement intelligentes (la balise audio ça t'a une autre gueule que télécharger une appli .swf qui lit une vidéo) et intéropérables.
L'inconvénient, c'est que ça "coupe" le libre du monde propriétaire. Et dans un monde où madame Michu a 30 contacts "encore" sous Windows, où les entreprises migrent frileusement en testant Ubuntu sur un PC parmi un parc de 200, la "rupture" risque d'avoir comme conséquence l'abandon pur et simple de la solution libre car "pas compatible".
C'est un choix à faire, dans la mesure où on n'a que 24H dans une journée: se taper la conf et de NFS de Samba sur un serveur, c'est lourd. Envoyer et un .doc et un .odt, c'est lourd. Développer et un site en Flash et le même en HTML 5, c'est lourd. Soutenir et Gnash et (par exemple) l'implémentation de HTML5 dans Konqueror, c'est lourd.
Ce choix, on le fait aussi en tant qu'utilisateur: je formate ma clef USB en ext3, en NTFS ou je fais deux partitions (lourd)? J'ai un compte MSN, un compte XMPP ou les deux (lourd)?
Il y a d'un côté le risque d'être toujours "à la traine" derrière du propriétaire, de l'autre le risque de "casser" la progression du libre et ses efforts de séduction en direction de madame Michu et des entreprises.
La FSF semble avoir fait le premier choix: ça peut paraître raisonnable, dans la mesure où avec 1 ou 2% d'utilisateurs, si on joue aux "intégristes" sur le plan de la compatibilité, on risque de stagner et de disparaitre. D'ailleurs, ce choix est bien présent dès qu'on installe Gnome, le DE "officiel" de la FSF: ho, du swfdec par ci, du samba par là.. pour le NFS on repassera, par contre.
Le "message" de la FSF est "On fait tout pour être un maximum compatible avec la daube propriétaire existante, mais en gardant comme impératif le fait que le code soit libre".
Sauf que dans le cas de Gnash, ça parait un peu idiot comme choix, pour plusieurs raisons:
- il existe déjà une implémentation fonctionnelle de Flash pour Linux, j'ai nommé le plugin de Adobe. Bouh je sais, c'est pas libre. Ceci dit, les applis Flash qui trainent sur le Web ne le sont pas non plus, à de rares exceptions prêt.
Donc, si je suis un puriste qui tient à n'utiliser que du code libre sur ma machine, je ne vais pas accepter le méchant .swf du webmaster, qui est 99% du temps propriétaire et livré sans ses sources, et insister pour avoir un lien direct vers la vidéo afin de la faire mouliner à mon lecteur vidéo libre préféré. Gnash ou pas Gnash ça ne change rien.
Si je suis prêt à utiliser du proprio "pourvu que ça marche", alors la solution "appli .swf proprio sur Gnash libre" fonctionne, mais la solution "appli .swf proprio sur Adobe Flash proprio" fonctionne encore mieux, pour une différence minime, au point où j'en suis. Gnash ou pas Gnash ça ne change rien.
- il y a toujours le risque que Adobe rende totalement incompatible son Flash avec tout projet libre. En ne publiant plus ses spécifications, par exemple. Il suffit d'une API de DRM, et le seul moyen de lire du contenu sous DRM sera de passer par le plugin proprio de Adobe. Adobe peut aussi s'amuser à "libérer" les spécifications de Flash pour ensuite attaquer les projets qui les utilisent:
http://linuxcentre.net/adobe-has-issued-a-dmca-removal-reque(...)
La FSF aurait l'air maline si Adobe attaquait le projet Gnash.
Ce risque est moins présent avec d'autres trucs propriétaires: dans le cas de SMB/Samba, Microsoft a été contraint par la justice de publier les spécifications, moyennant finances certes. Dans le cas des formats de bureautique, on a tous suivi la saga des normes et implémentations foireuses .doc/.docx/.odt, mais dans l'ensemble y'a du mieux par rapport à y'a 5 ans.
Tout ça pour dire que, sur ce point précis, j'ai du mal à comprendre le choix de la FSF: soutenir un projet que Adobe peut plomber, soit juridiquement, soit en se gardant une partie des spécifications de Flash, à la seule fin de compenser les conneries de webmasters qui compensent la bêtise d'utilisateurs qui subissent la fainéantise d'un éditeur qui profite de sa domination pour poser un navigateur tout pourri sur le Web.
Alors que, objectivement, les "garanties" juridiques et techniques données par Adobe au sujet de Flash sont bien moindres que celles données par Microsoft au sujet de Silverlight, la FSF a choisi de soutenir à 100% Gnash et a montré les dents au sujet de Moonlight. Je n'y vois qu'une seule explication: c'est le nom "Microsoft" qui fait peur, et pas celui de "Adobe".
Pourtant, le "grand méchant monopôle propriétaire", c'est peut-être Microsoft Windows avec ses 90% de parts de marché, mais c'est surtout Adobe Flash avec ses 98% de parts de marché, non?
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.