La visite de Jérôme

Un historique de toutes nos réunions

---

Table des matières

• jeudi 4 novembre 2004 (précédent)
• mercredi 1 décembre 2004 (suivant)
• Tous les comptes-rendus

mercredi 17 novembre 2004

La voix du secrétaire (Jean) avec l'aide d'Emmanuel

Alors que la rédaction du compte rendu était en bonne voie mais qu'il restait encore la mise en forme, j'ai ressenti des douleurs au poignet et à l'avant-bras droits. Il m'est alors devenu quasiment impossible de taper sur un clavier avec les dix doigts. Quant à taper sur un clavier avec la main gauche seulement, d'une part, c'est beaucoup plus lent, d'autre part, c'est très fatigant. Compte tenu de mes activités diurnes et professionnelles, il m'était impossible de taper de texte le soir chez moi. J'ai donc laissé le compte-rendu en suspens jusqu'à la réunion du 1^er décembre où j'ai pu obtenir l'aide d'Emmanuel. Une partie de ce compte-rendu a été tapée par Emmanuel qui a recopié mon texte manuscrit.

Présents à la réunion, en fonction de la disposition autour de la table

• Emmanuel,
• Anthony
• Guillaume,
• Philippe (Bl),
• moi
• Jérôme le lyonnais,
• Nicolas,
• Rafael,
• Olivier,
• Dam's,
• David (Sniper),
• Éric (glb),
• et notre tsar David.

Nous avons mangé des oeufs mayonnaise, des blue-cheeseburgers bleus, des bacons cheesburger, des spaghetti bolognese sans persil, des magrets de canard, des tartiflettes, des salades auvergnates, des tartes aux pommes, des nègres en chemise et des dames blanches. Nous avons bu de la Warsteiner, de la Furstenberg après épuisement de la Warsteiner, de la Blanche (plus facile à faire comprendre que Hoegarden) et autres bières, de l'Orangina et une margarita.

Comme à l'accoutumée, les sujets ont été Perl, Internet, l'informatique et le reste.

Perl

• Lors d'une réunion précédente, Stef a dit beaucoup de bien sur YAML [ discussion que j'ai manquée et dont je n'ai pas rendu compte ]. Les participants à la réunion, notamment Nicolas, sont plus dubitatifs. L'un des principaux reproches est que la spécification du langage YAML prévoit l'utilisation d'Unicode, mais que le module Perl ne le fait pas encore.
• Pour ses fichiers de configuration, Jérôme préfère utiliser Data::Dumper. Les données sont sauvegardées dans un format assez commode à manipuler, puisqu'il s'agit du langage Perl. Nicolas, quant à lui, préfère le module Storage. [ Je n'ai trouvé aucun module dont le nom soit Storage et rien d'autre. Je pense que Nicolas a voulu dire Storable. ]
• Jérôme nous raconte son travail sur le Capacity Planning, dont il avait déjà parlé sur la liste. L'outil sur lequel il a travaillé relève des données de performances (utilisation CPU, nombre de processus, mémoire, swap, utilisation disque, etc) sur plusieurs machines et les archive via rrdtool, de manière à pouvoir surveiller ces machines en temps réel et à pouvoir également investiguer un incident passé, surout que rrdtool permet de grapher très facilement par la suite. Les fichiers contenant les données extraites sont archivés au format tar. Jérôme a donc écrit quelques scripts Perl pour traiter les archives tar et il s'est rendu compte qu'il y avait de gros problèmes de performances. Ces problèmes étaient dus au module Archive::Tar, un module pur Perl qui charge en mémoire la totalité de l'archive pour pouvoir la traiter. Il a donc remplacé le module par un system("tar ...") et ça a fonctionné beaucoup mieux. Il est passé de 16Mb en 1h24 à 73Mb en 25mn. Mais ce n'était pas encore suffisant. Avec le module Devel::DProfPP et l'utilitaire dprofpp, il s'est aperçu que l'autre responsable des mauvaises performances était le module Log::Dispatch. En le remplaçant par des fonctions écrites à la main, Jérôme a obtenu des performances convenables.
• Ce n'est pas le seul grief de Jérôme à l'encontre de Log::Dispatch. Ce module fonctionne en créant des channels tels que l'écriture dans un fichier, l'écriture sur la console, l'envoi d'un SMS si la gravité est supérieure à telle valeur, etc. Mais une fois ces channels définis, il n'est plus possible de modifier leurs attributs.
• Pour revenir à Data::Dumper, Guillaume signale un comportement curieux de ce module. Il initialise une très grosse matrice carrée et demande le vidage correspondant par le module :

  use Data::Dumper;
  my $matrix; 
  for my $i (0 .. 999) {  $#{$matrix->[$i]} = 999 };
  open F, '> /dev/null' or die $!;
  print F Dumper($matrix);
  close F or die $!;
  

  Cela prend un certain temps, bien sûr, mais rien de catastrophique. Il l'initialise différemment et il redemande le vidage de la matrice :

  use Data::Dumper;
  my $matrix; 
  for my $i (0 .. 999)
    { for my $j (0 ..999) { $matrix->[$i]->[$j] = undef } }
  open F, '> /dev/null' or die $!;
  print F Dumper($matrix);
  close F or die $!;
  

  Le temps nécessaire est alors beaucoup plus important. Il a lancé les deux scripts en inhibant la ligne print par un dièse et a mis ainsi en évidence que c'est l'appel de Dumper() qui provoque la différence énorme de temps. Voici ses résultats :

  	$#matrix =	boucles imbriquées
  print	4.15 user 0.92 system 0:05.38 elapsed	19.44 user 2.11 system 0:23.94 elapsed
  #print	0.05 user 0.01 system 0:00.09 elapsed	1.50 user 0.05 system 0:01.65 elapsed

  Rafael pense que c'est un effet pervers d'une optimisation du module. Au cas où une structure complexe comporterait à des endroits différents des références à une même sous-structure, Data::Dumper utilise la même valeur qu'il référence deux fois ou plus. Le module est donc obligé de garder en cache et de comparer toutes les références qu'il crée. Avant la modification de la matrice, le module n'a pas besoin de faire cette recherche. Après la modification, cette recherche, coûteuse en temps de traitement, devient nécessaire.
• David et quelques autres ont évoqué POE. C'est le seul framework en Perl qui permette de faire de la programmation événementielle de manière générale. Il faut évidemment organiser le programme en termes de fonctions de rappel (callbacks). Mais, ce module est difficile à maîtriser. Tant qu'il s'agit de regarder les exemples dans le « livre » de recettes (cookbook) fourni avec le module, ça va. Mais lorsque l'on veut traiter un problème spécifique, c'est beaucoup plus ardu ! Cela rappelle à certains la programmation pour Windows 3.1, où ils simulaient la programmation événementielle avec une boucle comportant une structure switch -- case et où les divers gestionnaires d'événements communiquaient entre eux avec des variables globales.
• Anthony, qui vient ici pour la première fois, demande s'il est fréquent d'avoir des participantes aux réunions. Nous lui répondons que de temps en temps, un mongueur vient avec sa compagne, que cette compagne passe une bonne soirée et promet de venir à la suivante, mais qu'hélas, elle ne tient pas sa promesse. Les seules qui soient venues à plusieurs reprises sont la compagne de Kai et Natacha, la compagne de Sniper.
• Anthony demande également pourquoi il y a des comptes-rendus. Nicolas répond que c'est pour que les participants puissent se souvenir de ce dont il a été question. [ En fait, les premiers comptes-rendus ont dû être écrits pour peupler le site web et pour montrer que le groupe était actif. Maintenant, le site web comporte de nombreuses autres pages, comme celle des $A++ et les galeries de photos, mais les comptes-rendus sont devenus une institution de Paris.PM. ]
• Jérôme ne savait pas que BooK avait déménagé et était donc lyonnais depuis quelques semaines. Il faut dire que le groupe Lyon.PM se réunit rarement. À quoi bon organiser des réunions lorsque l'on est deux ou trois ? Je fais remarquer qu'il y a déjà eu des réunions de Paris.PM à trois, voire à deux.
• Si Lyon.PM a un effectif réduit, c'est encore pis pour Grenoble.PM. En effet, il y a un seul mongueur grenoblois. D'un autre côté, un effectif de 1 permet d'organiser des réunions à domicile, sans avoir besoin de se demander à quelle heure les transports en commun s'arrêtent et à quelle heure ils reprennent. D'un troisième côté, c'est plus difficile de consacrer une réunion à boire de la bière si la femme de l'unique mongueur est là pour surveiller son époux...
• Depuis le temps que l'on attendait la scission entre la liste Perl et la liste Paris ! La scission est effective depuis quelques semaines. Mais Guillaume ne s'en est pas rendu compte et c'est ainsi qu'il a manqué un certain nombre de discussions sur les dates, notamment la visite de BooK et les décalages de date pour la visite de Jérôme aujourd'hui et celle de Jeff en décembre.

Internet

• L'une des serveuses arborait un T-shirt avec un gros « BE ». Cela nous a amenés à évoquer le TLD de la Belgique. Nicolas n'est plus le seul à s'être offert un nom de domaine en .be, Éric en a un également. Nous suggérons d'autres noms de domaine dans d'autres pays, comme putri en Allemagne ou apo en Israël.
• Le PLF n'a toujours pas son nom de domaine personnel. Quel serait le TLD le plus approprié pour le PLF ? Sont suggérés le TLD .ru de la Russie, le TLD .uk de l'Ukraine, puis le véritable TLD .ua de l'Ukraine.
• Une discussion s'est tenue sur les mécanismes d'accusé de réception par courrier électronique. Le protocole SMTP prévoit en fait l'inverse, un mécanisme de compte-rendu d'échec, lorsqu'un serveur SMTP ne parvient pas à contacter le serveur SMTP suivant. Dans ce cas, au bout de trois jours d'essais infructueux, le serveur SMTP renvoie à l'émetteur un message pour rendre compte de l'échec. Il est toutefois impossible de tirer parti de cette fonctionnalité pour dire que l'absence de compte-rendu d'échec est un compte-rendu implicite de succès. D'une part le délai de trois jours est trop long, d'autre part on peut envisager le SNAFU suivant : un serveur SMTP reçoit un message à transmettre. Il acquitte la réception. Puis, avant d'avoir pu flusher les tampons vers le disque, le serveur plante. Au redémarrage, toute trace du message a disparu et le message n'arrivera jamais à son destinataire.
• Il existe des solutions pour la génération d'accusé de réception, mais chacune de ces solutions est spécifique à un client de courrier électronique. Il n'existe aucune norme et aucun standard. Donc, dans un environnement hétérogène, cela ne fonctionnera pas. Nicolas donne son exemple. Il est le seul dans son service à utiliser GNUS. Du coup, de temps à autre il reçoit des rappels à l'ordre pour lui demander de prendre connaissance de tel ou tel message, alors qu'il les a déjà lus mais que GNUS n'a pas envoyé d'accusé de réception.
• Est-ce vraiment un problème de ne pas pouvoir disposer de la génération automatique des accusés de réception ? Est-ce vraiment un problème si vous recevez du spam et que le spammeur n'est pas avisé que votre adresse est valide ?
• Nicolas évoque un réseau privé avec un variante curieuse du protocole DNS. La correspondance entre les adresses IP et les noms est listée sur une page web disponible sur un serveur. Pour la résolution inverse des adresses IP, il faut donc récupérer la page web par wget puis décortiquer le source HTML.
• Quelqu'un évoque un firewall de son réseau. Lorsque le firewall plante, cela bloque le switch auquel il est rattaché et du coup plus rien ne passe. L'interlocuteur de ce quelqu'un fait remarquer que la vocation première des firewalls est d'empêcher les paquets indésirables de passer. Donc, même planté, le firewall continue à assurer son rôle.

Informatique

• La nouvelle vient de tomber il y a quelques heures, quelques distributeurs de Linux, à savoir Mandrake, Progeny, Connectiva et Turbolinux viennent de former le groupe LCC (Linux Core Consortium selon la nouvelle, Losers' Core Consortium selon les mauvaises langues). Ce groupe est basé sur la LSB, un standard qui va plus loin que le standard FHS. Rafael a entendu parler du groupement en même temps que nous, alors que nous pouvions penser qu'il était mieux placé pour le savoir. Ce consortium peut être vu comme une réplique à la création d'United Linux (groupe dont faisaient partie également Connectiva et Turbolinux) ou bien comme un contrepoids à l'influence de Red Hat.
• Guillaume enseigne l'informatique à des étudiants. Un jour, il avait donné comme exercice de créer une page web avec un compteur, hébergée sur un serveur où tournait un serveur d'applications (du genre Tomcat). La réponse de 80 % des étudiants a été : « Il faut installer une base de données et créer une table pour y stocker la valeur du compteur. » La bonne réponse était de créer un servlet qui s'occuperait d'afficher le compteur et de l'incrémenter. En effet, à l'inverse des CGI, les servlets sont persistants. Mais, comme le remarque Guillaume, quand il est question de persistance, la première idée qui vient à l'esprit est « base de données ». Hélas, pour la plupart, les gens adoptent le premier outil auquel ils pensent et n'examinent pas les autres possibilités. Quelqu'un donne la métaphore d'un bricoleur qui utiliserait un tournevis pour enfoncer des clous, creuser des trous dans les murs et appliquer une couche de peinture sur lesdits murs.
• Un autre critère pour choisir tel ou tel outil est qu'il soit buzzword-compliant. C'est ainsi qu'à plusieurs reprises lors de la réunion, nous avons évoqués des outils de type J2EE.
• Comme Guillaume travaille à l'INRIA, nous lui demandons si le problème du mauvais outil existe là-bas et si tout le monde est invité à choisir, voire obligé d'utiliser OCaml. Il semblerait que non. Il existe quelques applications écrites en OCaml, comme la gestion des jours de congés, mais chacun peut utiliser le langage qui lui paraît le mieux adapté.
• Quelqu'un a évoqué la discussion qu'il a eue avec son interlocuteur chez son distributeur d'Unix payant. L'interlocuteur a suggéré une migration pour changer de version. Cela prendra, a-t-il dit, un quart d'heure, pas plus. Cela nous a fait beaucoup rigoler.
• Nous avons raconté plusieurs anecdotes, plus ou moins racontables, à propos de sauvegarde et d'archivage, ce soir-là. C'est Nicolas qui a commencé en racontant comment cela se passe avec Oracle. C'est simple, il suffit de lancer le script qui va bien et de tester le code retour : 0, c'est bien, 1 ou plus, quelque chose a foiré. En fait, c'est un peu plus compliqué. Oracle peut émettre des messages d'avertissement qui, à leurs yeux, ne justifient pas un code retour à 1. Nicolas ayant constaté que ces messages d'avertissement témoignent de problèmes réels et doivent être pris en considération quand même, il a ajouté quelques lignes à la suite pour examiner le fichier log et déterminer s'il contient la mention successfully ended with warnings. Rassuré ? Non, parce que si la sauvegarde s'est bien passée, cela ne veut pas dire pour autant qu'elle permettra d'assurer la restauration des données. Donc, à titre de vérification, Nicolas lance la restauration sur une base Oracle installée sur /dev/null et teste le code retour. Et examine le fichier log pour savoir s'il contient la mention successfully ended with warnings.
• Sniper raconte un incident en deux épisodes survenu sur un site où il a travaillé. Un jour, une panne se produit sur une unité de sauvegarde. Sniper téléphone donc au fabricant de l'appareil qui lui répond : « C'est d'accord, nous intervenons dans les trois heures, comme c'est marqué dans le contrat. » Trois heures passent, personne ne se présente. Sniper retéléphone pour s'entendre dire : « Mais nous n'avons trouvé aucune trace de votre contrat. Êtes-vous sûr de nous l'avoir envoyé ? » Sniper contacte son responsable, puis le service comptable et, en raison de l'urgence du problème, le responsable demande à Sniper de souscrire un contrat de maintenance, dans la limite d'une enveloppe budgétaire. Tout s'arrange, les techniciens interviennent, la machine est réparée, tout va pour le mieux dans le meilleur des mondes.
  Quelques mois passent. La machine tombe de nouveau en panne. Comme précédemment, Sniper téléphone et comme précédemment, attend trois heures en vain. Comme précédemment, il retéléphone et obtient la même réponse, « Nous ne trouvons pas votre contrat. Êtes-vous sûr de l'avoir souscrit ? ». Sniper leur a alors répondu qu'il transmettrait le problème à qui de droit et que leur service des contentieux contacterait le service de dépannage du constructeur. 38 minutes plus tard, un technicien se présentait pour dépanner l'unité de sauvegarde.
• Éric a évoqué une boîte, qui avait l'obligation légale de conserver des archives pendant x années. Un jour, la direction a décidé de faire évoluer son système d'archivage pour en avoir un plus puissant. Le constructeur est arrivé avec la nouvelle machine, a débranché l'ancienne, a installé la nouvelle, a chargé l'ancienne sur le camion et est reparti. Le client a conservé ses archives d'il y a x années. Bon, c'est vrai, le format de ces bandes était incompatible avec la nouvelle machine, mais où est le problème ?
• Nous avons aussi parlé d'installation de logiciel. La première anecdote est due à Jérôme. Lors d'une installation, c'est lui qui manipule le serveur, en aucun cas il ne laisse le technicien d'installation faire ce qu'il veut sur la console du serveur. Le technicien doit se contenter de lui donner les instructions. À un moment, ce dernier lui précise que le logiciel doit tourner sous root. Jérôme demande pourquoi. Compte tenu des spécifications du logiciel, rien ne justifie l'utilisation de root : pas de port IP inférieur à 1024, pas de commande réservée, pas de mise à jour des répertoires du système, rien de tout cela. Jérôme est resté sur ses positions et le technicien est reparti avec la question, comment faire fonctionner le programme avec un code utilisateur disposant de droits limités. Quelques jours plus tard, Jérôme a reçu la réponse :

  Nous comprenons que votre politique de sécurité vous impose de ne pas utiliser le code root pour faire fonctionner notre programme. Nous avons étudié la question et nous vous communiquons la méthode pour faire fonctionner notre programme avec un code utilisateur normal. Pour ce faire, dans le script xxx à la ligne nn, veuillez insérer sudo...

  En effet, l'assistance technique avait tout compris à propos des problèmes de sécurité !
• Au sujet de l'installation d'un autre logiciel, Jérôme souhaitait l'installer dans un répertoire spécifique. Il a donc bien spécifié le chemin de ce répertoire dans le script d'installation. Mais au bout d'un certain temps, il a vu apparaître à son grand déplaisir des fichiers qui s'installaient dans /opt/xxx. Une mauvaise langue a demandé si Jérôme n'a pas vu passer également des fichiers dans c:\Program Files\xxx.
• Dans le cadre de son travail, Jérôme collabore avec des Suédois. Il a pu observer qu'il y avait une nette différence entre les dossiers d'installation écrits par lui et ses compatriotes et ceux écrits par les Suédois. Un dossier d'installation français est concis, avec la liste des opérations à effectuer, les contrôles pour s'assurer que l'installation se déroule correctement. Dans un dossier d'installation suédois, on trouve beaucoup plus de détails. Par exemple, la liste détaillée des commandes pour mettre à jour les fichiers de configuration lorsque l'on utilise vi.
• Cela s'est passé entre un mongueur administrateur et un de ses collègues, un développeur. Le développeur a demandé à son admin d'installer la nouvelle version d'un logiciel qu'il avait écrit. Pour éviter d'installer n'importe quoi, l'admin jette un coup d'oeil dans le Changelog... Pas de Changelog ! Il demande au developpeur ce qui a changé, « Rien, ou quasiment rien. » Un peu plus tard, l'admin revient à la charge : « Pourquoi as-tu changé telle fonction dans tel fichier ? Et telle autre fonction dans tel autre fichier ? Et... » Regard surpris du collègue qui, semble-t-il, ne connaît pas diff -r.
• Une anecdote qui se rapproche d'une réflexion de Briac. Quelqu'un a raconté qu'une société devait fournir un logiciel à sa boîte et que ce logiciel serait installé sur un serveur dédié. Lorsque le technicien chargé de l'installation est arrivé, il avait un iBook. À l'époque, Briac avait insisté sur le besoin modeste en performances qui permettait de se contenter d'un ordinateur portable tenant lieu de serveur aux performances tout aussi modestes ; lors de la présente réunion, un autre critère a été évoqué, le fait que, sans la dépense supplémentaire d'un onduleur, le serveur est insensible aux coupures de courant durant jusqu'à une ou deux heures.
• Comment faire le tuning d'une machine (avec un Unix payant) ? Très simple, a dit quelqu'un. Il suffit d'installer les GNU-Tools et de placer /usr/local/bin avant /usr/bin dans le $PATH.
• Quand Emmanuel a allumé son PC portable, Guillaume a jeté un coup d'oeil sur sa configuration et il a constaté qu'il y avait de nombreux ports TCP/IP ouverts. Il attribue cela aux nombreuses « bonnes idées » des développeurs de Red Hat, qui ont au fil des ans installé de nombreux services avec leur propre port TCP/IP, puis les ont laissé tomber sans pour autant refermer le port.
• Microsoft a diffusé les spécifications matérielles pour les machines sur lesquelles Longhorn sera installé. Il faudra au minimum un bi-processeur et une carte graphique. Même sur les machines configurées en serveurs ? Oui, même les serveurs Longhorn auront besoin d'une carte graphique.
• L'explication se trouve peut-être dans la mésaventure qui est arrivée à un participant à la réunion. Des collègues lui ont signalé qu'un serveur avait des performances déplorables. De temps en temps, on le faisait redémarrer. Il fonctionnait comme il faut pendant 5 minutes, puis les performances s'effondraient. Au bout d'un certain temps, le narrateur a compris la cause du problème. Le serveur était configuré avec un économiseur d'écran Open-GL, donc particulièrement vorace en termes de cycles CPU. Tout ceci pour un serveur en rack, sans clavier, sans souris et sans écran, sur lequel on travaille uniquement par tunnel SSH à partir d'un poste client.
• La discussion a porté sur les logiciels de travail en groupe, tels que SourceForge. Mais les logiciels de ce type ont tellement de fonctionnalités que cela désoriente le programmeur de base, confronté brusquement à un tel logiciel. Il vaut mieux y aller progressivement, en installant le logiciel, mais en activant seulement, par exemple, la gestion des sources, style CVS. Puis, progressivement, à chaque fois qu'un utilisateur en exprime le besoin, on active les autres fonctionnalités une à une.
• Comment se faire mousser en prétendant être à la pointe du progrès ? C'est simple, il suffit d'utiliser un logiciel que personne d'autre ne connaît. « Vous utilisez CVS ? C'est ringard, j'utilise Subversion » « Vous êtes sous Linux ? C'est dépassé, moi, je suis sous OpenBSD ! » [ Histoire de désactiver les trolls, je précise que les opinions à l'emporte-pièce de ce genre n'ont pas vocation à être exactes, mais à déstabiliser l'interlocuteur qui croyait être à la pointe avec son Linux et son CVS. Linux et OpenBSD ont chacun leurs qualités et leurs défauts, mais Linux a une notoriété qu'OpenBSD n'a pas et dans le cas présent, cela constitue le handicap de Linux vis-à-vis d'OpenBSD. ]

Divers

• À propos de l'élection américaine, certains émettent l'hypothèse que cela arrange bien les Français, car avec Bush au pouvoir, on peut continuer à pratiquer l'anti-américanisme.
• Il a été question de la « libération » du Tibet par la Chine. Lorsque la Chine est intervenue au Tibet, les autorités chinoises avaient accompagné cela d'une campagne de bourrage de crâne, ce qui fait que de nombreux Chinois, même encore actuellement, pensent qu'avant l'intervention chinoise, les Tibétains pratiquaient l'anthropophagie et que les parents mangeaient leurs enfants.
• Nous évoquons la différence entre la Gendarmerie et le reste des forces armées. La fonction primaire des forces armées, c'est de faire la guerre. La fonction primaire de la Gendarmerie, comme pour la Police, c'est de maintenir l'ordre. Lorsqu'ils interviennent sur une prise d'otages, les groupes spécialisés tels que le GIGN, le GIPN et le RAID ont pour préoccupation majeure de neutraliser les preneurs d'otages tout en assurant la survie des otages. Ce qui contraste avec la façon dont les Spetsnaz, des guerriers, règlent les prises d'otages. Ceux-ci considèrent que les otages sont déjà passés par pertes et profits et que ce qu'on leur demande, c'est l'élimination des preneurs d'otages. D'ailleurs, lorsque la prise d'otages de la maternelle de Neuilly-sur-Seine avait eu un dénouement heureux en 1993, les Russes avaient officieusement émis des protestations car cela risquait d'établir un précédent nuisible à l'image de leurs Spetsnaz.
• Je ne l'ai pas relevé lors de la réunion, mais quelqu'un a commis un lapsus à propos de l'affaire de la maternelle de Neuilly-sur-Seine. Il a dit que le preneur d'otages s'appelait Bomberman au lieu de HB (Human Bomb).
• Pour en revenir aux Spetsnaz, il paraît que leur entraînement au close-combat consiste à passer deux heures en tête-à-tête avec un condamné à mort ou un condamné à une longue peine à qui l'on a dit : « Tu vas te retrouver face à un policier. Tu as le droit de taper. » Évidemment, les condamnés choisis pour ce genre de séance sont sélectionnés en fonction de leur force physique et de leur passé mouvementé.
• Le même jour que la réunion, il y a eu le grand plantage du réseau Bouygues. Guillaume ne s'en est pas aperçu. En effet, il ne garde pas son téléphone allumé en permanence et lorsqu'il en a eu besoin, le service était rétabli. À l'inverse, tous ceux qui gardent leur téléphone allumé en permanence sont restés en rade la majeure partie de la journée, faute de savoir qu'il fallait rebooter leur téléphone personnel en plus des serveurs Bouygues.