Quel est l'avantage de la façon dont Linux organise les fichiers des programmes installés? [fermé]

Sous Windows, le lecteur système C:possède un répertoire program_files, sous lequel chaque programme a son propre répertoire.

Sous Linux, sous /usr/et /usr/local/, il y en a /bin, /etc, /share, /src, etc.

Ainsi, sous Windows, tous les fichiers de chaque programme sont regroupés dans le même répertoire, tandis que sous Linux, les fichiers du même type de tous les programmes le sont.

Je pense que la façon dont Windows organise les programmes installés est plus logique que la manière de Linux, et donc les programmes installés sont plus faciles à gérer manuellement.

Quel est l'avantage de la façon dont Linux organise les fichiers des programmes installés? Merci.

J'ai cette question lorsque j'ai le problème de comment organiser les programmes installés dans $ HOME pour que le shell les recherche lors de leur exécution? , où j'essaie d'organiser mes programmes à $HOMEla manière de Windows, mais j'ai du mal à spécifier les chemins de recherche des programmes.

Sous Linux, les différents emplacements, généralement bien entretenus, reflètent une certaine logique. Par exemple.:

• /bin contient les outils (programmes) les plus élémentaires
• /sbin contient les programmes d'administration les plus basiques

Les deux contiennent les commandes élémentaires utilisées par le démarrage et le dépannage fondamental. Et ici, vous voyez la première différence. Certains programmes ne sont pas destinés à être utilisés par des utilisateurs réguliers.

Ensuite, jetez un œil /usr/bin. Vous devriez trouver ici un plus grand choix de commandes (programmes), généralement plus de 1000 d'entre elles. Ce sont des outils standard, mais pas aussi essentiels que ceux de /binet /sbin.

/usr/bincontient les commandes, tandis que les fichiers de configuration résident ailleurs. Cela sépare à la fois les entités fonctionnelles (programmes) et leur configuration et d'autres fichiers, mais en termes de fonctionnalités utilisateur, cela est pratique, car le fait de ne pas mélanger les commandes avec quoi que ce soit d'autre permet la simple utilisation de la PATHvariable pointant vers les exécutables. Il introduit également la clarté. Tout ce qui est devrait être exécutable.

Jetez un oeil à mon PATH,

$ echo "$PATH" | perl -F: -anlE'$,="\n"; say @F'
/home/tomas/bin
/usr/local/bin
/usr/bin
/bin
/usr/local/games
/usr/games

Il y a exactement six emplacements contenant les commandes que je peux appeler directement (c'est-à-dire non pas par leurs chemins, mais par les noms de leurs exécutables).

• /home/tomas/bin est mon répertoire privé dans mon dossier personnel pour mes exécutables privés.
• /usr/local/bin J'expliquerai séparément ci-dessous.
• /usr/bin est décrit ci-dessus.
• /bin est également décrit ci-dessus.
• /usr/local/gamesest une combinaison de /usr/local(à expliquer ci-dessous) et de jeux
• /usr/gamessont des jeux. Ne pas mélanger avec les exécutables utilitaires, ils ont leurs emplacements séparés.

Maintenant /usr/local/bin. Celui-ci est quelque peu glissant et a déjà été expliqué ici: Qu'est-ce que / usr / local / bin? . Pour le comprendre, vous devez savoir que le dossier /usrpeut être partagé par de nombreuses machines et monté à partir d'un emplacement net. Les commandes ne sont pas nécessaires au démarrage, comme indiqué précédemment, contrairement à celles de /bin, donc l'emplacement peut être monté dans les étapes ultérieures du processus de démarrage. Il peut également être monté en lecture seule. /usr/local/bin, d'autre part, est destiné aux programmes installés localement et doit être accessible en écriture. Ainsi, alors que de nombreuses machines réseau peuvent partager le /usrrépertoire général , chacune d'elles aura sa propre version /usr/localmontée dans le commun /usr.

Enfin, jetez un œil à PATHmon utilisateur root:

# echo "$PATH" | perl -F: -anlE'$,="\n"; say @F'
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
/sbin
/bin

Il contient ceux-ci:

• /usr/local/sbin, qui contient les commandes d'administration du type /usr/local
• /usr/local/bin, qui sont les mêmes que ceux que l'utilisateur ordinaire peut utiliser. Encore une fois, leur type peut être décrit comme /usr/local.
• /usr/sbin sont les utilitaires d'administration non essentiels.
• /usr/bin sont l'administration non essentielle et les utilitaires utilisateur réguliers.
• /sbin sont les outils d'administration essentiels.
• /bin sont les outils essentiels de l'administrateur et de l'utilisateur régulier.

De nos jours, je pense que c'est un héritage historique de l'UNIX classique.

Dans les premières versions UNIX, les programmes n'étaient pas aussi volumineux qu'aujourd'hui. Les programmes consistaient souvent en un seul fichier exécutable utilisant des bibliothèques système. Donc, personne n'a pensé aux programmes qui seront constitués de quelques bibliothèques propres. La bibliothèque principale était la bibliothèque C et chaque programme connaissait son emplacement.

De plus, l'environnement UNIX était considéré comme un produit fini (pour la préparation de la documentation). Par conséquent, le chemin d'accès à tous les outils a été corrigé.

Certains avantages des chemins d'accès fixes en jours sur le disque dur (disque dur) sont présents de nos jours. Si FSH (File System Hierarchy) se divise sur des partitions de disque distinctes et place des partitions avec des binaires et des bibliothèques près des secteurs principaux du disque dur, le temps de démarrage du programme sera un peu plus rapide.

Ce que vous voyez comme un système moderne de type Unix n'est pas vraiment traditionnel.

Normalement, il y aurait assez minime /et les /usrhiérarchies avec les services publics seulement du système, et les programmes sont ensuite installés séparément dans un sous - répertoire /usr/local, puis mis à la disposition en créant des liens symboliques.

Une configuration très typique pour le logiciel GNU consistait à compiler et installer avec

./configure
make
make install prefix=/usr/local/DIR/program-1
cd /usr/local/DIR
stow program-1

L' utilitaire GNU stow crée des liens symboliques pour rendre le logiciel disponible sur le chemin standard, sans avoir à ajouter de répertoires à la variable PATH (comme le fait Windows, et la corruption a tendance à s'y accumuler).

Cependant, les distributions Linux modernes expédient tout sous forme de packages prêts à l'emploi, de sorte que les programmes font désormais partie du "système". Parce que le gestionnaire de packages s'occupe de l'installation, il n'y a pas besoin de liens symboliques, et la séparation des programmes ne sert à rien (mais ralentirait le démarrage du programme car de nombreux petits répertoires devraient être analysés).

Si vous souhaitez installer un logiciel dans votre répertoire personnel, je vous suggère d'utiliser également GNU stow pour cela - cela vous permettra de garder vos programmes séparés, ce qui est judicieux si vous n'utilisez pas de gestionnaire de paquets.

Ma configuration traditionnelle est un répertoire dans ~/software/DIRlequel j'installe des programmes, puis j'utilise stow inside DIRpour créer ~/software/bin, ~/software/shareetc. Cela signifie que je n'ai qu'à ajouter ~/software/binà la variable PATH pour obtenir tous mes logiciels installés.

Utilisation:

./configure --prefix=~/software
make
make install prefix=~/software/DIR/program-1
cd ~/software/DIR
stow program-1

à installer si le programme suit les conventions GNU.

Vous semblez parler du style de division des fichiers individuels par objectif ( /usr/binpour les exécutables, /usr/libpour les bibliothèques) plutôt que par package d'application (compilateur C ++ dans un répertoire, programmes d'édition d'images dans un autre). Alors que dans les systèmes Unix une grande partie de la raison de cet historique, il existe également des forces actuelles qui ont tendance à faire pencher les systèmes de type Unix vers cela: les gestionnaires de paquets qui gèrent la plupart des programmes sur un système.

Sous Windows, historiquement et encore assez aujourd'hui, les applications ont été chargées de fournir leur propre programme d'installation et, en particulier, le programme de désinstallation, et même aujourd'hui, elles ne s'enregistrent fréquemment dans aucune liste d'applications centrale. Dans une situation comme celle-ci, il est généralement préférable pour une application d'avoir son "propre" répertoire pour autant de ses fichiers que possible. Cela permet d'éviter les conflits avec d'autres applications, bien que cela ne fonctionne pas toujours (en particulier dans le cas des DLL ).

Les systèmes Unix, d'autre part, ont généralement depuis les années 90 chacun un seul gestionnaire de packages accepté et un groupe fournissant une grande quantité de logiciels couramment utilisés via ce gestionnaire de packages. (Les gestionnaires de paquets officiels pour divers Unices incluent yumet aptpour les systèmes Linux, pkgsrcpour NetBSD et portspour FreeBSD. Souvent, les systèmes Unix commerciaux se retrouvent également avec un gestionnaire de paquets non officiel mais largement accepté, comme brewpour MacOS.)

Ces gestionnaires de packages ont l'avantage de pouvoir suivre et de suivre tous les fichiers du système dans les différents sous-répertoires qu'ils "possèdent". Étant donné qu'un seul groupe attribue le nom et l'emplacement de chaque fichier ici, ils peuvent tous utiliser un petit ensemble de répertoires partagés entre eux. Cela offre divers avantages, en particulier dans les domaines du partage de fichiers entre les applications et de la réduction du nombre de chemins dont vous avez besoin pour rechercher des bibliothèques et des fichiers exécutables.

Cela dit, il existe également une longue tradition d'installation de "répertoire séparé par application" dans Unix, généralement sous le /optrépertoire.