Cette section traite de plusieurs domaines qui peuvent demander des explications plus détaillées.
La réponse est : il est essentiel de nettoyer, créer, préparer, vérifier, trouver et monter d'autres systèmes de fichiers (peut-être sur des machines distantes). Il y a d'autres définitions, mais ceci est une définition générale que la plupart des gens intègreront au moins à la leur.
Le réseau présentait un dilemme intéressant. Certaines personnes voulaient séparer la configuration et les binaires pour le réseau des autres binaires et configuration. Cependant, nous ne sommes pas d'accord. Nous pensons que le réseau n'est pas un "package", mais une partie intégrante de la plupart des machines UNIX (et ressemblantes). À cause de ceci, le réseau ne devrait pas être placé dans un répertoire isolé, mais systématiquement placé dans les répertoires appropriés.
* /bin : tout ce qu'un utilisateur voudra utiliser et qui est en même temps considéré comme vital
{ hostname, netstat, ping }
* /sbin : tout ce dont seul root a besoin et qu'il considère vital
{ arp, ifconfig, route }
* /usr/bin : tous les binaires qu'un utilisateur voudra utiliser, et qui ne sont pas vitaux
{ finger, rcp, rlogin, telnet, etc. }
* /usr/sbin : tous les binaires réservés à l'administrateur et qui ne sont pas vitaux
{ in.ftpd, inetd, lpd, portmap, etc. }
Alors que ceci peut paraître confus en premier lieu (et ça prend un moment à digérer), en fait ça a un sens. Si vous ne pouvez monter que root pour une raison ou pour une autre et que vous avez besoin d'accéder au réseau pour réparer votre système, vous n'avez pas besoin que les fichiers soient relégués dans /usr/etc (ce qu'ils sont souvent). Les fichiers indispensables au montage de /usr dans les situations normales (et en cas d'urgence) sont placés dans l'arborescence root et tous les autres sont placés dans /usr pour limiter la taille du système de fichiers root.
Les fichiers de configuration pour le réseau appartiennent à /etc.
Le répertoire /usr/share contient en général des fichiers indépendants de l'architecture comme les pages de manuel, la zone temporelle, les informations sur le terminal, etc. En ce moment, il n'y a pas d'architectures différentes pour Linux (NdT maintenant si :-), mais avec le temps nous devrions voir Linux inclure d'autres architectures et d'autres systèmes ressemblant à UNIX.
Une note : aucun programme ne devrait référencer quoi que ce soit dans /usr/share. Par exemple, un programme de pages de manuel ne devrait jamais regarder directement dans /usr/share/man/man1/ls.1, mais il devrait tout le temps se référer à /usr/man/man1/ls.1. Tout ce qui est dans /usr/share sera "pointé" par l'utilisation de liens symboliques provenant d'autres endroits du système, comme /usr/man, /usr/lib/<something>, etc.
On travaille toujours sur les spécifications de /usr/share.
Il y a un large éventail d'utilisations pour les liens symboliques dans chaque système de fichiers. Alors que les liens symboliques ne sont pas encouragés pour une installation par défaut (que l'on trouve après avoir installé Linux) dans une norme comme celle-ci, ils sont souvent utilisés avec bonne raison sur des systèmes différents. Le problème est que les liens symboliques devraient être là pour tout garder quand n'importe qui espère le trouver là.
Soyez préparés à accepter que certains répertoires, même ceux que l'on trouve dans le répertoire root, vont quand même être des liens symboliques. Par exemple, sur certains systèmes /home ne sera pas sur root, mais lié symboliquement à un répertoire /var, ou autre part. /home peut aussi avoir sa propre partition physique, bien sûr, et être monté de son propre chef.
De manière similaire, parce que /usr peut être sur un serveur de fichiers central monté par NFS, /usr/local pourrait être lié à /var/local. Ce changement peut être justifié en se rappelant la raison principale d'avoir /var : séparer les répertoires des fichiers qui varient avec le temps et entre différents systèmes et machines de ceux qui peuvent être partagés et en lecture seule.
Quelquefois les systèmes lieront aussi /tmp à /var/<quelquechose> si la partition root devient trop petite (ou démarre trop petite). Il y a plus d'exemples de "bons" usages des liens symboliques, mais le problème entier se réduit à deux choses : les packages doivent être capables de trouver les choses où elles les attendent (avec raison) et les liens symboliques peuvent être utilisés pour résoudre le problème dans bien des cas.
Cependant, des problèmes peuvent aussi surgir en utilisant trop de liens symboliques. Ces problèmes comprennent une sur-confiance pour que les liens symboliques résolvent les problèmes, des confusions résultant de la sur-utilisation des liens symboliques, et les préférences esthétiques de gens différents.
Linux tourne en ce moment sur une grande variété de systèmes, certains en utilisateur simple avec des petits disques, certains comme serveurs dans des grands environnements en réseau. À cause de cette variété, cette norme ne met pas de règle en ce qui concerne quels binaires sont statiques ou dynamiques avec les deux exceptions suivantes. À la fois ln et sync devraient exister dans /bin ; toutes les versions liées en statique peuvent être placées dans /sbin, ou remplacer ceux de /bin.
Les grands systèmes Linux peuvent vouloir inclure d'autres binaires liés en statique (sh, init, mkfs, fsck, tunefs, mount, umount, swapon, swapoff, getty, login, et autres). Les développeurs et/ou les administrateurs système sont libres de lier statiquement/dynamiquement ceux-ci et d'autres binaires comme ils le souhaitent, tant que l'emplacement des binaires ne change pas.
Les systèmes en réseau (surtout ceux qui n'ont pas de lecteurs de disquettes), peuvent vouloir lier ifconfig, route, hostname, et d'autres utilitaires réseau en statique aussi. Ceci n'est en général pas nécessaire.
La liste de distribution FSSTND est située à <fhs-discuss@ucsd.edu>. Cette liste était située à l'origine sur la liste <linux-activists@Niksula.hut.fi> "Mail-Net" en tant que canal FSSTND. (Pour s'inscrire à la liste envoyez un courrier électronique à <listserv@ucsd.edu> avec dans le corps du message "ADD fhs-discuss".)
Merci à Network Operations à l'Université de Californie à San Diego qui nous a permis d'utiliser leur excellent serveur de listes de distribution.
Comme noté dans l'introduction, s'il vous plaît n'envoyez pas de courrier électronique à la liste de distribution sans d'abord contacter le coordinateur FSSTND ou un contributeur listé.
Les honneurs pour ce texte devraient être donnés aux activistes FSSTND, aux développeurs, aux administrateurs système, et aux utilisateurs dont l'avis a été essentiel à cette norme. Je voudrais aussi remercier chacun des contributeurs qui m'ont aidé à écrire, compiler, et composer ceci, une norme de consensus.
Je voudrais aussi donner des remerciements à ces développeurs Linux qui ont vu que donner un plan commun du système de fichiers à Linux est quelquechose qui va prolonger le développement du système d'exploitation Linux. Je voudrais aussi noter la bravoure et la persévérance de ces développeurs Linux qui ont commencé à suivre cette norme avant qu'elle ne soit finie.
Drew Eckhardt <drew@colorado.edu>
Ian Jackson <ijackson@cus.cam.ac.uk>
Ian McCloghrie <ian@ucsd.edu>
Daniel Quinlan <Daniel.Quinlan@linux.org>
Mike Sangrey <mike@sojurn.lns.pa.us>
David H. Silber <dhs@glowworm.firefly.com>
Theodore Ts'o <tytso@athena.mit.edu>
Stephen Tweedie <sct@dcs.ed.ac.uk>
Brandon S. Allbery <bsa@kf8nh.wariat.org>
Rik Faith <faith@cs.unc.edu>
Stephen Harris <sweh@spuddy.mew.co.uk>
Fred N. van Kempen <waltje@infomagic.com>
John A. Martin <jmartin@csc.com>
Chris Metcalf <metcalf@lcs.mit.edu>
Ian Murdock <imurdock@debian.org>
David C. Niemi <niemidc@clark.net>
Traduit le 2 juillet 1996 par Olivier Tharan
