Correct, dans le guide navigo ils mettent d'ailleurs l'accent sur cette séparation entre les données de voyage et les données nominatives. Voir à la page 11 de la brochure :
www.stif.info/IMG/pdf/GuideNavigo-3.pdf
Le problème ici n'est pas la façon dont ils traitent les données aujourd'hui, c'est que qu'il est possible de faire.
Si tu commets un délit, que la police t'arrête, te met en garde à vue et trouve sur toi un passe, ils pourront légalement vérifier tes déplacements. Comme s'ils trouvent des tickets de métro dans tes poches. C'est normal.
En revanche, avoir l'identité des gens dans la base de la RATP, c'est ouvrir la porte à des profilages personnalisés, hors de tout cadre juridique, et potentiellement secrets. Ca ne se fait peut-être pas aujourd'hui, mais le fait que ce soit facile à faire rend plus probable une mise en application future.
Il n'y a pas d'incohérence à constater que le non-anonymat est fréquent dans beaucoup d'actes de la vie quotidienne, et de tenter de corriger le problème point par point, si tant est que l'on considère que c'est un problème.
Il est vrai que ça coûte plus d'argent de satisfaire à la fois ceux qui choisissent plus de commodité et ceux qui veulent plus d'anonymat, mais c'est la démocratie. Tu trouveras facilement dans le spectre politique des partis qui considèrent que l'absence d'anonymat est une réponse adéquate aux problèmes de société. Ce n'est pas mon avis et je me batterai pour que l'on me donne le choix de l'anonymat.
Oui mais si la RATP possède l'ID de ton badge et ton nom dans une base de données, alors il n'y a plus de différence entre le passe anonyme et le non-anonyme.
Le concept du navigo découverte, c'est que tu écris ton nom avec un stylo à bille sur un bout de carton associé à la carte RFID, et tu y colles ta photo. Un contrôleur peut vérifier visuellement que la carte est personnelle et nominative, mais ton nom et ta photo sont juste sur le carton, pas dans la base - exactement comme feue la carte orange.
En revanche, si tu présentes une facture, et déclares une perte, tu devrais pouvoir annuler le passe et en racheter un nouveau crédité avec le même montant, sans rompre la chaîne de l'anonymat.
C'était mon cas aussi quand j'étais parisien. J'ai conscience de la faille mais je me dis que c'est déjà mieux comme ça.
Après tout dépend de la motivation qu'a la personne qui te trace. Pour te retrouver dans ce cas, il faut obtenir des données de la RATP, du groupe carte bleue, et de ta banque.
Le porte monnaie éléctronique ne corrige pas la faille, mais ça rajoute un maillon supplémentaire.
Je me demande s'il est théoriquement possible d'avoir un système de porte monnaie éléctronique qui préserve toute la chaîne de l'anonymat. Si à aucun moment tu n'as du liquide dans la main (avec le risque de se les faire voler), est ce qu'il est possible de supprimer tout lien avec ton compte en banque ?
En supposant que les spécifications des "bornes de recharge" soient ouvertes et qu'elles soient régulièrement auditées par une autorité indépendante ? (je rêve je sais)
Ca n'a pas de rapport immédiat avec le tchat, mais Fessebouc va également implémenter OAuth, une solution standardisée d'échange de crédits d'authentication entre sites sociaux :
Il dit qu'il veut bien aider à résoudre le problème au niveau du noyau mais que seuls les ingénieurs Google peuvent adapter la couche utilisateur à ces changements.
Pourtant, cette couche est aussi open-source. Qu'est ce qui l'empêche de faire des modifications là aussi ?
Google a écrit ce truc, ils ont aussi acheté ON2. Je ne vois pas comment ils pourraient publier des brevets exclusifs sur les technos ON2 sans être en contradiction complète avec ça.
Tu vois le verre à moitié vide. Pour moi, ils poussent à l'utilisation de la balise video à la place du Flash. C'est beaucoup plus important stratégiquement pour le web que de pousser un format standard aujourd'hui. Voir mes explications détaillées https://linuxfr.org//comments/1101445.html#1101445
Google n'est pas le messie mais pour ce sujet précis de la balise video, leur comportement est pour le moment bien plus vertueux que celui de Apple ou Microsoft.
Mais c'est vrai qu'on est beaucoup dans l'attente sur cette histoire. J'attends deux choses :
- le premier plugin firefox supportant le H264,
- ce que Google va faire de ON2.
Il manque Chromium. Si j'ai bien compris, rien ne marche sur chromium.
Navigateurs liés à un système particulier :
- Safari : H264 marche par défaut, Theora nécessite l'installation d'un plugin Quicktime,
- IE : balise vidéo non supportée, mais on suppose qui se basera sur Directshow
Navigateurs supportés sous les 3 systèmes dominants :
- Chrome : H264 marche par défaut, Theora marche par défaut,
- Chromium : H264 ne marche pas, pas activable, Theora ne marche pas, pas activable;
- Opera : H264 ne marche pas, pas activable; Theora marche par défaut,
- Firefox : H264 ne marche pas, pas activable; Theora marche par défaut.
Les 4 derniers navigateurs sont multi-systèmes et donc très logiquement embarquent leur propres codecs. Ca serait beaucoup plus fastidieux de les rendre compatibles avec à la fois Quicktime, Directshow et Gstreamer. Il faudrait une couche d'abstraction supplémentaire, et donc j'imagine beaucoup de code et de tests.
Safari et IE ont un avantage car ils n'ont à être compatible qu'avec un système. La position de la MoFo est donc idéologique mais aussi pratique : utiliser des codecs non embarqués implique de travailler avec 3 backends. Or ils ne peuvent pas embarquer H264 pour des raisons de license donc ça coince.
Ceci dit je pense que c'est une grosse erreur stratégique et qu'ils doivent supporter les 3 backends afin de supporter le H264 et ainsi rester compétitifs. Lors du passage à Firefox 2; ils ont abandonné leurs contrôles HTML (boutons, barres de défilement etc) internes pour passer à ceux du système. La même chose doit être faite ici pour l'affichage des vidéos.
La vidéo sur internet, ce n'est pas accessoire, ca sera bientôt l'essentiel du trafic internet [1]. Internet est en train de bouffer toute les autres chaînes de diffusion, télé y compris. On pense a Hulu aux Etats-Unis.
Tu sais la relation entre le marché et les industriels, elle est bidirectionnelle, si le marché impose Theora, les industriels supporteront Theora.
Des technologies qui ont été imposés par le marché envers les industriels, ce n'est pas ce qu'il y a de plus rare : mp3 face aux divers formats propriétaire, le divx, l'usb face au firewire dans la vidéo, etc ... Certes l'inverse
Ici le marché n'est pas vierge, c'est l'ensemble du marché de la vidéo qui est en train de migrer sur Internet. Et ils gardent leurs vieilles recettes : MPEG, brevets, etc. Et ce marché est pour le moment à 100% dans le H264, car cette technologie est prête et déployée, en logiciel comme en matériel, un peu partout.
Mozilla se bat contre une tendance de fond qui est l'établissement de l'industrie vidéo sur Internet. C'est perdu d'avance, et je suis d'ailleurs convaincu que le support H264 (ou au moins la non-obstruction du support) arrivera d'une façon ou d'une autre d'ici pas longtemps.
Mais le vrai combat n'est pas contre H264, c'est contre le duo Flash + H264.
Evidemment l'industrie du divertissement rêve d'un internet contrôlé bourré de DRM, pour maximiser le revenu. Adobe leur offre ça sur un plateau. Parce que tout le haut de la chaîne technique de l'affichage de la vidéo dans le navigateur dépend d'un logiciel propriétaire, ils sont libres d'y faire ce qu'ils veulent.
Le HTML5, c'est la libération de toute cette couche. Sauf le codec, soit. Mais c'est une situation bien meilleure. Le codec est juste une interface. Tu lui fais manger un format codé, il te le décode. Point. C'est beaucoup plus difficile de mettre un DRM dedans.
A coté, des grosses pointures d'Internet (dont Google, pas rien) poussent le HTML5 dès maintenant. En supportant H264, ils rendent beaucoup plus facile la migration à de nombreux fournisseurs de vidéo.
Si leur stratégie réussit, il se peut que d'ici un an ou deux, Flash ait un taux de pénétration de 80% ou 90% contrairement à 98% aujourd'hui. Et grâce à ca les fournisseurs de contenu seront bien obligés de supporter la balise HTML 5.
On aura amélioré la transparence et l'ouverture du marché de la vidéo. C'est le combat qui se joue maintenant. Il sera toujours temps après de régler le problème des brevets sur les codecs, mais ca se jouera à la prochaine génération de codecs. Le combat contre flash, c'est tout de suite. Et dans leur position actuelle, la MoFo n'aide pas.
Quant on fait remarquer qu'un netbook récent galère grave avec un flux HD classique (pas un machin avec une résolution à chier), y a plus personne.
Si le netbook est nvidia ION ou possede un chipset de type Broadcom Crystal, il ne devrait pas y avoir de problème. S'il y en a un, c'est un problème de driver, ou de flash.
Si Mozilla ne lâche pas le morceau, les gens qui visitent youtube avec Firefox, ou avec IE, auront besoin de Flash pour lire les vidéos. Ils devront lire un format encombré de brevets à l'aide d'un logiciel propriétaire.
Si Mozilla lâche le morceau, ses utilisateurs pourront lire les mêmes formats encombrés de brevets avec du logiciel libre. IE sera marginalisé, Flash disparaitra plus vite, la sécurité sur internet sera meilleure.
C'est pas l'idéal mais c'est un mieux. Le libre s'impose comme ça, petit à petit, pas en montant sur ses grands chevaux.
Sans vouloir être Bisounours, je dirais que ce n'est pas le style de google de pousser des technologies fermées pour garder leur part de marché.
C'est d'ailleurs ce que dit Blizzard dans le billet cité tout en haut de ce fil de commentaires : il y a des chances que Google soit en train de bosser sur un format suite a leur rachat d'ON2. On espère qu'ils libéreront ce format et qu'ils s'en servent pour youtube.
Le navigateur lui même devient lecteur vidéo. C'est ça ? Alors, si effectivement il s'agit bien de cela, je ne vois pas vraiment l'intérêt .
Si on suit ton raisonnement, il faudrait que Firefox utilise gimp ou xv pour afficher les images...
Pas vraiment. Il faudrait que Firefox utilise par exemple libpng pour afficher les png. C'est ce qu'il fait non ? Alors pourquoi pas la même chose pour les vidéos ?
Je pense que la majorité des critiques ne demandent pas H264 dans HTML5, ni même H264 dans Firefox, mais juste un support activable facilement.
C'est la clé du succès du libre : ton système installé par défaut est irréprochable du niveau des brevets, mais le support des codecs répandus est à portée de main.
En ce qui concerne le javascript et les non-voyants, il semblerait que leurs navigateurs en mode texte supportent le javascript, et qu'une majorité ne le désactivent pas.
C'est faux de dire qu'un site en Ajax n'est forcément pas accessible. Les choses bougent, il y a un groupe de travail sur le sujet ( http://www.w3.org/WAI/intro/aria ) et leurs conclusions commencent à être utilisées dans les librairies javascript.
Le Web va évoluer vers plus d'interactivité, qu'on le veuille ou non, car c'est ce que les gens veulent. Ca ne veut pas dire que l'esprit du web (tisser des liens sur la toile) va se perdre.
I've talked in several places about how moving the problem down to the OS is not a good idea. I do agree that if we were to support system codecs, GStreamer on Linux would be the least problematic platform.
J'ai pas le courage de parcourir tout son blog pour comprendre en quoi exactement ca pose probleme en general. Mais il en parle la :
En gros, sous Windows c'est pas possible parce qu'il y a trop de codecs de mauvaise qualité et du malware qui passe par les codecs. D'apres son commentaire, ca serait faisable sans trop de problemes avec Gstreamer.
Donc je devine que c'est beaucoup plus simple pour Mozilla de mettre les codecs dans le navigateur. D'ailleurs, les autres navigateurs font pareil.
En faisant ca, ils réduisent le choix de codecs de l'utilisateur. Le probleme, c'est qu'ils se servent de cette restriction comme d'un levier pour pousser des codecs au détriment d'autres.
C'est vrai, avec le html 5, le navigateur devient lecteur vidéo. Il y a deux types de lecteur vidéo : ceux qui se reposent sur des librairies partagées pour le decodage (movie player sous gnome, media player classic pour windows) et ceux qui ont tout en interne (style VLC).
Le gros avantage de VLC et consorts, c'est que comme tout est en interne, tout est lisible du premier coup, sans réfléchir. C'est le premier ressort de la popularité de VLC.
Puisque les navigateurs ont tout en interne, on pourrait s'attendre a ce qu'ils supportent tous les formats repandus sur le web. Mais Mozilla et Safari preferent faire une guerre de formats au détriment des utilisateurs.
Bien sur, sur le fond, je suis d'accord avec la MoFo, et je trouve que la methode commerciale consistant a inonder le marché avec du gratuit qui finalement devient payant est détestable.
Il n'empeche que les investissements dans le H264 ne sont pas seulement en logiciel. Il y a également les puces de décodage qui sont maintenent tres bon marché et permettent de regarder des vidéos haute définition avec une utilisation processeur minime, donc sur des machines d'entrée de gamme style netbook. Tout libriste que je suis, j'ai quand meme envie de profiter du format sur lequel toute l'industrie s'est accordée et pour lequel tout le materiel que j'achete est optimisé.
Je ne demande pas a mozilla d'intégrer ce codec dans Firefox. Mais s'il est dans mon systeme, qu'il me laisse l'utiliser.
Les 3 OS majeurs ont tous, a ma connaissance, un systeme central de gestion de codecs. Il y a un cout, bien sur, pour Mozilla, d'etre compatible avec ces 3 la, mais c'est quand meme une meilleure solution que d'embarquer ses codecs dans le navigateur.
Il faut voir ca comme une mise en perspective de la différence d'attitude entre la fondation Ubuntu et la fondation Mozilla face a un probleme identique : la gestion des formats multimedia couverts par des brevets.
Ubuntu est plus pragmatique, et mozilla plus idéaliste. Firefox a une plus grosse part de marché que Ubuntu, mais entre changer de navigateur et changer de systeme, il y a un monde....
C'est vrai, mais c'est quand même un gros progrès par rapport à un driver vidéo proprio.
On pourrait même pousser le raisonnement : ce chipset est spécialement conçu pour décoder du MPEG4 criblé de brevets logiciels. Mais bon, c'est 99% du contenu HD aujourd'hui.
Pour ne pas trop stresser le CPU le mieux c'est de faire faire le décodage par une puce spéciale. Ca veut dire : acheter une carte ATI ou NVIDIA et utiliser les pilotes propriétaires.
Mais cette puce (20 euros sur ebay au format miniPCIe, mais doit aussi exister en PCIe) a des pilotes libres. Avec un chipset graphique intégré de chez Intel, ça permet d'avoir un système 100% libre pour décoder ses vidéos HD.
L'article de network world ne parle pas d'abandonner IPv6.
Dans mon journal - un peu trollesque après réflexion - j'expose le fait que des mécanismes de transition IPv6 existent sur le papier depuis bien longtemps. Mais quand le problème se concrétise (plus d'addresses IPv4 dans deux ans) soudainement les FAI mettent la pression sur les équipementiers télécom pour faire des NAT IPv4 vers IPv4, parce que vite, vite, on a plus le temps.
Les FAI sont, je pense, dans une position attentiste pour IPv6. Ils attendent que ca soit déployé en masse chez les autres. Des implémentations de niche existent (comme free) mais désactivées par défaut et aucun ISP dans le monde n'a un nombre significatif de clients en IPv6 sur un réseau IPv6 natif.
Le problème que je voulais souligner dans le journal c'est que l'IETF et les fournisseurs d'accès n'ont pas les mêmes priorités. L'IETF veut un Internet neutre et efficace, les FAI hurlent à cause des investissements sans cesse croissants dûs au trafic Internet qui double tous les 18 mois (surtout à cause de la vidéo en ligne ces derniers temps). Certains FAI pourraient donc s'accomoder d'un Internet NATté moins efficace qui pourraient détourner l'attention des gens sur les services complémentaires qu'ils proposent.
Évidemment les problèmes du NAT ne sont pas insurmontables, comme souligné dans de nombreux commentaires. Mais :
- le NAT introduit un point critique supplémentaire dans la chaîne,
- les compétences nécessaires pour faire marcher certains types de logiciels sont plus élevées (par exemple BitTorrent aurait beaucoup plus d'adeptes s'il n'y avait pas besoin de rediriger les ports),
- les ressources humaines et compétences nécessaires pour créer et maintenir un logiciel passant les NAT sont plus élevées.
Bref, ça rend le Net moins pratique, et à la fin, moins attractif.
Les FAI veulent du NAT tout de suite, et pour l'IPv6, ils sont attentistes. Il y a des grosses chances que les accès Internet NATtés se multiplient d'ici un ou deux ans, comme l'exemple de ce FAI italien cité plus haut. Ca crée un palier, ça retarde l'arrivée du réseau tout-IPv6, et il y aura toujours des gens qui se satisfairont de ce palier et pousseront pour ne pas aller plus loin.
En gros les FAI sont d'accord en façade mais payent des lobbies pour promulguer le contraire. En particulier, s'ils sont peut-être d'accord pour la neutralité sur ligne fixe, ils ne veulent pas en entendre parler sur le mobile.
Les FAI estiment que leur investissement dans l'infrastructure d'Internet devrait leur permettre de capter une partie des revenus du net. Une des méthodes pour cela consiste à faire entorse à la neutralité du net pour pouvoir pousser ses propres services (télé à la demande, voix sur IP etc).
Le carrier-grade NAT pourrait être une bonne excuse pour ne pas déployer IPv6, proposer un service Internet de qualité dégradée pour mettre en valeur ses propres offres en parallèle.
A part l'article que j'ai déjà cité, il y a ce document de l'IETF : http://tools.ietf.org/html/draft-nishitani-cgn-02
Qui montre qu'il y a une demande pour des routeurs niveau ISP qui gèrent le NAT IPv4 vers IPv4.
Du reste, c'est une question ouverte à caractère spéculatif : quel est l'intérêt pour les ISP de déployer IPv6 si un Internet NATté en IPv4 arrange tout le monde ?
Je reste convaincu que l'IPv6, supérieur techniquement, finira par s'imposer mais ça pourrait prendre plus de temps que prévu.
Mentionnons également CouchDB (http://couchdb.apache.org ) qui développe une approche complémentaire : la pénétration de javascript dans la base de données.
Les applications lourdes en javascript ont de plus en plus tendance à générer leur HTML à partir de données encodées en JSON (http://www.json.org/ ). Plutôt que de générer ce json côté serveur à partir de la base de données, l'idée est de stocker directement ces données en JSON, et de les accéder avec un moteur puissant et distribué écrit (partiellement) en Erlang (http://www.erlang.org/ ).
Les requêtes base de données sont écrites en javascript en suivant le principe MapReduce(http://labs.google.com/papers/mapreduce.html ). Cela représente un peu plus de travail en perspective que les requêtes bases de données abstraites habituellement par un framework Web comme Rails ou Django, mais au moins, le développeur n'a pas l'impression de confier une partie critique de son appli web à un blob SQL dont il ne maîtrise (habituellement) pas tous les rouages. Et puis, si l'application est populaire, les problèmes de montée en charge reviennent à la face du développeur qui doit optimiser ses accès base de données de toute façon.
L'inconvénient majeur par rapport à SQL est que, si le système est distribué, le contenu de la base n'est pas cohérent : en parlant à deux serveurs différents, on peut avoir deux versions chronologiquement décalées du même objet. Mais le problème n'est pas si important dans l'univers des applis web (les données à jour apparaîtront au prochain rechargement). Et CouchDB gère les conflits.
Il est donc possible, avec un moteur de Javascript serveur et CouchDB, d'avoir un framework web qui génère en Javascript la page lors du chargement initial. Puis lorsque l'utilisateur interagit avec le site, le visuel est regénéré côté client, en utilisant les mêmes fonctions, et le client interagit directement en échangeant du JSON avec l'interface REST de CouchDB (http://en.wikipedia.org/wiki/Representational_State_Transfer ) plutot qu'avec le framework.
Bref, je vous encourage à l'essayer. Un peu jeune pour être en production mais c'est tellement plus naturel que du SQL :)
[^] # Re: Anonymat aux bornes
Posté par nicolas_o . En réponse au journal De l'incohérence des pro-anonymat. Évalué à 5.
www.stif.info/IMG/pdf/GuideNavigo-3.pdf
Le problème ici n'est pas la façon dont ils traitent les données aujourd'hui, c'est que qu'il est possible de faire.
Si tu commets un délit, que la police t'arrête, te met en garde à vue et trouve sur toi un passe, ils pourront légalement vérifier tes déplacements. Comme s'ils trouvent des tickets de métro dans tes poches. C'est normal.
En revanche, avoir l'identité des gens dans la base de la RATP, c'est ouvrir la porte à des profilages personnalisés, hors de tout cadre juridique, et potentiellement secrets. Ca ne se fait peut-être pas aujourd'hui, mais le fait que ce soit facile à faire rend plus probable une mise en application future.
[^] # Re: bizarre
Posté par nicolas_o . En réponse au journal De l'incohérence des pro-anonymat. Évalué à 10.
Il est vrai que ça coûte plus d'argent de satisfaire à la fois ceux qui choisissent plus de commodité et ceux qui veulent plus d'anonymat, mais c'est la démocratie. Tu trouveras facilement dans le spectre politique des partis qui considèrent que l'absence d'anonymat est une réponse adéquate aux problèmes de société. Ce n'est pas mon avis et je me batterai pour que l'on me donne le choix de l'anonymat.
[^] # Re: Anonymat aux bornes
Posté par nicolas_o . En réponse au journal De l'incohérence des pro-anonymat. Évalué à 6.
Le concept du navigo découverte, c'est que tu écris ton nom avec un stylo à bille sur un bout de carton associé à la carte RFID, et tu y colles ta photo. Un contrôleur peut vérifier visuellement que la carte est personnelle et nominative, mais ton nom et ta photo sont juste sur le carton, pas dans la base - exactement comme feue la carte orange.
En revanche, si tu présentes une facture, et déclares une perte, tu devrais pouvoir annuler le passe et en racheter un nouveau crédité avec le même montant, sans rompre la chaîne de l'anonymat.
[^] # Re: Faisez gaffe
Posté par nicolas_o . En réponse au journal De l'incohérence des pro-anonymat. Évalué à 4.
Après tout dépend de la motivation qu'a la personne qui te trace. Pour te retrouver dans ce cas, il faut obtenir des données de la RATP, du groupe carte bleue, et de ta banque.
Le porte monnaie éléctronique ne corrige pas la faille, mais ça rajoute un maillon supplémentaire.
Je me demande s'il est théoriquement possible d'avoir un système de porte monnaie éléctronique qui préserve toute la chaîne de l'anonymat. Si à aucun moment tu n'as du liquide dans la main (avec le risque de se les faire voler), est ce qu'il est possible de supprimer tout lien avec ton compte en banque ?
En supposant que les spécifications des "bornes de recharge" soient ouvertes et qu'elles soient régulièrement auditées par une autorité indépendante ? (je rêve je sais)
# OAuth
Posté par nicolas_o . En réponse au journal Discutez avec vos contacts facebook™ via XMMP. Évalué à 5.
http://developers.facebook.com/news.php?blog=1&story=350
Moi ça me fait plaisir de voir des mastodontes de l'internet s'engager du côté des standards ouverts.
[^] # Re: À la merci de Google ?
Posté par nicolas_o . En réponse au journal Android éjecté du noyau: l'avis de Greg Kroah-Hartman. Évalué à 3.
(c'est une vraie question, d'ailleurs ce serait intéressant de savoir pourquoi ils n'étaient pas contents avec l'existant)
Google n'a pas fait qu'un lâcher de code, Ils ont aussi mis sur le marché 1.5 millions de téléphones avec le noyau Linux dedans. [1]
A la louche, ça veut dire que 5% [2] des noyaux linux qui tournent dans le monde sont sous Android.
Donc ce n'est pas entièrement de la responsibilité de Google d'éviter le fork. Les développeurs du noyau ne peuvent pas passer à côté.
[1] http://www.appleinsider.com/articles/09/11/03/canalys_q3_200(...)
[2] http://counter.li.org/
# À la merci de Google ?
Posté par nicolas_o . En réponse au journal Android éjecté du noyau: l'avis de Greg Kroah-Hartman. Évalué à -3.
Pourtant, cette couche est aussi open-source. Qu'est ce qui l'empêche de faire des modifications là aussi ?
[^] # Re: Juste une petite piqûre de rappel
Posté par nicolas_o . En réponse au journal De youtube, html5, H264 et ubuntu. Évalué à 2.
Tu vois le verre à moitié vide. Pour moi, ils poussent à l'utilisation de la balise video à la place du Flash. C'est beaucoup plus important stratégiquement pour le web que de pousser un format standard aujourd'hui. Voir mes explications détaillées https://linuxfr.org//comments/1101445.html#1101445
Google n'est pas le messie mais pour ce sujet précis de la balise video, leur comportement est pour le moment bien plus vertueux que celui de Apple ou Microsoft.
Mais c'est vrai qu'on est beaucoup dans l'attente sur cette histoire. J'attends deux choses :
- le premier plugin firefox supportant le H264,
- ce que Google va faire de ON2.
[^] # Re: Réaction de T. Nitot sur la question
Posté par nicolas_o . En réponse au journal De youtube, html5, H264 et ubuntu. Évalué à 3.
Navigateurs liés à un système particulier :
- Safari : H264 marche par défaut, Theora nécessite l'installation d'un plugin Quicktime,
- IE : balise vidéo non supportée, mais on suppose qui se basera sur Directshow
Navigateurs supportés sous les 3 systèmes dominants :
- Chrome : H264 marche par défaut, Theora marche par défaut,
- Chromium : H264 ne marche pas, pas activable, Theora ne marche pas, pas activable;
- Opera : H264 ne marche pas, pas activable; Theora marche par défaut,
- Firefox : H264 ne marche pas, pas activable; Theora marche par défaut.
Les 4 derniers navigateurs sont multi-systèmes et donc très logiquement embarquent leur propres codecs. Ca serait beaucoup plus fastidieux de les rendre compatibles avec à la fois Quicktime, Directshow et Gstreamer. Il faudrait une couche d'abstraction supplémentaire, et donc j'imagine beaucoup de code et de tests.
Safari et IE ont un avantage car ils n'ont à être compatible qu'avec un système. La position de la MoFo est donc idéologique mais aussi pratique : utiliser des codecs non embarqués implique de travailler avec 3 backends. Or ils ne peuvent pas embarquer H264 pour des raisons de license donc ça coince.
Ceci dit je pense que c'est une grosse erreur stratégique et qu'ils doivent supporter les 3 backends afin de supporter le H264 et ainsi rester compétitifs. Lors du passage à Firefox 2; ils ont abandonné leurs contrôles HTML (boutons, barres de défilement etc) internes pour passer à ceux du système. La même chose doit être faite ici pour l'affichage des vidéos.
[^] # Re: Réaction de T. Nitot sur la question
Posté par nicolas_o . En réponse au journal De youtube, html5, H264 et ubuntu. Évalué à 5.
La vidéo sur internet, ce n'est pas accessoire, ca sera bientôt l'essentiel du trafic internet [1]. Internet est en train de bouffer toute les autres chaînes de diffusion, télé y compris. On pense a Hulu aux Etats-Unis.
Tu sais la relation entre le marché et les industriels, elle est bidirectionnelle, si le marché impose Theora, les industriels supporteront Theora.
Des technologies qui ont été imposés par le marché envers les industriels, ce n'est pas ce qu'il y a de plus rare : mp3 face aux divers formats propriétaire, le divx, l'usb face au firewire dans la vidéo, etc ... Certes l'inverse
Ici le marché n'est pas vierge, c'est l'ensemble du marché de la vidéo qui est en train de migrer sur Internet. Et ils gardent leurs vieilles recettes : MPEG, brevets, etc. Et ce marché est pour le moment à 100% dans le H264, car cette technologie est prête et déployée, en logiciel comme en matériel, un peu partout.
Mozilla se bat contre une tendance de fond qui est l'établissement de l'industrie vidéo sur Internet. C'est perdu d'avance, et je suis d'ailleurs convaincu que le support H264 (ou au moins la non-obstruction du support) arrivera d'une façon ou d'une autre d'ici pas longtemps.
Mais le vrai combat n'est pas contre H264, c'est contre le duo Flash + H264.
Evidemment l'industrie du divertissement rêve d'un internet contrôlé bourré de DRM, pour maximiser le revenu. Adobe leur offre ça sur un plateau. Parce que tout le haut de la chaîne technique de l'affichage de la vidéo dans le navigateur dépend d'un logiciel propriétaire, ils sont libres d'y faire ce qu'ils veulent.
Le HTML5, c'est la libération de toute cette couche. Sauf le codec, soit. Mais c'est une situation bien meilleure. Le codec est juste une interface. Tu lui fais manger un format codé, il te le décode. Point. C'est beaucoup plus difficile de mettre un DRM dedans.
A coté, des grosses pointures d'Internet (dont Google, pas rien) poussent le HTML5 dès maintenant. En supportant H264, ils rendent beaucoup plus facile la migration à de nombreux fournisseurs de vidéo.
Si leur stratégie réussit, il se peut que d'ici un an ou deux, Flash ait un taux de pénétration de 80% ou 90% contrairement à 98% aujourd'hui. Et grâce à ca les fournisseurs de contenu seront bien obligés de supporter la balise HTML 5.
On aura amélioré la transparence et l'ouverture du marché de la vidéo. C'est le combat qui se joue maintenant. Il sera toujours temps après de régler le problème des brevets sur les codecs, mais ca se jouera à la prochaine génération de codecs. Le combat contre flash, c'est tout de suite. Et dans leur position actuelle, la MoFo n'aide pas.
Quant on fait remarquer qu'un netbook récent galère grave avec un flux HD classique (pas un machin avec une résolution à chier), y a plus personne.
Si le netbook est nvidia ION ou possede un chipset de type Broadcom Crystal, il ne devrait pas y avoir de problème. S'il y en a un, c'est un problème de driver, ou de flash.
[1] http://www.techcrunch.com/2009/06/09/cisco-by-2013-video-wil(...)
[^] # Re: Petit article récapitulatif
Posté par nicolas_o . En réponse au journal De youtube, html5, H264 et ubuntu. Évalué à 4.
Si Mozilla lâche le morceau, ses utilisateurs pourront lire les mêmes formats encombrés de brevets avec du logiciel libre. IE sera marginalisé, Flash disparaitra plus vite, la sécurité sur internet sera meilleure.
C'est pas l'idéal mais c'est un mieux. Le libre s'impose comme ça, petit à petit, pas en montant sur ses grands chevaux.
[^] # Re: H264 et GIF
Posté par nicolas_o . En réponse au journal De youtube, html5, H264 et ubuntu. Évalué à 2.
C'est d'ailleurs ce que dit Blizzard dans le billet cité tout en haut de ce fil de commentaires : il y a des chances que Google soit en train de bosser sur un format suite a leur rachat d'ON2. On espère qu'ils libéreront ce format et qu'ils s'en servent pour youtube.
[^] # Re: MoFo, H.264 et liberté.
Posté par nicolas_o . En réponse au journal De youtube, html5, H264 et ubuntu. Évalué à 2.
Si on suit ton raisonnement, il faudrait que Firefox utilise gimp ou xv pour afficher les images...
Pas vraiment. Il faudrait que Firefox utilise par exemple libpng pour afficher les png. C'est ce qu'il fait non ? Alors pourquoi pas la même chose pour les vidéos ?
[^] # Re: Liberté vs nombrilisme
Posté par nicolas_o . En réponse au journal De youtube, html5, H264 et ubuntu. Évalué à 2.
C'est la clé du succès du libre : ton système installé par défaut est irréprochable du niveau des brevets, mais le support des codecs répandus est à portée de main.
[^] # Re: Liberté vs nombrilisme
Posté par nicolas_o . En réponse au journal De youtube, html5, H264 et ubuntu. Évalué à 3.
http://ajaxian.com/archives/webaim-study-screenreaders-and-j(...)
C'est faux de dire qu'un site en Ajax n'est forcément pas accessible. Les choses bougent, il y a un groupe de travail sur le sujet ( http://www.w3.org/WAI/intro/aria ) et leurs conclusions commencent à être utilisées dans les librairies javascript.
Le Web va évoluer vers plus d'interactivité, qu'on le veuille ou non, car c'est ce que les gens veulent. Ca ne veut pas dire que l'esprit du web (tisser des liens sur la toile) va se perdre.
[^] # Re: Les codecs de Firefox ou les codecs du système
Posté par nicolas_o . En réponse au journal De youtube, html5, H264 et ubuntu. Évalué à 3.
http://weblogs.mozillazine.org/roc/archives/2010/01/activex_(...)
Voici sa réponse :
I've talked in several places about how moving the problem down to the OS is not a good idea. I do agree that if we were to support system codecs, GStreamer on Linux would be the least problematic platform.
J'ai pas le courage de parcourir tout son blog pour comprendre en quoi exactement ca pose probleme en general. Mais il en parle la :
http://weblogs.mozillazine.org/roc/archives/2009/06/directsh(...)
En gros, sous Windows c'est pas possible parce qu'il y a trop de codecs de mauvaise qualité et du malware qui passe par les codecs. D'apres son commentaire, ca serait faisable sans trop de problemes avec Gstreamer.
Donc je devine que c'est beaucoup plus simple pour Mozilla de mettre les codecs dans le navigateur. D'ailleurs, les autres navigateurs font pareil.
En faisant ca, ils réduisent le choix de codecs de l'utilisateur. Le probleme, c'est qu'ils se servent de cette restriction comme d'un levier pour pousser des codecs au détriment d'autres.
[^] # Re: MoFo, H.264 et liberté.
Posté par nicolas_o . En réponse au journal De youtube, html5, H264 et ubuntu. Évalué à 1.
Le gros avantage de VLC et consorts, c'est que comme tout est en interne, tout est lisible du premier coup, sans réfléchir. C'est le premier ressort de la popularité de VLC.
Puisque les navigateurs ont tout en interne, on pourrait s'attendre a ce qu'ils supportent tous les formats repandus sur le web. Mais Mozilla et Safari preferent faire une guerre de formats au détriment des utilisateurs.
Bien sur, sur le fond, je suis d'accord avec la MoFo, et je trouve que la methode commerciale consistant a inonder le marché avec du gratuit qui finalement devient payant est détestable.
Il n'empeche que les investissements dans le H264 ne sont pas seulement en logiciel. Il y a également les puces de décodage qui sont maintenent tres bon marché et permettent de regarder des vidéos haute définition avec une utilisation processeur minime, donc sur des machines d'entrée de gamme style netbook. Tout libriste que je suis, j'ai quand meme envie de profiter du format sur lequel toute l'industrie s'est accordée et pour lequel tout le materiel que j'achete est optimisé.
Je ne demande pas a mozilla d'intégrer ce codec dans Firefox. Mais s'il est dans mon systeme, qu'il me laisse l'utiliser.
Les 3 OS majeurs ont tous, a ma connaissance, un systeme central de gestion de codecs. Il y a un cout, bien sur, pour Mozilla, d'etre compatible avec ces 3 la, mais c'est quand meme une meilleure solution que d'embarquer ses codecs dans le navigateur.
[^] # Re: Ubuntu ?
Posté par nicolas_o . En réponse au journal De youtube, html5, H264 et ubuntu. Évalué à -1.
Ubuntu est plus pragmatique, et mozilla plus idéaliste. Firefox a une plus grosse part de marché que Ubuntu, mais entre changer de navigateur et changer de systeme, il y a un monde....
[^] # Re: Broadcom crystal HD
Posté par nicolas_o . En réponse au journal Lire de la vidéo HD avec une machine limite. Évalué à 1.
Moi par exemple je compte la mettre dans mon eeebox B202 avec vidéo intel à la place de la carte wifi.
[^] # Re: Broadcom crystal HD
Posté par nicolas_o . En réponse au journal Lire de la vidéo HD avec une machine limite. Évalué à 2.
On pourrait même pousser le raisonnement : ce chipset est spécialement conçu pour décoder du MPEG4 criblé de brevets logiciels. Mais bon, c'est 99% du contenu HD aujourd'hui.
# Broadcom crystal HD
Posté par nicolas_o . En réponse au journal Lire de la vidéo HD avec une machine limite. Évalué à 10.
Pour ne pas trop stresser le CPU le mieux c'est de faire faire le décodage par une puce spéciale. Ca veut dire : acheter une carte ATI ou NVIDIA et utiliser les pilotes propriétaires.
Mais cette puce (20 euros sur ebay au format miniPCIe, mais doit aussi exister en PCIe) a des pilotes libres. Avec un chipset graphique intégré de chez Intel, ça permet d'avoir un système 100% libre pour décoder ses vidéos HD.
Elle doit fonctionner avec mplayer puisque XBMC sera compatible dans la prochaine version : http://xbmc.org/davilla/2009/12/29/broadcom-crystal-hd-its-m(...)
Broadcom n'est pas vraiment l'ami du libre d'habitude, mais on dit qu'intel a fait pression pour que les pilotes soient libérés.
[^] # Re: Revenons à la question initiale pour comprendre
Posté par nicolas_o . En réponse au journal Le NAT chez ton FAI ou la fin du Web tel qu'on le connaît ?. Évalué à 2.
Dans mon journal - un peu trollesque après réflexion - j'expose le fait que des mécanismes de transition IPv6 existent sur le papier depuis bien longtemps. Mais quand le problème se concrétise (plus d'addresses IPv4 dans deux ans) soudainement les FAI mettent la pression sur les équipementiers télécom pour faire des NAT IPv4 vers IPv4, parce que vite, vite, on a plus le temps.
Les FAI sont, je pense, dans une position attentiste pour IPv6. Ils attendent que ca soit déployé en masse chez les autres. Des implémentations de niche existent (comme free) mais désactivées par défaut et aucun ISP dans le monde n'a un nombre significatif de clients en IPv6 sur un réseau IPv6 natif.
Donc ils vont déployer des NAT IPv4, un bouzin qui marche "à peu près" et qui laisse entrevoir la possibilité d'une migration - voir ce brouillon de l'IETF http://tools.ietf.org/html/draft-shirasaki-nat444-isp-shared(...) .
Le problème que je voulais souligner dans le journal c'est que l'IETF et les fournisseurs d'accès n'ont pas les mêmes priorités. L'IETF veut un Internet neutre et efficace, les FAI hurlent à cause des investissements sans cesse croissants dûs au trafic Internet qui double tous les 18 mois (surtout à cause de la vidéo en ligne ces derniers temps). Certains FAI pourraient donc s'accomoder d'un Internet NATté moins efficace qui pourraient détourner l'attention des gens sur les services complémentaires qu'ils proposent.
Évidemment les problèmes du NAT ne sont pas insurmontables, comme souligné dans de nombreux commentaires. Mais :
- le NAT introduit un point critique supplémentaire dans la chaîne,
- les compétences nécessaires pour faire marcher certains types de logiciels sont plus élevées (par exemple BitTorrent aurait beaucoup plus d'adeptes s'il n'y avait pas besoin de rediriger les ports),
- les ressources humaines et compétences nécessaires pour créer et maintenir un logiciel passant les NAT sont plus élevées.
Bref, ça rend le Net moins pratique, et à la fin, moins attractif.
Les FAI veulent du NAT tout de suite, et pour l'IPv6, ils sont attentistes. Il y a des grosses chances que les accès Internet NATtés se multiplient d'ici un ou deux ans, comme l'exemple de ce FAI italien cité plus haut. Ca crée un palier, ça retarde l'arrivée du réseau tout-IPv6, et il y aura toujours des gens qui se satisfairont de ce palier et pousseront pour ne pas aller plus loin.
[^] # Re: Pour aller dans l'autre sens
Posté par nicolas_o . En réponse au journal Le NAT chez ton FAI ou la fin du Web tel qu'on le connaît ?. Évalué à 4.
http://arstechnica.com/tech-policy/news/2009/09/isps-react-s(...)
En gros les FAI sont d'accord en façade mais payent des lobbies pour promulguer le contraire. En particulier, s'ils sont peut-être d'accord pour la neutralité sur ligne fixe, ils ne veulent pas en entendre parler sur le mobile.
Les FAI estiment que leur investissement dans l'infrastructure d'Internet devrait leur permettre de capter une partie des revenus du net. Une des méthodes pour cela consiste à faire entorse à la neutralité du net pour pouvoir pousser ses propres services (télé à la demande, voix sur IP etc).
Voir la dernière publicité d'Orange qui abonde en ce sens :
http://www.numerama.com/magazine/13837-non-orange-il-n-y-a-b(...)
Le carrier-grade NAT pourrait être une bonne excuse pour ne pas déployer IPv6, proposer un service Internet de qualité dégradée pour mettre en valeur ses propres offres en parallèle.
[^] # Re: Avant de partir en trolls poilus dans tous les sens .....
Posté par nicolas_o . En réponse au journal Le NAT chez ton FAI ou la fin du Web tel qu'on le connaît ?. Évalué à 2.
http://tools.ietf.org/html/draft-nishitani-cgn-02
Qui montre qu'il y a une demande pour des routeurs niveau ISP qui gèrent le NAT IPv4 vers IPv4.
Du reste, c'est une question ouverte à caractère spéculatif : quel est l'intérêt pour les ISP de déployer IPv6 si un Internet NATté en IPv4 arrange tout le monde ?
Je reste convaincu que l'IPv6, supérieur techniquement, finira par s'imposer mais ça pourrait prendre plus de temps que prévu.
# CouchDB
Posté par nicolas_o . En réponse au journal Javascript côté serveur, intéressant ou pas ?. Évalué à 2.
Les applications lourdes en javascript ont de plus en plus tendance à générer leur HTML à partir de données encodées en JSON (http://www.json.org/ ). Plutôt que de générer ce json côté serveur à partir de la base de données, l'idée est de stocker directement ces données en JSON, et de les accéder avec un moteur puissant et distribué écrit (partiellement) en Erlang (http://www.erlang.org/ ).
Les requêtes base de données sont écrites en javascript en suivant le principe MapReduce(http://labs.google.com/papers/mapreduce.html ). Cela représente un peu plus de travail en perspective que les requêtes bases de données abstraites habituellement par un framework Web comme Rails ou Django, mais au moins, le développeur n'a pas l'impression de confier une partie critique de son appli web à un blob SQL dont il ne maîtrise (habituellement) pas tous les rouages. Et puis, si l'application est populaire, les problèmes de montée en charge reviennent à la face du développeur qui doit optimiser ses accès base de données de toute façon.
L'inconvénient majeur par rapport à SQL est que, si le système est distribué, le contenu de la base n'est pas cohérent : en parlant à deux serveurs différents, on peut avoir deux versions chronologiquement décalées du même objet. Mais le problème n'est pas si important dans l'univers des applis web (les données à jour apparaîtront au prochain rechargement). Et CouchDB gère les conflits.
Il est donc possible, avec un moteur de Javascript serveur et CouchDB, d'avoir un framework web qui génère en Javascript la page lors du chargement initial. Puis lorsque l'utilisateur interagit avec le site, le visuel est regénéré côté client, en utilisant les mêmes fonctions, et le client interagit directement en échangeant du JSON avec l'interface REST de CouchDB (http://en.wikipedia.org/wiki/Representational_State_Transfer ) plutot qu'avec le framework.
Bref, je vous encourage à l'essayer. Un peu jeune pour être en production mais c'est tellement plus naturel que du SQL :)