Comprendre la séparation entre /bin, /usr/bin, /usr/local/bin...

Je me suis souvent posé la question de "pourquoi les binaires sous linux sont envoyés dans différents dossiers, /bin, /usr/bin, etc… ?" (et idem pour les /lib vs /usr/lib). Et bien je viens de trouver la réponse grâce à ce post (en anglais) qui explique pourquoi cette séparation.

Et vu que je suis gentil, et que j’ai envie de faire un article sans trop me fatiguer, voici une magnifique traduction de ce post :

———————————————————————

Comprendre la séparation entre bin, sbin, usr/bin et usr/sbin (Rob Landley, 09/12/2010)

Réponse à la question de David Collier :

Je vois que busybox place ses liens dans ces quatre dossiers

Est-ce qu’il y a une règle simple qui définit dans quel dossier va chaque lien…

Par exemple, je vois kill dans /bin et killall dans /usr/bin… J’arrive pas a comprendre quelle serait la logique.

Vous savez quand Ken Thompson et Dennis Ritchie ont créé UNIX sur un PDP-7 en 1969 ? Et bien en 1971 ils l’ont remplacé par un PDP-11 avec une paire de disques RK05 (1.5 Mo chacun) pour le stockage.

Quand le système d’exploitation est devenu trop gros pour passer sur le premier disque RK05 (le système de fichier racine) ils l’ont laissé déborder sur le second, qui était celui où se trouvait les répertoires des utilisateurs (ce qui explique le nom /usr). Ils ont dupliqué les dossiers de l’OS ici (/bin, /sbin, /lib, /tmp…) et ont écrit les fichiers dans ces nouveaux dossiers parce que le premier disque était plein. Après, ils ont ajouté un troisième disque, ils l’ont monté sous /home, et y ont déplacé tous les répertoires des utilisateurs pour que l’OS puisse utiliser toute la place sur les deux premiers disques et grossir jusqu’a TROIS MEGAOCTETS (oooooh !)

Bien sûr ils ont fait des règles comme "quand le premier disque amorce, il doit avoir suffisamment pour pouvoir monter le deuxième disque sur /usr, donc ne mettez pas des chose comme la commande mount dans /usr/bin ou on aura un problème de la poule et de l’œuf en essayant de lancer le système." Plutôt évident. Et aussi plutôt spécifique à la v6 d’UNIX d’il y a 35 ans.

La séparation entre /bin et /usr/bin (et toutes les autres) est un reste de ça, un détail d’implémentation des années 70 qui a été traîné pendant des décennies par des bureaucrates qui ne se demandent jamais pourquoi ils font les choses. Ça n’avait plus de sens avant même l’invention de Linux pour plusieurs raisons :

La mise en place du système à l’amorçage est le domaine d’initrd et de l’initramfs, qui s’occupent des questions de "ce programme a besoin de celui-ci". On a déjà un système temporaire qui amorce le système principal. Les bibliothèques partagées (introduites par les gars de Berkeley) vous empêchent de mettre à jour indépendemment des morceaux de /lib et de /usr/bin. Les deux partitions doivent correspondre ou elles ne fonctionneront pas. Ce n’était pas le cas en 1974, à l’époque ils avaient une certaine indépendance vu que tout était lié statiquement. Les disques dur au détail pas cher ont dépassé les 100 Mo autour de 1990, et des logiciels de modifications de taille de partitions sont apparus à peu près au même moment (partition magic 3.0 distribué en 1997)

Bien sûr, une fois la séparation existante, certain ont défini des règles pour la justifier. La racine pour les trucs de l’OS communs à tous, et /usr pour les fichiers propres à la machine. Après, / pour les trucs qui venaient de AT&T et /usr pour les trucs ajoutés par votre distribution comme IBM AIX ou Dec Ultrix ou SGI Irix, et /usr/local pour les fichiers spécifiques à votre installation. Après, quelqu’un a décidé que /usr/local n’était pas un bon endroit pour installer de nouveaux paquets, alors ajoutons /opt ! J’attends toujours que /opt/local pointe le bout de son nez…

Forcément, à moisir pendant 30 ans, cette séparation a vu des règles intéressantes propres à chaque distribution apparaître et disparaître, comme "/tmp est nettoyé à chaque reboot, mais /usr/tmp ne l’est pas". (Bien sûr, sur Ubuntu /usr/tmp n’existe pas, et sur Gentoo /usr/tmp est un lien symbolique vers /var/tmp, qui a maintenant la règle du "pas nettoyé à chaque reboot". Oui, tous des tmpfs avant l’heure. C’est à cause de la racine en lecture seule, /usr serait toujours en lecture seule dans ce cas et /var est l’endroit où l’on peut écrire, / est principalement en lecture seule à l’exception des bits de /etc qu’ils ont essayé de déplacer dans /var, mais réellement les gens font plus souvent un lien symbolique de /etc vers /var/etc...)

Les bureaucraties classiques comme la Fondation Linux (qui a absorbé Groupe des Standards du Libre dans son conglomérat toujours plus gros il y a des années) documente joyeusement et en rajoute a ce genre de complexités dans jamais essayer de comprendre pourquoi c’était là à la base. "Ken et Dennis ont fait déborder leur OS dans l’équivalent du home parce qu’un disque RK05 du PDP-11 faisait trop petit" leur passe loin au dessus de la tête.

Je suis presque sûr que l’installation de busybox met ces binaires là ou les versions historiques de ces binaires se trouvent. Il n’y a plus de vraie RAISON pour ça aujourd’hui. Personnellement, je fais un lien symbolique de /bin, /sbin et /lib vers leurs équivalents dans /usr pour les systèmes que je mets en place. Les gars qui bossent dans l’embarqué essayent de comprendre et de simplifier.

———————————————————————

J’ai trouvé l’explication super intéressante vu que je connaissais absolument pas. Mais c’est vrai que je me pose plus trop la question puisque Archlinux a fusionné le tout dans les /usr depuis le 3 juin dernier. Et je peux vous dire que j’ai sacrément serré les fesses au moment du déplacement !