Il y a la version courte et la version longue de votre réponse ...
Version courte:
Comme votre lien déjà dit, /usrest un lieu pour l' ensemble du système , en lecture seule des fichiers. Donc, tous vos logiciels installés y vont. Il ne duplique pas les noms de /sauf /binet /lib, mais, à l'origine, dans un but différent: il /bin, /libne concerne que les fichiers binaires et les bibliothèques nécessaires au démarrage , alors /usr/bin, /usr/libque tous les autres exécutables et bibliothèques le sont. (maintenant soyez un bon garçon et ne posez pas de questions /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 /usr. Et c’est la raison pour laquelle il existe un fort mouvement en faveur de la fusion /usr/binet /bin, donc probablement dans un proche avenir (Ubuntu 12.10 peut-être?) /binSera un lien symbolique vers /usr/bin.
Mais peut-être vous confondez /usret /usr/local? Parce que oui, il y a (et devrait être) beaucoup 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 avaient 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. /binsystème de fichiers était pleine, ils les nouveaux fichiers binaires installé à ... /usr/bin. Et /usrétait, à cette époque, leur répertoire utilisateur !
Après la scission (presque gênante et souvent racontée sous forme de blague / histoire), ils ont commencé à créer des justifications (et des critères) "artificiels" pour décider de ce qui irait /binet de ce qui irait /usr/bin. La règle informelle était: les choses "essentielles" vont à /bin, "le reste" va à /usr/bin. Même avec /lib. Il n’a pas fallu longtemps pour que cela /usrdevienne encombré de répertoires liés au système, mélangés à des répertoires d’utilisateur. Ainsi /homeest née la tâche de garder tous les répertoires liés à l’utilisateur et de rester /usrpropres pour les "choses" système uniquement.
C'était bien avant que FHS existe. Quand il a été créé, il a adopté (et officialisé) la tradition actuelle et en a conservé le nom /usr, même si, à cette époque, cela n'avait plus rien à voir avec "utilisateur". Alors oui, les noms de fantaisie « U NIX s Ource r de epository » ou « U NIX s ystème r ESSOURCES » sont tous les noms confectionnés, et il est trop tard pour le renommer de toute façon. (mais pas trop tard pour le fusionner /bin)
"Ok, et à propos de quoi /usr/sbin?" , tu demandes. Bon sang, j'espérais que tu avais oublié. Ok ... /usr/sbinest pour les commandes qui ne peuvent (ou n'ont de sens que lorsque) exécutées par l' rootutilisateur, comme mountet fdisk.
"Mais n'est-ce pas presque pareil /bin?" . Oui, bien sûr, mais ...
"Attends, alors pourquoi y en a-t-il /sbinaussi? Ça 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 va de même pour les commandes essentielles "de réponse officielle" 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 qu'il y a beaucoup de noms hérités qui "restent collés" et qu'il est maintenant très difficile de s'en débarrasser.
Plus sur le cas pour la /usrfusion , de systemddocs:
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 /usrscission et sa raison d'être, par Rob Landley:
Comprendre les fichiers bin, sbin, usr / bin, usr / sbin
Aujourd'hui
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épertoires /usrsont dupliqués ici.
/opt- une atrocité destinée à des logiciels autonomes , en lecture seule et à l' échelle du système . C'est un logiciel qui ne divise pas leurs fichiers sur bin, lib, share, includecomme les logiciels bien comportés devrait.
~/.local- la contrepartie par utilisateur de /usr/local, c'est-à-dire: les logiciels installés par (et pour) chaque utilisateur
~/.local/opt - la contrepartie par utilisateur de /opt
Alors, où installer un 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 "Où dois-je installer le logiciel X?" passe par:
Est-ce un logiciel de répertoire unique, complètement autonome, comme Eclipse IDE et d'autres applications Java téléchargées, 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 répartis sur plusieurs répertoires, comme binet share, comme les logiciels traditionnels compilés et installés avec ./configure && make && sudo make install, 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, plus important encore, quelles modifications locales pourraient être écrasées lorsque le gestionnaire de mise à jour les met à niveau vers une nouvelle version ? Il va à/usr
Remarques:
Ceci explique pourquoi le préfixe d'installation par défaut pour les logiciels compilés est /usr/local, et pourquoi vous devriez le changer en ./configure --prefix=$HOME/.locallors 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 vous installez / supprimez des logiciels). Les fichiers accessibles en écriture (tels que les fichiers de configuration) sont généralement placés dans /etc(pour les logiciels système) et ~/.config(pour les paramètres par utilisateur). Bien que de nombreux logiciels hérités (et, malheureusement, certains modernes également) utilisent ~/.<software-name>, encombrent votre dossier de départ avec des milliards de répertoires et de fichiers.
~/.localet ~/.configne font pas partie de la spécification FHS. FHS ne traite pas le dossier personnel de l'utilisateur. Il s’agit d’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 certaines conventions concernant la structure du domicile de l’utilisateur. Tous les logiciels n'y adhèrent pas (par exemple, ce ~/.local/binn'est pas dans la configuration par défaut de l'utilisateur $PATH, alors que ce devrait être logique) , et aucun utilisateur n'est obligé de le suivre, mais les deux bénéficient de nombreux avantages en termes d'interopérabilité.
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 une explication aussi informels. C'était intentionnel, et il contient sûrement de nombreuses inexactitudes, mais je pense que c'est un bon moyen de donner à un nouvel arrivant un bref aperçu de l'installation répertoires rationnels)