Quelle est la raison d'être des "ressources système Unix", ou du /usr
répertoire, comme décrit ici , qui dupliquent de nombreux noms de répertoires sous le répertoire racine /
?
Mon but: J'installe Oracle JDK pour la énième fois et j'ai décidé de le mettre sous /home/user
. Je lis juste un peu pour voir si c'est une mauvaise idée sur une machine à utilisateur unique.
filesystem
history-of-ubuntu
H2ONaCl
la source
la source
/usr
signifiait un répertoire "utilisateur" caché pendant tant d'années ...Réponses:
Il y a la version courte et la version longue de votre réponse ...
Version courte:
Comme votre lien déjà dit,
/usr
est 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/bin
et/lib
, mais, à l'origine, dans un but différent: il/bin, /lib
ne concerne que les fichiers binaires et les bibliothèques nécessaires au démarrage , alors/usr/bin, /usr/lib
que 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/bin
et/bin
, donc probablement dans un proche avenir (Ubuntu 12.10 peut-être?)/bin
Sera un lien symbolique vers/usr/bin
.Mais peut-être vous confondez
/usr
et/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.
/bin
systè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
/bin
et 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/usr
devienne encombré de répertoires liés au système, mélangés à des répertoires d’utilisateur. Ainsi/home
est née la tâche de garder tous les répertoires liés à l’utilisateur et de rester/usr
propres 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/sbin
est pour les commandes qui ne peuvent (ou n'ont de sens que lorsque) exécutées par l'root
utilisateur, commemount
etfdisk
."Mais n'est-ce pas presque pareil
/bin
?" . Oui, bien sûr, mais ..."Attends, alors pourquoi y en a-t-il
/sbin
aussi? Ç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
/usr
fusion , desystemd
docs:Et une lecture étonnante sur la
/usr
scission 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/usr
sont 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 surbin
,lib
,share
,include
comme 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
bin
etshare
, 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/.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 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.~/.local
et~/.config
ne 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/bin
n'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)
la source
$PATH
n'a aucune pertinence. L'attaquant peut même changer cela via~/.profile
, votre argument est donc sans objet.~/.local/bin
est aussi sécurisé (ou non sécurisé, si vous le souhaitez) que~/bin
, pratique courante dans la plupart des distributions. L'idée qu'un utilisateur ne devrait avoir aucun répertoire pour conserver et exécuter des scripts personnels$PATH
est absurde.~/bin
est aussi sûr que~/.profile
, et$PATH
ne me protège pas contre les logiciels malveillants que je gère (qui a l’autorisation d’écrire à mon domicile). Je ne connaissais pas ce fichier, je suis désolé. Merci pour la clarification, désolé pour mon commentaire précédent.