Histoire d’Unix et Linux : de 1969 à aujourd’hui

L’histoire d’Unix et de Linux, en bref

L’histoire d’Unix et de Linux est un long conflit sur la question de savoir qui peut détenir le code source. Unix a été créé aux Bell Labs en 1969. Linux a été créé à Helsinki en 1991 et ne contient aucun code source original d’Unix. Ce qui est passé de l’un à l’autre, c’est une conception et un ensemble d’interfaces documentées : fichiers, processus, pipes et shell permettant d’assembler de petits programmes. Unix s’est diffusé dans les universités au cours des années 1970, car un accord antitrust conclu en 1956 interdisait à AT&T (American Telephone and Telegraph) de vendre des logiciels. Bell Labs a donc concédé le code source sous licence à bas prix. Unix s’est retrouvé partout sans appartenir à personne en dehors d’AT&T, et les conflits de licences qui ont suivi ont déterminé quel système libre de type Unix finirait sur vos serveurs.

1969 : un PDP-7 réformé et les idées qui ont perduré

Bell Labs s’est retiré du projet Multics en 1969. Multics (multiplexed information and computing service) était un grand système en temps partagé développé avec le MIT et General Electric. Les Labs ont décidé qu’il était trop ambitieux pour être terminé. Ken Thompson a conservé les idées qui lui plaisaient et a abandonné les autres. Il a écrit un petit système en temps partagé sur un mini-ordinateur PDP-7 réformé. Dennis Ritchie l’a rejoint. Le nom Unix était une plaisanterie aux dépens de Multics.

En 1970, le système a été transféré sur un PDP-11 acheté par les Labs pour les opératrices de saisie du service des brevets, car il était plus facile de financer un outil de traitement de texte qu’un système d’exploitation. Cette machine disposait de 24 KB de mémoire centrale, répartis entre le système et les programmes utilisateur. Cette circonstance budgétaire explique pourquoi le premier manuel Unix, daté de novembre 1971, était constitué de documents formatés. Elle explique aussi pourquoi vous tapez encore man 5 crontab. Les numéros de section de ce manuel sont ceux de votre manuel.

Deux changements ont rendu cette conception durable. Les pipes sont apparus dans la Version 3 en 1973, parce que Doug McIlroy soutenait depuis des années qu’il devait être possible de relier les programmes bout à bout. Thompson a ajouté l’opérateur | afin que la sortie d’un programme devienne l’entrée du suivant. Ensuite, la Version 4, publiée plus tard en 1973, a été réécrite en C. Un système d’exploitation écrit dans un langage portable peut être porté sur du matériel pour lequel il n’a pas été conçu. C’est pourquoi Unix a survécu à toutes les machines sur lesquelles il a commencé.

Pourquoi Unix s’est diffusé : AT&T n’avait pas le droit de le vendre

Un consent decree de 1956 a réglé une procédure antitrust contre AT&T. AT&T a conservé son monopole téléphonique, mais a accepté une restriction en contrepartie : l’entreprise devait rester en dehors des activités autres que les télécommunications. Les logiciels faisaient partie de ces activités. Lorsque les universités ont demandé Unix, Bell Labs ne pouvait donc pas le vendre comme un produit. Le laboratoire en a concédé la licence du code source pour une somme symbolique, sans support ni garantie.

L’effet a été considérable, et ce n’était pas ce qu’AT&T avait prévu. La Sixth Edition d’Unix, released en 1975, est arrivée dans des centaines de départements d’informatique avec son code source complet. John Lions, de l’University of New South Wales, a imprimé le code source du kernel avec un commentaire ligne par ligne et l’a utilisé pour son enseignement. Toute une génération a appris le fonctionnement d’un système d’exploitation en en lisant un véritable.

La licence a ensuite changé. La licence de la Seventh Edition, en 1979, interdisait d’utiliser le code source en cours. Le commentaire de Lions a donc circulé sous forme de photocopies de photocopies. Toute l’histoire tient dans cette situation. Unix était partout et non libre en même temps. Chaque amélioration apportée par quelqu’un améliorait donc le code propriétaire de quelqu’un d’autre.

Berkeley : les composants d’Unix que vous utilisez réellement

Ken Thompson a passé l’année universitaire 1975 à 1976 à l’University of California, Berkeley, puis y a laissé un groupe Unix très actif. Le Computer Systems Research Group (CSRG) de Berkeley distribuait des bandes contenant des améliorations locales. Ces bandes sont devenues BSD, la Berkeley Software Distribution. Bill Joy a écrit une grande partie des premiers travaux : 1BSD en 1978, puis 2BSD en 1979, qui intégrait l’éditeur vi et le C shell.

Le C shell est à l’origine de !! et !$. Bash a repris cette syntaxe. C’est pourquoi l’expansion de l’historique de bash surprend encore les utilisateurs qui tapent un point d’exclamation entre guillemets doubles plus de quarante ans plus tard.

La DARPA (l’agence américaine Defense Advanced Research Projects Agency) a ensuite financé Berkeley pour intégrer les nouveaux protocoles Internet à Unix. 4.2BSD, publié en août 1983, intégrait TCP/IP (transmission control protocol over internet protocol) et l’interface de programmation d’application socket. Chaque service réseau de votre serveur appelle encore socket(), bind(), listen() et accept() dans cet ordre, car Berkeley a choisi ces noms en 1983.

Un détail a déterminé la décennie suivante. Une bande BSD ne constituait pas un système complet. Elle regroupait des ajouts à l’Unix d’AT&T, et il fallait disposer d’une licence valide sur les sources d’AT&T pour l’utiliser légalement. Berkeley a remplacé les composants d’AT&T par son propre code sur plusieurs années, fichier par fichier. La question de savoir si ce remplacement était réellement complet a ensuite été portée devant les tribunaux.

1984 : la scission, puis les guerres Unix

Le Bell System a été démantelé le 1 janvier 1984. Le consent decree qui empêchait AT&T d’exercer une activité logicielle a disparu avec lui. AT&T pouvait désormais vendre Unix comme un produit, et c’est ce qu’il a fait. Les licences commerciales d’accès au code source sont devenues coûteuses. Unix a donc cessé d’être le système peu coûteux qu’une université distribuait à ses étudiants.

Les éditeurs l’avaient déjà dérivé. Chaque constructeur de stations de travail fournissait son propre Unix avec son propre matériel. À la fin des années 1980, un programme écrit pour une plateforme devait donc être porté sur la suivante. En 1988, le secteur s’est divisé en deux camps autour des standards : l’Open Software Foundation d’un côté et Unix International de l’autre. Pendant des années, ils ont fourni des systèmes incompatibles tout en débattant pour déterminer lequel était le véritable Unix.

POSIX (portable operating system interface) est né de cette situation. La norme IEEE 1003.1 a été publiée en 1988. Elle définissait ce qu’un système de type Unix devait faire : les system calls, le comportement du shell, les utilitaires standard et les interfaces de la bibliothèque C. C’est plus important qu’il n’y paraît, car une norme est une spécification et aucune licence ne la couvre. Trois ans plus tard, un étudiant a écrit un kernel à partir de ces documents.

Minix et le vide qu’il a laissé

Andrew Tanenbaum a publié Minix en 1987 comme système pédagogique pour son manuel sur les systèmes d’exploitation. Minix était un petit système de type Unix. Le code source était fourni avec le livre et le système fonctionnait sur les PC bon marché que les étudiants possédaient réellement. Sa lecture dans le cadre d’un cours était légale, contrairement à la Seventh Edition Unix.

Minix est resté volontairement limité, car il devait pouvoir être expliqué dans un livre. Tanenbaum a refusé des patches qui auraient pu en faire un système de production. Sa licence n’était pas libre non plus : il fallait acheter le livre, et vous ne pouviez pas décider vous-même de redistribuer votre version modifiée de Minix. En 1991, un étudiant pouvait donc lire le code d’un kernel fonctionnel de type Unix, mais ne pouvait rien construire de durable à partir de celui-ci.

GNU avait tout sauf un kernel

Richard Stallman a annoncé le projet GNU en septembre 1983, avec pour objectif de créer un système complet, libre et compatible avec Unix. En 1991, GNU avait produit la plupart des composants qui entourent un kernel : le compilateur GCC, la bibliothèque C GNU, les utilitaires binaires et bash, le shell écrit par Brian Fox en 1989, celui dans lequel votre serveur vous ouvre encore une session. Le kernel GNU, Hurd, restait la pièce qui ne cessait d’être repoussée.

La GNU General Public License version 2 a été publiée en juin 1991. Sa règle est simple. Vous pouvez utiliser le code et le modifier. Si vous distribuez le résultat, vous devez en distribuer le code source selon les mêmes conditions. Cette règle devient le point central de cette histoire deux sections plus loin.

Août 1991 : le message publié sur comp.os.minix

Le 25 août 1991, un étudiant d’Helsinki a publié le message suivant dans le groupe Usenet comp.os.minix :

Hello everybody out there using minix -

I'm doing a (free) operating system (just a hobby, won't be big and
professional like gnu) for 386(486) AT clones.

La version 0.01 est sortie en septembre 1991. Elle ne partageait aucun code avec Unix ni avec Minix. Il s’agissait d’un nouveau kernel pour le 386, développé sur une machine Minix, écrit pour les interfaces POSIX et associé aux outils GNU déjà disponibles. En janvier 1992, Tanenbaum a expliqué à Torvalds qu’un kernel monolithique était une conception obsolète. Son argument sur la conception était fondé, mais Torvalds répondait à une autre question : qu’est-ce qui fonctionne correctement sur l’unique ordinateur bon marché dont dispose un étudiant ?

En février 1992, la version 0.12 a été placée sous licence GPL. Torvalds a depuis qualifié cette décision de meilleure décision de sa carrière. La licence originale de Linux interdisait toute transaction financière, ce qui aurait empêché les fournisseurs de CD et les sociétés de support apparus par la suite. La GPL autorisait les activités commerciales tout en imposant que chaque modification distribuée soit réintégrée dans le même arbre partagé.

Le procès : d’avril 1992 à février 1994

Berkeley a publié Networking Release 2 (Net/2) en juin 1991 : un système BSD presque complet, dont les fichiers dérivés d’AT&T avaient été retirés. Six fichiers du kernel manquaient. Bill et Lynne Jolitz ont écrit des remplacements et publié 386BSD 0.0 en mars 1992, puis 386BSD 0.1 le 14 juillet 1992. Il existait désormais un BSD libre, complet et mature pour le 386, alors que Linux était encore un kernel développé par passion. Berkeley Software Design, Inc. (BSDi) vendait une version commerciale avec support, BSD/386, et en faisait la publicité avec le numéro de téléphone 1-800-ITS-UNIX.

En avril 1992, Unix System Laboratories (USL), la filiale d’AT&T qui détenait alors Unix, a poursuivi BSDi devant un tribunal fédéral du New Jersey pour violation de secrets commerciaux et de la marque Unix. La plainte a ensuite été modifiée pour ajouter les Regents of the University of California. L’université a engagé une action reconventionnelle en Californie en 1993, en affirmant qu’AT&T avait livré du code Berkeley dans System V sans lui attribuer le crédit exigé par sa propre licence.

Le fondement juridique de l’affaire s’est désagrégé en 1993. Le juge Dickinson Debevoise a refusé à USL une injonction préliminaire. Il estimait probablement invalide la revendication de copyright d’USL sur l’ancien code 32V, car AT&T avait distribué ce code pendant des années sans notices de copyright. Novell a racheté USL à AT&T à la mi-1993, et sa direction voulait mettre fin au conflit. L’affaire a été réglée en février 1994. Sur environ 18,000 fichiers de la distribution Berkeley, trois ont été retirés et environ soixante-dix ont reçu des notices de copyright USL.

Berkeley a publié 4.4BSD-Lite en juin 1994. Cette version était juridiquement propre. FreeBSD et NetBSD, tous deux fondés en 1993 sur le code Net/2 contesté, ont alors dû reconstruire leurs systèmes sur cette nouvelle base, ce qui a pris la majeure partie du reste de 1994. Linux 1.0 a été publié en mars 1994, au milieu de cette reconstruction.

Pourquoi Linux s’est-il imposé sur les serveurs plutôt que BSD ?

Le procès est la réponse la plus souvent donnée, et il en explique effectivement une partie. Entre avril 1992 et février 1994, toute personne qui choisissait un Unix libre pour un produit devait mettre en balance une action en justice bien réelle engagée par les avocats d’AT&T et un kernel développé par un étudiant finlandais, contre lequel personne ne pouvait poursuivre l’utilisateur. C’était précisément la période où le Web est apparu et où les premières distributions Linux ont été publiées : Slackware en juillet 1993, Debian en août 1993, puis Red Hat et SUSE.

Quatre autres facteurs ont compté autant que le procès.

• Le matériel. Linux a ciblé le PC 386 standard dès sa première ligne de code, et c’est ce matériel qui est devenu bon marché. Le centre de gravité de BSD était le VAX et la workstation, tandis que le portage vers le 386 était réalisé par deux personnes extérieures au projet.
• La licence. La GPL impose à une entreprise qui publie un kernel modifié de publier ses changements. Le travail des éditeurs revenait donc dans un même arbre de code. La licence BSD permet à une entreprise de garder ses modifications privées, et les entreprises ne s’en sont pas privées.
• Le modèle de développement. Torvalds intégrait rapidement les patches envoyés par des inconnus et publiait constamment de nouvelles versions. 386BSD publiait assez lentement pour que ses propres utilisateurs le forkent deux fois en 1993, donnant naissance à NetBSD et FreeBSD, puis à nouveau en 1995 avec OpenBSD.
• L’effet d’entraînement. Les développeurs vont là où se trouvent déjà les autres développeurs, et les drivers sont écrits pour le système qui compte le plus d’utilisateurs.

Il faut répondre honnêtement à la question technique. En 1994, BSD était le système le plus abouti, avec une base cohérente, un historique documenté et du code réseau que Linux a mis des années à rattraper. Personne n’a choisi Linux en 1994 parce qu’il était meilleur. Les utilisateurs l’ont choisi parce qu’il était disponible, libre de contraintes juridiques, compatible avec le matériel qu’ils possédaient déjà et amélioré chaque semaine.

Ce que BSD a conservé et où il est utilisé aujourd’hui

BSD a continué d’évoluer. Ce qu’il a perdu, c’est sa position par défaut. La preuve la plus claire se trouve sur votre propre machine : le projet OpenBSD a créé OpenSSH en 1999, et celui-ci est le serveur SSH présent sur presque tous les systèmes Linux distribués aujourd’hui. C’est pourquoi les pratiques liées aux clés SSH qu’il vaut la peine d’apprendre sont identiques dans les deux familles.

Netflix diffuse ses vidéos depuis des appliances FreeBSD. Junos, le système d’exploitation des routeurs Juniper, repose sur FreeBSD. Le logiciel système de la PlayStation descend de FreeBSD. macOS et iOS d’Apple intègrent du code BSD dans le kernel et dans tout le userland. La licence permissive qui a privé BSD de l’arbre de code serveur commun a intégré du code BSD dans de nombreux équipements qui ne le mentionnent jamais.

Si vous faites un choix aujourd’hui, la question est pratique plutôt qu’historique. Comparer Linux et FreeBSD comme serveurs revient à examiner ZFS, les jails, l’arbre des ports et la quantité de logiciels tiers qui supposent l’utilisation de Linux. FreeBSD 15 comme serveur est un système actuel et maintenu, pas une pièce de musée. Et Linux face à Windows Server est une question distincte, dont la réponse dépend de votre stack applicative.

Le design de 1969 que vous utilisez aujourd’hui sur un VPS

Chacun de ces éléments est plus ancien que la plupart des personnes qui l’utilisent.

• Le pipe. who | wc -l compte les utilisateurs connectés, car la Version 3 d’Unix, en 1973, permettait à la sortie d’un programme de devenir l’entrée d’un autre programme.
• Les sections du manuel. man 1 ls et man 5 crontab utilisent le système de numérotation du manuel de novembre 1971.
• La séparation du système de fichiers. /usr existe parce que le disque racine de ce PDP-11 était arrivé à saturation en 1971 et que les développeurs avaient déplacé les fichiers vers le second pack de disques. Les distributions ont depuis annulé cette séparation : exécutez ls -ld /bin sur Ubuntu 24.04 ou Debian 13 et vous obtenez un lien symbolique vers usr/bin.
• Les appels de socket. Berkeley les a écrits pour 4.2BSD en 1983, et tous les daemons réseau les utilisent encore.
• POSIX. Un script #!/bin/sh écrit conformément à la norme s’exécute sans modification sur Linux, FreeBSD, macOS et Solaris, car cette norme est l’élément qu’ils ont tous implémenté.

Lorsque vous louez un serveur privé virtuel et que vous vous y connectez, vous saisissez des commandes dans une interface conçue pour une machine dotée de 24 KB de mémoire et d’un service des brevets. Elle a survécu parce que cette interface a été publiée, discutée, normalisée, puis réimplémentée entièrement par des personnes qui n’avaient jamais été autorisées à voir le code original.

FAQ

Le noyau Linux contient-il du code Unix original ?

Non. Linus Torvalds a écrit le noyau à partir de zéro à partir de 1991, en ciblant les interfaces POSIX plutôt qu’un quelconque code source d’AT&T. L’héritage Unix tient à la conception et à une interface publiée : fichiers, processus, pipes et noms des appels système. Les outils GNU autour du noyau ont également été écrits à partir de zéro, à partir de 1983. Cette indépendance explique pourquoi le contentieux d’AT&T sur le code BSD n’a jamais concerné Linux.

Quand le procès intenté par AT&T à BSD a-t-il eu lieu, et a-t-il tué BSD ?

USL, la filiale d’AT&T qui détenait Unix, a poursuivi BSDi en avril 1992, puis a ajouté l’Université de Californie aux défendeurs. En 1993, le juge a refusé une injonction préliminaire, estimant que la revendication de copyright concernant l’ancien code 32V était probablement invalide. Novell a racheté USL à la mi-1993 et a réglé l’affaire en février 1994 : trois fichiers sur environ 18,000 ont été supprimés et environ soixante-dix ont reçu de nouvelles mentions de copyright. Cela n’a pas tué BSD. Cela a gelé l’adoption de BSD pendant les deux années où le monde choisissait un Unix libre.

Pourquoi Linux a-t-il pris la place de BSD sur les serveurs ?

La sécurité juridique a joué un rôle : en 1992 et 1993, Linux ne faisait l’objet d’aucun procès, contrairement à BSD. Les autres facteurs étaient le 386 comme cible dès le premier jour, la GPL qui réintégrait les modifications des fournisseurs dans un arbre unique, et un processus de fusion suffisamment rapide pour maintenir l’intérêt des contributeurs, tandis que 386BSD se divisait en trois branches. La qualité technique n’a pas été le facteur décisif, car BSD était le système le plus abouti en 1994.

FreeBSD vaut-il encore la peine d’être utilisé aujourd’hui ?

Oui, pour des raisons concrètes : ZFS intégré au système de base, les jails comme modèle d’isolation mature, un système de base développé comme un ensemble cohérent et une documentation qui reste exacte. Le coût concerne la compatibilité, car la plupart des logiciels serveur tiers, des outils de gestion de conteneurs et du support des fournisseurs supposent Linux. Choisissez FreeBSD lorsque ses capacités de stockage et de réseau justifient ce coût, plutôt que par fidélité à l’ancienne lignée.