UNIX

L’histoire d’UNIX commence par des besoins étonnamment concrets : un jeu de voyage dans le système solaire, un ordinateur peu utilisé, puis des documents de brevets à mettre en forme. En 1969, quelques chercheurs des Bell Laboratories commencent à construire un système d’exploitation qui va progressivement dépasser leur laboratoire.

UNIX ne se résume pourtant pas à un programme chargé de faire fonctionner un ordinateur. Il forme un véritable environnement de travail : les fichiers sont organisés dans une arborescence, les programmes s’exécutent sous forme de processus et de nombreuses commandes spécialisées permettent de manipuler des fichiers, traiter du texte, compiler des programmes ou automatiser des tâches. Un interpréteur de commandes, le shell, permet en outre de combiner ces outils et de créer ses propres procédures.

C’est cette manière d’organiser le travail informatique qui va faire une grande partie de sa force. Plutôt que de construire un outil immense capable de tout faire, UNIX favorise de petits programmes spécialisés que l’on peut associer selon les besoins. Le langage C facilitera ensuite son adaptation à de nouvelles machines ; les universités, les constructeurs puis les communautés du logiciel libre contribueront à diffuser et prolonger ses principes.

Suivre cette histoire permet de comprendre à la fois la naissance d’UNIX et la persistance de ses idées. Ses mécanismes prennent forme au fil des usages, des contraintes matérielles et des contributions d’une équipe.

Fiche rapide

Repère	Description
Origine	Bell Laboratories, aux États-Unis, en 1969
Principaux concepteurs initiaux	Ken Thompson et Dennis Ritchie, avec les contributions de plusieurs collègues
Premières machines	DEC PDP-7, puis PDP-11
Langage du noyau	Assembleur à l’origine ; réécriture majeure en C en 1973
Usages	Programmation, traitement de texte, enseignement, puis applications industrielles et réseaux
Particularité	Un système évolutif, une famille historique et, dans son sens formel actuel, une marque liée à une certification

Après Multics, préserver une autre manière de travailler

Au cours des années 1960, les Bell Labs participent avec le MIT et General Electric à Multics. Le projet vise un service informatique partagé, accessible depuis des terminaux, avec des mécanismes élaborés de protection et de gestion de la mémoire. Il prolonge notamment les expériences du CTSS. Grâce au temps partagé, plusieurs personnes peuvent travailler sur le même ordinateur, chacune depuis son terminal.

Les difficultés et les retards du projet conduisent les Bell Labs à s’en retirer en 1969. Les chercheurs risquent alors de perdre un environnement auquel ils tiennent. Dennis Ritchie explique leur attachement à cette manière de programmer et d’échanger entre collègues autour d’une machine commune. Continuer à disposer d’un tel lieu de travail devient l’un des moteurs du nouveau projet.

UNIX conserve certaines idées expérimentées avec Multics et leur donne une réalisation adaptée à des moyens beaucoup plus modestes. Multics poursuit de son côté son développement après le départ des Bell Labs. Pour le petit groupe qui cherche un nouvel environnement, la première occasion vient d’un ordinateur disponible et d’un jeu.

Un PDP-7, un jeu et les premiers outils

Ken Thompson développe un jeu, Space Travel, qui simule un déplacement dans le système solaire. Son exécution sur le grand ordinateur disponible pose des problèmes de coût et d’interaction. Un PDP-7 peu utilisé, équipé d’un dispositif d’affichage, offre une autre possibilité. Thompson et Ritchie adaptent le jeu à cette machine. Mais pour travailler réellement sur le PDP-7, il ne suffit bientôt plus d’y faire fonctionner Space Travel : il faut disposer d’outils permettant d’y enregistrer, organiser, modifier et exécuter des programmes.

C’est dans ce contexte que le système de fichiers prend forme. Thompson, Ritchie et Rudd Canaday réfléchissent à une manière d’organiser les données sur la machine. Thompson en réalise ensuite une version sur le PDP-7, puis ajoute progressivement les programmes nécessaires pour travailler avec le système : un interpréteur de commandes, un éditeur, des utilitaires et un assembleur. Au début, certains programmes sont encore préparés sur un autre ordinateur avant d’être transférés vers le PDP-7 par bande perforée. Peu à peu, l’ensemble dépasse largement les besoins du jeu : le PDP-7 devient le support d’un nouvel environnement de travail.

Une étape décisive est franchie lorsque l’environnement devient capable de produire ses propres programmes : le système sert désormais à son propre développement. Son nom vient ensuite. Ritchie attribue à Brian Kernighan, en 1970, le jeu de mots UNIX, inspiré de Multics. La naissance du système en 1969 précède donc son appellation ; elle correspond au début d’une expérimentation.

L’activité attire progressivement d’autres collègues. Dans son entretien ACM–Computer History Museum, Thompson évoque notamment les outils de construction de compilateurs apportés par Doug McIlroy. Autour du PDP-7 se forme le lieu de travail collectif que les chercheurs souhaitaient retrouver. Cette réussite encourage l’équipe à demander une machine mieux adaptée.

Une utilité immédiate à UNIX : les brevets

En 1970, l’équipe a besoin d’une nouvelle machine pour poursuivre ses expérimentations. Mais obtenir l’achat d’un ordinateur uniquement pour développer un système d’exploitation expérimental reste difficile à justifier auprès des Bell Labs. Les chercheurs cherchent donc une application immédiatement utile à l’entreprise.

Une occasion se présente avec le PDP-11. Pour obtenir son achat, l’équipe met en avant une utilisation très concrète : préparer, éditer et mettre en forme des documents. Joe Ossanna joue un rôle important dans cette orientation. Le service des brevets des Bell Labs devient ainsi l’un des premiers utilisateurs du système en dehors du petit groupe qui le développe. Des dactylographes peuvent préparer leurs textes avec les outils installés sur la machine.

Cette utilisation change la situation. UNIX n’est plus seulement un projet expérimental intéressant quelques chercheurs : il commence à résoudre un problème réel de l’entreprise. Le traitement des documents contribue ainsi à donner au système une utilité et une légitimité immédiates.

Le premier manuel UNIX, daté du 3 novembre 1971, montre cependant à quel point le système reste encore rudimentaire. Le PDP-11/20 ne dispose que de 24 Ko de mémoire et ne possède pas de matériel de gestion de la mémoire. UNIX est encore écrit en assembleur. Des éléments qui deviendront plus tard emblématiques du système, comme les pipes ou la commande grep, n’existent pas encore.

Pourtant, une idée essentielle apparaît déjà : plutôt que de construire un seul programme capable de tout faire, les chercheurs développent progressivement de petits outils spécialisés. Cette manière d’organiser le système va devenir l’une des caractéristiques fondamentales d’UNIX.

Ce que le système organise : noyau, shell et programmes

Lorsqu’un utilisateur saisit une commande, plusieurs composants coopèrent. Le shell, ou interpréteur de commandes, lit sa demande et prépare son exécution. Le programme demandé réalise la tâche : afficher un répertoire, éditer un texte ou compiler. Le noyau, au cœur du système, gère les processus — les programmes en cours d’exécution — et leur accès aux fichiers et aux périphériques.

Prenons ls, qui affiche le contenu d’un répertoire. Le shell lance ce programme ; ls demande au noyau les informations nécessaires et prépare l’affichage. On peut ainsi modifier l’outil sans réécrire tout le système. Le shell possède lui aussi son propre langage, qu’il est possible de faire évoluer.

Les programmes accèdent aux services du noyau par des appels système, des opérations prévues pour demander, par exemple, l’ouverture d’un fichier ou la création d’un processus. Thompson décrit cette organisation dans son article de 1978 sur l’implémentation d’UNIX.

Cette répartition facilite les contributions : chacun peut ajouter un outil en utilisant les services existants. Parmi ceux-ci, l’accès aux fichiers fournit une première base commune.

Des fichiers organisés dans une arborescence

Cette organisation se précise avec les premières machines. Sur le PDP-7, les répertoires existent déjà, mais les noms de chemins composés avec / sont absents. Les utilisateurs s’appuient sur des liens entre répertoires, avec des contraintes qui rendent les sous-répertoires difficiles à employer. Les chemins complets apparaissent avec le passage au PDP-11.

Dans l’UNIX décrit par Ritchie et Thompson, les fichiers sont désignés par des noms organisés en répertoires. Le chemin /usr/anna/rapport se lit depuis la racine / : on traverse le répertoire usr, puis anna, pour atteindre rapport. L’utilisateur peut retrouver son document sans connaître son emplacement physique sur le disque.

Le fichier devient une interface commune

Concrètement, pour le système, un fichier ordinaire contient une suite d’octets, les unités dans lesquelles les données sont enregistrées. Un texte et un programme exécutable peuvent figurer dans le même répertoire : chacun est accessible par un chemin, mais son contenu doit être interprété par les outils appropriés. Un éditeur, un compilateur ou un outil de calcul peut donc employer son propre format. Les permissions règlent les droits de lecture, d’écriture et d’exécution, selon le propriétaire, le groupe et les autres utilisateurs.

Quand les périphériques deviennent aussi des fichiers

De plus, UNIX étend ce mode d’accès à des périphériques grâce à des fichiers spéciaux. L’expression « tout est fichier » résume cet effort d’unification : plusieurs sortes d’entrées et de sorties utilisent des opérations communes. Elle a toutefois ses limites. Un périphérique n’est pas un fichier ordinaire enregistré sur disque, et tous les objets du système n’acceptent pas les mêmes opérations.

Une fois une entrée ou une sortie ouverte, le programme la désigne par un numéro : son descripteur de fichier. Trois numéros ont un rôle conventionnel : 0 pour l’entrée standard, 1 pour la sortie standard et 2 pour les messages d’erreur. Une commande peut donc lire ses données sur son entrée standard et écrire son résultat sur sa sortie standard, sans choisir elle-même leur provenance et leur destination. Cette propriété sera essentielle pour relier les outils. Définitions de POSIX.

Lancer un programme : séparer création et exécution

Les fichiers conservent les programmes et leurs données ; les processus leur donnent une activité. Un programme est un ensemble d’instructions enregistré. Un processus est une instance de ce programme en cours d’exécution, avec sa mémoire et ses ressources. UNIX distingue deux opérations : créer un processus, puis lui faire exécuter le programme voulu.

fork crée un processus enfant à partir du processus qui l’appelle, dit parent. L’enfant hérite notamment des descripteurs de fichiers du parent : ces numéros renvoient aux mêmes fichiers ouverts. Il peut ainsi conserver les connexions d’entrée et de sortie déjà établies.

Une fonction de la famille exec remplace ensuite le programme exécuté dans le processus qui l’appelle. Le processus conserve son identité, mais son code et ses données sont remplacés par ceux du programme demandé. exec ne crée donc pas, à lui seul, un processus supplémentaire.

Pour lancer une commande externe ordinaire, le shell peut créer un enfant avec fork, préparer ses entrées-sorties, puis lui faire exécuter la commande avec exec. Le shell parent attend sa fin ou poursuit son travail, selon la demande de l’utilisateur.

Cette séparation explique aussi pourquoi cd, la commande qui change de répertoire, est intégrée au shell. Le changement doit concerner le shell dans lequel l’utilisateur continuera à travailler. S’il était effectué seulement par un enfant, le répertoire du parent resterait inchangé.

Le shell peut également organiser le travail de plusieurs programmes. Dans le panel Unix50 des Bell Labs, en 2019, les anciens membres de l’équipe reviennent sur la complémentarité des processus, des fichiers hiérarchiques et de la communication par pipes. Les fichiers fournissent des données, les processus exécutent les traitements, et les pipes permettent de passer de l’un à l’autre.

Les pipes : construire un traitement en reliant des outils

Cette idée de liaison précède UNIX. Dès 1964, Doug McIlroy propose de faire subir aux données plusieurs transformations successives en raccordant des programmes. Son mémo emploie l’image de morceaux de tuyau d’arrosage que l’on assemble.

Le pipe, littéralement « tuyau », relie la sortie d’un processus à l’entrée d’un autre. Ritchie situe son introduction dans UNIX en 1972 ; les documents réunis par la Unix Heritage Society en attestent la présence au plus tard en janvier 1973. La notation évolue ensuite vers le caractère |, qui rend cette liaison immédiatement visible dans une commande.

Une commande prévue pour lire une entrée et produire une sortie peut alors participer à un traitement plus vaste sans connaître les autres étapes. Une suite de commandes ainsi reliées forme un pipeline. Dans le shell décrit par le manuel de la septième édition, chacune s’exécute dans un processus distinct.

Un exemple que l’on peut essayer aujourd’hui

Supposons qu’un fichier machines.txt contienne cette petite liste, avec éventuellement des lignes vides :

DEC
IBM
DEC
Honeywell
DEC
IBM

Pour compter les occurrences de chaque nom et classer les résultats par fréquence, on peut écrire :

grep -v '^$' machines.txt | sort | uniq -c | sort -nr

grep -v '^$' retire les lignes vides : le motif décrit une ligne sans caractère, et l’option -v inverse la sélection. Description de grep.

Le premier sort regroupe les noms identiques. uniq -c compte alors les répétitions consécutives. Cette étape de tri est nécessaire : uniq compare les lignes adjacentes, sans rechercher chaque doublon dans l’ensemble du fichier. Description d’uniq.

Le dernier sort -nr classe les comptes par valeur numérique décroissante : -n demande un tri numérique et -r inverse l’ordre. Manuel de Coreutils : sort. Le résultat, à l’espacement près, est :

3 DEC
2 IBM
1 Honeywell

Les quatre étapes du traitement. Cet exemple utilise des commandes disponibles aujourd’hui pour illustrer une méthode issue d’UNIX.

L’utilisateur compose ici un traitement sans écrire un programme spécialement consacré à cet inventaire. Il peut examiner une étape, la remplacer ou en ajouter une autre. La notation reste courte parce que les outils partagent des conventions d’entrée et de sortie.

Une pratique devenue une philosophie

L’avant-propos du numéro spécial du Bell System Technical Journal de 1978 expose cette manière de travailler. McIlroy, Pinson et Tague recommandent notamment de donner aux programmes une fonction bien définie, de préparer leurs sorties pour d’autres programmes, d’essayer rapidement les réalisations et de construire des outils pour faciliter le travail.

Les transformations de texte se prêtent particulièrement bien à cette pratique, à condition que les outils s’accordent sur les formats échangés. Dans notre exemple, chacun reçoit et produit des lignes de texte : cette convention permet leur coopération. La simplicité de la liaison repose donc sur des choix précis dans la conception des programmes.

1973 : le C ouvre la voie à la portabilité

La coopération des outils rend UNIX plus utile, mais son développement reste lié à la machine qui l’exécute. Les premières versions sont écrites en assembleur, un langage étroitement dépendant des instructions du processeur. Passer du PDP-7 au PDP-11 exige donc de reprendre du logiciel. L’évolution des langages BCPL, B, puis C va réduire cette dépendance.

De B au langage C

Ritchie enrichit B et développe un compilateur, le programme qui traduit le code du langage en instructions exécutables par la machine. Les types permettent de distinguer différentes sortes de données ; les structures regroupent plusieurs informations dans un même ensemble. Leur développement dans le C permet progressivement de décrire les données dont UNIX a besoin. Le système et le langage progressent ainsi ensemble.

Dans son entretien ACM–CHM, Thompson explique une difficulté matérielle qui pousse à cette évolution. B raisonne en mots, les unités de données manipulées par la machine, alors que le PDP-11 permet aussi d’accéder à des octets individuellement. Distinguer ces unités dans le langage aide à exploiter les possibilités du processeur. Les types répondent donc à un problème pratique de programmation.

Cependant, une tentative de réécriture rencontre encore des difficultés en 1972. Durant l’été 1973, le travail aboutit : la majeure partie du noyau est réécrite en C. Les éléments qui dépendent directement de la machine demandent toujours un traitement particulier.

UNIX peut changer de machine

Dès lors, la conséquence est considérable : pour adapter le système à une autre architecture, on peut conserver une grande partie de son code. Il reste à disposer d’un compilateur approprié et à traiter les dépendances matérielles. Le portage sur l’Interdata 8/32, mené aux Bell Labs en 1977–1978, démontre cette possibilité et révèle les obstacles : tailles des données, hypothèses implicites et interfaces à adapter. Johnson et Ritchie donnent à la portabilité un sens concret : déplacer un programme avec bien moins de travail qu’une réécriture complète.

L’article consacré au langage C développe les choix du langage. Pour UNIX, cette transformation élargit les possibilités de diffusion. Encore faut-il que d’autres puissent découvrir le système, l’obtenir et l’étudier.

Les universités font d’UNIX un terrain d’apprentissage

Cette diffusion commence avant les portages de la fin des années 1970. Ritchie et Thompson présentent le système à une conférence en octobre 1973, puis publient sa description dans les Communications of the ACM en juillet 1974. Les lecteurs découvrent ses interfaces et ses utilisations, de la recherche aux documents et aux opérations du réseau téléphonique.

Les étudiants peuvent étudier le code source

Dans ce contexte, la circulation du code source, le texte des programmes que les développeurs peuvent lire et modifier, favorise aussi l’adoption universitaire. Les étudiants et les chercheurs peuvent observer la réalisation des mécanismes du système, puis expérimenter leurs propres changements. Les manuels les accompagnent : leurs sections documentent séparément les commandes, les appels système et les autres composants.

UNIX devient un véritable atelier de programmation

Parallèlement, les éditions successives enrichissent cet environnement. Le manuel de la sixième édition est daté de mai 1975. La septième édition, en 1979, comprend notamment le shell de Stephen Bourne. Ses boucles, ses conditions et ses variables permettent d’écrire des suites d’instructions : on peut répéter un traitement sur plusieurs fichiers ou décider d’une action selon un résultat. En enregistrant ces instructions dans un fichier, l’utilisateur se fabrique un outil réutilisable, un script shell, adapté à son travail.

UNIX offre aussi un atelier pour produire des documents et construire d’autres logiciels. Dans la documentation de la septième édition, nroff et troff assurent la mise en forme des textes ; eqn prépare les formules mathématiques et tbl les tableaux. Pour les développeurs, lex et yacc aident à construire les parties d’un compilateur qui reconnaissent les éléments d’un langage et leur organisation. Cette collection d’outils prolonge les premiers usages documentaires et donne aux utilisateurs les moyens de créer leurs propres traitements.

Cependant, l’accès au système reste encadré par des licences. Un contrat universitaire de décembre 1974, conservé par Ritchie, réserve l’usage aux activités éducatives et académiques et impose des restrictions de divulgation hors de l’établissement. Les bénéficiaires peuvent étudier le source dans les conditions prévues ; ils ne disposent pas des libertés générales de redistribution associées aux logiciels libres. Cette question des droits prendra une place croissante dans la suite de l’histoire.

Dans ce cadre, les universités deviennent des lieux de développement. Berkeley va donner à cette appropriation une ampleur particulière.

Berkeley : d’une distribution d’outils à une branche d’UNIX

À l’université de Californie à Berkeley, UNIX arrive en 1974. Les améliorations locales, auxquelles contribuent notamment Bill Joy et Chuck Haley, donnent naissance aux Berkeley Software Distributions, ou BSD. Au départ, ces distributions sont des ensembles d’outils ajoutés à UNIX. Les travaux s’étendent ensuite à des composants du système lui-même.

Une étape passe par UNIX/32V, le portage sur VAX réalisé aux Bell Labs par John Reiser et Tom London. Berkeley reprend cette base et lui ajoute la gestion de la mémoire virtuelle, qui permet de dépasser la limite imposée à un processus par la seule mémoire physique disponible. Ces travaux contribuent à 3BSD, diffusé en 1979.

Le soutien de la DARPA accompagne la suite du développement. Avec 4.2BSD, publié en 1983, les améliorations du système de fichiers et du réseau renforcent l’intérêt de cette branche. Les développements TCP/IP, qui permettent la communication entre machines selon ces protocoles, bénéficient notamment des contributions de BBN.

L’histoire de Berkeley montre comment les usages transforment le système : les besoins des machines en réseau poussent à ajouter de nouveaux services. Cette capacité d’adaptation intéresse également les constructeurs, qui développent leurs propres versions d’UNIX.

Variantes commerciales et recherche d’un langage commun

Le développement commercial multiplie les variantes : System V chez AT&T, mais aussi SunOS, HP-UX ou AIX chez différents constructeurs. Les entreprises adaptent UNIX à leurs machines et à leurs marchés. Les branches échangent des fonctionnalités : System V Release 4, en 1989, réunit des apports de plusieurs traditions. UNIX devient une famille dont les membres partagent des origines et des idées, tout en évoluant différemment.

Cependant, cette diversité complique le travail des développeurs. Une application peut employer une fonction ou une option disponible sur un système et absente sur un autre. Le langage C aide à changer de processeur ; il faut aussi s’entendre sur les services que le système fournit aux programmes.

POSIX et la Single UNIX Specification répondent à ce besoin en définissant des interfaces et des comportements communs. La publication de POSIX.1 en 1988 marque un jalon de cette normalisation. Les spécifications fixent ce qu’une application peut attendre du système, tout en laissant aux développeurs le choix de son organisation interne.

Enfin, le nom UNIX possède aussi un sens formel : c’est une marque gérée par The Open Group. Un programme de certification permet aux produits qui satisfont aux exigences applicables d’obtenir le droit de l’utiliser. Descendre du code historique et être certifié UNIX sont donc deux propriétés distinctes. Cette distinction aide à comprendre les héritages qui se développent parallèlement aux variantes commerciales.

BSD, GNU, Linux et macOS : plusieurs formes d’héritage

GNU : reconstruire un environnement compatible avec UNIX

Pendant que les variantes commerciales se développent, d’autres projets reprennent le modèle UNIX en changeant les conditions de partage du logiciel. Dès septembre 1983, Richard Stallman annonce GNU, un projet de système compatible avec UNIX qui vise à garantir les libertés d’utilisation, d’étude, de modification et de redistribution.

Par ailleurs, dans sa conférence à l’UCSD en 2007, Stallman donne aussi une raison technique à ce choix : construire le système prendra des années, pendant lesquelles les architectures pourront changer. Un modèle portable doit limiter le risque d’obsolescence avant l’achèvement du projet. UNIX représente alors, explique-t-il, le système portable ayant réussi qu’il connaît. La qualité technique du modèle compte ainsi dans la naissance du projet libre.

Linux : un nouveau noyau dans la tradition UNIX

Linus Torvalds commence Linux en 1991. Le noyau est une nouvelle réalisation conçue dans la tradition UNIX ; sa documentation indique qu’il vise la compatibilité avec POSIX et la Single UNIX Specification. Un noyau ne suffit pas à constituer tout l’environnement de travail : les systèmes qui l’emploient réunissent également des bibliothèques, des outils et d’autres composants, dont ceux de GNU dans de nombreuses distributions.

BSD poursuit sa propre branche

De son côté, la branche BSD suit une autre voie : ses communautés travaillent à produire une base redistribuable issue de leur histoire avec UNIX. Après le règlement du conflit entre USL et Berkeley en 1994, FreeBSD doit notamment intégrer la nouvelle base 4.4BSD-Lite. Les systèmes BSD poursuivent ensuite leurs développements.

macOS conserve un héritage UNIX

Enfin, cet héritage atteint aussi les ordinateurs d’Apple. Darwin, le socle système sous les couches graphiques d’OS X, devenu macOS, associe notamment des technologies Mach et BSD. Certains produits macOS figurent au registre des systèmes certifiés UNIX, pour des versions et des configurations déterminées. Une interface graphique familière peut ainsi recouvrir un système qui conserve cet héritage.

L’héritage d’UNIX se décrit donc selon plusieurs critères, qui peuvent se combiner :

Notion	Ce qu’elle décrit	Exemple
Filiation historique	Une histoire de développements et de code issus de l’UNIX original	La branche BSD
Inspiration et compatibilité	Des mécanismes et interfaces proches, pouvant être réimplémentés	Le noyau Linux
Certification UNIX	La conformité vérifiée d’un produit aux exigences d’un programme	Certaines versions et configurations de macOS
Licence libre	Les droits accordés pour utiliser, étudier, modifier et redistribuer	Les logiciels GNU et les BSD libres, selon leurs licences

Repères chronologiques

Date	Événement
1969	Débuts du système sur PDP-7 aux Bell Labs
1970	Adoption du nom UNIX ; acquisition du PDP-11
1971	Premier manuel, daté du 3 novembre ; utilisation pour les documents du service des brevets
1972–début 1973	Introduction des pipes, attestés au plus tard en janvier 1973
1973	Réécriture majeure du noyau en C ; présentation publique à une conférence
1974	Publication dans les Communications of the ACM ; installation à Berkeley
1975	Sixième édition d’UNIX, dont le manuel est daté de mai
1977–1978	Portage du système sur Interdata 8/32 aux Bell Labs
1979	Septième édition d’UNIX, comprenant le shell de Bourne
1983	System V, 4.2BSD et annonce de GNU
1988	Publication de POSIX.1
1991	Débuts de Linux
1994	Règlement du conflit USL–Berkeley ; diffusion de 4.4BSD-Lite
1995	Lancement du programme de marque UNIX 95

Ce qu’UNIX a rendu durable

Le parcours d’UNIX éclaire la durée de certaines idées informatiques. Relier des commandes conserve son intérêt lorsque les machines changent ; définir des interfaces communes permet de reprendre une manière de travailler dans des réalisations différentes. Les mécanismes initiaux ont évolué, mais ils ont donné aux développeurs des points d’appui pour construire et échanger leurs outils.

Cette continuité doit beaucoup aux personnes qui se sont approprié le système. Les chercheurs des Bell Labs, les utilisateurs du service des brevets, les équipes universitaires, les constructeurs et les communautés du logiciel libre lui ont donné des usages et des directions que le PDP-7 de 1969 ne pouvait pas contenir à lui seul. UNIX reste ainsi un exemple de création technique dont la portée grandit avec les possibilités qu’elle ouvre à ses utilisateurs.

Pour poursuivre sur le site

• Multics : les ambitions du projet auquel les Bell Labs avaient participé.
• CTSS : une étape majeure de l’informatique en temps partagé.
• TOPS-10 : une autre tradition de systèmes interactifs chez DEC.
• Le langage C : le langage qui accompagne la transformation d’UNIX.
• Dennis Ritchie : le parcours d’un de ses principaux concepteurs.

Sources pour aller plus loin

• Stephen R. Bourne, Le système UNIX, chapitre 1 : une présentation de l’histoire et de l’environnement de travail par le concepteur du shell de Bourne. Le panorama des outils éclaire les usages de l’époque ; les indications sur les versions disponibles et le nombre d’installations doivent être replacées dans ce contexte.
• Dennis M. Ritchie, The Evolution of the Unix Time-sharing System : récit présenté en 1979 et repris en 1984, particulièrement utile pour les débuts du système et l’évolution de ses idées. Texte conservé par les Bell Labs.
• Dennis M. Ritchie et Ken Thompson, The UNIX Time-Sharing System : description des fichiers, des processus et des usages, publiée en juillet 1974 puis révisée en 1978. Article de 1974, version de 1978.
• Ken Thompson, UNIX Implementation, 1978 : présentation du fonctionnement du noyau. Texte de l’article.
• Stephen C. Johnson et Dennis M. Ritchie, Portability of C Programs and the UNIX System, 1978 : une explication précise des objectifs et des difficultés de portage. Texte de l’article.
• Marshall Kirk McKusick, Twenty Years of Berkeley Unix, 1999 : le parcours de BSD raconté par un de ses développeurs. Chapitre publié par O’Reilly.
• Entretiens et conférences des acteurs : le panel des Bell Labs de 2019, l’entretien ACM–CHM de Ken Thompson et la conférence UCSD de Stallman complètent les publications écrites par des souvenirs personnels. Unix50 — The Origin of Unix, entretien de Thompson, conférence de Stallman.