Site WWW de Laurent Bloch
Slogan du site

ISSN 2271-3905
Cliquez ici si vous voulez visiter mon autre site, orienté vers des sujets moins techniques.

Pour recevoir (au plus une fois par semaine) les nouveautés de ce site, indiquez ici votre adresse électronique :

De Multics à Unix et au logiciel libre
Article mis en ligne le 16 juillet 2014
dernière modification le 21 août 2014

par Laurent Bloch
logo imprimer
Licence : CC by-nd

Un échec plein d’avenir

Multics est un système d’exploitation né en 1964 au MIT (Massachusetts Institute of Technology) dans le cadre d’un projet de recherche nommé MAC, sous la direction de Fernando Corbató. La même équipe avait déjà créé le système CTSS. Multics était destiné aux ordinateurs General Electric de la famille GE 635, pour lesquels le constructeur fournissait de son côté un système d’exploitation plus conventionnel. Le projet associait le MIT, General Electric et les Bell Telephone Laboratories (une filiale d’AT&T, American Telegraph and Telephone, qui détenait le monopole des télécommunications pour les États-Unis).

L’objectif du projet était la réalisation d’un grand système informatique capable de fournir des services interactifs en temps partagé à un millier d’utilisateurs simultanés. Multics comportait beaucoup d’innovations de grande portée : le langage de commande pour piloter le fonctionnement de la machine était un langage de programmation, le même que celui dont disposait l’utilisateur pour interagir avec le système, le shell, inventé par Louis Pouzin pour le système prédécesseur de Multics, CTSS (cf. ci-dessous). Le système d’exploitation était écrit en langage évolué (en l’occurrence PL/1), voie ouverte par les systèmes Burroughs écrits en Algol, mais encore peu fréquentée. Les concepts de mémoire centrale pour les données volatiles et de fichiers pour les données persistantes étaient fondus en un concept unique de mémoire virtuelle segmentée, certains segments étant dotés de la qualité de persistance. Les segments persistants étaient catalogués dans des répertoires à l’organisation arborescente. Moins spectaculaire en apparence mais peut-être aussi importante était l’existence de toute une collection d’outils programmables et combinables entre eux destinés à faciliter le travail d’un type d’utilisateur : le programmeur, et plus spécialement celui qui écrivait un système d’exploitation.

Malgré ou à cause de toutes ces qualités uniques et promises à un grand avenir, Multics fut en gros un échec, au moins du point de vue de sa diffusion. Ses mérites furent reconnus tardivement, et le plus souvent tacitement, par ceux qui en reprirent les idées à leur compte.

Cette méconnaissance longue des mérites de Multics a ses raisons : la technologie des ordinateurs disponible à l’époque de sa diffusion, essentiellement pendant les années 1970, ne permettait de mettre en œuvre les méthodes et les concepts élaborés de ce système qu’au prix d’une grande lourdeur. Les ordinateurs exploités sous Multics étaient gros, chers et lents. L’institut de statistique qui employait à l’époque l’auteur de ces lignes en avait acquis un, fruit de la fusion CII-Honeywell-Bull, et ses experts en informatique démographique avaient essayé d’imaginer les moyens de traiter avec cet engin les recensements de la population, mais ils avaient fini par regarder ce drôle de système un peu de l’œil de la poule qui a couvé un œuf de cane.

Leur perplexité n’avait d’ailleurs d’égale que celle des ingénieurs commerciaux qui essayaient de vendre la chose, ou celle des ingénieurs spécialistes de Multics auxquels nous posions des questions incongrues comme « Pourrions-nous traiter des fichiers sur bande magnétique en traitement par lots ? », méthode béotienne mais indispensable à l’époque du fait de la faible capacité des disques.

Il résulta de cette expérience peu de résultats nouveaux dans le travail statistique courant, mais un sursaut intellectuel parmi ceux des informaticiens qui n’avaient pas définitivement sombré dans la léthargie coboliste [1] dont on n’émergerait que pour sombrer dans Windows. Si changer de langage ou de système ne rend pas plus intelligent, il y a des systèmes et des langages qui incitent à la réflexion, et d’autres moins. Cela dépend pour une grande part du type d’initiative laissé à l’utilisateur et du niveau d’intelligibilité que le système exhibe. Il y a des systèmes dont les paramètres de fonctionnement sont enfouis dans des fichiers binaires inaccessibles à l’utilisateur, qui n’a qu’un seul choix : cliquer sur des menus en espérant que cela finira par produire un résultat désiré ; c’est le cas de Windows. Unix au contraire contient tous ses paramètres dans des fichiers texte lisibles et réunis dans un endroit connu (le répertoire /etc). La première méthode n’est justifiable que si la réalisation du système est sans faille, et autorise l’utilisateur à ne jamais se préoccuper de ces paramètres, ce qu’ont réussi les concepteurs de MacOS, mais pas ceux de Windows ; elle suppose aussi que lesdits utilisateurs ne sont que cela, utilisateurs, qu’ils ne nourrissent aucun intérêt pour le système et n’envisagent pas une seconde de se mettre à le modifier, ou du moins à en modifier le comportement en jouant sur les paramètres.

Multics, sous cet angle comme sous certains autres, était un précurseur d’Unix, système qui considère ses utilisateurs comme des personnes intelligentes, mais aussi suffisamment intéressées par le système lui-même pour lui consacrer un temps non négligeable dont les employeurs ne comprennent pas toujours la fécondité. C’est ainsi que des industriels ont inventé pour Unix une interface utilisateur nommée CDE (Common Desktop Environment) dont le principe est de plaquer sur le système une sorte de super-Windows dont le paramétrage, réservé à des administrateurs, est ensuite propagé à la masse des utilisateurs. Cette vision centralisée et hyper-organisée aurait sans doute bien réussi dans les années 1960, mais elle risque de ne pas résister aux sables mouvants de la sociologie réelle des organisations des années 2000.

Où l’on commence à rêver à Unix

Les créateurs d’Unix, Ken Thompson et Dennis M. Ritchie, avaient une forte expérience de Multics, et ils savaient aussi bien ce qu’ils voulaient en retenir que ce qu’ils en rejetaient. Ils en retenaient notamment les aspects suivants :

- Le système est écrit non pas en assembleur, mais dans un langage de haut niveau (PL/1 pour Multics, C pour Unix). Seuls quelques fragments du code du noyau intimement liés à un matériel particulier sont en assembleur. Ceci facilite le portage [2] du système sur un nouveau modèle d’ordinateur. On a pu dire que le langage C était un assembleur portable.
- Le système de commandes qui permet de piloter le système est le même interpréteur qui permet à l’utilisateur d’exécuter des programmes et des commandes, et il donne accès à un langage de programmation. C’est le shell.
- Le système de fichiers d’Unix est très inspiré de celui de Multics, d’où vient aussi l’idée d’exécuter chaque commande comme un processus distinct.
- Mais surtout, comme Dennis Ritchie l’a expliqué dans son article de 1979, ce que lui et ses collègues des Bell Laboratories voulaient retrouver de Multics en créant Unix, c’était un système qui engendrait pour ainsi dire spontanément la communication et l’échange d’expériences entre ses adeptes.

Cette qualité, partagée par Multics et Unix, d’être propice à la création d’une communauté ouverte et communicative, mérite que l’on s’y arrête. Lorsque Multics a été introduit dans l’Institut statistique évoqué ci-dessus, il y a immédiatement cristallisé la formation d’une petite communauté intellectuelle, que la Direction n’a d’ailleurs eu de cesse de résorber parce qu’elle n’en comprenait pas la fécondité et qu’elle percevait son activité comme un gaspillage. D’innombrables expériences similaires ont eu lieu autour de Multics et d’Unix, sans qu’une cause unique puisse leur être attribuée. Le fait que ces systèmes aient été créés par des chercheurs, habitués à l’idée que la connaissance soit objet de partage gratuit et de communication désintéressée mais assortie de plaisir, est un élément. L’existence de logiciels commodes pour la création de textes, le courrier électronique et les forums en ligne a aussi joué, mais cette existence était-elle une cause ou une conséquence ? La nature programmable du shell, l’accès possible pour tous aux paramètres du système, inscrits dans des fichiers de texte ordinaires, encourageaient un usage intelligent du système, et l’intelligence va de pair avec l’échange.

Si l’on compare Multics et Unix aux systèmes industriels disponibles à l’époque, comme l’OS 360, GCOS 8 ou plus tard VMS de Digital Equipment, il apparaît que ces derniers ne sont pas conçus dans le même esprit : l’utilisateur dispose d’un mode d’emploi du système, réputé contenir les solutions pour tout problème qu’il pourrait se poser. Lorsque tout ceci est bien fait, comme par exemple dans VMS, le système à mémoire virtuelle conçu pour l’ordinateur VAX, cela suscite un usage efficace et commode mais passif du système.

L’auteur de ces lignes a été un utilisateur longtemps réticent et sceptique d’Unix, dérouté par l’aspect « boîte à outils » du système. VMS, que je pratiquais simultanément, avait été conçu par une équipe de (très bons) ingénieurs, soucieux de livrer un produit homogène et cohérent, et ils avaient parfaitement réussi. La meilleure preuve de cette réussite était la documentation du système, souvent un aspect un peu négligé : celle de VMS était une merveille de clarté et d’exhaustivité, au prix certes d’un nombre impressionnant de mètres linéaires de rayonnage. Mais quel que soit le problème à résoudre, on était sûr que la réponse était dans la « doc ». Lorsque Digital Equipment a produit sa propre version d’Unix, ils ont publié un petit manuel résumé des commandes Unix, baptisé « The little grey book » (la couleur canonique de la documentation Digital venait de virer de l’orange au gris). Par opposition, la documentation VMS s’est trouvée baptisée « The big grey wall ».

Habitué donc à l’univers confortable et hyper-balisé de VMS, je découvrais avec Unix un système de prime abord beaucoup moins homogène, même si je devais découvrir plus tard que son homogénéité résidait ailleurs. Comme chaque commande Unix s’exécute sous le contrôle d’un processus distinct, elle peut être assez découplée du noyau du système. Cette modularité, qui est un avantage, avait permis de confier l’écriture de beaucoup de commandes à des étudiants en stage, quand elles n’étaient pas tout simplement des contributions spontanées, et alors leur qualité et celle de leur documentation pouvaient être assez inégales.

De Multics les créateurs d’Unix rejetaient la lourdeur. La tentation fatale, pour des auteurs de systèmes informatiques en général, et de systèmes d’exploitation ou d’architectures de processeurs tout particulièrement, consiste à céder au perfectionnisme et à réaliser des dispositifs qui ajouteront au système global une complexité considérable pour résoudre des problèmes qui ne surgiront que très rarement. Les problèmes rares peuvent se contenter de solutions inefficaces mais simples. Force est de constater que les auteurs de Multics n’ont pas évité cette ornière. VMS non plus d’ailleurs, qui succédait aux merveilleux RSX-11M et autres IAS.

Frederick P. Brooks, le concepteur de l’OS/360, dans son livre justement célèbre The Mythical Man-Month, décrit ce qu’il appelle le syndrome du second système, et qui s’applique à Multics comme à l’OS/360 : une équipe constituée en grande partie des mêmes hommes autour de Fernando Corbató avait développé avec succès CTSS ; en s’attaquant à Multics ils ont voulu y introduire tous les perfectionnements coûteux qu’ils avaient, avec sagesse mais frustration, écartés de leur œuvre précédente. En informatique comme ailleurs, point de salut sans une part de renoncement.

En fait, à la fin des années 1960, l’échec de Multics aux Bell Labs était patent. L’équipe qui allait y concevoir Unix, autour de Ken Thompson et Dennis Ritchie, comprit que Multics ne serait pas utilisable pour un travail réel dans un délai raisonnable. De son côté le propriétaire de Multics, la compagnie General Electric, se sentait assez peu concerné par ce système développé par des chercheurs universitaires et préférait commercialiser ses ordinateurs avec son système conventionnel, GECOS. Lorsque Multics deviendrait utilisable, à la toute fin des années 1970, les ordinateurs qu’il pouvait piloter étaient définitivement périmés et sans espoir de succession.

Dans un article de 1979 Dennis Ritchie a décrit cette période où les Bell Labs se retiraient du projet Multics. Ce processus s’accompagnait d’un autre facteur d’incertitude : une réorganisation visait à séparer les équipes de recherche en informatique des équipes de l’informatique opérationnelle ; ce genre de séparation, conforme aux vues des managers financiers efficaces et à jugeote courte, a pour conséquence habituelle de diminuer les moyens disponibles pour la recherche et de réduire la qualité de l’informatique opérationnelle, privée de stimulation intellectuelle. Le groupe de D. Ritchie, K. Thompson, M. D. McIlroy et Joseph F. Ossanna souhaitait conserver l’environnement de travail luxueux que Multics leur procurait à un coût d’autant plus exorbitant qu’ils en étaient les derniers utilisateurs. Pour ce faire ils allaient développer leur propre système sur un petit ordinateur bon marché et un peu inutilisé récupéré dans un couloir, un PDP 7 de Digital Equipment. Unix était sinon né, du moins conçu.

Les hommes d’Unix : sociologie des sciences et des hiérarchies

Effectivement, peu de femmes dans cette histoire. Raison de plus pour mentionner Evi Nemeth (disparue en mer en 2013 entre l’Australie et la Nouvelle-Zélande), et, peut-être pas tout à fait dans le même domaine ni à la même époque, Radia Perlman, spécialiste des protocoles de réseau [3], et Elizabeth Zwicky.

Le lecteur, à la fin de l’alinéa précédent, se sera peut-être fait la réflexion que pour que des employés d’une grande entreprise puissent développer un système d’exploitation, même ascétique, pendant leur temps libre, il fallait que leur encadrement ne soit pas trop rigide. Parce que ce même lecteur devrait maintenant être convaincu que le système d’exploitation est l’objet technique le plus complexe que l’homme ait conçu et réalisé au cours du XXe siècle. Quelle était au fait la mission théorique de ces jeunes gens ? Qui contrôlait la réalisation de leurs objectifs ?

Peter H. Salus a écrit un livre (A Quarter Century of UNIX) qui met en scène les principaux acteurs de la naissance d’Unix. De prime abord, on est frappé en lisant ces aventures de découvrir que cette création, qui a eu des répercussions considérables dans les domaines technique autant qu’industriel et économique, n’a vraiment été décidée ni par un groupe industriel, ni par un gouvernement, ni par aucun organisme doté de pouvoir et de moyens financiers importants. On peut d’ailleurs en dire autant de l’Internet, une autre création aux répercussions considérables, d’ailleurs très liée à Unix et issue du même milieu social.

À la lecture du livre de Salus, quiconque a un peu fréquenté les milieux scientifiques d’une part, les milieux industriels de l’autre, ne peut manquer d’être frappé par le caractère décalé, pour ne pas dire franchement marginal, de la plupart des acteurs de la genèse unixienne.

Le monde de la science a sa hiérarchie, où les disciplines spéculatives et abstraites ont le pas sur les recherches appliquées et les disciplines descriptives, et où bien sûr (surtout en France) les chercheurs sont patriciens et les ingénieurs et techniciens ilotes, entourés d’une population au statut incertain, les étudiants en thèse ou en post-doc, dont une minorité d’élus accédera au patriciat mais dont la majorité ne deviendra même pas ilote, contrainte à descendre aux enfers, c’est-à-dire le monde réel des entreprises industrielles et commerciales.

Dans cet univers social, l’informatique, discipline récente et mal identifiée, perçue (au mépris de toute vraisemblance, mais qu’importe au sociologue) comme un vague sous-produit de la branche la moins noble des mathématiques (l’analyse numérique), se situe plutôt vers le bas. Au sein de la discipline informatique, le haut du pavé est tenu par les domaines où il y a une théorie possible, de préférence mathématique ou à la rigueur physique : linguistique de la programmation, algorithmique (surtout numérique ou logique), traitement de l’image ou du signal en général. Les systèmes d’exploitation disposent de tout un arsenal de concepts, mais pas d’une théorie, c’est ainsi ; de surcroît ils sont bien près du matériel, cette chose qui a des relents de cambouis et de sueur. Donc ils sont en bas. Alors des ingénieurs qui s’occupent de systèmes d’exploitation...

Le monde industriel (nous nous plaçons à l’époque de la naissance d’Unix, avant la prise de pouvoir par les financiers à costume noir et cortex de calmar) a (avait ?) un système de valeurs symétrique de celui de la science : on y respecte (au moins dans les entreprises dotées d’une vraie tradition industrielle et qui ont su la conserver, c’est-à-dire, en France, rarement) celui qui fait des choses, de vraies choses. C’est un univers dominé par les ingénieurs, qui sont censés se coltiner avec la matière. On sait bien qu’une industrie dynamique doit avoir des centres de recherche, et que dans ces endroits travaillent des types bizarres appelés chercheurs, mais même si on ne les méprise pas vraiment, ils sont considérés avec une certaine distance.

Or que nous apprend Salus ? Thompson et Ritchie étaient chercheurs dans une entreprise industrielle. Au fur et à mesure de leur apparition, les noms de ceux qui ont fait Unix, parmi eux Kirk McKusick, Bill Joy, Eric Allman, Keith Bostic, sont toujours accompagnés d’un commentaire de la même veine : ils étaient étudiants undergraduates ou en cours de PhD, et soudain ils ont découvert qu’Unix était bien plus passionnant que leurs études. Bref, les auteurs d’Unix n’ont jamais emprunté ni la voie qui mène les ingénieurs perspicaces vers les fauteuils de Directeurs Généraux, ni celle que prennent les bons étudiants vers la tenure track, les chaires prestigieuses, voire le Nobel [4].

Introduction à la démarche unixienne

Comme le note Christian Queinnec aux premiers mots de son livre ABC d’Unix « UNIX est un système de production de programme ». Et, conformément à l’esprit d’Unix, cette assertion est à prendre à la fois de façon extensive : ce système comporte tout ce dont peut rêver un auteur de programme, et, aussi, de façon restrictive : malgré quelques concessions récentes, il ne comporte fondamentalement rien d’autre. Les Unix modernes tels que Linux sont certes dotés de logiciels utilisables par le commun des mortels, avec des interfaces graphiques, mais les vrais unixiens n’en abusent pas.

La documentation canonique d’Unix (les man pages) constitue une excellente entrée en matière : aucun effort pédagogique, aucune de ces redondances qui facilitent l’acquisition d’une notion. Les mots en sont comptés, aucun ne manque mais pas un n’est de trop. La lecture attentive (très attentive) de ces pages délivre une information nécessaire et suffisante à l’usage du système, d’où une locution proverbiale souvent proférée par les Unixiens expérimentés en réponse à un néophyte qui demande de l’aide : « RTFM ! » (Read the f... manual !). On le voit, Unix est à l’opposé de ces logiciels à interface graphique dont les vendeurs laissent croire qu’ils peuvent être utilisés sans lire aucune documentation [5].

À qui était, comme l’auteur, habitué aux systèmes des grands ordinateurs IBM des années 1970, ou au système VMS que Digital Equipment Corporation (DEC) avait développé pour ses ordinateurs VAX, la transition était rude. Les systèmes d’IBM et de DEC étaient conçus dans le but d’élargir l’audience de l’informatique à des utilisateurs moins professionnels, à une époque où les micro-ordinateurs n’existaient pas. Pour ce faire, la syntaxe de leur langage de commandes cherchait à s’adoucir en utilisant des lexèmes plus proches du langage humain, en tolérant des abréviations ou au contraire des tournures plus bavardes mais plus faciles à mémoriser. La réponse du système à une commande était aussi édulcorée : présentation aérée, commentaires explicatifs.

Pour un Unixien, toutes ces variations pédagogiques ne sont que concessions coupables à l’ignorance informatique des secrétaires et des comptables. L’initiation informatique des ces professions respectables est peut-être un objectif louable, mais dont il ne veut rien savoir, et Unix non plus, parce que pour un développeur [6] ces aides pédagogiques sont autant d’obstacles à son travail.

La syntaxe des commandes Unix est sèche comme un coup de trique, d’une part parce qu’elles sont destinées à des professionnels qui les connaissent par cœur à force de les utiliser à longueur de journée, d’autre part parce qu’elles constituent un langage de programmation (le shell) qui permettra d’automatiser des opérations répétitives, et que pour un langage toute souplesse syntaxique se paye en espace et en temps (il faut bien écrire les instructions qui vont interpréter les commandes, et autant de variations possibles autant de dizaines de lignes de code en plus).

La réponse du système à l’utilisateur qui lui soumet une commande est tout aussi austère, le plus souvent d’ailleurs il n’y a pas de réponse. Ainsi, si vous voulez modifier le nom d’un fichier, et que le nouveau nom que vous souhaitez lui donner est déjà pris par un autre fichier, si le renommage est effectué le fichier homonyme sera détruit. Les systèmes à l’usage des secrétaires, des comptables ou des présidents d’université, face à un tel cas, posent la question à l’utilisateur : « veux-tu vraiment détruire l’autre fichier ? », ou renomment le fichier menacé. Pour Unix rien de tel : le fichier est froidement détruit sans même une notification post mortem. C’est un système pour les vrais hommes, qui savent ce qu’ils font, assument leurs erreurs et savent les réparer.

Mais à cet ascétisme il y a une raison encore plus dirimante, et qui n’est pas de l’ordre du sado-masochisme. L’invention sans doute la plus géniale d’Unix est la possibilité, par la simple syntaxe du shell, de réaliser des opérations de composition de processus, au sens algébrique du terme.

Les opérations les plus simples consistent à rediriger les résultats de sortie d’une commande vers un fichier, et à donner en entrée à une commande des données stockées dans un fichier, ce qui n’est pas encore de la composition de processus. Mais pour réaliser ceci il fallait déjà standardiser les formats d’entrée et de sortie des commandes, et découpler les mécanismes d’entrée et de sortie, pour introduire les notions d’entrée standard et de sortie standard, ce qui ouvrait la voie à des réalisations plus ambitieuses.

L’opérateur de composition de processus en séquence est «  ; ». On remarque la concision. « a ; b » se lit : exécuter la commande a, puis la commande b. La plupart des commandes Unix s’exécutent comme un processus indépendant. Le lancement d’un programme créé par un utilisateur obéit à la même syntaxe et aux mêmes règles, ce qui encourage les développeurs à utiliser les conventions des commandes Unix, et ainsi à contribuer à l’enrichissement du système.

L’opérateur de composition de processus parallèles asynchrones est « & ». « a & b » se lit : lancer l’exécution de a, puis sans attendre qu’elle se termine lancer aussitôt b. Les deux processus seront concomitants (et concurrents pour l’acquisition du contrôle du processeur).

L’opérateur de composition de processus parallèles synchrones est « | ». « a | b » se lit : lancer l’exécution de a, puis lancer b qui va aussitôt attendre la première ligne de résultat issue de a, la traiter puis se bloquer en attente de la suivante, etc.

Prenons un exemple simple : je veux la liste de tous les processus en cours d’exécution qui exécutent le serveur WWW Apache, avec leur numéro de processus.

La commande qui affiche la liste des processus s’appelle « ps », qui doit, pour afficher non seulement les processus de l’utilisateur mais tous les autres, être agrémentée des paramètres a et x, ce qui s’écrit donc « ps ax ». Cette commande va produire la liste de tous les processus, avec leur numéro et le nom du programme exécuté, à raison d’une ligne par processus. Je veux filtrer cette liste pour n’en retenir que les lignes où le nom de programme qui apparaît est apache.

Parmi les plus belles commandes d’Unix il faut citer grep (pour global regular
expression print
retranscrit plus tard en general regular expression parser, analyseur général d’expressions régulières). Cette commande peut faire des choses très savantes, mais nous allons l’utiliser de façon très simple, pour retrouver une chaîne de caractères dans le texte soumis à son entrée standard. « grep apache » signifie : si la ligne de l’entrée standard contient le texte « apache », afficher le texte à l’écran, sinon passer à la suivante.

Nous allons composer les deux commandes « ps ax » et « grep apache » par l’opérateur de composition parallèle synchrone « | » :

ps ax | grep apache

Chaque ligne issue de la première commande sera soumise à la seconde pour analyse, ce qui réalisera le filtre souhaité :

$ ps ax | grep apache
 284 ?        S      0:00 /usr/sbin/apache
 295 ?        S      0:00 /usr/sbin/apache
 296 ?        S      0:00 /usr/sbin/apache
 297 ?        S      0:00 /usr/sbin/apache
 298 ?        S      0:00 /usr/sbin/apache
 299 ?        S      0:00 /usr/sbin/apache
 434 pts/0    S      0:00 grep apache

Je reçois ainsi la liste de tous les processus Apache avec leur numéro, et en prime le processus d’analyse, puisque sa ligne de commande comporte elle aussi le texte apache.

Cette métaphore du filtre est promue au rang de paradigme par UNIX : les programmes vraiment unixiens doivent être écrits comme des filtres, c’est à dire recevoir un flux de caractères sur leur entrée standard et émettre un flux de caractères (convenablement modifié) sur leur sortie standard, ce qui permet de les combiner ad libitum.

C’est le livre de Jean-Louis Nebut [7] qui me semble-t-il explicite le mieux la syntaxe du shell en termes de filtres et de composition de processus. Il est aisé de concevoir que le fonctionnement d’un tel système suppose une discipline assez ascétique dans la syntaxe des commandes et leur mode d’interaction. Notamment, puisqu’elles doivent être les syntagmes d’un langage de programmation, dont les programmes sont usuellement appelés shell scripts, il n’est pas souhaitable que les commandes engagent un dialogue avec l’utilisateur, qui dans ce cas ne sera pas un humain mais le système d’exploitation. Vous avez dit interface graphique ? passez votre chemin : seule vaut la ligne de commande.

Dissémination d’Unix

Un système exigeant

Nous venons de dire qu’Unix était un système de production de programme, conçu pour satisfaire les programmeurs professionnels et à peu près personne d’autre. Comment expliquer alors qu’il se soit répandu dans beaucoup d’autres domaines, souvent au prix de beaucoup de crises de nerfs de la part d’utilisateurs furieux ? Parce qu’il faut bien dire qu’Unix n’est pas un système confortable pour qui n’est pas disposé à y consacrer la moitié de son temps de travail.

L’auteur de ces lignes, il y a de nombreuses années, a compris que s’il voulait espérer conserver l’estime de certains collègues il lui fallait savoir se servir assez couramment d’Unix et surtout de l’éditeur de texte Emacs avec lequel d’ailleurs il compose le présent texte. Cette prise de conscience a entraîné de nombreuses et lourdes conséquences. Il en va d’Emacs comme d’Unix : aucun espoir d’acquérir un minimum de maîtrise de cet éditeur (œuvre géniale de Richard Stallman) sans plusieurs heures de pratique quotidienne, qui au bout de quelques mois permettront de savoir raisonnablement utiliser quelques dizaines parmi ses 14 000 et quelques fonctions, sans parler du langage de programmation qui lui est incorporé. Bien, il fallait s’y mettre, et pour cela une seule solution : utiliser Unix et Emacs pour tout, rédaction de documents, courrier électronique, lecture des News du Net.

De ce type de situation on serait tenté d’inférer une conception un peu paradoxale du métier d’informaticien : le travail consisterait essentiellement à rester en symbiose avec le système et les outils de base comme Emacs, à se tenir au courant de leurs évolutions en fréquentant des collègues, par des rencontres, des colloques, les News, à essayer les nouveaux logiciels dès leur sortie, et, logiquement, à en produire soi-même. Il va de soi que dans cette perspective les demandes trop précises d’un employeur qui n’aurait pas compris ce processus seraient perçues comme autant d’obstacles mesquins. Le trait ici est bien sûr forcé, mais l’employeur avisé n’oubliera pas que ses ingénieurs, pour rester compétents, ont besoin de temps pour les activités énoncées ci-dessus.

La conclusion qui semblerait logique après la lecture des lignes précédentes serait qu’Unix aurait dû disparaître sous les coups furieux des DRH et des chefs de projet, ou du moins aurait dû rester cantonné à un petit monde de chercheurs, de développeurs et de hobbyistes. Il n’en a rien été pour au moins deux raisons exposées ci-dessous.

Naissance d’une communauté

Lorsqu’après quelques années de travail assez confidentiel il n’a plus été possible à AT&T (American Telegraph and Telephone) d’ignorer le travail de Thompson et Ritchie, celui-ci avait acquis une certaine ampleur et une certaine notoriété, notamment dans le monde universitaire. AT&T décida de vendre Unix assez cher aux entreprises [8], et se laissa convaincre d’en concéder l’usage gratuit aux universités. Cette décision fut à l’origine de la popularité d’Unix dans le monde universitaire.

C’est en 1974 que Vinton Cerf (de l’Université Stanford) et Robert Kahn (de BBN) publièrent le premier article sur TCP/IP, qui allait devenir le cœur des protocoles de l’Internet. Le travail sur les protocoles fut intense, avec des contributions décisives, soit dit sans chauvinisme, du Français Louis Pouzin déjà cité. En 1977 TCP/IP atteignit une certaine maturité, et c’est de ce moment que l’on peut dater la naissance de l’Internet expérimental.

En 1979 la DARPA lançait des appels d’offres assez généreux auprès des centres de recherche prêts à contribuer au développement de TCP/IP, elle souhaitait notamment l’adapter au VAX 11/780, l’ordinateur à mots de 32 bits que DEC venait de lancer (les PDP-11 étaient des machines à mots de 16 bits). Bill Joy, du Computer Systems Research Group (CSRG) de l’Université de Californie à Berkeley et futur fondateur de Sun Microsystems, convainquit la DARPA qu’Unix serait une meilleure plateforme que VMS pour ce projet parce qu’Unix avait déjà été porté sur plusieurs types d’ordinateurs.

De fait, dès 1977 le CSRG avait créé une version expérimentale d’Unix (la « 1BSD », pour Berkeley System Distribution) dérivée de la Sixth Edition des Bell Labs. La Seventh Edition de 1978 tournait sur DEC PDP-11 et avait été portée sur un ordinateur à mots de 32 bits, l’Interdata 8/32 : elle fut portée sur VAX sous le nom de 32V, et le CSRG (nommément Bill Joy et Ozalp Babaõglu) réunit ces diverses souches pour créer la 3BSD en 1979.

Le financement de la DARPA devait stimuler les deux projets : le développement de cette nouvelle version d’Unix nommée « Unix BSD », résolument tournée vers le monde des réseaux, et celui de ce que l’on connaît aujourd’hui sous le nom de TCP/IP. De ce jour, les développements respectifs de TCP/IP, de l’Internet et d’Unix furent indissociables. La souche Bell Labs continua son évolution indépendamment pour engendrer en 1983 la version System V. La suite de cette histoire se trouve ci-dessous.

La disponibilité pratiquement gratuite pour les universités, les subventions généreuses de la DARPA, c’était deux contributions de poids au succès d’Unix. Un troisième ingrédient s’y ajouta, sans lequel les deux autres n’eussent sans doute pas suffi : ce monde du réseau des centres de recherche était par ses traditions prédisposé aux échanges intellectuels, et justement la construction du réseau lui fournissait le moyen de s’y adonner de façon décuplée. Dans le monde scientifique d’antan, les contacts avec l’extérieur un peu lointain étaient l’apanage des patrons de laboratoire, qui allaient aux conférences où ils accédaient à des informations qu’ils pouvaient ensuite distiller pendant des séminaires suivis religieusement par les disciples. Avec le réseau, de simples étudiants ou de vulgaires ingénieurs pouvaient entrer en contact directement avec des collègues prestigieux. En outre, ces échanges étaient indispensables, parce qu’Unix était gratuit, mais sans maintenance, les utilisateurs étaient contraints de s’entr’aider pour faire fonctionner leurs systèmes. Je me rappelle encore en 1981 les collègues de l’IRCAM qui administraient un des premiers VAX sous Unix d’Europe, toute leur maintenance logiciel était en direct avec Berkeley. Une communauté (scientifique ? technique ? dans les marges de la science et de la technique ?) allait se créer. L’association USENIX en serait une des instances visibles, mais elle resterait largement informelle.

Il est à noter que cette communauté serait assez vite internationale : pour les managers d’AT&T qui s’étaient laissé convaincre de concéder Unix gratuitement aux chercheurs, comme pour la DARPA, le monde informatisable se limitait aux États-Unis et à leur extension canadienne, ils n’avaient pas un instant envisagé l’existence d’universités en Europe ou en Australie, et encore moins qu’elles puissent s’intéresser à Unix. Pourtant, Salus énumère les institutions inscrites à la première liste de diffusion électronique, telles que citées par le numéro 1 de UNIX NEWS de juillet 1975, et on y trouve déjà l’Université catholique de Louvain et l’Université hébraïque de Jérusalem. N’oublions pas que le premier article consacré à Unix était paru dans les Communications of the Association for Computing Machinery (CACM), l’organe de la principale société savante informatique, en juillet 1974, sous la plume de Thompson et Ritchie, seulement un an auparavant donc.

Accéder au réseau, pour les non-Américains, posait quand même un problème de taille : financer une liaison téléphonique transatlantique privée n’était, et n’est toujours pas, à la portée d’un budget de laboratoire. Ce n’est pas avant la décennie 1980 que les subventions conjuguées de la National Science Foundation (NSF) américaine et, par exemple, du ministère français de la Recherche permettront un accès convenable pour l’époque à ce qui était devenu entre-temps l’Internet. Mais dès les années 1970 des groupes Unix quasi militants apparaissaient dans quelques pays : Australie en 1975, Grande-Bretagne en 1976, Pays-Bas en 1978, France en 1981. Unix se propage sur bande magnétique, son usage est recommandé de bouche à oreille, c’est assez analogue au phénomène des radio-amateurs dans les années 1960 : tout le plaisir est de réussir à établir une communication avec le Japon ou le Kenya, peu importe après tout ce que l’on se dit, mais le sentiment d’appartenance à la même société d’initiés est d’autant plus fort que les gens sérieux et raisonnables ne comprennent pas.

Ce milieu social d’étudiants en rupture de PhD et d’ingénieurs de centres de calcul dont les responsables ont renoncé à comprendre la teneur exacte de l’activité va assurer le développement d’Unix et de l’Internet, tant les deux sont indissociables. Ce faisant ils vont engendrer une nouvelle entité technique et économique, le logiciel libre. Tout cela sans maîtrise d’ouvrage, sans cahier des charges, sans business plan, sans marketing, sans conduite du changement ni plan qualité, ni tout un tas d’autres choses soi-disant indispensables.

Avant d’aborder la question du logiciel libre, il faut s’interroger sur un phénomène quand même surprenant : nous avons dit qu’Unix était très inconfortable pour tout autre qu’un développeur utilisant ses diverses fonctions à longueur de journée. Comment expliquer alors qu’en une dizaine d’années il se soit vu reconnaître une position hégémonique dans tout le monde de la recherche ? Parce que même dans les départements d’informatique des universités et des centres de recherche, la majorité des gens ne passent pas leur temps à programmer, il s’en faut même de beaucoup, alors ne parlons pas des biologistes ou des mathématiciens.

La réponse n’est pas univoque. Mon hypothèse est que si cette population d’étudiants et d’ingénieurs, pauvre en capital social et en légitimité scientifique, a pu se hisser à cette position hégémonique, c’est que la place était à prendre. Pendant les années 1960 et 1970, on assiste aux tentatives des autorités académiques légitimes de l’informatique, dont les porte-drapeaux ont nom Dijkstra, Hoare, Knuth, ou en France Arsac, Ichbiah, Meyer, pour imposer leur discipline comme une science à part entière, égale de la Physique ou de la Mathématique. Pour ce faire ils élaborent des formalisations, des théories, des concepts souvent brillants. Peine perdue, ils échouent, malgré le succès technique et économique retentissant de l’informatique, ou peut-être même victimes de ce succès. Le public, fût-il universitaire, ne discerne pas l’existence d’une science derrière les objets informatiques qui deviennent de plus en plus ses outils de travail quotidiens. Les raisons de cet état de fait restent en grande partie à élucider, sur les traces de chercheurs en histoire de l’informatique tels en France Pierre-Éric Mounier-Kuhn, Valérie Schafer ou Camille Paloque-Berges. Ce désarroi identitaire de l’informatique universitaire snobée par ses collègues laissait le champ libre à des non-mandarins d’autant plus dépourvus de complexes qu’ils n’avaient aucune position à défendre et que le contexte économique d’Unix lui permettait de se développer dans les marges du système, sans gros budgets hormis le coup de pouce initial de la DARPA. Les financements absorbés par Unix et TCP/IP sont assez ridicules si on les compare à ceux de l’intelligence artificielle, sans doute la branche la plus dispendieuse et la plus improductive de la discipline [9], ou même à ceux du langage Ada, projet sur lequel se sont penchées toutes les bonnes fées de la DARPA et du monde académique, et qui finalement n’a jamais percé en dehors des industries militaires et aérospatiales (ce n’est déjà pas si mal, mais les espoirs étaient plus grands).

Finalement, les outsiders unixiens l’ont emporté par leur séduction juvénile et leur occupation du terrain pratique, qui leur a permis de proposer à telle ou telle discipline les outils qui lui manquaient au moment crucial : le système de composition de documents TeX pour les mathématiciens, qui seul répondait à leurs exigences typographiques, et pour les informaticiens toutes sortes de langages et surtout d’outils pour créer des langages. J’ai vu dans le monde de la biologie Unix supplanter VMS : il faut bien dire que les tarifs pratiqués par Digital Equipment et la rigidité de sa politique de produits lui ont coûté la domination d’un secteur qui n’avait pas beaucoup de raisons de lui être infidèle. Un collègue m’a confié un jour « Le principal argument en faveur d’Unix, c’est que c’est un milieu sympathique ». Cet argument m’avait paru révoltant, mais je crois qu’il avait raison, si l’on prend soin de préciser que par « sympathique » on entend « propice aux libres échanges intellectuels ».

Le schisme

Une si belle unanimité ne pouvait pas durer (et aurait été de mauvais augure). La souche BSD manifestait une certaine indépendance par rapport à l’orthodoxie AT&T. Ci-dessus nous avons laissé d’une part les versions issues de la souche Bell Labs, regroupées à partir de 1983 sous l’appellation System V, de l’autre celles issues de la souche BSD, qui en 1983 en sont à la version 4.2BSD. De cette époque on peut vraiment dater la séparation de deux écoles rivales. On pourra se reporter au livre de McKusick et ses coauteurs [10] qui donne dans ses pages 5 et 6 un arbre phylogénétique complet du genre Unix.

Quelles étaient les différences entre System V et BSD ? En fait la seule différence vraiment profonde, perceptible dans l’architecture du noyau, était le code destiné à la communication entre processus (et de ce fait au fonctionnement du réseau), organisé dans les systèmes BSD selon le modèle de socket, tandis que les System V utilisaient un autre modèle, moins versatile, baptisé STREAMS. BSD fut aussi en avance pour adopter un système de mémoire virtuelle à demande de pages et un système de fichiers amélioré (Fast File System). Autrement certaines commandes du shell étaient différentes, ainsi que le système d’impression et l’organisation des fichiers de paramètres du système (répertoire /etc) [11], etc. La différence était surtout perceptible pour les ingénieurs système et pour les développeurs de logiciels proches du noyau.

Au fur et à mesure qu’Unix se répandait, certains industriels en percevaient l’intérêt commercial et lançaient des gammes de matériels sous Unix. Bill Joy et certains de ses collègues de Berkeley créaient en 1982 Sun Microsystems dont les ordinateurs à base de processeurs Motorola 68000 mettaient en œuvre une version dérivée de BSD, SunOS. Chez DEC c’était Ultrix. HP-UX de Hewlett-Packard et AIX d’IBM étaient de sensibilité System V. Dès 1980 Microsoft avait lancé Xenix ; à ce sujet il convient d’ailleurs de noter qu’à cette époque Bill Gates considérait Unix comme le système d’exploitation de l’avenir pour les micro-ordinateurs ! AT&T lançait ses propres microprocesseurs et ses propres ordinateurs (la gamme 3B) sous Unix, qui n’eurent aucun succès : le démantèlement du monopole d’AT&T sur les télécommunications aux États-Unis au début des années 1980 lui donnait l’autorisation de commercialiser des ordinateurs, mais cela ne suffit pas à assurer le succès de cette gamme de machines...

En fait les différences idéologiques étaient plus tranchées que les différences techniques. Le monde de la recherche et de l’université, ouvert sur les réseaux, penchait pour BSD, issu du même univers, cependant que le monde de l’entreprise avait tendance à se méfier de l’Internet (ou à lui être indifférent) et à se tourner vers la version de la maison-mère, System V.

Il y eut des trahisons sanglantes et impardonnées : en 1992, Sun, porte-drapeau du monde BSD avec SunOS 4.1.3, à l’époque le meilleur Unix de l’avis de la communauté des développeurs, conclut avec AT&T des accords d’ailleurs sans lendemain aux termes desquels il passait à System V sous le nom de Solaris, honni par les puristes BSD. C’était un peu comme si le pape avait annoncé, du balcon de Castelgandolfo, son ralliement à la Réforme.

Ce qui est certain, c’est que ces luttes de clans et ce culte de la petite différence ont beaucoup nui à la diffusion d’Unix et beaucoup contribué au succès des systèmes Windows de Microsoft. La communauté des développeurs a également déployé tous ses efforts pour combattre toute tentative de développer au-dessus d’Unix et du système de fenêtrage X une couche d’interface graphique « à la Macintosh », qui aurait rendu le système utilisable par des non-professionnels. De tels systèmes sont apparus (Gnome, KDE), alors que la bataille a été gagnée (au moins provisoirement) par Windows. Mais après tout Android et iOS sont des Unix...

On peut aujourd’hui considérer que le schisme BSD-System V est résorbé dans l’œcuménisme : tous les System V ont des sockets (pour faire du TCP/IP il faut bien) et tous les BSD ont le système de communication inter-processus (IPC) STREAMS de System V, notamment. Mais l’idéologie BSD reste toujours vivace.

Aux sources du logiciel libre

Principes

Le logiciel libre mobilise beaucoup les esprits en ce début de millénaire. La définition même de la chose suscite de nombreuses controverses dues en partie au fait que le mot anglais free signifie à la fois libre et gratuit. Si l’on s’en tient à une acception restrictive, l’expression logiciel libre désigne un modèle économique et un mouvement associatif créés en 1984 par un informaticien de génie, Richard M. Stallman, auteur depuis 1975 d’un logiciel extraordinaire, Emacs. En 1983, Stallman, qui travaillait au laboratoire d’intelligence artificielle du MIT, excédé par les restrictions au développement d’Unix induites par les droits de propriété industrielle d’AT&T et de quelques autres industriels [12], fonde le projet GNU (« GNU is Not Unix ») destiné à créer un système d’exploitation libre de droits et dont le texte source serait librement et irrévocablement disponible à tout un chacun pour l’utiliser ou le modifier.

L’année suivante, Stallman crée la Free Software Foundation (FSF) pour « promouvoir le droit de l’utilisateur d’ordinateur à utiliser, étudier, copier, modifier et redistribuer les programmes d’ordinateur », c’est à dire étendre le modèle du projet GNU à d’autres logiciels. Un corollaire indissociable de ce principe est que le texte source du logiciel libre doit être accessible à l’utilisateur, ainsi que la documentation qui permet de l’utiliser. Cette clause confère à tout un chacun le moyen de modifier le logiciel ou d’en extraire tout ou partie pour une création nouvelle. Pour assurer la pérennité du principe, tout logiciel libre conforme aux idées de la FSF est soumis aux termes d’une licence, la GNU GPL (GNU General Public License), qui impose les mêmes termes à tout logiciel dérivé. Ainsi il n’est pas possible de détourner du logiciel libre pour créer du logiciel non libre sans violer la licence.

Préhistoire

Avant d’examiner plus avant les tenants et les aboutissants de ces principes et de ce modèle économique, il convient de signaler que jusqu’en 1972 le logiciel, s’il n’était pas libre au sens de la GPL, était pratiquement toujours disponible gratuitement et très souvent sous forme de texte source, et ce parce que jusqu’alors la conscience du coût et de la valeur propre du logiciel était dans les limbes. IBM, qui avait fini par accaparer 90% du marché mondial de l’informatique, distribuait systèmes d’exploitation et logiciels d’usage général à titre de « fournitures annexes » avec les ordinateurs.

Peu après l’annonce de la gamme IBM 360 en 1964, RCA annonça les ordinateurs Spectra 70 dont l’architecture était conçue afin de pouvoir accueillir le logiciel développé pour les IBM 360, y compris le système d’exploitation. Cette ambition ne se réalisa pas, notamment parce que les ingénieurs de RCA n’avaient pu se retenir d’ajouter à leur système des « améliorations » qui en détruisaient la compatibilité, mais IBM avait perçu la menace et commença à élaborer une parade juridique qui consistait à séparer la facturation du logiciel de celle du matériel : ce fut la politique d’unbundling (dégroupage), annoncée en 1969, mais dont l’application à ce moment fut entamée assez mollement.

Au début des années 1970, quelques industriels (notamment Telex, Memorex et Calcomp) commencèrent à vouloir profiter de la manne et pour cela vendre des matériels compatibles avec ceux d’IBM (disques, dérouleurs de bandes, imprimantes, et plus tard unités centrales et mémoire), c’est à dire tels que les clients pourraient les acheter et les utiliser en lieu et place des matériels IBM originaux. IBM riposta à ce qu’il considérait comme une concurrence déloyale en cessant de divulguer le code source des parties de système d’exploitation qui permettaient la conception et le fonctionnement des systèmes concurrents. Il en résulta des procès acharnés, et en 1972 un arrêt de la Cour suprême des États-Unis, au nom de la législation anti-trust créée pour limiter l’emprise de Rockfeller, statua dans le procès Telex-IBM et imposa à IBM de facturer à part logiciel et matériel. Ceci précipita l’entrée en vigueur de la politique d’unbundling. Les observateurs de l’époque déclarèrent que cela n’aurait aucun effet, mais deux industries étaient nées : celle du matériel compatible IBM, qui serait florissante une vingtaine d’années, et celle du logiciel, dont Microsoft est le plus beau fleuron.

Précurseurs

Si l’Église chrétienne a reconnu à Jérémie, Isaïe, Daniel et Ézéchiel la qualité de précurseurs de la vraie foi et de la venue du Sauveur, Richard Stallman est plus intransigeant, mais n’en a pas moins lui aussi des précurseurs. Ils se situent dans les limbes, à l’époque où ARPANET engendrait TCP/IP, qui était bien évidemment du logiciel, et qui était distribué aux membres du réseau, c’est à dire, nous l’avons vu, potentiellement à toutes les universités et tous les centres de recherche. Comme tout cela se passait à Berkeley, il en résulta que le système de prédilection de TCP/IP et, partant, de l’Internet fut Unix, et que traditionnellement les principaux logiciels de réseau sous Unix furent distribués gratuitement, du moins aux centres de recherche, sous les termes d’une licence dite « BSD » qui garantissait les droits de propriété intellectuelle des « Régents de l’Université de Californie ». Les éléments de base du protocole TCP/IP proprement dit font partie du noyau Unix BSD, d’où ils ont assez vite été adaptés aux noyaux des autres Unix, cependant que les logiciels d’application qui en permettaient l’usage, tels que Sendmail pour envoyer du courrier électronique, Ftp pour transférer des fichiers, Telnet pour se connecter à un système distant, etc., étaient distribués indépendamment. Plus tard Bind pour la gestion du service de noms de domaines, INN pour le service de News et beaucoup d’autres logiciels s’ajouteront à cette liste, toujours gratuitement.

Par ailleurs, Unix devenait populaire dans le monde de la recherche et les logiciels développés par des scientifiques étaient aussi rendus disponibles dans des conditions analogues : TeX pour la composition typographique, Blast pour la comparaison de séquences biologiques, Phylip pour l’analyse phylogénétique, pour ne citer que trois exemples parmi une foule, sont disponibles selon les termes de licences assez variées (ou d’absence de licence...), mais toujours sans versement de redevances. Bref, le monde de la recherche fait et utilise du logiciel libre depuis longtemps sans forcément le dire ni même en avoir conscience.

Économie du logiciel

L’économie du logiciel, étudiée notamment avec brio par Michel Volle dans son livre e-conomie [13], exprime un paradoxe dont la conscience ne s’est manifestée que récemment. Citons Michel Volle dans la présentation de son livre : « Le “système technique contemporain” est fondé sur la synergie entre micro-électronique, informatique et automatisation. On peut styliser sa fonction de production en supposant qu’elle est “à coûts fixes” : le coût de production, indépendant du volume produit, est payé dès l’investissement initial. Développons cette hypothèse : les usines étant des automates, l’emploi réside dans la conception et la distribution. La distribution des revenus n’est pas reliée au salariat. Les entreprises différencient leur production pour construire des niches de monopole. Elles organisent leurs processus autour du système d’information. Le commerce passe par des médiations empruntant la communication électronique.

L’investissement est risqué, la concurrence est mondiale et violente. On retrouve dans cette présentation stylisée des aspects tendanciels de notre économie. Elle éclaire la description des secteurs de l’informatique, de l’audiovisuel, des réseaux (télécommunications, transport aérien, etc.), du commerce, ainsi que les aspects stratégiques et tactiques des jeux de concurrence dans ces secteurs et dans ceux qui les utilisent. On voit alors que cette économie hautement efficace pourrait aller au désastre si elle était traitée sur le mode du “laissez faire”, sans considérer les exigences de l’éthique et de la cohésion sociale. » (texte disponible sur le site http://www.volle.com selon les termes de la GNU Free Documentation License).

Dans le cas du logiciel ces traits sont particulièrement marqués : la création d’un logiciel important tel qu’un système d’exploitation [14] est une tâche colossale qui peut mobiliser des centaines de personnes pendant une décennie, le coût marginal du produit final livré dans un grand magasin est pratiquement nul, le prix payé par le client est essentiellement celui de la boîte en carton, des frais de transport et de gestion et de l’effort commercial. Il en résulte, dans l’industrie du logiciel, une tendance irréversible au monopole : dans une industrie à coût marginal de production nul, dès que vous vendez plus que les autres, vous êtes très vite beaucoup plus riche, avec les conséquences qui en découlent. Dès lors qu’un marché prend forme et s’organise, il émerge un fournisseur unique : Microsoft pour les systèmes des micro-ordinateurs et la bureautique, Oracle pour les bases de données, SAP pour la gestion financière et comptable, SAS pour l’analyse statistique. Quelques concurrents subsistent, en permanence au bord de la faillite ou cachés dans des « niches » de marché [15].

Manuel Serrano en a tiré les conséquences dans sa thèse d’habilitation [16] en plaidant pour le « logiciel moyen » : les grands logiciels ne seraient devenus encombrants, dans bien des cas, que par la prolifération incontrôlée d’un processus de développement devenu bureaucratique. Une réflexion plus intense d’un groupe plus petit et plus conscient des objectifs à atteindre permettrait d’obtenir un logiciel plus petit et de meilleure qualité.

Dans cette situation désespérante, l’espoir de diversité, dans un contexte industriel classique, ne peut venir que de l’apparition de nouveaux segments de marchés, desservis par de nouvelles technologies, rôle joué dans le passé par les mini-ordinateurs, puis les micro-ordinateurs à base de microprocesseur, innovations technologiques qui réduisaient de plusieurs ordres de grandeur les coûts de production.

Modèle du logiciel libre

Le logiciel libre, face à cette situation, représente un potentiel très dynamique, parce qu’il obéit à un modèle économique tout autre. Microsoft ne peut utiliser contre lui aucune des armes classiques de la concurrence industrielle, telles que la guerre des prix, la publicité, les fournitures associées, l’effet de gamme, etc., parce que le logiciel libre n’est sur aucun de ces terrains.

Les caractères économiques du logiciel libre ont été étudiés, entre autres, par Marie Coris dans son travail de thèse de doctorat à l’Université Montesquieu de Bordeaux IV (voir sa communication au congrès JRES 2001 Impact des logiciels libres sur l’industrie du logiciel : vers un nouveau modèle productif ?). Elle énumère d’abord les caractères du logiciel en général :

- un bien d’information, aspect amplement développé ici dont découle l’importance des économies d’échelle ;
- un bien en réseau : son utilité croît en raison du nombre de ses utilisateurs ;
- un bien à cheval entre public et privé :

  • le coût de production pratiquement engagé en totalité dès le premier exemplaire,
  • l’usage non destructif (il peut être utilisé par un nombre infini d’utilisateurs),
  • l’usage non exclusif (il est difficile d’empêcher quelqu’un d’autre de l’utiliser) sont des caractéristiques d’un bien public,
  • le recours à la protection du droit d’auteur ou du brevet permet d’annuler les aspects « publics », par exemple en limitant la reproductibilité, et de faire du logiciel un bien privé.

L’alternative se situe entre le logiciel comme bien privé, idée des entreprises telles que Microsoft, Oracle, etc., et le logiciel comme bien public, idée du logiciel libre.

Volle, Coris et d’autres ont montré que le marché d’un bien d’information ne peut prendre que deux formes :

- si les instances de ce bien sont suffisamment différenciées, plusieurs fournisseurs peuvent coexister dans des niches du marché ;
- dès qu’un fournisseur réussit à prendre sur ses concurrents un avantage significatif en déniant leur différence, il obtient une situation de monopole du fait des économies d’échelle considérables procurées par le volume des ventes.

Le logiciel libre échappe à cette alternative parce qu’il se situe hors de la logique marchande, et que la rétribution de ses auteurs relève des domaines symbolique et moral. Michel Volle a fait remarquer qu’un auteur de logiciel libre aurait aussi un accès facilité au capital-risque le jour où il voudrait créer une entreprise du fait de la reconnaissance acquise dans le domaine non marchand.

La GNU GPL définit parfaitement les « quatre libertés » caractéristiques du logiciel libre : liberté d’utilisation, liberté de copie, liberté de modification et liberté de redistribution. Elle autorise donc la modification et la redistribution, mais en imposant que le logiciel reste sous GPL, et ce également dans le cas de l’incorporation d’un logiciel libre à un nouveau logiciel : le caractère « libre » est héréditaire et contagieux. Dans ce dispositif, le statut du code source détermine la nature publique du bien, plus qu’il ne sert vraiment à la maintenance par l’utilisateur. La publicité du code interdit l’appropriation privée. Mais plonger dans les sources pour y introduire des modifications est une entreprise à n’envisager qu’avec circonspection ; cela risque de coûter fort cher.

Reste à se poser une question : le logiciel libre, comme le logiciel non libre, est écrit par des hommes et des femmes qui y consacrent tout ou partie de leur vie professionnelle et qui ne vivent pas de l’air du temps. Qui finance la production de logiciels libres, et comment, puisque, quoique ses apôtres s’en défendent, sa caractéristique principale est bien qu’il est possible de l’utiliser sans bourse délier ?

Bertrand Meyer, dans un article assez polémique de critique du libre [17], dresse une nomenclature des sources de financement possibles, qui énerve les adeptes mais à laquelle il est difficile de dénier toute véracité :

  1. une donation : le développeur vit de sa fortune personnelle ou développe pendant ses nuits et ses jours de congé ;
  2. le financement public : le logiciel a été créé par un centre de recherche, une université ou une autre entreprise publique ;
  3. le financement privé : une entreprise décide de distribuer un logiciel développé à ses frais selon le modèle libre ;
  4. la subvention (publique ou privée) : le développeur crée un logiciel en utilisant son temps de travail et les ressources de son employeur, public ou privé, sans que celui-ci lui ait confié cette tâche.

Le cas 4 est celui qui provoque parfois quelque agacement, et on ne peut exclure qu’il soit assez répandu. Cela dit, un examen de ce cas informé par les tendances les plus récentes de la sociologie du travail montre que cette situation n’est pas forcément scandaleuse, et que l’initiative prise par le développeur peut comporter des avantages pour son employeur même s’il n’en avait pas initialement conscience. La création d’Unix en est le plus bel exemple, et si l’on regarde en arrière, on peut se dire qu’AT&T en aurait sans doute tiré encore plus d’avantages en en faisant un logiciel libre ; Unix ne lui a pas vraiment rapporté beaucoup d’argent, et sa facturation aux entreprises a considérablement restreint sa diffusion. Le succès actuel de Linux apporte ex post des arguments à l’appui de cette hypothèse. Toutefois, Bertrand Meyer a raison d’écrire que sans le couple Intel-Microsoft il n’y aurait jamais eu de PC à 600 Euros, et partant jamais de succès pour Linux.

Un exemple typique et très instructif du cas 3 est celui du logiciel Ghostscript, produit par la société Aladdin Enterprises, qui est un interpréteur du langage PostScript. PostScript est un langage de description de pages utilisé comme format de sortie par de nombreux logiciels et comme format d’entrée par beaucoup d’imprimantes. Ghostscript est utile pour afficher à l’écran le contenu d’un fichier PostScript, et pour l’imprimer sur une imprimante dépourvue d’interpréteur PostScript incorporé, ce qui est le cas notamment de beaucoup de petites imprimantes à jet d’encre. Ce logiciel a deux groupes bien distincts d’utilisateurs : des millions de propriétaires de petites imprimantes bon marché qui veulent afficher et imprimer du PostScript, et une dizaine d’industriels fabricants d’imprimantes, qui incorporent Ghostscript par paquets de cent mille exemplaires à leurs productions.

Dans sa grande sagesse, la société Aladdin Enterprises a décidé de ne pas se lancer dans la commercialisation à grande échelle d’un logiciel qui vaudrait quelques dizaines d’Euros, et de le distribuer aux particuliers sous les termes d’une licence dite Aladdin Ghostscript Public License, qui protégeait la propriété intellectuelle d’Aladdin et permettait un usage gratuit. Depuis 2000, Ghostscript est un logiciel libre disponible sous les termes de la GNU GPL. Aladdin Enterprises tire plutôt ses revenus de la clientèle des fabricants d’imprimantes.

Le cas 2 est sans doute le plus fréquent. La justification initiale de ce modèle me semble remonter au principe constant de l’administration américaine : ce qui a été payé une fois par le contribuable ne doit pas l’être une seconde fois. Les logiciels dont le développement a été financé par des contrats de recherche de la DARPA doivent être mis gratuitement à la disposition du public, au même titre que les photos de l’espace prises par la NASA.

Ce principe ne semble pas scandaleux : ce qui a été financé par l’argent public [18] (au sens large) revient au public. Les résultats de la recherche publique sont disponibles publiquement. Il s’agit d’un système de redistribution : tous les contribuables financent les logiciels produits de cette façon, et les bénéficiaires en sont les utilisateurs. Il est légitime de s’interroger sur l’équité de ce processus de répartition, mais il en est sans doute de pires.

Qui pourrait s’estimer lésé ? Essentiellement les entreprises dont la prospérité repose sur le logiciel commercial, et qui pourraient arguer d’une concurrence déloyale, puisque le plus souvent alimentée par des financements publics. Curieusement, on observe peu de protestations de cette nature, et encore moins de procès.

Il convient aussi de remarquer que le modèle du logiciel libre, s’il n’apporte apparemment que des avantages à l’utilisateur, peut comporter des inconvénients pour l’auteur, qui s’interdit en fait tout contrôle exclusif sur la divulgation de son travail. Certes, les clauses de la GNU GPL permettent la commercialisation de logiciel libre, et il est parfaitement possible de recourir au système de la double licence, par exemple GNU GPL pour le monde académique et licence commerciale pour le monde industriel. Mais il est clair qu’un logiciel novateur dont l’auteur peut espérer des revenus importants sera mal protégé des contrefaçons si son code source est divulgué. En fait, dans le monde académique la pression idéologique pour la GNU GPL est très forte, et les auteurs de logiciels qui souhaitent vivre des fruits de leur activité de développeur plutôt que d’un emploi universitaire (ou qui, faute d’un tel emploi, n’ont pas le choix) sont assez marginalisés par ce système. Le caractère contagieux et contraignant de la GNU GPL est très pénalisant pour l’auteur qui ne souhaiterait pas vivre dans l’abnégation (c’est le terme exact : le logiciel qu’il a écrit ne lui appartient plus), ou qui, faute d’avoir obtenu un poste dans un organisme public, ne le pourrait pas. Il y a des exemples d’auteurs qui pour avoir refusé les servitudes de la GNU GPL se sont vu mettre au ban de la communauté, leurs travaux passés sous silence et leurs logiciels exclus des serveurs publics.

En fait, la réalité usuelle du développeur de logiciel libre est qu’il gagne sa vie autrement, et que la rétribution qu’il attend pour son oeuvre est la reconnaissance de ses pairs. Quiconque bénéficie du logiciel libre ressent le désir d’y contribuer et ainsi d’adhérer à une communauté perçue comme éthique. Il est souhaitable que la GNU GPL ne reste pas hégémonique et que d’autres licences aux termes moins idéologiques et plus équilibrés apparaissent dans le monde du logiciel libre.

Une autre façon de faire du logiciel

Le modèle du logiciel libre n’est pas sans influence sur la nature même du logiciel produit. En effet, dans ce contexte, un auteur peut facilement utiliser d’autres logiciels s’ils sont libres, que ce soit pour recourir à des bibliothèques de fonctions générales ou pour s’inspirer d’un logiciel aux fonctions analogues mais dans un environnement différent.

Des systèmes de développement coopératif se mettent en place par le réseau, qui seraient impensables pour du logiciel non-libre : les programmes sous forme source sont accessibles sur un site public, et chacun peut soumettre sa contribution. L’archétype de ce mode de développement est celui du noyau Linux proprement dit, coordonné par Linus Torvalds personnellement.

Pour qu’un tel procédé donne des résultats utilisables, il faut que le logiciel présente une architecture qui s’y prête, notamment une grande modularité, afin que chaque contributeur puisse travailler relativement indépendamment sur telle ou telle partie. Par exemple, dans le noyau Linux, tout ce qui permet le fonctionnement de machines multi-processeurs et la préemption des processus en mode noyau demande une synchronisation beaucoup plus fine des fils (threads) d’exécution : les adaptations nécessaires ont été réalisées par Robert Love, ce qui a été possible parce qu’il n’était pas trop difficile d’isoler les parties du code concernées. À l’inverse, lorsque Netscape a voulu donner un statut Open Source à une partie du code de son navigateur connue sous le nom Mozilla, l’opération a été rendue difficile parce que le code initial n’avait pas été réalisé selon un plan suffisamment modulaire.

Finalement, la réutilisation de composants logiciels, dont plusieurs industriels parlent beaucoup depuis des années sans grand résultat, sera sans doute réalisée plutôt par les adeptes de l’Open Source. En effet, l’achat d’un tel composant est un investissement problématique, tandis que le récupérer sur le réseau, l’essayer, le jeter s’il ne convient pas, l’adopter s’il semble prometteur, c’est la démarche quotidienne du développeur libre. On pourra lire à ce sujet l’article de Josh Lerner et Jean Tirole, The Simple Economics of Open Source.

L’analyse détaillée des conséquences d’un tel mode de construction de logiciel reste à faire, mais en tout cas il ne fait aucun doute que le résultat sera très différent. Rappelons les étapes classiques de la construction d’un système informatique pour un client selon le mode projet :

- expression des besoins ;
- cadrage, opportunité, faisabilité ;
- spécification ;
- réalisation ;
- recette...

Oublions tout cela dans le monde du libre. Le logiciel commence à prendre forme autour d’un noyau, noyau de code et noyau humain, généralement une seule personne ou un tout petit groupe. L’impulsion initiale procède le plus souvent du désir personnel des auteurs de disposer du logiciel en question, soit qu’il n’existe pas, soit que les logiciels existants ne leur conviennent pas, que ce soit à cause de leur prix ou de leur environnement d’exécution. Puis d’autres contributions viennent s’ajouter, presque par accrétion. Un coordonnateur émerge, souvent l’auteur initial, il assure la cohérence de l’ensemble ; on l’appelle dictateur bienveillant. Quand des divergences de vue surgissent, il peut y avoir une scission : ainsi deux versions sont disponibles pour Emacs, Gnu Emacs et Xemacs, toutes deux libres.

Le catalogue du logiciel libre est assez vaste. Tout d’abord le logiciel libre avant la lettre :

- TeX, LATEX, respectivement de Donald Knuth et de Leslie Lamport, avec lesquels est réalisé le présent document ;
- les logiciels réseau :

  • Sendmail, pour envoyer du courrier ;
  • Bind, pour résoudre les noms de domaine,
  • beaucoup d’autres, ce sont eux qui « font marcher » l’Internet ;

- X Window System ;
- des quantités de programmes scientifiques : l’essentiel de la biologie moléculaire se fait avec du logiciel libre.

Et pour le logiciel libre canonique, de stricte obédience :

- Gnu Emacs, un éditeur, et son rival Xemacs, GCC, un compilateur C, The Gimp, un concurrent libre de Photoshop, GNAT, un environnement de programmation ADA, GNOME, un environnement graphique pour Linux, gnumeric, un tableur ;
- Linux, FreeBSD, OpenBSD, NetBSD, des systèmes d’exploitation Unix ;
- PostgreSQL et MySQL, des systèmes de gestion de bases de données relationnelles ;
- Apache, un serveur WWW.

Chacun dans son domaine, ces logiciels sont de toute première qualité, et il n’y a pas à hésiter : ce sont eux qu’il faut utiliser ! Il manque bien sûr des choses, comme un logiciel OCR comparable à Omnipage de Caere...

Linux

Linux est indubitablement un système emblématique du logiciel libre. S’il y a d’autres systèmes d’exploitation libres, y compris dans la famille Unix, et si les logiciels libres ne sont pas tous destinés à Unix, l’association avec Linux est inévitable.

Le début de ce chapitre montre la filiation entre le mouvement autour d’Unix et le développement du logiciel libre, mais le paradoxe était qu’Unix lui-même n’était pas libre, AT&T en détenait les droits. Pourtant la communauté Unix était très attachée à l’idée de l’accès au code source du système, puisque le développement de nouveaux logiciels, certains très proches du système, ne pouvait être entrepris qu’avec un tel accès. En outre les droits d’AT&T semblaient contestables, parce qu’Unix avait recueilli beaucoup de contributions extérieures souvent non rémunérées. Plusieurs moyens ont été envisagés pour briser ou contourner ce paradoxe.

Le premier moyen consistait à obtenir d’AT&T une licence source. Si pour des chercheurs ou des universitaires c’était théoriquement possible, pratiquement des obstacles surgissaient. Si l’on était loin des États-Unis et que l’on n’avait pas de relations dans ce milieu, nouer les contacts nécessaires pouvait demander des mois. Une fois la licence source obtenue, il fallait obtenir du fournisseur de son ordinateur les sources de la version de système précise installée sur la machine, ce à quoi il ne se prêtait pas toujours avec bonne volonté. Bref, le seul moyen de pouvoir accéder réellement aux sources d’un système opérationnel était d’appartenir à un des groupes en vue du monde Unix. Rappelons qu’au début des années 1980 une machine capable de « tourner » Unix et le réseau coûtait au minimum l’équivalent de 100 000 Euros et que l’Internet n’atteignait pas l’Europe (il fallait se contenter du réseau UUCP, plus fruste).

Ces difficultés étaient particulièrement ressenties par les enseignants qui voulaient initier leurs étudiants à Unix, ce qui était bien sûr impossible sans accès au code source. Ils ont très tôt imaginé des moyens de contourner les droits d’AT&T. Le précurseur quasi légendaire de cette démarche fut un professeur australien, John Lions, dont le livre de 1977 A Commentary on the Unix System, V6 comportait le code du noyau. AT&T n’avait autorisé qu’un tirage limité, mais comme en URSS du temps de Brejnev apparut une véritable activité clandestine de Samizdat. Ce livre fut réédité en 1996, et il mérite toujours d’être lu. John Lions aura vu la publication légale de son œuvre avant sa mort en décembre 1998.

Andrew Tanenbaum, professeur à l’Université Libre d’Amsterdam (Vrije Universiteit Amsterdam) (il vient en 2014 de prendre sa retraite), rencontra le même problème. Pour les besoins de son enseignement il créa de toutes pièces un système miniature inspiré d’Unix, adapté aux micro-ordinateurs à processeur Intel et baptisé Minix. Le cours donna naissance à un livre dont les premières versions (1987) comportaient en annexe le code de Minix. Il était également possible d’acheter les disquettes pour installer Minix sur son ordinateur, mais ce n’était ni très bon marché ni très commode. C’est en partant de Minix que Linus Torvalds créa Linux.

Pendant ce temps le groupe BSD travaillait à expurger son code de toute instruction rédigée par AT&T, de façon à l’affranchir de tout droit restrictif. Le résultat fut 4.3BSD Net1 en 1989, puis 4.3BSD Net2 en 1991. L’objectif était de produire 4.4BSD-Lite en 1993, mais USL (Unix System Laboratories, une branche d’AT&T qui était à l’époque propriétaire des droits Unix) attaqua ce projet en justice, ce qui en différa la réalisation d’un an. Du groupe BSD émanèrent aussi un système Unix pour processeurs Intel en 1992, 386BSD, et une société destinée à le commercialiser, BSD Inc. Mais tous ces efforts furent retardés par des questions juridiques. Ils débouchèrent, sensiblement plus tard, sur les Unix libres FreeBSD, OpenBSD et NetBSD.

Rappelons que depuis 1983 le projet GNU visait lui aussi à produire un système similaire à Unix mais libre de droits et disponible sous forme source. Au début des années 1990 ce groupe avait réalisé un certain nombre de logiciels libres utilisables sur les divers Unix du marché, notamment des utilitaires, mais toujours pas de noyau. En fait ce n’est qu’en 2000 que le système Hurd destiné à remplacer le noyau Unix et basé sur le micro-noyau Mach créé à l’Université Carnegie-Mellon commença à ressembler à un vrai système.

Le salut allait venir d’ailleurs. En 1991 un étudiant de l’Université d’Helsinki, Linus Torvalds, achète un ordinateur doté d’un processeur Intel 386 et cherche un moyen d’explorer son fonctionnement. Minix lui semble une voie prometteuse, dans laquelle il s’engage, mais il y rencontre quelques obstacles et commence à réécrire certaines parties du noyau. En août 1991 Linux est né, en septembre la version 0.01 est publiée sur le réseau. Elle ne peut fonctionner que sous Minix. La version 0.02 publiée le 5 octobre 1991 permet l’usage du shell bash et du compilateur C gcc, deux logiciels GNU. La première version réputée stable sera la 1.0 de mars 1994.

Pour résumer la nature de Linux, nous pourrions dire que c’est un noyau, issu à l’origine de celui de Minix, et dont le développement est toujours assuré sous la supervision personnelle de Linus Torvalds, entouré des outils GNU, le tout sous licence GPL. Ce que Linus Torvalds a fait, d’autres auraient peut-être pu le faire eux-mêmes, et ils regrettent sans doute d’en avoir laissé l’occasion, à un Européen de surcroît, mais l’histoire est ainsi.

Linux est au départ plutôt un Unix System V, mais doté de toutes les extensions BSD souhaitables, ainsi que des dispositifs nécessaires à la conformité POSIX [19]. Sa principale originalité tient sans doute à son processus de développement : alors que tous les autres systèmes d’exploitation cités dans ce chapitre ont été développés par des équipes organisées, le développement du noyau Linux s’est fait depuis le début par « appel au peuple » sur l’Internet. Quiconque s’en sent la vocation peut participer aux forums, lire le code et proposer ses modifications (appelées patches). Elles seront examinées par la communauté, et après ce débat Linus Torvalds tranchera et décidera de l’incorporation éventuelle au noyau officiel. Il est difficile d’estimer les effectifs d’une telle communauté informelle, mais le nombre de contributeurs actifs au noyau Linux était en 2003 sans doute inférieur à 200 (nombre de développeurs recensés pour la version 2.0. Plus récemment : 1 326 contributeurs à la version 3.2 de janvier 2013). Le succès de Linux résulte sans doute en partie de facteurs impondérables : pourquoi l’appel initial de Torvalds a-t-il séduit d’emblée ? La réponse à cette question est sûrement complexe, mais en tout cas le succès est incontestable. Ce qui est sûr, c’est que l’appel à contribution d’août 1991 répondait à une attente et à une frustration largement répandues.

Comme nous pouvons nous y attendre, Linux connaît aussi la division en chapelles. Ici elles s’appellent « distributions ». Au début, la diffusion des éléments de Linux s’effectuait par le réseau, mais assez vite cela devint volumineux et compliqué. Il fallait transférer le noyau lui-même (en code source), ainsi que les logiciels (surtout GNU) sans lequel il aurait été inutilisable, en veillant à la synchronisation des versions compatibles. Au bout de quelques années apparurent des éditeurs qui distribuaient pour un prix modique des CD-ROMs comportant tout ce qu’il fallait pour démarrer.

Par exemple en 1996 on pouvait acheter pour l’équivalent de moins de 30 Euros (somme compatible avec la notion de logiciel libre, puisqu’elle ne rémunérait que la copie, l’emballage et la distribution, pas le logiciel lui-même) le jeu de CD Infomagic, qui comportait notamment la distribution Slackware. La Slackware était une distribution assez ascétique : les différents logiciels étaient simplement fournis sous forme d’archives compressées qu’il fallait compiler, en bénéficiant quand même du logiciel de gestion de configuration make.

D’autres distributions proposent des paquetages : il s’agit de programmes tout compilés. Rassurez-vous, les principes du logiciel libre sont respectés, le paquetage source est fourni à côté. Les distributions RedHat et Debian ont chacune leur format de paquetage, leur logiciel d’installation qui en outre contrôle les dépendances entre paquetages, l’installation et la mise à jour par le réseau, etc. Il faut bien reconnaître que c’est assez pratique. Mais pour le débutant qui se lance dans l’installation de Linux il est néanmoins conseillé d’avoir à proximité un ami qui est déjà passé par là !

(Avec l’aimable autorisation des Éditions Vuibert pour mon livre Systèmes d’exploitation des ordinateurs : histoire, fonctionnement, enjeux (disponible en ligne librement, suivre le lien) dont ce texte est adapté.)

Notes :

[1Adjectif formé sur le nom de COBOL, langage de programmation peu prisé malgré de réelles qualités parce que destiné aux informaticiens de gestion, au bas de la hiérarchie implicite de la profession. Ses dignes successeurs sont SQL et Perl.

[2Porter un logiciel d’un ordinateur à un autre ou d’un système à un autre signifie l’adapter aux caractéristiques techniques particulières de ce nouveau contexte. L’opération s’appelle un portage. Un logiciel pour le portage duquel le travail à faire est nul ou négligeable est dit portable ; cette qualité, très recherchée, s’appelle portabilité. Unix est le système d’exploitation le plus portable parce qu’il est écrit pour l’essentiel dans un langage évolué (C) plutôt que dans l’assembleur d’un processeur particulier, et grâce à la bonne abstraction de ses primitives, grâce aussi à la simplicité et à l’élégance de son architecture générale.

[3Notamment Spanning Tree Protocol grâce auquel votre réseau Ethernet fonctionne.

[4On sait qu’Alfred Nobel, lorsqu’il créa ses Prix, ne voulut pas en attribuer aux Mathématiques. La légende dit que cette exclusion serait due à une trop grande sympathie qu’aurait éprouvée Madame Nobel pour un certain mathématicien. Pour se consoler les mathématiciens créèrent la médaille Fields, décernée tous les quatre ans. Les informaticiens ont encore plus besoin de consolation, puisqu’ils n’ont même pas réussi à séduire Madame Nobel. Ils ont créé le Turing Award, qui a notamment été décerné, parmi nos personnages, à Maurice V. Wilkes, E.W. Dijkstra, Donald E. Knuth, C. Antony R. Hoare, Frederick P. Brooks, Fernando Corbató, Ken Thompson, Dennis M. Ritchie et Leslie Lamport, sans oublier Joseph Sifakis, unique Français de ce palmarès. Voir le site de l’ACM pour plus de détails.

[5Cette prétention flatte la paresse naturelle de l’utilisateur, mais elle est fallacieuse. Il est certes possible, avec tel logiciel de traitement de texte dont le nom signifie « mot » dans une langue germanique et insulaire, de créer facilement un document laid et peu lisible, mais dès lors que l’on veut un résultat présentable il faut se plonger dans la documentation et découvrir que ce logiciel est complexe, tout simplement parce que la typographie est complexe.

[6C’est avec Unix que « développeur » a supplanté « programmeur ». Ces deux termes ont rigoureusement le même sens, « personne dont le métier est la création de programmes informatiques », mais « programmeur » avait été victime d’une dévalorisation injuste. Les premiers managers de l’informatique ont pensé y reproduire un schéma qui était déjà en déclin dans l’industrie : l’ingénieur conçoit, l’ouvrier fait. En informatique l’analyste concevrait ce que le programmeur ferait. Erreur. L’ingénieur disposait, pour transmettre à l’ouvrier la description de ce qu’il devait faire, d’un outil précis et rigoureux, le dessin industriel. Rien de tel en informatique, malgré des efforts qui durent encore pour créer des systèmes de spécification infaillibles dont UML est le dernier avatar. Et à cela il y a des raisons : un ordinateur doté de son système d’exploitation et de ses langages de programmation n’est pas seulement infiniment plus versatile et plus souple qu’un étau-limeur ou qu’une fraiseuse, il est surtout d’une toute autre nature. Il traite de l’information, et comme nous l’avons vu l’information n’est que parce qu’imprévisible. Et l’information qui décrit un programme à réaliser est de la méta-information, puisque le programme est lui-même de l’information. De ce fait la vraie difficulté réside bien toujours dans l’écriture du programme, qui est un exercice incroyablement délicat et laborieux. E.W. Dijkstra se définissait lui-même comme programmeur. Mais rien n’y fait, le programmeur sent le cambouis et la sueur, alors que son remplaçant le développeur arbore (jusqu’à la retraite et au-delà) l’uniforme seyant et l’éthos décontracté des étudiants californiens.

[7Jean-Louis Nebut. UNIX pour l’utilisateur. Éditions Technip, Paris, 1990.
Face à l’océan des livres-mode d’emploi inodores et sans saveur, celui-ci introduit des concepts (ceux de la programmation) dans un univers d’où ils sont souvent bannis. Unix y apparaît sous un jour nouveau, doté d’une cohérence non limitée à sa structure interne, et du coup compréhensible même à qui n’en a pas lu le noyau. L’exercice (organiser cet apparent fouillis) était difficile.

[8En fait à cette époque AT&T possédait le monopole des télécommunications aux États-Unis, en contrepartie de quoi il lui était interdit d’avoir une véritable action commerciale dans d’autres domaines comme l’informatique.

[9Pour être juste, il faut dire que si l’intelligence artificielle au sens fort du terme a été une telle source de déceptions depuis l’article fondateur de McCulloch et Pitts en 1943 qu’il est difficile de résister à la tentation de parler d’imposture, ses financements somptueux ont permis la réalisation de produits dérivés du plus grand intérêt, comme les langages LISP, les interfaces graphiques à fenêtres, le système d’édition de texte Emacs et bien d’autres, souvent d’ailleurs des logiciels libres.

[10Marhall Kirk McKusick, Keith Bostic, Michael J. Karels, John S. Quarterman. The Design and Implementation of the 4.4 BSD Operating System. Addison-Wesley, Reading, Massachusetts, 1996. Le célèbre Daemon Book que tout utilisateur de Unix devrait lire.

[11Cette question d’organisation d’une arborescence de fichiers n’est pas négligeable, son respect des conventions et sa stabilité importent pour la portabilité des logiciels. C’est par défaut d’attention à ce point que MacOS X est un mauvais environnement de développement, l’arborescence change tout le temps.

[12En fait l’ire fondatrice qui décida de la vocation prophétique du Maître était dirigée contre Xerox et son pilote d’imprimante... Felix culpa. Le lecteur remarquera que malgré leurs péchés AT&T et Xerox jouent un rôle capital dans l’histoire de l’informatique en y apportant plus d’innovations que bien des industriels du secteur.

[13Michel Volle. e-conomie. Economica, Paris, 2000.
Une analyse économique informée et pénétrante des nouvelles technologies par un des maîtres de l’économétrie et de la statistique.

[14Un système d’exploitation commercial moderne tel que Windows 2000 comporte quelque 30 millions de lignes de programme. Estimer le nombre de lignes de Linux est assez difficile parce qu’il faudrait ajouter à la taille du noyau celle des multiples utilitaires et logiciels généraux qui le complètent. Un décompte sur le répertoire des sources du noyau, qui comporte les pilotes de périphériques et les modules, donnait pour la version 2.4.12 (octobre 2001, architecture Intel 386) utilisée pour rédiger le présent ouvrage 2 333 129 lignes (aujourd’hui, en 2014, c’est plutôt 15 millions de ligne, cf. un article plus détaillé), auxquelles il faudrait en ajouter presqu’autant pour le système de fenêtrage X, sans oublier les bibliothèques de commandes et de fonctions diverses, mais dont il conviendrait de retirer quelques dizaines de milliers de lignes pour les parties redondantes liées par exemple à des architectures différentes (Intel x86, ARM, PowerPC, MIPS, etc.). Le rendement moyen d’un développeur est hautement sujet à controverses, mais si l’on compte les temps consacrés à la rédaction de la documentation et à l’acquisition de connaissances, 50 lignes par jour de travail semble un maximum, soit 10 000 par an et par personne. Mais comme le signale Brooks dans son livre Le mythe de l’homme-mois une telle valeur est éminemment trompeuse. La création d’un logiciel est une tâche très complexe, et la division du travail la complique encore en multipliant les fonctions de direction, de coordination et d’échanges d’information, qui peuvent aboutir à ralentir le processus plus qu’à l’accélérer.

[15Frederick P. Brooks, Jr. The Mythical Man-Month. Addison-Wesley, Reading, Massachusetts, 1975, Vuibert pour l’excellente traduction française d’une nouvelle édition augmentée. S’il faut neuf mois à une femme pour faire un enfant, deux femmes ne peuvent pas y arriver en quatre mois et demie. Au-delà du rappel au bon sens dont bien des managers ont vraiment besoin, Brooks, qui fut le concepteur principal de l’OS/360, jette un regard (auto-)critique sur la plus ambitieuse entreprise d’ingénierie des cinquante dernières années : l’écriture des systèmes d’exploitation.

[16Manuel Serrano. « Vers une programmation fonctionnelle praticable ». Habilitation à diriger des recherches, Université de Nice, 2000. Une réflexion pratique non dépourvue d’aperçus théoriques sur la construction de logiciels. Disponible ici : http://www.laurentbloch.org/MySpip3....

[17Bertrand Meyer. The Ethics of Free Software. Software Development Magazine, mars 2000. http://www.sdmagazine.com/.

[18Ramenons ici à de justes proportions la vision que l’on a souvent en France du système universitaire américain, dont les universités seraient autant d’entreprises privées gérées comme des sociétés commerciales et dont les étudiants seraient purement et simplement des clients. Cette vision est simpliste : ainsi l’Université de Californie, organisée autour de huit campus répartis sur le territoire de l’État, reçoit 80% de ses financements de l’État de Californie, de l’État fédéral, des municipalités et d’agences fédérales. Les étudiants californiens y sont admis gratuitement sur des critères de dossier scolaire. D’autres universités ont sans doute des modes de fonctionnement plus éloignés du service public français, bref, les situations sont variées et il n’est pas certain que les formations universitaires soient plus réservées aux catégories privilégiées là-bas qu’ici, même si les barrières ne sont pas disposées de la même façon.

[19POSIX (Portable Operating System Interface) est une norme de l’IEEE qui définit une API (Application Program Interface) et une interface de commande pour les systèmes d’exploitation, assez inspirés d’Unix. La première version de POSIX a été rédigée en 1986 par un groupe de travail auquel appartenait notamment Richard M. Stallman. Cet effort de normalisation fut au départ assez mal reçu par une communauté Unix plutôt libertaire : je me rappelle une conférence Usenix à la fin des années 1980 où certains participants arboraient un badge « Aspirin, Condom, POSIX ». Mais il est certain que POSIX fut salutaire.


Forum
Répondre à cet article
De Multics à Unix et au logiciel libre - inconfort
Robert Ehrlich - le 11 août 2014

Avant d’aborder la question du logiciel libre, il faut s’interroger sur un phénomène quand même surprenant : nous avons dit qu’Unix était très inconfortable pour tout autre qu’un développeur utilisant ses diverses fonctions à longueur de journée. Comment expliquer alors qu’en une dizaine d’années il se soit vu reconnaître une position hégémonique dans tout le monde de la recherche ? Parce que même dans les départements d’informatique des universités et des centres de recherche, la majorité des gens ne passent pas leur temps à programmer, il s’en faut même de beaucoup, alors ne parlons pas des biologistes ou des mathématiciens.

Là encore, au risque de me répéter, je peux affirmer qu’à ses débuts Unix était beaucoup moins inconfortable que la plupart des systèmes existants.
J’ai comme j’ai déjà dû le dire ailleurs installé mon premier système Unix vers la fin des années 70, peu de temps auparavant j’avais fait une bref séjour aux Etats-Unis en visite chez un oncle physicien qui travaillait aux Bell Labs. Comme mon labo (LRI Orsay) avait déjà pris la décision d’utiliser Unix à cette époque, voyant que j’étais intéressé, cet oncle m’a d’une part proposé une session Unix chez lui à distance par réseau téléphonique sur un ordinateur des Bell Labs, d’autre part il m’a invité aux Bell Labs et m’a présenté un certain nombre de personnes qui travaillaient avec Unix. Donc pour ce physicien d’une génération avant la mienne qui n’était pas du tout programmeur ni informaticien, Unix était suffisamment confortable pour qu’il ’utilise couramment chez lui. D’autre part aux Bell Labs la plupart des gens que j’ai rencontré n’étaient pas non plus des informaticiens ni des programmeurs mais des utilisateurs de telle ou telle fonction plus ou moins spécifique particulière à leur travail disponible sous Unix ... ou ailleurs. Car à l’époque Unix était aussi utilisé comme "front-end" pour accéder à des système plus puissants mais moins confortables (c’est dans cette utilisation que trouve son origine le champ GCOS du fichier passwd, qui contenait des paramètres nécessaires à l’utilisation d’un système GCOS). Il faut également rappeler que Thompson et Ritchie ont décroché le financement de leur PDP11, qui a permis le passage au multi-tâche, par la promesse d’y réaliser un système de production de documents de qualité sur photocomposeuse moins cher et plus confortable que tout ce qui existait à l’époque, promesse tenue : lors de mon passage aux Bell Labs c’était l’une des grandes utilisations d’Unix, ce fut aussi la principale motivation au départ pour le LRI de se lancer dans cette aventure. Après ils se sont rendu compte que sans la photocomposeuse c’était beaucoup moins bien, mais moi j’avais récupéré un super joujou.

Pour ce qui est de l’inconfort des autres systèmes, il faudra une autre fois que je raconte mes mésaventures avec le JCL d’IBM et ses "cartes DD".

Pour la petite histoire, la session Unix chez mon oncle se passait sur un terminal Texas Silent imprimant sur du papier thermique, je dois encore avoir la feuille déroulante quelque part dans mes archives.

Amalgame
Emmanuel Saint-James - le 27 juillet 2014

Cher Laurent

Merci pour cet article, très intéressant
et plein de détails importants trop peu connus.
Un passage néanmoins me semble passablement confus.
C’est dans la section "Naissance d’un communauté",
les 3 paragraphes avant "Le schisme".
Tu y amalgames le succès d’Unix, réel, à celui, qui reste à démonter,
de la classe sociale qui en serait l’auteur, paternité d’ailleurs elle aussi
discutable, et plus discutable encore le fait que cette classe sociale
serait aussi méprisée que tu le dis. Et pour terminer, tu opposes ce succès
à l’affirmation d’un échec des "autorités académiques", que tu identifies en
France à 3 personnes, dont seule la première, Arsac, a fait une carrière
académique. Je vais essayer de démêler cet écheveau.

Un peu de matérialisme historique d’abord. Tu n’évoques jamais le fait
que pendant les dix ans mis par Unix pour s’imposer, le prix et les
capacités des ordinateurs ont considérablement changé. Si les "autorités
académiques" faisaient beaucoup de théorie à l’époque, c’est d’abord
parce qu’elles n’avaient pas les moyens de faire autre chose.
C’était même une nécessité économique : Arsac racontait ses journées
perdues à porter ses cartes perforées à l’autre bout de la ville pour
apprendre de l’unique ordinateur disponible au CNRS qu’il manquait un
" ;" à la deuxième ligne, et aux essais suivants que la mémoire avait
été saturée par une poignée d’appels récursifs ! Ca motive quand même
beaucoup pour théoriser l’analyse syntaxique et la transformation
recursif / itératif. Ta critique s’adresse plutôt à la génération qui
a suivi, qui n’avait pas cette excuse ; j’y reviendrai.

Ensuite, il est doublement incohérent d’opposer le succès public d’un
outil d’ingénieur, ici un système d’exploitation, à un travail
théorique, toujours destiné à des spécialistes, ici sur les langages
de programmation. Ce contre quoi Unix a gagné, ce sont les systèmes
d’exploitation spécifiques aux constructeurs d’ordinateurs qui voulaient
garder leur clientèle captive par ce biais. Et cette victoire a de
nouveau une raison historique. Unix est né dans le laboratoire de
recherche d’un opérateur de télécommunications, non ceux des
constructeurs informatiques encore marqués par l’usage des cartes
perforées, d’où a découle ce que Bachelard aurait appelé une rupture
épistémologique, affirmant que le coeur d’un système d’exploitation
n’est pas le fichier de données mais le flux d’informations.
Autrement dit on passe de l’archive statique consultée rarement, au
flux dynamique presque toujours en activité. Qu’une rupture
épistémologique vienne d’outsiders au milieu académique est assez
classique : on a assez souligné qu’Einstein était ingénieur au bureau
des brevets, où des brevets sur des horloges ont nourri son inspiration.

Peut-être veux-tu suggérer que les "milieux académiques" ont cru
bon de réinventer des langages de programmation universels alors que
le besoin était d’inventer le premier système d’exploitation
universel. Mais Arsac s’est bien gardé de proposer un langage, tandis
que Meyer et Ichbiah ont proposé les leurs alors qu’ils étaient
ingénieurs dans une entreprise. On a ici plutôt un clivage assez
fréquent entre un normalien qui analyse le monde, et deux
polytechniciens qui prétendent le transformer autoritairement.
Dans le cas de Meyer, son langage Eiffel est un échec mérité car il
avait trop peu de choses nouvelles à y inclure pour justifier une
telle prétention. Pour Ichbiah, il a fait le travail qu’attendait son
employeur, répondre à un appel d’offres, et relativement bien
puisque’ADA a gagné le concours face à des concurrents très sérieux.
C’est plutôt au commanditaire, l’armée américaine, qu’on peut
reprocher d’avoir demandé un nouveau langage, alors que la bonne
réponse (mais c’est facile à dire des decennies plus tard) aurait été
de définir un sous-ensemble de C où on aurait remplacé son mal fichu
"typedef" par le système de types d’ADA, qui se justifie dans le
secteur où il était destiné car un bug y est dramatique.

Par ailleurs, les universitaires s’intéressaient déjà aux systèmes
d’exploitation, notamment Dijkstra que tu cites. Je ne suis pas sûr
que ce soit eux qui ont inventé la notion de sémaphore, indispensable
à Unix, mais au minimum ils l’ont considérablement améliorée. Quant à
la notion de flux d’entrée et de sortie de processus en Unix, c’est
une transposition directe de la programmation fonctionnelle, à
l’époque sujet fétiche des universitaires (à quelques exceptions dont
Arsac, c’est pour moi sa seule vraie erreur de jugement), il est
probable (ça vaudrait la peine de le vérifier) que les auteurs d’Unix
avait un peu de cette culture. A l’inverse, la communauté de la
programmation fonctionnelle s’est très tôt intéressé à Unix, d’une
part à cause de cette transposition, d’autre part parce que la
programmation dite concurrente qu’il offrait était au départ étrangère
à la programmation fonctionnelle, étendre celle-ci pour inclure
celle-là était un défi intellectuel majeur qui sera relevé d’aboard
inélégament avec la pile-spaghetti, ensuite superbement avec la
capture de continuation en Scheme. Bref, tu opposes deux communautés
qui se sont écoutées que tu ne le prétends.

Reste la question de la pénétration de la culture de l’ingénieur dans
le monde universtaire. De nouveau il faut prendre de la distance
historique. Dans les thèses de physique d’avant-guerre, on trouve des
descriptions d’expérience où le matériel est désigné par le nom de
leur fabricant : les chercheurs de l’époque n’étaient nullement gênés
de faire implicitement de la publicité à des entreprises commerciales.
Cette idéologie qu’une science digne de ce nom ne doit
pas se compromettre avec les objets techniques est en fait un moment
très précis de l’histoire de sciences, celui de l’immédiat
après-guerre où le milieu académique sortait traumatisé de la
collaboration de scientifiques avec les pouvoirs militaires pour en
décupler la puissance destructrice. C’était particulièrement le cas
en France, avec le groupe Boubarki. Ce collectif toujours changeant de
mathématiciens a eu le mérite d’inventer le développement collaboratif
en maths, mais il a eu aussi le tort d’imposer l’idéologie sus-dite,
et à ce titre est coupable de beaucoup de choses, en particulier du
démarrage tardif de l’informatique au pays de Descartes, qui avait
pourtant tous les atouts pour l’inventer. Les premiers laboratoires
publics d’informatique en France se sont inscrits dans cette idéologie
(jusqu’à exclure Arsac de la direction de son labo, coupable de trop
s’intéresser à la programmation que ses successeurs se vantaient de ne
pas maîtriser !) mais cela a disparu avec le départ en retraite de
toute cette génération marquée par cette problématique de
l’après-guerre.

Ce qu’il faut voir c’est que la démocratisation de l’enseignement
supérieur ne se traduit pas seulement par l’arrivée de bacheliers
issus des classes défavorisées sur les bancs des amphis, mais aussi
par leur accès à des postes de chercheur et d’enseignant-chercheurs,
et aussi à des rapports moins inégalitaires entre enseignants et
non-enseignants à l’université, 68 étant passé par là. Les questions
soulevées par les ingénieurs sont donc plus audibles qu’auparavant,
car les milieux sociaux sont moins clivés qu’aux générations
précédentes. Il faut aussi prendre en compte la prise de pouvoir
progressive du manager dans les établissements scientfiques, qui a
remplacé l’évaluation qualitative des laboratoires, par une évaluation
strictement comptable en nombre de publication et de contrats avec des
entreprises, qu’elle qu’en soit les qualités et les buts. Cela ne
pouvait qu’encourager l’acceptation de sujets d’études que la
génération précédente aurait qualifié de pas assez noble.

On peut quand même se poser la question de savoir si aujourd’hui on
n’est pas tombé dans l’excès inverse : les mandarins universitaires ont
empêché la science d’avancer dans certaines directions, mais au moins
ils la faisaient avancer dans d’autres. Les managers d’aujourd’hui
n’ont même pas cette excuse.

Bien à toi.

Amalgame
Laurent Bloch - le 27 juillet 2014

Merci cher Emmanuel pour cette riche contribution. Comme bien tu te doutes, parmi les choses que tu écris je suis d’accord avec certaines et pas avec d’autres, alors je corrigerai certaines erreurs que tu relèves, et répondrai pour certaine points que je maintiens. Notamment, si Ichbiah et Meyer n’étaient pas des universitaires, les équipes avec qui ils travaillaient en comportaient. Bon, plus de détails plus tard ! Amicalement.

Ingénieurs, chercheurs, universitaires
Laurent Bloch - le 27 juillet 2014

Cher Emmanuel,

Tu écris « Tu y amalgames le succès d’Unix, réel, à celui, qui reste à démonter, de la classe sociale qui en serait l’auteur, paternité d’ailleurs elle aussi discutable, et plus discutable encore le fait que cette classe sociale serait aussi méprisée que tu le dis. »

En fait, pour ce qui est du mépris (éventuellement mutuel) entre chercheurs et ingénieurs je te renvoie à un texte sur le sujet. Et quant à l’organisation d’Ancien Régime de l’université française, en société d’ordres et de statuts, j’ai pu vérifier par moi-même lorsque j’y travaillais.

Sémaphores
Robert Ehrlich - le 29 juillet 2014

la notion de sémaphore, indispensable
à Unix

La notion de sémaphore était si peu indispensable à Unix à ses débuts que ses auteurs, tout en connaissant fort probablement son existence, ont soigneusement évité d’y recourir. Les raisons sont probablement le coût en temps d’exécution et en place mémoire que cela aurait représenté. Il faut se rappeler ce qu’était un PDP11, la machine du premier Unix multi-tâche, voir mes commentaires précédents.

Il leur fallait néanmoins un mécanisme d’exclusion mutuelle, pour éviter des modifications incohérentes de structures de données du noyau par plusieurs processus s’exécutant en simultanéité apparente. Toute la ruse de Thompson et Ritchie a été de profiter de ce que cette simultanéité n’était qu’apparente, ces premiers Unix ne s’exécutant que sur des mono-processeurs.
Le principe de base était que le noyau est non-préemptif : un processus exécutant du code en mode kernel ne perd la min au profit d’un autre que volontairement, et s’il décide de le faire alors qu’il a laissé une ou plusieurs structures du noyau dans un état non cohérent, il y laisse un indicateur "booléen", un bit à 1, qui veut dire "personne ne touche à ça à part moi tant que ce bit est à 1"., ce qui sous-entend qu’il est assuré de reprendre la main au moins pour remettre les chose dans l’ordre (conséquence : le "kill" d’un processus ne devient effectif qu’au moment où il tente de retourner en mode user, auparavant il est dans un état dit "zombie" (mort-vivant)). Comme le processus qui positionne ce bit est assuré de ne pas perdre la main entre le moment où il teste ce bit et le moment ou il le positionne, point n’est besoin de mécanisme matériel du type test & set assurant l’indivisibilité des deux opérations, ça s’écrit en C avec les opérateurs usuels.

Reste la question des interruptions qui peuvent éventuellement exécuter du code entre le test et le set, où consulter des structures dans un état incohérent. Il faut donc interdire les interruptions entre le test et le set et aussi bien dans une routine d’interruption qu’ailleurs, tester ce bit d’exclusion avant d’accéder à la structure, tout ceci seulement pour les interruptions qui peuvent accéder à cette structure.

Malgré cette politique non-préemptive le partage du temps équitable entre processus est assuré par le fait que le code que tout processus exécute avant de retourner en mode user teste si entre temps un autre processus n’est pas prêt à l’exécution et plus prioritaire et dans ce cas décide de perdre la main son profit, ces priorités évoluant en fonction du temps consommé par chaque processus, chose gérée par l’interruption d’horloge.

Evidemment tout ce mécanisme tombe à l’eau dès qu’on a plus d’un processeur exécutant le code du noyau. Les premiers Unix multi-processeurs s’en sont sorti en décidant qu’un seul processeur exécutait le code du noyau. Plus tard Linux par exemple a introduit de vrais sémaphores en lieu et place de ce mécanisme, ce qui permet à plusieurs processeurs d’exécuter du code du noyau sans s’emmeler les pinceaux.

http://robert.ehrlich.free.fr
Sémaphores
Emmanuel Saint-James - le 29 juillet 2014

Grand merci pour cette précision. J’avoue ma méconnaissance des premiers Unix, dont j’ignorais que c’était des systèmes plus coopératifs que concurrents. Cela dit le concept de sémaphore n’est qu’un parmi d’autres dans les systèmes d’exploitation que les chercheurs ont investigués très tôt : l’ordonnancement, par exemple, relève à la fois du système et la recherche opérationnelle. Il faudrait faire les histoires parallèles des différentes versions des systèmes et des articles de chercheurs sur leurs concepts : mon propos est simplement de dire que dès le début ces deux histoires ne sont certainement pas disjointes..

De Multics à Unix et au logiciel libre
- le 27 juillet 2014

Ma compétition de planeur est terminée, j’ai donc du temps pour d’autres commentaires. Au sujet de ce qui suit :

Nous venons de dire qu’Unix était un système de production de programme, conçu pour satisfaire les programmeurs professionnels et à peu près personne d’autre. Comment expliquer alors qu’il se soit répandu dans beaucoup d’autres domaines, souvent au prix de beaucoup de crises de nerfs de la part d’utilisateurs furieux ? Parce qu’il faut bien dire qu’Unix n’est pas un système confortable pour qui n’est pas disposé à y consacrer la moitié de son temps de travail.

Pire que ça, Unix a été conçu pour satisfaire une personne : Ken Thompson, dont le but était de faire un programme de jeux d’échecs.
Pour ce qui est des crise de nerfs, là encore, il s’agit d’utilisateurs de 2ème ou 3ème génération. A l’époque de mon premier contact avec Unix (6th edition), c’était de loin le plus convivial des systèmes existants. Ses deux principales caractéristiques : interactivité et multi-tache ne se trouvaient simultanément que sur des systèmes beaucoup plus gros et couteux.

Cette notion de convivialité est extrêmement relative et entachée de tas d’a priori. J’ai souvent dit que l’interface graphique initié par la célèbre marque à la pomme (en fait le centre de recherche de Xerox à Palo Alto) et devenu un quasi standard obligatoire de nos jours représente le stade nourrisson de l’interface homme-machine : le nourrisson ne sait pas parler, il montre (pointe) ce qu’il veut et crie (clique) pour l’obtenir. Plus tard il apprend à parler et du coup ses possibilités d’expression s’accroissent infiniment. De même l’utilisateur sérieux d’un système informatique apprend un langage qui lui permet d’exprimer ce qu’il veut faire. La difficulté d’un tel apprentissage est à mon expérience bien plus faible que celle de l’apprentissage de l’anglais par lequel doit passer tout chercheur aujourd’hui.
Pour donner une idée de ce que pouvait être les "convivialités" de différents systèmes à l’époque, l’auteur d’un des articles parus dans le journal des Bell Labs sur le système Unix proposait le test suivant : écrire un programme FORTRAN (quasiment le seul langage de programmation évolué trouvable à peu près sur tous les systèmes de l’époque) dont le résultat soit un programme FORTRAN, compiler et exécuter le premier puis le deuxième programme. La première partie ne présentait pas grande difficulté pour qui connaissait le système sur lequel il voulait le faire, mais la deuxième étape présentait des difficultés quasi insurmontables sur beaucoup de systèmes dans lesquels les fichiers avaient des types et le type d’un fichier "sortie de résultat d’un programme FORTRAN" n’avait rien à voir avec le type "programme source FORTRAN", il fallait passer par un utilitaire de conversion en supposant qu’il en existe un. Je me souviens d’avoir été confronté à un problème voisin quelques annés plus tard, à l’époque où le quasi standard en matière d’ordinateur de prix "abordable" était devenu le VAX de Digital Equipement Corporation. Un laboratoire de la fac d’Orsay avait un tel ordinateur fonctionnant sous le système du constructeur (VMS) et désirait passer sous Unix BSD. Le problème était de transférer les fichiers des utilisateurs d’un système à l’autre. Le responsable du labo m’avait demandé si je pouvais réaliser la chose. Après consultation de la doc disponible (un gros classeur papier parmi une ou plusieurs dizaines d’autre), j’ai abouti à la conclusion que le seul utilitaire sous VMS capable de sauvegarder toute une hiérarchie de fichiers avec toute l’information associée s’appelait "backup", qui créait des "bandes backup" dont le format était décrit sur de nombreuses pages de la doc, car il y avait de nombreux formats de fichiers, pour chacun il fallait trouver comment le convertir en un fichier Unix qui soit vu par ce dernier système à peu près comme il l’était sous VMS. Comme je me doutais que certains formats n’étaient utilisés par aucun utilisateur j’ai fait l’impasse sur ces formats en me contentant d’un message d’erreur "Je ne sais pas convertir ce type de fichier". Je pensais écrire ce jour là un programme à usage unique, mais il a resservi ultérieurement à l’INRIA quand après le crash du vol Ariane 501 l’INRIA a entamé un collaboration avec Arianespace qui fournissait ses données sur des bandes de ce format, ainsi que par Jean Paul Chieze, ingénieur système à l’INRIA dans un équipe graphique, pour des échanges avec des groupes utilisant ce format, il a complété le programme en rajoutant le traitement de types que j’avais ignoré mais dont il avait besoin.

Emacs
Robert Ehrlich - le 22 juillet 2014

Puisque j’y suis invité, j’essaie de poursuivre la rédaction des commentaires que ce texte m’inspire. Ils arriveront forcément au compte-gouttes, vu que je participe en ce moment à une compétition de planeurs, c’est l’épreuve annulée d’aujourd’hui qui me fournit le loisir d’écrire ce qui suit. Cela concerne cet extrait :

L’auteur de ces lignes, il y a de nombreuses années, a compris que s’il voulait espérer conserver l’estime de certains collègues il lui fallait savoir se servir assez couramment d’Unix et surtout de l’éditeur de texte Emacs avec lequel d’ailleurs il compose le présent texte. Cette prise de conscience a entraîné de nombreuses et lourdes conséquences.

Il s’agit là déjà de réactions d’Unixiens de seconde génération. Mon premier contact avec Unix date de la fin des années 1970, quand le Laboratoire de Recherche en Informatique de la faculté d’Orsay m’a confié le soin d’installer Unix sur le PDP11/34 qui avait été acheté dans ce but. Pour fixer grossièrement les idées, il s’agit d’un machine 16 bits dotée initialement de 128k octets de mémoire extensible à 56k et de deux disques de 4 Mo chacun dont un amovible. Je regrette que cette brève description ne rende pas justice à cette véritable oeuvre d’art informatique qu’était le PDP11, ce sera pour un autre sujet. Même si Emacs existait déjà à cette époque, il était hors de question de le faire fonctionner sur cette configuration, c’était un privilège réservé aux riches propriétaires de PDP10, le haut de gamme du constructeur DEC, pour lequel je crois qu’il avait été écrit.

L’éditeur de texte standard de l’époque, c’était "ed" et ça le reste pour moi. Beaucoup de gens aujourd’hui sont étonnés quand ils me voient l’utiliser et me regardent comme un dinosaure. Je ne méconnais pas les avantages d’un éditeur "pleine page", "visuel", WYSYIWYG, comme on peut qualifier Emacs, qu’il m’arrive d’utiliser quand je le juge approprié, mais souvent ce n’est pas le cas. Une bonne partie de ce que j’ai eu a faire durant ma vie professionnelle comme travail d’édition consistait à modifier une ou deux lignes d’un fichier après d’intenses réflexions et l’exécution de multiples commandes dont l’affichage des résultats m’avait conduit à la conclusion de la nécessité de ce changement et à ce moment je n’avais que faire de l’affichage des autres lignes dans une nouvelle fenêtre ou dans la même après l’avoir effacée, ce qui me cache ces résultats affichés précédemment où figure en général ce que je dois mettre dans dans la (les) lignes à modifier.

Pour plus d’information sur "ed", taper "ed unix text editor" dans votre moteur de recherche préféré fournit une foule de renseignements intéressants et/ou amusants.

Le seul message d’erreur de ed était " ?". Quelque part Brian Kernighan avait écrit qu’il est inutile de prévoir des messages d’erreur compliqués qui de plus souvent ne reflètent pas vraiment l’erreur réelle (je ne peux m’empêcher de repenser à celui qui nous a bien fait rire : "Yves Devillers : not a typewriter"), et qu’il valait mieux une indication d’erreur minimale, l’utilisateur comprendra bien de lui-même où il s’est trompé. Cette déclaration est à l’origine de la légende de l’automobile de Kernighan, qui ne comporte sur son tableau de bord qu’un gros voyant rouge en forme de point d’interrogation qui s’allume quand quelque chose ne va pas, en réfléchissant un peu Kernighan comprend où est le problème.

Ceci dit les critiques sur la convivialité de ed et plus généralement du système Unix me semblent très naïves et "premier degré". A comparer avec l’un des premiers systèmes dit conviviaux d’une célèbre marque à la pomme qui avait inventé pour cela la notion de "modal dialog" : en cas d’erreur une nouvelle fenêtre s’affiche où figure un message d’erreur le plus souvent sans intérêt, qui cache ce qui était affiché précédemment ayant probablement quelque rapport avec l’erreur et interdit toute autre action que cliquer sur le mot "fermer", ce qui fait disparaitre la fenêtre et donc le message, comme pour confirmer qu’il est sans intérêt.

Le sigle qui s’appliquerait bien à ed est non pas WYSIWYG mais WYSIWYD : What You See Is What You Did. On voit ce qu’on a fait, les commandes restent affichées, ça peut aider, surtout le roi de la faute de frappe que je suis.

Développeur
Robert Ehrlich - le 20 juillet 2014

Ce texte me donne envie d’écrire une quantité de commentaires qui dépasserait en longueur celle du texte lui-même tant je me sens concerné par le sujet (et un peu acteur dudit). Mais pour faire bref je vais me contenter du dernier qui m’est venu à l’esprit, au sujet de la note qui dit que la notion de "développeur" est arrivée avec Unix.

Pour moi ce terme est arrivé avec le Macintosh, voire même son prédécesseur le Lisa. Il fait partie d’un certain nombre de choix conscients et volontaires de terminologie de la part de la maison Apple, comme "application" au lieu de "programme", "disque" au lieu de "floppy" ou "disquette" (ces deux derniers termes étant perçus comme péjoratifs selon une brochure de la maison). A l’époque je me souviens que mon commentaire fut que programmer une "application" pour MacIntosh était tellement difficile et compliqué qu’il fallait pour celà une nouvelle race de programmeurs : les développeurs.

PS

Concernant le commentaire plus haut sur le COBOL et la façon d’ajouter un même nombre à plusieurs variables, je suis loin d’être un expert en C++, langage que je déteste, mais il me semble qu’il suffirait de définir un opérateur, disons ++=, dont l’effet de bord serait le même que +=, mais dont le résultat serait l’opérande droit, et l’opération s’écrirait :

TOTAL_JOUR ++= TOTAL_SEMAINE ++= TOTAL_MOIS ++= TOTAL_FACTURE ;

Développeur
Laurent Bloch - le 21 juillet 2014

Merci Robert pour cette contribution, et j’espère que tu prendras le temps d’écrire tout ce qui te vient à l’esprit sur ce sujet et que tu laisses en suspens ici. Et si tu ne sais pas où le publier, je m’en ferai un plaisir !

Pour ce qui est du terme « développeur », il me semblait l’avoir entendu pour la première fois à la fin des années 1970 dans la bouche d’un Multicien, mais c’est un souvenir trop imprécis pour que j’en mette ma main au feu.

Amicalement !

De Multics à Unix et au logiciel libre
Frédéric Brouard - le 20 juillet 2014

Bonjour,

je n’aime pas le terme punitif employé au sujet de COBOL. En effet dans certains cas, des langages moins "arides" (et encore... pensez vous que C/C++/Java soient moins arides que Pascal ou ADA ?) sont encore plus punitifs. Par exemple avec COBOL, il est possible en une seule instruction d’additionner une valeurs à plusieurs variable :

ADD TOTAL_FACTURE TO TOTAL_SEMAINE, TOTAL_MOIS, TOTAL_AN

Dite moi comment faire cela aussi simplement en C++ par exemple !

A +

De Multics à Unix et au logiciel libre
Laurent Bloch - le 20 juillet 2014

Vous avez raison, je rectifie.



pucePlan du site puceContact puceEspace rédacteurs puce

RSS

2004-2017 © Site WWW de Laurent Bloch - Tous droits réservés
Site réalisé sous SPIP
avec le squelette ESCAL-V3
Version : 3.87.35