Un ange passe Un historique de toutes nos réunions

Table des matières

• mercredi 12 mai 2004 (précédent)
• mercredi 21 juillet 2004 (suivant)
• Tous les comptes-rendus

mercredi 16 juin 2004

La voix du secrétaire (Jean)

Présents à la réunion :

• Jérôme,
• Sylvain,
• Christophe,
• un nouveau dont je n'ai pas retenu le nom,
• Paul-Christophe,
• Emmanuel,
• BooK,
• Nicolas (Chuche),
• Guillaume,
• Eric (glb),
• « Mat »,
• Rafael,
• Philippe (Bl),
• D@vid (la cravate),
• et moi.

Nous avons mangé des rillettes, des oeufs mayonnaise, des blue-cheese-burgers, des tartiflettes, des spaghetti bolognese sans persil, des pavés de boeuf et une crème caramel. Nous avons bu de la Beamish, de la Stout, de la Pécheresse, de la Kriek, de la Kilkenny et autres bières et une margarita. Le serveur n'étant pas le même que la dernière fois, Emmanuel a obtenu une cinquante d'Orangina.

Nous avons parlé de Perl, Internet, informatique et le reste.

Perl

• Au sujet du format POD, utilisé pour la rédaction des articles pour Linux-Magazine, on signale l'existence d'un module soumis par Allison Randal et étendant les possibilités du POD standard. C'est avec ces extensions que certains livres O'Reilly ont été écrits.
• Il est également question du module POD::Tests qui permet de vérifier que votre module comporte bien du POD et que celui-ci est bien écrit. Existe-t-il un module Code::Tests qui vérifie que votre module comporte autre chose que du POD ?
• Suite à la discussion du mois de mai et au compte-rendu, Jérôme est allé consulter le source de ACME::Code::Police. Il a été impressionné par le fait que la partie exécutable de ce module tenait sur une seule ligne, tout le reste étant la documentation.
• Rafael en profite pour rappeler l'existence de la variable d'environnement PERL5OPT, qui prend tout son intérêt avec ACME::Code::Police. En insérant :

  export PERL5OPT='-MACME::Code::Police'
  

  dans les bons fichiers .profile, on est sûr que tout le monde utilisera le module.
• Nous avons également évoqué Acme::Inline::PERL, qui, comme l'indique la documentation, « apporte à vos scripts la puissance du langage Perl ». Les modules Inline fonctionnent sur le même principe. Ils commencent par extraire le source, le compilent (on peut le constater quand le programme se bloque un léger temps) et l'exécutent. Acme::Inline::PERL fonctionne sur le même principe. Il extrait le source, le compile avec sleep 1 et l'exécute avec eval.
• BooK a essayé d'utiliser Devel::Cover pour s'assurer que son module HTTP::Proxy est testé à fond par le jeu de tests fourni dans la distribution. Mais cela ne donne pas de résultat. Peut-être est-ce à cause des fork() qui se trouvent dans le module ?
• Le module HTTP::Proxy a valu à Philippe le bonheur d'être cité dans www.perl.com/, dans l'article sur HTTP::Recorder. Problème, son prénom a été mal orthographié.
• Parmi les exemples pour HTTP::Proxy, Philippe a prévu le l33t-spe4k. Certains pensent à écrire de même un filtre « chef suédois ».
• Un peu plus tard dans la soirée, Paul-Christophe évoque le problème du typage des données. Pour savoir si une donnée saisie à l'écran est bien numérique comme il le souhaite, il teste :

  if ($x + 0 eq $x)
  

  [ En fait, il y avait une légère erreur dans le papier sur lequel Paul-Christophe et Philippe Bl ont discuté. Vous avez ici la version corrigée. ] BooK évoque le module Devel::Peek qui permet de fouiller dans les internes de Perl et de savoir si telle variable scalaire est un nombre ou une chaîne.
• Un autre outil de développement qui a été évoqué, c'est Devel::DProf, qui permet de savoir où le script ou module consomme du temps et quelle portion de code il faut optimiser.
• Paul-Christophe a évoqué Class::DBI, un module qui permet d'utiliser des bases de données sans passer par SQL. Avec ce module, on peut également contrebalancer certains manques de certaines bases de données. C'est ainsi qu'il est impossible de définir des triggers en MySQL. Avec Class::DBI, on peut définir les triggers, qui seront exécutés dans la couche Perl au lieu de l'être dans la couche base de données. Évidemment, c'est moins performant, mais pourquoi s'en priver sur une base de données à faible trafic (quelques centaines de requêtes par jour) ? D@vid s'est aperçu que ce module faisait déjà ce qu'il a programmé pour lire et mettre à jour une base de données.
• Paul-Christophe évoque un problème que Guillaume a déjà évoqué lors de sa présentation aux Journées Perl 2004, le contrôle des clés d'un hachage. Nul n'est à l'abri d'une faute de frappe. Si l'on alimente $h{foo} et que quelques lignes plus bas on lit $h{fou}, on obtiendra undef et on ne comprendra pas pourquoi. C'est pourquoi Paul-Christophe a voulu utiliser les pseudo-hachages. Il ne cherchait pas le gain (mineur) en performances, mais plutôt la vérification dès la compilation des clés du hachage. Notons que la vérification ne porte que sur les valeurs « en dur ». Si l'on mentionne $h{$cle}, il n'y a pas de contrôle à la compilation. Mais au moins, cela ne laisse plus passer les $h{fou} mis à la place de $h{foo}. Mais Paul-Christophe a eu un écho très négatif de Mark-Jason Dominus, qui lui a dit que les pseudo-hachages, c'était dépassé, fini, out, etc.
• Paul-Christophe a jeté un coup d'oeil dans le source de Class::DBI. Il y a vu des portions de code qu'il trouve horribles. Par exemple, pour alimenter un hachage en piochant la clé dans @ARGV (ou @_ dans le cas d'une subroutine) :

  $h{+shift} = 1;
  

  Le problème, c'est l'insertion implicite de guillemets à l'intérieur des accolades indiquant une clé de hachage. Même avec des blancs, comme

  $h{ shift } = 1;
  

  Perl considérera qu'il s'agit de la clé "shift". Pour que Perl considère que la clé du hachage est la valeur retournée par la fonction shift, il faut insérer un « + » à gauche du shift. Ou alors, utiliser des parenthèses :

  $h{shift()} = 1;
  

• Il est possible d'utiliser un « + » unaire avant (et non plus après) une accolade. Cela sert à différentier les blocs des références de hachage dans certains cas ambigus. Il existe un exemple dans la documentation de map. Ainsi,

  %h = map { lc($_), 1 }, @liste;
  

  crée un hachage dont les clés sont les chaînes de @liste converties en minuscules. Les accolades sont interprétées ici comme des délimiteurs de bloc. À l'inverse

  @loh = map +{ lc($_), 1 }, @liste;
  

  produit une liste de références à des hachages anonymes, chacun d'entre eux ne comportant qu'une seule clé. Les accolades, dans ce cas, sont interprétées comme un constructeur de référence de hachage. Il existe un autre exemple dans la documentation sur les références. Notamment dans le cas où une fonction doit renvoyer à l'appelant la référence à un hachage.

      sub hashem {        { @_ } }   # mauvais mais on ne le sait pas
      sub hashem {       +{ @_ } }   # ok
      sub hashem { return { @_ } }   # ok
  

• Nous avons remarqué une tendance récente dans Linux-Mag. La mode actuelle est aux tours de Hanoï. Nous savons comment le faire en Python, nous savons également le faire avec des procédures stockées pour MySQL. Car, bien entendu, la principale utilité des procédures stockées d'une base SQL, que dis-je, leur raison d'être, c'est de résoudre les tours de Hanoï. BooK estime que nous ne devons pas être en reste et nous devons écrire une prochaine Perle de Mongueurs montrant la résolution des tours de Hanoï avec un uniligne.
• BooK a cherché à savoir qui pourrait participer aux Rencontres Mondiales du Logiciel Libre à Bordeaux. Comme cette conférence a lieu dans deux semaines, personne n'est en mesure de débloquer son emploi du temps professionnel pour faire le déplacement. En revanche, pour la conférence à Lyon, au mois d'octobre, certains se sont proposés.
• Philippe a également demandé qui, à part lui, était intéressé pour participer à YAPC::Europe-2004 à Belfast. J'ai l'intention d'y aller. D@vid trouve que le mois de septembre n'est pas commode pour faire le déplacement (c'est déjà pour cette raison qu'il n'avait pas pu aller à Munich).
• Les organisateurs de YAPC-Belfast sont à la recherche d'un logo pour la conférence. Certains proposent un logo basé sur le drapeau européen, mais en remplaçant le fond bleu par une couleur plus perlienne : l'orange ou le rose. Et nous n'étions pas d'accord sur le nombre d'étoiles. Certains pensent que le nombre a été figé une bonne fois pour toutes à 12, les autres pensent que l'Europe imite les États-Unis et rajoute des étoiles au fur et à mesure que des nouveaux états adhèrent à l'Union Européenne.

Internet

• Une page web qui a eu du succès, c'est le scriptomètre de Pixel (Pascal Rigaux). On en a parlé dans Use Perl, cela a été repris dans slashdot [ et on en parle même chez les Mongueurs de Paris et dans leurs comptes-rendus ! ] Pixel a cherché à comparer les langages de script existants, y compris C++ et Java, qui ne sont pas vraiment des langages de script. Il a défini un certain nombre de tâches à effectuer, comme afficher la liste des fichiers d'un répertoire. Le langage le meilleur est le shell. En deuxième position, on trouve Perl et Ruby ex-aequo. Loin, très loin derrière, on trouve C++ et Java. Pixel a reçu de nombreuses réactions à son scriptomètre, dont certains lui signalant qu'il pouvait améliorer ses scripts et économiser un ou deux caractères par-ci par-là.
• En absence d'administrateurs, des collègues ont demandé l'aide de Paul-Christophe parce qu'ils avaient des problèmes sur un serveur web. Paul-Christophe a commencé par envoyer un ping sur le serveur. C'est bon, la machine était accessible. Ensuite, il s'est connecté par telnet sur le port 80 de cette machine. L'un de ses collègues lui a alors rappelé que le problème ne venait pas de telnet, mais de HTTP. telnet, a-t-il dit, c'est le port 23. À quoi ça sert donc, de tester telnet sur le port 80 ? C'est de la perte de temps...

Informatique

• Nous avons abordé plusieurs sujets sur la sécurité et la confidentialité sous Unix et sous GNU/Linux. Cela a commencé par deux collègues de travail, dont l'un avait apporté son PC portable professionnel. Comme il s'est connecté pour faire quelques expériences, l'autre a remarqué comment il saisissait son mot de passe. Et ce n'était pas le mot de passe normalisé !
• Guillaume rappelle que le premier combat de RMS fut de convaincre ses camarades du MIT que ce n'est pas bien de mettre des mots de passe, cela donne un pouvoir abusif à root et les autres utilisateurs sont brimés. Depuis cette époque, de l'eau a coulé sous les ponts et le système GNU/Linux a été diffusé avec des mots de passe. Cela dit, il reste encore des traces du combat de RMS contre les mots de passe. En effet, le groupe wheel n'existe pas sous GNU/Linux, alors qu'il existe sur tous les autres Unix. D'autre part, tout le monde a le droit de faire un su sous GNU/Linux, alors que seuls les membres du groupe wheel peuvent le faire sous les autres Unix.
• Guillaume et un autre parlent d'un système Unix (peut-être GNU/Linux) configuré au niveau de sécurité 5. Sur un tel système, impossible de travailler normalement. Si l'on veut savoir pourquoi la machine rame, d'habitude on fait un ps. Ici, on ne peut faire un ps que si l'on connaît le PID du processus à surveiller. D'autre part, la complétion des commandes du shell ne fonctionne pas. Ce n'est pas une mesure de sécurité en tant que telle, c'est un effet secondaire et pervers d'une autre mesure de sécurité : les utilisateurs ont un accès +x sur le répertoire /usr/bin, mais pas d'accès +r. Impossible donc de déterminer la liste des exécutables situés dans le $PATH et dont le nom correspond aux caractères déjà tapés. Les bâtons dans les roues sont si nombreux que ceux qui connaissent le mot de passe de root l'utilisent souvent, histoire de travailler un peu plus aisément.
• Jérôme se souvient d'une machine AIX sur laquelle il a travaillé il y a de nombreuses années. Les utilisateurs de cette machine avaient pour consigne d'utiliser le code root avec parcimonie pour se connecter. D'un autre côté, lors du démarrage de la machine, le mot de passe de root était affiché en clair juste après le rappel de cette règle... Encore heureux que le mot de passe n'était pas affiché sur l'écran de login !
• BooK évoque une intervention au cours de laquelle il devait se connecter en root sur une machine. Seulement, l'administrateur en titre était en congés et personne d'autre ne connaissait le mot de passe. Il a toutefois réussi à sortir de cette impasse. Il s'est connecté en root sur une autre machine dont l'administrateur était présent. De cette machine, il s'est connecté en rsh sur la machine qui l'intéressait. Pas besoin de la séquence de login, a pensé la machine cible. Si l'utilisateur est root sur la machine appelante, il mérite d'être root sur la machine appelée ! Philippe a alors édité /etc/passwd. Il a mis en commentaire la ligne concernant root et en a créé une autre dans laquelle il a inscrit la forme cryptée d'un mot de passe qu'il connaissait. Il a pu se connecter depuis la console de la machine sur laquelle il devait travailler et il n'avait plus besoin de la session rsh. Avant de partir, il a rétabli l'ancienne version de la ligne root de /etc/passwd. Jérôme tient à préciser qu'en réalité, Philippe n'a pas « mis en commentaire la ligne de root ». En fait, il a créé un utilisateur #root.
• Un des participants à la réunion a évoqué une intervention chez un client. Là, l'administrateur système a été fier de lui donner le mot de passe de root, car ce mot de passe venait d'un calembour faisant référence à un lieu touristique américain bien connu.
• Pour éviter les mots de passe fragiles, il existe un certain nombre de consignes : au moins un chiffre, au moins une lettre majuscule, au moins un caractère qui n'est pas alphanumérique, nombre minimum de caractères, etc. Mais si l'on veut que le mot de passe soit encore prononçable, cela réduit l'ensemble des valeurs possibles et BooK trouve que cela affaiblit le système de mot de passe. Quelqu'un trouve au contraire que cela ne pose aucun problème, même pour quelqu'un dont la langue maternelle n'est ni l'allemand ni le russe. Mais pour lui, un mot de passe prononçable, c'est un mot de passe tel que : « zed crochet ouvrant double-vé elle err dé neuf point d'exclamation a hache ».
• Sur un Unix propriétaire, les mots de passe étaient limités à huit caractères. Ce qui veut dire que si l'on saisissait neuf caractères, n'importe quelle séquence de neuf caractères, la session était ouverte avec le code utilisateur demandé.
• Philippe (Bl) a voulu se renseigner auprès de Nicolas sur la différence entre l'exploitation et la production sur un site informatique. Dans ses explications, Nicolas a évoqué les anciens temps, avant la généralisation d'Unix et de Windows. De nos jours, un certain nombre de tâches répétitives sont assurées par des logiciels ou des robots, mais cela n'a pas toujours été le cas. Dans le temps, il fallait parfois une équipe d'une dizaine de personnes pour assurer le fonctionnement de deux mainframes. Sur ces dix personnes, une ou deux dominent le sujet et sont capables de réagir à une situation imprévue. Les autres se contentent de suivre fidèlement les procédures rédigées par les deux premières et ne sont pas en mesure de faire face à l'imprévu. Nicolas évoque notamment une personne qui avait vu s'afficher à l'écran : « Tapez votre login: ». La personne avait tapé « v », « o », « t » et ainsi de suite jusqu'à « i » et « n » et là, elle avait attendu que la machine fasse quelque chose...
• Nicolas a évoqué le tuning des bases de données. Normalement, cela devrait faire partie dans ses attributions. En fait, c'est un domaine tellement pointu qu'il est plus judicieux de faire appel à un spécialiste de chez Oracle ou de chez Sybase pendant trois ou quatre jours par an et de leur demander de faire le tuning des bases sur le serveur machin et sur le serveur truc. Et de toutes manières, les problèmes de performance, c'est dans 80 % des cas la faute des programmes applicatifs, dans 17 % des cas un problème de matériel et le reste du temps, c'est la base de données qui est en cause (pourcentages approximatifs).
• Nicolas cite le cas d'un programme applicatif dans lequel un SELECT comportait plus de 16 jointures. Avec les règles d'indentation, on se retrouvait au bout de quelques lignes avec une page blanche, il fallait scroller horizontalement pour lire quelque chose d'intéressant. Il cite également une application qui avait été migrée d'un serveur ancien, avec un petit processeur et pas beaucoup de RAM vers un nouveau serveur, muni d'un processeur puissant et d'une quantité confortable de RAM. La même requête passait très bien sur l'ancien serveur, mais elle n'aboutissait pas sur le nouveau. Au bout d'un certain temps de débuggage, Nicolas et l'expert qui s'occupait du problème ont compris que le SGBD Oracle dispose de deux méthodes d'optimisation. La première, qui s'applique à des serveurs de faible puissance, donnait de bons résultats sur l'ancien serveur de Nicolas. La seconde, mise en place sur les gros serveurs, s'est révélée inadaptée à ce cas-là.
• Dans le temps, il y a 10 ou 15 ans, une base de données qui occupait 20 Mo sur les disques était une grosse base de données. Maintenant, on trouve communément des bases de données de plusieurs Go. À un moment de la discussion, Nicolas a même prononcé le mot « téra-octet » mais je ne crois pas qu'il parlait d'une base de données existante.
• Guillaume parle des machines qu'il a récupérées de la casse de chez HP. Il y avait notamment quatre machines hexa-processeurs, voire octo-processeurs. Comme elles pesaient très lourd, Guillaume et ceux qui l'accompagnaient ont bricolé ces machines pour augmenter au maximum la capacité RAM de l'une d'entre elles, de façon à n'emporter que celle-là. Avec 20 Go de RAM, certains participants à la réunion pensent que l'on pourrait faire un miroir CPAN qui tiendrait en RAM. Quelle rapidité ! D'autres pensent plutôt à une machine pour les smoke tests des Perl 5 Porters. Guillaume pensait à d'autres développements comme celui de KDE.
• Paul-Christophe et BooK ont parlé des livres publiés par Microsoft Press. Curieusement, les ouvrages cités sont des ouvrages de bonne qualité, alors que l'on n'a pas tendance à associer qualité et Microsoft. [ Il s'agissait entre autres de Code Complete de Steve McConnell, et Writing Solid Code de Steve Maguire. -- BooK ]
• BooK a appris que la nouvelle version de vim permettait d'éditer la liste des fichiers d'un répertoire. C'est le mode dired d'emacs en plus léger. Si, sur cette liste, on utilise le mode replace (commande R en mode écran), on écrase le nom d'un fichier et cela renomme ledit fichier. BooK a voulu essayer de voir ce que donnerait une commande de filtre (du genre 8!!sort en mode écran) mais l'expérience semble ne pas avoir été concluante.
• Nous avons évoqué une nouvelle récente, l'apparition du premier ver pour téléphone portable. Le ver n'affecte que les téléphones Nokia d'un certain type. Si Bluetooth est en service et que vous passez à côté d'une borne contaminée, alors votre téléphone est contaminé lui aussi, même si vous ne l'utilisez pas à ce moment-là. Ce ver ne fait rien de nocif, à part sa propagation. Les actions méchantes, c'est pour la prochaine fois.

Divers

• BooK m'a accusé de confondre la cryptographie et la stéganographie. Selon lui, j'ai formulé une remarque sur l'article de Jérôme sur LDAP et dans cette remarque, j'aurais évoqué l'échange de lettres entre Musset et George Sand en présentant cela comme de la cryptographie. Depuis, j'ai relu l'historique des messages de commit. Ma remarque était en réalité une interrogation sur les nuances de signification entre les termes « décoder », « déchiffrer » et « décrypter » et je n'ai pas du tout évoqué la littérature du XIX^e siècle. Sébastien (« Maddingue ») a donné des explications en réponse à mon interrogation et c'est lui qui a évoqué George Sand, tout en l'associant à la stéganographie. BooK signale aussi que l'association dont l'objet est de perpétuer la mémoire de George Sand essaie de dire que l'échange de lettre entre Musset et George Sand n'a jamais eu lieu, mais l'association n'arrive pas à se faire entendre. Signalons en outre que pour certains participants à la réunion, le correspondant de George Sand s'appelle Alfred de Musset, pour les autres il s'agit de Georges Musset.
• Quelqu'un [ Guillaume ? Je crois bien que c'est lui, mais il n'en est pas sûr. ] a lu le résumé de la biographie de Ronald Reagan. Quel grand homme c'était ! Selon cet article, en effet, c'est grâce à lui que le mur de Berlin est tombé, car il n'a pas hésité à se rendre seul en Europe de l'Est. Et ce n'est pas le seul de ses exploits. Et moi qui croyais que c'était un acteur ! D'autres font remarquer que Reagan avait la maladie d'Alzheimer (après avoir dit Parkinson) et que ces maladies cérébrales semblaient être une caractéristique des présidents républicains. Les présidents démocrates, quant à eux, ont plutôt tendance à souffrir des attentats. [ C'est même pas vrai ! Garfield et McKinley étaient républicains. ]
• Nicolas évoque la construction des ponts. L'ingénieur ou l'architecte commence par évaluer le nombre de véhicules que ce pont devra supporter. Puis il calcule quelle charge cela fait. Ensuite, il applique un facteur de sécurité, qui peut doubler, voire quadrupler la valeur de la charge nominale. Et malgré cela, on sait que le pont est prévu pour être utilisé pendant quelques décennies. Le risque zéro n'existe pas et on peut toujours avoir des surprises. Par exemple, on a constaté il y a quelque temps que les ponts en béton avaient un problème. Au sens figuré, on appelle cela le « cancer du béton » et au sens propre, si les souvenirs lointains de Nicolas ne le trahissent pas, cela s'appelle une « alcali-réaction ». Et du coup, la valeur de la résistance du béton est moindre que prévue. Je rappelle la méthode romaine pour construire les ponts. Lors de la mise en service du pont, l'ingénieur devait se tenir sous le pont (lu dans le Forum sur les Risques technologiques).
• Pour Guillaume, il est plus facile de diviser 30 par 3 que de diviser 30 par 2. Pour économiser des efforts de calcul mental à Guillaume, ses interlocuteurs lui ont énuméré les diviseurs de 30 (dans le désordre). C'est tout naturellement que la discussion a dérivé vers les nombres premiers puis vers le crible d'Erathostène. BooK tente de nous faire admettre qu'il faut calculer des racines carrées pour établir la liste des nombres premiers par cette méthode. Guillaume trouve que ce n'est pas indispensable, au rythme actuel des processeurs, si on passe au crible la liste des nombres de 2 à 100 000, on effectue les itérations jusqu'à 100 000, cela gaspillera un temps infime.
• Nicolas portait une chemise à fleurs, imprimée dans les tons vert et blanc (pour autant que l'éclairage du sous-sol permette de distinguer les couleurs correctes). Sylvain a manifesté son admiration pour la chemise. Il était prévu que Nicolas et Sylvain se voient pour des raisons professionnelles le vendredi suivant (formation assurée par Sylvain dans l'administration où travaille Nicolas). Comme Sylvain sera obligé de porter la cravate, pour le narguer, Nicolas a promis qu'il porterait une chemise réellement hawaïenne ou tahitienne, avec des fleurs de couleur vive. Et un bermuda.
• Guillaume est allé récemment à Vienne et il a été très étonné de voir une rue Stavisky. Quel ne fut pas son étonnement de voir qu'un obscur fait divers franco-français était si connu que l'Autriche avait décidé de le commémorer avec des noms de rue ! Il a lu la plaque de plus près et il s'est rendu compte qu'en fait, la rue était à la mémoire de Stravinsky, le musicien.
• Guillaume a également parlé d'Alexandre Jacob, mais je n'ai quasiment rien entendu sur ce sujet. J'ai tout juste cru comprendre qu'il s'agissait d'un anarchiste et que certains pensent qu'il a été un des modèles pour le personnage d'Arsène Lupin.
• Nicolas a évoqué les fims de Paul Verhoeven. De nombreuses personnes n'aiment pas, parce qu'elles prennent ce film au premier degré. Comment prendre au premier degré Starship Troopers quand on voit apparaître l'un des héros, un parapsychologue, dans une tenue qui évoque la Gestapo et qui porte comme emblème un dessin ressemblant beaucoup à l'aigle nazi ? Quand un personnage secondaire se lance dans un discours patriotique se terminant par : « C'est l'armée qui a fait de moi l'homme que je suis. » et quand la caméra révèle alors que l'homme est amputé des deux jambes ? Et ce n'est pas le seul film de Verhoeven dans ce cas. Robocop (le premier du moins) est une critique de la société américaine.
• Il a été question également de Demolition Man et d'un autre acteur qui est en train de mal tourner. Dans ce film, le personnage interprété par Stallone (ce n'est pas Stallone qui tourne mal, attendez) est projeté dans le futur. Quelle n'est pas la stupéfaction de ce personnage de voir des établissements nommés en souvenir du Président Schwartzenegger ! Le film comportait déjà les réflexions entendues à l'occasion des dernières élections de Californie, certaines personnes souhaitant un changement de la constitution (c'est-à-dire un amendement) pour retirer la clause de naissance sur le territoire américain pour pouvoir devenir président.
• Comme BooK va déménager à Lyon, la discussion a porté sur les charmes touristiques de cette ville et pas seulement son café Perl. Guillaume a parlé d'un concert mouvementé auquel il a assisté.
• Alors que nous parlions de navigateurs web, BooK a demandé à Jérôme : « Qui est le browser Amaya ? » La réponse, que Jérôme n'a pas su donner, était : « Julien ». C'était une private joke. Philippe nous a expliqué comment il fallait comprendre l'astuce, mais quelqu'un lui a fait remarquer que pour une private joke, il ne faut justement pas donner d'explication pour qu'elle puisse rester private. Je m'en tiendrai donc là dans ce compte-rendu. La prochaine fois, il faudra être présent pour avoir les explications.
• Il y a eu également des vannes vaseuses. Par exemple, « Il ne faut rien gâcher, il faut tout manger. » Euh bon, je ne vais pas m'appesantir sur les détails...
• Également, à quatre ou cinq reprises, il y a eu un blanc dans la conversation. Même D@vid ne disait rien (alors qu'il avait prévu de parler de la linguistique des langues elfes au Troisième Âge). « Un ange passe », a-t-on coutume de dire en France. Ou bien « un flic vient de naître » dit-on en Russie (lu dans On y va !, autobiographie de Constantin Feldzer).