Présents à la réunion, en fonction de la position autour de la table
Guillaume,
Laurent,
Antoine,
Anthony,
moi,
Emmanuel,
sa Seigneurerie Dam's,
Olivier,
Nicolas,
Jérôme,
Sniper,
et David (L).
Nous avons mangé des oeufs mayonnaise, des blue-cheeseburgers et
cheeseburger, une côte de boeuf, une tartiflette, des spaghetti carbonara,
des charlottes au chocolat, des mousses au chocolat
et des tartes aux pommes. Nous avons bu de la Paulhaner, de
la Kriek, de la Stout, d'autres bières, de l'Orangina, du Pepsi
(en 25), du Coca (en 50) et une margarita.
Il n'y avait pas de Breizh Cola. Plus suprenant compte tenu
des origines du gérant de la Taverne, il n'y avait pas de
Corsica Cola, ni de bière Colomba.
Lorsque le gérant s'est adressé à Dam's pour la prise de commande,
il a utilisé un vocabulaire qui n'était peut-être pas tout-à-fait
adapté. Dam's l'ayant fait remarquer au gérant, celui-ci s'est
rattrapé et lui a alors montré qu'il savait parler avec un
vocabulaire tout-à-fait châtié et avec déférence.
Laurent a commencé à lire
Higher Order Perl.
Il avait une question à poser et il a cherché le passage
en question, mais il ne l'a pas trouvé.
Peut-être avait-il ouvert son livre à l'envers
et remarqué un morceau de code qui semblait syntaxiquement
correct lu de cette façon, mais dont la signification
lui paraissait obscure.
L'hypothèse de la lecture à l'envers m'est venue à cause
de deux conférences éclairs que j'ai vues à Braga.
Dans la première, un Néerlandais présentait son module,
ACME::Rot180,
qui permet de prendre une chaîne de caractères et de la faire
pivoter de 180 degrés. Évidemment, cela requiert des caractères
Unicode. La deuxième conférence éclair était celle de H. Merijn Brandt,
qui enchaînait en montrant comment écrire
« Just Another Perl Hacker » après rotation de 180 degrés.
Il se basait sur des particularités méconnues de
pack,
qui ne sont décrites que
dans perlpacktut.
La traduction de
Perl Best Practices
avance. Au moins de mon côté. Parce que BooK s'est récupéré
d'autres tâches, notamment avec sa participation à
OSCON-Europe
et la transcription des interviews des conférenciers.
La traduction de ses chapitres n'avance donc pas très vite.
Il a quand même relu les chapitres que j'ai déjà traduits.
Jérôme, Nicolas et Laurent ont parlé des
articles
pour Linux-Mag,
en particulier des articles sur la production qu'ils
rédigent. J'avoue que je ne suis plus les articles de très
près et je ne connais pas suffisamment le sujet, donc je
n'ai pas retenu le détail de leur discussion.
Une anecdote tout de même sur les articles : quelqu'un
a rédigé une perle et l'a envoyée sur le répertoire CVS.
Dans le message de commit, nous avons constaté que l'auteur y avait
laissé le code d'accès à la messagerie électronique
et son mot de passe. Emmanuel a demandé si c'était le
véritable mot de passe. L'auteur a répondu évasivement
ce qui laisse penser que c'était le véritable mot de passe.
De nombreux logiciels ont été évoqués :
RT
(Request Tracker),
Mason,
Template::Toolkit
Bugzilla et autres.
Même un auteur de module peut être surpris par ce que fait son
module. C'est le cas de Michel Rodriguez. Un participant à la
réunion lui a ainsi appris que
XML::Twig
pouvait analyser deux fichiers XML en parallèle, en basculant de l'un à l'autre
à chaque ligne. Si Michel n'était pas au courant,
c'est parce que c'est une fonctionnalité de
expat
sur lequel se base XML::Twig et
que Michel a reprise sans le savoir dans son module.
Il a été beaucoup question de Google
ce soir-là. Sniper a évoqué
un site
qui explique comment tirer au mieux parti de la façon dont
Google index les pages web. Dans le forum associé à ce
site, de nombreux contributeurs ne sont intéressés que
par l'évolution de leur rank :
« Cela ne va pas du tout ! Hier, j'avais
un rank de 7 et aujourd'hui je
me retrouve à 2 ! »
David (L) a évoqué
trois
articles de
Cringely,
décrivant
l'expérience
à laquelle s'est livré un utilisateur
des Google Ads.
Les Google Ads apparaissent en fonction de
deux critères : le page-rank du site
de destination et le montant de la rémunération par clic.
L'utilisateur avait souscrit un abonnement à 10 cents
par clic. Pour voir si cela vaudrait le coup de changer de
tarif, l'utilisateur a créé un site bidon, semblable au
véritable site, pour avoir le même pagerank
et il a souscrit aux Google Ads avec un
tarif de 1 dollar par clic. Le site bidon avait,
bien entendu, plus de clics que le site à 10 cents.
Au bout de quelque temps, l'utilisateur a essayé avec
40 cents par clic. Il s'est aperçu alors que le
site bidon à 40 cents était moins efficace que le
site à 10 cents. Cela voudrait-il dire que les
sites qui modifient leur abonnement sont avantagés
ou pénalisés selon la façon dont ils ont modifié
leur abonnement ? Rappelons que le but de Google,
comme toute entreprise, est de gagner du fric.
Et que l'un des moyens pour gagner des sous est
de persuader les utilisateurs qu'un abonnement à
1 dollar par clic est plus avantageux qu'un
abonnement à 40 cents par clic.
Quelqu'un a fait une étude statistiques du nombre de pages
indexées par
Google
et par Yahoo!
L'évolution de ce nombre
chez Google semble très suspecte. En revanche, les
différents nombres annoncés par Yahoo! au fil du temps
sont plausibles. Est-ce que Yahoo! est sincère ou bien
est-ce que les statistiques ont été inventées après
une mûre réflexion ?
Dans le temps, dans les résultats de recherche de Google, nous avions
une indication de la pertinence de chaque résultat grâce à une barre
verte plus ou moins longue. Il est possible de la retrouver si l'on
installe la
Google-bar.
Mais alors Google sera averti des pages web que vous visitez
(c'est d'ailleurs signalé dans la
politique vis-à-vis de la vie privée
de la Google-bar si on lit attentivement). Nous avions
déjà évoqué
un phénomène analogue,
mais c'était Opera
qui était en cause et ceux qui avaient
découvert le phénomène
étaient Stéphane (le nôtre) et
Dan Sugalski.
Le respect de la vie privée couvre beaucoup plus que les habitudes
de navigation sur Internet. Il y a aussi toutes les informations
personnelles que l'on peut trouver sur différentes pages web.
Et avec Google, c'est très facile d'accéder à ces informations
personnelles. Quelqu'un a voulu en faire la démonstration
en recherchant des informations concernant l'un des deux
fondateurs de Google. Il a trouvé et il a publié le
résultat. En représailles, la direction de Google a donné
la consigne à tout le personnel de Google de boycotter
la personne et la boîte où il travaille : plus de
correspondance par messagerie électronique, ni par téléphone,
ni par courrier sur papier.
Parmi les
fonctions avancées de recherche
de Google (et peut-être
d'autres moteurs de recherche), il y a la recherche sur une
plage de valeurs numériques. En demandant la plage des nombres
à 16 chiffres, on obtient ainsi divers numéros de cartes
de crédit.
David (L) a évoqué une fausse manip qui lui a occasionné
des sueurs froides. Il souhaitait connaître les routes
IP statiques à partir de son poste et pour ce faire, il
a tapé la commande netstat -nr.
Il appuie alors sur la touche « return » et... rien,
pas de réponse, écran bloqué. Il essaie la souris et ne
constate aucune problème de ce côté-là, il peut sélectionner
les fenêtres comme il faut, les faire passer au premier plan.
En revanche, toujours pas de réponse sur son Xterm.
Il s'enquiert de la situation auprès de quelques collègues,
avec la voix de quelqu'un qui a fait une bêtise mais qui est
le seul à le savoir, mais ses collègues ne se doutent de rien,
ils n'ont (pour l'instant) rien remarqué d'anormal.
Enfin, au bout d'un long moment d'incertitude il constate à
son grand soulagement que le clavier était mal branché
et qu'un faux mouvement avait coupé la liaison juste avant
l'appui sur le retour-chariot.
Nous avons évoqué une fonctionnalité de certains
langages de programmation, qui vérifient systématiquement
que les résultats de calcul ne provoquent pas de problème
du genre débordement de valeur. C'est le cas avec
Ada,
avec la variante de
C
appelée Managed C et avec
Java.
Une fois que l'on a pu tester qu'il n'y avait pas de
débordement ni d'erreur de domaine dans les calculs, on peut
désactiver ces vérifications pour accélérer les traitements.
Sauf sur
Java,
où les vérifications ne sont pas débrayables.
Dans la suite logique de cette conversation, quelqu'un a
rappelé la vanne traditionnelle expliquant comment
se tirer une balle dans le pied. Avec un langage
qui effectue des contrôles de débordement, il est
très difficile de se tirer une balle dans le pied, mais
quand on y arrive, ce n'est pas une simple balle, c'est
un véritable obus.
La programmation objet, c'est bien, à condition de l'utiliser
à bon escient. Ne pas faire comme certains qui créent
une classe Heure, une classe Minute et
une classe Seconde, puis créent une classe Heures
(avec un « s ») qui agrège les trois premières
classes. De temps en temps, un peu de procédural ne
fait pas de mal dans un programme écrit dans un langage
orienté objet.
De même, pour les exceptions avec try et catch,
l'abus est dangereux. La documentation d'un langage orienté
objet (Ruby, je crois),
les déconseille carrément.
Nicolas nous parle de l'administration système. On y
fait du resource planning, du trending,
du reporting, plein de choses en « ing ».
Guillaume assure que Nicolas a oublié quelques activités :
le glanding, le surfing et
l'IRCing.
Dans le temps, l'exploitation consistait à monter les bandes sur les
dérouleurs, à lancer les travaux batchs de longue durée en évitant
les conflits de ressources. Il y avait d'autres petits boulots
comme la saisie des données sur cartes perforées. Tout cela a disparu,
maintenant il y a des éditeurs plein écran, il y a cron
et autres logiciels de planification, il y a des robots pour la
manutention des cartouches magnétiques. Guillaume évoque le cas de
l'INRIA,
qui a dû reclasser ses nombreux monteurs et ses
nombreuses perfos, ce qui expliquerait d'après certains l'abondance de personnel
administratifs aujourd'hui par rapport à d'autres administrations.
cron est peut-être plus fiable qu'un pupitreur, encore
faut-il qu'il soit correctement paramétré. Quelqu'un cite un
contre-exemple dans lequel toutes les tâches démarrent à une heure
ronde (c'est-à-dire lorsque la grande aiguille est sur le 12).
Pourquoi ne pas faire démarrer certaines tâches à « plus 5 »
et d'autres à « plus 10 » ?
Sur certaines machines, lorsque la charge commence à être un peu
trop élevée, le système interrompt certains processus au hasard.
Quand il flingue
sshd
sur un serveur
Oracle,
c'est un peu délicat
pour que l'administrateur intervienne et ajuste le fonctionnement
de la machine. Mais parfois, c'est le processus Oracle qui passe à
la casserole sur le serveur Oracle.
Autre problème de conflit : un site comporte un serveur et
une trentaine de clients. Une sauvegarde des postes clients est
programmée pour chaque soir. Le problème, c'est que le serveur
possède une carte réseau à 100 mégabits, tandis que les
clients possèdent chacun une carte gigabit.
Sur un autre site, les sauvegardes ne posent pas de problème. Il
y en a une tous les 1 400 jours environ. Quelqu'un
demande s'il s'agit de sauvegardes incrémentales. [ Au fait,
dois-je mettre le pluriel ? ] Celui qui rapporte
l'anecdote fait remarquer qu'avec un tel laps de temps,
une sauvegarde incrémentale différera peu d'une sauvegarde
globale. Quelqu'un d'autre fait remarquer qu'il y a un avantage
à avoir un tel intervalle entre deux sauvegardes : les
bandes magnétiques ne sont pas usées, donc on peut
utiliser toujours la même bande à chaque sauvegarde... incrémentale.
[ À propos de cette ultime remarque, lisez la deuxième anecdote dans
cette page,
ainsi que celle qui nous vient de la Finlande.
Et que cela ne vous empêche pas de lire les autres. ]
Il paraît qu'il existe dans la base de registres des clés dont
le seul effet est de provoquer un plantage du système. Cela peut
être utile quand il est nécessaire d'analyser un mauvais fonctionnement du système.
Il paraît également qu'il est possible de « customiser » le
Blue Screen of Death
et changer la couleur du fond, qui n'est donc plus forcément bleue
et celle du texte. Bien sûr, certains ont pensé à spécifier la même teinte dans
les deux cas sur le PC d'un collègue de travail puis à demander à ce
collègue d'aller lire la clé adéquate dans la base de registres...
Sous Mac OSX,
on n'appelle pas cela un BSOD, mais un kernel panic.
Et c'est particulièrement spectaculaire à regarder. Les informations
d'état de la machine s'affichent, si j'ai bien compris, sur une fenêtre
dont la transparence est complète au début puis décroît en quelques secondes.
Il existait une recette pour provoquer un kernel panic
sur les anciennes versions de Mac OSX. L'une des étapes consistait à
établir un lien symbolique d'un répertoire vers lui-même. Je ne me souviens
plus du reste. N'importe comment, c'est corrigé.
Il est question d'une install-party qui doit se tenir dans
quelques semaines. Cette install-party est sponsorisée
par l'éditeur d'une distribution Linux. Cet éditeur a l'intention
d'envoyer des T-shirts à son effigie aux animateurs deux jours
avant la date prévue pour, paraît-il, s'assurer que ces animateurs
auront des affaires propres à se mettre !
Sous Unix, il existe deux commandes différentes portant le même
nom, killall. L'une d'elles permet d'envoyer un signal
à tous les processus portant le nom donné en paramètre.
L'autre commande flingue la totalité des processus tournant
sur un système. Sur certains systèmes, on trouve les deux
commandes, l'une par exemple dans /sbin et l'autre
dans /usr/bin.
Un jour, dans le cadre de son travail, David (L) était en train
d'installer une machine dans un rack. La machine ne coulissait pas
correctement sur les glissières, donc David a été obligé de pousser ferme.
Puis sa main a dérapé et il s'est éraflé. Plus tard, il a rencontré
une personne qui n'a jamais mis les pieds dans une salle machine, mais
qui fréquente de temps en temps les cafés. Le dialogue a donné à peu
près ceci :
-- Qu'est-ce qui t'est arrivé ?
-- Je me suis battu avec un serveur.
-- Ah bon ?!
Une méprise du même genre : un participant a vu une publicité
pour une manifestation dans un grand magasin,
« les 4 Jours Java ».
Non, il ne s'agissait pas du
langage
de chez Sun,
mais de l'Indonésie.
Dam's a des problèmes avec un modem USB, qui « frise », c'est-à-dire
qui cesse de fonctionner lorsque la température augmente. Certains
lui suggèrent de faire du water cooling USB.
L'un des participants a l'occasion de faire un peu d'enseignement
à des étudiants. Il nous évoque un cours de
SQL
qu'il a donné à des
étudiants de tous horizons, dont quelques Chinois. Pour effectuer
les exercices du cours, les Chinois ouvrent Word, tapent leur
instruction SQL dans Word, puis font un copier-coller
vers l'interpréteur SQL. Et là, l'interpréteur SQL part en vrille.
Il semblerait que ce soit dû aux caractères du genre guillemets,
avec la conversion automatique par Word des guillemets informatiques
vers les guillemets typographiques, lesquels ne sont pas digérés par
l'interpréteur SQL. Ce qui est curieux, c'est que ce problème
se produit seulement chez les étudiants chinois.
Quelqu'un d'autre évoque un système de droits et d'autorisations qui
repose sur une base
SQL.
Comme le système de droits est particulièrement
compliqué, cette personne crée des utilisateurs par recopie :
insert into TUSER (select * from TUSER where ...)
puis par modification des rares champs compréhensibles (login,
nom, etc).
Tout le monde consulte
PC-INpact,
tout le monde est expert en
informatique grâce à PC-INpact. C'est ainsi qu'un participant
à la réunion, administrateur système de son état, a été informé
par un « costard-cravate » que « Oracle, c'est pas bien.
Je sais, je l'ai lu dans PC-INpact. »
Un film que Jérôme nous recommande absolument de voir en DVD (ou en cassette), c'est
Galaxy Quest.
Il le connaît pour ainsi dire par coeur et il est
capable de reproduire le timbre de voix des aliens
(sa fille aussi, mais sans le faire exprès ; précisons
que les aliens ont des voix de fausset, qui correspondent très
bien à la voix d'un enfant entre 1 et 2 ans).
D'autres sont capables de rappeler une citation de ce
film :
Nous avons parlé des événements actuels, c'est-à-dire de la
grippe aviaire. Il paraît que le virus de la grippe aviaire
ne résiste pas à la chaleur. Du coup, comme quelqu'un l'a
lu dans un blog, avec le nombre important de poulets que
l'on rencontre dans les rues, ce n'est pas étonnant que certains
adoptent des mesures prophylactiques consistant à faire brûler
ce qu'ils peuvent, c'est-à-dire en général des poubelles et
des voitures.
Dans un autre domaine, il a été question de nouveau de
l'épuisement des ressources pétrolières. Curieusement,
cela va conduire à faire du Canada un pays exportateur
de pétrole. En effet, le Canada possède dans certaines
zones de grandes quantités de sable imprégné de pétrole
à fleur de surface.
Jusqu'à présent, personne n'y avait prêté attention, car
c'était considéré comme inexploitable. En fait, le véritable
terme aurait dû être « en dessous du seuil de rentabilité ».
Mais avec l'augmentation du prix du pétrole, voilà que ces
sables pétrolifères acquièrent une certaine compétitivité,
donc un intérêt certain.
C'est comme les bassins houillers du nord de la France. Ils ont
été fermés pour cause de rentabilité, pas pour épuisement des
filons. On envisage de recommencer à extraire du charbon, mais
cette fois-ci en minant à ciel ouvert. Il suffit de décaper
le sol sur une trentaine de mètres d'épaisseur et on arrive
aux veines de charbon, que l'on peut alors extraire au bulldozer.
