Faut-il encore présenter StatusNet ? Il est généralement considéré comme le clone libre et décentralisé de Twitter de référence. Une réussite toute relative comparé au nombre d’utilisateurs sur la version propriétaire mais un bon succès quand même par rapport aux autres projets libres du genre. Cependant, pour Evan Prodromou, son créateur, il était temps d’avoir quelque chose de nouveau et plus moderne. Il est donc passé de PHP à NodeJS, de MySQL à NoSQL, de Gitorious à Github et a créé Pump.io. Les concepts de fonctionnement sont légèrement différents : StatusNet est clairement calqué sur Twitter avec la limite de 140 caractères alors que Pump utilise un formatage riche en wysiwyg sans limite de taille, le tout à la sauce Bootstrap. Cependant le public StatusNet est visé puisqu’une migration forcée d’identi.ca (instance de StatusNet rassemblant une très grosse partie des utilisateurs) vers Pump est prévue en avril. La messe étant dite, faisons une présentation de ce nouveau venu.

Avec un nom pareil, je trouve quand même que ça part mal.

Protocole

J’avais parlé de ce problème dans mon article précédent : Pump n’utilise pas OStatus (le groupe de protocoles utilisé par StatusNet) et ne sera donc pas compatible avec ce dernier. C’est nul, je sais. Cependant les standards utilisés ne diffèrent pas trop non plus. Les activity streams sont au cœur du réseau (déjà présents dans OStatus sous forme XML mais l’on va encore plus loin cette fois). Activity Stream est un standard initié par Facebook, Google, Microsoft (et plein d’autres gens bien) pour unifier la façon de représenter des actions sur les réseaux sociaux et faciliter l’interopérabilité. Un message d’un serveur Activity Stream à un autre est par exemple :

    {
        "id": "http://coding.example/api/activity/bwkposthw",
        "actor": {
            "id": "acct:bwk@coding.example",
            "displayName": "Brian Kernighan",
            "objectType": "person",
            "url": "http://coding.example/bwk"
        },
        "verb": "post",
        "object": {
            "id": "http://coding.example/api/note/helloworld",
            "content": "Hello, World!"
            "objectType": "note"
        },
        "published": "1973-01-01T00:00:00"
    }

Dans pump, une activité est authentifiée via OAuth, ce qui permet de séparer complètement l’authentification du contenu

POST /api/user/bwk/feed HTTP/1.1
Host: coding.example
Authorization: OAuth oauth_consumer_key="[...]",
    oauth_token="[...]", [...]
Content-Type: application/json

{
    "verb": "follow",
    "object": {
        "id": "acct:ken@coding.example",
        "objectType": "person"
    }
}

C’est simple et clair. Un exemple assez sympa de proof of contest est openframgame.com. C’est un site très simple de simulation de ferme. Vous avez de l’argent avec lequel vous achetez des parcelles, des semences et de l’eau. Vous plantez des semences, vous arrosez vos plantes et les revendez une fois atteinte la maturité. Rien de très intéressant dans le fonctionnement interne mais là où ça peut être intéressant est qu’il communique avec un compte Pump via des activty streams. Le fait que votre plante ait soif ou que vous ayez revendu une parcelle de tomates est une activité envoyée au serveur. Vous pourriez ainsi prévoir des réactions automatisées comme l’envoi de l’action d’arroser lorsque une plante a soif ou poster un message de victoire dès votre premier million amassé. On peut facilement imaginer les nombreuses possibilités si certains services utilisaient le couple activity streams – PubSubHubbub. En parlant de PuSH, Evan a annoncé dans un status vouloir l’intégrer dans pump.io.

Pourquoi pas du RSS (l’enfant pauvre et délaissé du web actuel) me diriez-vous ? Je ne suis pas dans la tête d’Evan mais il a un jour fait une réflexion disant que si Google abandonnait Google Reader (et donc le RSS), c’était sans doute car le RSS est très primitif. Pas de principe de conversation, on reste dans un schéma de producteur-consommateur qui ne correspond pas web social actuel. Personnellement, je ne pense pas que le RSS soit dépassé (car le schéma producteur-consommateur convient très bien à certains types de contenu) mais le rejoins sur le fait qu’il n’est pas adapté aux réseaux sociaux. Un flux public en RSS pour suivre les messages d’une personne peut être utile (je l’avais suggéré) mais ne doit pas être le protocole central pour l’interaction (ce qui était le cas dans StatusNet).

Ce qui est génial avec cette utilisation des activity streams est qu’il n’y a plus de formats différents pour l’API publique, la communication entre serveurs ou le flux d’un utilisateur : tout est activité (ou liste d’activités) au format JSON. J’envoie une activité (après authentification avec OAuth) avec le verbe « follow » à mon serveur pour donner l’ordre de suivre quelqu’un et je reçois en réponse, en cas de succès, l’activité qui apparaîtra dans mon flux. Même l’interface web est en fait un client web utilisant des activités avec le serveur. La plupart des actions (par exemple l’enregistrement d’un nouvel utilisateur) se fait via des activités.

Je vous laisse lire la page API.md pour plus de détails mais cela explique bien le fonctionnement général. C’est simple et propre, j’aime.

Tester

À quoi ressemble ce service ? C’est très facile, allez sur la page Try it qui vous redirigera aléatoirement vers une des 10 instances déployées par Evan. Contrairement à StatusNet qui avait identi.ca comme point central du réseau (au point où les gens confondaient parfois les deux et certains clients ne supportaient qu’identi.ca), Evan a voulu que Pump fonctionne réellement comme une fédération d’instances décentralisées.

Inscrivez-vous sur une instance, suivez d’autres gens (en passant par Login -> Account on another server? dans le cas d’utilisateurs sur d’autres serveurs), envoyez des messages et des images. On n’a pas encore toutes les fonctionnalités de StatusNet mais ce n’est pas loin.

Installation

Bon fini de rire, comment on déploie son instance sur son serveur ? Bonne nouvelle : il est assez simple de faire tourner un site en NodeJS. Mauvaise nouvelle : pour ceux qui font tourner plusieurs services sur une même machine via Apache ou Nginx, déployer Pump risque de vous poser des problèmes. Votre serveur web habituel écoutant sur le port 80 ou 443, il y a conflit avec NodeJS voulant écouter sur le même port.

Plusieurs possibilités s’offrent à vous :

• utiliser pump seul sur le port 80 ou 443 (pas pratique)
• utiliser pump sur une IP interne ou différente de celle utilisée par Apache/Nginx (pas facile, peut être fait en utilisant une machine virtuelle par exemple, configuration ici pour apache et ici pour nginx)
• utiliser un port différent pour NodeJS avec un proxy redirigeant vos connexions vers le port 80 (perte de performance)

Il faut savoir que NodeJS a une bonne gestion de la concurrence ce qui lui permet, entre autres, de si bons benchmark. En utilisant un proxy, vous empêchez cette concurrence et réduisez les performances de Node à celles d’Apache. C’est dommage mais pas insurmontable non plus.

Après recherche, j’ai finalement trouvé deux systèmes fonctionnant pas trop mal avec Varnish (système de cache) et Apache : soit tout fonctionnant sur le port 80 avec Varnish servant de proxy, soit avec Pump écoutant sur le port 443 et Apache sur le port 80. Voulant utiliser du SSL pour pump, j’ai choisi la deuxième solution avec un certificat CaCert. Ci-dessous les explications des deux méthodes :

Tout sur le port 80

Première méthode : on n’utilise pas de SSL et fait tout tourner sur le port 80. Pour cela, j’utilise Varnish pour faire la différence, en m’aidant de ce tutoriel.

Configurez Varnish pour écouter sur le port 80 en modifiant le fichier /etc/default/varnish

DAEMON_OPTS="-a :80 \
             -T localhost:6082 \
             -f /etc/varnish/default.vcl \
             -S /etc/varnish/secret \
             -s malloc,256m"

Créez le fichier /etc/varnish/default.vcl pour indiquer la redirection

backend apache {
    .host = "127.0.0.1";
    .port = "6001";
}
backend node {
    .host = "127.0.0.1";
    .port = "6002";
}
sub vcl_recv {
    if(req.http.host == "pump.mart-e.be") {
        set req.backend = node;
    } else {
        set req.backend = apache;
    }

    if (req.http.Upgrade ~ "(?i)websocket") {
      return (pipe);
    }
}
sub vcl_pipe {
  if (req.http.upgrade) {
    set bereq.http.upgrade = req.http.upgrade;
  }
}

En cas de domaine contenant « pump.mart-e.be », on redirige vers le port 6002, autrement vers le port 6001. Les commandes avec « pipe » étant pour permettre le fonctionnement des websockets à travers Varnish. Il vous faudra ensuite faire écouter Apache sur le port 6001 au lieu de 80 en modifiant le fichier /etc/apache2/ports.conf.

NameVirtualHost *:6001
Listen 6001

et en changent tous vos <VirtualHost *:80> par <VirtualHost *:6001> dans la configuration des sites.

En ce qui concerne pump en lui même ce n’est pas trop compliqué. Le fait qu’on utilise le port 6002 pour pump vous permet de lancer node avec un utilisateur non-root. Pump ne fonctionne pas (encore) bien avec la version 0.10 de NodeJs (il manque même certaines dépendances je pense), préférez donc la 0.8. Comme pump.io est encore en développement actif, on préférera la version git à mettre à jour régulièrement. Les explications ci-dessous utilisent mongodb mais vous pouvez utiliser un autre service tel que Redis ou même laisser le « disk » par défaut pour ne pas avoir de base de donnée (attention aux performances).

Utilisez le fichier pump.io.json.sample pour créer le fichier /etc/pump.io.json. Voici le mien :

{
    "driver": "mongodb",
    "params": {"host": "localhost", "port": 27017},
    "secret": "azerty12345",
    "noweb": false,
    "site": "pump-e",
    "owner": "mart-e",
    "ownerURL": "http://mart-e.be",
    "port": 80,
    "serverUser": "www-data",
    "hostname": "pump.mart-e.be",
    "address": "127.0.0.1",
    "nologger": false,
    "uploaddir": "/var/www/pump/uploads",
    "debugClient": false,
    "firehose": "ofirehose.com"
}

Installez bien le paquet mongodb et démarrez le démon (ici sur le port 27017). N’oubliez pas non plus de créer le dossier uploaddir mentionné. Lancez pump via

ou utilisez la commande forever (npm install -g forever) pour quelque chose de plus stable. Si vous sauvegardez les logs dans un fichier, vous pouvez les consulter via bunyan (npm install -g bunyan et puis tail -f pumpd.log | bunyan), ça en facilitera grandement la lecture.

Et ceci était un des premiers services à interagir avec pump, c’est beau !

Pump en SSL

La config précédente est bien, mais c’est encore mieux si on utilise du HTTPS ! Trouvez-vous donc un certificat SSL (openssl req -nodes -new -keyout server.key -out server.crt) et envoyez-le sur votre serveur. Comme on ne veut pas produire de page d’erreur quand les gens essayent d’accéder à pump en HTTP, on va utiliser Varnish pour faire une redirection, status HTTP 302. Le fichier /etc/varnish/default.vcl devient donc :

backend apache {
    .host = "127.0.0.1";
    .port = "6001";
}
sub vcl_recv {
    if(req.http.host == "pump.mart-e.be" && req.http.X-Forwarded-Proto !~ "(?i)https") {
        set req.http.x-Redir-Url = "https://pump.mart-e.be" req.url;
        error 750 req.http.x-Redir-Url;
    } else {
        set req.backend = apache;
    }

    if (req.http.Upgrade ~ "(?i)websocket") {
      return (pipe);
    }
}
sub vcl_error {
  if (obj.status == 750) {
    set obj.http.Location = obj.response;
    set obj.status = 302;
    return(deliver);
  }
}
sub vcl_pipe {
  if (req.http.upgrade) {
    set bereq.http.upgrade = req.http.upgrade;
  }
}

Attention, si vous avez la version 3 ou plus de Varnish (dans Debian stable c’est encore la 2), la concaténation se fait avec un +, la ligne de calcul d’URL devient donc : set req.http.x-Redir-Url = "https://pump.mart-e.be" + req.url;

Varnish ne gère pas le trafic SSL donc on est obligé de rester sur le port 80 pour ce dernier.

Rien de change du coté d’apache (par contre faites bien attention dans le fichier ports.conf de ne pas écouter sur le port 443) mais le fichier de config de pump devient :

{
    "driver": "mongodb",
    "params": {"host": "localhost", "port": 27017},
    "secret": "monkey1",
    "noweb": false,
    "site": "pump-e",
    "owner": "mart-e",
    "ownerURL": "http://mart-e.be",
    "port": 443,
    "serverUser": "www-data",
    "hostname": "pump.mart-e.be",
    "address": "pump.mart-e.be",
    "nologger": false,
    "uploaddir": "/var/www/pump/uploads",
    "debugClient": false,
    "firehose": "ofirehose.com",
    "key": "/etc/ssl/server.key",
    "cert": "/etc/ssl/server.crt"
}

Notez que le champ « address » est passé de 127.0.0.1 à pump.mart-e.be. Sans cela, je n’ai pas réussi à accéder à mon serveur depuis l’extérieur. Ajoutez également l’URL de votre serveur pump (pump.mart-e.be ici) dans le fichier /etc/hosts pointant vers 127.0.0.1. Ainsi, la boucle est bouclée pour l’accès en local.

Via mes tests, j’ai noté que les serveurs semblaient retenir les précédentes informations de connexion. C’est-à-dire que les serveurs avec lesquels j’avais interagi à l’époque de mauvaises configs ou lorsque je tournais sur le port 80 semblent avoir retenu ces infos et je n’arrive plus à les contacter. J’ai ouvert un bug report à ce sujet. En attendant que cela soit réglé, faites bien attention de choisir votre mode de connexion et de vous y tenir.

Les clients

C’est bien beau d’avoir une bonne API mais qu’en est-il des clients externes ? Hélas, on n’en est qu’aux débuts. Il existe actuellement une librairie en python PyPump, utilisée par Muon, un client ncurse l’utilisant. C’est tout à ma connaissance…

Le fonctionnement de l’API semblant assez simple, ça ne devrait qu’être une question de temps avant l’apparition de plus de clients mais actuellement c’est un frein certain à l’adoption de pump. Si vous voulez recevoir la reconnaissance de toute une communauté (1170 personnes aux dernières nouvelles), c’est l’occasion rêvée pour faire un peu de développement !

Les services externes

Si vous voulez passer à Pump, une fonctionnalité intéressante est les bridges avec les autres réseaux. C’est dans ce but que pump2status a été créé. Pour l’instant, ce site vous permet de lier votre compte pump à votre compte StatusNet et vous permet de découvrir les gens ayant fait la transition (comme moi !). Dans le futur, ce site vous permettera de publier sur StatusNet vos activités Pump. Sont également prévus, par ordre de priorité et hackerliness Google+, Twitter, Facebook sans doute même des Foursquare, LinkedIn et Instagram plus tard. En raison du bug des anciennes configs mémorisées, pas certain que vous me trouverez (si vous voyez mart@pump.jpope.org, c’est mon compte de test, je ne devrais plus l’utiliser).

Là où Status.Net englobait un maximum de fonctionnalités, le but de Pump.io est d’être beaucoup plus minimaliste dans son mode de fonctionnement et de se baser sur des services externes. Les fonctionnalités de gestion du spam sont par exemple déléguées à activityspam (dont spamicity.info est une instance, wiki) ou le service OFireHose est utilisé pour faciliter la fédération du contenu public (dont ofirehose.com est une instance).

Les passerelles fonctionneraient avec ce même principe. On pourrait ainsi avoir une application externe s’occupant de récupérer du contenu venant de Twitter et de le convertir en activités poussées vers un compte pump. C’est une des possibilités parmi d’autres mais le principe reste d’utiliser des services externes.

L’idée (pas mauvaise) est de garder le coeur de Pump.io minimale pour avoir quelque chose de robuste et hack-friendly. Mon seul regret est l’absence d’extensions, je ne suis pas certain que le modèle de services externes fonctionne dans tous les cas de figure (pour une modification des templates par exemple).

Le futur

Dans une présentation datant de février dernier, Evan annoncait vouloir migrer les serveurs identi.ca de Status.Net vers pump.io en avril 2013. Les inscriptions sur identi.ca sont bloquées depuis quelques jours. On verra si ça pourra se faire mais je pense que le logiciel n’est clairement pas encore assez mature pour faire la transition aujourd’hui.

Vous en avez rêvé, e14n n’a fait : le bouton « Je n’aime pas » !

Un des soucis potentiel est que la transition casserait tous les clients Status.Net (n’utilisant plus l’API à la Twitter). Une possibilité serait de maintenir une compatibilité avec un bridge entre les deux. J’avais vu cette suggestion faite par Evan (mais n’arrive plus à retrouver le lien). Cela faciliterait grandement les choses le temps de la transition.

Si la sauce prend bien, Evan espère voir les gens adopter massivement pump.io et développer pour celui-ci. Les possibilités d’utilisation du réseau sont assez larges et intéressantes. Openfarmgame était une démo simple. Ih8.it en est une autre. On pourrait même imaginer des analyses globales des comportements via les publications poussées sur ofirehose (de la pub ?). Les principes de fédérations semblent bien réfléchis, et l’on devrait éviter les travers rencontrés avec StatusNet et identi.ca.

Si vous ne voulez pas passer à Pump.io (parce que ça ne correspond pas à ce que vous cherchez), faites une sauvegarde de votre compte identi.ca et utilisez Status.Net sur une autre instance (c’est le moment de passer à l’auto-hébergement). N’oubliez pas, ce n’est pas parce qu’identi.ca et Evan passent à Pump.io que la communauté est obligée de suivre. C’est du libre après tout.

Pump est encore un peu jeune mais néanmoins déjà utilisable. Essayez-le, faites-vous un avis et choississez ensuite si vous voulez rester sur StatusNet ou passer à Pump (ou utiliser les deux ou aucun). Je ne compte pas encore remplacer mon compte StatusNet par Pump mais ça sera sans doute le cas un jour (et me permettra d’abandonner définitivement mon compte Friendica inutilisé). En tout cas, espérons que ce réseau ne soit pas encore « un parmi tant d’autres ».

…
Les souvenirs et les regrets aussi.
Mais mon serveur silencieux et fidèle sourit toujours et remercie la vie.
Je t’aimais tant, tu étais si standardisée, comment veux-tu que je t’oublie ?

– Jacques Prévert.

Les réseaux libres et décentralisés c’est beau, pas de censure ou exploitation de vos données, bel exemple de liberté d’expression. Chacun choisissant son serveur, on évite les problèmes de points de passage uniques et diminue les problèmes en cas de défaillance d’un nœud. Enfin dans la théorie parce qu’en réalité c’est complètement le bordel. Les réseaux sociaux libres fleurissent un peu partout mais il n’y a pas moyen de s’entendre.

La semaine passée, pump.io venait de sortir sa version 0.2, une première release après 4 mois de développement (c’est là qu’on se rend compte que Diaspora avec ses 2 ans de développement s’est bien foutu de nous). Pump est un projet de Evan Prodromou, le créateur de StatusNet, et présenté comme la succession de ce dernier (prévu pour la 0.3, en avril 2013, les inscriptions sur identi.ca sont d’ailleurs désormais gelées). StatusNet continuera a vivre et être maintenu mais il ne faut pas s’attendre a voir de grandes nouveautés apparaître. Pump est écrit en NodeJS et avec une base de donnée NoSQL (MongoDB & co). Je n’ai aucun problème avec le fait d’abandonner le couple vieillissant PHP/MySQL (au contraire). Le point problématique est un aspect que l’on voit apparaître très souvent avec les réseaux sociaux libres : il n’utilise pas OStatus mais une nouvelle API. OStatus est une suite de protocoles (Atom, Activity Streams, PubSubHubbub, Salmon et Webfinger) qui permet de se mettre d’accord sur la façon dont deux serveurs OStatus peuvent communiquer. C’est grâce à OStatus que je ne suis pas obligé d’utiliser StatusNet pour communiquer avec quelqu’un l’utilisant, je peux utiliser Friendica par exemple. Cependant Friendica est un peu l’exception qui confirme la règle, a part lui qui met un point d’honneur a être compatible avec plusieurs réseaux, les autres utilisent systématiquement des manières propre pour communiquer.

Prenons l’exemple de Tent, un nouveau protocole décentralisé assez sympa (dont TentStatus est la partie permettant le microblogging). La façon de voir les choses est intéressante et suis convaincu qu’on puisse voir de chouettes projets apparaître (comme la page Related Projects le montre). Cependant ils ont fait le choix de recommencer from-scratch et cassant toute compatibilité. Les serveurs Tent ne peuvent parler qu’avec des serveurs Tent. Les raisons avancées pour ne pas utiliser OStatus sont discutables : pas de messages prives, impossible de changer de serveur en gardant les relations, pas d’API standard pour l’interaction. Mais comme mentionné dans un commentaire, c’est plus drôle de partir de zéro.

Avec cette parabole Turbo+ 2.0, nous devrions enfin a comprendre leurs messages codés avec ce mystérieux « XMPP »

Vous vous souvenez de Diaspora ? Belle levée de fond, beaucoup d’espoirs, deux ans de développement pour finalement abandonner le projet a la communauté. Les créateurs décident de se concentrer sur leur sorte de générateur de meme (qui utilise ironiquement Facebook-connect, un bel aveu d’échec). Il semble avoir une bonne relève et il est possible que ce projet aboutisse a quelque chose mais Diaspora part avec une mauvaise base : un protocole interne quasi inexistant (qu’on pourrait presque qualifier de propriétaire). Diaspora avait été conçut sans trop savoir où aller puisque l’API n’était pas documentée et changeait tout le temps. Le projet Friendica a essayé d’être compatible avec celui ci mais a rencontre de nombreuses difficultés. Il semblerait que la communauté a prit conscience de ce problème puisqu’ils essayent d’être compatible avec d’autres réseaux. Personnellement, j’ai abandonné mais espoirs concernant Diaspora mais je peux changer d’avis, wait and see… ou pas.

Ces deux exemples ne sont pas les seuls, dans les plus connus on a aussi Movim (a base de XMPP, pas d’interopérabilité avec d’autres API type OStatus) ou SalutAToi (utilise une API basée sur XMPP documentée mais de leur cru quand même). Notons les bons élèves que sont Friendica et BuddyCloud puisqu’ils supportent plusieurs standards.

Pour revenir a Pump, Evan avait sans doute de bonnes raisons de changer la façon d’interagir entre serveurs, il s’y connaît en réseaux décentralisés et API. En raison de quelques problèmes avec StatusNet, il a préféré repartir sur une nouvelle base. Il annonçait quand même qu’un effort serait fait pour être compatible avec StatusNet. Cependant, l’API de base reste différente, toutes les fonctionnalités devront être adaptées pour faire la transition.

Pour se rendre compte du problème, imaginons maintenant que StatusNet ou Diaspora soient complètement abandonnés par les développeurs et ne soient plus maintenus. Les logiciels ont amassés une bonne base d’utilisateur mais ces utilisateurs vont lentement migrer vers des solutions plus modernes et maintenues. Sans l’émergence d’une solution supérieure, ils vont se diviser, se tournant peut être même vers une solution propriétaire. Cette migration se fera petit a petit, avec une base d’utilisateur ne voulant pas faire de migrer en raison de la communauté déjà présente sur son vieux réseau. Si ces logiciels ne sont plus maintenus, des Pump ou Friendica seront sans doute moins tentés de continuer a maintenir un niveau de compatibilité vers eux. Les nouvelles fonctionnalités ne seraient pas portées en OStatus. La communauté se retrouverait encore plus fragmentée. C’est évidement un scénario peu probable (déjà car OStatus n’est pas utilisé que par StatusNet) mais cela montre le problème des multiplications de standards : division de la communauté encore plus accentuée en cas d’abandon de projets.

Se mettre d’accord sur un protocole standard c’est une condition essentielle pour le succès des réseaux libres décentralisés. Sans cela, je ne pense pas que l’on pourra dominer les réseaux propriétaires centralisés ayant l’avantage de ne pas avoir a se soucier de ce problème. Je ne critique pas un standard en particulier (je ne me permettrais pas d’en désigner un supérieur aux autres), que ce soit OStatus, Pump, Tent, Diaspora ou un autre à base de XMPP, il faut se mettre d’accord sur une API commune et il faut arrêter d’en développer une nouvelle pour chaque logiciel. Toutes les API ne sont sans doute pas compatibles avec tous les cas de figure (sans parler de l’école HTTP vs XMPP) mais il y a sûrement moyen de dégrossir. Créer c’est bien, améliorer l’existant, c’est mieux.

CC-BY-NC XKCD

Google a annoncé un nouveau modèle de Chromebook : le Pixel. Une machine à 1300$ avec des specs assez misérables pour son prix : i5, 4GB de RAM, SSD de 32GB, USB2, poids et encombrement assez banal pour un 13″. Ah non il a un écran haute définition (je dirais bien pour regarder un Blu-ray dans le train mais y a pas de lecteur) et un écran tactile (woo, sé taktil !). Là où Google innove est avec son OS minimaliste (mais qui supporte les .zip depuis 2011!) et son accès au cloud. Lorsque l’on achète cette machine, l’on reçoit 1TB de stockage sur les serveurs de Google via Google Drive pendant 3 ans. Ainsi à n’importe quel moment, sur n’importe quelle machine, on peut accéder à ses fichiers en ligne. Plus de risques de crash de disques durs, Google se charge de tout ! La vie est belle dans le nuage. Excusez-moi, je pars vomir et je reviens.

*bruit de chasse d’eau*

Non ! La vie n’est pas belle. Le concept du Chromebook est une des pires idées que l’on puisse avoir et qui me fait vraiment peur si ça marche. Dans un article du journal Le Soir de samedi dernier, l’on présentait le modèle comme s’attaquant de front à Apple. Ils ne croient pas si bien dire puisque je ne vois ça comme passer d’un gaspillage d’argent (silence fan boy d’Apple, c’est dépassé de troller avec toi) à un autre sans doute pire.

Il y a un concept simple qu’on oublie de plus en plus aujourd’hui : la propriété. Si un bien m’appartient, j’en fais ce que je veux. De la voiture que l’on peut repeindre aux murs que l’on peut abattre en passant par le livre que je peux revendre, ça fonctionne pas trop mal. Notamment avec le cloud, l’informatique semble s’éloigner de ces concepts. Je loue un livre sur Amazon (puisqu’il en reste proprio et peut en faire ce qu’il veut), je loue ma musique à l’écoute sur Spotify (puisque je n’y aurai plus accès si j’arrête de payer ou si une major veut retirer son catalogue), je loue même ma vie sociale (puisque une fermeture de mon compte Facebook me réduirait à l’état d’ermite). Ça ne suffit pas ? Maintenant louez tout ! Vos emails, vos documents professionnels, vos photos de famille, votre carnet d’adresse, toute votre vie numérique ! Même supprimer un fichier ne dépendant plus de vous (le fichier reste sagement sur les serveurs de Google). Il s’agit ici d’une double location : vous payez le stockage en argent (après le 1TB pendant 3 ans, c’est 50$/mois pour la même capacité), avec votre vie privée (mais ça c’est pas neuf) et si ça ne suffit pas, vous êtes dépendant du fournisseur (Google) pour accéder à vos fichiers.

De par son mode de fonctionnement, il est évident qu’un accès internet est essentiel. Pas de connexion, pas de chocolat. Ils disent viser les power-users mais considérer que les professionnels ont un accès internet tout le temps est un peu optimiste (train ? déplacements ?). Même quand je reste à mon bureau au boulot à coté du routeur, il arrive que le net saute par temps de grands froids (et oui OpenERP a installé ses bureaux à la campagne). Si on avait tous des chromebooks, chômage technique ! Il y a bien un modèle avec puce 4G mais comptez 200$ de plus.

Il y a deux jours, la BBox de Jean-Kevin est tombée en panne

Bien sur l’accès internet va se faire d’en plus en plus présent, les forfaits illimités 4G ne devraient pas mettre trop longtemps à arriver, le problème d’accès n’est que temporaire. Seulement le problème fondamental reste : vous mettez tous vos œufs dans un même panier. Qu’on soit à la ferme, à la bourse ou en informatique, c’est une très mauvaise pratique, et d’autant plus si celui qui porte le panier est un américain (partiot act power) dont on ne sait pas grand chose et avec qui on ne pourra sûrement pas discuté en cas de pépin. Ploum avait fait un très bon article en imaginant un monde selon Google, c’est l’occasion de le (re)lire. Google deviendra il une nouvelle prison dorée ?

Même s’il n’est pas de bon ton de souhaiter du malheur, c’est pourtant ce que je souhaite à ce Chromebook, pour le bonheur de l’informatique en général. Je dirais bien qu’il n’y a de toute façon aucune chance pour que les gens prennent mais les précédents historiques tels que les succès de Facebook ou d’Apple me laisse songeur et craintif.

Si vous possédez un système archlinux chiffré avec LUKS/LVM (comme expliqué ici, tuto que je dois encore mettre à jour), vous avez sans doute eu une mauvaise surprise récemment. En effet, suite à une mise à jour du paquet LVM2 vers la version 2.02.98-3, LVM utilise lvmetad pour l’activation automatique. La mise à jour a été annoncée sur le blog d’Archlinux mais si vous avez loupé la nouvelle ou comme moi que vous avez Manjaro qui n’a pas prévenu (grmlml), vous avez du avoir une mauvaise surprise au dernier boot : plus rien qui fonctionne. Voici la marche à suivre pour réparer un système dont le boot est cassé :

Le système peut voler gaiement pendant des mois, au premier problème de boot, on fait moins le fier…

1. Démarrez sur un live cd. On va utiliser celui d’Achlinux ici mais ça devrait convenir avec d’autres. Faites les bidouilles habituelles comme changer la disposition de clavier (loadkeys be-latin1).

2. Déchiffrez et détectez les partitions nécessaires. Attention les noms et numéros peuvent changer, à adapter.

3. On monte les partitions nécessaires (encore une fois, noms à adapter).

4. On modifie le fichier /etc/lvm/lvm.conf (en utilisant éventuellement /etc/lvm/lvm.conf.pacnew) pour changer la ligne use_lvmetad à use_lvmetad = 1.

5. On régénère les fichiers de boot

En changeant linux par un autre si vous n’utilisez pas un preset de base (linux34 sous Manjaro par exemple).

Redémarrez et tout devrait être rentré dans l’ordre.

C’est lors de l’ouverture du FOSDEM de 2015 que Tristan Nitot a annoncé la décision d’utiliser Webkit comme moteur de rendu pour la version 37 de Firefox. Cette déclaration fut globalement très bien accueillie par la communauté. En effet depuis le passage l’an passé d’Internet Explorer à ce moteur de rendu, Mozilla faisait figure d’extraterrestre en étant un des seul à encore utiliser Gecko et non le traditionnel Webkit.

Dans un consortium réunissant entre autre Google, Apple, Opera et Microsoft, les meilleurs développeurs ont travaillé sans relâche sur Webkit pour lui ajouter les dernières fonctionnalités possibles. L’ajout du support de la balise html expérimentale <skype/> est d’ailleurs attendu dans la prochaine version avec beaucoup d’impatience.

Certains se souviennent encore du débat virulent du W3C lors de l’introduction de l’attribut CSS @webkit-import(facebook) qui permettait facilement de calquer le look de son site sur celui du célèbre réseau social. Ce vieux groupes de barbus de la première heure ne pouvait pas réaliser l’importance de ce type de fonctionnalités. On ne regrettera pas la dissolution de leur groupe de travail depuis longtemps inutile.

Jimmy Carter se recueillant devant la tombe du moteur de rendu inconnu

Avec ces nombreuses avancées, les logiciels dotés de webkit avaient une avance sans précédent. Même les smartphones d’entrée de gamme avec un misérable quad-core permettaient une partie en réseau fluide de The Elder Scroll VI (entièrement en HTML5) alors que Firefox n’implantait que la moitié des fonctionnalités requises.

Quelques libristes convaincus ont bien tenté l’expérience FirefoxOS mais la manque de compatibilité avec la plupart des sites web (passant pourtant le HTML5 Test de Google) rendait la navigation décourageante. Ce mauvais choix de technologie avait condamné le projet avant même une sortie de sa version stable.

Ça faisait longtemps que les web-développeurs en avaient assez de passer un temps considérable à adapter leurs designs. La décision de Mozilla était obligatoire si elle voulait avoir une chance de garder ses 5% de part de marcher. Qu’est-ce qu’il y a de mal à Webkit de toute façon ? Il est open source et très puissant, tout le monde s’accorde pour le dire. Enfin un seul moteur de rendu, un grand pas pour le développement web.

Cet article est une réaction à la triste décision d’Opera de passer de Presto à Webkit annoncée cette semaine.

Depuis quelques jours le documentaire TPB AFK: The Pirate Bay Away From Keyboard est disponible en téléchargement, streaming et pré-commande. Je viens de finir de le regarder et vous conseille de le faire également si ce n’est pas encore fait.

Le reportage suit Gottfrid Svartholm, Fredrik Neij et Peter Sunde, les fondateurs du célèbre site The Pirate Bay de 2008 à 2012, le long de leur procès fait par Hollywood et l’industrie musicale pour violation de copyright.

Le documentaire ne cherche pas à tirer au clair les faits liés au procès mais se contente de suivre les 3 geeks. Des points comme savoir si le site générait ou non d’énormes revenus (affirmé par Hollywood, démenti par le trio) n’est par exemple que légèrement abordé. On découvre plutôt le coté moins connu et pas toujours reluisant de l’organisation (ou de la non-organisation). Gottfrid se drogue, Fredrik est raciste et alcoolique et la solidarité entre les trois n’est pas des plus présentes (fuir sans donner de nouvelles quand ça tourne mal). Peter (le porte parole) est sans doute celui qui avance le plus les arguments idéologiques de libre accès à la culture et partage d’information tandis que les deux autres s’intéressent plus à l’aspect technique qu’autre chose.

On a également quelques moments assez délicieux comme Fredrik expliquant au juge avoir un filtre anti-spam redirigeant les emails contenant « DMCA » (dont les réponses sont connues) ou Gottfrid déclarant aux journalistes que la stratégie des procureurs est de mentir d’une façon tellement ennuyante qu’on s’endort et n’arrive plus à se défendre. Mon extrait préféré restant une déclaration de Peter en réponse à « quand vous êtes vous rencontré IRL pour la première fois ? »

We don’t like that expression.
We say AFK – Away From Keyboard.
We think that the internet is for real.

Le film est disponible en pré-commande sur tpbafk.tv, en streaming sur youtube ou en téléchargement BitTorrent sur TPB bien entendu.

Internet grouille déjà de traductions dont une française est par exemple disponible ici.

En conclusion un documentaire très intéressant que tout utilisateur du site devrait regarder.

Il y a quelques semaines, j’avais présenté SMailArchiver, mon script de backup d’email sécurisés en python. Aujourd’hui un petit article pour les nouveautés de la nouvelle version 0.4.

Concernant les fonctionnalités, SMailArchiver permet désormais le stockage en clair si l’argument -e ou --encrypt n’est pas utilisé. Chaque email est toujours stocké individuellement pour faciliter l’incrémental mais la commande de restauration devient -r ou --restore pour plus de cohérence (précédemment -d ou --decrypt dans la version 0.3). Celle-ci se chargera de créer un seul fichier. Le format du fichier de configuration json a également légèrement été modifié en conséquence.

L’extension pour le stockage gagne également en cohérence. Un fichier anciennement nommé 42.gz.mbox deviendra désormais 42.mbox.gz.enc, ce qui indique : un email au format mbox compressé puis chiffré. Un mail non compressé et/ou non chiffré n’aura pas l’extension .gz et/ou .enc. La restauration se base sur ces extensions pour les manipulations à réaliser.

Un peu de patience, tout le monde aura sa mise à jour

Pour ceux ayant réalisé leurs backup avec la version 0.3, un script de migration a été créé pour régler le problème de changement de format. Renseignez le dossier contenant les mails (placez éventuellement le fichier de configuration dedans) ainsi que la version depuis laquelle vous arrivez (0.3 dans ce cas). Le script se chargera de renommer les fichiers et modifier le fichier de config.

Le programme est désormais également accessible depuis github en plus de gitorious. En espérant que cela favorisera une éventuelle contribution (non ceci n’est pas du tout un appel caché).

Étant donné que je parle essentiellement de ce script sur un blog francophone, il me semblait normal de mettre les instructions en Français. Aux cotés du précédent README, se trouve maintenant un fichier LISEZMOI. Si des polyglottes me lisent, n’hésitez pas a me soumettre des traductions en Burgonde ou Klingon.

Last but not least, l’utilisation de la licence MIT. Jusqu’à présent il n’y avait pas de licence formelle ce qui était problématique pour l’utilisation du code dans d’autres programmes. Chose réglée, j’ai opté pour une licence permissive, je n’avais pas envie d’ennuyer avec les contraintes de la GPL pour un si petit bout de code, du code réutilisé est une reconnaissance en soit.