Le carnet du grincheux

Je suis adhérent d'une association professionnelle à but mafieux. Comme il faut absolument se mettre au goût du jour, donc au web 2.0, pour attirer les jeunes générations, nous avons décidé de refondre entièrement son site web qui avait été fait il y a plusieurs années et qui ne donnait pas satisfaction.

Ce site web est assez simple. Il comporte une partie publique et une partie privée réservée aux adhérents. Un annuaire des diplômés est disponible avec plus ou moins d'information selon que l'utilisateur est identifié comme adhérent ou non. Vous allez me dire qu'il n'y a pas de quoi casser trois pattes à un canard. Et pourtant…

Le projet a été lancé en septembre 2009 et n'a pas encore abouti. Les premières phases, appels d'offres et choix du prestataire, se sont bien déroulées. Le projet a commencé à partir en vrille juste après le choix du prestataire et aujourd'hui, plus de deux mois après la date de livraison prévue, nous n'avons strictement rien d'utilisable alors que le prestataire veut être payé.

Ce site devait pouvoir être hébergé n'importe où et utiliser des technologies libres pour ne pas retomber dans le travers du premier site, à savoir Apache (ou WASD), php (pour qu'il soit un peu percé sinon ce n'est pas drôle) et PostgreSQL. Dans le cahier des charges, j'ai précisé que ce site devait pouvoir fonctionner indiféremment sous Unix ou OpenVMS pour que les chemins d'accès aux fichiers et les retours à la ligne soient gérés correctement. D'après le prestataire, MySQL, c'est mieux que PostgreSQL. J'ai laissé dire et faire en les attendant au tournant et je dois dire que n'ai même pas eu à les attendre… Le squelette devait utiliser un CRM standard. Une grande discussion a eu lieu pour départager Spip et Joomla, le choix se portant sur Spip pour un certain nombre de raisons.

Je pensais naïvement que le prestataire allait configurer Spip pour créer ce site et que sa maintenance serait aisée. Quelle erreur ! Le code livré au mois de juillet est une aberration, un nœud de spaghetti dans lequel le fond est mélangé à la forme. Plutôt de d'écrire des squelettes pour configurer Spip, la configuration prend place dans le code même du CRM. Autant dire que toute mise à jour, même cruciale lors des alertes de sécurité, sera fastidieuse voire impossible. J'ai essayé de comprendre le fonctionnement de la chose, c'était peine perdue, car entre les macros de Spip, les variables globales de php, les subtilités des cookies et l'absence totale de commentaires utiles, il y a de quoi se perdre. Les seuls commentaires sont du type « début des modification » et « fin des modification », commentaires utiles comme on le voit immédiatement.

Pourtant, ce prestataire n'a aucune excuse. La documentation de Spip est abondante et écrite en français. Il n'y a même pas un problème de barrière de langue. Soit il n'a pas essayé de se plier à la philosophie de Spip, soit il a sciemment fait quelque chose de non maintenable, sous le prétexte de la protection de l'emploi, en se disant que nous ferions appel à lui pour toute mise à jour ou tout modification.

Un an après le début de ce projet, nous sommes rendu au point de départ. Pourtant, je suis sûr qu'il n'y a que deux mois de travail à temps plein sur un tel site. Je sens que je vais me plonger sérieusement dans Spip car, quinze mille euros hors taxes pour deux mois de travail, c'est bien payé.

Il ne faut pas désespérer de la sociologie puisque cette science nous permet par moment de franches rigolades. Je vais finir par croire que j'ai toujours un œil ou une oreille qui traîne au mauvais moment au mauvais endroit pour voir ou entendre ce que personne d'autre ne semble voir ou entendre.

Le 6 août dernier, sur France Inter, se tenait l'émission Ça vous dérange. J'ai déjà eu l'occasion d'écrire ici que cette émission était humoristique, mais là, nous avons dépassé tout ce que nous pouvions en attendre. Le débat parlait de la prostitution en général et de la place du ou de la prostituée dans la société en général. Au début du débat — la belle allitération que voilà —, quelqu'un a cru bon faire un trait d'esprit en demandant si la prostitution était ou n'était pas un métier.

Un pavé dans la marre me direz-vous. Je ne sais pas s'il s'agit d'un pavé, mais d'une question vaine et creuse, certainement. Je ne suis pas sûr que cela fasse vraiment avancer le débat, mais pourquoi pas.

Était parmi les invités une prostituée, Gaby, qui prétendait avoir trente ans de métier — on pourrait donc croire que la prostitution est un métier — sans jamais — les enfants, détournez votre regard — avoir été pénétrée par un client. Vous me direz aussi que s'il y a un client, il y a une activité et, par le fait même, la prostitution serait un métier.

C'est sans compter avec un certain Jean-Philippe Guillemet, sociologue de son état, qui assène vers les 12h15, et qui n'aura de cesse de le répéter jusqu'à 13h00, que prostitué(e), ce n'est pas un métier, parce qu'il n'y a ni formation initiale ni formation continue [sic].

À la suite ce cette sentence sans appel, le débat s'est considérablement échauffé. La gourgandine restant sur ses positions et défendant avec dignité son métier ne pouvait plus s'entendre avec le sociologue complètement obtus.

Réduire un métier au fait qu'il faille une formation initiale et une formation continue me semble assez bizarre. C'est même d'autant plus idiot que l'immense majorité de nos faits et gestes est acquise et non innée. Nous mangeons à table avec des couverts plutôt que par terre dans l'écuelle du chat parce que nous l'avons appris et non parce que c'est notre nature. De même nous parlons français ou nous écrivons l'arabe ou l'allemand parce que nous l'avons appris. Un petit sénégalais adopté à la naissance par un couple de belges ne va pas se mettre spontanément à parler peul. Pourtant, parler peul, français ou arabe, manger à table plutôt qu'en partageant ses croquettes avec le chat ne fait pas de nous des professionnels. Tout au plus des gens civilisés. Enfin, lorsque je regarde le contenu de certaines assiettes, je préfèrerais la gamelle du chat. Je dois aussi dire que quand je vois certaines personnes à table ou que je les entends parler, j'ai comme un doute sur la civilisation qui les a engendrés, mais leurs comportements restent du domaine de l'acquis.

Comment peut-on réduire sans rire la notion de métier à la seule formation ? Un métier, c'est plus qu'une formation, initiale ou continue. C'est une activité qui permet de gagner plus ou moins sa vie. Un individu échange de son temps et de son savoir-faire contre autre chose, des espèces sonnantes ou trébuchantes ou toute autre sorte de rémunération.

En ce sens, il est parfaitement idiot de dire à brûle-pourpoint que la prostitution n'est pas un métier puisque non seulement le ou la prostituée l'a appris d'une manière ou d'une autre et qu'il ou elle échange son temps contre de l'argent.

Je pense que ce qui dérangeait profondément cet invité, c'est plus la possibilité de reconnaître un statut social à la personne se prostituant que le fait de savoir si oui ou non la prostitution est un véritable métier.

Mon cher Jean-Philippe, ce n'est pas en déclarant doctement que la prostitution est ou n'est pas un métier avec des arguments complètement dépassés et risibles qu'on évitera de voir la prostitution dans nos villes et nos campagnes. Ce n'est pas en interdisant la prostitution qu'on la verra disparaître ou en rouvrant les maisons closes qu'on la verra fleurir. Non, la prostitution, c'est avant tout le fruit de la misère, du côté de la personne se prostituant et, il ne faut surtout pas l'oublier, du client. C'est une activité qui obéit à la triste loi de l'offre et de la demande. Le jour où tu auras compris cela, je pense que ta réflexion aura progressé.

Il n'y a pas à être pour ou contre la prostitution. Les prostitués sont des personnes humaines et il ne s'agit pas de savoir si elles sont entrées dans la prostitution par choix ou contraintes et forcées. Naturellement, si elles ont été contraintes à se prostituer, il convient de condamner ceux qui en sont responsables. Mais dans tous les cas, il y a une situation à gérer et je ne vois pas en quoi une personne qui fait commerce de son corps n'aurait pas de droit ouvert à la retraite en fonction de ses cotisations ou de droit ouvert auprès des différentes assurances sociales.

Surtout qu'en y regardant bien, attendre le client par tous les temps, c'est vraiment un métier pénible !

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.