Linux 0.01 a 35 ans : la première version invitait surtout à lire

Le 17 septembre 1991, Linux 0.01 faisait son entrée dans l’histoire informatique. Trente-cinq ans plus tard, sa promesse mérite d’être relue : examiner un noyau inachevé, comprendre ses limites et rendre la suite possible.

Avant les distributions faciles à installer, il y a un ordinateur précis sur lequel un développeur fait fonctionner son expérience. Ailleurs, un lecteur récupère les sources et tente de préparer sa propre machine. Entre ces deux situations, tout un travail reste à accomplir. La première publication de Linux avait l’intérêt de le dire franchement.

Elle donnait accès à une construction que d’autres pouvaient étudier. Pour cet anniversaire inscrit au calendrier geek, la bonne question n’est donc pas seulement de savoir ce que Linux savait déjà faire. Il faut aussi comprendre ce que signifiait publier un système dont le premier public était composé de lecteurs susceptibles de devenir contributeurs.

Trois dates, trois étapes différentes

Le 25 août, le 17 septembre et le 5 octobre 1991 ne désignent pas le même événement. En août, Linus Torvalds sollicitait des avis dans le groupe de discussion consacré à MINIX. Septembre correspond à la première diffusion des sources, la version 0.01. En octobre, une nouvelle annonce publique présentait un système devenu plus exploitable. Réunir ces dates en un lancement unique efface le passage de l’annonce à l’objet que d’autres peuvent examiner.

L’entrée d’archive de Linux 0.01 porte la date du 17 septembre 1991. Elle indique également une importation dans Git en 2007. Cette seconde date explique la nature du document : le dépôt conserve un événement ancien, il ne témoigne pas d’une utilisation de Git en 1991.

Dans son récit de 1992 réunissant les premiers messages, Torvalds se souvenait d’une sortie vers la mi-septembre. Une datation archivistique et un souvenir approximatif apportent deux éclairages différents. L’anniversaire d’aujourd’hui concerne la diffusion du code, et non la première mention publique du projet.

Ce que contenait réellement cette première livraison

Les notes originales de Linux 0.01 décrivent un noyau destiné aux ordinateurs AT à processeur 386. Il fallait adapter la configuration et compiler les sources. Un écran VGA ou EGA, un contrôleur de disque compatible et même une disposition finlandaise du clavier inscrite dans le code faisaient partie des hypothèses de départ. Torvalds signalait avoir obtenu un noyau fonctionnel sur deux machines.

Ces détails mesurent l’écart entre une expérience réussie et un produit reproductible. Le matériel de l’auteur constitue un cas concret ; il ne représente pas tous les ordinateurs des lecteurs. La prise en charge des périphériques, la préparation des fichiers et la qualité des instructions sont autant de problèmes distincts. Un numéro de version ne les résout pas à lui seul.

Le noyau gère les ressources et sert d’intermédiaire entre les programmes et le matériel. Pour disposer d’un environnement utilisable, il faut aussi des bibliothèques, des outils et des applications. Les notes distinguent ces éléments et citent les logiciels GNU parmi les outils importants. Imaginer 0.01 comme une distribution actuelle réduite à quelques fichiers serait donc trompeur.

Pourquoi MINIX était nécessaire sans fournir son code

Les notes affirment à la fois que Linux ne contient pas de code MINIX et que MINIX est nécessaire pour amorcer son utilisation. La contradiction disparaît lorsqu’on sépare l’implémentation de l’environnement qui permet de la préparer. Un logiciel peut être construit sur un autre système sans reprendre le code de ce dernier.

On peut emprunter un établi pour fabriquer un appareil sans fabriquer cet appareil avec le bois de l’établi. Pour Linux, l’environnement existant permettait de préparer les fichiers et de réaliser la construction. La compatibilité avec le système de fichiers MINIX facilitait aussi l’accès aux données depuis les deux environnements.

Cette distinction reste utile lorsqu’un projet se dit indépendant. Parle-t-on de son code source, de ses outils de compilation, de son installation ou de son entretien à long terme ? Ces questions ne reçoivent pas forcément la même réponse. La première publication pouvait rendre un nouveau noyau accessible sans supprimer immédiatement toutes ses dépendances pratiques.

Linux 0.01 fonctionnait-il vraiment ?

Les documents résistent à une réponse trop nette. Les notes contemporaines évoquent deux machines sur lesquelles le noyau fonctionne, tout en présentant la version principalement comme un texte à lire. Dans son retour ultérieur sur cette période, Torvalds décrit les sources de 0.01 comme n’étant pas réellement exécutables. Il faut conserver les deux formulations.

La conclusion solide est plus modeste : il s’agissait d’une publication de sources soumise à de fortes contraintes, pas d’une installation fiable pour n’importe quel lecteur. Les documents seuls ne permettent pas de préciser les préparatifs, adaptations locales ou attentes qui expliqueraient entièrement cet écart. Compléter l’histoire avec une explication imaginée n’aiderait personne.

En revanche, le contraste enseigne une distinction précieuse. « Cela fonctionne chez l’auteur », « l’archive se compile » et « une autre personne reproduit le résultat » sont trois affirmations différentes. Une documentation utile indique laquelle a été vérifiée. La réussite future d’un projet ne dispense pas de lire ses débuts avec cette précision.

La portabilité ne faisait pas partie du paquet initial

Le premier Linux exploitait les caractéristiques du 386. Les notes reconnaissaient que ce choix compliquait le portage vers d’autres architectures. Elles expliquaient aussi que le noyau, le système de fichiers et la gestion de mémoire partageaient un même espace de code et de données pendant l’exécution : un trait de son organisation monolithique.

Tout ce qui limitait le système n’était donc pas une simple fonction manquante. Certaines limites venaient de choix destinés à faire fonctionner un ordinateur réel. Étendre ensuite le projet supposait de repérer et de revoir les hypothèses liées à cette machine. Commencer par un cas concret peut être fécond sans constituer déjà une solution universelle.

Notre article sur Dennis Ritchie, C et la portabilité d’Unix éclaire cette différence. Écrire une grande partie d’un système en C ne supprime pas automatiquement sa dépendance à un processeur. Le langage facilite certaines adaptations ; les décisions d’architecture peuvent néanmoins rester très spécifiques.

Le passage à la GPL constitue une autre étape

Il serait également inexact de projeter toute l’histoire de la licence sur septembre 1991. Les conditions de 0.01 imposaient la disponibilité des sources et la conservation des mentions de droits d’auteur. Elles interdisaient aussi de faire payer la distribution, même pour couvrir des frais de traitement. Ce n’était pas encore le régime GPL associé ensuite à Linux.

Dans les notes de Linux 0.12, Torvalds proposait de supprimer cette restriction pour adopter les conditions du copyleft GNU. Il laissait aux contributeurs la possibilité de s’y opposer et indiquait le 1er février comme date d’effet prévue. Dans le contexte du début de 1992, cela décrit un jalon postérieur à la première publication.

La leçon historique est simple : diffuser du code et définir les possibilités de sa redistribution sont deux décisions. Les règles influencent la façon dont d’autres personnes participent. On peut reconnaître l’importance de 0.01 tout en montrant que le cadre de collaboration continuait lui aussi à se construire.

Fêter cet anniversaire en ouvrant les notes de version

Une lecture attentive suffit pour commencer. Repérez ce qui est annoncé comme fonctionnel, ce qui manque et ce qui dépend d’un matériel particulier. Comparez ensuite le document contemporain au souvenir de Torvalds. Cet exercice permet de distinguer une pièce d’archive du récit qui l’entoure, sans installer de logiciel ancien sur son ordinateur quotidien.

Linux 0.01 a rendu un travail visible alors que ses limites l’étaient encore. D’autres pouvaient commencer à le comprendre, à le discuter et à l’améliorer. Trente-cinq ans plus tard, cette ouverture reste le meilleur sujet d’anniversaire : une première version n’a pas besoin de contenir tout l’avenir pour permettre la prochaine étape.