Quelle est la raison d'être du répertoire `/ usr`?

Question

Quelle est la raison d'être du répertoire "ressources système Unix", ou du répertoire /usr, comme décrit ici , qui duplique de nombreux noms de répertoires situés dans le répertoire racine /?

Mon objectif: J'installe Oracle JDK pour la énième fois et j'ai décidé de le placer sous /home/user et je lis un peu pour voir si c'est une mauvaise idée sur un ordinateur à utilisateur unique.

MestreLion · Accepted Answer

Il y a la version courte et la version longue de votre réponse ...

Version abrégée:

Comme votre lien l'a déjà dit, /usr est un emplacement pour les fichiers du système , en lecture seule . Donc, tous vos logiciels installés y vont. Il ne duplique aucun nom de / à l'exception de /bin et de /lib, mais, à l'origine, avec un objectif différent: /bin, /lib est uniquement destiné aux binaires et aux bibliothèques requis pour le démarrage , alors que /usr/bin, /usr/lib est utilisé pour tout. les autres exécutables et bibliothèques. (maintenant soyez un bon garçon et ne posez pas de questions sur /sbin, c'est la version courte après tout)

De nos jours, la distinction entre "requis pour le démarrage" et "non" a diminué, car la plupart des distributions modernes, y compris Ubuntu, ne peuvent pas démarrer correctement sans plusieurs fichiers de /usr. Et c’est pourquoi il ya un fort mouvement en faveur de la fusion de /usr/bin et de /bin, donc probablement dans un avenir proche (Ubuntu 12.10 peut-être?) /bin sera un lien symbolique vers /usr/bin.

Mais peut-être confondez-vous /usr et /usr/local? Parce que oui, il y a (et devrait être) un lot de noms de répertoires dupliqués. Plus sur cela plus tard ...

Version longue:

Dans les années 70, sous Unix (oui, Unix, bien avant Linux), les disquettes ne disposaient que de peu d’espace (pas de disque dur, rappelez-vous?), Et à un moment donné, le nombre et la taille des fichiers binaires du système devenaient trop importants. Un seul disque suffit pour permettre aux développeurs de les répartir sur plusieurs supports afin de leur créer de nouveaux points de montage. Le système de fichiers /bin étant saturé, ils ont installé les nouveaux fichiers binaires à ... /usr/bin. Et /usr était, à ce moment-là, leur ... répertoire utilisateur !

Après que la scission (presque gênante et souvent racontée comme une blague/tradition) a eu lieu, ils ont commencé à créer des justifications (artificielles) (et des critères) pour décider de ce qui irait à /bin et de ce qui irait à /usr/bin. La règle informelle était: les choses "essentielles" vont à /bin, "le reste" va à /usr/bin. Idem avec /lib. /usr n'a pas tardé à se remplir de répertoires liés au système, mélangés à des répertoires utilisateur. Ainsi, /home est né, afin de conserver tous les répertoires liés à l'utilisateur et de garder /usr clean uniquement pour les "commandes" système.

C'était bien avant que FHS existe. Quand il a été créé, il a adopté (et officialisé) la tradition actuelle et conservé le nom /usr, bien qu’à ce moment-là cela n’ait plus rien à voir avec "utilisateur". Alors oui, les noms de fantaisie "U NIX s ource r epository "ou" U NIX s ystem r esources "sont des noms inventés, et il est trop tard pour le renommer de toute façon . (mais pas trop tard pour y fusionner /bin)

"Ok, qu'en est-il de /usr/sbin?" , demandez-vous. Bon sang, j'espérais que tu avais oublié. Ok ... /usr/sbin est destiné aux commandes qui ne peuvent être exécutées que par l'utilisateur root, ou qui n'ont de sens que lorsque, comme mount et fdisk.

"Mais n'est-ce pas presque la même chose que /bin?" . Oui, bien sûr, mais ...

"Attendez, alors pourquoi existe-t-il un /sbin également? Cela n'a aucun sens!" . Eh bien, c'est à cause de ... euh .. humm ..

Regardez, un singe à 3 têtes derrière vous!

Ok, espérons-le, vous êtes assez distrait. Passer à autre chose ...

(si vous pensez que je triche, oui, vous avez raison. Mais il en est de même pour les commandes "officielles" "de réponse" qui ne peuvent être exécutées que par root et doivent être disponibles avant même de monter / "). La vérité est que: la ligne est en effet floue et il y a beaucoup de noms hérités qui "restent collés" et il est maintenant assez difficile de s'en débarrasser.

Plus sur le cas pour la fusion /usr , à partir de systemd docs:

La justification historique de/bin,/sbin et/lib séparés de/usr ne s'applique plus aujourd'hui. Ils ont été séparés pour avoir sélectionné les outils sur un disque dur plus rapide (ce qui était petit, parce que c’était plus cher) et pour contenir tous les outils nécessaires au montage de la partition/usr plus lente. Aujourd’hui, une initialisation distincte doit déjà être montée par initramfs lors de l’amorçage, ce qui justifie la création d’une unité divisée. En outre, de nombreux outils dans/bin et/sbin dans le statu quo ont déjà perdu la capacité de fonctionner sans/usr pré-monté. Il n'y a plus aucune raison valable pour avoir le système d'exploitation réparti sur plusieurs hiérarchies, il a perdu sa raison d'être.

Et une lecture étonnante sur la scission /usr et sa raison d'être, par Rob Landley:

Comprendre les fichiers bin, sbin, usr/bin, usr/sbin split

De nos jours

Actuellement, en ce qui concerne les répertoires d'installation, la meilleure façon de comprendre est de penser de cette façon:

/usr - tous les fichiers en lecture seule installés à l’échelle du système et installés par (ou fournis par) le système d’exploitation
/usr/local - fichiers en lecture seule installés à l’échelle du système et installés par l’administrateur local (généralement vous). Et c’est pourquoi la plupart des noms de répertoire de /usr sont dupliqués ici.
/opt - une atrocité destinée aux logiciels en lecture seule et autonomes à l'échelle du système. C'est-à-dire que les logiciels qui ne divisent pas leurs fichiers en bin, lib, share, include comme le devraient les logiciels bien comportés.
~/.local - la contrepartie par utilisateur de /usr/local, c'est-à-dire: logiciel installé par (et pour) chaque utilisateur
~/.local/opt - l'homologue par utilisateur de /opt

Où installer le logiciel?

La liste ci-dessus constitue déjà la moitié de la réponse à votre question sur le JDK Oracle, du moins, elle donne plusieurs indices. La liste de contrôle pour "Où devrais-je installer le logiciel X?" passe par:

S'agit-il d'un logiciel d'annuaire unique entièrement autonome, comme Eclipse IDE et d'autres applications téléchargées Java, et vous souhaitez qu'il soit disponible pour tous les utilisateurs? Puis installez dans /opt
Comme ci-dessus, mais vous ne vous souciez pas des autres utilisateurs et je veux installer pour votre seul utilisateur? Puis installez dans ~/.local/opt
Ses fichiers sont répartis sur plusieurs répertoires, tels que bin et share, comme un logiciel traditionnel compilé et installé avec ./configure && make && Sudo make install, et devraient être disponibles pour tous les utilisateurs? Puis installez dans /usr/local
Comme ci-dessus, mais uniquement pour votre utilisateur? Puis installez dans ~/.local
Logiciels installés par le système d'exploitation ou via des gestionnaires de packages (tels que Software Center) et, surtout, , quelles modifications locales peuvent être écrasées lorsque le gestionnaire de mise à jour les met à niveau vers une nouvelle version ? Il va à /usr

Notes:

Cela explique pourquoi le préfixe d'installation par défaut des logiciels compilés est /usr/local et pourquoi vous devez le changer en ./configure --prefix=$HOME/.local lors de l'installation du logiciel pour votre propre utilisateur uniquement.
Vous avez peut-être remarqué que tous les répertoires ci-dessus sont en lecture seule (sauf, bien sûr, lorsque installer/supprimer des logiciels). Les fichiers accessibles en écriture (tels que les fichiers de configuration) se trouvent généralement dans les codes /etc (pour les logiciels système) et ~/.config (pour les paramètres par utilisateur). Bien que de nombreux logiciels hérités (et malheureusement aussi des logiciels modernes) utilisent ~/.<software-name>, encombrent votre dossier de départ avec des milliards de fichiers de répertoire et de répertoires.
~/.local et ~/.config ne font pas partie de la spécification FHS. FHS ne traite pas le dossier personnel de l'utilisateur. C’est une tentative de XDG, une autre organisation standard axée sur les environnements de bureau (tels que Gnome, KDE et Unity), pour tenter de définir des conventions concernant la structure du domicile de l’utilisateur. Tous les logiciels n’y adhèrent pas (par exemple, ~/.local/bin ne figure pas dans le code par défaut de l’utilisateur $PATH, alors que la logique le devrait) , et aucun utilisateur n’est obligé de le suivre, mais les deux gagnent. nombreux avantages d'interopérabilité s'ils le font.

J'espère que cela aide à clarifier un peu les choses. N'hésitez pas à demander n'importe quoi pour que je puisse améliorer la réponse!

(et j'espère aussi que les puristes ne me tueront pas pour un langage et des explications extrêmement informels. C'était intentionnel et il y a sûrement de nombreuses inexactitudes, mais je le fais Je pense que c’est un bon moyen de donner à un nouvel arrivant un bref aperçu de la compréhension des bases d’installation des répertoires)