Je vous ai déjà parlé de l'importance de la décentralisation : il faut créer des services indépendants qui communiquent entre eux (l'email) plutôt qu'un gros service qui contrôle tout le monde (Facebook, Google).

Mais créer un service décentralisé est une véritable gageure. Si les problèmes techniques sont légions (compatibilité, communication, standardisation), ils ne sont rien face à l'immense défi humain. Je pense notamment aux abus comme le spam ou la fraude. Un service centralisé peut gérer les spammeurs au cas par cas en désactivant les comptes. Un service décentralisé doit mettre en place une stratégie complètement différente. Le seul réseau décentralisé d'envergure, le mail, n'a d'ailleurs jamais résolu ce problème.

Pour réussir, un service décentralisé doit donc offrir une solution au moins équivalente en termes de confort d'utilisation, une résolution des problèmes propres à la décentralisation et un petit plus qui fera la différence, qui poussera les utilisateurs à abandonner la concurrence.

Le résultat est sans appel : depuis l'email, aucune solution décentralisée n'a réellement percé auprès du grand public. Même le protocole de chat XMPP ne doit son succès qu'à son adoption par Google. Et, soyons honnêtes, si Google décide d'arrêter d'utiliser XMPP demain, ce ne seront pas les utilisateurs de Google Chat qui se plaindront mais bien les utilisateurs des autres serveurs qui n'auront plus accès à la majorité de leurs contacts.

Les raisons d'un échec

Comme je vous le disais précédemment, les libristes se sont concentrés sur la résolution des problèmes techniques, faisant fi de l'expérience utilisateur. La décentralisation ne fait pas exception. Ainsi, il est hors de question de mélanger un serveur de mail avec un serveur de chat XMPP. Chaque outil doit être indépendant. La conséquence directe est que la majorité des utilisateurs de solutions libres ont une adresse pour le mail et une pour le chat. Et, quand bien même certains services offriraient une adresse commune, il n'y aucune réelle intégration contrairement à Google qui, entre autres, envoie par mail les messages reçus lorsqu'on est déconnecté.

Face au succès des services webs centralisés, le monde libre a répondu avec la license AGPL. Plutôt que de se poser la question de l'indépendance, de ce que nous souhaitions construire et offrir aux utilisateurs, nous nous sommes contentés de nous vautrer dans notre petite zone de confort : l'accès au code source et l'évangélisme.

Les avantages de la centralisation

Mais il y a pire : la décentralisation est censée nous garantir l'indépendance, la sécurité par rapport à une seule entreprise. Mais, entre nous, quels sont les risques lorsque vous utilisez un service en ligne ?

1. Le serveur est indisponible pour une période prolongée suite à une défaillance matérielle
2. Vos données sont perdues suite à une défaillance matérielle et un mauvais plan de sauvegarde.
3. Vos données sont volées suite à un piratage
4. Votre fournisseur fait faillite et disparaît dans la nature
5. Votre fournisseur décide de couper l'accès à vos données sans préavis

Chez un géant comme Google, la probabilité de souffrir d'un des 4 premiers problèmes est virtuellement nulle. Quand à la cinquième, elle arrive de temps en temps. Cela fait d'ailleurs un certain buzz et cela permet aux libristes d'avoir des exemples concrets pour illustrer le problème de la centralisation.

Les alternatives à la centralisation

Fuyant les géants, vous vous êtes installé chez un petit fournisseur indépendant. Tristement, il faut reconnaître que les 5 problèmes deviennent beaucoup plus probables. Vous devenez donc extrêmement dépendant de ce fournisseur qui peut faire faillite, se faire pirater ou brusquement augmenter ses prix sans que vous n'ayez la moindre chance d'alerter l'opinion publique.

Étant très doué en informatique, vous faites partie de cette minorité capable de gérer des services de base et vous décidez alors de passer à l'autohébergement. Malheureusement, cela a un coût non négligeable. Si il permet de résoudre les deux derniers points, il maximise la probabilité des trois premiers. Cela vous coûte de l'argent, cela vous prend un temps fou et cela vous force à être disponible en permanence. Un exemple célèbre est Rick Falkvinge, fondateur du Parti Pirate. Il héberge son site sur son propre serveur dans son bureau. Régulièrement, son site est indisponible pendant plusieurs jours suite à une panne de courant ou un problème de disque dur alors qu'il est à l'étranger. Dans ces cas-là, il ne communique plus que par Twitter, Google+ et Facebook, les réseaux centralisés…

Il s'en suit, de manière paradoxale, que la solution la plus sécurisée et qui vous donne le plus d'indépendance est… d'utiliser un géant centralisé comme Google.

Google plus libre que Diaspora

Et à ce petit jeu, Google est très fort et se permet le luxe d'offrir une fonctionnalité de Libération de Données : vous pouvez à tout moment télécharger toutes vos données dans un format aisément exploitable. Photos, publications, commentaires, contacts : tout y est ! Il s'en suit que j'ai un meilleur contrôle de mes données chez Google que celles sur Diaspora, où l'outil d'export n'est pas encore complet !

Diaspora et Status.net sont les exemples mêmes de l'échec du libre face à la décentralisation. Se contentant de copier les solutions centralisées en aposant un protocole décentralisé dessous, elles ont justifié leur échec par le monopole des acteurs de Facebook et Twitter. Le récent succès de Pinterest montre pourtant qu'il y a de l'espace pour l'innovation.

Et pourtant…

C'est dommage ! La décentralisation aurait pu devenir le cœur de notre expérience utilisateur. L'analyse du problème montre que la seule solution qui rende réellement indépendant est l'autohébergement mais qu'il faudrait le rendre simple, accessible à tous et sûr. Imaginez un instant une version serveur et une version client de votre distribution préférée. La version serveur s'installe en un clic sur le boitier dans votre salon et une interface graphique permet de créer les comptes sous forme d'une adresse email. Quand à la version client, il suffit de s'y connecter avec son adresse mail pour avoir aussitôt accès aux mails, aux calendriers, au chat, au partage de fichiers, à votre flux d'informations continues. C'est un rêve que certains n'abandonnent pas.

Simple et efficace.

Mais… Attendez une seconde ! C'est exactement ce que Google est en train de faire avec ChromeOS. Des services décentralisés, redondants, accessible du monde entier en un clic. Il n'y a qu'un seul hic : ils sont contrôlés par une seule société. Un société qui fait tout trop bien, allant jusqu'à financer la concurrence pour encourager la compétition. Si vous étiez à leur place, que feriez-vous de différent ? Sincèrement ?

Alors, préférez-vous mettre tous vos œufs dans un unique panier très solide ou … pas de panier du tout ?

Photo par Mark Tominski

Original post of Ploum.Votez pour ce billet sur Planet Libre.

Une des fonctionnalités les plus impressionnantes de la nouvelle version d’Android, la 4.2, est certainement Photo Sphere, un nouveau mode dans l’application native de l’appareil photo qui permettra de capturer des clichés sur 360° (un panorama amélioré en somme). Nous avons déjà pu voir Photo Sphere en action sur une vidéo publiée par Google et nous savons également que les photos prises par cette nouvelle fonction pourront être partagées directement sur Google Maps.

Cependant, nous n’avions aucune information quant à un partage possible autrement que par Google+ ou Google Maps. Car si les panoramas pourront bien évidemment être visionnés sur nos smartphones, cela sera moins facile sur un site internet classique. Et justement, pour pouvoir intégrer ces clichés et permettre à vos visiteurs de les parcourir, un dossier a fait son apparition sur GitHub.

Ce script est au final plutôt simple à intégrer (c’est le but en même temps). La marche à suivre est la même que le fichier test.html (sur lequel vous pouvez tester la chose) visible sur le dossier de GitHub : vous devrez tout d’abord inclure deux fichiers JavaScript externes et compléter par un troisième script qui utilisera les fonctions ainsi incluses afin de créer le panorama. Dans cet exemple, il faudra donc cliquer sur le lien « makeIt » pour générer et profiter du panorama d’exemple.

Et c’est plutôt bien foutu finalement : le panorama est affiché dans un div et nous pouvons naviguer au travers grâce à quelques cliquer-glisser. Et si vous le souhaitez, vous pouvez même profiter calmement du spectacle offert par la chose puisque le panorama défile aussi automatiquement sous nos yeux, sans que l’on n’ait quoi que ce soit à faire.

Via

Original post of Tasse de Café.Votez pour ce billet sur Planet Libre.

Le 26 octobre 2012 a été publiée la cinquième version des exceptions à l’interdiction de contournement des systèmes de protection du Copyright (droit d’auteur) aux États-Unis. Ces exceptions sont débattues dans le cadre d’une longue procédure de consultations participatives prévue par la section 1201 du Digital Millennium Copyright Act (DMCA), et menée par le bureau du Copyright de la bibliothèque du Congrès.

Cette révision triennale de la réglementation a pour but de permettre une adaptation rapide du cadre juridique aux évolutions technologiques. C’est une manière de procéder très différente de la nôtre, puisque nous bénéficions en France d’un cadre légal définissant à l’article L. 122-6-1 IV du Code de la propriété intellectuelle une exception globale à des fins d’interopérabilité :

La reproduction du code du logiciel ou la traduction de la forme de ce code n’est pas soumise à l’autorisation de l’auteur lorsque la reproduction ou la traduction au sens du 1° ou du 2° de l’article L. 122-6 est indispensable pour obtenir les informations nécessaires à l’interopérabilité d’un logiciel créé de façon indépendante avec d’autres logiciels [...]

Le défaut de cette méthode est que c’est le juge qui trace la limite par la jurisprudence, et qu’en l’absence de contentieux et donc de jugements, nous sommes confrontés à une forme “d’insécurité juridique”. Les américains savent eux de manière beaucoup plus claire ce qu’il est possible de faire ou non. Ainsi, concernant les smartphones et les tablettes, c’est la classe B qui nous intéresse :

B. Wireless Telephone Handsets—Software Interoperability

Computer programs that enable wireless telephone handsets to execute lawfully obtained software applications, where circumvention is accomplished for the sole purpose of enabling interoperability of such applications with computer programs on the telephone handset.
This exemption is a modification of the proponents’ proposal. It permits the circumvention of computer programs on mobile phones to enable interoperability of non-vendor-approved software applications (often referred to as ‘‘jailbreaking’’), but does not apply to tablets—as had been requested by proponents—because the record did not support it.

Mais qui étaient donc les “proponents” , c’est à dire ceux qui ont proposé et soutenu cette classe de périphériques, qui voulaient pouvoir jailbreaker non seulement leurs smartphones, mais aussi leurs tablettes ?

Proponent Electronic Frontier Foundation (‘‘EFF’’), joined by New America Foundation’s Open Technology Initiative, New Media Rights, Mozilla Corporation (‘‘Mozilla’’), and the Free Software Foundation (‘‘FSF’’), as well as several hundred individual supporters

Il n’est pas surprenant d’y retrouver l’EFF, déjà à l’origine de la proposition en 2010, soutenue par les groupements du logiciel libre les plus influents politiquement, la FSF et Mozilla, ainsi que par des centaines de particuliers. Mais pourquoi le bureau du Copyright a-t-il refusé de considérer cette nouvelle catégorie de périphériques ? Le FUD habituel d’un lien entre jailbreak et “piratage”, c’est-à-dire “contrefaçon” en droit français, est balayé d’un revers de main :

While Joint Creators raised concerns about pirated applications that are able to run on jailbroken devices, the record did not demonstrate any significant relationship between jailbreaking and piracy.

C’est en fait le caractère mal défini ou trop large de l’appellation “tablette”, recouvrant potentiellement trop de types de périphériques différents, qui est la justification du refus :

The Register found significant merit to the opposition’s concerns that this aspect of the proposed class was broad and illdefined, as a wide range of devices might be considered ‘‘tablets,’’ notwithstanding the significant distinctions among them in terms of the way they operate, their intended purposes, and the nature of the applications they can accommodate. For example, an ebook reading device might be considered a ‘‘tablet,’’ as might a handheld video game device or a laptop computer.

Même si l’agence gouvernementale américaine des télécoms (NTIA) était d’un tout autre avis, puisqu’elle considérait la définition proposée par l’EFF comme totalement pertinente :

NTIA was persuaded that the proposed class should apply to tablets as well as mobile phones, believing that category to have been sufficiently defined by EFF.

Cependant, le bureau du Copyright n’insulte pas l’avenir et laisse la porte ouverte pour les prochaines révisions des exceptions :

In future rulemakings, as mobile computing technology evolves, such a definition might be more attainable

Dont acte, rendez-vous en 2015 !

Original post of fgallaire.Votez pour ce billet sur Planet Libre.

Il y a quelques temps, on ma confié un Arduino Uno afin que j'en produise un test. Pour les gens qui ne connaissent pas ce type de produit, il s'agit d'une carte électronique capable de recevoir de l'information via divers capteurs et de contrôler plusieurs sorties électroniques. L'objectif d'un tel matériel est de faire ni plus ni moins que de la domotique.

Je ne suis pas du tout électronicien mais j'ai cependant quelques bases suite à ma filière S-SI au lycée. J'ai donc porté un intérêt tout particulier à cette carte et ce qu'elle pouvait fournir. Il n'est pas inutile de rappeler que je suis sur une Debian et que l'ensemble de mon travail devait pouvoir se faire à travers cet environnement. En parcourant la documentation, il s'avère qu'on peut développer sur cette carte qu'on soit sur une distribution Linux, un Windows ou bien sur un Mac OS X. L'installation des logiciels sur mon environnement était très simple. En effet Debian fournit des packages dédiés pour jouer avec les cartes Arduino. Il faut noter que pour les autres grandes distributions, c'est du pareil au même, c'est donc un premier bon point.

J'avais une grande appréhension quant au langage de développement qui allait être utilisé. Des lectures que j'ai pu faire de la domotique, le C est beaucoup utilisé et je n'ai pas spécialement d'affinité avec ce langage (je ne l'utilise pour ainsi dire jamais). Au final, j'ai été une nouvelle fois étonné puisque Arduino a pensé aux gens comme moi qui n'auraient pas eu les compétences requises en C. Arduino fournit en effet un outil de développement dont le langage se rapproche énormément de Processing. Sans aller à les comparer en terme de fonctionnalité, je m'arrêterai simplement sur l'écriture qui s'en rapproche beaucoup. Le langage facilite énormément le développement puisque une fois la carte branchée, il suffit de commencer à développer en ne se posant que des questions fonctionnelles. On déploie le code quasi instantanément et le rendu est direct. La documentation est évidement très complète et permet de développer rapidement des choses sans se prendre la tête. Cependant, pour les allergiques au Java, vous devrez quand même installer une jvm pour pour lancer l'éditeur et je suppose que c'est ce même langage qui est envoyé et exécuté sur la bestiole.

Voici un bout de code faire clignoter aléatoirement 3 leds :

// Les 3 sorties de la carte qui identifient les entrées des 3 leds
int leds[] = {11, 12, 13};
int i;
 
// code exécuté que la carte est réinitialisée 
void setup() {
  for (i = 0; i < 4; i++) {         
    pinMode(leds[i], OUTPUT);
  }
}
 
// code exécuté à fréquence de temps régulière
void loop() {
  int level = random(3);
 
  // suivant le nombre aléatoire tiré, on aliment ou pas les leds
  for(i = 0; i<4; i++) {
    if(i == level) {
      digitalWrite(leds[i], HIGH);
    }
    else {
      digitalWrite(leds[i], LOW);
    }
  }
 
  delay(100);
}
// Ce n&#039;est vraiment pas compliqué :)

La carte n'était pas livrée seule, c'est une plaque d'essais et une belle quantité de composants qui l'accompagnaient. On reconnaîtra des fils de connexions, des résistances, des leds, des boutons poussoirs et bien d'autres choses.

C'est à ce moment que ce glisse le vrai problème rencontré. Bien que l'ensemble de ces composants se suffit pour bidouiller et faire plein de choses, sans matériels complémentaires, ça devient compliqué d'assembler les circuits. Ce n'est pas de la faute d'Arduino mais si vous deviez faire l'acquisition d'un tel outil, ne serait-ce que dans un objectif pédagogique, prenez soin de vous munir d'outils en plus.

Les quelques circuits que j'ai pu bricoler étaient des modifications simples des exemples de la documentation. J'envisage de m'acheter la carte Arduino Ethernet : je souhaite effectivement travailler sur un monitoring de mes serveurs. Cette version de carte (Arduino Uno) manque de l'interface réseau pour pouvoir rentrer vraiment dans mes besoins personnels et mes compétences en électronique trouvent vite leurs limites.

C'est un excellent produit et je présume que beaucoup de personnes se sont déjà empressées de jouer avec. Si vous êtes curieux et que le monde de la domotique vous intéresse, je vous recommande fortement cette marque qui a mis toutes les billes du coté du développeur : vous.

Une note supplémentaire qui donnera le sourire aux anglophobes (la doc officielle n'existe pas en français), vous pourrez trouver un tas d'informations et notamment des tutoriels videos sous-titrés sur Arduino de RS Components.

Original post of Simon Vieille.Votez pour ce billet sur Planet Libre.

Lire la Suite »

Original post of Olivier Delort.Votez pour ce billet sur Planet Libre.