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.
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 + 0eq$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 passub hashem{ +{@_}}# oksub 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.
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...
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.
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 XIXe 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
ConstantinFeldzer).