Répertoire /usr sous Linux : l'effet papillon d'un incident matériel il y a 50 ans

Le répertoire /usr sous Linux n’est pas l’abréviation de User ?

L’effet papillon d’un « incident matériel » il y a 50 ans

En utilisant Linux ou Unix, vous avez sûrement déjà pensé à ceci.

« Qu’est‑ce que /usr représente exactement ? »

À première vue, on dirait que c’est juste User sans le e. Mais si c’était le cas, pourquoi ne pas l’appeler /user ? Pourquoi garder /usr ?

• Un raccourci pour taper ?
• Une contrainte de longueur de nom ?
• Pourtant, des répertoires de quatre lettres comme /boot, /home, /proc existent sans problème.

Si c’était vraiment « user », on aurait écrit /user. Le fait que nous utilisions le terme ambigu /usr cache une histoire que nous ignorons.

Aujourd’hui, nous allons plonger dans le répertoire /usr et découvrir l’histoire « mélancolique » de 50 ans qui a conduit à cette confusion.

1. Conclusion : le /usr actuel n’est pas « User »

Dans le standard de système de fichiers Linux (FHS, Filesystem Hierarchy Standard), /usr est défini comme :

Une zone contenant, de façon (généralement) en lecture seule, des programmes, des bibliothèques et des données partagées utilisées à l’échelle du système.

C’est pourquoi la structure que nous voyons est la suivante.

• /usr/bin – la plupart des exécutables destinés aux utilisateurs
• /usr/sbin – les exécutables destinés à l’administration système
• /usr/lib* – les bibliothèques utilisées par ces exécutables
• /usr/share – les données indépendantes de l’architecture (manuels, icônes, locales, etc.)

Il est clair que cela n’a rien à voir avec les fichiers personnels de l’utilisateur. Les répertoires personnels (~/…), documents, photos, etc. se trouvent tous sous /home.

Ainsi, du point de vue actuel, on peut résumer /usr en une phrase :

/usr = « un entrepôt de ressources système et d’applications partagées »

Mais une question subsiste.

« usr n’était‑t‑il pas initialement l’abréviation de user ? »

C’est là que l’histoire devient intéressante. À l’origine, il s’agissait bien de user. Mais au fil des 50 ans, son usage a complètement changé.

2. Les débuts d’Unix : /usr/nom_utilisateur était le répertoire personnel

Revenons aux débuts d’Unix, dans les années 1970.

À cette époque :

• Le répertoire personnel d’un utilisateur n’était pas /home/alice comme aujourd’hui
• Il se trouvait directement sous /usr, par exemple /usr/alice.

En d’autres termes, le /usr d’antan était vraiment :

« un répertoire où étaient rangées les choses liées à l’utilisateur »

Les ordinateurs de l’époque, comme le PDP‑11, disposaient de disques d’une capacité très limitée. On parlait alors de « quelques dizaines de kilo-octets ou de méga-octets ».

• Le disque racine (/) – un espace étroit contenant uniquement les fichiers essentiels du système
• Le deuxième disque (/usr) – un espace plus généreux, destiné à héberger les répertoires personnels

Cette structure était logique. Le problème était… Unix (et ses développeurs) a rapidement grandi.

3. « Le disque est plein » → on pousse les fichiers système dans /usr

Unix a continué d’évoluer, ajoutant de nouvelles commandes et fonctionnalités. Le problème : la capacité du disque racine (/) restait inchangée.

Finalement, un jour, la situation suivante se produit.

« Il n’y a plus d’espace sur / pour les programmes… »

Les développeurs ont alors pris une décision pragmatique.

« Le deuxième disque (/usr) est assez spacieux, alors on déplace les programmes qui ne sont pas essentiels au démarrage vers là-bas. »

Ainsi, le /usr qui était à l’origine le répertoire personnel a lentement commencé à recevoir des programmes, des bibliothèques et des données.

Le résultat est la structure que nous connaissons aujourd’hui.

• /bin – les commandes indispensables au démarrage (initialement sur le disque racine)
• /usr/bin – les autres commandes (déplacées sur le deuxième disque)
• La même logique s’applique à /lib vs /usr/lib

En résumé :

Le /usr qui était un « habitat utilisateur » a reçu, par manque d’espace, des fichiers système, comme un déménagement improvisé.

C’est exactement ce qu’on appelle une « solution de contournement due à la pénurie d’espace disque ».

Depuis, Unix a continué d’évoluer :

• Les répertoires personnels ont migré vers des emplacements plus intuitifs comme /home
• Le /usr est devenu un entrepôt partagé pour programmes et bibliothèques.

À ce stade, l’histoire devient assez amusante.

• Nom : usr (user)
• Contenu réel : fichiers système et applications

Le propriétaire a déménagé, mais le logement est maintenant rempli uniquement de fichiers système.

4. « Unix System Resources » ? C’est une interprétation post‑hoc

Cette situation contradictoire a duré longtemps, jusqu’à ce que quelqu’un commence à dire :

« Oui, maintenant /usr est l’abréviation de Unix System Resources. »

Vous avez peut‑être vu cette phrase dans un document. Mais il y a un point important.

C’est une explication post‑hoc (backronym), pas la signification officielle de l’époque.

Les documents et témoignages d’Unix montrent que :

• /usr était initialement l’abréviation de user
• Il servait à héberger les répertoires personnels
• En raison de la pénurie d’espace, il a évolué vers un répertoire contenant des programmes, des bibliothèques, etc.

Avec le temps, les gens ont simplifié la réalité en disant :

« Comme c’est maintenant un espace de ressources système, on l’appelle Unix System Resources. »

Ce phénomène est appelé backronym : on prend un acronyme existant et on lui donne une nouvelle signification.

C’est un phénomène fréquent dans le monde du développement.

• Un nom ou une structure temporaire
• Il est documenté
• Il devient standard
• Plus tard, on explique que c’était « initialement » une autre chose

5. L’héritage de 50 ans : l’histoire de l’Usr Merge

À ce stade, on peut se demander :

« Pourquoi garder /bin et /usr/bin séparés alors que le disque est assez grand ? »

Les distributions Linux modernes (Ubuntu, Fedora, Debian, etc.) travaillent à nettoyer cet héritage historique. Ce processus s’appelle /usr merge (UsrMerge).

Essayez d’exécuter la commande suivante sur une distribution récente :

$ ls -l /
lrwxrwxrwx 1 root root    7  ...  bin  -> usr/bin
lrwxrwxrwx 1 root root    7  ...  sbin -> usr/sbin
lrwxrwxrwx 1 root root    7  ...  lib  -> usr/lib

Vous verrez probablement ces liens symboliques.

• /bin n’est pas un répertoire réel mais un lien vers /usr/bin
• Le même principe s’applique à /sbin et /lib

En d’autres termes, la structure actuelle est en train de revenir à :

« La plupart des programmes et bibliothèques se trouvent tout sous /usr »

Pourquoi fusionner ? Plusieurs raisons :

• Simplification de la gestion des paquets et du portage
• Facilité de traitement des conteneurs et des images (on peut considérer /usr comme une « image système »)
• Pas besoin de maintenir la séparation imposée par les contraintes matérielles d’antan

Ce point est intéressant : tout a commencé par une décision prise en 1970 :

« Le disque était trop petit, alors on a déplacé les programmes dans /usr. »

C’est un exemple parfait de « il n’y a rien de permanent ».

6. Comment comprendre /usr aujourd’hui ?

Lorsque vous travaillez sur un système Linux, gardez à l’esprit :

« C’est l’endroit où se trouvent les programmes, bibliothèques et données partagées utilisés par le système »

À l’inverse :

• Fichiers personnels / paramètres → /home/mon_compte
• Données fréquemment modifiées (logs, cache, bases de données, etc.) → /var
• Applications installées manuellement (pas via le gestionnaire de paquets) → généralement sous /opt ou /usr/local ([Ask Ubuntu][1])

En résumé :

• /usr = le monde du système et des applications
• /home = le monde personnel de l’utilisateur

Cette distinction rend les choses beaucoup plus claires.

Conclusion : un compromis de développeur encapsulé dans un nom de répertoire

Le répertoire /usr contient :

• Les réalités pratiques des développeurs Unix d’antan confrontés à la pénurie d’espace
• Le compromis temporaire (« on fait ça maintenant, on réorganis plus tard »)
• Et, des décennies plus tard, la normalisation et la réorganisation (UsrMerge)

Au lieu de simplement retenir :

• « /usr = Unix System Resources »
• « /usr n’est pas un répertoire utilisateur »

Connaître cette histoire rend l’expérience de travailler avec /usr/bin, /usr/lib un peu plus enrichissante.

« Ah, c’est le résultat d’une décision prise il y a 50 ans quand le disque était plein ! »

Même un simple répertoire sur un écran noir porte l’héritage des limites matérielles et des compromis des développeurs. C’est assez fascinant, non ?