Quels sont les avantages de la structure du système de fichiers Unix


9

Si j'installe une application sous Linux, par exemple Debian / Gnu Linux, les fichiers des applications sont copiés dans de nombreux répertoires différents du système de fichiers.

Certains scripts vont dans / usr / share .. / usr / local d' autres fichiers dans / var .. / log .. etc / et ainsi de suite.

Pour moi, c'est ok car j'ai appris quelque chose sur le système de fichiers et la plupart des répertoires sont là pour contenir des fichiers dans un but précis. Cela correspond très bien à la philosophie Unix "faire une chose et bien le faire"

Mais ma question est quels sont les avantages d'une telle structure de répertoires? Ou est-ce simplement l'héritage des vieux jours unix. (par exemple, par rapport à l'utilisation de Windows, où tous les fichiers d'une application se trouvent dans un "dossier" spécifique)

Réponses:


9

Ce qui me semble le plus facile à penser, c'est que des fichiers similaires vivent dans la même arborescence de répertoires. Les fichiers de configuration vivent /etc, les fichiers journaux et / ou les fichiers de trace d'exécution vivent /var/log, les exécutables vivent /usr/bin, les informations d'exécution comme les fichiers PID vivent /var/run. Vous voulez savoir ce qu'il y a dans le fichier de configuration NTP? Changez le répertoire en /etcet faites ls ntp*. Vous voulez avoir des fichiers exécutables de surveillance de programme afin qu'un virus de système de fichiers traditionnel ne les infecte pas? Tout /usr/binet /usr/local/bindoit être regardé.

Le deuxième avantage auquel je peux penser est que le style d'organisation Unix favorise une séparation des données et des exécutables. Les exécutables vivent dans un répertoire éloigné de l'endroit où vivent les modèles ( /usr/share, probablement) et loin de l'endroit où vivent les données. Cette séparation pourrait être une raison pour laquelle Unix / Linux / * BSD ont plus de résistance aux virus du système de fichiers que Windows, ou l'ancien Mac pré-OSX.


Ce sont de bons points. Pourquoi la séparation des fichiers exécutables et des fichiers de données, de modèle et de configuration est-elle une raison pour une meilleure protection contre les virus?
Jan Koester

3
Beaucoup (mais pas tous) des virus et vers dans le monde se propagent en raison de la possibilité de changer les données en exécutables: les débordements de pile et l'injection SQL et l'injection de code fonctionnent tous de cette façon. Les virus de macro "Word" se sont propagés au moins en partie parce que les macros "Word" sont incluses dans les fichiers .doc. La séparation des données de l'exécutable par fichier est un niveau de protection, mettre les données dans un répertoire, l'exécutable dans un second, les modèles dans un 3ème, la configuration dans un 4ème met encore plus de barrières à la confusion des données et l'exécutable en place.
Bruce Ediger

2
L'argument de séparation des données et des exécutables est un non-sens complet. L'organisation du système de fichiers est dans l'intérêt de l'homme; ce n'est pas comme s'il y avait une séparation physique entre les bits qui les empêche de se donner des cooties ou quoi que ce soit. La sécurité d'UNIX est historiquement meilleure en raison d'un modèle d'autorisations plus fort et plus étroitement appliqué en général.
moelleux

@fluffy systèmes de fichiers séparés offrent une séparation légèrement plus forte, mais ce point est en partie sans objet car il est impossible de séparer /bin, /etc, de /.
jw013

@fluffy - d'accord, aucune séparation "physique" n'existe ou n'est possible. Mais c'est une séparation par nom. Les logiciels malveillants doivent chercher dans un autre répertoire (plutôt que "." Ou dirname $ 0 ou quelque chose) pour trouver des modèles ou d'autres données. Ce n'est pas une sécurité absolue, pas plus que la fermeture d'une fenêtre en verre n'est une sécurité absolue. La sécurité est un bien économique, avec une valeur marginale pour chaque unité de travail supplémentaire. Chaque petit geste compte.
Bruce Ediger

11

Quelle que soit l'organisation choisie, cela rendra certaines choses plus faciles et d'autres plus difficiles.

Organisation des fichiers par types, comme Unix (en bin, man, lib/python, ...), il est plus facile d'utiliser des fichiers. Si vous souhaitez exécuter une commande, vous savez où la trouver, quel que soit le package qui la fournit. Si vous souhaitez rechercher dans la documentation, tout est au même endroit. Si un programme fournit un module de mise en évidence de la syntaxe Vim, une fonction d'achèvement zsh ou des liaisons Python, le fichier correspondant sera à un endroit où vim / zsh / python pourra le trouver.

Unix organise également les fichiers par modèles d'utilisation. Les fichiers de configuration entrent /etc, les fichiers qui ne changent pas en fonctionnement normal entrent /usret les fichiers qui changent entrent automatiquement /var. Les données des utilisateurs tombent sous /home. Ceci est très utile pour la gestion de la configuration (gérez le contenu /etcet la liste des packages installés). Il est également utile de définir des stratégies de sauvegarde: ce qui est /etcet /homeest d'une importance cruciale, tandis que ce qui est /usrpeut être facilement téléchargé à nouveau.

Le principal coût de la méthode Unix est que l'installation d'un logiciel est répartie sur de nombreux répertoires. Cependant, les systèmes Unix modernes ont quand même des gestionnaires de paquets; la gestion des fichiers dans de nombreux répertoires n'est de loin pas la chose la plus complexe qu'ils font (le suivi des dépendances est très utile et plus difficile).

Comparez cela avec Windows. Windows a commencé sans gestion de package et chaque application a créé son propre répertoire quelque part. Tous les fichiers se trouveraient normalement dans ce répertoire: programmes, données statiques, données utilisateur,… Sauf parfois pour les bibliothèques dont les programmes tomberaient dans un répertoire système commun sans tenir compte des conflits («DLL hell»). Au fil du temps, Windows est devenu multi-utilisateur, nécessitant la séparation des répertoires utilisateur des répertoires système. Windows a également créé un emplacement central pour les fichiers de configuration (Unix /etc) et certaines données système (Unix/var), le registre. Il s'agit davantage d'un artefact historique en grande partie dû au manque de gestion des packages et aux débuts de l'histoire en tant que système mono-utilisateur. L'approche Windows a de nombreuses limites: elle ne permet pas aux packages logiciels d'interagir facilement. Par exemple, la plupart des logiciels installés ne se retrouvent pas sur le chemin de recherche de commandes par défaut, ils interagissent donc mal avec toute forme de script. Les installateurs fournissent généralement une icône de menu dans un cas spécial - déposée dans un répertoire système distinct (à la Unix!).

Une limitation de l'approche Unix est qu'elle ne permet pas facilement la coexistence de plusieurs versions d'un package, ce qui est particulièrement problématique lors de la mise à niveau du package. Un moyen de tirer le meilleur parti des deux mondes serait de décompresser chaque package dans son propre répertoire (une /optstructure) et de créer des forêts de liens symboliques des répertoires des packages vers une /usrstructure. C'est ce que fait un logiciel comme stow .

En résumé, l'approche Unix facilite l'utilisation des fichiers, la gestion des fichiers et l'interaction des packages; il nécessite un logiciel de gestion de paquets, mais c'est quand même souhaitable. L'approche Windows facilite la gestion manuelle des packages, mais doit virer vers le modèle Unix pour obtenir des fonctionnalités utiles.


1
Impressionnant. À mon avis, cependant, il était auparavant plus facile de gérer les packages individuellement. L'avènement du registre Windows a changé tout cela, puis certains. Non seulement il est gigantesque et labyrinthique - il l'est aussi intentionnellement - avec certaines valeurs en code octet alors que d'autres ne le sont pas et sans vraie rime ou raison à la structure. Je suppose que c'est la façon dont cela doit être si vous voulez développer un système d'exploitation géré et protéger les secrets commerciaux et les méthodes propriétaires: déroutant.
mikeserv

3

Un avantage principal non mentionné ci-dessus, et l'une des raisons historiques de la structure, est la séparation physique sur plusieurs volumes / disques disponibles à différentes étapes du processus de démarrage.

Un autre avantage est que les différents répertoires peuvent être montés sur des volumes / systèmes de fichiers optimisés pour les données du répertoire. Par exemple, tmpfspour /run; et /sbinsur des supports / ROM en lecture seule.

De plus, les volumes peuvent être locaux ou distants, personnels ou partagés.

Enfin, voir Répertoire d'applications pour une approche alternative (mentionnée par @fluffy) utilisée sous UNIX (OS X .app), Linux ( ROX Desktop ) et Windows ( PortableApps.com ).


1

Il n'y a pas vraiment d'avantages à cette disposition, à part qu'il est facile de deviner où se trouvent les fichiers partagés et de configuration pour une application. UNIX a un long héritage de ce type de disposition, et il serait assez difficile de le casser. Cependant, certaines distributions UNIX ont changé de modèle - elles ne fournissent les anciens emplacements qu'à des fins héritées, et d'autres applications sont regroupées dans son propre petit répertoire / package. Mac OS X en est l'exemple le plus frappant, et il existe quelques distributions Linux obscures qui font la même chose (et Android fait quelque chose de similaire, va un peu plus loin et installe et lance également chaque application sous son propre ID utilisateur). ).

La principale chose qu'une convention de système de fichiers fournit est juste cela - une convention, afin que les gens sachent où chercher les fichiers (que ce soit manuellement ou dans le code). Il n'y a aucune vraie raison technique pour que ce soit un moyen plutôt qu'un autre.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.