ribwund a écrit 1439 commentaires

free mettra surement à jour sa QoS

Ça sous-entend que c'est une histoire de QoS, pas de peering.

Euh, je vois qu'Apple et Google contribuent à peu près autant l'un que l'autre (check les camemberts plus bas)

Le camembert c'est depuis la création du projet. Si tu regardes les dernieres années (y'a les graphes ici: http://blog.bitergia.com/2013/03/01/reviewers-and-companies-in-webkit-project/ ), c'est quasi 50% des contributions qui viennent de google (et 25% apple).

Les chiffres ?

http://blog.bitergia.com/2013/02/06/report-on-the-activity-of-companies-in-the-webkit-project/

Au delà de la technique, vous nous trouvez pas cela bizarre qu'Opéra réagisse aussi vite ?

Je trouve pas ça bizarre, le choix qu'ils avaient annoncé c'était de se baser sur le code de chromium, pas webkit en particulier. C'est donc tout à fait logique qu'ils suivent chromium dans le fork.

FYI: LWN interprete la nouvelle de façon très en faveur de Google: http://lwn.net/SubscriberLink/545562/e1286a20d71d1701/

Le bitcoin est décentralisé, il ne peut donc pas être contrôlé par une entité, c'est un code source libre, c'est ces 2 propriétés qui expliquent sont succès et personnellement je préfère ça plutôt que de voir le succès d'une monnaie électronique fournie par Amazon, Facebook ou Google…

50% de la puissance computationnelle peut décider d'un changement d'algorithme (comme recemment quand ils ont décidés que l'ancienne version du client prendrait le pas sur la nouvelle). Bon après j'imagine qu'en temps qu'utilisateur t'es pas obligé de "suivre" le fork majoritaire, mais ça serait le bordel…

C'est une version bizarre de la democratie vu que avec les fermes GPU et les fermes ASIC, la puissance n'est que relativement distribuée.

Je vois, j'interprete le patent grant differement je pense. A mon avis ce sera clarifié quand l'accord sera public (et à ce moment on verra si le patent grant est modifié, et comment).

Perso, je prend ça comme un "amuse toi à forker et tu vas prendre", pas sur que quiconque ose maintenant quand même.

Je pense que c'était déjà le cas, si tu forkais t'avais 0 protection.

http://blog.webmproject.org/2013/03/onward.html

there was certainly no "finding" or "admission" of infringement

À moins d'aller au procès, rien ne dit que MPEG-LA avait des brevets couvrant VP8. D'autre part je ne vois pas ce qui te fait affirmer que dans le pool existant (sans les nouveaux brevets MPEG-LA) Google était propriétaire de tous et qu'il n'y avait pas de licence/sublicence. Je vois ton point de vue, mais pour moi y'a rien de nouveau, si il y a un problème il existait avant (le fait que çe ne couvre que le protocole publié par Google notamment).

Oui j'ai vu les commentaires.

Je vois ton point de vue (le fait que ça ne couvre que le format VP8), mais y'a rien de nouveau dans l'annonce de l'accord. Google possèdait deja (ou avait une licence) sur des brevets VP8 ou lié (notamment les brevets de On2), ça rajoute uniquement plus de brevets dans le pool royalty-free.

Je m'en fou de cette partie, car j'ai le CLA. GPL ou tartampion, c'est une licence en plus pour lui, elle n'est pas pour moi.

Surtout que si j'ai bien compris, tu vendais deja des versions proprios, donc pour les personnes qui ont signés le CLA ça change vraiment pas grand chose.

D'ailleurs il me semble que la GPL est censé être utilisateur-centrique et non developpeur-centrique. Le but ce n'est pas de forcer les entreprises à contribuer, mais de permettre aux utilisateurs de modifier les logiciels qu'ils utilisent.

Alors que pour le developpeur original, l'interet du libre c'est souvent de recevoir des contributions. Même si le logiciel est GPL, si y'a un "jeté de code" sur un ftp dans un recoin de l'internet, ça va pas beaucoup plus l'aider que si y'avait rien eu.

Depuis deux semaines, Google a déjà flingué le libre, en signant un accord qui stipule que ce n'est pas libre (ils ont acheté des droits mondiaux dessus, donc ils les reconnaissent, mais n'ont pas acheté le droit de libérer les brevets).

Source ?

L'accord n'a pas encore été publié, mais sachant que le but de VP8 c'est de fournir un codec "royalty-free" et qu'ils ont obtenu une licence (et le droit de "re-licencié") sur les brevets en question en royalty-free, rien ne change.

En pratique ces nouveaux brevets vont s'ajouter au pool couvert par le "patent grant": http://www.webmproject.org/license/additional/

Bref, soit c'était peut etre deja pas libre, mais c'est pas l'accord avec MPEG-LA qui change quelque chose.

Si Red Hat savait que tout son code pouvait être repris par Oracle, amélioré, modifié et revendu sans qu'Oracle n'ait à fournir le source correspondant, je suis certain que le management de Red Hat aurait toute autre vision du libre.

Une fois que y'a une masse critique, il me semble qu'il y a quand même intérêt à reverser les contributions (par exemple pour faciliter le passage d'une version du noyau à l'autre) ? Que je sache les grosses boites web (ex: Google) n'ont pas d'obligations à contribuer mais le font quand même.

Je pourrais comprendre l'argument du SPAM, mais le blocage de la présence à un contact ajouté manuellement, là c'est vraiment pas défendable.

Ça m'étonnerait que ce soit volontaire… c'est plutôt une erreur de config d'un coté ou de l'autre (genre version de protocole différente ?)

Sinon y'a des chances d'avoir une clé USB qui fait de la crypto asymétrique dans pas trop longtemps: http://www.computer.org/cms/Computer.org/ComputingNow/pdfs/AuthenticationAtScale.pdf

Et la puce de paiement sans contact ne me semble guère mieux.

Par curiosité, pourquoi ? J'ai jamais regardé en détail, mais y'a pas de raison que ce soit moins sécurisé que la puce non ?

Là c'est juste pas possible, je ne peux pas forcer quelqu'un à utiliser un compte Google si il veut me parler.

Y'a rien à forcer, tu l'ajoutes dans ta chat list et ça marche…
La seule chose qui marche plus c'est l'invitation xmpp depuis un compte non gmail (et j'avoue que les invits spam me faisaient bien chier).

Une dernière question, quelqu'un sait comment lancer une demande d'ajout de contact Gtalk->autre serveur XMPP depuis l'interface de Gmail ? J'espère que c'est encore possible sinon ça va être relou pour dire au gens d'utiliser mon nouveau JID.

cf. ci-dessus.

Pour moi c'est à cause de la demande. (Dart, qui est un projet des auteurs de V8, essaie d'etre la version de js intrinsèquement rapide).

Ils retirent vraiment la synchronisation CalDAV qu'ils viennent tout juste de mettre en place ou bien il s'agit d'API complémentaires ???

Le support existe toujours mais c'est basé sur une whitelist.

Pour pas avoir a implementer deux sandbox.

Avec ce genre d'argument, on peut dire n'importe quoi surtout si comme tu le dis y'a pas de détail.

L'argument c'est pas "c'est évident", c'est "c'est évident sachant que le SLA est de 99.9%".

Autant la sauvegarde sur bande je veux bien y croire, autant pour le multi-site je demande des preuves, et la distance entre les sites.

Drive c'est un produit pour utilisateur final, pas pour developpeur, donc y'a pas de détail. Mais c'est assez évident que c'est multi-site, tu peux pas avoir un SLA à 99.9% (et en pratique il est largement atteint) sans avoir une réplication correcte.

Pour les produits pour les développeurs, y'a (un poil) plus de détails: https://developers.google.com/storage/docs/faq#policy

Pour $500 t'as pas de réplication multi-site et de la sauvegarde sur bande…

Oui, j'ai pensé que quelqu'un me répondrait DVCS :)
Je pense pas que la cible d'un DVCS ce soit le grand public (et le DVCS fonctionne assez differement du operational transform de Abicollab, GDocs: c'est une autre granularité, et c'est implicite),