Au Joyeux Ragondin

Le dictionnaire Littré, édition 1863, en-ligne et téléchargeable pour utilisation locale, c'est trop d'la balle. Sa mère. Dans le même style, il y a Dictionnaires d'autrefois.

J'ai commencé ce blog après avoir découvert les agrégateurs de fil, attiré par la possibilité de pouvoir réunir en un même endroit de nombreuses sources. Après quelques années d'utilisation, j'ai pu remarquer quelques tendances. En particulier, dans certains des fils s'accumulent les billets non lus.

• Si le fil ne contient pas l'intégralité des billets, j'ai tendance à ne suivre les liens que lorsque le titre est vraiment accrocheur.
• Si le fil contient un long texte argumenté, j'ai tendance à le laisser "pour plus tard" et à favoriser les billets courts parlant d'actualité.
• De la même manière, je délaisse des blogs qui pourraient pourtant m'intéresser, comme Drawn! ou Longevity Meme News parce qu'ils contiennent un résumé peu intéressant, mais des liens qu'il faut approfondir. Dans le cas de Drawn!, il faut aller voir les liens des artistes (avec des interfaces en Flash dans 90 % des cas) et dans le cas de LMN, il faut lire les articles pour espérer comprendre quelque chose.

Les blogs sont-ils destinés uniquement à contenir des informations superficielles sur des sujets d'actualité ? On pourrait penser que le problème principal consiste à faire le tri parmis la masse d'information pour extraire les billets intéressants, mais que se passe-t-il lorsque le nombre de billets intéressants est trop élevé ? J'ai tendance à stocker pour lire plus tard, « quand j'aurai le temps » mais le classement chronologique des blogs est peu adapté à ce genre de choses.

Alors, quel avenir pour le blog ? Des sites permettent déjà de centraliser les fils, de les étiquetter et de les partager. À quand des sites communautaires chargés, en plus, d'effectuer une synthèse de ce qu'on appelle la blogosphère ? Si ces sites existent déjà, n'hésitez pas à m'en faire part.

Dans un article sur Wired, Bruce Schneier propose de rendre les éditeurs de logiciels responsables (légalement) des bugs dans leurs logiciels pour, dit-il, créer un encouragement à améliorer leur qualité. Slashdot s'interroge naturellement sur les conséquences d'une telle responsabilité sur les logiciels libres, qui sont en grande partie développés par des bénévoles.

Un constat tout simple : actuellement il y a un encouragement financier à laisser des bugs dans son logiciel, à deux niveaux ; premièrement, il faut tenir les délais de livraison du produit, et donc plus on essaye de corriger les bugs plus on prend de retard ; deuxièmement, s'il reste des bugs génants on aura peut-être une mauvaise réputation, mais on pourra aussi vendre des mises à jour. Ce constat fait, on peut se dire qu'en rendant les éditeurs responsables, on crée un encouragement à corriger les bugs qui pourrait inverser la tendance et améliorer la qualité globale des logiciels qui, au moins pour les logiciels grand public, est catastrophique.

Qu'est-ce qu'un bug ? À priori, ce mot désigne n'importe quel comportement du logiciel qui n'était pas prévu par ses développeurs. Une observation importante : il est extrêmement difficile, et souvent impossible, de prouver qu'un logiciel fait ce que l'on veut, ni plus, ni moins. D'autant plus lorsque l'interaction avec l'extérieur (par exemple Internet) rend les choses imprévisibles. Il faut donc au minimum distinguer quelques catégories de bugs :

• Les bugs idiots, qui auraient pu être évités facilement par un étudiant en première année. Par exemple, un buffer overflow à cause de l'utilisation de strcpy au lieu de strncpy. Typiquement, ce sont des bugs qui peuvent être détectés par des logiciels, ou résolus en utilisant des langages de plus haut niveau.
• Les bugs de protocole, qui font trop confiance. Quelque part au niveau de la communication entre deux trucs, un développeur a supposé que la communication était fiable, qu'aucun des trucs n'était piégé, ou d'une manière ou d'une autre a permis que quelqu'un de mal intentionné abuse. Ces bugs sont plus difficiles à résoudre, il n'y a pas toujours de règles simples, mais avec de la discipline on peut s'en sortir.
• Les bugs compliqués, par exemple un système multithread où, dans certains cas très rares, une interaction entre deux bouts de code a des conséquences inattendues qui, si elles sont utilisées par quelqu'un de mal intentionné, peuvent être désastreuses. C'est compliqué parce qu'il y a deux niveaux de bug : d'abord il faut se rendre compte qu'un truc imprévu peut se produire bien que cela n'arrive jamais dans les tests, et ensuite il faut se rendre compte que cela peut être exploité (par exemple). On peut encore s'en sortir, mais cela prend énormément de temps, et donc coûte très cher.
• Les bugs impossibles à résoudre. Il y a des cas où on ne peut pas garantir que le programme fait bien toujours ce que l'on veut. Dans ce genre de cas, la solution de sécurité consiste à limiter les fonctionnalités pour reprendre un peu de contrôle. Par exemple, un navigateur équippé d'une machine virtuelle Java pose des limites à ce que peuvent faire des applets Java, de sorte que si les limites sont bien posées, les applets ne peuvent rien faire de catastrophique. Mais est-ce toujours une solution possible ? On ne peut pas faire de preuve formelle de tous les programmes, alors comment garantir que son programme fonctionne lorsqu'on n'a pas cette preuve ?

Évidemment, si l'on rend les éditeurs responsables des bugs, il faut tracer une limite quelque part. Quand on trouve un bug idiot dans un logiciel vendu très cher, c'est qu'il y a un problème. Quand l'utilisation d'un langage un peu strict aurait évité un bug, on peut s'en prendre à celui qui a décidé des outils à utiliser ou aux développeurs peu rigoureux. Mais pour les cas où une preuve est hors de portée, que faire ? Et pour le cas où le coût de détection des erreurs est trop élevé ?

Schneier parle d'un encouragement à corriger les bugs, pas d'une punition. Ça se comprend assez bien dans le domaine des logiciels pour le grand public, mais quand des vies sont en jeu, je suppose que les choses se compliquent. Un exemple intéressant, toujours dans les logiciels « communs » : Don Knuth, développeur de TeX, offre aux découvreurs de bugs un chèque dont la valeur augmente au fil du temps. Au début, la récompense était d'un cent, et elle a été doublée régulièrement depuis 1985. Évidemment, quand on a un chèque de Knuth, on ne l'encaisse pas : on l'encadre. Est-ce que Schneier pensait à ce genre de choses ? Il pensait plus probablement à rembourser les acheteurs de logiciels défectueux. Deux solutions différentes pour deux modes de développement différents ?

Hier, j'ai essayé de faire une série d'étiquettes et de les imprimer sur du papier autocollant prédécoupé. Pour information, mon imprimante est une Epson en principe parfaitement supportée, et mes étiquettes sont dans un format standard. Je m'attendais donc à ce que tout fonctionne du premier coup. Le parcours suivi est plutôt amusant.

• Tout d'abord, j'ai commencé par utiliser glabels, qui est fait pour ça et qui, joie, incluait un modèle pour mes étiquettes. L'interface est relativement utilisable, et on peut exporter en Postscript ou PDF, bref, pas mal du tout. J'imprime, et ça ne colle pas du tout à mes étiquettes.
• J'ai décidé de passer à un logiciel un peu plus professionnel, Scribus, dont on m'avait dit grand bien. Là, forcément, c'est un peu plus compliqué, puisque ce n'est pas dédié à la fabrication d'étiquettes. L'interface est assez horrible, et les repères magnétiques fonctionnent suivant une logique qui me dépasse. Je n'ai pas trouvé de moyen de faire une étiquette et de la recopier 21 fois sur la page sans la dupliquer, pour que les modifications se fassent sur toutes en même temps. Finalement, je m'en sors, j'imprime, et ça ne colle toujours pas.
• Arrivé à ce stade, je commence à me douter que le problème vient d'ailleurs, peut-être entre la chaise et le clavier. Je fais un essai en traçant un rectangle de 1 cm sur 2 cm avec LaTeX, et une fois le PDF imprimé, on a perdu 1 mm tous les 2 cm. La résolution de l'imprimante et celle du PDF diffèrent.
• Ne trouvant pas comment résoudre le problème, dans le doute, j'essaye d'imprimer le DVI produit par LaTeX. Miracle, ça marche ! Finalement, j'ai donc fait mes étiquettes avec LaTeX et le package labels. J'aurais dû passer par là dès le début, mais j'avais peur de galérer pour la mise en page.

Deux impressions : (La)TeX, c'est bien, mais je le savais déjà ; ma grand mère aurait eu du mal à s'en sortir toute seule. Étant donné le nombre de gens qui ne savent pas résoudre ce genre de problème de résolution et qui n'ont pas envie d'apprendre un langage de traitement de texte non-WYSIWYG, je me dis que l'impression via les logiciels libres a encore quelques progrès à faire.

Tous ceux qui ont des statistiques pour leur site web s'amusent un jour ou l'autre à regarder par quelles recherches on arrive sur leur site. Le plus amusant étant bien sûr que la plupart des visiteurs qui arrivent par un moteur de recherche ont fait une recherche qui n'a rien à voir avec le contenu du site. En dehors d'un gain d'intérêt pour Aubrey de Grey, voici quelques points qui intéressent mes nombreux visiteurs :

• La durée de vie maximale d'un ragondin en captivité est de 12 ans, mais les rigueurs de l'hiver, des chiens de chasse et des coups de pelle diminuent grandement cette durée.
• L'explication des Chroniques de l'oiseau à ressort, c'est qu'il faut débrancher le téléphone avant de commencer à faire cuire des pâtes.
• « La théorie de l'évolution est douteuse. » Non, il faut la prendre comme une métaphore du fait que la Terre n'a pas été créée en un jour, mais en six ou sept.
• Pour lutter contre le vieillissement, il faut faire du sport mais pas trop, boire du café mais pas trop, boire du vin mais pas trop, manger des fruits mais pas trop de calories, et épargner de l'argent pour quand des pilules de jouvence seront vraiment disponibles.
• Des exemples de phénomènes improbables : la Lune qui se change en nain de jardin, les États-Unis qui entament un programme de désarmement, Sarkozy qui abandonne la politique.
• Pour montrer qu'une droite est un ensemble indénombrable, je suppose qu'on peut partir du fait qu'on peut étiqueter les points de la droite par les nombres réels. Ensuite, la démonstration que les nombres réels forment un ensemble indémontrable est classique et facile à trouver sur le net.
• Je n'ai pas encore trouvé de blog produit par une vie extraterrestre, mais un bon point de départ pour une recherche serait Skyblog, qui contient des textes à l'apparence aléatoire recelant peut-être un message.
• Enfin, pour le monsieur qui voudrait créer un compte sur Google mais ça ne marche pas, je suggère d'aller chez MSN, car Google est notre futur evil overlord.