David Madore's WebLog: 2011-09

J'ai perdu ma carte bancaire (bleue/VISA/Cléo). Enfin, perdue : je sais très bien ce qui s'est passé, j'ai dû l'oublier dans le terminal de paiement au supermarché hier soir ; évidemment, j'ai fait opposition, mais en attendant je n'en ai plus, et je me rends compte à présent à quel point je suis totalement accro à ce petit bout de plastique. (Comme d'habitude, aussi, les choses tombent au pire moment possible.)

La nouvelle carte sera probablement livrée dans mon agence bancaire, qui est à Orsay, ça ne m'arrange pas du tout : bizarrement, ma banque (il s'agit du Crédit Lyonnais de LCL) ne semble pas permettre qu'on fasse livrer la carte dans une agence quelconque de leur réseau (alors que pour un chéquier, c'est possible). L'occasion pour mon poussinet de se moquer de moi sur le ton de ah, je n'arrête pas de te dire que tu aurais dû faire transférer ton compte dans une agence à Paris. Je vais voir si c'est possible de faire ça juste à temps pour que la carte arrive là, mais j'ai des doutes.

Il faut dire que le concept de l'agence qui tient le compte ressemble à un archaïsme complètement con : ce n'est pas comme s'il y avait un petit casier à Orsay avec des billets de banque dedans qui sont à moi. La banque fait de la pub pour une « agence en ligne » (e-LCL), mais je trouve que ce n'est que souligner la connerie du truc : si leur but est que les gens fassent un maximum de choses en ligne, pourquoi ils ne rendent pas ça possible pour tous les clients de toutes leurs agences ? Pourquoi passer à l'agence électronique est-il un choix à faire plutôt qu'un ensemble de services offerts à tous leurs clients ? (Et en l'occurrence, comme je ne trouve pas de description de la façon dont on reçoit les cartes bancaires quand on est chez cette agence virtuelle, donc je ne sais pas si c'est intéressant.)

On me signale cette esquisse d'une démonstration (dont la version complète formerait un gros bouquin), par Edward Nelson (qui est pourtant un matheux relativement renommé, pas un fou dans sa cave), du fait que les mathématiques usuelles, et en fait déjà l'arithmétique de Peano, serait contradictoire.

L'idée serait une sorte de variante du paradoxe bien connu de l'« examen surprise » :

Un prof annonce à ses élèves qu'ils auront un examen au cours de la semaine qui vient (lundi à vendredi) et qu'ils ne pourront pas savoir avant le jour même quel sera le jour de l'examen ; les élèves raisonnent alors que l'examen ne peut pas être le vendredi puisque sinon le jeudi soir ils sauraient que ce ne peut être que le lendemain, et du coup le vendredi est exclu donc l'examen ne peut avoir lieu que du lundi au jeudi, mais les élèves peuvent alors répéter le même raisonnement pour exclure le jeudi, et ainsi de suite, et du coup l'examen ne peut pas avoir lieu du tout ; pourtant, lorsque le mercredi l'examen a lieu, il est effectivement une surprise.

On peut gloser cent mille ans sur ce paradoxe, je ne vais pas le faire parce que ça m'énerve particulièrement (voyez l'article Wikipédia à ce sujet), mais la résolution n'est pas particulièrement compliquée : si on appelle T₀ l'axiome il y aura un examen cette semaine et T_i+1 l'axiome (T₀ et) on ne peut pas conclure sur la base de T_i quel jour l'examen aura lieu avant qu'il ait lieu, alors T₁ implique que l'examen n'a pas lieu vendredi, T₂ implique qu'il n'a pas lieu jeudi non plus, T₄ implique que l'examen a forcément lieu le lundi, et T₅ est contradictoire. Si l'examen a lieu le mercredi, c'est que T₃ était faux, voilà tout : si on interprète l'énoncé du prof comme T_∞ défini comme (T₀ et) on ne peut pas conclure sur la base de T_∞ quel jour l'examen aura lieu avant qu'il ait lieu, c'est contradictoire et faux, ce qui n'empêche que T₂ peut être vrai, ce qui présente déjà un certain élément de surprise. Bref, je trouve que ce paradoxe n'est pas spécialement intéressant. Mais je veux surtout faire remarquer que ce paradoxe appelle naturellement à faire appel à différentes théories, de plus en plus complexes, dans lesquelles on sait (ou on peut conclure) des choses.

L'erreur technique de Nelson (parce que comme Randall Munroe je n'ai pas le moindre doute qu'il y en ait une, et je ferais bien de prendre son conseil et d'ouvrir les paris au lieu d'essaier d'expliquer les choses) est facile à trouver : même si je n'ai pas envie d'essayer de comprendre exactement ce qu'il prend comme théories faibles de l'arithmétique, il est clair que le ℓ qu'il considère en haut de la page 4 (de l'esquisse signalée au début de cette entrée) dépend de la complexité (de Kolmogorov) de la théorie T. Or page 5 il considère des preuves qui increase in rank and level (de nouveau, je n'ai pas envie de savoir exactement ce qu'il entend par là), donc dans des théories T dont la complexité varie, alors qu'il prétend garder ℓ fixe. Perdu.

Du moins c'était ma réaction immédiate en lisant son esquisse, et comme je vois ici que Terence Tao est arrivé à la même conclusion, je suis raisonnablement confiant que c'est bien là le problème (au moins dans la façon dont Nelson explique les choses). Les mathématiques sont sauves (et nous avec) !

Mais même si j'ai envie d'ironiser en disant que c'est un peu inquiétant qu'un membre de la National Academy of Science puisse prétendre des choses aussi sottes, il y a un certain intérêt à essayer de comprendre ce que croit en fait Nelson, parce que ce n'est pas idiot (même si quand il pense que l'arithmétique de Peano est contradictoire, je suis totalement et complètement convaincu qu'il se trompe), et c'est une question qui est revenue à diverses reprises sur ce blog. Il ne prétend pas que les mathématiques réellement pratiquées sont contradictoires (et encore moins que 0=1), seulement que tous les systèmes dans lesquels on les fait habituellement sont contradictoires, parce que le principe de récurrence est faux et contradictoire. (Et il pense pouvoir reformuler beaucoup de résultats mathématiques dans un système plus faible qui lui convient, ce qui est en soi intéressant, par exemple du point de vue des mathématiques à rebours, même si on ne croit pas une seule seconde que ZF soit contradictoire.)

Peut-être que pour comprendre sa thèse je peux inviter mon lecteur à lire un texte de vulgarisation sur l'infini que j'avais écrit il y a quelques années, où je commence par expliquer le principe de récurrence sous la forme : 0 est un nombre fini, si n est un nombre fini alors n+1 est aussi un nombre fini (et les entiers naturels sont exactement ce qui s'obtient de cette manière, cf. ce que je racontais récemment sur les ordinaux) ; de ça, je prétends conclure que 1000, mais aussi 10¹⁰⁰⁰ ou 10↑10↑10↑10↑⋯↑1000 (avec 1000 élévations à la puissance), ou encore d'autres choses beaucoup plus grandes, sont des nombres finis. Faux, me rétorquerait Nelson : la seule façon dont je pourrais montrer que 10¹⁰⁰⁰ est un nombre fini, c'est par une démonstration qui commencerait par 0 est fini, donc 1 est fini, donc 2 est fini, donc 3 est fini, donc 4 est fini… et qui terminerait 10¹⁰⁰⁰ par donc 10¹⁰⁰⁰ est fini. Or si on met en doute le fait que 10¹⁰⁰⁰ soit fini, cette démonstration ne vaut que si elle est écrite complètement, ce qui est manifestement impossible, et je ne peux pas agiter des mains en disant oui, je pourrais le faire en principe, mais c'est très long alors il n'en est pas question : la question est justement de savoir si on pourrait le faire en principe, et si je ne le fais pas, mon raisonnement est circulaire. (Le problème est sérieux, puisque si on permet des longueurs non-standard, il est connu et certain qu'il existe des démonstrations de contradiction dans les mathématiques, mais ces démonstrations ne sont justement pas de longueurs finie, ce ne sont pas du tout des démonstrations, donc tout repose crucialement sur la question de la finitude.)

Maintenant, dans l'arithmétique de Peano, il n'y a aucun problème : si x et y sont des entiers naturels, alors x^y existe (=est fini, a bien un sens, est un entier naturel). Mais c'est justement ça que Nelson met en doute : dans les théories faibles de l'arithmétique qu'il considère (je n'ai pas regardé les détails, mais ce genre de choses est assez habituel, voyez par exemple la partie C de ce livre), la fonction exponentielle n'est pas forcément totale : il n'y a pas de raison que x^y existe si x et y sont des entiers naturels. Du coup, il faudrait effectivement une démonstration démesurément longue pour montrer que 10¹⁰⁰⁰ est un nombre fini ; et ces théories faibles ont un intérêt certain en algorithmique (à cause d'un rapport profond entre leurs théorèmes et différentes hiérarchies de complexité).

Maintenant, je ne sais pas si Nelson croit vraiment que le nombre 10¹⁰⁰⁰ n'existe pas ([ajout : en fait, probablement pas, parce que la fonction de multiplication, elle, est bien totale, et on peut construire 10¹⁰⁰⁰ en multipliant 1000 fois par 10, ce qui constitue une démonstration assez courte pour être écrite] ; mais il le croit sans doute pour le nombre 10↑10↑10↑10↑⋯↑1000 avec 1000 élévations à la puissance). Cela ne signifie pas qu'il existerait un plus grand entier naturel : tout le monde est d'accord que si n est un entier naturel, alors n+1 en est un, juste qu'on n'atteindrait jamais des nombres comme ce que je prétends avoir écrit ; c'est une opinion provocatrice, que je ne partage pas du tout parce que je suis religieusement platoniste, mais qu'il est difficile de disqualifier, parce qu'il est vrai qu'il faut pour éviter des démonstrations ridiculement longues (et peut-être, justement, prétendra Nelson, infiniment longues !) des axiomes strictement plus forts que ce qu'il admet, et dont il peut tout à fait croire qu'ils sont contradictoires (même si, en l'occurrence, il s'est trompé).

Et c'est un problème philosophique que je considère comme assez sérieux, de savoir si vraiment ces nombres ridiculement grands existent, et comment, et dans quelle mesure et pourquoi on a besoin qu'ils existent, et si les mathématiques peuvent s'en passer. Si on pense qu'ils existent (ce qui est mon cas), la difficulté est d'éviter le côté religieux du paradis platoniste. À l'inverse, si on pense qu'ils n'existent pas (ce qui est le cas de Nelson et, je crois, dans une certaine mesure, d'au moins un lecteur de ce blog), la difficulté est d'expliquer pourquoi ils ne causent pas de contradiction (s'ils n'en causent pas, c'est une forme d'existence au moins potentielle : pourquoi des choses inexistantes auraient-elles des conséquences tangibles comme la non-contradiction de Peano ou de ZFC ?), ou sinon, de trouver cette contradiction (comme Nelson semble déterminé à faire). Les paris sont ouverts !

C'est le jour qui s'y prête, alors je pose la question de savoir si un jour la France pourra se débarrasser de ce furoncle sur sa démocratie qu'est le Sénat. Parce qu'on peut se réjouir ou se lamenter que la gauche ait réussi à y emporter la majorité, force est quand même de constater que cette majorité est incroyablement ténue, dans une période où, entre dissidences au sein de l'autre camp, fatigue du pouvoir en place et élections locales fastueuses pour elle, la gauche avait le maximum de chances qu'elle pouvait jamais rêver sauf si le général de Gaulle s'était réveillé de sa tombe pour dire votez PS ! — et il n'y a pas grande différence entre une chambre où l'alternance ne se fait jamais et une où elle ne se fait que d'un ou deux sièges quand Mars, Vénus, Jupiter et Saturne sont toutes alignées dans une conjonction séculaire. Chose dont Jean-Pierre Raffarin semblait bien persuadé en expliquant je ne sais plus quel jour dans le cadre de l'émission C dans l'air que ce serait grave pour la stabilité des institutions et pour l'indépendance du Sénat si la haute assemblée passait à gauche.

Pas que je voie un problème fondamental avec le bicamérisme, mais il faudrait se demander au juste à quoi il est censé servir. (Victor Hugo aurait eu cette phrase, on ne sait pas trop à quel moment : Défense de déposer un Sénat le long de la Constitution.) Représenter les collectivités locales, c'est passablement hypocrite quand il s'agit en fait de surreprésenter les zones rurales, ce qui est assez scandaleux du point de vue démocratique, et la France n'est pas un État fédéral où les régions devraient être représentées pour protéger leurs prérogatives. Le Sénat se vend souvent comme une assemblée de vieux sages (ça c'est pour justifier le côté maison de retraite de la politique), plus réfléchie que le fougueux Palais-Bourbon, où les lois peuvent s'élaborer avec plus de sérénité. Pourquoi pas, après tout, à condition de l'assumer complètement : par exemple, le Sénat pourrait être formé automatiquement par échantillonage dans les n dernières législatures de l'Assemblée, ce qui en ferait effectivement une assemblée de vieux sages qui varie moins rapidement que l'Assemblée, tout en étant au moins élue de façon tout de même démocratique (i.e., en même temps que l'Assemblée, avec une mesure de retard) ; mais je n'ai jamais vu passer de telle proposition. (J'ai en revanche vu passer des avis de faire élire le Sénat à la proportionnelle, mais cela oblige à se demander si une assemblée serait prééminente sur l'autre, et si oui laquelle, et pourquoi. Le bicamérisme égalitaire pose au moins des problèmes de paralysie possible.)

Mais ce qui est particulièrement honteux, c'est la façon dont le Sénat possède un véto absolu permettant d'empêcher toute tentative de réformer la façon dont le Sénat est élu. Or, et l'alternance n'y changera rien, le Sénat n'a pas envie de changer (les Sénateurs élus par le mode d'élection X n'ayant pas envie de changer le mode d'élection X, ni même de permettre qu'on change le mode d'élection X sans leur demander leur avis). Le Sénat peut bloquer toute loi organique qui l'intéresse, comme toute tentative de réformer la Constitution : même si on peut prétendre que l'utilisation de l'article 11 de la Constitution (permettant au président de la République de soumettre au référendum tout projet de loi portant sur l'organisation des pouvoirs publics) permet de contourner la procédure de l'article 89 (qui exige l'accord du Sénat), comme cela a effectivement été tenté par de Gaulle en 1969 (année où les Français ont laissé passer une rare occasion de supprimer le Sénat, donc), les constitutionnalistes ne semblent pas du tout d'accord sur la question de savoir si cette voie est réellement possible. Je vous renvoie à un article détaillé sur le blog de Frédéric Rolin (lequel, comme un domaine à la con s'est fait websquatter, est plutôt à consulter via archive.org si on ne veut pas juste tomber sur un spam), où il explique que le Conseil constitutionnel, dans la jurisprudence de sa décision Hauchemaille du 25 juillet 2000, censurerait probablement un hypothétique décret soumettant à referendum un texte de nature constitutionnelle qui ne serait pas passé par la procédure normale de l'article 89. À la place, Frédéric Rollin propose, pour réformer le Sénat ou contourner son opposition, l'idée de faire voter par referendum un texte de loi non-normatif comme une sorte de proclamation solennelle face à laquelle, si le peuple français s'est clairement exprimé, il serait politiquement indéfendable de continuer à s'opposer. Ce n'est pas une idée idiote, mais je suis un peu sceptique quant au fait que ça puisse marcher. Il me semble vraiment que, quoi qu'on fasse, la sénatusectomie ou toute réforme sérieuse de l'institution demeure impossible.

C'est ce qu'on peut appeler un verrou institutionnel. De façon générale, et quelle que soit l'institution, a fortiori un pays, un verrou institutionnel, quelqu'un ou un organe qui a le pouvoir de paralyser toute réforme, à commencer par la suppression du verrou, est quelque chose de très problématique, parce que cela signifie qu'on risque d'être obligé d'avoir recours au coup d'État ou à une révolution pour le contourner. Les pères fondateurs des États-Unis, par exemple, se sont rendus compte du problème que le Congrès pouvait devenir un verrou de ce genre, et ont imaginé une procédure de réforme de la Constitution de l'Union (jamais utilisée) qui permet de contourner un blocage du Congrès ; ceci étant, ça ne leur a pas donné l'idée d'éviter que les États de l'Union puissent eux-mêmes agir en la matière comme des verrous contre la population (mais ça, apparemment, ça ne préoccupait pas spécialement les pères fondateurs : tout amendement de la Constitution de l'Union demande la ratification par 3/4 des États), et ça n'a pas non plus évité que le Sénat des États-Unis devienne une sorte de verrou géant permanent où il faut 60 voix pour faire quoi que ce soit. À l'ONU, le Conseil de Sécurité, ou du moins ses membres permanents, sont un verrou conçu et voulu par la Charte, et ce n'est que par des moyens tout à fait indirects ou bien par une proclamation solennelle (un peu de l'ordre d'idée de ce que Frédéric Rolin propose ?) que l'Assemblée générale peut faire quoi que ce soit. Et je ne parle pas de l'Union européenne parce que j'ai déjà ramassé dans ce qui précède largement de quoi faire faire caca aux trolls.

L'écriture de l'entrée précédente, en interlingua, et la lecture de quelques textes en interlingua avant et après, m'a conduit à m'interroger sur l'usage et le sens des temps grammaticaux entre les différentes langues, ou du moins entre les seules langues que je maîtrise assez parfaitement pour avoir un avis vraiment fondé sur un usage idiomatique, c'est-à-dire le français et l'anglais (qui sont d'ailleurs toutes les deux classées par l'interlingua comme des langues sources).

L'anglais a une riche moisson de temps grammaticaux (tellement riche que la nomenclature pose quelque problème), fondée sur un usage assez systématique des temps composés et surcomposés (il n'y a que deux temps simples, le présent et le prétérit), et qui d'ailleurs mélange des notions temporelles et des notions aspectuelles (pas que je sois vraiment persuadé que la distinction ait toujours un sens ou soit toujours pertinente) : he speaks (présent), he is speaking (présent progressif), he spoke (prétérit), he was speaking (prétérit progressif), he has spoken (parfait), he has been speaking (parfait progressif), he had spoken (plus-que-parfait), he had been speaking (plus-que-parfait progressif), he will speak (futur), he will be speaking (futur progressif), he will have spoken (futur antérieur), he will have been speaking (futur antérieur progressif). Je ne considère que le mode indicatif (quoique là aussi, la dinstinction temps/mode n'est ni claire ni forcément très pertinente), sinon il faudrait au moins ajouter : he would speak (conditionnel), he would be speaking (conditionnel progressif), he would have spoken (conditionnel antérieur), he would have been speaking (conditionnel antérieur progressif).

La liste semble cependant close : autant ces constructions satisfont le logicien par leur côté systématique, autant on doit avouer qu'elles ne sont pas si systématiques que ça : pour tout temps grammatical T on ne peut pas former trois nouveaux temps en mettant au temps T l'auxiliaire dans les constructions be speaking, have spoken et encore moins will speak, sinon on arriverait à des temps comme *he is being speaking (présent progressif progressif ?), *he is having spoken (présent progressif antérieur ?), he has had spoken (parfait antérieur ?), †he is willing speak (présent progressif postérieur ?), etc. : certaines de ces constructions sont plus ou moins défendables (notamment le surcomposé he has had spoken me semble assez correct, en fait), d'autres ne le sont absolument pas (l'auxiliaire will, en fait, n'est même pas vraiment un verbe, donc il est totalement impossible de changer son temps en le remplaçant par be willing ou quelque chose comme ça). Ceci étant, même dans les temps qui existent sans aucune ambiguïté, en ajoutant une couche de voix passive, on peut arriver à des choses aussi agréablement récursives que words that will have been being spoken (le futur antérieur progressif passif).

Le français, en comparaison, a quatre temps simples : il parle (présent), il parlait (imparfait), il parla (passé simple) et il parlera (futur) ; si on considère le conditionnel comme un temps plutôt qu'un mode, il faut y ajouter : il parlerait. Le Bescherelle, comme beaucoup d'autres grammaires, n'admettent comme seule construction de temps composé que la construction avoir parlé (c'est-à-dire l'auxiliaire avoir, ou être selon les verbes, et le participe passé). Ceci donne les temps supplémentaires : il a parlé (passé composé), il avait parlé (plus-que-parfait), il eut parlé (passé antérieur) et il aura parlé (futur antérieur) ; et c'est tout (et il aurait parlé pour le conditionnel passé, agrémenté de la « seconde forme » inexplicable il eût parlé, qui est le seul temps composé qui ne corresponde pas clairement à un temps simple).

Cette analyse me semble un peu simpliste, d'une part parce que d'une part on trouve occasionnellement, peut-être même plus souvent qu'en anglais, des temps surcomposés (il a eu parlé, il avait eu parlé, il aura eu parlé et peut-être il eut eu parlé même si ce dernier fait un peu hu-hu), et d'autre part parce que ça omet deux autres schémas de composition que sont le passé récent et le futur proche : en effet, avec le verbe aller ou venir de suivi de l'infinitif on forme des constructions qui méritent, tout autant qu'avec aller (ou être) suivi du participe passé, d'être qualifiées de temps composés : il va parler (futur proche), il vient de parler (passé récent), mais aussi il allait parler (qu'on pourrait qualifier de futur proche antérieur, mais quand on n'y réfléchit, ce n'est pas très logique par rapport à la différence entre futur simple et futur antérieur, il vaudrait mieux le qualifier de passé prochement postérieur) et il venait de parler (passé récemment antérieur ?). Bizarrement, cela s'arrête là : on ne peut pas mettre aller ou venir de à d'autres temps ; enfin, on peut le faire, mais ça n'a pas le sens idiomatique d'une formation de temps composé (il ira parler signifie qu'il fera un bout de chemin pour parler, pas qu'il sera sur le point de parler ; on s'en rend compte en essayant de mettre au passé puis au futur la phrase tu arrives devant la porte, tu vas frapper : au passé cela donne tu arrivas devant la porte, tu allais frapper et pas tu allas frapper, et au futur on est obligé de dire quelque chose comme tu arriveras devant la porte, tu seras sur le point de frapper).

L'interlingua a trois temps simples : ille parla (présent), ille parlava (passé, dont je vais reparler dans un instant), ille parlara (futur) ; on peut y ajouter un conditionnel, ille parlarea. Mais à ce système de temps simples de richesse intermédiaire entre l'anglais (2 temps simples) et le français (4 temps simples), il ajoute plus de schémas de composition que le français ou que l'anglais : on peut former un temps composé comme en français en conjuguant haber parlate (avoir parlé, donc avoir plus le participe passé, et comme en anglais ce sera toujours l'auxiliaire avoir qui servira), mais aussi comme pour les temps progressifs de l'anglais en conjuguant esser parlante (être parlant), ou encore comme pour les temps proches du français en conjuguant vader parlar (aller parler) ou venir de parlar (venir de parler), même si ce dernier n'est pas explicitement mentionné par les grammaires. Et il n'y a pas de raison de limiter ces deux dernières compositions comme le français le fait, donc on a 4×4=16 temps simplement composés : ille ha[be] parlate (passé composé), ille habeva parlate (passé antérieur), ille habera parlate (futur antérieur), ille es[se] parlante (présent progressif), ille era [=esseva] parlante (passé progressif), ille [es]sera parlante (futur progressif), ille va[de] parlar (futur proche), ille vadeva parlar (passé prochement postérieur(?)), ille vadera parlar (futur prochement postérieur(?)), ille veni de parlar (passé proche), ille veniva de parlar (passé prochement antérieur), ille venira de parlar (futur prochement antérieur). Et il n'y a pas de raison de ne pas surcomposer comme fait l'anglais, donc le he has been speaking de l'anglais peut très bien se traduire ille ha essite parlante, mais rien ne dit non plus que la composition dans l'autre sens, ille es habiente parlate (*he is having spoken), n'a pas autant le droit d'exister. Cela fait une belle floraison de temps !, qui n'a rien à envier à celle de l'esperanto, mais qu'il faut probablement utiliser avec modération si le but est d'être compréhensible et pas de s'amuser (encore que s'amuser est encore la raison la plus valable d'utiliser des langues inventées).

⁂

Mais ce n'est pas tout de fabriquer des temps selon des règles logiques, il faut aussi qu'ils aient vaguement un sens, ces temps.

Il est intéressant de comparer le français et l'anglais, parce que l'usage des temps est relativement orthogonal. Il serait rigolo de faire un tableau avec en ligne les 14 temps de l'anglais (ou plus si on compte le conditionnel) et en colonne les 12 ou plus temps du français, et essayer de remplir toutes les cases où on peut donner un exemple assez naturel de contexte où on emploierait tel temps en anglais et tel temps en français. Comme je n'ai pas le courage d'essayer de remplir tout le tableau, je vais juste tâcher de discerner un petit nombre d'usages communs, et pour les temps du passé :

1. un événement ponctuel dans le passé, présenté dans le cadre d'une narration : on utilisera alors typiquement le passé simple en français (et alors l'oracle parla ainsi) et le prétérit en anglais (and then the oracle spoke thus) ;
2. un événement durable ou répétitif dans le passé, ou dont la terminaison n'est pas envisagée ou soulignée : on utilisera alors typiquement l'imparfait en français (il aimait couper les cheveux en quatre) et le prétérit en anglais (he liked to split hairs) ;
3. un événement ponctuel dans le passé, rapporté au présent ou comparé au présent : on utilisera alors typiquement le passé composé en français (hier, j'ai parlé avec un grammairien fou) et le prétérit en anglais (yesterday, I spoke with a mad grammarian) ;
4. un événement dans le passé situé comme englobant un événement plus ponctuel : on utilisera alors typiquement l'imparfait en français (nous parlions ensemble quand tout d'un coup…) et le prétérit progressif en anglais (we were speaking together, when suddenly…) ;
5. un événement indéfini dans le passé, produisant des conséquences présentes ou évoqué relativement au présent : on utilisera alors typiquement le passé composé en français (j'ai parlé de grammaire de nombreuses fois sur ce blog) et le parfait en anglais (I have spoken many times about grammar on this blog).

Ce ne sont que des catégories très grossières, je ne prétends ni qu'elles soient très bonnes ou très bien définies, ni que dans chacune de ces catégories on ne puisse pas trouver des cas où le temps choisi sera différent, et je prétends encore moins avoir couvert tous les cas. Mais en première approximation, c'est déjà quelque chose, et en tout cas on voit bien que les temps français et anglais se recoupent très mal. Et cela pose du coup la question, pour une langue inventée comme l'interlingua, de savoir quel temps on utilise dans chaque cas. Pour le cas 5, je n'ai aucun doute qu'on doive utiliser le passé composé (io ha multe vice parlate de grammatica sur iste blog), puisque le français comme l'anglais concourent dans ce sens. Pour le cas 4, puisque l'interlingua a les temps progressifs de l'anglais, on peut sans hésitation les utiliser (nos era parlante insimul, quando subito…). Pour les cas 1 et 2, j'utiliserais le passé simple (e alora le oraculo parlava assi ; ille amava secar le capillos in quatro), même si je suis inexplicablement gêné par le fait que ces deux cas fusionnent (inexplicablement, vu que c'est le cas en anglais et que ça ne me gêne pas). Reste le cas 3, où le français et l'anglais ont une solution nettement différente : faut-il écrire heri, io ha parlate con un grammaticario folle, en imitant le français, ou bien, en imitant l'anglais, heri, io parlava con un grammaticario folle ? J'ai tendance à pencher pour le premier, parce que le second signifie plutôt pour moi hier, je parlais avec un grammairien fou (cas 4 ci-dessus), mais en fait, pour dire ça sans ambiguïté, on peut très bien mettre : heri, io esseva parlante con un grammaticario folle (de nouveau, comme en anglais).

Bref, c'est le problème avec les langues inventées, il n'y a pas d'idiome pour dire ce qu'on doit faire. Ce n'est pas vraiment un problème : les ambiguïtés dont on parle ne sont pas bien graves (ce ne sont pas vraiment des ambiguïtés, juste des hésitations sur l'usage ; mais cf. ce que je racontais ailleurs sur l'« atisme » et l'« itisme » en esperanto, il semble que ça ait été une belle flamewar, pardon, une flammilito). Mais j'ai quand même tiqué en lisant ce post de blog (écrit par un hongrois) en interlingua, auquel je faisais référence dans la précédente entrée, parce qu'il écrit, par exemple, io era presente a iste occasion e faceva photos tamben (j'étais présent à cette occasion et j'ai aussi fait des photos ; il s'agit en gros des cases 2 et 3 de ma catégorisation ci-dessus) là où sous l'influence du français j'aurais mis io era presente […] e io ha facite.

Il serait intéressant de reprendre mes catégories 1 à 5 ci-dessus (éventuellement enrichies ou corrigées s'il s'avère qu'elles sont trop mauvaises) pour donner les exemples dans un maximum de langues pour lesquelles la comparaison a un intérêt (probablement en gros les langues indo-européennes). Pour ce qui est de l'allemand, j'ai tendance à traduire par : (1) und dann sprach das Orakel so (prétérit, donc), (2) ihm gefiehl Haarspalterei (prétérit de nouveau), (3) gestern habe ich mit einem verrückten Grammatiker gesprochen (passé composé parfait), (4) wir sprachen zusammen, als plötzlich… (prétérit) et (5) ich habe oftmals von Grammatik auf diesem Blog gesprochen (parfait) — ce qui colle plutôt mieux avec le français et mon interprétation-française-de-l'interlingua qu'avec l'anglais — mais je ne sais pas si mon intuition linguistique est fiable en la matière.

Une autre question, évidemment, est de savoir si ça a un intérêt quelconque d'avoir des temps verbaux plutôt que tout exprimer par des adverbes. Mais ça c'est une polémique dans laquelle je ne rentrerai pas (pour ne pas démolir les langues indo-européennes : je les aime bien, moi, les langues indo-européennes).

Mi pullinetto es presentemente in Italia (a Roma). Ille non parla le italiano, ergo si ille debe communicar con italianos, lo facera in anglese. Que es tristissime : ille poterea comprehender le italiano si illo serea parlate multo lentemente ; sed in senso inverse, le italianos generalemente non comprehende le francese — de facto, illos anque non ben parla le anglese. Il es alique absurde de utilisar le anglese pro communicar inter gentes de linguas latin. Mi oncle, qui parla perfectemente le italiano e qui va satis frequemente in Espania, parla in italiano con le espanioles e illes le comprehende globalemente ; etiam le espanioles pote parlar con le portugeses si istes imita un accento espaniol. Sed si on cognosce solo le francese, que facer ? On poterea parlar un sorta de pseudo-italiano o pseudo-espaniol, sin se fatigar a apprender le conjugationes (io parlo, tu parli, egli parla, noi parliamo, voi parlate, essi parlano : proque non simplemente semper parla ?). E illo, es exactemente que es le interlingua.

Io non crede al possibilitate de successo del linguas inventate (sin motivation politic forte). Sia nos realistic : nemo parla le esperanto e nemo lo parlara unquam, le esperanto non es de alcun utilitate pro communicar. (Io pensa anque que le esperanto es un lingua nimis artificial e disagradabile : vide iste e ille paginas Web pro saper proque. In omne caso, illo es difficile a comprehender si on non lo ha apprendite antea : vos, lectores francese, haberea probabilemente trovate mia kokidetĉjo estas ĉi-hore en Italujo, li ne parlas itale, do se devas komuniki kun italoj, ĝin faros angle minus comprehendibile que le prime phrase de iste texto, mi pullinetto es presentemente in Italia, ille non parla le italiano, ergo si ille debe communicar con italianos, lo facera in anglese ; e pro un chinese, le duos es equalmente 乱语.) Io anque non crede al successo del interlingua como lingua mundial ; e de facto etiam minus gentes lo parla (o simplemente cognosce su nomine) que le esperanto. Il es desperate.

Sed como lingua commun inter populos latin, non es completemente aberrante : le interlingua non pretende al universalitate — e assi illo ha un avantage certe supra le esperanto, es que multe gentes lo comprehende spontaneemente[#]. Io non pote parlar le italiano sin ser ridiculissime, sed io pote parlar[#2] passabilemente le interlingua (sin lo haber unquam vermente apprendite), como vos vide : non es absurde de pensar que, parlante interlingua (o interlingua con qualque parolas de italiano miscite), io serea melio comprehendite del italianos que si io parlarea in francese o in porco-italiano o etiam in anglese. Le ridiculo es certe, sed non plus que quando mi oncle parla in italiano con le espanioles. (Le italianos pensarea probabilemente que io parla in catalan o alique como isto.)

Io ha nunquam experite, sed si io haberea un amico italiano (o espaniol, portugese, romanian…), serea satis natural de nos scriber in iste lingua, post haber convenite de isto. Parlar assi a alcuno que io non cognosce, forsan non (io es nimis timide).

OK, iste post era un experientia (e io jam ha facite un tal : istac e illac[#3]) pro saper : qui lo ha legite usque al fin ? E qui lo ha comprehendite sin haber apprendite le lingua ? Scriber in interlingua es amusante pro me, illo me dona un sentimento de libertate (proque le grammatica non es nimis rigide : illo admitte frequentemente diverse possibilitates equalmente correcte, on non va me dicer que io ha facite multe « faltas », per exemplo que istac non es un existente parola interlingual). Io deberea essayar de scriber aliquando un fragmento litterari gratuite in iste lingua.

[#] Etiam gentes qui parla solo le anglese, apparentemente, e non un lingua latin (io non lo credeva, sed io ha un testimonio in iste senso). Es probabilemente multo plus difficile pro illes, sed non excludite.

[#2] Parlar, scribeva io ? Scriber, certemente, sed parlar, de facto, io non ha realmente experite.

[#3] Non es impressive : il es gentes qui tene un blog integre in interligua (como isto).

Je déjeunais hier avec mon poussient dans une brasserie quelconque, et nous n'avons pas pu nous empêcher d'entendre la conversation de la table voisine, qui portait sur l'usage d'Internet. Le genre de conversation qui a tendance à m'alarmer que les gens puissent être d'une ignorance aussi profonde. Bon, en l'occurrence, ce n'était pas si affolant que ça (et les personnes en question étaient probablement septuagénaires, ce qui compte comme circonstance atténuante face aux nouvelles technologies), leur façon de discuter de la barre d'URL du navigateur était plutôt drole qu'effrayante, et il n'est pas très clair si c'était le genre de personnes qui tapent Google dans la barre de recherche de Google pour pouvoir accéder à Google et faire leur recherche (si, si, ça existe), mais ce qui m'a surtout frappé, c'est la façon dont elles avaient l'air de considérer Internet comme un truc géré par une sorte d'autorité centrale, comme si leur navigateur Web, leur fournisseur Internet, Google, et la plupart des sites Web relevaient d'une unique organisation. Est-ce vraiment une erreur grave de ne pas comprendre que ce sont des choses totalement séparées ? En un sens, oui, parce que seule une compréhension minimale des acteurs en présence permet d'espérer s'armer correctement contre les arnaques et les trous de sécurité (il faut commencer par comprendre que votre navigateur est votre allié — même s'il peut souffrir de problèmes de sécurité — et que Google l'est un petit peu, mais qu'un site Web aléatoire doit être vu avec soupçon sauf si on est certain qu'il est bien ce qu'il prétend être).

Je me suis souvent dit, puisqu'on exige des utilisateurs d'une voiture qu'ils aient un permis de conduire lorsqu'ils veulent s'en servir sur les routes, ne faudrait-il pas demander des internautes potentiels, lorsqu'ils veulent souscrire à un abonnement Internet, de passer d'abord un permis de surfer qui attesterait de leur maîtrise de certains concepts très basiques, par exemple :

• comprendre qu'Internet est un réseau décentralisé d'ordinateurs, et que le Web en est sa face la plus visible (et savoir un petit peu la différence entre ces deux termes),
• savoir qu'un navigateur Web est un logiciel qui permet de consulter des pages Web, et qu'il y en a plusieurs possibles (et peut-être aussi savoir ce qu'est un système d'exploitation, et qu'il y en a plusieurs possibles),
• savoir un minimum utiliser son navigateur, par exemple créer un bookmark, ouvrir un nouvel onglet, etc. (mais pas forcément : ces choses n'ont guère d'impact sur la sécurité),
• comprendre un petit peu comment est organisée l'adresse d'une page Web (et peut-être le terme URL), par exemple pour savoir que quand on va visiter http://www.example.tld/blah.html on se connecte à l'ordinateur nommé www.example.tld qui est géré par la personne qui a loué le domaine example.tld,
• en particulier, comprendre la différence entre saisir une adresse Web et rechercher un mot-clé dans un moteur de recherche ou dans l'historique du navigateur,
• comprendre comment sont attribués les noms de domaine (notamment, que l'identité de personne n'est vérifiée, sauf pour le HTTPS, et encore pas grand-chose),
• comprendre les rudiments de la sécurité : savoir choisir un mot de passe, savoir le faire retenir à son navigateur, savoir qui peut connaître ce mot de passe, etc., et aussi comprendre la notion de trou de sécurité, de virus, etc.,
• comprendre les bases de l'anonymat : ce qu'un site Web peut savoir de vous (et pour commencer, ce qu'est une adresse IP), ce qu'est un cookie, etc.

Tout cela serait sanctionné par un petit QCM, beaucoup plus facile que pour le code de la route (les questions possibles seraient moins nombreuses, on en aurait vite fait le tour : l'idée serait que n'importe qui puisse apprendre les connaissances requises en un jour ou deux). Rendre la chose obligatoire, même simplement pour souscrire à une offre ADSL/fibre (pas question d'exiger ça pour rentrer dans un cybercafé), est sans doute un chouïa liberticide, mais on peut peut-être imaginer des mesures incitatives, juste proposer ces cours gratuitement comme on fait des cours de secourisme, il y a sans doute des possibilités.

Pourquoi ? Parce qu'il est faux de dire que celui qui connecte son ordinateur à Internet sans comprendre quoi que ce soit à la sécurité ne met en péril que son propre ordinateur : si cet ordinateur se retrouve enrôlé dans un botnet (voilà un concept qu'il faudrait introduire dans un cours de ce genre), il cause du mal à tous les internautes et à Internet dans son ensemble, il peut participer à des attaques DDoS ou à l'envoi de spam, dont l'utilisateur ne sera pas judiciairement responsable mais qui méritent sans doute qu'on s'en soucie.

Bon, en fait, ce qui me pose surtout problème, c'est que si on instaurait un tel brevet de sécurité, d'aucuns se précipiteraient pour y mettre de la propagande sur la propriété intellectuelle. (Voyez les affiches totalement ridicules que l'HADOPI nous a récemment concoctées.)

Encore une fois je vais tenter de communiquer mon enthousiasme pour un objet mathématique en essayant d'en parler de façon compréhensible par ma petite sœur[#] : et encore une fois je vais échouer lamentablement parce que les non-matheux n'y comprendront vite rien ou n'essaieront pas de lire, et les matheux n'y apprendront rien. Encore une fois j'écris un post de blog en promettant que c'est le premier d'une série : et encore une fois je vais échouer parce que cette série s'arrêtera probablement à un élément (c'est toujours mieux que zéro, certes).

Parmi les choses qui me fascinent dans les mathématiques (un jour, je publierai un petit catalogue de mes objets mathématiques préférés), il y a beauté qui émane de la symétrie (dans quoi je range toute structure algébrique assez rigide), mais il y a aussi quelque chose sur quoi j'ai plus de mal à mettre un mot, disons peut-être la grandeur. Les ordinaux sont très représentatifs de cette dernière catégorie, et ils forment d'ailleurs une échelle de grandeur à l'aune de laquelle on peut mesurer beaucoup de « phénomènes » mathématiques (souvent pour un résultat décevamment[#2] médiocre, d'ailleurs). J'ai déjà tenté d'en parler sur ce blog (et encore), mais sans vraiment faire l'effort de vulgariser de quoi il s'agit au juste : voici donc une nouvelle tentative, agrémentée de petits dessins.

[Lire la suite…]

Mon passage à RAID6 est essentiellement fini, mais comme j'aime bien connaître les détails de ce que j'utilise[#], j'ai voulu savoir un peu précisément comment il fonctionne (je sais ce que c'est qu'un code correcteur, bien sûr, mais je veux dire, savoir assez précisément comment les données sont organisées pour pouvoir reconstituer mes disques moi-même, ou aller y chercher n'importe quelle donnée, si jamais Linux cessait d'exister dans un pouf de logique).

L'idée de base est la suivante : à part les métadonnées dont je n'ai pas cherché à savoir comment elles sont organisées, un tableau RAID divise chaque disque (ou partition) du tableau en chunks (également appelés stripes), qui font par défaut 512ko. Si on a N disques dont N−k de données et k de redondance, alors un ensemble de N chunks au même emplacement sur chacun des disques s'appelle une stride, et une stride porte donc N−k chunks de données plus k chunks de redondance. Sur N−k disques (différents pour chaque chunk, comme je vais l'expliquer), les chunks contiennent les données de la stride : ce sont ces disques-là qui seront normalement lus, sauf erreur signalée (quand un disque accepte de lire un bloc, on peut considérer que les données sont correctes, parce qu'il y a des sommes de contrôle au niveau du disque). Les k disques restants contiennent des syndromes de contrôle, calculés octet par octet à partir des N−k chunks de données de la stride. Si j'écarte le RAID0, qui n'a aucune redondance, et le RAID1 qui pour lequel tous les disques sont de toute façon identiques, il reste uniquement k=1 pour le RAID5 et k=2 pour le RAID6. Pour le RAID5, la somme de contrôle s'appelle P, ou chunk de parité, et pour RAID6, les deux sommes de contrôle s'appellent P (la même que pour RAID5) et Q.

L'organisation d'un tableau RAID6 de 4 disques (en mode left-symmetric, le mode par défaut) ressemble à ceci, où chaque ligne représente une stride, chaque colonne un disque (ou partition) et chaque case un chunk :

	Disque 0	Disque 1	Disque 2	Disque 3
Stride 0	Q	D0	D1	P
Stride 1	D2	D3	P	Q
Stride 2	D5	P	Q	D4
Stride 3	P	Q	D6	D7
Stride 4	Q	D8	D9	P
Stride 5	D10	D11	P	Q
(etc., cycliquement)

Ici, D indique un chunk de données, P et Q des chunks de syndrome pour la stride. En l'absence d'erreur, les données se lisent donc en prenant le chunk 0 du disque 1 (ce qui donne D₀, le premier chunk de données), puis le chunk 0 du disque 2 (ce qui donne D₀), puis le 1 du disque 0 (D₂), puis le 1 du disque 1 (D₃), puis le 2 du disque 3 (D₄) et le 2 du disque 0 (D₅), et ainsi de suite, comme indiqué par ce tableau. Le rôle des disques est permuté cycliquement à chaque stride, ce qui assure qu'ils jouent tous le même rôle, et qu'il n'y en a pas un qui s'use prématurément (contraster avec RAID4, qui isole un disque uniquement pour la parité) ; la stride 0 attribue le syndrome Q au disque 0 et le syndrome P au dernier disque et les données aux autres disques dans l'ordre, et ensuite on décale cycliquement en décrémentant les numéros des disques. Pour du RAID5 on aurait une organisation semblable à ceci près qu'il n'y a pas de Q, donc la première stride attribue le syndrome P au dernier disque et les données aux autres, et la rotation se fait pareil (je parle toujours pour le mode mode left-symmetric : vous aurez sans doute deviné que right-symmetric tourne dans l'autre sens).

Le syndrome P est très facile à calculer : c'est simplement le XOR de tous les octets de données correspondants (c'est-à-dire que chaque octet d'un chunk P est le XOR des octets numérotés de la même manière dans chacun des chunks D de la même ligne) ; le syndrome Q, lui, est une combinaison linéaire des octets de données calculée dans le corps 𝔽₂₅₆ à 256 éléments, dont les coefficients sont g⁰, g¹, g², etc., où g est un élément primitif de 𝔽₂₅₆ et l'exposant est donné par le numéro du chunk de données à l'intérieur de la stride. Si je reprends le tableau précédent indiquant l'organisation du RAID6 sur 4 disques, ça fait :

	Disque 0	Disque 1	Disque 2	Disque 3
Stride 0	D0⊕2⊛D1	D0	D1	D0⊕D1
Stride 1	D2	D3	D2⊕D3	D2⊕2⊛D3
Stride 2	D5	D4⊕D5	D4⊕2⊛D5	D4
Stride 3	D6⊕D7	D6⊕2⊛D7	D6	D7
Stride 4	D8⊕2⊛D9	D8	D9	D8⊕D9
Stride 5	D10	D11	D10⊕D11	D10⊕2⊛D11
(etc., cycliquement)

J'ai noté ⊕ pour le XOR, qui est l'addition dans 𝔽₂₅₆, et ⊛ pour la multiplication dans ce dernier, l'élément primitif étant g=2 avec une représentation de 𝔽₂₅₆ de façon habituelle modulo un polynôme irréductible. Voyez ce document (temporairement indisponible sur kernel.org alors vous pouvez le consulter ici sur le cache Google) pour les détails. Mais sur le cas très simple de 4 disques, on se persuade très facilement qu'en connaissant deux quelconques des nombres u, v, u⊕v et u⊕2⊛v, on retrouve toujours u et v.

Quel polynôme irréductible est choisi pour les calculs ? Le document précédent affirme que la représentation de 𝔽₂₅₆ choisie est celle de AES/Rijndael, c'est-à-dire modulo x⁸+x⁴+x³+x²+1. J'ai sauté en l'air en voyant ça, parce que je sais très bien, pour faire faire ce genre d'exercice à mes étudiants, que le polynôme utilisé par AES/Rijndael n'est pas primitif (je veux dire, la classe de l'indéterminée modulo le polynôme, i.e., l'élément codé par 0x02, n'est pas d'ordre multiplicatif 255, mais 51). Du coup, ça voudrait dire que le RAID6 de Linux ne marche plus au-delà de 51 disques de données (ou du moins, ne peut pas corriger toutes les combinaisons de deux disques défaillants).

Heureusement, le polynôme d'AES/Rijndael est, en fait, x⁸+x⁴+x³+x+1, et c'est la première affirmation qui est fausse, la seconde est correcte, le RAID6 de Linux utilise bien x⁸+x⁴+x³+x²+1, qui est primitif, donc RAID6 marche comme annoncé (enfin, au moins mathématiquement — je n'ai pas 54 disques sous la main pour tester). M'enfin, ça reste une erreur et un sale coup du Club Contexte, d'avoir écrit ça. Et potentiellement dangereuse, si quelqu'un se précipite pour utiliser des implémentations matérielles optimisées des opérations AES afin d'accélérer le RAID6 ! J'ai écrit à Peter Anvin, qui a reconnu l'erreur (il avait bien remarqué que x⁸+x⁴+x³+x+1 n'était pas primitif et a cru à une faute de frappe, choisissant donc involontairement un polynôme non-standard) et m'a promis de la corriger.

Concrètement, donc, pour le choix x⁸+x⁴+x³+x²+1, calculer 2⊛v pour un octet v se fait en calculant soit 2v (la multiplication usuelle) soit 2v⊕0x11d, lequel des deux est inférieur à 256. Ceci, parce que 0x11d est le nombre 2⁸+2⁴+2³+2²+1.

Vérification concrète sur un de mes tableaux RAID6 : les 32 premiers octets de chacun des quatre disques du tableau sont :

/dev/sdc20
00000000  aa 98 b9 a6 40 e0 da c2  c6 ca 5c 14 ad c0 ae e8  |....@.....\.....|
00000010  40 e8 d0 f2 40 ee c2 f2  40 ee d0 d2 c6 d0 40 e6  |@...@...@.....@.|
/dev/sda20
00000000  58 46 53 42 00 00 10 00  00 00 00 00 03 10 6c 00  |XFSB..........l.|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
/dev/sdd20
00000000  79 6f 75 72 20 70 65 61  63 65 2e 0a 57 68 61 74  |your peace..What|
00000010  20 74 68 79 20 77 61 79  20 77 68 69 63 68 20 73  | thy way which s|
/dev/sdb20
00000000  21 29 26 30 20 70 75 61  63 65 2e 0a 54 78 0d 74  |!)&0 puace..Tx.t|
00000010  20 74 68 79 20 77 61 79  20 77 68 69 63 68 20 73  | thy way which s|

Visiblement, le disque 1 (/dev/sda20, ne me demandez pas comment ils se sont retrouvés dans cet ordre dans le tableau) contient le début D₀ des données (il s'agit d'un filesystem XFS, donc ça commence par XFSB), et le disque 2 (/dev/sdd20) contient aussi un chunk de données (D₁, un bout d'un fichier[#2]). Le disque 3 (/dev/sdb20) contient le XOR de ces deux chunks, P=D₀⊕D₁, ce qui est assez visible puisque comme D₀ contient beaucoup de 0, sur ces octets-là il s'agit de la même chose que D₁. Et enfin le disque 0 (/dev/sdc20) contient Q=D₀⊕2⊛D₁, ce qui comme D₁ ne contient que des octets ASCII (donc <0x80), vaut en fait D₀⊕2D₁, et ça se voit par exemple au fait que beaucoup d'espaces (0x20) dans D₁ deviennent des arrobas (0x40) dans Q (lorsque D₀ contient 0). Ici, rien ne permet de vérifier qu'on a le bon polynôme. En revanche, si je considère la stride 2 (à l'offset 0x80000 parce que j'utilise des chunks de 256ko),

/dev/sdc20
00080000  f6 2a 28 86 e1 68 a8 fe  b3 63 2c 2d 26 a8 22 f8  |.*(..h...c,-&.".|
00080010  f2 13 c6 e4 9a 7c 55 3f  25 bf 75 48 7a db f7 8e  |.....|U?%.uHz...|
/dev/sda20
00080000  09 d5 d7 79 1e 97 57 01  4c 9c d3 d2 d9 57 dd 07  |...y..W.L....W..|
00080010  0d ec 39 1b 65 83 aa c0  da 05 0d 37 85 24 08 71  |..9.e......7.$.q|
/dev/sdd20
00080000  0e ab af ee 20 2f b2 1e  84 39 a7 a5 b3 b2 bb 12  |.... /...9......|
00080010  06 d9 6e 2a d6 07 55 81  b5 d9 92 ef 0b 54 0c fe  |..n*..U......T..|
/dev/sdb20
00080000  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00080010  ff ff ff ff ff ff ff ff  ff ba 78 7f ff ff ff ff  |..........x.....|

— cette fois on peut faire le calcul : sur le premier octet, par exemple, D₄ contient 0xff, D₅ contient 0xf6, on vérifie que P contient 0xff⊕0xf6=0x09, et comme Q doit contenir 0xff⊕2⊛0xf6=0x0e, c'est que 2⊛0xf6=0xf1 et comme 2×0xf6=0x1ec, le polynôme utilisé est représenté par 0x1ec⊕0xf1=0x11d, comme je l'annonçais (et ce n'est pas le polynôme de AES/Rijndael).

À ce stade-là, je m'estime satisfait dans le fait que j'ai compris comment les choses fonctionnent.

[#] En fait, cette affirmation est parfaitement fausse : en général, quand je regarde comment quelque chose fonctionne, surtout en informatique, je suis tellement dégoûté par ce que je découvre que je n'ose plus m'en servir.

[#2] Si vous voulez tout savoir, ce fichier contient des phrases complètement dénuées de sens dans un style assez pompeux : Jesus strong first whoredoms, where no bread along which is in your peace. What thy way which shall be killed. And when God. They are come to pass, the image with him: for thy mine eyes unto the Midian was the land whither the same there arose a man be fulfilled: But I spoken by you, and his tabernacle at the altar another: for the time of tempted in thing, the figunto thee: they believe it to them: but thou hast given me to be unto you the Shushan is with man's wife. Il s'agit du résultat du passage de dissociated press sur la bible du roi Jacques que j'avais fait il y a longtemps parce que je trouvais le résultat très amusant.

J'ai déjà dû raconter quelque part sur ce blog que je suis obsédé par la préservation de l'information. En particulier, l'idée de perdre des données informatiques est quelque chose contre quoi je veux me garder le plus sérieusement possible. Ça m'est déjà arrivé par le passé, à une époque où les disques durs coûtaient strictement plus qu'une bouchée de pain, et j'ai perdu des fichiers qui m'étaient précieux[#]. Pour mes données les plus précieuses, j'ai un système de sauvegarde où (1) les données sont répliquées par RAID entre plusieurs disques (cf. ci-dessous), (2) elles sont en plus répliquées chaque jour par rsync entre deux ordinateurs distants de 20km (et le point précédent s'applique sur chacun de ces ordinateurs), (3) sur l'un de ces ordinateurs, une copie est faite chaque nuit de tous les fichiers qui ont changé, histoire de pouvoir extraire de vieilles versions si je me rends compte que j'ai fait des changements malencontreux (ceci, en plus du fait que beaucoup de données sont de toute façon sous contrôle de git ; et le premier point s'applique aussi à ces copies), et (4) une fois par an au moins, je fais aussi une copie sur médias optiques, que j'archive. Avec tout ça, je me sens raisonnablement en sécurité.

Le problème, c'est qu'à côté de ces données de grande importante (très grossièrement, tous les fichiers que je crée moi-même), il y en a d'autres, qui ne méritent pas des précautions aussi importantes, ou surtout, qui ne les permettent pas parce que le volume de données est trop important, mais qu'il m'embêterait quand même assez sérieusement de perdre : des tas de choses que j'ai téléchargées sur Internet (ou dont l'effet de rayons cosmiques aléatoires frappant mon disque dur a causé l'apparition), ou encore des choses calculées par des ordinateurs au prix d'heures de calculs que je n'ai pas envie de refaire. Il me faut donc plusieurs niveaux intermédiaires entre les données les plus importantes et les moins importantes (voire, celles qui sont nettoyées automatiquement, comme le contenu de /tmp).

Et un autre facteur qu'il ne faut pas perdre de vue, c'est le temps passé à restaurer les données en cas de problème : parfois les données elles-mêmes n'ont pas vraiment de valeur (comme pour les partitions système : il s'agit d'exécutables Linux qui de toute façon sont disponibles publiquement), mais le temps passé à les récupérer ou à les remettre en place peut justifier qu'on utilise tel ou tel mécanisme de sauvegarde.

J'en viens à RAID : pour ceux qui ne connaissent pas, cet acronym signifie Redundant Array of Inexpensive Disks. L'idée est de partager des données entre plusieurs disques durs de façon soit à augmenter la capacité ou la vitesse, soit à diminuer les risques de pertes de données, soit les deux. En gros, vous avez N disques (ou partitions de même taille sur des disques différents), vous choisissez un niveau de redondance k qui vous protège contre la panne simultanée de k disques, et RAID vous présente l'ensemble comme si vous aviez un seul disque de la capacité totale de N−k disques, et qui peut résister à une défaillance de k disques. En clair, il existe les principaux niveaux suivants :

• RAID0, qui ne crée aucune redondance (k=0) : vos données sont réparties entre les N disques et il n'y a aucune protection contre les défaillances, bien au contraire, si un disque quelconque a un problème, toutes les données sont perdues. Ceci n'est donc utile que pour des données temporaires, ou très peu précieuses. L'avantage, c'est qu'on gagne en capacité et en vitesse de transfert (la capacité totale, comme la vitesse de transfert, est en gros celle de N disques).
• RAID1, qui est l'extrême inverse : la redondance est totale (k=N−1) : tous les disques contiennent une copie complète des données, ils sont miroirs les uns des autres. Même si tous les disques sauf un tombent en panne, les données sont sauves, puisque n'importe lequel permet de tout reconstituer.
• RAID5, qui est intermédiaire entre 0 et 1 (non, les numéros n'ont aucune logique, je suppose que c'est juste l'ordre d'introduction) : on a une redondance de k=1 disque. Autrement dit, RAID5 vous protège contre la panne d'un disque mais si deux disques tombent simultanément en panne, vos données sont perdues. En contrepartie, si vous avez N disques, vous avez la capacité de N−1 disques (et également un gain en vitesse, sur lequel je n'approfondis pas). Bien sûr, RAID5 n'a de sens que pour N≥3 disques (si on n'a que deux disques, soit on fait de la redondance et c'est du RAID1, soit on n'en fait pas et c'est du RAID0).
• RAID6, qui est aussi intermédiaire entre 0 et 1, mais plus proche du 1 que ne l'est le 5 : cette fois, on a une redondance de k=2 disques. Autrement dit, RAID5 vous protège contre la panne simultanée de deux disques (mais pas trois). En contrepartie, si vous avez N disques, vous avez la capacité de N−2 disques (et également un gain en vitesse, sur lequel je n'approfondis pas). Et RAID6 n'a de sens que pour N≥4 disques.

Lorsqu'on a 4 disques, toutes les possibilités sont représentées là : 0 disque de redondance pour RAID0, 1 pour RAID5, 2 pour RAID6 et 3 pour RAID1. (Je ne parle pas des autres niveaux de RAID, qui, à mon avis, ne sont pas très intéressants — par exemple le RAID10 est du RAID0 au-dessus de RAID1, qui entre 4 disques offre quelque part entre 1 et 2 disques de redondance vu qu'il peut subir la mort de 2 disques à condition que les 2 disques ne soient pas dans le même sous-tableau RAID1.)

En général, on ne choisit pas RAID1 entre un grand nombre de disques, ou, si on le fait, c'est pour des raisons différentes de la seule redondance (par exemple pour le fait que n'importe quel disque peut être lu pour trouver les données, ce qui peut être pratique lors du processus de démarrage). Certains peuvent se dire que RAID6, qui protège contre la panne simultanée de deux disques, est déjà un excès de précautions (quand un disque tombe en panne, on va le changer immédiatement, et il est peu vraisemblable qu'un autre disque tombe en panne pile à ce moment), mais c'est oublier que les pannes ne sont pas des événements indépendants : le même problème (un choc électrique ou mécanique, par exemple) peut causer la mort de plusieurs disques[#2], d'une part, et plus subtilement, l'utilisation du RAID lui-même peut causer la mort d'un disque (lorsqu'on remplace un disque dans un tableau RAID, il se produit une grande activité sur tout le tableau, qui peut accélérer la mort d'un disque) ; sans compter que si on a deux disques issus de la même série, ils peuvent avoir le même défaut de fabrication[#3]. Donc, deux disques de redondance, ce n'est pas forcément un luxe inutile.

Le RAID a aussi quelque chose de très agréable, c'est qu'il est complètement transparent. Si un disque fait une faute de lecture isolée, la couche RAID détecte la faute, lit les données à partir des autres disques, réécrit le secteur défectueux, ce qui cause sa réallocation par le firmware du disque (donc en pratique « la corrige »), et on ne voit qu'un léger délai. Si un disque meurt complètement, la couche RAID finit par se lasser, chasse le disque du tableau (qui devient alors dégradé), et tout continue à fonctionner, et quand vous achetez un nouveau disque pour le remplacer et que vous l'ajoutez au tableau, les données sont automatiquement copiées vers lui pour que le tableau cesse d'être dégradé. Pas besoin de s'embêter à retrouver où on a mis des copies de sauvegarde ou quoi que ce soit.

En contrepartie, RAID n'attrape pas tous les problèmes pour lesquels on fait des sauvegardes. Par exemple, si on efface un fichier malencontreusement, la couche RAID réplique l'effacement sur tous les disques, et ne vous protège pas du tout. Il existe des choses plus sophistiquées, comme des snapshots par copy-on-write (disponibles par exemple, sous Linux, dans BTRFS), mais cela, à son tour, ne vous protège pas contre des bugs du filesystem. Bref, il faut décider quelle assurance on veut, et contre quoi.

On a aussi parfois le choix entre le RAID logiciel ou matériel (c'est-à-dire que certaines cartes mères ou chipsets SATA sont capables de gérer le RAID de façon transparente et de ne présenter au système d'exploitation que l'apparence d'un seul disque). Mon choix est parfaitement clair, et c'est celui du RAID logiciel (celui de Linux : je ne suppose que Windows et Mac OS ont des choses semblables), qui est peut-être légèrement plus coûteux en ressources, mais qui m'offre beaucoup plus de finesse dans la gestion des choses, par exemple celle de convertir de RAID5 vers RAID6 (ou de lancer une vérification) sans passer des heures dans un outil du BIOS, et aussi la garantie que mes données sont stockées sur les disques dans un format connu et documenté, donc qu'elles ne vont pas devenir inaccessibles si ma carte mère meurt.

Comme je l'ai évoqué, il est possible de faire des conversions entre niveaux de RAID, ou entre nombres de disques. Ces conversions (de nouveau, sous Linux et en utilisant mdadm, je ne sais rien des autres OS) se font à chaud : le système continue de fonctionner normalement alors qu'on est en train de convertir, disons, un RAID5 entre 3 disques vers un RAID6 entre 4 disques (ce qui garde la même capacité, et ajoute un disque de redondance, mais nécessite de réorganiser toutes les données du tableau) ; les choses sont même prévues pour qu'on puisse interrompre l'opération et la reprendre plus tard (par contre, dans ce cas, le tableau cesse d'être disponible au moment où on interrompt). Enfin, ça c'est la théorie, parce que sur le noyau que j'utilise (un Linux 3.1.0-rc6[#4]), même si la conversion en elle-même se passe très bien, on ne peut pas dire que ça ne gêne pas le fonctionnement normal du système : j'ai des processus qui restent bloqués indéfiniment (et c'est probablement un bug, pas juste une attente disque devenue plus lente à cause de la conversion, parce que ça a l'air de toucher les processus un peu aléatoirement, et même quand on convertit des tableaux RAID absolument pas utiles au système ni utilisés par les processus qui bloquent). Enfin, ça reste utilisable, la preuve c'est que j'ai pu écrire tout ça sur la machine en question.

Moi je faisais du RAID5 entre 3 disques jusqu'à récemment, et comme j'ai vu qu'il y en a un qui commençait à montrer des faiblesses[#5] (ce qui, s'agissant de RAID5 veut dire qu'il faut le changer immédiatement), je me suis dit, plutôt que bêtement le remplacer, pourquoi ne pas ajouter un nouveau disque et faire du RAID6 sur 4 disques, et je virerai le disque qui faiblit quand il sera vraiment mort, pas au premier signe de faiblesse. En plus, ça me permet d'ajuster plus finement le niveau de RAID entre différentes partitions : il y en a pour lesquelles je reste à RAID5, mais sur 4 disques, pour gagner un peu de place, parce que ce sont des données vraiment peu importantes (un miroir Debian).

Et à part ça… c'est long… Mais qu'est-ce que c'est long ! La conversion du RAID5 sur N disques en RAID6 sur N+1 disques passe par un disque dur supplémentaire (il y a donc 5 disques impliqués dans l'affaire en ce qui me concerne, les détails sont là), vers lequel chacune des données du tableau doit être écrite, puis relue (ça va méchamment l'user, soit dit en passant — heureusement je m'en fous). Et ça se fait au rythme de 5.5Mo/s en moyenne. Et pour convertir 1To, au rythme de 5.5Mo/s, il faut… 50 heures. Voilà pourquoi, depuis maintenant une journée complète et sans doute pour encore aussi longtemps, j'ai 5 disques durs qui moulinent, qui moulinent, qui moulinent.

[#] En particulier, j'ai perdu des petits textes humoristiques que mon papa écrivait à mon sujet (c'est-à-dire, pour se foutre de moi), et qui s'appelaient The Adventures of Altcee : ça me fait de la peine, parce que j'aimerais bien les relire. Il semble qu'il en existe peut-être encore un exemplaire, mais il est sur une disquette 5″¼ et c'est devenu impossible de retrouver un lecteur 5″¼ de nos jours (ou en tout cas un lecteur 5″¼ dont on soit raisonnablement certain qu'il marche et qu'il ne risque pas d'endommager cette disquette si ce n'est pas déjà le cas !). [Ajout : elles ont maintenant été récupérées.]

[#2] J'ai un copain qui peut témoigner du risque lié au fait d'attacher les disques durs dans son boîtier avec des élastiques pour amortir les vibrations.

[#3] Raison pour laquelle j'essaie de faire des tableaux RAID entre disques de fabricants différents. Là, j'ai un Samsung, un Hitachi (le petit nouveau), un Seagate et un Western Digital.

[#4] Je n'aime pas utiliser des noyaux expérimentaux comme ça, mais en l'occurrence je n'avais pas le choix parce que j'étais coincé entre un bug USB des 2.6.38.x et un bug obscur dans le cache de routage dans les 3.0 qui cassait vraiment sérieusement ma config réseau, et pour lequel on ma donné un patch qui ne s'applique qu'au 3.1.

[#5] Dénonçons le coupable : c'est le Seagate. C'est un disque de 1To, et il en est à ~300 secteurs réalloués. Ceci dit, Western Digital mérite aussi un blâme dans l'histoire, pour des histoires expliquées ici par eux-mêmes (et dont l'explication technique détaillée est : ce sont des bouffons).

Encore un petit fignolage, après quoi j'espère arrêter pour un moment de faire du méta sur ce blog (parce que les blogs qui parlent d'eux-mêmes, je pense que ça n'intéresse pas tellement les gens[#] — mais il faut bien s'occuper de la technique de temps en temps).

Comme il y a manifestement une demande pour un feed de ce blog qui inclue les entrées complètes et formatées, et comme je suis résolument hostile au fait de mettre ça dans le fichier RSS — non pas, je répète, parce que je ne veux pas qu'un feed contienne les entrées complètes, mais simplement parce que le fichier qui contient les entrées complètes, c'est le fichier HTML lui-même, donc ce sont aux agrégateurs de se démerder avec pour le présenter comme un feed[#2] — j'ai ajouté des informations au microformat hAtom qui sont censées indiquer que la page est un feed, que chaque entrée est une entrée, quelle en est la date et heure de publication, le titre et le contenu (forcément complet, donc). Il paraît qu'il existe des agrégateurs qui savent effectivement en faire quelque chose : donc essayez l'adresse principale du blog (http://www.madore.org/~david/weblog/) comme flux dans votre agrégateur préféré (ou tout autre outil équivalent), et voyez si ça donne quelque chose. Je suis un peu sceptique, parce que le format hAtom est vraiment mal spécifié et mal documenté (et est d'interaction douteuse avec le HTML5 : j'ai utilisé time pour spécifier les heures[#3] vu qu'il est hors de question de pervertir abbr pour ça comme les microformats le préconisent), mais bon, ça peut difficilement faire du mal.

Bref, si quelqu'un voit une amélioration quelconque, qu'il me le fasse savoir, ça me surprendra agréablement. Si ça ne marche pas, inutile de le signaler : je m'en doutais. (Si ça casse quelque chose, dites-le, m'enfin ça m'étonnerait quand même beaucoup.)

[#] Ceci dit, c'est peut-être un concept, en fait, un blog qui ne parle que de lui-même, avec des entrées qui pourraient s'intituler critique de l'entrée précédente, ou apologie de cette entrée-ci. Douglas Hofstadter avait bien proposé de faire un livre intitulé Reviews of this book, dont le contenu serait entièrement constitué des critiques du livre (l'idée serait de demander aux critiques littéraires de faire un premier tour où ils critiqueraient l'idée, on concatène ça en un livre, on leur envoie et ils modifient leurs critiques, et on répète jusqu'à ce que, on l'espère, ça finisse par converger, auquel moment on publie le livre et chacun peut écrire sa critique). Et je serais assez tenté de le lire, ce livre, s'il paraissait (enfin, je commencerais peut-être par vérifier si les critiques sont bonnes ).

[#2] C'est une idée qui flotte depuis longtemps puisque Mark Pilgrim la discutait en 2002.

[#3] Malheureusement, la date (published ou updated) est justement le truc considéré comme indispensable dans hAtom. Donc si l'utilisation de la balise time perturbe, rien n'en ressortira ; heureusement, j'ai mis cette balise sur la date qui servait de toute façon de permalien, et comme la date est au format ISO valide (sauf pour cette unique entrée que je conserve fièrement et précieusement), au moins un outil ne comprenant pas la balise time a des chances de lire la date du post sans l'heure.

Certains observateurs attentifs ont peut-être remarqué l'apparition, dans le coin en bas à droite de certains entrées de ce blog (mais pas toutes, loin de là), juste au-dessus du lien vers les commentaires, d'une indication de catégories dans lesquelles l'entrée a été rangée (chaque mot étant un lien vers la page de la catégorie, et le point entre parenthèses un lien vers l'entrée elle-même dans sa catégorie). [Précision (2011-09-13T01:05+02:00) : On me souffle en commentaire que ce ne sont pas des catégories mais des tags que j'utilise, même si personnellement je considérais ces deux mots comme interchangeables. En tout cas, pour être bien clair, ma classification ne se limite pas à une seule catégorie par article.] C'est un des goodies rendu possible par mon nouveau moteur de blog : initialement, il n'y avait qu'une seule catégorie, mes fragments littéraires gratuits, maintenant il n'y a aucune difficulté à en créer d'autres (y compris pour mettre la même entrée dans plusieurs catégories).

Mais bon, reparcourir 1935 entrées pour décider de comment classer chacune, ça ne m'enchante pas trop, alors je fais les choses de façon un peu aléatoire, je rajoute les catégories au fur et à mesure que l'envie me vient et je récolte les entrées dedans au fur et à mesure que je retombe dessus — donc pour l'instant c'est un peu n'importe quoi. Sans compter que je ne sais pas exactement quelles frontières données au catégories (faut-il viser large ou précis ?), ni à partir de quel moment faire figurer une entrée dans une catégorie (par exemple quand une entrée évoque en passant un film, ça ne suffit certainement pas à la mettre dans la catégorie cinéma, alors que si c'est une critique de film certainement — mais entre les deux il y a beaucoup de place pour hésiter). Les entrées « en vrac » qui parlent de douze choses différentes sont spécialement problématique à ce compte-là. Et la catégorie des posts parlant de moi-même est particulièrement indéfinissable, parce que tous les posts parlent de moi dans une certaine mesure, je veux isoler ceux qui parlent le plus de moi, et je ne sais pas où mettre la limite (celui-ci, par exemple, raconte-t-il ma vie ?).

J'ai tout de même taggué pour l'instant : 12 entrées sur le droit, 15 sur la religion, 19 sur la philo, 23 sur les langues ou la linguistique, 24 sur la physique, 25 sur les technologies Web, 26 sur Unicode, 48 sur la politique, 94 sur les films et le cinéma, 101 sur l'homosexualité ou les thèmes gay, 106 sur les maths, les 138 fragments littéraires gratuits, et enfin 310 posts parlant de moi. Ces derniers sont problématiques à plusieurs titres, à la fois parce que comme je le disais je ne sais pas trop quoi mettre dedans, et aussi parce que ça fait une page trop grande. (Pour comparaison, les pages mensuelles varient entre 2 entrées pour septembre 2008 et 79 pour août 2003, avec une moyenne à 19.)

Il faut encore que je crée plein de catégories relatives à l'informatique, mais je ne sais pas comment les grouper. Et certainement une catégorie livres ou littérature, mais je ne sais pas laquelle vaut mieux.

J'avais évoqué le Web sémantique le mois dernier, je reviens un peu sur le sujet puisque je suis maintenant entré dans le monde merveilleux de HTML5.

Qu'est-ce que le Web sémantique ?

L'idée du Web sémantique, expliquée à un enfant de cinq ans (bon, OK, peut-être douze), pourrait être exposée comme ceci. Les ordinateurs ne sont pas très malins, ils ne savent pas comprendre le français (ou l'anglais, ou le chinois…), et en particulier, les moteurs de recherche ne comprennent rien du tout des pages Web qu'ils indicent : ils ne voient qu'un tas de liens qui pointent vers d'autres pages Web, séparées par du texte qui pourrait aussi bien être en cunéiforme. Ça ne les empêche pas de donner de bons résultats avec de la simple recherche dans du texte, mais parfois on aimerait bien qu'ils comprissent ce qu'ils reçoivent : ça permettrait de faire des recherches plus sophistiquées (par exemple : trouve-moi une recette de cuisine de gâteau facile à préparer en moins de 40′ — si on recherche les mots-clés les plus évidents, on peut encore s'en sortir pour les mots recette, gâteau, facile, mais le moins de 40′ à peu de chances d'apparaître comme ça dans la page, et inversement on peut tomber sur une page qui raconte j'ai réparé mon ordinateur en moins de 40′, c'était vraiment facile de changer le disque dur, la bidouille c'est du gâteau et je vais vous donner la recette de comment je m'y suis pris). D'où l'idée d'inventer un langage permettant de communiquer des informations simples d'une manière compréhensible par un moteur de recherche : non pas d'écrire une page Web séparée dans un langage adressé aux ordinateurs, mais d'annoter une page Web destinée aux humains pour permettre aux ordinateurs de s'y retrouver un peu, et de savoir vaguement de quoi ça parle.

Il n'est pas question de traduire tout le texte en langage machine, ni que ça s'applique à des concepts subtils, mais uniquement de faciliter la digestion d'informations factuelles simples qui pourraient figurer dans une base de données. Par exemple, expliquer que ceci est un blog, que le lien en haut à gauche est un permalien, que l'avant-dernière entrée est la critique d'un film (que les mots Habemus papam sont le titre de ce film, et Nanni Moretti le nom du réalisateur, et que la critique dans son ensemble pourrait se résumer par telle note). Un commerçant en ligne pourrait indiquer qu'il s'agit d'un commerçant en ligne, spécialisé dans tel type de choses, et s'il a des locaux dans le monde physique, à quel endroit ils sont, quelles en sont les horaires d'ouverture, etc. De cette manière, quelqu'un qui chercherait sur Google Maps tel type de commerce pourrait voir ce résultat apparaître.

C'est une bien jolie idée, il n'est pas sûr que ça puisse marcher. Par exemple parce que dès lors que les moteurs de recherche et les humains ne lisent pas exactement la même chose, quelqu'un peut avoir intérêt à chercher à tricher, à présenter une information dans le texte en français et une autre, contradictoire, dans le Web sémantique, parce que c'est la première qui l'engage et la seconde qui aide à le trouver, donc il pourrait afficher des prix faux pour ses articles. Ou quelque chose comme ça. D'un autre côté, il est déjà possible de faire à des fins douteuses des sites Web qui apparaissent différemment à Google et à un humain (mais si Google l'apprend ils vous punissent, et il y a des mécanismes pour signaler ce genre de tromperies). Il n'est pas non plus clair que ce soit si rentable (si quelqu'un est venu vous voir en cherchant le produit X et que vous ne l'avez pas, vous pouvez y gagner en vendant le produit Y à la place, mais vous pouvez aussi l'énerver beaucoup). Enfin, si les navigateurs évoluent eux aussi pour comprendre le Web sémantique et le présenter aux utilisateurs, ça permettra de démasquer ce genre de tromperie. Bref, pour l'instant, tout ceci est assez théorique — mais la question se pose en tout cas de savoir qui doit faire confiance à qui pour dire quoi sur quoi.

[Lire la suite…]

Puisque tout le monde a l'air de jouer à ce petit jeu, voici ma contribution à qu'est-ce que j'ai pensé le 11 septembre 2001. J'ai écrit le texte suivant 2001-09-11T22:54:36Z :

Comme je disais ailleurs, on est touché par de petites choses idiotes. Des milliers de victimes, j'ai beau l'entendre, j'ai beau condamner de toute la force de mon esprit, ça ne fait pas venir des larmes. Penser que les Twin Towers n'existent plus, ça me fait un choc énorme. Pourtant, ce n'était pas une oeuvre d'art précieuse (quoique mon père en dise :-). Et de plus je ne les ai jamais vues en vrai.

De même, les milliers de victimes, elles sont abstraites. Mais quand on voit certaines images de gens prisonniers dans la tour juste avant qu'elle s'effondre, ça devient nettement plus concret, et là, ça émeut vraiment.

Dire, c'est le plus gigantesque acte de terrorisme de tous les temps, c'est vague, ça ne me frappe pas tant. Entendre égrener la liste de tous les chefs d'État qui condamnent l'attentat et qui offrent leurs condoléances au peuple américain, curieusement, ça me rend la chose nettement plus palpable.

L'émotion est quelque chose d'étrange. Je pense que Douglas Adams, dans le premier tome du HHGG […] décrit quelque chose de très intéressant dans ce que ressent Arthur Dent après la destruction de la Terre.

Tu dis que c'est la première fois que tu as les larmes aux yeux pour un événement qui te touche aussi peu directement. Ce n'est pas mon cas (pour ce qui est de « la première fois »). Oscar Wilde, en réponse à la question de quel était l'événement le plus tragique de sa vie, avait répondu, la mort d'Emma Bovary. Il y a quelque chose de profond là-dessous. Je suis très ému par ce qui s'est passé, certainement, et pourtant, il m'est arrivé d'être plus ému par des choses entièrement fictives (tel livre ou tel film), ou infiniment moins graves. Finalement, ce qui m'émeut, ce n'est pas la catastrophe en elle-même, c'est la façon dont elle m'est présentée.

C'est comme ça que la douleur du déchirement survient. On est touché par une perte, une rupture, une disparition. Les Twin Towers étaient un Monument de la civilisation humaine. Un symbole. Il a disparu. Qu'est-ce que ces milliers de victimes ? Elles n'ont pas de visage pour moi. Je ne les ai jamais connues (sauf si j'apprends après coup que je connaissais telle ou telle personne qui a péri dans le désastre). Je ne perds rien en elles. Depuis l'attentat, plus de personnes sont mortes dans le monde pour d'autres raisons qu'il n'en est mort dans cet attentat. Gouttes d'eau dans la mer. Mais parmi ces personnes mortes, soudain, une image me montre un visage. Un point insignifiant, mais auquel on s'attache immédiatement parce qu'on *ne voudrait pas être à sa place*. Et la mort de ce visage donne soudainement une ampleur humaine à la tragédie. Malgré cela, l'ensemble n'attriste pas plus que la mort d'un personnage de fiction que l'auteur a pris le soin méticuleux et cruel de vous rendre attachant.

L'avion qui s'est écrasé sur le pentagone ne m'a fait, lui, aucun effet. S'il avait détruit le capitole ou le monument à Lincoln, même sans faire la moindre victime, ça m'aurait énormément choqué.

Oui, décidément, l'émotion est quelque chose d'étrange.

Voir aussi ce que j'écrivais deux ans après, dans la même veine.

Je suis allé voir le film Habemus papam de Nanni Moretti, l'histoire d'un pape nouvellement élu et récalcitrant, et j'en ressors avec une impression partagée. Dans l'ensemble j'ai bien aimé l'ambiance de cette comédie rafraîchissante et assez attendrissante. Le collège des cardinaux est présenté comme une bande de vieillards un peu enfantins et finalement bien sympathiques, et le personnage joué par le réalisateur (un psychanalyste) est vraiment excellent. La scène où le pape croise des gardes suisses en exercice dans les jardins mérite aussi qu'on voie le film. En revanche, la chute m'a gravement déçu : on a eu l'impression que pour éviter à tout prix la fin que le spectateur attendait et voyait venir (cliquez ici pour dévoiler : je m'attendais à ce que l'acteur qui joue Konstantin Treplëv dans La Mouette déclare forfait juste au moment de monter sur scène de la même façon que Melville (le pape) l'a fait avait d'être présenté à la foule, que le pape le remplace in extremis, que jouer ce rôle lui donne le courage de revenir de lui-même au Vatican, et qu'il fasse un discours fort drôle dans lequel la troupe d'acteurs l'aurait reconnu, et qui aurait finalement donné raison à la bonne humeur du collège des cardinaux), le réalisateur a choisi un dénouement différent, plus grave, peut-être plus tchékhovien mais à mon avis en décalage avec le reste du film. Au final, je ne sais pas si je dois recommander.

Voici qui me donne l'occasion entre autres de vérifier que je n'ai pas cassé le système qui produit la version PDF de mes fragments, et que le système de catégories de mon nouveau moteur de blog fonctionne.

Comme on vit dans un Univers où il est impossible de rien inventer, je suppose que l'idée que j'expose ci-dessous a déjà été exploitée, soit dans la réalité (les anthropologues nous apprennent qu'il y a plus de choses sur terre qu'il n'en est rêvé dans notre philosophie), soit dans une œuvre de fiction dont je suis sûr qu'un commentateur va me sortir l'auteur. Quoi qu'il en soit, je me suis amusé à écrire ceci :

Mais la caractéristique la plus frappante des Qriqrx, et celle qui leur a valu leur célébrité, est assurément leur conception de la vie et de l'immortalité. Les Qriqrx se disent éternels parce qu'ils pratiquent la réincarnation. Il n'est pas suffisant d'affirmer qu'ils croient à la réincarnation, à la façon des hindous : ils la pratiquent activement, c'est-à-dire que, pour les Qriqrx, il ne s'agit pas d'une loi cosmique plus ou moins métaphysique mais d'une invention humaine tangible, par laquelle la mort a été vaincue.

La réincarnation est choisie, c'est-à-dire qu'au moment de l'adolescence (soit vers l'âge de 15 ans), le jeune Qriqrx se voit attribué par les sages, de concert avec la famille de l'intéressé, en tenant compte de la personnalité de ce dernier, un mort en « attente de réincarnation ». L'adolescent va passer trois ans à découvrir et à devenir celui qu'il sera, pour finalement le réincarner formellement lors d'une cérémonie de passage à l'âge adulte — ou plutôt une cérémonie de passage à l'immortalité, au cours de laquelle il reçoit son nom éternel.

Le réincarneur est considéré comme en tout point le même individu que le réincarné : il reçoit tout de lui — biens et dettes, amis, statut social, conjoint. Le lien avec son enfance n'est pas pour autant coupé : le nom d'enfance, ou nom éphémère, qui identifie la réincarnation de l'individu, est accolé au nom éternel, et les deux existences (celle, infinie, de l'éternel qui se réincarne et celle, brève, de l'adolescent qui le devient) sont considérées comme s'ajoutant l'une à l'autre. Les parents du réincarneur sont vus comme des alliés, mais comme des alliés parmi d'autres, puisque le Qriqrx éternel s'allie à des parents à chaque fois qu'il se réincarne, et il garde normalement des contacts avec six ou sept successions de parents (et, symétriquement, d'enfants). La relation de parent, ou d'ancien parent, à enfant adulte est une relation d'égal à égal, puisque l'âge n'a pas de sens entre individus éternels. On acquiert de nouveaux parents comme on acquiert de nouveaux enfants, et il est considéré comme un honneur d'être le père ou la mère d'un héros ou d'un sage. Il n'est pas particulièrement surprenant de devenir, par exemple, le père de son père (c'est-à-dire, qu'un individu se réincarne dans son petit-fils).

Le réincarné peut être mort postérieurement à la naissance du réincarneur (mais toujours avant l'âge de 15 ans de ce dernier) : les Qriqrx n'y voient pas de paradoxe ; il arrive même, quoique cela soit inhabituel, qu'un mourant choisisse lui-même un enfant dans lequel se réincarner (ce choix n'est cependant pas forcément accepté par les sages). Une femme peut se réincarner en homme et vice versa : le sexe, comme l'âge, est envisagé comme une propriété éphémère de l'individu ; le tempérament, au contraire, est essentiel, et il importe que ceux du réincarneur et du réincarné soient aussi compatibles que possible.

La tribu prend collectivement garde que sa population ne varie pas trop. Si elle diminue, cela signifie que la liste des morts en attente de réincarnation s'allonge : cela est gênant, car ces personnes sont alors absentes, leur fonction sociale vacante et leurs biens séquestrés (même si une gérance ou un usufruit temporaire peut en être attribué). À l'inverse, si la population augmente, cela signifie qu'il faut attendre plus longtemps avant de pouvoir devenir éternel. Les Qriqrx qui meurent avant d'avoir atteint l'âge adulte sont considérés comme des existences imparfaites ou des « faux réveils » : si un réincarné avait déjà été attribué, alors il s'agit d'une existence imparfaite de ce Qriqrx éternel connu, tandis que pour un enfant plus jeune on ignore jusqu'au nom de celui dont il est existence imparfaite.

On l'a signalé, la réincarnation n'est pas pour les Qriqrx une opération de magie ou une croyance religieuse : il s'agit d'un acte social, comme le mariage ou le divorce. Le réincarneur a pour mission de devenir celui qu'il réincarne, mission qu'il accomplit en apprenant tout ce qu'il le peut de celui qu'il va devenir, notamment en conversant avec son conjoint (qui sera le sien), ses amis, ses enfants, ses parents et anciens parents (qui souvent ont eux-mêmes été réincarnés), en apprenant son métier, en se familiarisant avec ses biens, etc.

Le résultat de cette organisation est que la mort est vue comme une période d'absence, assurément désagréable, mais néanmoins temporaire, et qui ne fait pas obstacle à ce qu'on puisse prendre des engagements pour l'avenir. Le Qriqrx a la certitude qu'il sera là dans cent ans, dans mille ans et au-delà, et même s'il finira par oublier son existence présente, il sait qu'il s'inscrit dans une chaîne infinie de réincarnations qui forment le même individu éternel. À l'inverse, notre culture lui semble incompréhensible, dans laquelle nous laissons les individus vivre sans passé et mourir définitivement.

Ajout : voir cette entrée ultérieure pour une sorte d'analyse.

Mon poussinet est un geek de trains (enfin, pas que de ça, mais entre autres de ça) : en deux ans — depuis qu'il a commencé sa thèse à Bordeaux — il a fait en train pas loin de la distance de la Terre à la Lune, et il aimerait travailler un jour pour la SNCF. Entre autres choses, il s'est donné pour mission de comprendre en profondeur comment fonctionne le système de tarification des trains français. Et il aime aussi raconter ce qu'il comprend : ça peut rendre service, mais le moment où il raconte les choses n'est pas forcément le moment où on en a besoin. Alors je l'ai tanné pour qu'il ouvre lui aussi un blog. Je vous présente donc :
(roulement de tambour)

le blog du poussinet

où vous apprendrez tout ce que vous avez toujours voulu savoir sur le prix des billets et que vous n'avez jamais osé demander. (Au moment où j'écris, il y a deux entrées : je n'ai pas voulu signaler le blog tout de suite, parce qu'un blog vide, ça ne donne pas trop envie.) L'avantage pour moi, c'est que maintenant quand il commence à me parler de la réduction sur la classe de contingent truc pour la carte chose, je peux lui dire : raconte ça sur ton blog.

Comme le passage à HTML5, évoqué dans l'entrée précédente pose le problème de la compatibilité des navigateurs, j'ai voulu essayer de savoir ce qu'utilisent mes lecteurs.

Problème : ce n'est pas évident du tout. D'abord parce que mon serveur Web est pollué de zillions de requêtes dont très peu, finalement, concernent vraiment le contenu réel : il y a les gens qui viennent depuis les moteurs de recherche (et dont l'écrasante majorité ne doit pas trouver ce qu'ils cherchaient, ou trouvent des choses idiotes : la page la plus populaire de mon site, et de très loin est celle-ci via Google images, ce ne sont pas des gens intéressés par moi ou par ce que je raconte), il y a les moteurs de recherche eux-mêmes et toute la jungle des robots butineurs, et il y a les agrégateurs… Une même personne peut revenir très souvent et plein de personnes peuvent se cacher derrière la même IP. Bref, c'est compliqué.

J'ai opté pour la méthodologie suivante : j'ai pris l'ensemble des requêtes depuis le 28 août, j'ai sélectionné uniquement celles qui demandaient une URL sous /~david/weblog/, puis j'ai trié par couple IP+UA (où UA désigne l'User-Agent, c'est-à-dire l'identifiant du navigateur tel qu'il est renvoyé par le navigateur). Je n'ai gardé que les couples IP+UA ayant fait au moins 5 requêtes dans la période (façon de m'assurer que ce sont de « vrais » lecteurs et pas des gens tombés là par hasard) : on peut appeler un tel couple IP+UA un « lecteur », même si bien entendu cela ne correspond pas forcément à une personne physique (par exemple parce que quelqu'un peut utiliser régulièrement deux navigateurs différents, ou deux ordinateurs différents, auquel cas il apparaît deux fois, et bien sûr parce qu'il y a encore des robots dans le tas). À ce stade-là, il restait 575 lecteurs. (Je jette le nombre de requêtes de chacun, qui ne m'intéresse pas.) Sur ces 575 lecteurs, j'ai essayé d'identifier (de façon semi-manuelle) tous les navigateurs habituels, en jetant tout ce qui est robot ou agrégateur (ou, en fait, tout ce que je ne comprenais pas) : il me reste 323 entrées, qui se répartissent de la façon suivante : [#]

118	Firefox 6.0
49	Firefox 3.6
32	Chrome 13.0
17	Firefox 5.0
11	MSIE 8.0
11	Firefox 9.0a1
10	Opera 9.80
8	Safari 5.0
7	Safari 5.1
7	MSIE 7.0
7	MSIE 6.0
7	Firefox 4.0
7	Firefox 3.5
5	MSIE 9.0
5	Firefox 7.0
5	Firefox 3.0
3	Safari 4.0
3	Chrome 12.0
2	Chrome 14.0
1	w3m 0.5.2
1	Safari 4.1
1	Safari 3.0
1	Firefox 2.0
1	Firefox 1.5
1	Chrome 9.0
1	Chrome 7.0
1	Chrome 15.0
1	Android 2.3

Bon, je ne peux qu'insister sur le fait que ça ne veut pas dire grand-chose (par exemple, les 11 « lecteurs » utilisant Firefox 9.0, c'est plutôt une personne qui a changé 11 fois de version), mais ça donne quand même une idée : très grossièrement 68% de mon lectorat qui ne passe pas par un agrégateur utilise Firefox, 12% utilise Chrome (ou Chromium), 9% IE, 6% Safari et 3% Opera. Le navigateur le plus susceptible de poser problème est MSIE ≤8, et j'aimerais savoir s'il arrive encore à afficher mon site (je ne parle évidemment pas de comprendre le SVG ou le MathML, mais juste d'afficher quelque chose de vaguement lisible).

[#] Je profite de cette table pour pousser une gueulante : avec tout ce que le HTML a inventé, et tout ce que le CSS permet de faire, il reste excessivement pénible de fixer l'alignement d'une colonne d'un tableau (par exemple, comme je voudrais le faire ici, aligner sur la droite les chiffres de la première colonne). Le HTML5 a supprimé l'attribut align qui était la façon évidente de faire ça en HTML4, en reléguant la fonction à CSS, mais justement CSS n'offre pas vraiment de mécanisme qui convienne. Naïvement on pourrait penser qu'ajouter un <col style="text-align: right" /> fonctionnerait, mais comme Ian Hickson l'explique, ce n'est pas le cas, parce que les propriétés CSS des colonnes ne servent que pour un très très petit nombre de trucs, et il y a des raisons à ça (je trouve que ces raisons assez peu convaincantes, d'ailleurs, mais je ne vais pas entrer dans les détails). On peut toujours faire un truc comme #maTable td:nth-child(n) { text-align: right } [#2], mais ce n'est pas vraiment une réponse, parce que les cellules d'une table peuvent faire plusieurs colonnes de largeur, donc il n'y a pas moyen de sélectionner à coup sûr les cellules de la colonne n avec un truc aussi simple que nth-child… du coup, la seule solution est de styler chaque cellule individuellement (ce qui ne répond pas à la question : on ne fixe pas l'alignement de la colonne, on fixe l'alignement de chaque cellule de la colonne). En guise de protestation, je laisse le tableau non aligné.

[#2] Par contre, j'e profiter de ça pour évoquer quelque chose d'autre : ma très grande satisfaction à découvrir que le HTML5 a introduit l'attribut scoped sur l'élément style, qui permet d'ajouter des règles de style sur un élément et tous ses descendants. En effet, en HTML4, on pouvait déjà mettre des attributs style sur un élément pour définir des règles qui s'appliquent à lui, mais si on voulait mettre une règle sur ses descendants, on était obligé de passer par la stylesheet globale : pas moyen d'écrire par exemple <table style="THIS td:first-child { text-align: right }">…</table> pour que tous les premiers td contenus dans la table soient alignés à droite : on devait soit mettre l'attribut style séparément sur chaque balise td de la table, soit donner à la table un id ou une classe (ce qui n'est pas problématique en soi) et insérer la règle de style à un tout autre endroit (ce qui, en revanche, est sérieusement merdique quand on songe que le bout de HTML en question pourrait être, par exemple, transcopié dans un autre document, par exemple par un agrégateur, qui peut reproduire l'arbre DOM mais pas chasser et interpréter les règles de style). En HTML5, on peut écrire : <table><style>td:first-child { text-align: right }</style>…</table>. Cela faisait des années que je me disais que cette possibilité manquait !

On va encore me reprocher de faire des annonces techniques qui n'ont aucune conséquence perceptible (mais bon, quand je parle d'autre chose, l'électro-encéphalogramme des commentaires enregistre un calme plat, alors que voulez-vous ?) : je viens de passer ce blog (et toutes les pages de ce site gérées par le même moteur) en HTML5[#]. C'est encore mal dégrossi, mais j'ai essayé de mettre les balises sémantiques comme article, header, footer, nav là où elles s'imposaient. Sur les navigateurs modernes, cela ne devrait faire aucune différence visible. Il y a peut-être un espoir que Google soit moins désorienté dans l'indexation, mais je n'y crois pas trop[#2].

En revanche, ce qui est bien est que je peux maintenant, enfin, librement inclure du SVG et du MathML dans mon blog. Et pour que mon annonce ne soit pas complètement creuse, donc, voici à gauche une étoile à sept branches en SVG (donc si vous ne voyez pas d'étoile à sept branches, c'est que votre navigateur n'est pas assez récent), et voici une formule en MathML permettant de montrer que l'étoile en question est constructible par origami :

$$e^{\frac{2i\pi }{7}}=\frac{1}{6}\left(-1+\sqrt{-7}+\sqrt[3]{\frac{7}{2}+\frac{21\sqrt{-3}}{2}}+\sqrt[3]{\frac{7}{2}-\frac{21\sqrt{-3}}{2}}+\sqrt[6]{-\frac{497}{2}+\frac{273\sqrt{-3}}{2}}-\sqrt[6]{-\frac{497}{2}-\frac{273\sqrt{-3}}{2}}\right)$$

(La démonstration de la formule est laissée en exercice au lecteur. Je ne sais pas ce que j'ai trouvé le plus pénible dans l'histoire, d'ailleurs, entre la calculer et la taper en MathML.) Si vous voyez juste quelques nombres éparpillés mais pas de fraction ou de racine, même conclusion que pour le SVG : votre navigateur est trop vieux ou mauvais (et je note avec déception que, chez moi, aussi bien Chrome qu'Opera sont incapables d'afficher le MathML — ce qui est d'autant plus bizarre, s'agissant de Chrome, que WebKit est censé avoir au moins une implémentation partielle de MathML).

[#] Techniquement, et pour répondre à la première de mes questions techniques de l'autre jour, en polyglotte HTML5/XHTML5. J'ai validé un certain nombre de pages (certes pas toutes) contre le validateur expérimental, ce qui m'a d'ailleurs fait trouver un bug dedans (dû à la façon dont Java saucisonne l'Unicode en UTF-16 ; c'est assez ironique, parce que l'auteur de ce validateur écrit en faisant l'éloge de Java's notion of Unicode frozen as UTF-16 from to dawn of time until eternity).

[#2] En revanche, et cela devrait répondre du même coup à la deuxième de mes questions techniques de l'autre jour, si j'adopte, et je vais envisager de le faire, le microformat hAtom, j'ai bon espoir que cela permette de vraiment définir la limite des entrées et aux agrégateurs de fournir un contenu complet.

Je suppose que beaucoup de mes lecteurs, surtout ceux qui n'ont pas la chance d'être soit Allemands soit homosexuels , ne doivent pas connaître Ralf König. Il est un dessinateur et scénariste de bédés allemand (vivant à Cologne, mais je ne l'ai pas croisé dans la rue la semaine dernière), dont les albums, au début surtout adressées au lectorat gay (par exemple sa série Conrad & Paul, qui met en scène un couple de garçons colognais, Conrad, le grand, un prof de piano gentil et plutôt coincé, et Paul, le petit, l'alter ego du dessinateur, qui couche avec tout ce qui bouge et fantasme sur les mecs musclés et poilus, tout le contraire de Conrad, ce qui ne l'empêche pas de l'aimer quand même), mais qui devient de plus en plus mainstream, met en scène et s'adresse maintenant aussi aux hétéros (notamment Comme des lapins, qui évoque pour une fois les problèmes de couples hétéros), et s'est peut-être un peu assagi du même coup.

Toutes ses bédés (dont je commence à avoir fait le tour) ne se valent pas, mais, globalement, j'adore. Il a un génie à la fois pour le dessin et pour le théâtre : pour ce qui est du dessin, une petite recherche sur Google images devrait donner une idée du style, qui n'est pas exactement soigné, mais il a un vrai talent pour croquer les émotions (l'étonnement, la concupiscence, l'esprit vide, la gêne… ceci dit, ce qu'il a fait de mieux dans ce domaine c'est peut-être Roy & Al, où les héros éponymes sont deux chiens) ; et pour ce qui est de l'intrigue, je trouve que ça tient souvent de Marivaux : les personnages se mettent dans des situations inextricables qui conduisent à des quiproquos hilarants. Il y a pas mal d'humour cru, mais aussi beaucoup d'allusions sophistiqués, et on voit que l'auteur est très cultivé. Certains de ses albums sont vaguement des parodies d'œuvres célèbres : il a notamment écrit un Lysistrata d'après Aristophane (que je n'ai pas lu), Jago dont je vais parler ci-dessous, Djinn Djinn qui fait référence aux Mille et Une Nuits (et aussi aux cadeaux offerts par Hārūn al-Rashīd à Charlemagne, rien que ce passage-là est génial), ou encore trois livres sur la bible (Prototyp, Archetyp et Antityp, non encore traduits en français, sur Adam, Noé et Jésus — j'ai lu les deux premiers et je dois avouer qu'à part Dieu et le Serpent qui sont vraiment excellents, le reste est un petit peu décevant).

Au début je lisais Ralf König en français (il faut dire que les traductions françaises sont très bien faites), puis je me suis rendu compte qu'il ne me fallait pas tant d'effort que ça pour pouvoir le lire en allemand ; en plus, ça m'apprend pas mal de vocabulaire peu conventionnel et rigolo (et potentiellement utile, qui sait ?) : schwul (homo), die Schwuchtel (la pédale, dont on peut tirer un verbe, schwuchteln), die Tunte (la tantouze), die Sau (la truie → le bâtard ; voire, Drecksau), Kuchelsex (les câlins), knutschen (se peloter), ficken (to fuck), reinrammen (to ram into : faire pénétrer bien profondément), geil (bandant, sexy, chaud ; par exemple : geile Sau), der Schwanz (la queue), die Funz (le fond, le fion), das Gleitgel (le gel lubrifiant), die Klappe (les toilettes dans lesquelles on baise, terme assez spécifique apparemment, d'ailleurs les hétéros allemands n'ont pas l'air de comprendre ce qu'est un glory hole)… Bref, toutes sortes de mots que mes profs d'allemand ne m'ont jamais appris au lycée !

Le dernier livre que j'ai lu de lui, c'est Iago (Jago en allemand), qui, comme on s'en doute, est une parodie de Shakespeare — un mélange d'Othello, de Macbeth, de Hamlet, du Songe d'une nuit d'été, de Roméo et Juliette et de Vénus et Adonis, un peu à la façon du film Shakespeare in Love (que je recommande d'ailleurs aussi très vivement au passage). Ça se passe à Londres du vivant de Shakespeare (qui est présenté comme un soûlard qu'on retrouve régulièrement bourré, la nuit, en train de pisser aux pieux sur lesquels on plante des têtes coupées), d'ailleurs précisément en 1603, la troupe de Burbage joue Hamlet et les acteurs en coulisse discutent de la beauté du bourreau (celui qui coupe les têtes qu'on plante en haut des pieux) ; l'acteur qui interprète Horatio est un petit bonhomme mal rasé et attiré par les mecs musclés et poilus (bizarrement, il y a toujours dans les bédés de Ralf König un petit bonhomme mal rasé et attiré par les mecs musclés et poilus, on se demande pourquoi), et voilà que débarque un Maure musclé et poilu qui va susciter la jalousie entre cet acteur et son collègue qui joue Ophelia (les femmes au théâtre étaient, à l'époque shakespearienne, jouées par des hommes), folasse blonde qui s'habille en Galvin Klyne et auquel trois sorcières vont faire des prophéties de gloire… à partir de là, ça se complique énormément. La bédé fait neuf actes, rythmés par plein de citations de Shakespeare qu'on peut jouer à reconnaître (comme dans Shakespeare in Love, mais je trouve ça plus difficile quand les citations sont en allemand que quand elles sont en VO), la solution est donnée à la fin. Bref, j'ai particulièrement aimé, alors je recommande ! — à la fois aux amateurs de Shakespeare et à ceux qui veulent pratiquer leur allemand.

Maintenant que mon nouveau moteur de blog me permet de faire des changements techniques sur ce blog (c'est-à-dire, en fait, de faire joujou), encore faut-il savoir quels changements je voudrais/devrais/pourrais faire. Voici certaines des questions que je me pose, et sur lesquelles certains de mes lecteurs ont peut-être un avis.

Première question, comment servir du contenu XHTML ? Il faut savoir que le XHTML, qui, comme son nom le suggère, est la version XML du HTML, peut en gros être servi de deux façons différentes : comme du HTML (c'est-à-dire, sous le type MIME text/html) ou comme du XML (c'est-à-dire, sous le type MIME application/xhtml+xml). Dans le premier cas (ce que je fais actuellement), bien que le contenu soit réputé être du XML bien-formé, il n'est pas analysé comme tel, mais comme une « soupe de tags » (par exemple, si une balise ouverte n'était jamais fermée, cela ne provoquerait pas une erreur fatale), autrement dit, on ignore qu'il s'agit de XML. Certaines mesures de compatibilité doivent alors être prises pour permettre au contenu d'être analysé de la même façon par un parseur « soupe de tags » que par un parseur XML (par exemple, si on doit pour une raison ou une autre créer un élément div vide, par exemple pour lui donner des attributs de style, il faut l'écrire sous la forme <div style="clear: both"></div> et pas <div style="clear: both"/> comme le XML permettrait mais ce qui confuserait les parseurs « soupe de tags » qui y verraient une balise ouvrante jamais refermée). Actuellement, je fais toutes sortes d'efforts dans ce sens, ce qui a d'ailleurs pas mal compliqué la tâche de l'écriture du moteur de blog (parce que bien que ces mesures de compatibilité soient recommandées par le W3C, personne ne semble avoir écrit de code spécifique pour produire du XHTML en en tenant compte). À l'inverse, servir du XHTML comme du XML présente différents avantages, notamment le fait de pouvoir y mélanger différents autres standards XML, comme le SVG ou le MathML. Mais au moment où j'ai écrit le précédent moteur de ce blog, cette possibilité était mal supportée : certains navigateurs ne comprenaient pas du tout le XHTML présenté sous le type MIME application/xhtml+xml, et même ceux qui le supportaient ne le géraient pas toujours très bien, par exemple Firefox ne faisait pas de rendu incrémental (il devait attendre que toute la page soit chargée avant de commencer à afficher quoi que ce soit). Probablement, de ce point de vue-là, la situation s'est améliorée, et je suppose que le seul navigateur qui gère encore imparfaitement le XHTML servi comme XML est IE dans ses anciennes versions (et même si je ne veux pas envoyer paître les gens qui utilisent encore ça, je peux toujours servir les pages avec un type MIME différent pour ce navigateur).

Mais la question du type MIME n'est pas tout. Même si je sers le XHTML comme du XML, il se pose la question de savoir si je déclare une DTD, et si oui, laquelle. Actuellement, je déclare <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">, autrement dit je promets du XHTML 1.0 strict, je fais les efforts nécessaires pour que ç'en soit, et je valide effectivement mes pages contre cette DTD. Seulement, de nos jours où la multiplication des standards du Web a beaucoup compliqué le jeu de tags qui peuvent apparaître dans un document, les DTD sont un mécanisme de validation plus ou moins obsolète : on préfère des choses plus flexibles et basées sur du XML pur, comme RelaxNG ou XSD (je n'y connais rien, donc je ne sais pas ce qui exite vraiment dans l'un ou l'autre pour valider du XHTML moderne, mais je n'ai pas de doute qu'il y ait des possibilités dans cette direction). Notamment, il n'a été que très difficilement possible de produire une DTD pour la combinaison XHTML+MathML+SVG, et cela représentera probablement la culminaison des efforts dans cette direction. Seulement, ne pas déclarer de DOCTYPE du tout va faire (si le document est servi avec type text/html) que des navigateurs Web tomberont dans un mode spécial « quirks », où ils ne gèrent pas le CSS correctement. La meilleure solution est sans doute de commencer les documents par <!DOCTYPE html>, comme le préconise le HTML5.

Voilà justement un autre sujet, le HTML5 : comme le XHTML2 a été maintenant officiellement abandonné, on doit bien admettre que le HTML5 est le standard moderne. Mais il ne facilite pas forcément les questions précédentes. Notamment, il se pose toujours la question de savoir si, et comment, on peut fabriquer des documents qui soient du HTML5 valide à la fois quand ils sont interprétés en mode « soupe de tags » text/html (qui cette fois est une soupe de tags normalisée, donc plus si soupesque que ça) et en mode XML (c'est-à-dire XHTML). Or si je veux produire et manipuler mon document avec des outils XML (ce que je veux), et quand même le rendre lisible aussi largement que possible, c'est bien ce que je dois faire. Cette page de FAQ, au demeurant très intéressante, fait une réponse inquiétante : It is possible to construct documents that are valid HTML5 when labeled as text/html and valid XHTML5 when labeled as application/xhtml+xml. Doing so is much harder than it first appears and is most often useless, so you'd probably spend your time better by not trying.[#] Ceci contredit d'ailleurs un petit peu l'autre réponse suivante, qui est faite un peu plus loin : If you don't care about IE, you can use an XML serializer and serialize to XHTML5 (application/xhtml+xml). However, if you do care about IE, you can use an HTML5 serializer and serialize from an XML pipeline to text/html. In this case, you must avoid constructs that aren't supported in text/html (e.g. div as a child of p). Accessoirement, le fait que le standard HTML5 ne soit pas encore fini n'aide pas trop les choses !

Tiens, un petit détail s'agissant de HTML5 : je suis un grand fan de la distinction entre les balises abbr et acronym[#2], et ces andouilles ont décidé assez gratuitement de la supprimer (il ne subsiste que abbr). Pourquoi tant de haine ? Je pourrais remplacer acronym par abbr dans toutes mes pages, mais c'est quand même une perte d'information assez violente ; à la place, je suppose qu'il faut plutôt remplacer acronym par abbr class="acronym" et faire une stylesheet orale pour indiquer comment lire le texte.

[#] Je pense que si je ne mets aucune entité, j'arrive bien à produire des documents qui sont à la fois du HTML5 et du XHTML5 valides. En revanche, si je veux mettre des entités (juste par défi), ça devient vraiment technique. Voici donc un défi : produire un document qui soit (1) du HTML5 valide en mode « soupe de tags », (2) du XHTML5 valide selon la spécification HTML5, (3) du XML bien-formé et si il contient une référence à une DTD, alors valide selon cette DTD, et (4) pour garantir la non-trivialité, qu'il contienne à la fois une référence à une entité (disons —) et un élément SVG. Est-ce possible ?

[#2] Pour préciser, abbr sert à marquer une abréviation qui doit se lire lettre par lettre, par exemple HTML, noté <abbr>HTML</abbr> et prononcé [aʃteɛmɛl], et acronym sert à marquer un acronyme qui se lit comme un seul mot, par exemple MIME, noté <acronym>MIME</acronym> et prononcé [maɪm].

Deuxième question, comment faire un flux de syndication correct ? Je fais notamment référence à des commentaires sur l'entrée précédente. Actuellement, je propose un flux RSS 1.0, auquel je peux assez facilement ajouter un flux Atom s'il y a de la demande. Mais encore faut-il savoir quoi mettre dedans. Auparavant il n'y avait que le titre des entrées. Maintenant j'ai mis le début du texte proprement dit (160 caractères initialement, que je viens d'augmenter à 500 puisque 160 semble un peu court). Mais j'avoue que je ne sais pas très bien à quoi ce truc sert (en fait, je n'ai jamais utilisé d'agrégateur de flux, ce qui n'aide pas). Dans mon esprit, avoir le début du contenu devait servir à voir rapidement si on a lu l'article et, sinon, si on est éventuellement intéressé à la lire, un peu comme Google affiche en-dessous d'un lien dans les résultats de recherche : du coup, cela fait sens de ne mettre que le début (et de retirer le formatage). Apparemment, il y a des gens qui préfèrent lire complètement le contenu par un agrégateur. Je n'ai pas d'objection à ça (je vois mal quelle objection je pourrais avoir, à part que je suppose que ça casse toutes les stylesheets CSS), mais j'ai un petit problème avec l'usage du fichier RSS (ou Atom) lui-même : dans mon esprit, le fichier RSS a pour but d'être petit et téléchargeable rapidement et fréquemment, pour pouvoir facilement savoir s'il y a du nouveau contenu — si on veut télécharger le contenu proprement dit, il faut voir ailleurs. Autrement dit, je veux bien qu'un agrégateur permette de lire mon blog complètement, mais dans ce cas c'est le boulot de l'agrégateur de télécharger le fichier HTML proprement dit (s'il a calculé qu'il y avait du nouveau et qu'il y avait raison de télécharger), d'en extraire la bonne section, et de la présenter comme il veut la présenter, cela ne devrait pas se limiter à la lecture du RSS. Donc il faut m'expliquer comment obtenir ça, parce qu'en l'état je suis un peu perplexe (on me souffle qu'Atom doit permettre de fournir un lien vers le contenu proprement dit, mais je ne comprends pas vraiment comment). Ajout (2011-09-06T15:20+02:00) : Quelqu'un me dit que ce n'est pas possible pour un flux Atom de référencer du contenu externe, mais quelqu'un d'autre suggère, et cette page semble confirmer, que si, avec l'attribut src sur la balise atom:content ; mais les agrégateurs Atom sont-ils assez malins pour utiliser correctement une ressource externe qui soit un div dans un document HTML ?, voilà ce que je voudrais savoir.

Cette question rejoint un peu la précédente : si je passe à HTML5, alors on me suggère que je peux mettre les entrées dans des balises article, ce qui simplifierait le boulot d'outils cherchant à analyser le blog automatiquement. Je suis tout à fait favorable à ça.

Ajout (2011-09-07) : voir l'entrée du surlendemain.

Troisième question, comment gérer les commentaires ? Actuellement c'est un script Perl maison qui s'en occupe, et qui tourne sous la forme d'un CGI sur mon serveur Web. Je n'y ai pas touché du tout : ce moteur de commentaires est à peu près complètement séparé du moteur de blog (et il permet d'ailleurs de commenter n'importe quelle page Web, c'est voulu, même si j'aurais tendance à être réticent à modérer favorablement des commentaires sur des pages ne me concernant pas du tout), les seules connexions étant que je fournis au moteur de commentaires des alias pour les entrées de mon blog (pour afficher le titre de l'entrée commentée) et qu'à l'inverse j'ai un petit bout de JavaScript qui affiche le nombre de commentaires et la date du dernier à la fin de chaque entrée. Cette séparation a l'avantage que le système de commentaires ne m'a pas handicapé pour le changement du moteur de blog ; elle a l'inconvénient que quand on me demande de produire un flux RSS des commentaires ou, pire, de reproduire l'entrée elle-même en tête de chaque page de commentaires, ce n'est pas facile.

Je voudrais donc probablement, à terme, refaire ce moteur de commentaires, ce qui est d'ailleurs sans doute plus facile. Et probablement l'intégrer de façon plus proche avec le moteur de blog. Pour ça, j'ai déjà choisi mon arme : Apache Tomcat, parce que pour s'intégrer avec un outil en Java ce sera le mieux (et parce que je ne veux vraiment pas apprendre PHP ; quant à Perl, il m'a profondément déçu par son absence de bibliothèque convenable pour gérer le XML : XML::LibXML est complètement cassé dès qu'on commence à jouer avec les namespaces, or on doit le faire si on prétend mélanger XHTML avec n'importe quoi).

Mais une question d'un peu plus haut niveau consiste à se demander quel mécanisme d'entrée fournir pour les commentaires. Actuellement, on tape du pur texte, seule est fournie la possibilité d'entrer un lien en tapant <URL: schéma://monurl >, ce qui est malcommode et d'ailleurs les gens ne lisent pas les instructions et se trompent plus souvent qu'ils ne réussissent. Je voudrais faire plus agréable que ça, mais c'est extrêmement délicat : permettre de taper du HTML demande par exemple soit de trouver un parseur « soupe de tags » (capable de transformer la soupe en un vrai arbre DOM) soit d'exiger que le commentateur produise du XHTML bien-formé, ce qui est bourré d'écueils (les gens n'ont pas envie de refermer leurs balises, je pense, il n'y a que les maniaques comme moi pour le faire). Sans doute les navigateurs modernes ont-ils tout ce qu'il faut (un éditeur de HTML inclus qui produise automatiquement du XHTML bien-formé), ce qui fait que je pourrais fournir le choix entre taper du texte pur, taper du XHTML à la main ou, si on a un navigateur convenable, taper du XHTML à travers un widget fourni par le navigateur. Reste qu'il faudra encore, pour des raisons de sécurité, valider ce XHTML derrière, choisir un modèle de contenu autorisé, etc. : tout ça est un peu fastidieux.

Par ailleurs, j'ai un ami qui réclame que les commentaires soient accessibles par une interface NNTP, pour pouvoir les agréger avec ses autres groupes de discussion. La demande est raisonnable sur le principe, même si je n'aime vraiment pas le protocole NNTP, et que la conversion HTML↔texte est au mieux déplaisante (sans parler de la quasi-impossibilité de faire un round-trip correct, quelque chose qui figure d'ailleurs dans ma TORANT-list). Si au moins il existait des standards d'échange ou téléchargement des messages sur les webforums (un standard basé sur JSON, typiquement), je pourrais utiliser ça et lui dire que dès lors que les messages sont récupérables sous un format clair c'est à lui de se débrouillre pour interface avec NNTP… mais je ne crois pas qu'un tel standard existe. (Ce qui est hautement regrettable, parce qu'il est vraiment pénible de suivre des webforums qui ont tous leur style différent, sans pouvoir les agréger sous une interface unique dans un newsreader.) Au moins en lecture, un flux RSS ou Atom serait sans doute désirable.

Sonnez hautbois, résonnez musettes ! Il est arrivé le moteur de blog nouveau ! Chantons tous son avènement !

Ça fait un an et demi que j'y pensais, que je bassinais mes lecteurs régulièrement avec ça, que j'y travaillais très très épisodiquement (après avoir mis du temps à faire les choix techniques), mais voilà, enfin, les choses sont en place et j'ai une première version un peu coupante sur les bords mais réellement fonctionnelle : ce blog[#] n'est plus généré par un programme en C de 3000 lignes mal écrit, buggué et impossible à maintenir, mais par… un programme en Java de 3000 lignes que j'espère légèrement moins mal écrit, légèrement moins buggué et légèrement moins impossible à maintenir.

Vous ne voyez pas la différence ? C'est normal. C'est voulu, même : à part de timides petits changements dans l'en-tête et le pied-de-page des différentes parties de ce blog, j'ai visé à tout garder identique. Le principal changement qui devrait être visible pour ceux qui utilisent le flux RSS, c'est le truc qu'on me réclamait régulièrement, à savoir une date et heure sur les entrées, et le (début du) contenu des entrées elles-mêmes dans le flux (chose qu'il aurait été quasiment impossible de faire avec l'ancien moteur sans s'arracher les cheveux). Sinon, la plupart des changements ont lieu de mon côté : mon blog n'est plus tapé comme un fichier unique de 6.6Mo (and counting) mais comme un petit fichier par mois (ça va rendre git plus heureux, même si en contrepartie c'est moins commode pour rechercher dedans), et quand je recompile il y a plein de magie noire mêlant du PostgreSQL, du Perl et du Java pour ne regénérer que les bouts vraiment modifiés. J'ai aussi dû me battre avec plusieurs misfeatures de XML ou des parseurs XML[#2].

Ceci étant, le but n'était pas tellement de changer des choses, même pour moi, mais de me donner les moyens de pouvoir les changer : autrement dit, de quitter une situation où je ne peux rien faire évoluer parce que le programme est tellement horrible que je refuse d'y toucher. Et pour ça, je crois avoir effectivement gagné.

[#] Ce blog, et avec lui une bonne partie des pages Web de ce site, celles qui ont vaguement le même look.

[#2] En voici une qui m'a causé pas mal d'arrachage de cheveux : si vous considérez le fichier XML suivant : <?xml version="1.0"?> <pouet>&pouet;</pouet>, il n'est pas bien-formé, parce que l'entité &pouet; est référencée sans être définie ; en revanche, si je rajoute n'importe quelle référence à un document externe, disons <?xml version="1.0"?> <!DOCTYPE pouet [<!ENTITY % nothing SYSTEM "/dev/null"> %nothing;]> <pouet>&pouet;</pouet>, alors magiquement le document devient bien-formé. La logique, assez compréhensible, est que le caractère bien-formé ou non d'un document XML doit pouvoir se décider sans consulter la moindre ressource externe, donc dès qu'on ne peut plus être sûr sans en consulter que l'entité n'a pas été définie, ce ne peut plus être une contrainte de bien-formitude bonne forme. (C'est cependant toujours une contrainte de validité.) Mais ce qui m'agace c'est que, du coup, les parseurs XML ne signalent pas d'erreur et qu'il n'y a apparemment pas de moyen de les forcer à en produire une (j'ai vraiment envie que Xerces me signale si j'utilise une entité non définie parce que j'ai fait une faute de frappe, et pas qu'il la remplace par la chaîne vide !). La seule façon de faire semble être de demander au parseur de valider, et d'ignorer la floppée d'erreurs qu'il va pondre sauf celle-ci : c'est vraiment absurde. (Et je ne vous parle pas du fait que Xerces a douze interfaces différentes avec douze façons différentes d'enregistrer un gestionnaire d'erreurs, et que trouver comment lui faire avaler un org.apache.xerces.xni.parser.XMLErrorHandler et pas un org.xml.sax.ErrorHandler parce qu'on veut éviter d'avoir à parser le message d'erreur, c'est pas évident.)