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

88

Quelle est la raison d’être des "ressources système unix" ou du répertoire /usr , comme décrit dans ici , ce qui duplique plusieurs des noms de répertoires sous le répertoire racine / ?

Mon objectif: j'installe Oracle JDK pour la énième fois et décide cette fois-ci de le mettre sous /home/user et je ne fais que lire un peu pour voir si c'est une mauvaise idée sur une machine mono-utilisateur .

    
posée H2ONaCl 02.05.2012 - 18:46
la source

1 réponse

133

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

Version courte:

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 / sauf /bin et /lib , mais, à l'origine, avec un objectif différent: /bin, /lib est uniquement pour les fichiers binaires et les bibliothèques requis pour démarrer , tandis que /usr/bin, /usr/lib est pour tous 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" 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 y a un fort mouvement vers la fusion de /usr/bin et de /bin , donc probablement dans un avenir proche (Ubuntu 12.10 peut-être?)% Co_de% sera un lien symbolique vers /bin .

Mais peut-être que vous confondez /usr/bin et /usr ? Car oui, il y a (et devrait être) un lot de noms de répertoires dupliqués. Plus à ce sujet plus tard ...

Version longue:

Dans les années 70, sous Unix (oui, Unix, bien avant Linux), les disquettes avaient peu d’espace (pas de HD, rappelez-vous?), et à un moment donné, les binaires du système ils ne correspondraient pas à un seul disque, et les développeurs devaient les séparer sur plusieurs supports et créer ainsi de nouveaux points de montage pour eux. Le système de fichiers /usr/local était plein, ils ont donc installé les nouveaux fichiers binaires à ... /bin . Et /usr/bin était, à cette époque, leur répertoire ... utilisateur !

Après la séparation (presque embarrassante et souvent racontée comme une blague / une histoire), ils ont commencé à créer des justifications (et critères) "artificielles" pour décider ce qui irait à /usr et ce qui irait à /bin . La règle informelle était la suivante: les choses "essentielles" vont à /usr/bin , "le reste" va à /bin . Même avec /usr/bin . Il ne fallut pas longtemps avant que /lib devienne encombré de répertoires liés au système, mélangés à des répertoires d'utilisateurs. Ainsi, /usr est né pour garder tous les répertoires liés à l'utilisateur et pour que /home reste propre pour les "choses" du système uniquement.

C'était bien avant que FHS existe. Quand il a été créé, il embrassait (et formalisait) la tradition actuelle et gardait le nom /usr , bien qu'à ce moment-là, cela n'avait plus rien à voir avec "l'utilisateur". Donc oui, les noms de fantaisie " U NIX s ource r epository" ou " U NIX s ystem r esources "sont des noms composés, et il est trop tard pour le renommer. (mais pas trop tard pour y fusionner /usr )

"Ok, qu'en est-il de /bin ?" , vous demandez. Bon sang, j'espérais que tu avais oublié. Ok ... /usr/sbin est pour les commandes qui ne peuvent être (ou ne sont significatives que lorsque) exécutées que par l'utilisateur /usr/sbin , comme root et mount .

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

"Attendez, alors pourquoi il y a aussi un /bin ? Cela n'a aucun sens!" . Eh bien, c'est à cause de ... euh .. humm ..

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

Ok, j'espère que vous avez été assez distrait. Aller de l'avant ...

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

Plus d'informations sur la requête pour la fusion / , depuis /usr docs:

  

La justification historique pour un / bin, / sbin et / lib distinct de / usr ne s'applique plus aujourd'hui. Ils ont été séparés pour avoir sélectionné des outils sur un disque dur plus rapide (ce qui était petit, car cela coûtait plus cher) et contenir tous les outils nécessaires pour monter la partition plus lente / usr. Aujourd'hui, une partition séparée / usr doit déjà être montée par les initramfs lors du démarrage initial, ce qui justifie la résolution des problèmes. En outre, de nombreux outils dans / bin et / sbin dans le statu quo ont déjà perdu la capacité d’exécuter sans pré-monté / usr. Il n’ya plus de raison valable pour que le système d’exploitation soit réparti sur plusieurs hiérarchies, il a perdu sa raison d’être.

Et une lecture étonnante sur le pourcentage de systemd et sa justification, par Rob Landley:

Comprendre le partage bin, sbin, usr / bin, usr / sbin

De nos jours

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

  • /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 - des fichiers en lecture seule à l'échelle du système installés par l'administrateur local (généralement, vous). Et c'est pourquoi la plupart des noms de répertoire de /usr/local sont dupliqués ici.

  • /usr - une atrocité conçue pour les logiciels et autonomes en lecture seule du système. C'est-à-dire que les logiciels ne partageant pas leurs fichiers sur /opt , bin , lib , share comme le feraient des logiciels bien comportés.

  • include - contrepartie par utilisateur de ~/.local , c'est-à-dire: logiciel installé par (et pour) chaque utilisateur

  • /usr/local - la contrepartie par utilisateur de ~/.local/opt

Alors, où installer le logiciel?

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

  • S'agit-il d'un logiciel de répertoire unique entièrement autonome, comme Eclipse IDE et d'autres applications java téléchargées, et vous souhaitez qu'il soit disponible pour tous les utilisateurs? Ensuite, installez dans /opt

  • Comme ci-dessus, mais vous ne vous souciez pas des autres utilisateurs et je veux installer uniquement pour votre utilisateur? Ensuite, installez dans /opt

  • Ses fichiers sont répartis sur plusieurs répertoires, comme ~/.local/opt et bin , comme les logiciels traditionnels compilés et installés avec share , et devraient être disponibles pour tous les utilisateurs? Ensuite, installez dans ./configure && make && sudo make install

  • Comme ci-dessus, mais uniquement pour votre utilisateur? Ensuite, installez dans /usr/local

  • Logiciel installé par le système d’exploitation ou par l’intermédiaire de gestionnaires de packages (comme Software Center) et, surtout, sur lequel toute modification locale pourrait être écrasée lorsque le gestionnaire de mises à jour le met à jour ? Il va à ~/.local

Remarques:

  • Ceci explique pourquoi le préfixe d’installation par défaut pour les logiciels compilés est /usr et pourquoi vous devez le remplacer par /usr/local lors de l’installation de logiciels 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 vous installez / supprimez des logiciels). Les fichiers accessibles en écriture (comme les fichiers de configuration) vont généralement à ./configure --prefix=$HOME/.local (pour les logiciels à l'échelle du système) et /etc (pour les paramètres par utilisateur). Bien que de nombreux logiciels anciens (et, malheureusement, certains logiciels modernes) utilisent ~/.config , encombrent votre dossier de départ avec des milliards de répertoires et de fichiers.

  • ~/.<software-name> et ~/.local ne font pas partie de la spécification FHS. FHS ne traite pas du dossier de base de l'utilisateur. Ils sont une tentative de XDG, une autre organisation standard orientée vers les environnements de bureau (comme Gnome, KDE et Unity), pour tenter de définir certaines conventions concernant la structure de la maison de l'utilisateur. Tous les logiciels ne s'y conforment pas (par exemple, ~/.config n'est pas dans la valeur par défaut de l'utilisateur ~/.local/bin , alors que la logique le devrait), et aucun utilisateur n'est obligé de le suivre, mais tous deux gagnent beaucoup les avantages de l'interopérabilité s'ils le font.

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

(et j'espère aussi que les puristes ne me tueront pas pour un langage et une explication aussi informels. C'était intentionnel et il y a sûrement beaucoup d'inexactitudes, mais je crois que c'est un bon moyen de faire un nouveau venu a une brève vue d'ensemble de la compréhension des justifications des répertoires d'installation)

    
réponse donnée MestreLion 11.05.2012 - 22:49
la source

Lire d'autres questions sur les étiquettes