Unix, a History and a Memoir

Publié le 15/08/2022

A la lecture de ce livre, on d√©couvre qu'une grande partie de l'informatique moderne a √©t√© cr√©√©e et pens√©e dans les laboratoires Bell, √† partir du milieu des ann√©es 1960. Une des missions du Bell Labs √©tait de d√©velopper une compr√©hension math√©matique du fonctionnement des communications. Le r√©sultat le plus important aura √©t√© la th√©orie de l'information de Claude Shannon (mais √† c√īt√© de quoi, on trouvait √©galement des propositions de r√©solution √† des probl√®mes de partionnement de graphs 1).

Ce qui est dr√īle (d'une certaine mani√®re et avec un humour particulier), c'est que beaucoup de grands de l'informatique moderne ont travaill√© ou approch√© le Bell Labs:

Un des ancêtres de Unix était le CTSS (Compatible Time-Sharing System), qui pouvait sans doute être considéré comme l'un des plus innovants de l'époque. Il avait été créé au MIT en 1964, à l'ère du "batch processing": les développeurs alimentait des cartes perforées, les donnaient à un opérateur et attendaient le résultat (qui pouvait arriver quelques heures, voire jours, plus tard). A l'opposé de ceci, les développeurs qui utilisaient CTSS dsposaient d'un terminal(-like), connecté directement ou par ligne téléphonique à un seul (gros) ordinateur (type IBM 7094).

CTSS était tellement performant et innovant que des chercheurs du MIT décidèrent de faire encore mieux, et commencèrent à développer un nouveau système appelé Multics - the Multiplexed Information and Computing Service, en collaboration avec le MIT et General Electrics. Multics a cependant été victime du second system effect:

*After a success (like *CTSS*), it's tempting to try to create a new system that fixes all the remaining problems with the original while adding everybody's favorite new features too. 
The result is often a system that's too complicated.
--- page 31 - CTSS and Multics

Multics eut finalement sa release, et les personnes qui travaillaient dessus ont d√Ľ trouver autre chose √† faire 2. C'est √† ce moment-l√† que Ken Thompson a pu mettre la main sur un DEC PDP-7, d√©j√† d√©pass√© en 1969 (seulement 16KB de RAM, et fonctionnant avec des mots de 18 bits, mais avec un chouette affichage graphique). Un des soucis du PDP-7 √©tait qu'il √©tait √©quip√© d'un disque √† chargement vertical dont la vitesse de lecture √©tait trop rapide pour l'ordinateur qui y √©tait connect√©. Ken Thompson √©crivit un ordonnanceur pour maximiser l'√©criture de donn√©es vers n'importe quel p√©riph√©rique de sortie. Pour tester son algorithme, il avait besoin d'un programme permettant de charger des donn√©es en quantit√©. Il r√©alise √† ce moment-l√† qu'il lui suffit de d√©velopper un √©diteur, un assembleur et une surcouche au noyau pour avoir un syst√®me d'exploitation fonctionnel.

1 Etant donné un ensemble de noeuds connectés par des arêtes, trouvez une manière de séparer/regrouper les noeuds en deux groupes de taille égale, de manière à ce que le nombre d'arêtes qui connecte un groupe à l'autre soit le plus faible possible.

2 Bell Labs était organisé de manière à ce que chaque employé soit plus ou moins orienté dans ses recherches, mais ils restaient malgré tout extrêmement libres dans leur travail. Cf. page 16-17: This was standard practice: people were introduced to other people, encouraged to wander around, and left to find their own research topics and collaborators.

Unix

Les composants principaux de l'élégance d'Unix sont les suivants dont la conception est toujours d'actualité (et ont souvent été copiés, voire émulés). Ceci concerne:

Système de fichiers

Le système de fichiers d'Unix est tiré de l'expérience que Ken Thompson a acquise en développant celui de Multics. La conception de ce système de fichiers est toujours d'actualité, et a été souvent copiée/émulée par d'autres systèmes. Elle permet notamment de ne pas avoir de limites de profondeur des noeuds et considère tout élément comme un inode, qu'il s'agisse d'un dossier ou d'un fichier. Pour simplifier, le système de fichier traite uniquement de bytes, et se fiche un peu de savoir qu'il s'agit d'un montage réseau, d'un disque mécanique ou d'une bande magnétique.

C'est également à cette implémentation-ci que l'on doit les chemins relatifs et fameux . et ...

Appels systèmes

Les appels systèmes sont des services exposés directement par le système d'exploitation 3, et qui peuvent être appelés par les différents programmes qui tournent sur ce système. Ceci inclut la possibilité de démarrer ou d'arrêter d'autres programmes, de lire ou d'écrire des informations dans des fichiers, voire d'accéder à des périphériques ou à des connexions réseau.

A l'origine, Unix proposait seulement 30 appels systèmes, dont la moitié était en lien avec le système de fichiers (read, open, write, close, ...). Pour l'anecdote, la fonction creat ne prenait pas de e suite à un choix de Ken Thompson, choix qu'il regrette encore aujourd'hui:

Rob Pike once asked Ken Thompson what he would change if he were to do Unix over again.
His answer ? 
"I'd spell `creat` with an `e`.

-- page 64.

Shell

Le shell, qui est un programme qui appelle d'autres programmes, en autorisant une redirection des entrées et sorties (et en distinguant la sortie classique des erreurs). Un shell ne remplace aucun programmes compilés, mais font partie de la ceinture d'outils du développeur: si on se retrouve à répéter certaines actions plusieurs fois, il convient de prendre du recul et d'automatiser le maximum. Si un script shell venait à devenir lent, il pourrait toujours être réécrit dans un autre langage, plus adapté.

Un des gros plus du shell concerne la possibilit√© de rediriger des inputs/outputs, pour pouvoir lire un fichier en entr√©e plut√īt que d'attendre une entr√©e au clavier, pour pouvoir √©crire une sortie applicative vers un fichier, voire pour cha√ģner les deux.

Pipes

Les pipes, qui permettent simplement de connecter la sortie d'un programme avec l'entrée d'un autre(plus élégant que ça, on ne fait pas). Le seul prérequis à ceci est, que chaque programme utilise du texte comme étant l'interface universelle:

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface. 

-- Doug McIlroy - The Art of Unix Programming (2003)

L'élégance de la solution fait que it [was] super-trivial [to implement] given that the mechanisms for I/O redirection were already there. [...] It is constructed from the very same commands used constantly in simplex fashion. The mental leap needed to see this possibility and to invent the notation is large indeed

Expressions rationnelles (et grep)

Une "expression rationnelle" (ou régulière) est un mini-langage qui permet de décrire des modèles de texte.

"Doug McIlroy said 'Wouldn't if be great if we could look for things in files?"

L'implémentation des expressions rationnelles (et de leur prise en compte un peu partout au niveau système) est une histoire commune dans la construction d'Unix: on part d'un vrai problème communiqué par un utilisateur, on connait la théorie de manière approfondie et une ingénierie effective, une amélioration continue, une bonne expertise du groupe, un environnement ouvert et une culture d'expérimentation de nouvelles idées font que "ça juste marche".

grep vient en fait de la commande g/re/p de l'éditeur ed qui permettrait d'afficher toutes les lignes qui correspondraient à l'expression rationnelle re dans la commande.

3 Personnellement, les termes de système d'exploitation me hérissent un chouia, et je proposerais bien à l'académie française de basculer vers système d'opération... Parce que certains systèmes nous laissent un peu penser que c'est l'utilisateur qui est exploité.

Le langage C

Le langage C est un composant primordial du succ√®s d'Unix. De son c√īt√©, Multics avait fait le pari d'utiliser un langage de haut-niveau: PL/1. PL/1 est une tentative de combinaison entre Fortran, COBOL et Algol. Le soucis touchait la cha√ģne de compilation, qui √©tait trop lourde et trop compliqu√©e pour la plupart des d√©veloppeurs. Apr√®s la sortie de Multics, Doug McIlroy et Doug Eastwood cr√©√®rent un sous-ensemble de PL/1, BCPL (Basic Combined Programming Language), qui √©tait beaucou plus simple que n'importe quel dialecte de PL/1, tout en √©tant accessible pour de la programmation syst√®me.

A c√īt√© de cela, Ken Thompson √©tait persuad√© qu'aucun syst√®me n'√©tait complet sans Fortran. Probl√®me (pour le PDP-7): un compilateur Fortran √©tait trop compliqu√© √† porter, √† cause des limitations mat√©rielles. C'est ainsi qu'il cr√©a le langage B, dont la syntaxe √©tait beaucoup plus proche de BCPL que de Fortran.

Ainsi arriva le langage C, d√©riv√© de B, mais auquel une gestion des types de donn√©es a √©t√© ajout√©e (et qui correspondait aux types de donn√©es g√©r√©s par le PDP-11, successeur du PDP-7 au Bell Labs): bytes, entiers (deux bytes), nombres √† virgule flottante (quatre ou huit bytes), ... Le langage C s√©parait √©galement les notions d'entiers et de pointeurs (l√† o√Ļ BCPL et B les traitaient de la m√™me mani√®re).

Jusqu'en 1973, Ken Thompson a essayé de réécrire le noyau en C, mais cela s'est avéré trop difficile, jusqu'à ce que Dennis Ritchie ajoute un mécanisme permettant de définir et de gérer des données imbriquées dans des structures (les struct en C) au langage.

Les outils complémentaires

On peut citer ici les outils type diff, spell, patch, join, ... qui sont encore utilis√©s quotidiennement dans Git et dans beaucoup d'autres grands logiciels. On verra √©galement arriver Lex et Yacc, qui feront apparaitre de nouveaux langages et DSL, de m√™me que Make, qui permettra l'automatisation de nombreuses t√Ęches, ainsi que sed et awk qui compl√©teront la boite √† outils du d√©veloppeur moderne (sauf qu'ils datent tous de la fin des ann√©es '70). On verra aussi tous les outils de pr√©paration de documents (Eqn, troff, ...), dont LaTeX de Don Knuth sera largement inspir√©.

De mani√®re plus g√©n√©rale, tous ces outils repr√©sentent tr√®s bien la philosophie Unix, qui √©tait de r√©aliser une t√Ęche (mais bien) et de consid√©rer le texte et les cha√ģnes de caract√®res comme des citoyens de premi√®re classe.

A ce stade, Unix aura évolué du PDP-7, au DEC VAX-11/780, en passant par le PDP-11, et en devenant à présent (presque) indépendamment du matériel sur lequel il sera déployé.

C'est aussi à ce moment que l'on verra apparaitre le Bourne Shell, qui accompagne la plupart des grandes distributions actuelles (Debian, Ubuntu, Fedora, Arch, ...) et qui venait avec ses propres instructions de programmation: if...then...else...fi, do, ... tout en enrichissant les redirections d'I/O:

Licences

La distribution d'Unix a aussi ouvert les contributions open-source; √† la base, l'acquisition d'Unix √©tait relativement ch√®re pour une universit√© ($20.000 de l'√©poque; $100 000 de la n√ītre), mais ces licences octroyaient par d√©faut le code source, ainsi qu'une forme de support - Ken Thompson a ainsi pass√© une ann√©e sabatique √† Berkeley en 1975 et 1976. La disponibilit√© des sources permit √† Berkeley de contribuer √† la pile r√©seau, mais √©galement √† la cr√©ation de nouvelles applications (vi, C-Shell, l'interface des sockets, ...).

Conclusions

C'est top à lire, un peu high-level, un peu personnel, un peu autobiographique. Cela parle de langages (C, Pascal, PL/1, COBOL, ...), d'architecture physique, de bits, de bytes, de mots, de RAM, de limitations matérielles, ...

Unix a évidemment permis la création de dérivés (Linux, forcément), mais aussi BSD, de part son système de licences, les systèmes V (HP-UX, AIX, Solaris, ...), et évidemment macOS.