vjm a écrit 397 commentaires

Je ne pense pas parce que ça ne relie pas tous les composants et que ce n'est pas nécessairement non bloquant. Ça n'a rien à voir avec un réseau de Clos ou un réseau de Banyan comme on en trouve dans les backplanes des routeurs hautes performances modernes. Notamment ça n'offre pas les mêmes performances. Un southbridge typiquement y'en a (au moins) un sur chaque carte d'un tel châssis.

L'erreur que tu fais c'est que la simulation peut servir non seulement à créer de nouvelles armes mais également à assurer la maintenance des armes existantes.

IEEE Spectrum avait fait un dossier excellent sur ce sujet par rapport au programme américain : http://spectrum.ieee.org/aerospace/military/what-about-the-n(...)

Et l'arme nucléaire n'empêche pas complètement la guerre. Par contre elle garantit l'inviolabilité du territoire et donc la souveraineté. C'est le cas même pour le Pakistan ou Israël : les conflits sont limités en intensité et en étendue géographique, bref ne menace jamais l'intégrité du territoire (oui, même Israël qui ne connaît plus du tout le même genre de menace sur son territoire que pendant la guerre de Yom Kippour par exemple). Pour la France au moins, après avoir passé plusieurs siècles à se faire visiter régulièrement pas des hostiles et avoir connue deux guerres extrêmement destructrices sur son territoire, l'inviolabilité du territoire a un certain sens.

Si on rajoute le fait que les transferts réseaux se font par un bus relié au CPU et non à la carte graphique, et le goulet d'étranglement du bus PCI-Express, alors les performances pratiques sont très souvent 10x plus faibles que celles promises sur le papier par le constructeur.

D'ailleurs - je me permets une parenthèse - c'est pour la même raison que les articles récents sur les routeurs software open source ne sont pas vraiment industrialisables. Même celui récemment qui justement utilisait des GPU pour accélérer ses traitements. Au final, on continuera à être limité niveau I/O tant que tous les composants ne seront pas sur un même fond de panier très performant (ce qui fait la différence sur les gros châssis réseau).

Proxmox c'est de l'OpenVZ pour Linux et du KVM pour tout le reste. C'est autant de la containerisation que de la virtualisation complète.

Par contre effectivement, à cause du mélange des deux, ça fonctionne avec des kernels un peu particuliers qui sont donc souvent en retard de quelques versions.

Niveau performances et facilité d'utilisation c'est très bien. Maintenant dès qu'on veut aller un peu plus loin, on se retrouve vite à ne pas disposer des bonnes options dans l'interface web. Donc au final on se monte son propre équivalent.

Dalvik ne réimplémente pas les spécifications Java et ne se base sur OpenJDK mais ça n'empêche pas que d'un point de vue juridique Google viole les brevets détenus par Oracle. En réimplémentant un VM qui exécute du Java, ils ont forcément implémenté des fonctionnalités qui d'après Oracle sont couvertes par leurs brevets.

Ensuite puisque Dalvik n'est pas basé sur OpenJDK, que la licence soit Apache 2.0 et pas GPL, on s'en fout, ce n'est en rien un travail dérivé.

Je tempère un peu ton commentaire :
- Darwin c'est la base d'OS X, ça n'existait pas avant OS X, ça a été créé et libéré par Apple. Il y a des bouts de code de tous les BSD dedans mais c'est suffisamment différent (vraiment très différent, en gros ce qu'il y a de BSD c'est juste assez pour que ça ressemble à quelque chose qui puisse faire tourner des softs Unix) pour qu'on considère qu'ils ont créé un nouvel OS complet
- KHTML c'était loin d'avoir eu le même succès que ce que c'est devenu grâce à WebKit. LLVM a aussi bien profité de l'aide d'Apple.
- Cisco vendait déjà du matériel et était déjà leader avant même que SSH existe. Et s'il y a bien certains produits qui se basent sur OpenSSH (et sur Linux, et sur FreeBSD, etc.) dans leur gigantesque gamme, il suffit d'avoir essayer de scripter des accès à IOS via SSH pour voir que c'est une implémentation maison et bien pourrie.

Bref, le libre c'est bien pratique pour ces boîtes ponctuellement mais elles n'en n'ont pas (eu) besoin pour réussir.

L'implémentation du polling dans FreeBSD est assez ancienne. Elle existe surtout comme moyen de préserver le CPU en cas de fort trafic pour les interfaces qui ne sont pas capable de faire de l'interrupt mitigation. Sur des interfaces modernes avec de bons drivers (i.e. Intel ou des cartes 10 Gbps), le polling est forcément moins efficace.

Sur ce sujet, il y a eu un bon thread quoi que qu'un peu trollesque (avec notamment des interventions de Luigi Rizzo qui a fait l'implémentation originale) sur freebsd-net : http://lists.freebsd.org/pipermail/freebsd-net/2009-April/02(...)

Certes mais y'a le côté multi-streaming de SCTP qui serait intéressant je pense à la place ou en-dessous de HTTP, indépendamment de l'overhead protocolaire. Ca éviterait de multiplier les connexions TCP parallèles (qui fait partie des bonnes pratiques encouragées par exemple par Google/Yahoo! dans des bouquins comme High Performance Websites) qui pose ses propres problèmes en terme de surcharge sur les équipements (aussi bien terminaux que sur le chemin) ainsi qu'en terme de flow fairness.

Sinon pour ce qui est des ratios de trafic, il y a le projet ATLAS qui a des données assez fiables : http://www.arbornetworks.com/en/arbor-networks-the-universit(...)

• Rise of the 'Hyper Giants': Five years ago, Internet traffic was proportionally distributed across tens of thousands of enterprise managed web sites and servers around the world. Today, most content has increasingly migrated to a small number of very large hosting, cloud and content providers. Out of the 40,000 routed end sites in the Internet, 30 large companies – "hyper giants" like Limelight, Facebook, Google, Microsoft and YouTube – now generate and consume a disproportionate 30% of all Internet traffic.

C'est tout à fait exact (d'après moi).

Pour compléter, le principe end-to-end a été posé au moment de la création de TCP/IP (un des auteurs de l'article séminal c'est Dave Clark, un des fondateurs de l'IETF). Il pose effectivement un principe technique qui est que certaines fonctions nécessitent de toute façon la coopération des extrémités donc autant tout mettre à l'extrémité par souci d'efficacité. C'est le concept fondateur de TCP. Mais il n'exclut pas en soit de mettre une intelligence dans le réseau (qui était la façon de faire traditionnelle dans le monde des télécoms). Et la pratique et le pragmatisme ont fait qu'on a introduit des éléments actifs donc intelligents dans le réseau. Mais end-to-end a été un considéré comme un élément essentiel du succès d'Internet. Combiné à Ethernet il a permis de réduire drastiquement le coût des équipements réseau en les simplifiant. Dans le même temps, il a déporté l'innovation technologique vers les extrémités. Il devenait possible de déployer des applications sans coordination avec le réseau, juste en les mettant en place sur les extrémités. C'est de là que vient l'expression que le succès d'Internet vient du fait qu'il est un réseau idiot avec l'intelligence en périphérie. C'est globalement vrai même si c'est une généralisation un peu abusive, cf. http://www.faqs.org/rfcs/rfc3724.html .

D'un autre côté, il y a un concept juridique anglo-saxon qui est celui de common carrier (cf . http://en.wikipedia.org/wiki/Common_carrier ). Ce statut un peu particulier impose de fournir un service sans discrimination. Aux USA, les opérateurs de télécommunications au sens traditionnel sont des common carriers mais pas les opérateurs de réseaux informatiques. Ils sont néanmoins tous régulés par la FCC qui est un peu l'équivalent d'une fusion de l'ARCEP et du CSA. En France, il y un principe vaguement similaire qui est dans le Code des Postes et des Communications Électroniques (CPCE) qui dit qu'un opérateur de communications électroniques doivent respecter le secret des correspondances et la neutralité au regard du contenu des messages transmis. À ma connaissance ça n'a jamais vraiment servi, ne serait-ce que parce que les pouvoirs d'enquête et de sanction de l'ARCEP ne sont pas très développés.

Maintenant nous sommes dans les années 2000. Entre le développement du haut débit, l'évolution des usages (vidéo notamment) et le débat autour de la contrefaçon, certains ISP se mettent à intervenir sur leur réseau pour décider quel trafic peut circuler. C'est notamment le scandale Comcast qui ralentit voire bloque BitTorrent en 2007. Il y a aussi une évolution juridique et industrielle aux USA qui fait que le marché des ISP devient grosso modo un duopoles là où il y avait une très forte compétition.

Et là le principe technique de end-to-end et le principe juridique de common carrier se rencontrent. On se rend que ce qui faisait le succès d'Internet (la compétition très libre en grande partie grâce aux end-to-end) est menacé. Donc on ressort le principe de neutralité du réseau (à l'IETF on parle de transparence du réseau) et on se met à s'en servir comme argument à la fois technique et juridique. Aux USA le débat prend la forme de demande pour que les ISP soient régulés comme des common carriers (avec les obligations de neutralité qui vont avec) ce que la FCC a essayé de faire l'an dernier si je me souviens bien avant d'être débouté en justice au titre qu'elle n'a pas le droit de décider ça toute seule (il faut une loi je crois aux dernières nouvelles).

Mais comme Internet est global, la problématique concerne tout le monde et le débat est arrivé en Europe, notamment grâce à des gens un peu visionnaires comme Benjamin Bayart. Mais ici, très typiquement, on se méfie bien plus (à raison) de l'intervention de l'État que des actions d'entreprises donc le débat de la neutralité s'inscrit plus contre les initiatives gouvernementales comme HADOPI mais aussi LOPPSI ou l'ARJEL.

- Oui l'obligation de respecter le marquage QoS serait purement contractuelle et pas technique. Exactement comme pour les ratios de peering actuellement ou comme un client pro d'un ISP peut le faire entre ses sites actuellement.
- Ce n'est pas l'application qui décide de son marquage mais l'utilisateur de l'application. Idéalement tu as un équipement que tu contrôles qui fait le marquage en sortie de ton réseau et le réseau de l'ISP se contente de respecter les classes de QoS. Pour un particulier le marquage pourrait être fait directement le poste ou la box ou le DSLAM ou le routeur de collecte, avec les associations classe/type de trafic définies via une interface web simple. J'ai un Linksys à la maison qui a une gestion embryonnaire de la QoS mais ça sert à rien puisque c'est pas exploité par le réseau de l'opérateur derrière.

Attention mon avis n'est qu'un avis et il y a des gens bien plus compétents que moi en réseau. Par exemple, même si ça m'intéresse beaucoup, j'ai jamais eu la chance de travailler directement chez un opérateur. Il est possible que j'ai une vision un peu simpliste de leurs contraintes économiques.

Tu as parfaitement compris qu'il faut une procédure technique pour définir les classes (par exemple là où je travaille on fait ça artisanalement avec Completel pour qu'ils respectent nos règles de QoS LAN en les transportant à travers leur WAN MPLS) et une forme quelconque de régulation pour encadrer l'usage de la discrimination du trafic.

Mais il manque encore un autre élément qui est la raison pour laquelle la QoS ne s'effectue qu'au sein d'un même réseau : pour être vraiment end-to-end, il faut que le marquage QoS soit transitif, qu'il soit respecté même quand le flux traverse un autre réseau, typiquement ceux des transitaires IP entre les deux extrémités. Et ça, ça suppose de rajouter un niveau de complexité aux accords de transit et de peerings entre opérateurs voire fournisseurs de contenus. C'est très compliqué et ça n'a jamais pris malheureusement.

Sinon il y a un moyen plus simple et plus radicale de sauvegarder la neutralité : interdire l'intégration verticale (cf. http://fr.wikipedia.org/wiki/Int%C3%A9gration_verticale dans notre cas pas d'opérateur fournisseur de contenus) et appliquer la séparation fonctionnelle (dissocier l'infrastructure physique et les services, cf http://www.arcep.fr/uploads/tx_gspublication/lettre55.pdf ). On peut rêver.

Ils ont une arme sympathique contre Facebook : le Data Liberation Front ( http://www.dataliberation.org/ ). Si tu peux sortir tes données de n'importe quel service pour aller vers n'importe quel autre service concurrent via des formats standards et ouverts, tu retrouves au niveau applicatif la notion de neutralité des réseaux.

L'argument de la saturation du réseau c'est une très vieille rengaine en ingénierie réseau. Fait des recherches sur "exaflood" c'était le terme que Cisco et d'autres aimaient employer pour vendre leurs équipements. Internet allait s'effondrer à cause de la voix et de la video.

L'argument à avancer c'est que les opérateurs sont de gros hypocrites. En 2000 suite à la bulle Internet, ils se sont retrouvés avec une surcapacité monstrueuse du coup ils ont cassé les prix et se sont bien gardés d'investir dans l'infrastructure pendant des années. Bref, ils se sont gavés. Par contre ça accéléré le processus de maturation du marché des opérateurs dans lequel il est désormais devenus très difficiles de dégager des profits confortables (c'est un cas classique d'économie industrielle de mon point de vue).

Maintenant que l'usage rattrape la capacité, ils pleurnichent qu'ils ont besoin de faire des investissements et pour ça ils essayent de tirer de l'argent à tout le monde : aux consommateurs en lui fournissant des services additionnels exclusifs ou en se lançant dans la production de contenu (genre Orange qui est producteur de cinéma maintenant...) et aux fournisseurs de contenus sous prétexte qu'ils utilisent la bande passante que les consommateurs sont pourtant déjà censé avoir payé.

Or, essayer d'augmenter la capacité pour faire face à de la saturation c'est une solution de facilité très coûteuse et pas forcément très intelligente parce que c'est très difficile de calculer de quelle capacité tu as ou vas avoir besoin. La meilleure solution ce serait plutôt d'investir agressivement dans la recherche en réseau pour améliorer un peu le comportement de certains protocoles par rapport à l'usage moderne et aux contraintes des ISP.

Mais tant qu'on avait de la surcapacité, ça intéressait pas grande monde de travailler sur ce genre de recherche. Heureusement ça se réveille depuis deux ans. Quelques exemples prometteurs pour moi :
- http://en.wikipedia.org/wiki/Proactive_network_Provider_Part(...)
- http://trac.tools.ietf.org/area/tsv/trac/wiki/re-ECN
- https://datatracker.ietf.org/wg/ledbat/charter/
- Il y a aussi pas mal d'applications qui profiteraient très bien d'arrêter d'utiliser HTTP comme protocole de transport universel et développer SCTP ce serait pas inintéressant

Et pour ce qui est de la différentiation de services (de la QoS quoi), ça peut aussi être une solution tant que ce sont les extrémités qui définissent les classes à prioritiser ou pas et pas l'ISP en fonction d'accord commerciaux.

- Son constat de base sur les portails, c'est finalement le même que celui des thuriféraires de la neutralité des réseaux avec la notion de Minitel 2.0

- la notion de communication efficaces et équitables c'es pas une invention de Ridiguel, c'est juste l'un des principaux champs de recherche en ingénierie réseau depuis 30 ans. Suffit de faire une recherche sur google pour flow fairness ou tcp fairness. Ca fait partie du problème plus vaste d'allocation des ressources sur un réseau qui est l'un des champs de recherche majeurs souhaité par l'Internet Architecture Board genre là : http://groups.csail.mit.edu/ana/Publications/DevelopingaNext(...) . C'est suffisamment d'actualité pour donner lieu à des débats houleux et récents autour de propositions radicales : http://tools.ietf.org/html/draft-briscoe-tsvarea-fair-02

- faire de la différentiation de services, c'est vieux comme IP. Y'a eu le champ Precedence, y'a eu ToS, maintenant on a DiffServ, etc. Bref on veut faire de la QoS depuis le début. Simplement parce que différents flux ont différentes contraintes (latence, débit, gigue, etc.). C'est pas l'antithèse de la neutralité des réseaux. De toute façon la neutralité est une notion politique plus que technique, le principe end-to-end qui est à son origine est beaucoup moins rigoureux (http://web.mit.edu/Saltzer/www/publications/endtoend/endtoen(...) qui dit que des fois il vaut mieux implémenter une fonction dans le réseau plutôt que dans l'application si ça améliore les performances...) tout comme la culture de pragmatisme qui règne à l'IETF. Comme Lawrence Lessig l'a déjà expliqué, le problème c'est pas la notion de services différenciés, c'est que l'opérateur en profite pour favoriser son contenu ou celui de ses partenaires commerciaux (source : http://online.wsj.com/article/SB122929270127905065.html ). Il faut juste que la QoS reste entre les mains des utilisateurs finaux et on est bon.

- l'intelligence dans le réseau ça fait un bout de temps qu'il y en a. Il existe plus depuis longtemps ce réseau idiot idéalisé. Il y a des tas d'éléments actifs qui maintiennent des états concernant les flux en cours. Or la notion du réseau idiot c'est qu'il ne devait pas maintenir d'états, c'est la source de l'opposition entre IP et ATM, entre les ingé réseaux et les téléphonistes. Mais depuis on a des firewalls, du NAT, de la QoS, du policy-based routing (i.e. pas que basé sur des critères purement techniques), du traffic engineering, etc. Ca fait bien longtemps que le réseau est intelligent. Et encore une fois, il peut y avoir de bonnes raisons. Le problème c'est si ça sert pour faire la discrimination qui réduit la liberté d'expression ou d'entreprendre. Bref c'est un problème d'appliquer les lois qui existent déjà dans un cadre nouveau.

Sur les critiques qui sont formulées de la pensée supposée de Ridiguel :
- Très bonne remarque, les pouvoirs publics auraient dû faire le forcing sur l'interopérabilité et les standards ouverts et on aurait une offre beaucoup plus variée et plus de compétition ce qui compenserait les dérives actuelles notamment sur la vie privée.
- Sur ton second point en gros tu plaides le retour aux quotas de trafic avec certaines classes de trafic hors quota. Ca m'étonnerait que le consommateur suive et en tout cas je vois mal le moindre opérateur s'y risquer. Et ce que tu décris ça impose quand même d'avoir une classification à un endroit, au plus proche de la source. Mais c'est exactement comme ça que fonctionne la QoS. Nul besoin d'opposer quantité et qualité, tu parles de la même chose. D'ailleurs, un réseau je peux le saturer même sans envoyer énormément de donnée. Il suffit d'avoir des flux non coopératifs qui foutent en l'air l'équité et du point de vue d'un flux individuel ça revient à avoir un réseau saturé (ex : http://www.cs.northwestern.edu/~akuzma/rice/shrew/ ou http://www.cs.washington.edu/homes/tom/pubs/CCR99.pdf ). Donc au final, j'ai quand même besoin d'avoir des buffers différents dans mes équipements réseau pour appliquer des algorithmes de gestion de file d'attente ou pour ordonnancer différemment les flux en fonction de ce que chacun a réellement besoin, ne serait-ce que pour garantir à ta classe "appel d'urgence" de pouvoir continuer à passer pendant que je rejette le trafic en vrac qui a dépassé le quota mais qui continue à venir me saturer une interface. Pour tout ça, soit les flux ont été taggués en amont et je fais confiance soit je cherche des heuristiques dans le paquet (i.e. de la DPI dans le cas plus extrême mais ça peut aussi être juste l'équivalent de NBAR de Cisco, cf. http://www1.cisco.com/en/US/products/ps6616/products_ios_pro(...) ). En tous cas il suffit pas juste de dire "il faut envoyer moins !". Le problème c'est d'empêcher que les opérateurs choisissent les politiques de QoS eux-mêmes sous couvert d'accords commerciaux parce que ça désavantage le consommateur mais sinon y'a rien d'intrinsèquement mauvais à faire de la QoS et donc de la différentiation.

Globalement je trouve que c'est faire bien grand cas de ce bonhomme qui ne dit rien de bien intéressant et qui est loin d'avoir l'aura que cet article semble vouloir lui attribuer. Il est juste particulièrement opportuniste.

PS : je vais me faire descendre mais je trouve en plus que les spécifications fonctionnelles des moyens de sécurisation HADOPI sont bien. Elles serviront juste à labelliser et ce qui est décrit c'est grosso modo ce que sait faire un Symantec Endpoint Protection et assimilés. Il est sans arrêt dit que l'utilisateur peut contrôler la politique de sécurité. Le seul truc supplémentaire par rapport à l'offre commerciale existante c'est 1) le coup de la copie des logs signés pour avoir une valeur en justice et 2) en plus des listes d'url commerciales, on aura des listes d'url gouvernementales mais a priori publiques ne serait-ce que pour des raisons purement techniques (genre le logiciel peut être open source et l'utilisateur garde le contrôle de la politique de sécurité). Limite ça va améliorer l'équipement en outils de sécurité sur les postes des français. En tous cas j'ai pas vu en quoi c'était un mouchard...

Pff trop long tout ça, désolé.

Ca n'empêche que l'alternative ce n'est pas d'avoir son propre cloud, surtout parce que le père de famille qui regarde un film X, il saura quand même pas se le monter. L'alternative à tous les incidents que tu décris, c'est de ne pas utiliser le réseau du tout.

Le problème, cloud computing ou hébergement en général (parce que ce sont rigoureusement les mêmes problématiques), c'est de ne pas se faire enfermer par une unique plateforme (en l'occurrence c'est le cas d'UltraViolet donc ça pue). Comme ça, tu peux créer des copies de sauvegarde sur plusieurs plateformes ou simplement changer de plateforme si son fonctionnement (en terme de qualité ou de confidentialité) ne te plaît pas.

Je répondais surtout au commentaire qui prétendait que la solution à ces problèmes c'est d'avoir son propre cloud. C'est sympa mais ça garantie pas plus la qualité ni la confidentialité (puisqu'il faut bien héberger son instance quelque part et que chez soi tu n'as ni la qualité d'hébergement d'un data center ni la qualité d'accès au réseau tant qu'on aura pas de la fibre symétrique à la maison) et surtout c'est une solution qui ne peut être maîtrisée que par moins de 5% des gens qui veulent pouvoir accès à leurs données depuis n'importe où, donc c'est anecdotique.

La simple preuve de tout ça c'est les blogs et les emails. La majorité des gens passent par des solutions hébergées donc on n'y coupera pas pour le reste des données. C'est pratique. Mais il faut se prévenir de l'enfermement et ça, ça se fera plus en libérant des données (par des formats et protocoles interopérables et ouverts) qu'en libérant du code.

Enfin je trouve amusant le niveau de qualité et de confidentialité qu'on exige du cloud computing comparé au niveau de confiance qu'on a pour les webmails ou les hébergeurs actuellement.

Ton erreur c'est que les permissions Unix n'ont qu'un sens localement à ta machine alors que les DRM sont basés sur une PKI et ont donc un sens partout (pour peu que les OS et le matériel en tire partie). Donc permissions Unix != DRM.

A la rigueur, en équivalent libre, il y avait la proposition d'un Right Notification System : http://osdir.com/ml/org.fsf.france.general/2003-10/msg00009.(...)

Sauf que pour l'immense majorité des utilisateurs potentiels, ils n'auront pas les moyens humains, temporels, techniques ou financiers d'héberger leur propre instance et surtout pas avec le même degré de qualité qu'un fournisseur de service (qu'il soit commercial ou associatif) qui profite de la mutualisation de la plate-forme entre de nombreux utilisateurs.

Donc il faudra qu'il fasse héberger son instance par quelqu'un ou utilise l'instance de quelqu'un donc ça revient à remettre ses données entre les mains de quelqu'un et donc retour à exactement la même situation qu'au départ. D'ailleurs au passage je trouve amusant qu'on s'offusque autant des risques du cloud computing alors que personne n'a jamais tilté sur le fait de mettre ses données sur un serveur chez OVH.

Le problème du cloud, c'est celui de l'hébergement de services en général : il n'est pas technique, ce n'est qu'une question de réglementation (qui grosso modo existe) et d'interopérabilité pour pouvoir migrer facilement ses données en cas de problème. C'est strictement la même problématique que faire héberger un serveur quelque part actuellement.

La seule différence, c'est que le cloud c'est juste une version moderne de Service-Oriented Architecture donc on appelle des API donc on peut intégrer la notion de données hébergées directement dans les logiciels (possible actuellement mais plus complexe, genre à coup de prise en charge du stockage sur du réseau vu comme un système de fichier genre sshfs ou ftpfs ou un protocole dédié genre smb ou webdav). Et là on retombe sur la seule vraie problématique : l'interopérabilité pour qu'un même logiciel puis accéder de la même façon à des données hébergées quelque soit la plate-forme technique sur laquelle elles sont hébergées.

Bref, le cloud computing n'a qu'un seul et unique problème : l'interopérabilité et la standardisation.

Sur ordre de l'Élysée, l'ISO change d'avis en 24h et introduit OOXML dans le RGI.

Ca m'étonnerait que ce soit l'ISO qui s'occupe du RGI. Si mes souvenirs sont bons il s'agit de la DGME. Et l'histoire de l'ordre de l'Elysée, je crois que c'était pour le vote de l'AFNOR au moment du processus de normalisation d'OOXML à l'ISO. L'AFNOR allait voter non et en quelques jours les positions de la DGME et de la DGE (bref du gouvernement), qui avaient été consultées par l'AFNOR, ont changé ce qui a finalement poussé l'AFNOR à se contenter d'une abstention. Je ne pense pas qu'on en soit au point que l'ISO prend directement ses ordres du gouvernement français.

Un exemple qui me fait douter est celui des radios. Quand les radios ont apparu, tout le monde en faisait : chacun plantait une antenne radio dans son jardin, c'était l'effervescence et de milliers, de millions de stations de radios florissaient. Un jour ça a cessé parce que la FCC, qui s'occupe aujourd'hui de la neutralité du net, a attribué les fréquences à quelques acteurs économiques.

Là je comprends pas bien. On parle de la situation en France avec les radios libres ou aux Etats-Unis (ce qui justifierait de parler de la FCC) ? En plus, il y a toujours eu une spécificité majeure pour le spectre radioélectrique qui est que c'est une ressource rare dont l'attribution a toujours été régulé même au niveau mondial (CMR et IUT). Ce n'est que très récemment qu'on peut commencer à envisager un spectre totalement dérégularisé (cf. http://en.wikipedia.org/wiki/Open_spectrum ). D'ailleurs il faut aussi prendre en compte le contexte historique. Entre Internet, les radios, la télévision, le téléphone, on sait désormais des choses sur l'organisation des télécommunications qu'on ignorait alors. Je ne pense pas qu'un retour en arrière total soit possible. Mais c'est vrai qu'après avoir été relativement tranquille quelques années tant que les usages dépassaient la compréhension du législateur et que l'action de celui-ci n'était pas trop nécessaire au développement, on constate une certaine réaction d'une partie du monde politique.

D'ailleurs ce que je trouve le plus inquiétant pour cette table ronde, c'est qu'elle a beau être politique, on se retrouve avec des participants du monde politique plutôt marginaux (DLR et PCF) et surtout avec aucun contradicteur.

Ils ont quand même été profilé par le New York Times ( http://www.nytimes.com/2010/05/12/nyregion/12about.html ) et ils ont fait plusieurs conférences en public.

Autant d'information qu'on trouve sur le site joindiaspora.com ...

Ça n'empêche que ça pourrait être encore plus simple vu que sur le Nexus One de Google il suffit de faire fastboot oem unlock depuis adb.

Non le réseau neutre ne suffit pas, il faut aussi l'interopérabilité entre services (et bien sûr, tout simplement l'existence de services concurrents). Mais en l'occurrence, non seulement des services concurrents à Google existent mais en plus Google est probablement l'une des sociétés les plus au fait des problèmes d'interopérabilité au point d'avoir lancé le Data Liberation Front ( http://www.dataliberation.org/ ).

Si Minitel 2.0 était un problème d'usage, alors même que les solutions sont déjà disponibles (capacités d'auto-hébergement en propre ou sur infrastructure mutualisée, services concurrents à Google, etc.) il n'y aurait en l'état pas de problèmes. Or il y a un problème. Et pas parce que les usages sont mauvais mais parce qu'il y a menace sur la neutralité (par exemple pour moi l'IPTV ou la ToIP n'auraient jamais dû être des services fournis directement par les opérateurs, et Orange devenant producteur de contenu avec Studio 37 c'est encore pire) mais en plus parce qu'en l'état il n'y pas ou peu d'interopérabilité (impossible de faire transiter mes données d'un réseau social ou d'une plate-forme de diffusion à l'autre sans tout refaire moi-même).

Je n'ai jamais dit qu'avant c'était mieux, je dis juste que centraliser les donné c'est du Minitel 2.0 selon BB.

Dans ce cas, il y a toujours eu Minitel 2.0 puisqu'il y a toujours centralisation des données sur des serveurs mutualisés entre des nombres variables d'utilisateurs. Le fait qu'avant ce soit 180 millions de gens chez GMail alors qu'avant c'était 10000 personnes sur les serveurs mail de UC Berkeley, ça change rien (surtout que rapporté au nombre total d'utilisateurs d'Internet à chaque époque, ça doit même être pareil).

Et pour la petite remarque sur les ingénieurs réseau, depuis 3 messages tout ce que tu sais me balancer c'est ton interprétation d'une interprétation (celle de Bayart) et aucun cas un effort de réflexion. Donc oui je sors l'argument d'autorité pour te montrer que je sais un tout petit peu de quoi je parle et que dans cet article il n'y avait aucune raison de faire un NdM sur le Minitel 2.0.

Par contre, je rajoute juste que vu comme tu te fais pertinenter, je suppose que ça signifie que beaucoup de gens ont compris comme toi et ça explique que le terme soit en train de devenir complétement galvaudé à force d'être utilisé pour décrire des choses qui n'ont rien à voir.

Je suis ingénieur réseau et j'étais à la première conférence de Benjamin Bayart à FRnOG, merci. Et utiliser le mot Minitel ça a bien à voir directement avec la notion de neutralité. Il faut y rajouter la notion d'interopérabilité pour pouvoir rester propriétaire de ses données et les migrer vers des services concurrents (qui peuvent se développer parce que le réseau reste neutre). Si tu vires la neutralité et l'interopérabilité, tu bascules dans du Minitel. Mais pas si tu mets tes données sur des serveurs (à toi ou tiers, peu importe s'il y a neutralité et interopérabilité). On dit l'intelligence doit être à la périphérie du réseau, on dit pas tout le monde doit être client ET serveur. On protège les utilisateurs ET les fournisseurs de service du diktat de l'opérateur. Mais on n'implique pas que chaque utilisateur doit aussi être fournisseur. Par contre, on peut garantir qu'il peut le devenir s'il le souhaite. Mais s'il ne le souhaite pas ou ne le peux, il n'y aucune raison d'édicter qu'utiliser un service mutualisé proposé par-dessus le réseau (mais toujours situé en périphérie) est intrinsèquement mal. Surtout tant qu'il y a neutralité et interopérabilité, encore une fois. Sinon on prend le risque de limiter le développement d'Internet en réduisant son exploitation la plus complète aux experts à même de monter leur propre plate-forme.

Dire Si tout le monde met ses vidéos sur Youtube et non sur son site perso, alors même si le réseau est neutre, c'est du minitel 2.0. est une inéptie révisionniste qui fait passer Internet pour le mythe du bon sauvage où il aurait existé un état initial vierge de tout pêché. La solution c'est pas l'auto-hébergement pour tous, c'est la libre concurrence via la neutralité et l'interopérabilité.

Pour faire simple, le neutralité de net correspond à des problèmes de législation, et le minitel 2.0 a des problèmes d'usages.

Ca c'est faux. Non seulement parce que la neutralité ça existe en terme de communication avant même qu'elles aient été électroniques (i.e. La Poste) et ensuite parce que la neutralité sur Internet vient de l'usage qu'ont introduit les protocoles qui sont à sa base en partant de la notion de end-to-end. Pour reprendre Lessig, code is law.

Or Internet ne s'est pas créé comme ça. Internet est décentralisé. Chaque machine a autant de poids qu'une autre (en pratique les serveurs de google ont plus de poids que mon blog à la maison, mais ce n'est pas la question. Tout le monde a sa chance).

Quand on a créé Unix et Internet, les micro-ordinateurs étaient des grosses machines sur lesquelles on se partageait l'accès, d'où la notion de time-sharing. Les accès se faisaient pas des machines très peu puissantes qui finalement exécutaient peu de chose. La volonté de beaucoup de libristes d'avoir un Internet indépendant de grosses entreprises de service pousse au révisionisme.

Quand on parle de Minitel 2.0, on parle surtout de savoir si l'opérateur de réseau a le droit ou pas de décider quel type de contenu a le droit de circuler sur son réseau. A l'époque du Minitel, il fallait montrer patte blanche à France Télécom pour avoir le droit d'opérer un service. C'est ça qui est à l'opposé de l'essence d'Internet dans lequel le réseau est agnostique par rapport au contenu qui transite. Et c'est ça qui est un danger pour l'innovation non seulement parce que ça la ralentit (on ne peut pas inventer et déployer en quelques jours si on doit demander l'autorisation de l'opérateur) mais aussi parce que les opérateurs deviennent de plus en plus des fournisseurs de contenu et peuvent donc décider de privilégier leurs propres services sur leur infrastructure.

Donc la NdM est non seulement un procès d'intention mais montre en plus encore une fois que 95% des gens qui invoquent l'expression Minitel 2.0 à tout bout de champ n'y comprennent rien.

Et comme ça, c'est plus clair : http://lists.zeromq.org/pipermail/openamq-dev/2010-March/001(...) ?