En attendant Godot... euh, Serge Un historique de toutes nos réunions

Table des matières

• mercredi 02 mai 2001 (précédent)
• mercredi 06 juin 2001 (suivant)
• Tous les comptes-rendus

jeudi 10 mai 2001

La voix du secrétaire (Jean)

• Briac, qui a mangé une andouillette, et bu une Guinness,
• BooK, qui a mangé une escalope milanaise et bu de la blanche,
• moi, qui ai mangé un magret de canard, et qui n'ai pas eu besoin de demander une Margarita à la serveuse, elle s'en souvenait,
• François, qui a mangé un magret de canard,
• Kai, qui n'a rien mangé, mais qui a bu de la Kriek,
• Birgit, qui a mangé des frites, et bu de la Kriek,
• David et sa cravate, qui a mangé un magret de canard, et bu de la Kwack (vous savez, dans le verre en forme de sablier).

Obfuscation

• BooK est en train de se préparer pour YAPC::Amsterdam, où il compte faire un exposé sur The Art of Obfuscated Programming. Il dispose bien entendu des archives de l'OPC et de l'IOCCC, et de la colonne de Perl Monks, mais il cherche d'autres exemples. François lui signale l'existence d'un fichier T_EX obfusqué dans CTAN.
• En revanche, trouver un programme Python obfusqué lui semble irréaliste. Il a bien écrit des programmes bilingues Perl + Python, mais en lisant ces programmes en mode Python, il n'y avait rien de bien mystérieux, juste des instructions inutiles et des commentaires avec plein de caractères spéciaux (un peu comme du code exécutable Perl).
• Pour savoir à partir de quel moment l'obfuscation a pu apparaître, Philippe a trouvé un arbre généalogique des langages de programmation. On peut constater qu'Intercal n'y figure pas. Cela dit, l'une des idées à la base d'Intercal était de ne rien faire comme les autres langages, ce qui signifie que Intercal n'aurait été relié à aucun autre langage dans le graphe.
• Selon Philippe, l'obfuscation est impossible avec les langages machine et les langages assembleur. Briac et moi lui conseillons de relire la Geste de Mel, le Vrai Programmeur.
• BooK évoque les quines, programmes capables de produire leur propre code source. Je rappelle que les quines étaient à la base d'un article de Ken Thompson [ en fait, lors de la réunion je ne savais plus si c'était Kernighan ou Ritchie ; j'avais tout faux ], "Reflections on Trusting Trust", où il révélait l'existence d'une porte dérobée dans login(1) et dans le compilateur C. Cet article fait partie des classiques de l'ACM (Association for Computer Machinery, l'une des plus anciennes organisations s'intéressant à l'informatique nous dit François).
• Philippe rappelle l'idée de Stéphane, qui voulait utiliser l'encodage des caractères Unicode pour créer un programme en respectant la limite sur le nombre de caractères, sans être gêné par une quelconque limite en nombre d'octets. Avec un bon encodage, on pourrait même obtenir un programme en 1 caractère. Je signale que The Perl Journal a publié un programme de zéro caractère. En fait, c'est le programme proposé par Gordon Lack pour l'OPC zéro. Il est destiné à lire des fichiers Macintosh, dans lesquels les délimiteurs de ligne sont les CR, pour les convertir en fichiers Unix, avec des LF pour séparer les lignes. L'astuce vient de ce que la ligne "shebang" n'est pas comptée dans la taille du programme. Voici le source intégral de ce programme :

  #!/usr/bin/perl -w015l12pi.bak
  

  Perl

• Pour déterminer où aura lieu la conférence YAPC::Paris, nous examinons plusieurs possibilités. Elle pourrait avoir lieu à Paris intra-muros, ce qui poserait peu de problèmes pour l'hébergement et pour le transport. Ou bien elle pourrait se tenir en grande banlieue (Orsay, Saint-Quentin-en-Yvelines), ce qui serait plus délicat pour le transport et l'hébergement. En revanche, cela inciterait les participants à assister aux conférences, plutôt que d'aller voir la Tour Eiffel. Kai a participé à la conférence German Perl Workshop, et nous raconte un peu comment c'était organisé. La conférence avait lieu dans un village perdu, pas du tout touristique. Et il y avait un car pour ceux qui voulaient aller à la ville.
• François a un nouveau module en préparation. C'est un module pour faire de la cryptographie (RSA, DES et autres). Il existe bien un module pour les bignums et un autre pour les bigints, mais ce sont des modules tous usages, permettant de faire n'importe quelle opération arithmétique avec les bigints. Le module de François ne permettra que de faire que les opérations indispensables pour la cryptographie, ce qui permettra d'optimiser ces opérations.
• Nous évoquons les maladresses de style en programmation Perl. Par exemple, il y a ceux qui alimentent le tableau @INC à la main, alors qu'il est si simple d'écrire

  use lib 'Toto::Tata';
  

  Je cite un exemple que j'ai vu il y a quelques mois sur la liste PPM. L'auteur du message écrivait ainsi son programme CGI :

  print "première ligne";
  print "deuxième ligne";
  print "troisième ligne";
  print "quatrième ligne";
  

  Il n'y avait aucun "\n", ce qui est gênant si l'on intercepte le fichier résultant pour le débuggage. Mais le pire à mon avis, c'est la lourdeur du code. J'aurais utilisé une chaîne sur plusieurs lignes :

  print 'première ligne
  deuxième ligne
  troisième ligne
  quatrième ligne';
  

  voire un here-document :

  print <<'EOT';
  première ligne
  deuxième ligne
  troisième ligne
  quatrième ligne
  EOT
  

  François nous rappelle que l'on peut utiliser plusieurs here-documents à la suite, et qu'il n'est même pas nécessaire d'utiliser des valeurs différentes pour les balises de fin :

  ma_fonction(<<"EOT", <<"EOT", <<"EOT");
  première ligne du paramètre 1
  deuxième ligne du paramètre 1
  EOT
  ligne 1 du deuxième paramètre
  ligne 2 du deuxième paramètre
  EOT
  première ligne du paramètre 3
  deuxième ligne du paramètre 3
  EOT
  

  Il est possible d'indenter les here-documents. Voir les quelques lignes dans Amelia, page 67, la recette 1.11 du livre du mouflon, pages 23 à 26, ou bien la FAQ.
• Il paraît qu'il y a un fêlé qui a installé l'intégralité de CPAN sur son système personnel ! Cela a toutefois permis de tirer des conclusions dont bénéficiera la communauté. En effet, son expérience permet d'attirer l'attention sur les modules dont la procédure d'installation est défaillante, et sur les incompatibilités entre différents modules.
• Cela dit, Michael Schwern a lancé un projet, appelé CPANTS (CPAN Testing Service), qui permettra de charger, d'installer et de tester automatiquement le plus grand nombre possible de modules de CPAN. En fonction des résultats, chaque module recevra une note, selon qu'il passe les tests sur la plupart des architectures, selon la façon dont il cohabite avec les autres modules, etc.
• David s'est mis à Perl parce qu'il a lu une série d'articles d'initiation à Perl dans Linux Magazine, et qu'il a eu le sentiment qu'il pourrait comprendre ce langage de programmation. [ Heureusement qu'il n'a pas commencé par lire les oeuvres de Philippe, aussi bien sur le site PPM que chez les Perl Monks. ]
• On me demande des nouvelles de la traduction d'Amelia. En effet, c'est moi le relecteur officiel de O'Reilly France pour cette traduction. Gérald a déjà traduit les chapitres 29 à 32, et une autre personne s'est chargée de la préface et des deux premiers chapitres. Normalement, à la date de la réunion, j'aurais dû disposer également du glossaire, et des chapitres 3 et 4. Il y a donc un léger retard de ce côté. D'autre part, il était prévu un troisième traducteur, mais cela ne se fera pas, donc Gérald a quelques chapitres supplémentaires à traduire.

  Sujets techniques

• Briac ayant apporté une carte d'extension à BooK, il a été abondamment question de cartes et de puces. Comment overclocker un processeur avec une perceuse et du vernis à ongle, les déboires de BooK avec le service après-vente de Surcouf, les problèmes des lecteurs de disquettes, lorsqu'ils sont déconnectés, puis reconnectés à l'envers (il n'y a pas de détrompeur), les boîtiers mal dimensionnés qui empêchent de rentrer les cartes au fond de leur logement, les cartes qui sortent d'usine avec des patchs, car il est impossible d'arrêter la chaîne de production (ou plutôt, cela coûterait trop cher, il vaut mieux investir en main d'oeuvre pour câbler les patchs).
• Linus travaillant chez Transmeta, il est assez bien placé pour parler du travail de programmation matérielle, par opposition à la programmation logicielle. Le rythme des nouveautés est beaucoup moins rapide pour les composants que pour les programmes. C'est dû au fait que si une amélioration se révèle buguée, dans un programme ce n'est pas trop grave. Il suffit de diffuser les correctifs, et de les installer, ce qui est facile à faire, avec les moyens actuels. En revanche, si on détecte un bug dans un composant, il faut changer la chaîne de fabrication, produire les nouveaux composants, et faire parvenir les composants corrigés à tous ceux qui ont un circuit défaillant, pour procéder à l'échange standard. Cet échange, ainsi que l'acheminement du composant corrigé, est beaucoup plus lourd que pour un logiciel, c'est pourquoi les adaptations sont testées en long, en large et en travers avant d'être intégrées dans la chaîne de fabrication.
• Beaucoup moins médiatique que le bug de l'an 2000, il y a le bug du milliard de secondes. C'est en effet dans quelques mois que l'estampille d'Unix atteindra les 10 chiffres. Normalement, cela ne devrait pas véroler les systèmes de fichiers, ni provoquer de gros dégâts. Mais on est à la merci de quelqu'un qui stocke les estampilles dans un tableau prévu pour 9 caractères.
• Après avoir évoqué son futur module de cryptographie, François a parlé de cryptographie en général. Cette technique se base sur des mathématiques hautement élaborée, mais aussi sur des espoirs et des probabilités. Ainsi, pour savoir si un grand nombre est premier, on utilise le critère de Rabin-Miller, dont le résultat en fait est soit "le nombre est vraisemblablement premier", soit "le nombre est composé, c'est prouvé". D'autre part, les codes avec clé publique et clé privée reposent sur l'hypothèse qu'il est très long et très difficile de décomposer un grand nombre en facteurs premiers, si le plus petit des facteurs premiers est déjà un grand nombre. Jusqu'à présent, aucune méthode de factorisation ne permet de factoriser de tels nombres, mais quelqu'un peut faire une découverte un jour ou l'autre.
• Parmi les nombres premiers, il existe un nombre premier illégal. C'est le nombre obtenu en compressant par gzip un décodeur DECSS, et en interprétant le résultat comme un nombre en binaire. Comme les tout derniers bits peuvent être choisis arbitrairement sans changer le fichier décompacté, il est possible de s'arranger pour obtenir un nombre premier.
• L'un des sujets traités a porté sur la comparaison entre les archives RPM et les archives DEB. L'avis de la majorité des participants est que les archives DEB sont beaucoup plus faciles et agréables à utiliser que les archives RPM : pour installer une archive RPM, la gestion des dépendances est anti-ergonomique, et pour en créer une, il faut taper un fichier de spécifications, dont la syntaxe et le contenu sont abscons.
• Récemment, les abonnés à la liste ont été victime du virus HOMEPAGE.html.vbs. Ce virus comportait un programme codé de manière simpliste (décalage de deux positions dans le code ASCII, sauf pour CR, LF et SPC), mais ce codage était suffisant pour tromper les anti-virus inclus dans les clients de courrier électronique, qui n'ont pas détecté le problème. D'autre part, le nom avec deux extensions permettait de tromper également les humains, pour la raison suivante : pour je ne sais quelle raison foireuse, de nombreux programmes Microsoft affichent les noms de fichier en enlevant l'extension. Par conséquent, le fichier joint HOMEPAGE.html.vbs apparaît sous la forme HOMEPAGE.html, ce qui semble inoffensif. Cela dit, comme le signalait Fabien Penso sur la liste, ceux qui n'utilisent ni Microsoft Outlook, ni Microsoft Exchange, ni Microsoft Machin-Chouette, ont tout de suite vu qu'il y avait une entourloupe.
• BooK a entendu dire que c'était un virus tout nouveau, et que c'était celui qui s'était répandu le plus vite depuis que les virus informatiques existent. Cette information n'a aucune signification réelle. Depuis que les virus se transmettent par Internet, leur vitesse de transmission dépend du nombre de messages électroniques échangés, donc en gros du nombre d'ordinateurs connectés à Internet. Comme ce nombre est en progression constante, c'est inévitable que chaque virus se propage plus vite que le précédent.
• Au sujet des pièces jointes doûteuses, je signale que j'ai reçu un jour un courrier avec une pièce jointe Testcoul.exe, mais que je ne l'ai toujours pas ouverte. Mon frère m'a parlé d'un programme qui affiche pendant quelques millisecondes le mot "GREEN" en caractères rouges, et qui vous demande ensuite quelle couleur c'était. Et selon que l'on clique sur un bouton ou un autre, le programme vous apprend si vous êtes plus sensibles au texte où à la longueur d'onde. Si ça se trouve, le programme dont mon frère m'a parlé et celui que j'ai reçu de quelqu'un d'autre sont les mêmes, mais il se peut également que cet autre programme soit un virus.
• François nous rappelle que Bruce Schneier a évoqué une source de problèmes de sécurité : Unicode. Les programmes fonctionnant en ASCII sont (plus ou moins) fiables, car on fait attention aux caractères dangereux (apostrophes inverses, par exemple), et aux débordements de buffer. Mais avec Unicode, les caractères sont tellement nombreux, et il en arrive tout le temps, ce qui fait qu'il est impossible de savoir quels sont les caractères dangereux.
• David demande comment fonctionne Unicode. En gros, il faut installer un fichier pour avoir une police basée sur un jeu de caractères plus ou moins complet, et il faut avoir également les logiciels adaptés, capables de décoder des caractères Unicode et de les afficher (éditeur de texte, navigateur web, etc).
• François nous raconte ses déboires avec la distribution Mandrake de Linux. Une première fois, c'est un client qui l'a appelé deux jours de suite pour lui signaler qu'il avait perdu le travail d'une journée. Le problème était le suivant.
  1. À l'origine, il existait sous Linux un démon update, destiné à vider les buffers de fichiers toutes les trente secondes et mettre les disques à jour.
  2. Un jour, il a été décidé de remonter cette fonction dans le kernel.
  3. Au début, la fonction se trouvait dans le kernel à titre expérimental, donc il était dit clairement que, pour des machines de production, il fallait laisser le démon update. En effet, il n'y avait rien à craindre si le kernel et le démon tentaient tous les deux de vider les buffers. À l'inverse, si chacun comptait sur l'autre pour vider les buffers, personne ne le ferait, et il y aurait donc de gros problèmes.
  4. Or, dans le script de lancement de la distribution concernée, le démon update figurait en commentaires. Donc, il ne se lançait jamais. Et rien lors de la procédure d'installation n'attirait l'attention sur ce point.
  François a évoqué ce problème sur la mailing-list du kernel. Quelqu'un lui a fait remarquer qu'il était hors-sujet, puis Alan Cox a répliqué que le message de François était tout-à-fait justifié, et que cela pouvait servir à d'autres personnes qui pourraient rencontrer le même problème, et mettre en cause le kernel.
• L'autre problème vient des fonctions APM et SMP. La fonction APM permet des économies d'énergie, en mettant en veille le processeur s'il est inactif. La fonction SMP permet le fonctionnement en multi-processeur. Ces deux fonctions sont incompatibles. Et dans la distribution Mandrake, le kernel comportait les patchs pour les deux fonctions.
• Comme il a été question de Postscript, François fait un parallèle entre Postscript (notation polonaise inverse, programmation par pile) et Lisp (notation polonaise directe, programmation par liste). [ Pour avoir beaucoup programmé sur HP-25 et HP-41, et pour avoir aussi un peu programmé en Emacs-Lisp, je trouve que la programmation de liste n'a pas grand chose à voir avec la programmation de pile. Le seul point commun, c'est de requérir une agilité mentale pour s'affranchir des langages algébriques infixes habituels. ]
• En Lisp, il est essentiel de bien savoir fermer les parenthèses comme il faut. Pour ce faire, il y a plusieurs écoles. Philippe a entendu parler du crochet fermant, une "super-parenthèse" qui ferme toutes les parenthèses qui sont encore ouvertes. Moi je mets à profit les effets spéciaux d'Emacs et de vi, qui, chaque fois que l'on tape une parenthèse fermante, mettent en relief la parenthèse ouvrante qui correspond. François, lui, sait exactement combien il lui reste de parenthèses ouvertes, et il connaît parfaitement la vitesse de répétition de son clavier. Donc, il se contente d'appuyer sur la touche parenthèse fermante le temps nécessaire.
• Dans vi, il existe des possibilités de macros. Philippe avoue ne jamais être allé plus loin que quelques simples map. François (je crois) signale qu'il existe un fichier de macros qui montre une animation des tours de Hanoï.
• Curieusement, les disciplines techniques, et en premier lieu l'informatique, sont sensibles à des phénomènes de mode. C'est ainsi qu'il y a cinq ans, Java était le nec plus ultra, le point de passage obligé, et la garantie de réussite de tout projet informatique de pointe. Maintenant, après le développement d'Internet, on constate un phénomène analogue avec IP, puisque les banques sont en train d'adopter ce protocole pour les distributeurs automatiques (il en a déjà été question le mois dernier). Cela dit, qui dit IP ne dit pas nécessairement Internet. Vos retraits bancaires ne circuleront pas sur les mêmes câbles que les téléchargements de MP3 ou les commandes à Amazon.
• Pour en revenir à Java, avec le recul de 5 ans, on peut constater que les objectifs originaux ont été noyés dans des considérations politico-commerciales. Il ne reste rien du langage portable et cohérent d'antan. Philippe et François illustrent cela avec les objets AWT et je ne sais plus quoi d'autre. Je n'ai pas retenu les détails, la seule chose que je puisse dire, c'est que maintenant, Java est un langage bancal.
• François nous explique qu'il sait taper sur un clavier QWERTY, y compris un clavier dont les touches sont libellées en AZERTY, mais configuré au niveau système en QWERTY. En revanche, pendant la courte période où les minitels avaient un clavier alphabétique, il n'a jamais pu se faire à cette configuration (et il n'est pas le seul, loin de là). Cela lui permet, notamment, de mettre un terminal VT en mode programme, et de taper des accolades, des backslashs et des pipes sans utiliser la touche Alt-Gr. Avec les derniers modèles de VT, il est possible d'avoir deux sessions liées à deux lignes tty différentes, et d'en configurer une en mode programme et l'autre en mode texte. Je fais remarquer que je n'aime pas les VT420. Au bout d'une demi-journée, j'ai les poignets en compote, car les touches n'ont pas un mécanisme bien franc, et il faut appuyer plus fort que sur un clavier normal.

  Donald Knuth

• Knuth a beaucoup avancé sur le volume 4 de The Art of Computer Programming (tiens, ce titre nous rappelle quelque chose...). Cela dit, les informations à ce sujet divergent. L'un dit que la sortie de ce volume est prévue pour 2006, l'autre dit que c'est le volume 5 qui doit sortir à cette date, et que le volume 4 va sortir dans pas longtemps. Quant à moi, il me semble avoir lu que Knuth comptait sortir une version préliminaire du volume 4 en fascicules séparés.
• Il a été question à un moment de la génération de nombres aléatoires. Notamment, avec les derniers développements du matériel informatique, on peut initialiser le générateur de nombres pseudo-aléatoires avec des phénomènes physiques tels que la température du processeur, ou la pression atmosphérique au niveau de la tête de lecture du disque. Je ramène la discussion sur Knuth, en disant que l'un des exercices du volume 2 consistait en ceci : "Examinez la bibliothèque de sous-programmes sur chacune des machines de votre site, et remplacez le générateur aléatoire par un générateur correct. Essayez de ne pas vous scandaliser des résultats obtenus".
• J'avoue, je n'ai quasiment essayé aucun des exercices de TAOCP, et j'ai sauté les démonstrations quand elles étaient trop longues ou trop techniques. Cela dit, certains exercices ont une difficulté de 40, c'est-à-dire selon Knuth "un bon sujet de thèse". Il y en a même de difficulté 50, avec un énoncé simple tel que :

  Démontrez que tout nombre pair peut s'exprimer sous la forme de la somme de deux nombres premiers.

  En fait, l'exemple que j'ai donné est apocryphe. En revanche, l'exemple que mes interlocuteurs ont donné est réel, et figure dans l'introduction :

  Montrez que, pour n supérieur ou égal à 3, l'équation
  xⁿ + yⁿ = zⁿ
  n'admet aucune solution avec x, y et z tous les trois entiers et différents de zéro.

• Knuth a trouvé un bon moyen pour s'assurer que ses ouvrages sont exempts d'erreur. Chaque fois que quelqu'un en détecte une, Knuth rétribue la première personne qui a trouvé cette erreur. Le prix est de 2,56 $ par correction.
• Knuth fait aussi peu de fautes dans ses programmes que dans ses livres. Il paraît qu'il a écrit la première version de Metafont d'une traite, et que cela a compilé et tourné du premier coup. Combien de personnes sont capables d'en dire autant ? Et lorsque quelqu'un a demandé à Knuth pourquoi il n'avait pas fait faire le boulot par un de ses étudiants, il a répondu que cela irait plus vite s'il le faisait lui-même.
• Cela dit, Knuth n'utilise plus Metafont pour faire de la typographie. Il l'utilise simplement pour résoudre des équations linéaires. Par exemple, si vous avez un point A en (5, 1) et un point B en (1, 3), et que vous voulez savoir où la droite (AB) coupe l'axe des X, il suffit de soumettre le fichier suivant à Metafont :

  x1 = 5; y1 = 1;
  x2 = 1; y2 = 3;
  z3 = whatever [z1, z2]; y3 = 0;
  message "x3 ="; show x3;
  end;
  

• Il est également question de la polémique entre Dijkstra (Goto Statement Considered Harmful) et Knuth (Structured Programming With Goto Statements, qui figure dans le livre Literate Programming).
• Je ne sais plus à quel propos, nous avons parlé de T_EX, et notamment François a signalé qu'il était possible de tout redéfinir. Je cite l'exemple de texinfo, le format de documentation de GNU, qui est en fait un dialecte de T_EX où le backslash est un caractère tout ce qu'il y a de plus commun, et où l'arrobase est le caractère qui introduit les opérateurs, les macros, etc. En fait, lorsque l'on compare du T_EX et du texinfo, cela ne se ressemble pas du tout, et pourtant c'est la même chose. À propos, nous prononçons T_EX "tèk", comme dans technique. Mais comment faut-il prononcer "texinfo", avec le son "ks" de la lettre "x", ou avec le son "k" de la lettre "khi" ?
• Cela dit, nous regrettons que GNU ait laissé tomber les pages de man au profit du format texinfo. C'est pourquoi, parmi les participants à la réunion, certains aiment bien les distributions BSD, car au moins elles contiennent des pages de man à jour et bien faites.

  Sujets divers

• Si nous ne voyons pas plus souvent François, c'est parce qu'il participe également aux réunions de Linux-fr, qui ont lieu le premier jeudi du mois, dont en général le lendemain de notre réunion. Ils ont choisi le "first jeudi", par analogie avec le "first tuesday" des start-ups. Mais Philippe fait remarquer que cela fait à peu près un an et demi que nos réunions se passent le premier mercredi du mois, alors que cela fait moins d'un an que c'est comme cela pour Linux-fr.
• Il a été question des vrais-faux canulars. Ainsi, il y a une page web décrivant un ordinateur à pommes de terre, déjà évoquée lors d'une réunion précédente. C'est une page truquée, mise en scène. Mais il y a aussi un vrai ordinateur à pommes de terre, qui fonctionne réellement avec le courant généré par des pommes de terre. Dans un même ordre d'idée, il y avait la RFC sur le protocole IP par porteur aviaire. Comme le raconte Slashdot cette RFC a été implémentée récemment par des Norvégiens. Quelqu'un encore a converti son PC en alambic : le processeur sert à chauffer le liquide, et le ventilateur permet de refroidir le serpentin. Cela dit, le rendement n'est pas fameux.
• Un article récent de Slashdot [ et du Forum sur les risques ] raconte comment un professeur de fac a fait pour piéger les étudiants qui se contentaient de faire du copier-coller pour leurs devoirs. En discutant sur cette anecdote, nous remarquons que faire du copier-coller n'est pas forcément répréhensible, si l'on cite ses sources. Mais apparamment, ce n'était pas le cas ici.
• En parlant de Postscript, et de PDF, nous avons évoqué Ghostview. Philippe signale qu'il ne faut pas confondre la société Aladdin qui diffuse Ghostview et la société Aladdin qui propose des logiciels pour Macintosh. Lors de la réunion, nous avons dit (à tort) qu'il y avait une différence d'orthographe entre les deux sociétés. En fait, ce nom désigne de nombreuses sociétés, et j'en ai trouvé une avec une orthographe différente.
• Nous avons même parlé de musique pop et de rock-n'roll. En effet, Philippe a l'intention d'aller voir Magma en concert. Mais pour leur tournée mondiale, ils jouent généralement dans des villes de faible importance. C'est ainsi que leur concert en France sera à Vitry-le-François. François raconte qu'il les a vu jouer dans des endroits assez inhabituels pour un groupe de rock ; notamment, il a assisté à un concert dans une cathédrale. Je rapproche ce concert d'un passage de Moi y'en a vouloir des sous, de Jean Yanne et Gérard Sire. Une séquence de ce film montrait la messe inaugurale d'une église, et pour célébrer l'événement, c'est Magma qui était présent pour jouer la musique lors de la messe. Je me souviens notamment d'un plan, où le curé demandait à l'évèque ce qu'il pensait du morceau que Magma était en train d'interprêter, et l'évèque répondait : "C'est le pied !". (François, quant à lui, nous conseille Frank Zappa).
• Philippe nous reparle de la recherche qu'il avait faite, sur les nombres dont l'expression en base 10 est symétrique par rapport à l'expression en base 16. Le premier est 53 (en base 10), qui s'écrit 35 en base 16. Il y a également 371 (soit 173 en base 16) et 5141. Il est facile de prouver que le nombre de solutions est fini, ce qui est laissé à titre d'exercice pour le lecteur. En revanche, il est assez long de démontrer que ce sont ces trois-là, et aucune autre. Malgré tout, BooK avait fait cette recherche et cette vérification à la main, sans aucune programmation.
• Même s'il sait effectuer des changements de base sans problème, Philippe regrette de ne pas savoir calculer des racines carrées avec une méthode papier-crayon, que ce soit en décimal, en octal ou en hexadécimal. Je lui réponds que si on sait les calculer en décimal, il suffit ensuite de connaître les tables d'addition et de multiplication en octal pour savoir extraire les racines carrées en octal, la méthode étant la même. Personnellement, je sais calculer les racines carrées en décimal avec un papier et un crayon ; en revanche, je ne m'aventurerai pas à le faire dans une autre base de numération.
• Cela dit, il y a des personnes qui calculent en octal comme s'ils avaient fait cela depuis le cours préparatoire. Le jargon file nous raconte que il est arrivé à certaines personnes de vérifier leur relevé bancaire, et d'additionner les montants en base 8.