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 les personnes autorisées à 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 d’origine d’Unix. Ce qui est passé de l’un à l’autre, c’est une conception et un ensemble d’interfaces publiées : fichiers, processus, pipes et shell permettant d’assembler de petits programmes. Unix s’est diffusé dans les universités dans les 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 préféré concéder le code source sous licence à faible coût. Unix s’est retrouvé partout tout en n’appartenant à personne en dehors d’AT&T. 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 de récupération 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 vaste système time-sharing développé avec le MIT et General Electric. Les Labs ont estimé qu’il était trop ambitieux pour être achevé. Ken Thompson a conservé les idées qui lui plaisaient et abandonné les autres. Il a écrit un petit système time-sharing sur un mini-ordinateur PDP-7 mis au rebut. Dennis Ritchie l’a rejoint. Le nom Unix était une plaisanterie aux dépens de Multics.

En 1970, le système a été porté sur un PDP-11 acheté par les Labs pour les dactylographes 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, partagée entre le système et les programmes utilisateur. Cet accident de financement explique pourquoi le premier manuel Unix, daté de novembre 1971, était un ensemble de documents mis en forme. Il explique aussi pourquoi vous tapez toujours man 5 crontab. Les numéros de section de ce manuel sont ceux du vôtre.

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 des programmes bout à bout. Thompson a alors 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 répandu : AT&T n’avait pas le droit de le vendre

Un accord transactionnel conclu en 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 à l’écart des activités autres que les télécommunications. Les logiciels faisaient partie de ces activités. Ainsi, lorsque les universités ont demandé Unix, Bell Labs ne pouvait pas le vendre comme un produit. Le laboratoire en a donc concédé le 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, publiée en 1975, a atteint 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, puis l’a utilisé pour son enseignement. Toute une génération a appris le fonctionnement d’un système d’exploitation en étudiant un système réel.

Puis la licence a changé. La licence de la Seventh Edition, publiée en 1979, interdisait l’utilisation du 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 présent partout tout en restant non libre, si bien que chaque amélioration apportée par quelqu’un améliorait le code propriétaire de quelqu’un d’autre.

Berkeley : les parties d’Unix que vous saisissez réellement

Ken Thompson a passé l’année universitaire 1975-1976 à l’Université de Californie à Berkeley, où il a laissé derrière lui 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, avec l’éditeur vi et le shell C.

Le shell C 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 saisissent un point d’exclamation entre guillemets doubles, plus de quarante ans après.

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, fournissait TCP/IP (transmission control protocol over internet protocol) ainsi que l’interface de programmation applicative des sockets. 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 AT&T pour l’exécuter légalement. Berkeley a remplacé les composants d’AT&T par son propre code pendant 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 : l’éclatement, puis les guerres Unix

Le Bell System fut démantelé le 1 janvier 1984, et le consent decree qui avait empêché AT&T d’entrer dans le secteur des logiciels disparut avec lui. AT&T pouvait désormais vendre Unix comme un produit, et c’est ce qu’il fit. Les licences commerciales donnant accès au code source devinrent coûteuses. Unix cessa donc d’être le système peu coûteux qu’une université fournissait à ses étudiants.

Les fournisseurs l’avaient déjà forké. Chaque fabricant de stations de travail livrait son propre Unix sur son propre matériel. À la fin des années 1980, un programme écrit pour un système devait donc être porté sur le suivant. En 1988, le secteur se divisa 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 livrèrent des systèmes incompatibles tout en débatant pour déterminer quel Unix était le véritable Unix.

POSIX (portable operating system interface) naquit de ce désordre. La norme IEEE 1003.1 fut publiée en 1988. Elle précisait 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 écrivit un kernel à partir de ces documents.

Minix et le vide qu’il a laissé

Andrew Tanenbaum a publié Minix en 1987 comme système d’enseignement 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 était autorisée en classe, ce qui n’était plus le cas avec Unix Seventh Edition.

Minix est volontairement resté limité, car il devait pouvoir être expliqué dans un livre. Tanenbaum a refusé des correctifs qui en auraient fait un système utilisable en production. La licence n’était pas libre non plus : il fallait acheter le livre, et la redistribution d’une version modifiée de Minix ne dépendait pas de votre seule décision. Ainsi, en 1991, un étudiant pouvait lire le code d’un kernel de type Unix fonctionnel, mais ne pouvait rien construire de durable dessus.

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 de type 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 et dans lequel votre serveur vous ouvre toujours une session. Le kernel GNU, Hurd, était la pièce qui continuait à manquer.

La version 2 de la GNU General Public License 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 deviendra le point central de cette histoire dans deux sections.

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 de code ni 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 architecture obsolète. Son argument de conception était fondé, mais Torvalds répondait à une autre question : qu’est-ce qui fonctionne correctement sur l’unique ordinateur bon marché que possède un étudiant ?

En février 1992, la version 0.12 a été placée sous licence GPL. Torvalds a depuis déclaré que c’était sa meilleure décision. La licence originale de Linux interdisait toute transaction financière, ce qui aurait empêché les vendeurs de CD et les sociétés de support qui sont apparus ensuite. 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 de code 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 gratuit, complet et mature pour le 386, alors que Linux n’était encore qu’un kernel développé comme projet personnel. Berkeley Software Design, Inc. (BSDi) vendait une version commerciale prise en charge, 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 possédait 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 inclure les Regents of the University of California. L’Université a engagé une action reconventionnelle en Californie en 1993, en faisant valoir qu’AT&T avait intégré du code Berkeley dans System V sans lui attribuer le crédit exigé par sa propre licence.

Le fond du litige s’est effondré en 1993. Le juge Dickinson Debevoise a refusé à USL une preliminary injunction. Selon lui, la revendication de copyright d’USL sur l’ancien code 32V était probablement invalide, car AT&T avait distribué ce code pendant des années sans mentions 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é supprimés et environ soixante-dix ont reçu des mentions 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 occupé la majeure partie du reste de 1994. Linux 1.0 a été publié en mars 1994, au milieu de cette reconstruction.

Pourquoi Linux a-t-il conquis les serveurs plutôt que BSD ?

Le procès est la réponse la plus souvent donnée, et il en fait effectivement partie. Entre avril 1992 et février 1994, toute personne qui choisissait un Unix libre pour un produit devait mettre en balance les poursuites engagées par les avocats d’AT&T et un kernel écrit par un étudiant finlandais, contre lequel personne ne pouvait engager de poursuites. C’était précisément la période où le Web est arrivé et où les premières distributions Linux sont apparues : Slackware en juillet 1993, Debian en août 1993, puis Red Hat et SUSE. Red Hat a transformé cette avance en standard commercial, et le parcours de Red Hat Linux à CentOS, puis à Rocky et AlmaLinux explique pourquoi une distribution fondée en 1993 détermine encore ce qui fonctionne sur un grand nombre de serveurs d’entreprise.

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

• Le matériel. Linux a ciblé le PC 386 standard dès ses premières lignes de code, et c’est ce matériel qui est devenu bon marché. Le centre de gravité de BSD était le VAX et les stations de travail, tandis que le portage vers le 386 était un effort externe mené par deux personnes.
• La licence. La GPL impose à une entreprise qui distribue un kernel modifié de publier ses modifications, ce qui a fait remonter les travaux des éditeurs 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 de contributeurs inconnus et publiait constamment. 386BSD publiait assez lentement pour que ses propres utilisateurs le forkent deux fois en 1993, donnant naissance à NetBSD et FreeBSD, puis de nouveau en OpenBSD en 1995.
• L’inertie. 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 être honnête sur la question technique. En 1994, BSD était le système le plus abouti, avec une base cohérente, un historique documenté et un 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 toute contrainte juridique, fonctionnait sur le matériel qu’ils possédaient déjà et progressait 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 bonnes pratiques liées aux clés SSH à 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 l’ensemble du userland. La licence permissive qui a privé BSD de l’arbre de code serveur commun a placé du code BSD dans une grande quantité de matériel qui ne le mentionne jamais.

Si vous devez choisir 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 Linux sous-jacent. FreeBSD 15 comme serveur est un système actuel et maintenu, pas une pièce de musée. Et Linux face à Windows Server constitue une question distincte, dont la réponse dépend de votre stack applicative.

La conception 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 Version 3 Unix permettait déjà, en 1973, de transformer la sortie d’un programme en entrée d’un autre.
• 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 plein en 1971. Les développeurs ont alors déplacé des fichiers sur 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 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 fonctionne sans modification sous Linux, FreeBSD, macOS et Solaris, car la norme est l’élément qu’ils ont tous implémenté.

Un héritage n’a pas survécu au passage : la séquence de boot en shell que Linux avait reprise de System V a maintenant disparu de presque toutes les distributions, et l’argument en faveur de son remplacement par systemd constitue le conflit le plus récent sur ce que devrait être un système de type Unix.

Lorsque vous louez un serveur privé virtuel et que vous vous 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, standardisée, puis réimplémentée entièrement par des personnes qui n’ont jamais été autorisées à voir le code d’origine.

FAQ

Linux contient-il du code Unix original ?

Non. Linus Torvalds a écrit le kernel from scratch à partir de 1991, en ciblant les interfaces POSIX plutôt qu’un quelconque code source d’AT&T. L’héritage Unix réside dans la conception et dans une interface publiée : fichiers, processus, pipes et noms des system calls. Les outils GNU autour du kernel ont également été écrits from scratch, à partir de 1983. Cette indépendance explique pourquoi le contentieux d’AT&T concernant le code BSD n’a jamais touché Linux.

Quand le procès d’AT&T contre 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 preliminary injunction, estimant que la demande fondée sur le copyright du code 32V historique é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. Le procès n’a pas tué BSD. Il a gelé son adoption pendant les deux années où le monde choisissait un Unix libre.

Pourquoi Linux a-t-il pris le dessus sur les serveurs plutôt que BSD ?

La certitude 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 merge assez rapide pour maintenir l’intérêt des contributeurs, tandis que 386BSD se divisait en trois branches. La supériorité 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 base system, les jails comme modèle d’isolation mature, un base system développé comme un ensemble cohérent, et une documentation qui reste fiable. Le coût est le travail de compatibilité, car la plupart des logiciels serveur tiers, des outils de conteneurs et du support des fournisseurs supposent Linux. Choisissez FreeBSD lorsque ses fonctions de stockage et de réseau justifient ce coût, plutôt que par fidélité à l’ancienne lignée.