Avec la participation de sa Seigneurerie

Un historique de toutes nos réunions

Table des matières

mercredi 9 novembre 2005

La voix du secrétaire (Jean)

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.

Nous avons parlé de Perl, d'Internet d'informatique et d'autres sujets.

Perl

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.
Certains avaient le livre de la Panthère deuxième version, celle de Simon Cozens. Il y a deux points communs avec la première version : le titre et l'illustration. Tout le reste a changé.

Internet

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.

Informatique

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. »

Divers

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 :
Never give up, never surrender!
Et même s'il y a Sigourney Weaver, ce n'est pas la même atmosphère qu'Alien.
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.