Le carnet du grincheux

Faire accroire à des informaticiens barbus qu'ils peuvent remplacer des matheux obtus à tendances perverses est une croyance trop répandue. Je me demandais depuis quelque temps pourquoi l'un des mes algorithmes ne donnait pas le même résultat selon qu'il était lancé avec un seul fil d'exécution ou avec plusieurs. En disséquant une bibliothèque mathématique — GSL 1.14 pour ne pas la citer —, je viens de m'apercevoir que les générateurs aléatoires ne résistent pas à la création de fils d'exécution parallèles. En relisant la documentation en long, en large et en travers, je n'arrive pas à trouver le moindre début d'information sur le fonctionnement des générateurs aléatoires dans un processus multithreadé. Visiblement, cela doit couler de source à moins que les concepteurs de ladite bibliothèque ne se soient jamais posé la question.

Pourtant, il serait de bon goût que les concepteurs de cette bibliothèque s'assurent que leurs générateurs suivent une statistique aléatoire connue et conforme quel que soit le nombre de fils d'exécution parallèles dans un processus et surtout quel que soit le nombre d'appel au générateur. En d'autres termes, il serait normal que la bibliothèque utilise un thread spécifique dans lequel tournerait ledit générateur et qui renverrait à chaque fil d'exécution effectuant une requête sur ce générateur une variable aléatoire correcte.

Ce n'est pas exactement comme cela qu'est codée cette bibliothèque. À chaque nouveau thread, c'est à l'utilisateur de cloner son générateur en le réinitialisant avec la valeur de la graine du thread père ou d'en réinitialiser un. Dans le premier cas, tous les threads fils risquent fort de tirer la même séquence, dans le second cas, le côté aléatoire sera limité par l'aléa disponible sur le choix de la graine lors de la réinitialisation. La qualité des variables aléatoires tirées dans des threads parallèles s'en ressent. À quoi sert donc l'utilisation d'un générateur aussi performant qu'un ranlux389 si l'utilisateur est contraint de le réinitialiser dans chaque thread ? Visiblement, cela ne semble pas gêner les concepteurs de GSL. Je ne suis même pas sûr qu'ils soient conscients de leur boulette. Ils ont dû sauter des pages dans leur manuel d'analyse numérique…

Pire, je serais assez curieux de connaître le niveau de compréhension mathématique de l'utilisateur de base de ces fonctions. J'ai comme l'affreuse impression que l'immense majorité d'entre eux ne se pose même pas la question, n'ayant pas la formation mathématique suffisante. J'ai trouvé le pot aux roses parce que j'ai une certaine habitude, une solide culture mathématique, que j'ai vu un résultat de calcul utilisant ces fonctions pour le moins étrange, et que j'ai la possibilité et les connaissances pour démonter la bibliothèque en question et en comprendre le fonctionnement.

Une fois le problème diagnostiqué, il fallait aussi corriger le programme utilisant ces fonctions, ce qui n'a pas été une mince affaire et s'est terminé par l'utilisation d'interruptions logicielles.

Nous avons donc d'une part une bibliothèque prise comme une boîte noire par la plupart des développeurs et un algorithme utilisant pour argent comptant un certain nombre des fonctions fournies par cette bibliothèque. Rien dans la documentation ne laisse entrevoir les limitations de ces fonctions en environnement parallèle ni ne met en garde l'utilisateur contre une mauvaise utilisation due à l'implantation de ces fonctions. Nous obtenons d'autre part des résultats de calculs complètement aberrants sans aucune raison apparente. Mais comme le développeur a pris soin de spécifier au début de son programme #define _REENTRANT, l'honneur est sauf.

L'utilisation de bibliothèques spécialisées n'est donc pas une chose aussi positive qu'on veut bien nous le faire croire. Le résultat d'un programme est autant lié à la propre qualité de son code qu'à celles des bibliothèques utiliseés. Il faut de plus ou avoir une confiance absolue en les concepteurs desdites bibliothèques, ou avoir assez de connaissances pour tester leurs différentes fonctions et les pousser dans leurs retranchements.

Le corrolaire immédiat est qu'on ne devrait utiliser une bibliothèque qu'à partir du moment où on pourrait l'écrire soi-même. Mais quel est le développeur qui agirait encore comme cela de nos jour ?

Petite méditation du jour. Je ne résite pas à vous faire partager ce court extrait d'un livre qui a maintenant une cinquantaine d'années :

Naguère encore, au café du Commerce, on ne jurait que par le progrès. Qu'il y ait ou n'y ait pas progrès, le progrès en tant qu'idéal a un sens, et un sens louable : faire toujours mieux. Aujourd'hui l'idéal du progrès est remplacé par l'idéal de l'innovation : il ne s'agit pas que ce soit mieux, il s'agit seulement que ce soit nouveau, même si c'est pire qu'avant, et cela de toute évidence. Cet idéal est poursuivi dans les plus petites choses comme dans les plus grandes ; il est absurde, mais le public n'a pas conscience de cette absurdité, ou, s'il en a conscience, se tait et serre les fesses, car l'innovation, en tant qu'Idée-Bête, est une divinité, et comme telle effrayante. Adorez-la, ou gare !

Ce texte, qui n'a pas pris une ride, est issu d'un carnet d'Henry de Montherlant, Va jouer avec cette poussière, Carnets 1958-1964, publié en 1966 chez Gallimard. Dommage que Montherlant se soit suicidé en 1972 car j'aurais bien aimé avoir son avis sur l'idéal du progrès tel que nous le vivons actuellement.

Je me faisais cette réflexion en apprenant récemment que Kodak avait abandonné la fabrication de son excellent Kodachrome 64. Après l'arrêt du 200 et du 25, ce n'était qu'une question de temps. Le problème est qu'il n'existe aucune émulsion capable de remplacer le Kodachrome. Pour ceux qui ne seraient pas au courant, le Kodachrome était un film diapositif couleur introduit sur le marché en 1935 et tellement bon qu'il a été fabriqué durant soixante-quatorze années. Contrairement à tous les autres films inversibles, il se compose de plusieurs couches de films noir et blanc. Les pigments sont ajoutés lors du développement (procédé K-14), ce qui lui apporte une stabilité accrue dans le temps. Kodak le garantissait pour garder ses propriétés plus de 100 ans.

Aujourd'hui, nous avons à notre disposition des pellicules Fuji qui ne sont pas mauvaises (procédé E-6) mais dont la durabilité n'est pas assurée, des émulsions Kodak (procédé E-6) quelconque et quelques autres sans grand intérêt. Autant en noir et blanc il existe aujourd'hui plus d'émulsions qu'avant l'arrivée du numérique, autant en couleur, le choix s'est considérablement restreint.

La photographie numérique ne répond pourtant pas aux critères de conservation des œuvres. Je ne parlerais pas ici de la qualité moindre des clichés due aux objectifs en cul de bouteille ni des capteurs qui ne sont pas très bon. La qualité des photographies numériques est même tellement bonne que Zeiss a ressuscité son ancienne marque Zeiss Ikon pour fabriquer des nouveaux appareils 35 mm, partant du principe qu'ils se mettront à faire des boîtiers numériques lorsque la technologie permettra d'avoir au moins la même qualité avec un boîtier numérique qu'avec l'un de leurs boîtiers argentiques 35 mm.

Le problème de la photographie est la conservation du cliché. Un tirage sur papier baryté peut moisir, mais une carte mémoire peut s'oxyder. Pourtant, même moisie, je peux toujours regarder ma photographie. Si la carte mémoire est morte, je peux toujours regarder ma carte mémoire, ça ne va pas m'avancer à grand'chose.

En effet, le principal problème du passage de la photographie argentique à la photographique numérique n'est pas un problème de qualité, même s'il y aurait beaucoup à dire puisque, le cliché ne coûtant plus rien, tout le monde se prétend photographe. Le véritable problème est la dissociation entre le support de l'information, l'information et l'appareil nécessaire à sa lecture.

Avec une photographie argentique, tout est lié : le papier ou le film et les cristaux d'argent, la lecture se faisant immédiatement grâce à l'œil. La durée de conservation est supérieure à un siècle, voire à deux si l'on considère les photographies des années 1830 qui sont toujours regardables. Lorsqu'on parle d'une photographie numérique, on parle d'un support (carte mémoire, disques durs, CD-ROM's, DVD…), d'un format de fichiers et d'un ordinateur. Combien de fois ai-je entendu dire qu'untel avait perdu toutes ces photographies parce que son disque dur était tombé en panne ? Combien de fois ai-je entedu dire que les photographies de vacances de l'année dernière ne sont plus lisibles parce que le DVD gravé ne l'était plus ? La durée de vie de la photographie numérique est la durée de vie du composant le plus faible de la chaîne. Dans le meilleurs des cas, on nous annonce dix ans. Dans le pire, avec des DVD à graver bas de gamme, on peut péniblement atteindre les trois mois. Et je ne parle pas encore des tirages. S'ils sont fait dans un laboratoire, il y a de fortes chances pour que le tirage soit fait par transfert sur papier photographique, à l'ancienne. Là, le résultat sera archivable. Mais s'il est fait sur des imprimantes, les couleurs vont très vite tourner. Souvenez-vous des épreuves Polaroid des années 70…

Les historiens des siècles à venir vont nous maudire. Tous les documents, toutes les photographies (à l'exclusion des photographies argentiques) seront soit illisibles soit perdues. Le progrès ne nous aura permis qu'à devenir amnésiques. C'est donc un véritable progrès.

Ça y est, on l'attendait depuis le rachat de Sun Microsystems par Oracle. La nouvelle est tombée vendredi 13 août 2010, en plein mileu des vacances pour que ça ne fasse pas trop de bruit dans la communauté OpenSolaris. Le mémo en question, prétendûment confidentiel, contient un tas de choses sur l'avenir du matériel Sun Microsystems et de Solaris. J'en retire deux paragraphes, les plus importants pour le futur de Solaris.

We will continue to use the CDDL license statement in nearly all Solaris source code files. We will not remove the CDDL from any files in Solaris to which it already applies, and new source code files that are created will follow the current policy regarding applying the CDDL (simply, that usr/src files will have the CDDL, and the very small minority of files in usr/closed might not have it). Use of other open licenses in non-ON consolidations (e.g. GPL in the Desktop area) will also continue. As before, requests to change the license associated with source code are case-by-case decisions.

En d'autres termes, on va pouvoir — lorsqu'on aura les sources avec un train de retard — admirer un savoureux mélange entre un code libre et un code fermé. On aimerait bien savoir sur quel critère se fera la distinction. OpenSolaris sera-t-il encore utilisable pour des machines de production ?

We will distribute updates to approved CDDL or other open source-licensed code following full releases of our enterprise Solaris operating system. In this manner, new technology innovations will show up in our releases before anywhere else. We will no longer distribute source code for the entirety of the Solaris operating system in real-time while it is developed, on a nightly basis.

Là, c'est « the cherry on the cake ». Mis bout à bout, les deux paragraphes signifient qu'Oracle veut bien filer une partie des sources de Solaris, mais une fois qu'elles seront périmées. La question est surtout : quel sera le délai pour cette mise à disposition du code.

J'utilise les systèmes d'exploitation de Sun depuis SunOS 4.x et je suis passé par toutes les version possibles et imaginables de Solaris. Il faut regarder les choses en face, si le matériel Sun était de l'excellent matériel, Solaris a toujours été une sombre saleté — pour rester poli — que les gens n'utilisaient que parce que c'était le seul, pendant très longtemps, à tourner correctement sur le matériel de Sun. En effet, les subtilités de la gestion des caches et des différents bus étaient longtemps restés largement non documentées. En coulisse, on l'appelait Slowlaris depuis que des pans entiers du système étaient écrits en Java, et on se dépêchait de rajouter tous les outils GNU pour avoir quelque chose d'utilisable. En ce sens, Nexenta était la seule distribution OpenSolaris réellement utilisable.

Au fil des années, l'avantage de Solaris sur les systèmes alternatifs s'est considérablement réduit. L'administration correcte d'un système Solaris est absconse, les patches de sécurité sont impossibles à passer sans avoir dans une main un fer à cheval, dans l'autre une gousse d'ail et dans la dernière une patte de lapin. Même les firmwares des dernières machines Sparc T1/T2 sont complètement moisis qu'ils plantent au bout d'un certain temps. Il faut redémarrer le serveur électriquement pour reprendre la main sur la console d'administration, ce qui n'est pas très propre, vous en conviendrez !

À la place d'Oracle, je me ferais du souci. Les systèmes libres sont devenus plus performants sur leurs matériels que le système historique et propriétaire — en même temps que le matériel est devenu de moins en moins fini — et ce n'est pas en limitant artificiellement le développement des systèmes libres sur ce matériel qu'ils pourront limiter la chute de Solaris. Par ailleurs, vu le prix de la machine d'entrée de gamme — prix qui a juste été multiplié par trois lors du rachat — auquel il faut ajouter un contrat de support de Solaris pour bénéficier des patches et ne pas avoir un système plus troué que la casserole à nouille des shadoks, je pense sérieusement à regarder de plus près ce qui se fait chez la concurrence. Quitte à avoir un système d'exploitation propriétaire, autant directement utiliser OpenVMS sur une machine Integrity de Hewlett-Packard. C'est maintenant moins cher que du matériel Oracle et largement plus fiable.

Note liminaire — et non préliminaire — à l'attention des imbéciles et des mal comprenants qui se seraient égarés ici par pure mégarde :

ce qui suit est à prendre au deuxième voire au troisième degré. Je n'en pense pas un mot. On peut rire de tout, mais pas avec n'importe qui et si vous être outrés de ce que vous allez lire, il n'est vraiment pas nécessaire de me le faire savoir.

Cela ne vous a certainement pas échappé. Nous fêtons aujourd'hui le premier de nos quatre ou cinq shabbats de ramadan annuels. Je les attends toujours avec beaucoup d'impatience. Je suis en effet coincé entre un couple de juifs séfarades de plus en plus orthodoxes à mesure qu'ils enchaînent les voyages en terre d'Israël et un couple de musulmans tout ce qu'il y a de plus charmant, sans « s », je parle du couple pas des musulmans, encore que je n'ai strictement rien contre eux pris séparément ni contre les autres musulmans d'ailleurs. Je tiens à la vie, entre autre parce que j'ai encore envie de manger mon entrecôte du vendredi.

Le shabbat de ramadan est donc un moment béni des dieux, enfin du Dieu unique et omnipotent parce qu'il paraît qu'il s'agit du même, même si ses séides se trucident entre eux parce qu'ils croient en le même Dieu mais pas en la même religion.

D'un côté nous avons les musulmans qui jeûnent du lever au coucher du soleil, de l'autre côté les juifs qui ne font rien de la veille au soir au coucher du soleil suivant. Enfin, rien est un bien grand mot. S'ils n'appuient pas sur le bouton de la porte ou sur celui de la minuterie, ce n'est pas ce qui les empêchent ni de se casser la figure dans l'escalier, ni de lire la Thorah et ses commentaires après le repas. Il est certainement écrit quelque part dans le Lévithique qu'il est interdit d'appuyer sur le bouton de la minuterie un jour de shabbat et qu'il faut bricoler les clanches des portes cochères pour pouvoir entrer et sortir sans appuyer sur le bouton. Heureusement qu'il n'y a pas d'hindou dans l'immeuble parce que je ne me vois pas démonter les deux portes d'accès pour laisser entrer et sortir les vaches sacrées !

Je ne savais pas qu'une des traditions juives était d'avoir toujours une place pour l'étranger de passage le jour du shabbat, jour qui commence la veille au soir. Je l'ai appris à mes dépens. Ayant durant quelques années beaucoup travaillé à l'étranger, mon voisin me gardait le courrier. Un vendredi soir, de retour de l'aéroport Charles-De-Gaulle, je frappe à sa porte encore avec ma valise pour récupérer un courrier à traiter de façon urgente. M'excusant platement parce que le shabbat était commencé, il m'a donné mon courrier et m'a prié, ou plutôt ordonné, de déposer ma valise chez moi et de revenir pour le repas. L'étranger qui frappe à la porte, juif ou non, se doit d'assister au shabbat.

Sauf que le shabbat, c'est un repas le vendredi soir, repas que même Rabelais n'aurait pu décrire dans les plus folles pages de Gargantua, la procession à la synagoge le samedi matin — j'y ai échappé, je n'ai fait qu'ouvrir et fermer les portes de l'immeuble —, le repas du samedi midi (couscous cacher, légumes au vinaigre, trois plats successifs plus dessert), la lecture de la Thorah avec ses commentaires, une longue prière hébraïque, puis le repas du soir et l'allumage des bougies de fin de shabbat. C'est donc avant tout un moment de bonne chair.

De l'autre côté, nous avons le jeûne du ramadan. Il consiste à ne rien ingérer du lever au coucher du soleil. Mais alors qu'est-ce qu'ils se rattrapent la nuit ! J'ai eu l'occasion de participer à ce genre de petite sauterie en pays musulman et c'est vraiment impressionant. C'est donc aussi un moment de bonne chair.

Vous allez me dire que cette bonne chair est hallal et non cacher ou le contraire. Mais dans les faits, quelles différences ? Le principe est le même, la seule différence entre les deux abattages rituels est le nom du préposé au contrôle et la direction de l'abattage. Rien n'interdit à une viande cacher d'être abattue en direction de la Mecque et sous le double contrôle d'un rabbin et d'un imam. Quant à la viande hallal, rien ne lui interdit non plus d'être contrôlée en présence d'un imam à partir du moment où il y a déjà un rabbin. Quant aux bouteilles d'eau minérale cacher ou de vin cacher, je me suis toujours demandé comment elles étaient abattue et dans quelle direction.

Pourquoi donc ne pas relier ces deux religions qui ont quelques points communs ? Il serait possible de créer un shabbat de ramadan, quelque chose de festif et totalement libéré, à la fois cacher et hallal, œcuménique, une agape ininterrompue de vingt-quatre heures sous couvert de religion, une sorte de syncrétisme joyeux pour la paix entre les religions.

Il faudrait que je propose ça à la mairie de Paris. La municipalité me semble être un peu à court d'idée ces temps-ci.

Amis du goret-codage, des GOTO's calculés, des IF's arithmétiques, des blocs COMMON et des EQUIVALENCE's, vous devriez commencer à comprendre que mon langage de programmation de prédilection est le FORTRAN et que je ne parle C que contraint et forcé, lorsque j'ai des choses subtiles à faire avec la mémoire du calculateur ou qu'il me faut écrire une interface graphique à grands coups de X11/Xt/Xm en d'autres termes Motif que je parle — heureusement pour moi — dans le texte. Si je m'écoutais, j'écrirais pourtant tout dans deux langages issus de mes réflexions les plus tordues — qui a dit avinées ? —, les RPL/2 et RPL/C, qui comme tout le monde sait, comportent une extension Motif sous la forme d'un module motif.rplso (rplso pour RPL/2 shared object). Il doit certainement rester un tas de problèmes dans ces deux langages, mais au moins, je sais qui engueuler lorsque ça ne fonctionne pas. D'un autre côté, malgré le nombre d'utilisateurs qui commence à devenir important, les rapports de dysfonctionnement sont plutôt rares, signe s'il en est qu'on arrive à écrire des choses propres en restant strictement dans les bornes imposées par le C (en mouture C99) et le FORTRAN (en versions 1977 et 2003). Il faut dire que j'ai écrit des dizaines de lignes de code en C pour l'armée française, plus exactement pour la Délégation Générale de l'Armement, et que, si les militaires marchent au pas, les codes sources de leurs applications ont eux-aussi le petit doigt sur la couture du pantalon si vous voyez bien ce que je veux dire, ce dont je doute pour les plus jeunes qui n'ont pas eu la joie de faire leur service militaire…

Autant le dire tout de suite, pour moi, en dehors de la programmation fonctionnelle, il n'y a point de salut. La programmation orientée objet est un paradigme que je n'arriverai jamais à comprendre. Pourtant, je vous promets que j'ai essayé. J'ai tenté l'écriture de choses en C++, en Ada 95 et même en Java, c'est vous dire, mais je suis toujours revenu à mes premières amours. Pour être tout à fait exact, je pense ne pas comprendre l'intérêt de la programmation orientée objet, voire, j'arrive à penser certains jours — et de plus en plus souvent — que c'est une débauche d'énergie pour rien et qui ne sert au développeur médiocre qu'à masquer sous un vernis de concepts abstrus et mal maîtrisés son inculture et son indigence crasse.

Le RPL/2 est un langage fonctionnel impur utilisant les notations algébrique ou polonaise inversée, fruit de plusieurs années de réflexions autour des langages de programmation et dont la documentation est disponible au bas de cette page. Il faudrait que je trouve le temps de l'achever. Elle me sert pourtant à tester les développeurs qui veulent travailler avec moi. Ce n'est pas par vice, simplement parce que mon travail consiste à implanter des algorithmes sur des machines massivement parallèles et que ce langage est le seul langage efficace pour le faire. J'ai pourtant essayé des choses comme OpenMP sans véritable satisfaction. Il masque par exemple tous les problèmes de concurrence qui peuvent apparaître sur des calculateurs parallèles sans limiter les possibilités du développeur. Il est donc un excellent compromis entre un langage comme le C qui permet de tout faire, mais à la main, et un truc ou un grand machin — suivez mon regard, non, je ne parle pas d'OpenMP qui fonctionne bien mais n'est pas adapté à mon problème — issu des techniques de programmation orientée objet qui permet de programmer des calculateurs parallèles mais sans vraiment savoir ce que l'on fait.

Je mets donc mes candidats devant une machine avec une documentation complète, un éditeur de texte de base — vim pour ne pas le citer parce que je ne suis pas assez pervers pour les mettre devant emacs, la plupart utilisant difficilement deux doigts pour taper un texte —, un compilateur RPL/2 et un cahier des charges minimaliste pour regarder leurs réactions et la façon qu'ils ont de résoudre le problème posé sachant que le programme demandé est presque à la portée du premier venu. Il suffit de savoir lire une documentation en français et d'avoir les idées claires.

À ce moment, je peux avoir plusieurs réactions totalement différentes. Le candidat peut s'effondrer après avoir paniqué ou, plus rarement, résoudre le problème demandé. Ce qui est amusant, ou désolant c'est selon, c'est que dans la plupart des cas, il va essayer de reproduire dans un langage fonctionnel, le schéma qu'il aurait utilisé dans un langage objet, créant le nouveau paradigme de la programmation orientée abjecte.

Reproduire les techniques de programmation objet dans un langage fonctionnel monte une méconnaissance totale de l'outil informatique et de son fonctionnement. En creusant, on se rend compte sans peine que les candidats qui tombent dans ce travers n'ont étudié dans toute leur formation que le langage Java. La conséquence directe est que la génération montante des développeurs, outre d'être majoritairement incapable d'utiliser autre chose qu'un langage orienté objet, ne connaît pas les bases du fonctionnement de l'outil informatique et imagine qu'un processeur comprend directement les objets créés par leur programme. Jamais ils n'ont pris conscience qu'un compilateur est un programme qui transforme un algorithme écrit dans un langage de programmation quelconque en un langage binaire strictement impératif et que le bytecode Java, contrairement au code source, n'est plus un langage objet.

Et c'est comme ça qu'on retrouve du code inutilisable chez des stagiaires, que des salariés veulent être payés très cher parce qu'ils connaissant Java alors que leur production est indigne d'un développeur C débutant et que la qualité des logiciels est en chute libre depuis quelques années. Lorsque j'ai commencé la programmation, tous mes programmes étaient testés une fois qu'ils fonctionnaient avec un programme singe — un truc qui se comportait comme si un singe était assis devant la console et appuyait n'importe où sur le clavier. Certains jours, j'aimerais ressortir un tel programme pour voir combien de temps tiendrait un programme écrit par cette race de développeurs. C'est juste un rêve, avant d'utiliser un programme singe, il fallait déjà que le programme à tester fonctionne normalement…