(Comme d’hab’, les italiques sont des avis et commentaires personnels, ou des citations en langue non française. Le non-italique tente la fidélité au livre. Les traductions sont personnelles et pas forcément bonnes, je suis preneur de meilleures adaptations, par exemple pour hater. D’ailleurs j’ai plusieurs fois jeté l’éponge. )

Certains qui me connaissent auront du mal à croire que j’ai lu ça. Et pourtant.

Le Unix-Haters Handbook relève en fait plus du document historique (1994), sinon archéologique, que de quoi que ce soit d’actuel. Il serait une mine de thèmes d’uchronies, : si Unix n’avait pas existé, quel système l’aurait remplacé ? Je parle d’une époque où MS-DOS, Windows 3.1 et Macintosh (Système 7) régnaient sur la bureautique — ou n’étaient pas. Évidemment, le mélange des domaines (l’Unix serveur de fichiers ou serveur de courrier de l’époque n’est pas le poste bureautique ou le serveur web de maintenant) fait partie du jeu.

Les auteurs, Simson Garfinkel, Daniel Weise, Steven Strassmann, ont vécu l’époque où Unix remplaçait petit à petit VMS, ITS et d’autres. Et ils n’ont pas aimé. Le livre est à charge, donc paradoxalement j’en ai très peu appris sur ces concurrents qui étaient forcément plus mieux, sinon en creux. Dennis Ritchie se paye leur tête dans l’anti-préface (je pense que c’est intraduisible) :

“The systems you remember so fondly (TOPS-20, ITS, Multics, Lisp Machine, Cedar/Mesa, the Dorado) are not just out to pasture, they are fertilizing it from below.”

— Dennis Ritchie

et aussi (à apprendre par cœur et à resservir dans votre prochaine flamewar) :

Like excrement, it [this book] contains enough undigested nuggets of nutrition to sustain life for some. But it is not a tasty pie: it reeks too much of contempt and of envy.

« Comme des excréments, [ce livre] contient assez de pépites nourissantes non digérées pour permettre à certains de vivre. Mais ce n’est pas un plat appétissant : il exhale trop le mépris et l’envie. »

— Dennis Ritchie

Ceux de ma génération et d’après considèrent souvent qu’en pratique Unix = Linux, même si intellectuellement nous savons (?) que ce n’est pas le cas. Oh, il y a bien encore Solaris, du moins jusqu’à ce qu’Oracle se lasse, un Hurd dont la ponctualité effraierait même un mainteneur Debian, et puis cette incarnation un peu exotique, qui est à Unix ce que le toucan est au Tyrannosaurus rex, MacOS X, autrefois connu sous le nom de NeXSTEP[1]. Et puis HP-UX, AIX dans pas mal d’entreprises, QNX dans l’embarqué… Linux lui-même se décline en tellement de versions qu’on pourrait parler de systèmes différents. Et Android et iOS entrent-ils dans la catégorie ?

Bref. Ce livre n’évoque même pas le Linux 0.99 sous Slackware ou Debian (déjà !) de l’époque, dure leçon d’humilité pour tous les fanatiques, fanboys et adeptes du libre. GNU n’existe alors que par Emacs et les compilateurs. Sun par contre est évoqué - de la même manière dont je vomissais ma bile autrefois sur Windows 98 (mais avec plus de style).

Unix (la version originale) date de l'époque où l’on marchait encore sur la Lune. Il a beaucoup évolué depuis, et avec succès. En fait, il serait devenu un virus (minimaliste et en conséquence portable, il vampirise son hôte, et mute souvent) avec une interface utilisateur.

Sun est une cible particulièrement appréciée. Dans mon esprit Sun et Solaris étaient associés aux gros Unix stables et indestructibles sur lesquels moulinent les bases Oracle critiques (ai-je simplement été victime du marketing ?), mais ici on croit entendre des linuxiens parler de Windows. Les stations Sun ne sont là que parce qu’elles sont moins chères, la stabilité n’est pas leur fort, et nombre des produits issus de la firme semblent mériter une haine inextinguible.

La mauvaise foi et les généralisations abusives suintent partout où les reproches ne sont pas solidement étayés par des anecdotes, exemples, et emails de victimes désespérées — donc seulement une ligne sur deux. Les flèches touchent d’autant plus juste que certaines lacunes unixiennes… ont persisté jusque 2011 ! Le tout sur un style pince-sans-rire typique du milieu.

Exemples :

sendmail

Ce logiciel de transfert de mail a sévi jusqu’à mon époque (j’ai très vite eu envie de découvrir postfix ou exim), et était déjà connu pour sa stabilité relative, ses fichiers de paramétrage cryptiques (encore plus proches du bruit blanc que perl, c’est dire), sa compatibilité pathologique avec la pléthore de systèmes de l’époque ( @#$@$^%<<<@# ) at @$%#^! est paraît-il une adresse email valide), sa capacité à interpréter le corps du message comme une suite d’adresses, ou les messages d’erreur Deferred: Not a typewriter. Avec un sens aigu de la justice équilibrée, un cri du cœur a été lancé en 1993 :

“The thing that gets me is that one of the arguments that landed Robert Morris, author of ‘the Internet Worm’ in jail was all the sysadmins’ time his prank cost. Yet the author of sendmail is still walking around free without even a U (for Unixery) branded on his forehead.”

« Ce qui me rend dingue, c’est que l’un des arguments utilisés pour envoyer en prison Robert Morris, l’auteur du “ver Internet” était ce que sa plaisanterie a coûté en temps d’administrateurs système. Et pourtant l’auteur de sendmail se balade encore librement sans même un U (pour Unixellerie) tatoué sur son front. »

Le livre dédié chez O’Reilly contenait plus de pages que Guerre et paix et aurait arrêté une balle tirée à bout portant. La chauve-souris de la couverture a inspiré une comparaison entre l’animal et l’outil, par exemple :

Bat guano is a good source of potassium nitrate, a principal ingredient in things that blow up in your face. Like Sendmail.

« Le guano de chauve-souris est une bonne source de nitrate de potassium, ingrédient principal des choses qui vous explosent à la figure. Comme Sendmail. »

Tout est un flux d’octets

La philosophie Unix, c’est « tout est un flux d’octets » (a stream of bytes), manipulés à l’aide d’une cascade d’outils divers, censés faire une seule chose et bien. En conséquence, les outils n’ont aucune cohérence quant aux arguments de ligne de commande.

Les rédacteurs regrettent amèrement l’absence de notion d’enregistrement. Chaque application doit en conséquence redécouvrir la roue de ce côté (“You see Unix knows parsing like Dan Quayle knows quantum mechanics.” (oui, forcément, les références politiques datent aussi)), par exemple sur un fichier aussi critique que /etc/passwd, où la synergie bugatoire avec sendmail s’exprime pleinement.

Un chapitre croustillant détaille l’absence de systèmes de locks et donc… leur émulation via deux systèmes qui s’ignorent (j’ai l’impression que perdure la situation...).

Le système de fichiers

Les systèmes de fichier actuels (ext4, ZFS…) ont bien évolué depuis l’antique UFS — qui est toujours là, avec ses répertoires contenant les noms des fichiers. Le temps a eu raison de certains des reproches, par exemple l’absence de journalisation (quoique pas depuis si longtemps sous Linux…). D’autres sont des lacunes toujours là dans une Ubuntu toute fraîche, même si des outils au-dessus du système de fichiers peuvent les combler :

  • pas de cryptage intégré ;
  • aucune notion de versions de fichiers (comme dans VMS) (et le prochain MacOS va redécouvrir la chose trois décennies plus tard !) ;
  • pas de notion de type de fichier comme les connaissent les Macintosh depuis 1984, juste des extensions aux noms de fichiers associés à des « nombres magiques » dans les fichiers eux-mêmes, nouvelles source de mille bugs (Les tendances sur le sujet sont contradictoires, avec le Mac OS X qui renonce aux ressources et ne prend en compte que l’extension et, dans la plupart des OS récents, les types reconnus par des couches supérieures via l’extension… Est-ce parce que la notion de métadonnée est hermétique à l’utilisateur et l’association d’icelles au fichier difficile à maintenir au fil des migrations et déplacements au travers du net et de divers systèmes ?) ;
  • la possibilité d’avoir dans le nom du fichier à peu près n’importe quoi d’autre qu’un /, d’où moults bugs ésotériques, fichiers ineffaçables, voire trous de sécurité (c’est encore plus drôle après qu’on a réussi à créer ce fichier avec un /...).

L’administration

Un Unix bien administré est censé avoir plusieurs partitions, histoire par exemple que /tmp ne remplisse pas de l’espace au détriment de /usr, ou pour sauvegarder une partition (forcément entièrement, jamais en live). Les utilisateurs d’autres systèmes ont beau jeu de dire qu’à l’inverse un système de fichier pouvait s’étaler sur plusieurs disques, et gérer l’espace grâce à des quotas, plus d’une décennie avant la rédaction du livre. Les partitions swap existent encore, d’ailleurs (en voie de disparition sur les Linux récents ?), quand le système de fichier pourrait tout simplement convenir.

Bref, toute la logique de gestion des disques vise en fait à contourner des limites ou les conséquences de bugs.

Un autre sujet, toujours d’actualité : la pléthore de fichiers de configuration.

Those allergic to Microsoft Windows with its four system configuration files shouldn’t get near Unix, lest they risk anaphylactic shock.

« Ceux allergiques à Microsoft Windows[2] et ses quatre fichiers de configuration ne devraient pas s’approcher d’Unix, au risque d’un choc anaphylactique. »

Bien sûr, tous ces fichiers ont une syntaxe différente, supportent ou pas des commentaires, et confondent ou pas tabulations et espaces. (Honnêtement, je préfère un bordel de fichiers texte qui sont à peu près localisables, au moins dans une Debian ou mon vieux Windows 3.1, à quelque chose de plus complexe à base de XML, ou, horreur, de binaire.)

Pour compliquer la chose, les outils standards font de même chacun leur sauce sans soucis de cohérence. Le phénomène s’étend jusqu’aux shells, dont il y a pléthore, aux sémantiques qui diffèrent parfois. Et écrire un script un peu costaud devant tenir compte de tous les cas devient un cauchemar.

And, indeed, that is my memory of Unix tools—you spend all your time learning to do complex and peculiar things that are, in the end, not really all that impressive. I decided I’d rather learn to get some real work done.

« En fait, c’est mon souvenir des outils Unix — on passe son temps à apprendre à faire des choses complexes et bizarres qui au final ne sont pas si impressionnantes. J’ai décidé que j’allais plutôt apprendre à bosser. »

— Jim Giles

(On voit que certains n’ont pas sué sur des bêtes fichiers .bat.) Les pipes permettent de faire communiquer des programmes, de manière fragile. Rien de sérieux n’a jamais été développé ainsi. Le Macintosh se passait très bien de cela (dans une utilisation totalement différente et sans soucis de réutilisation d’un script, œuf corse)(s’il lit jusque là, je sais qu’un certain lecteur aura déjà bondi et m’aura parlé d’un outil de scriptage remontant même à l’époque où Steve Jobs n’avait pas encore été viré d’Apple.).

Allez, j’adore ces deux paragraphes, surtout avec le recul et le passage à MacOS X :

When was the last time your Unix workstation was as useful as a Macintosh? When was the last time it ran programs from different companies (or even different divisions of the same company) that could really communicate? If it’s done so at all, it's because some Mac software vendor sweated blood porting its programs to Unix, and tried to make Unix look more like the Mac.
The fundamental difference between Unix and the Macintosh operating system is that Unix was designed to please programmers, whereas the Mac was designed to please users. (Windows, on the other hand, was designed to please accountants, but that’s another story.)


« À quand remonte la dernière fois où votre station Unix a été aussi utile qu’un Macintosh ? Quand pour la dernière fois avez-vous utilisé des programmes de différentes sociétés (ou même de différentes divisions d’une même société) qui pouvaient vraiment communiquer ? Si c’est même faisable, c’est qu’un vendeur de logiciels Mac a sué sang et eau pour porter ses programmes sur Unix, et tenté de transformer un Unix en Mac.
La différence fondamentale entre Unix et le système du Macintosh est qu’Unix a été conçu pour plaire aux programmeurs, alors que le Mac a été conçu pour plaire aux utilisateurs. (Windows, d’un autre côté, a été conçu pour plaire aux comptables, mais c’est une autre histoire.) »

NFS

The ‘N’ in NFS stands for Not, or Need, or perhaps Nightmare.

— Henry Spencer

Ce protocole inventé par Sun (déjà une tare en soi, apparemment) est coupable d’être sans état, sans sécurité (puisque basé sur des magic cookies), dans le but de contourner l’instabilité des serveurs et stations Sun, puis d’avoir eu besoin de rajouter état (verrous…) et sécurité par-dessus à coup de rustines. Les anecdotes sont cruelles. La page 291, au milieu d’une comparaison digne d’Umberto Eco, contient le délicieux :

The Sun kernel has a user-patchable cosmology.

« Le noyau Sun a une cosmologie rapiéçable par l’utilisateur. »

Pour finir, l’indépendance de NFS par rapport à l’OS client est une blague.

(Le récent NFS v4 valide a posteriori tout cela puisqu’il apparemment il garde le nom mais n’a plus rien à voir avec les versions précédentes.)

Le C, le C++ et le développement

Do not meddle in the affairs of Unix, for it is subtle and quick to core dump.

— Anonyme

L’annexe B l’affirme : le C et Unix sont un poisson d’avril qui a mal tourné. Thompson, Kernighan & Ritchie ont cherché en 1969 à créer le système le plus cryptique qui soit, parodie de Multics et du Pascal.

We stopped when we got a clean compile on the following syntax:

for(;P("\n"),R=;P("|"))for(e=C;e=P("_"+(*u++/ 8)%2))P("|"+(*u/4)%2); ”

Mouais.

Toujours est-il que les dinosaures rédacteurs regrettent l’époque où un programme qui plantait pouvait être débogué immédiatement, sans autopsier un core volumineux dont les symboles ont disparu (éventuellement écrasé par le propre core du débuggeur).

Sur le plan fondamental, le C est délicat à parser (analyser ?), d’où d’ailleurs les cascades d’erreurs de compilation générées par une seule faute de syntaxe. Quant au C++, c’est une cause perdue de ce point de vue. Et d’ailleurs : qu’est-ce que c’est que ce langage moderne qui n’a même pas de garbage collector ni même de grammaire claire ?

The only marvelous thing about C++ is that anyone manages to get any work done in it at all.

« La seule chose merveilleuse avec la C++, c’est que des gens arrivent à bosser avec. »

(J’ai l’impression que les reproches faits au C++ sont les mêmes de nos jours qu’il y a presque 20 ans. Non je ne connais pas vraiment le C++ et le peu que j’en connais m'a convaincu de le mettre tout en bas de la liste des langages à apprendre et que je n’aurai pas le temps d’apprendre.)

Sur le plan anecdotique, make exige des tabulations et non des espaces au début de ses fichiers de configuration (et encore de nos jours) : l’auteur aurait refusé de modifier sa syntaxe car il avait déjà dix (10) utilisateurs. (J’ai retrouvé le même problème dans le beaucoup plus récent rsnapshot.)

La sécurité

Au regard de ce qui va suivre, il semble accessoire qu’Unix ne supporte pas la moindre défaillance du matériel sous-jacent :

That’s because Unix programs usually don’t check for hardware errors—they just blindly stumble along when things begin to fail, until they trip and panic.

« C’est parce que les programmes Unix ne vérifient pas les erreurs matérielles — ils trébuchent dans le noir quand ça commence à dérailler, jusqu’à ce qu’ils se rétament en paniquant. »

Sur le plan logiciel, on insiste bien sur le fait que le ver Morris, un des premiers virus passés par le réseau en 1988, et qui l’a paralysé à l’époque, est bien un ver Unix : la faute à sendmail, finger, aux mots de passe faiblards…

Pire est mieux

Les auteurs vont jusqu’à dire que conceptuellement Unix est le représentant de l’école de pensée « Pire est mieux » : un truc qui marchotte maintenant est mieux qu’un truc parfait dans longtemps. La simplicité avant tout, et surtout avant la correction, la consistance ou l’exhaustivité.

Cela se retrouve dans les outils de développement par exemple (p 176) :

The designers of the Interlisp environment had a completely different approach. They decided to develop large sophisticated tools that took a long time to learn how to use. The payoff for investing the time to use the tools would be that the programmer who learned the tools would be more productive for it. That seems reasonable.

Sadly, few programmers of today’s machines know what it is like to use such an environment, in all its glory.


« Les concepteurs de l’environnement Interlisp avaient une approche complètement différente. Ils avaient décidé de développer de gros outils sophistiqués dont la maîtrise nécessitait beaucoup de temps. L’avantage pour le temps investi à apprendre ces outils serait que le programmeur qui les utiliserait serait plus productif. Cela semble raisonnable.

Hélas, peu de programmeurs sur les machines de maintenant savent ce que veut dire utiliser un environnement dans toute sa splendeur. »

(Je me fais violence pour ne pas commenter et fournir de nombreux exemples où on code d’abord et on apprend après. Certes pas dans un contexte universitaire comme celui des auteurs du livre.)

Et puis :

Consistent mediocrity, delivered on a large scale, is much more profitable than anything on a small scale, no matter how efficient it might be.

« La médiocrité constante, délivrée à grande échelle, est bien plus profitable que n’importe quoi à petite échelle, aussi efficace que cela soit. »

Il est hilarant de constater que tout ce que l’on reproche ou a reproché à Windows jusque récemment l’a été à Unix : un outil léger bancal immédiatement accessible qui marche la plupart du temps vs le gros Unix propriétaire rigide et complexe. Soit Windows marque une nouvelle descente dans le néant, soit Unix s’était entretemps stabilisé — comme Windows l’a fait ensuite.
Les pessimistes noteront que le « bancal tout de suite » au lieu de « réfléchi demain » est également la philosophie dominante pour tout ce qui concerne ce qui se fait sur le web, voire l‘économie entière, pression du court terme oblige. Au moins là y a-t-il une certaine sélection naturelle qui s’opère (pour le mieux ? c’est discutable).

Lisez-le !

Le PDF est gratuitement en ligne mais hélas je ne connais aucune traduction française. En même temps, celui qui s’intéresse au Néolithique Paléozoïque de l’informatique a intérêt à maîtriser l’anglais.

Voir aussi la page Wikipédia dédiée, la page de pub de l’époque, ou encore l’archive de la liste de diffusion qui a donné naissance au livre. On y trouvera d’autres merveilles assassines non incluses dans le livre comme A Requiem for a Dying Operating System, The UNIX cult, The Top 10 Ways to get screwed by the "C" programming language[3].

Critiques

Il existe des critiques du livres sur le net, par exemple celle d’Eric Raymond en 2008 : en gros, il reproche au livre d’être daté (forcément), de noyer « une once de pertinence dans une livre de polémique », de ne pas prendre en compte les interfaces graphiques apparues un lustre plus tard voire plus, de ne pas reconnaître qu’ailleurs ce n’était pas mieux, et de ne pas avoir prévu Linux (qui découvrait à l’époque ce qu’était un réseau), ou Python (vagissant également), plus perfidement d’avoir été en 1994 bloqué aux années 80, ou d’avoir été du mauvais côté de l’histoire (un des auteurs a participé à NeWS, concurrent de X) et de tomber dans le romantique regret de ce qui aurait pu être ; même de ne pas avoir cherché eux-même à améliorer la chose. En fait, ESR justifie de grosses parties du bouquin (ici à propos du C) :

Gradually, in a messy and evolutionary way, the Unix community is teaching itself the lesson that the authors of this chapter wanted to give it. I agree with them that it could have happened faster and should have happened sooner.

« Graduellement, de manière brouillonne et par évolutions successives, la communauté Unix s’est enseigné la leçon que les auteurs de ce chapitre voulait lui donner. Je leur accorde que cela aurait pu arriver plus vite et aurait dû arriver plus tôt. »

Beaucoup moins récemment, en 1997, la Linux Gazette parlait du livre (en pleine explosion du nouvel OS libre) : Andrew Kuchling reconnaît quelque pertinence (“The chapter on the X Window System is devastating and accurate.”) et se demande si la raison de ces plaintes ne serait pas qu’en 1994 les Unix libres au source ouvert étaient beaucoup moins répandus et connus : certaines lacunes ont été corrigées à ce moment. Dans ce sens, le livre est une mine d’idées d’améliorations — pour beaucoup implémentées dans Linux ou MacOS X quatorze ans après.

En notre millénaire (2003), Slashdot a lancé un fil lors de la publication intégrale en ligne : au milieu des habituels verbiages et crachats sur Windows, on trouve quelques gemmes, comme ce rappel du contexte par un des auteurs, qui ne regrette rien.

Validité

Il a été dit que le Handbook n’est plus drôle depuis la sortie de Windows NT 4 (maudit soit son nom). L’année 1995, celle d’après la parution du livre, marque le début de l’apogée de Microsoft, sur les bureaux d’abord, dans les serveurs ensuite, et l’union sacrée contre Redmond fut alors de mise.

Les tables tournèrent et Windows se prit dans la tronche tous les reproches des barbus à Unix : instabilité pathologique (par exemple Windows 95 plantait systématiquement après une quarantaine de jours, et on mit des années à s’en apercevoir) [4], mépris des standards (et carrément by design), impossibilité de scripter… Windows s’est bien amélioré depuis[5] même si son hégémonie est menacée à terme (des mondes entiers se développent sans lui, sous Linux, MacOS, Android…). Y aura-t-il un nouveau système « bâclé mais suffisant » pour nous faire regretter Windows ?

Ou est-ce le libre (qui fait tourner l’essentiel des supercalculateurs, des box comme des téléphones évolués de nos jours, de Linux à Java en passant par BSD, Apache...) qui a réellement changé la donne ? Et si le libre était apparu dès l’époque de Multics, VMS et autres regrettés dinosaures ammonites ichthyostegas créatures précambriennes de l’informatique ? ESR, dans la critique ci-dessus, le reconnaît pour X : il a gagné parce qu’open source.

Notes

[1] L’orthographe n‘est pas claire et déjà à l’époque ils s’interrogeaient sur la nature de la créature de Steve Jobs : “NeXT, meanwhile, calls their version of Unix (which is really Mach with brain-dead Unix wrapped around it) NEXTSTEP. But it’s impossible to get a definition of NEXTSTEP: is it the window system? Objective-C? The environment? Mach?”

[2] Époque bénie où on se cassait les dents sur AUTOEXEC.BAT au lieu de se noyer dans la base de registre.

[3] Et moi non plus je ne peux pas supporter ce langage. En fait c’est comme la nitroglycérine, il faut le laisser aux gens qui en ont vraiment besoin pour faire des choses que le commun des mortels ne fait jamais.

[4] Et la situation était tellement sérieuse qu’un des lecteurs de ce blog écrivit un outil pour personnaliser l’écran bleu. Souvenirs souvenirs…

[5] Si si !