-->[]

Le groupe Jack Lutz a sorti un album: The Promises One Makes.

Ça réchauffe, ça console... ou bien ça vous envoie au fond. Intéressant, en tout cas.

Dans un tout autre style, je ne peux passer sous silence le délicieux It Should Be Rejected, de 3374 Namur.

Ces deux groupes sympathiques ne seraient rien sans Palomar1 (voir la présentation de leur dernier album, Don't Betray Them). À ne pas louper également, Billings Gazette bien sûr, mais aussi Icehouse Pieces, The Criminal Code, A Successful Calamity, Toad Doctors, Metrotown, Palinode, Penny Arcade Adventures et bien d'autres...

Le principe :

1. http://en.wikipedia.org/wiki/Special:Random
Le premier article de la page est le nom de votre groupe.

2. http://www.quotationspage.com/random.php3
Les 4 derniers mots de la dernière citation sera le titre de votre album.

3. http://www.flickr.com/explore/interesting/7days/
La 3ème photo, quelle qu’elle soit, sera votre pochette d’album!

Prenez la photo, ajoutez-y votre nom de groupe et le titre de l’album… Vous avez maintenant votre pochette d’album.

Bon j'ai pas pu résister, un petit dernier (peut-être que d'autres suivront):

Je disparais bientôt en Roumanie pour quelques semaines, du coup il se pourrait que je ne blogue pas trop pendant ce temps, mais pas d'inquiétude.

Haha, elle est bonne hein ?

12 septembre. Barcelone. Chaleur, plage, soleil, short, 2 douches par jour.

18 septembre, Marbourg. Froid, bonnet, écharpe, 4 épaisseurs, nez qui coule, feuilles mortes.

Ça calme.

Il y a quelques semaines, Colin Didier, alias errtu, a annoncé qu'il s'était mis à plancher sur un plugin irssi pour Jabber, nommé irssi-xmpp. Comme je l'ai déjà mentionné il y a quelques mois, il existe aussi irssi-jabber qui fait la même chose, mais le développeur est content avec l'état actuel du plugin et n'est pas spécialement motivé pour avancer le développement, alors errtu a décidé de repartir à zéro.

Pour les gens qui connaissent pas irssi, c'est un programme de "tchat" en ligne de commande qui utilise de base le protocole IRC, mais qui peut utiliser d'autres protocoles par le biais d'extensions ou plugins.

Pour les gens qui connaissent pas Jabber, c'est un protocole de messagerie décentralisé, un peu comme les mails: depuis une adresse toto@hebergeur-truc.com on peut discuter avec tata@herbergeur-machin.net, donc personne ne peut avoir le monopole du réseau, et il ne peut pas y avoir de "panne générale". En ce qui concerne l'apparence du bouzin, il y a plusieurs logiciels Jabber, mais dans le cas le plus fréquent ça ressemble grosso-modo à ICQ, MSN Messenger, Yahoo Messenger et consorts: une liste d'ami·e·s, on voit s'illes sont là ou pas, et on peut chatter avec elleux, à deux ou en groupe.

Le problème avec Jabber c'est qu'il n'y avait pas de bon client en mode texte. Bon, et le problème avec irssi (qui est en mode texte, donc) c'est qu'il ne faisait pas de Jabber. Grâce à l'effort amorcé par errtu, paf, c'est bon. Du coup, je me suis dit que c'était la bonne occasion pour en faire un paquet Debian: ça fait longtemps que je voulais apprendre à faire ça, et par ailleurs ça permet de donner davantage de visibilité à irssi-xmpp. J'en ai donc fait un, avec l'aide de Lunar et de la documentation de Debian. Au début je l'ai mis sur un dépôt personnel, puis Lunar m'a proposé de l'envoyer dans l'archive Debian officielle, ce qui m'a permis de me familiariser avec le processus :

• Signaler un ITP (Intent To Package), c'est-à-dire prévenir que je comptais faire un paquet nommé irssi-plugin-xmpp (pour coller à la convention de nommage Debian).
• Premier moment d'émotion: dernières relectures et envoi (upload) du paquet source et du paquet compilé par la personne qui effectue l'envoi (Lunar, dans mon cas, donc compilé pour amd64, qui est l'architecture de sa machine) sur les serveurs Debian. Les paquets envoyés arrivent dans la NEW queue (file d'attente des nouveaux paquets). Ils doivent être validés par les responsables FTP, ce qui constitue un premier niveau de vérifications (compatibilité de la licence avec les critères de liberté de Debian, etc.). Le paquet est resté 6 jours dans la file, ben je peux vous dire que c'est long :)
• Deuxième moment d'émotion: le paquet a enfin été accepté hier. La suite est donc :
  • L'ITP a été automatiquement fermé.
  • Le paquet source et le paquet compilé pour amd64 se sont retrouvés publiquement accessibles dans la file d'entrée des paquets.
  • Des programmes automatiques de compilation (build daemons) se sont mis à construire le paquet pour les architectures manquantes: i386, mips, sparc, powerpc, etc..
• Quelques heures après, le paquet source et les paquets compilés pour chaque architecture ont été rendus disponibles sur le FTP principal de Debian pour la distribution "unstable", puis synchronisés sur les différents miroirs à travers le monde.

Le résultat concret, c'est qu'une personne utilisant Debian unstable peut maintenant installer le paquet irssi-plugin-xmpp via sa méthode d'installation préférée (apt-get, aptitude, synaptic, etc.).

Mon premier paquet Debian... c'est peut-être bête mais ça fait plaisir. Bon par contre c'est que le début, maintenant faut le maintenir, c'est-à-dire suivre les nouvelles versions et les packager aussi, tenir compte des signalements de bugs, etc.. Quant à irssi-xmpp, l'existence d'un paquet permettra à un peu plus de gens de l'utiliser facilement, et j'espère que ça permettra au programme de s'améliorer encore grâce aux suggestions, signalements de bugs, bouts de code, etc..

Il y a environ 3 ans, j'ai fait un "petit" programme nommé battground. Au début, c'était un petit script shell qui changeait la couleur du fond d'écran suivant l'état de charge de la batterie de mon laptop, le genre de petit script à la con bricolé en 1h dans un moment d'ennui.

Petit à petit j'ai commencé à lui rajouter des petites fonctionnalités, comme par exemple pouvoir configurer la variation des couleurs au fil de la charge, décharge, etc.. J'ai fini par me prendre complètement au jeu et à passer des journées entières dessus, d'ailleurs Marie s'en souvient sûrement encore très bien :) Au final, ce petit script est devenu un truc assez complet, complexe, et compliqué :

• Chaque état de charge a une couleur de base, comme ça on peut savoir d'après la couleur si la batterie est en train de se vider, remplir, si elle a fini de se charger, etc..
• Le pourcentage de batterie (donc entre 0 et 100) est transformé en un autre nombre, comme on veut, par des petites fonctions mathématiques simples, appelées filtres. Par exemple, "reverse" transforme 0 en 100, 100 en 0, 60 en 40, etc.. Autre exemple, "step" arrondit à la dizaine (ou à ce qu'on veut) et produit donc un effet d'échelon. Encore autre exemple, "threshold" transforme tout ce qui passe en-dessous (ou au-dessus) d'une certaine seuil en une valeur fixe, par exemple 0. Il est possible de combiner (composer, pour les matheuses/matheux) plusieurs fonctions ensemble, les unes à la suite des autres. Le nombre final sert à faire varier la teinte de la couleur de base, et idem pour la saturation. Comme chaque filtre est un fichier indépendant très simple, on peut aussi créer soi-même ses propres filtres si on se sent d'humeur matheuse.
• On peut faire des thèmes, qui sont donc la combinaison de couleurs de base et d'une série de filtres. Il y a des thèmes basiques prédéfinis, par exemple un qui met du vert pour la charge, rouge pour la décharge, bleu pour "chargé", et qui se fout du pourcentage de batterie. Un autre thème prêt à l'emploi passe progressivement de noir à blanc en passant par les verts pour la charge, et retourne de blanc à noir mais cette fois en passant par les rouges pour la décharge. C'est très facile de faire ses propres thèmes, du coup c'est un peu comme choisir des assortiments de couleurs de fond d'écran, sauf que ça "bouge".
• Autre détail, on peut choisir le critère de mise à jour de l'information: une seule fois au lancement du programme, à chaque événement ACPI, toutes les 5 minutes, etc.. Les critères disponibles devraient suffire, mais on peut écrire ses propres critères de mise à jour. Je sais pas moi, à chaque réception de mail par exemple :)
• On peut télécommander le programme en le forçant à mettre à jour les couleurs manuellement, en lui faisant relire ses fichiers de configuration, etc..
• À la demande de Lunar qui avait à l'époque un Mac, ça marche aussi sur les Macs, qui n'utilisent pas ACPI pour la gestion de la batterie mais PMU.

Bref, en quelques semaines, le petit script était devenu un machin assez gros. Le seul truc qui n'a jamais changé, c'est que... c'est resté écrit en shell ! C'est bien séparé en plusieurs fichiers et tout, mais le tout combiné, c'est environ 1000 lignes de code.

Aujourd'hui, dans l'idée de faire un paquet Debian, j'ai remis le nez dedans, corrigé quelques trucs, ajouté une gestion du cas "batterie absente", etc.. Mais quand même... il faudrait vraiment refaire ce programme dans un autre langage, par exemple en C, en haskell, en python, ou n'importe quoi mais pas en shell par pitié, parce que là c'est vraiment devenu trop gros. N'empêche, c'était marrant à faire... Je vais peut-être me remettre à l'utiliser, tiens.

Bon là je suis un peu mort de rire mais je vais quand même mettre le lien ici.

Alors maintenant faut que vous sachiez, la nouvelle feature de Google Images, c'est Google Image Labeller. C'est vraiment trop bien, vous avez le droit de mettre des mots-clés sur les images. Gratuitement, oui ! Sans avoir besoin de vous loguer sur votre compte Google, oui vous avez bien entendu ! Et vous gagnez des points. Des points qui servent à quoi ? Mais à rien, rhooo, c'est pas fini de poser des questions bizarres ? Y'a même une espèce de truc d'émulation mutuelle, on est en paire avec quelqu'un et c'est celui qui tague le plus vite qui a gagné.

Et oui, c'est nouveau, c'est gonflé, mais le pire c'est que ça va peut-être quand même marcher, on sait pas. Google ils sont vraiment balaises. D'ailleurs rigolez pas... matez un peu les All-time Top Contributors, y'a des scores de ouf, alors que le truc a quelques heures.

Non mais j'hallucine, sont vraiment mortels chez Google, hein. Comme dit Nico, je les imagine très bien : "On fait quoi... on le fait, on le fait pas ? Ça va passer tu crois ? Bon allez on le fait."

Vous saviez, vous (oui, vous), que Jabber gère les messages "normaux" ? Mais oui, non, pas le tchat à la MSN et ICQ, mais les trucs avec un sujet et tout. Oui, voilà, comme les mails. Ah vous saviez pas ? Pas d'inquiétude, c'est normal, c'est parce que la plupart des clients Jabber le gèrent pas vraiment super bien. La plupart sont, grosso-modo, des clones d'ICQ, qui considèrent les messages normaux comme un mal nécessaire, sans chercher beaucoup plus loin. Oui, comme les messages de type headline, exactement. En même temps, faut avouer, on ne leur jette pas la pierre, Pierre. C'est des clients chat, c'est pas vraiment leur boulot. Oui d'accord, mais alors on fait comment ? C'est le boulot de qui ?

Je dirais... celui des logiciels comme Thunderbird. Bah oui, ce dernier gère déjà très bien les news, ce qui est logique vu que c'est un peu la même structure que les mails, bien que ce soit un protocole distinct. Alors du coup, ça paraîtrait logique d'avoir une jolie gestion des messages normaux Jabber. Pis avec un minimum d'imagination, du coup, ça permettrait une jolie intégration, un peu comme ce qui est fait dans l'interface de GMail. En vrac:

• si on y est autorisé bien sûr, connaître l'état de présence de l'expéditeur d'un mail (le JID peut être indiqué via le header SMTP Jabber-ID) ;
• enclencher une discussion "chat" suite à un mail ;
• répondre via un message Jabber normal à un mail, ou réciproquement ;
• voir la "carte de visite" de l'expéditeur d'un mail ;
• on peut même imaginer faire une intégration tripartite avec les news, vu que l'intégration mail/news est déjà là.

Du coup, j'ai commencé à en parler par là...

Ce soir je faisais une petite recherche pour voir si des gens avaient déjà parlé de faire un plugin irssi pour Telepathy. Ben oui, ça serait malin... On pourrait même carrément modifier irssi pour qu'il implémente Telepathy en natif : vu que Telepathy gère potentiellement tous les protocoles de façon modulaire via l'utilisation de Connection Managers, y'aurait même plus besoin de certains plugins (plugin ICQ, plugin Jabber, plugin SILC, ...).

Sauf qu'en fait j'ai pas eu le temps de chercher bien longtemps, parce que je suis tombé sur un truc qui m'a fait dresser l'oreille: Icecap, qui est censé être un protocole de messagerie instantanée. Tiens, connaissais pas, marrant. C'est pas pour dire que je suis assez renseigné sur ce qui touche à ce domaine, mais quand même, si un peu. En fait il s'avère que c'est ce qui s'appelait jusqu'à il y a pas si longtemps irssi2. Ah bah ok, en fait je connaissais du coup (haha), c'est un "repensage" de irssi et IRC par Timo Sirainen, l'auteur d'irssi et du serveur de mail Dovecot. Les pages du wiki sont assez intéressantes, même si les notions de protocole et logiciel sont parfois utilisées et différenciées de manière bizarre.

Par la suite, de Icecap en PSYC, je suis tombé sur une "analyse" un tout petit peu acide de Jabber par une personne nommée lynX. Et là, faut bien le dire, Jabber (et, entre les lignes, d'autres gens autour) en prend vraiment, mais alors, plein la gueule. Pis faut bien avouer... tout n'est pas faux, bien que lynX ait visiblement l'habitude de faire dans le sensationnalisme et les paroles mal ou pas pesées, à tel point qu'il y a un disclaimer sur sa page utilisateur. Boah, allez, c'est bien les coups de fouet, pis ça fait circuler le sang :)

Bon, depuis quelques jours ou semaines (ou quelque chose comme ça), j'ai une espèce d'idée de projet un peu bizarre. En même temps, j'ai souvent des idées de projets un peu bizarres, je crois, que je mets pas toujours en pratique, enfin parfois si mais pas toujours. Alors du coup je me dis que j'aurais qu'à l'écrire ici, comme ça si jamais ça tombe dans un trou de mon cerveau et que je le fais pas, au moins ça fait une trace.

L'idée c'est qu'il y a peu de clients MUC corrects, genre aussi aboutis que les clients IRC, par exemple. Pis aussi, les gens ils ont l'habitude de leur client IRC, par exemple irssi, mIRC, etc.. Du coup, je me dis que ça serait marrant d'avoir un serveur IRC qui se baserait en arrière-plan sur un serveur MUC. Une autre manière de le dire c'est que ce serait un client MUC contrôlable via le protocole IRC. Par exemple tu te connectes au serveur IRC en question, tu fais un /list, et pouf tu as la liste des chans du serveur MUC. L'instant d'après, tu rentres sur un des chans du serveur IRC, et paf, en vrai tu es sur un salon MUC. Comme tout client Jabber qui se respecte, le serveur IRC utiliserait son propre JID, et se connecterait au réseau Jabber avec une ressource distincte pour chaque client IRC.

Voilà en gros l'idée, donc au final c'est un peu le symétrique de la passerelle IRC telle que celle présente dans ejabberd.

Après ça pose quelques problèmes "conceptuels", du coup faut que je réfléchisse encore. Par exemple, sur IRC, la notion de nick est générale sur tout le serveur, alors que sur Jabber on peut prendre un nick différent pour chaque chan. C'est un problème un peu chiant, hein, faut bien l'avouer. Une solution de contournement serait de présenter, comme nick IRC, non pas le nick sur le MUC (après tout, c'est un parallèle possible, mais ce n'est pas le seul), mais le JID complet, genre nomdusalon@serveur/nick, ou encore le JID réel de la personne si le MUC l'expose. Du coup ça permettrait de "désambigüiser" le nick, mais par contre c'est moins joli, et le problème aussi c'est que les RFC relatives à IRC n'autorisent pas le @ et le / dans les nicks. Après, c'est pas comme si le respect des RFC était l'aspect le plus marquant du monde IRC, donc faut voir si l'impact réel serait si problématique. Une autre idée serait tout bêtement de n'autoriser qu'un seul chan par connexion, mais par contre d'autoriser plein de connexions pour chaque client, pour se faire pardonner. Ça résoudrait en partie le problème, vu que le nick serait bien sûr différent pour chaque connexion. Par contre ça empêcherait de choisir le même nick pour plusieurs chans, donc au final c'est le problème contraire, du coup c'est pas super malin mon garçon, mais merci d'avoir essayé.

Enfin voilà, y'a évidemment d'autres problèmes, telle que les caractères autorisés ici et là, à commencer par les nicks IRC qui sont trouze-mille fois plus restrictifs que sur Jabber (toi aussi tu aimes ton espace dans ton nick IRC). Après, y'a moyen de faire un mapping entre le nick Jabber et un pseudo-nick IRC forgé en remplaçant les espaces par des underscores, les lettres accentuées sans l'accent, etc. (en gérant bien sûr l'unicité, quitte à rajouter un underscore à la fin si le nick est déjà pris), et de présenter aux gens côté IRC juste le pseudo-nick (idem pour les noms de chans zarb), m'enfin c'est moins drôle, quoi. Les problèmes de charset seraient aussi pas très marrants à gérer, vu que le protocole IRC ne spécifie juste pas de charset (la RFC dit, presque texto, "y'a pas de charset ici, on envoie 8 bits et ça fait 1 octet, faites pas chier avec vos conneries, déjà c'est compatible avec vos terminaux ASCII alors vous plaignez pas.").

Pour le langage, en python ça peut être pas mal, et en plus il existe un mini serveur IRC nommé miniircd, donc ça fait déjà une super bonne base pour démarrer.

Bref au final ça peut être un projet rigolo, avec des fonctionnalités bien sûr limitées en tant que serveur IRC, et clairement aussi en tant que client MUC (mais bon ça c'est normal, si on choisit d'utiliser un client IRC on s'attend pas à avoir toutes les power-features des MUC Jabber), m'enfin ça permettrait déjà de dire « hé, toi, viens sur mon chan #truc, il est sur le serveur IRC "blablabla"», et paf la personne vient et capte même pas que c'est du Jabber, haha, ouah l'autre, trop bête, mouarf, lol. Ahem. Bref. Ça a l'air bien, nan ?

Je réfléchis depuis quelques mois sur un projet nommé DIAS, dont l'objectif est de fournir un mécanisme d'authentification sur internet un tant soit peu global, tout en restant complètement décentralisé et indépendant.

La constatation initiale est que, sur internet, la gestion des comptes utilisateurs est gérée de façon assez "préhistorique". Le meilleur exemple, ce sont les sites web, et plus particulièrement les forums: la plupart du temps, lorsque l'on veut poster un message sur un forum, il faut se créer un compte utilisateur en remplissant un formulaire à rallonge avec toujours les mêmes infos: nom, prénom, adresse mail, blablabla, et surtout à la fin, pouf, création d'un nouveau compte utilisateur, et hop un mot de passe associé. Bien sûr, on choisit généralement toujours le même nom d'utilisateur (et très souvent le même mot de passe), mais c'est pas grave, il faut recommencer à chaque fois. Je parle des forums parce que c'est le plus fréquent, mais c'est valable pour d'autres formes de sites web, et même pour d'autres formes de communication par internet (IMAP, news, ssh, etc.).

Au final :

• C'est chiant pour l'utilisateurice, qui doit s'inscrire ou se faire inscrire partout, se souvenir de là où ille est inscrit·e, là où ille ne l'est pas, mémoriser l'identifiant, le mot de passe, etc.. D'accord, dans le cas des sites web, les navigateurs modernes offrent une manière de mémoriser ces informations, mais ce n'est qu'une manière de contourner le problème initial.
• C'est chiant pour les "serveurs" (site web, etc.), qui doivent à chaque fois réinventer un moyen de stocker les comptes utilisateurs, offrir un mécanisme de création de compte, confirmation, procédure en cas d'oubli du mot de passe, sans parler de la gestion des comptes abandonnés...
• À l'échelle d'internet, c'est complètement crétin. On a beau avoir beaucoup avancé sur des tas de choses, personne ne semble se soucier de ce point, bien qu'il concerne directement la "vie quotidienne" des gens. Ça en est devenu ridicule.

Il y a déjà eu des initiatives pour prendre en main ce problème, l'une des plus connues étant "Microsoft Passport". Je ne connais pas les détails, mais pour ce que j'en ai compris, les gens ont un identifiant "passport" unique qu'ils peuvent donner sur les sites qui participent à l'initiative. Cet identifiant et le mot de passe associé sont stockés de manière centrale chez Microsoft, à qui les sites utilisant se système vont donc déléguer l'authentification. Ce système, bien que semblant résoudre le problème, pose bien sûr un gros problème d'indépendance, de sécurité, et de pérennité: qu'est-ce qui se passe si du jour au lendemain Microsoft rend ce service indisponible, payant, si la base de données est piratée ? Je passe sur la possibilité de faire par exemple des statistiques de qui va sur tel site, combien de fois par semaine, et les possibilités d'abus que ça ouvre (revente de l'information à des tiers par exemple). Je parle ici de Microsoft Passport à titre d'exemple, mais bien sûr le problème est le même pour tout système similaire présupposant un "fournisseur d'identité" central. À ma connaissance, aucun de ces systèmes n'a vraiment accroché, et on comprend pourquoi.

Bon, donc OK, on tient le problème, mais cette approche-là est mauvaise. Du coup, j'ai essayé de réfléchir à un système qui offrirait le même type d'avantage, c'est-à-dire la possibilité in fine d'apparaître sous un identifiant unique, mais qui ne poserait pas le problème de la centralisation en termes de qui maîtrise cette information. Et bien sûr, ça fait penser à quoi, forcément ? Ben oui, les adresses Jabber (JID): tout comme les adresses mail, un JID est formé d'un identifiant et d'un nom de serveur, séparés par un "@". Ce schéma permet d'avoir des adresses globalement uniques, tout en permettant que le stockage des adresses soit complètement décentralisé: chaque serveur Jabber est responsable de son ensemble d'adresses.

Reste le problème crucial: au moment de s'authentifier sur un site web (je dis site web tout le temps, mais c'est pas forcément que ça, hein), il faut donc prouver que l'on possède le JID truc@serveur.com. Facile, me direz-vous, suffit de donner le mot de passe. Ah ben oui mais non. Hors de question de filer son mot de passe Jabber à tout site qui le demande, bonjour la confidentialité. Paf, l'éternel problème: prouver que l'on possède une information, sans pour autant la donner explicitement.

Une solution, un peu chiante, mais qui marche, est de passer par un système intermédiaire de tickets: je fais une demande de ticket à un "fournisseur de tickets" (on n'aurait qu'à l'appeler "agent", c'est plus court), en lequel le site web a confiance, et ceci je le fais via Jabber, par mon adresse truc@serveur.com. En échange, l'agent me répond par un numéro de ticket unique, que je n'ai qu'à montrer fièrement au site web, comme une sorte de "certificat" qui prouve que truc@serveur.com c'est moi. Et pouf c'est tout.

En vrai c'est pas tout, mais c'est déjà un peu long, alors du coup tout est expliqué en détail sur le site de DIAS (c'est en anglais).

Après quelques mois où j'ai été assez "occupé" (haha), cette semaine j'ai eu un peu plus de temps, alors je me suis enfin décidé à parler de ce projet sur la mailing-list jdev. Le truc rigolo est que quelqu'un (Richard Dobson) a fait quelque chose de presque exactement équivalent. C'est moins détaillé, mais ça a le mérite d'être déjà écrit sous forme de XEP. Du coup, on va probablement bosser ensemble pour enrichir cette XEP avec certaines idées présentes dans DIAS.

Il existe aussi un autre système très intéressant, nommé OpenID, qui tente également de résoudre le même problème, et qui l'aborde sous un angle différent. Je n'ai toujours pas bien compris comment ça marche (mais je me soigne), ni tous les points forts/faibles, donc pas de comparatif ici.

Dans les idées que les autres gens ont eues, il y en a une qui s'appelle "Verifying HTTP requests via XMPP" (vérification de requêtes HTTP via XMPP), et son petit nom c'est XEP-0070. Contrairement à DIAS, qui fait une vérification a priori de l'identité, ce système fait une confirmation, c'est-à-dire une vérification a posteriori. Dans l'état actuel des choses il est fortement corrélé à HTTP, mais l'idée a été émise (et aimée) de changer ça.

Enfin voilà, à suivre donc. Je crois que j'ai bien envie de bosser avec Richard Robson sur l'amélioration de la XEP-0101 (Jabber tickets), et en parallèle de mieux comprendre OpenID.

Voici une suite de messages que j'ai reçus par messagerie instantanée (je n'étais pas devant mon écran à ce moment-là) il y a quelques jours, d'une amie qui utilise Windows et Word. Je ne peux pas m'empêcher d'en coller une partie ici, car c'est le cas concret typique du problème posé par l'utilisation de formats de fichiers fermés, et de logiciels (et systèmes d'exploitation) propriétaires.

allo?
bon tu ne dis plus etre devant ton ordi..alors je t'explique rapidos le pb
j'ai un windows vista
et pas de pack office
dc impossible de lire mes aciens docs..;vois la galère
et j'aiperais éviter d'acheter un pack office a 160 euros
j'aimerais savoir quelles possibilités s'offrent a moi, a part le bracage de logiciel en magasin...je suis sure que je me ferais prendre!!
donc puis-je installer un pack office 200 piraté sans faire beugguer mon vista
ou encore dois-je télécharger a l'eesai (3 mois), les derniers pack office sortis...
enfin bref, HELP ME, je n'y comprends rien, et j'aimerais garder mon ordi en état de marche le plus longtemps possible, sans aire une mauvaise manip qui me le bousillerais au bout de 8 jours...

Dans la pratique... À court terme, je dirais... ne pas passer à Windows Vista, car effectivement de nombreux logiciels ne sont pas compatibles avec ceux de Windows XP. M'enfin ça, c'est à court terme... avec le temps ça ne sera pas très viable, hein.

On voit clairement un gros problème des logiciels propriétaires : tu veux passer à la version suivante du système d'exploitation (Windows Vista) ? Tu n'as pas le choix, tu dois aussi passer à la version suivante du logiciel XXX (par exemple, Word). En payant, éventuellement.

Si tu ne veux pas payer, la conséquence est, en cascade :

1. Tu ne peux pas utiliser la nouvelle version de Word, et donc tu ne peux pas utiliser Word, tout court, car l'ancienne version n'est pas compatible avec ton nouveau Windows.
2. DONC, tu ne peux pas lire tes anciens documents, car pas de chance, ils ont besoin de l'ancien Word pour être utilisables. Comme le format de document est gardé secret, tu te retrouves enfermé-e à l'extérieur de tes propres fichiers, sans rien pouvoir en faire. Un peu comme si la clé de tes albums photos était soudée au mur de ta maison, ou qu'il fallait la demander au magasin de photo en bas de la rue chaque fois que tu veux les regarder : impossible de déménager, fallait y penser avant ! Si tu veux vraiment déménager tout en ayant le droit de continuer à regarder tes photos, il faut transférer ton dossier au magasin de photos en bas de ta nouvelle maison. C'est cher, et surtout... ça te posera le même problème au coup d'après.

Du coup, sur le plus long terme, la bonne idée est :

1. Tant que c'est encore possible, ouvrir TOUS (oui, hein, c'est chiant) ses fichiers avec un programme capable de lire les fichiers Word. Ça veut dire, donc, seulement Word (et seulement la bonne version !), ou encore OpenOffice (qui théoriquement ne devrait pas savoir comment ouvrir les fichiers Word (format fermé), mais avec beaucoup de travail les développeurs y sont à peu près arrivés).
2. Les enregistrer, tous, dans un format de fichier PAS propriétaire. Avec Word, il y a seulement le format RTF, mais c'est un peu "spartiate", on perd pas mal de mise en forme, etc.. Sinon, il y a aussi le format Open Document, et c'est quand même le meilleur choix. Pour pouvoir enregistrer dans ce format, il faut soit le faire avec OpenOffice, soit installer le plugin OpenDocument pour Word.
3. À l'avenir, arrêter d'utiliser Word (et surtout le format Word) si on veut pouvoir faire quelque chose de ses fichiers dans X jours, mois, années... À la place, le format Open Document est tout indiqué, car il est libre, et du coup ne peut pas être "pris en otage" par une boîte ou par quelqu'un. Sous Windows, le logiciel Open Office marche très bien. Quand on envoie un fichier à quelqu'un, il faut que cette personne ait OpenOffice d'installé (ou au pire, le plugin OpenDocument pour Word). De plus en plus de monde a OpenOffice installé sur son ordinateur ; si ce n'est pas le cas, un petit lien vers ce billet peut peut-être les aider à en comprendre l'intérêt... :)
4. De manière plus générale, arrêter d'utiliser un système d'exploitation traître. Ubuntu Linux marche très bien, est très agréable à utiliser, et pas besoin d'être un expert en informatique pour s'en servir.

Ce billet n'est pas là pour faire de la publicité à OpenOffice, à Ubuntu, ou que sais-je, ni pour embêter Microsoft. Personnellement j'ai déjà fait mes choix, ça me suffit, et d'habitude je regarde le spectable de l'extérieur, avec éventuellement un sourire amusé. Mais là, ça me flingue de voir des ami-e-s se faire avoir dans une arnaque pareille.

Ouah... je suis fasciné par la liste Swadesh du créole martiniquais. Du coup, je suis comme un con devant mon écran à lire les mots en créole, c'est trop bien...

C'est très instructif d'ailleurs, je viens de capter que le nom du groupe de musique Malavoi a probablement un rapport avec "bay lavwa" qui signifie "chanter" (ça vient certainement de "baye la voix", avec le verbe bayer qui signifie "rester la bouche grande ouverte" (comme dans "bayer aux corneilles")). J'aime beaucoup, aussi, "piébwa" qui veut dire "bois" (probablement dérivé de "pied de bois"), et "lapo piébwa" pour l'écorce, et "tibren" ("un peu", dérivé de "petit brin" j'imagine)... Bon y'en a plein, ok :) Ah oui, j'ai aussi un faible pour "timanmay" pour désigner les enfants ; d'ailleurs quand j'étais petit on nous appelait "la marmaille", mais d'un coup je me demande si c'est à cause des influences créoles dans ma famille ou si c'est un mot commun en français...

Oh, c'est rigolo, il y a pratiquement un an, jour pour jour, j'ai déjà passé une nuit blanche sur le même canapé, devant le même écran d'ordinateur, mais lisant et écrivant dans un autre langage.

Barcelone est une ville où c'est généralement une excellente idée de jeter souvent un oeil au contenu des grosses poubelles qui sont dans la rue. Il y a quelques jours, j'ai trouvé un ordinateur portable avec sa mallette, sa souris sans fil, et son chargeur. Bon, l'écran est pété, mais il y a une sortie d'écran externe et sinon il est en parfait état de fonctionnement. Quelques jours avant, j'ai trouvé un switch. Dans la même poubelle, un transmetteur audio/vidéo sans fil (genre ton lecteur DVD est au rez-de-chaussée et tu veux regarder un film dans ton lit au premier étage). Ne parlons pas des vêtements, sèche-cheveux, meubles, outils, casque audio sans-fil...

(la réaction en lisant ce billet, pour certaines personnes, pourra être "beurk, fouiller dans les poubelles, mais quelle honte". Pour d'autres, la réaction sera probablement : "bah évidemment que les poubelles regorgent de trésors, t'apprends la vie ou quoi ?"... Comme ce sont 2 types de réaction complètement inverses l'une de l'autre, je me dis que ça a sûrement du sens d'en parler quand même...)

Bon bah j'ai une maison (à Barcelone). Ça fait une semaine aujourd'hui... pourvu que ça dure :)

Oui je sais c'est un peu télégraphique comme post, mais c'est fou comme ça prend du temps ces petites bêtes. Allez, zou.

Normalement, quand tu es en train de faire le marché à Sighetu-Marmatiei, en Roumanie, tout près de la frontière Ukrainienne, en plein milieu du Maramures, tu t'attends pas à croiser sur ton chemin une voiture Unix (et sa plaque d'immatriculation).

(oui c'était en août, je lag un peu...)