Salut,
 
on sait tous ou presque ce qu'il y a dans les dossier situés à la racine (si vous ne savez pas, je vous conseille de vous reporter au FHS : http://www.pathname.com/fhs/2.2/ )
 
mais quel est l'origine de leur nom ?
 
Pour certains, l'énigme est assez simple (je propose ici mon interprétation) :
 
/bin : binaries (programmes binaires)
/boot : contient le noyau et les infos de boot
/dev : device files
/home : de home (chez soi) en anglais
/lib : les bibliothèques nécessaires (library en anglais)
/mnt : les points de montage par défaut (mount)
/root : le dossier du root
/tmp : les fichiers temporaires
 
pour d'autres c'est déjà un peu plus complexe mais encore compréhensible :
 
/sbin : binaires systeme (ou securisé puisque normalement uniquement pour le root ?), encore que je trouve que ls est un binaire système...
/var : les données variables + les caches des systèmes de paquetages , un peu bizarre parce que de prime abord, il semble redondant avec /tmp bien qu'en fait il traite des données différentes et donc ne l'est pas.
 
 
et alors, il y en a, on se demande d'où sortent les noms :
 
/etc : Editable Text Configuration mais cela semble être une signification inventé après la création pour faire sérieux et éviter de rappeler et caetera (qui serait la signification initiale)
 
/usr : Unix System Resource
 
/opt : les programmes commerciaux (optional ?)
 
/proc : probablement process (/proc contient les infos sur tout les process en cours) UPDATE
 
/sys : système (uniquement pour les noyaux 2.6) ? UPDATE
 
les noms de dossiers spéciaux :
le .d (de xinetd.d ; init.d etc) = directory
le rc (de rc5.d par ex) : resource configuration
 
 
Je pose donc la question :
 
Mais d'où viennent t'il ?  
 
en espérant que vous saurez, A+

/usr pour user : les programmes utilisateurs (non systèmes / indispensables)
 
Sinon je me suis toujours demandé ce que signifiaient les lettres "rc" comme dans /etc/rc.d ...  

et les .d (init.d rc.d xinit.d inet.d cron.d ...) pourquoi ils ont là ?
 
rc : runlevel change ? (puisqu'on éxécute ce qu'il y a dedans à chaque changement de runlevel) mais ça marche pas pour rc.firewall ou rc.local ni rc.sysinit

 
peut etre pour daemon    comme httpd, sshd, dhcpd etc...

.d pour directory
 
rc = resource ?

le s de sbin, c'est peut-être le s de super-utilisateur non ?

pour ce qui est specific a linux y a bcq de choses qui expliquent la dedans http://www.pathname.com/fhs/pub/fhs-2.2.pdf
 
FHS = file hierarchy standart , ca va avec la lsb

Euh, t'as vu que c'est le lien que je donne à la 5° ligne du premier topic ?

Apparemment, /bin et /sbin n'existaient pas au debut de linux.
 
Ca a commence avec /usr /var /etc je pense (peut etre aussi /proc et quelques autres, mais pas bin ni sbin).
/usr pour mettre ce qui etait relatif aux utilisateurs (usr pour user)
/var pour mettre ce qui etait variable
/etc pour mettre le reste (etcaetera, le reste quoi)
 
Ensuite, ils sont du se dire que ca faisait trop de trucs a mettre dans ETC, donc ils ont fait une arborescence plus fournie, mais en gardant ce qu'il y avait avant pour compatibilite (en 1993 je crois).

.d c pas daemon ?  

ben non, pourquoi tu veux que ce soit daemon ? les *.d sont des directories (on met le d pour pas les confondre avec des fichiers homonymes).
pkoi daemon ? vois pas le rapport ?

heu ché pas suis nul, xinit.d ya des daemon dedans enfin voila patapai !

dans xinit.d ? c'est où ça ? dans /etc/ ? ça m'étonnerai qu'il y ait des démons là dedans mais bon..

oups, xinetd.d  

/usr ne signifie pas "user", puisque le user met son bordel dans /home.
C'est unix system resource, en gros tous les logiciels.

 
et /etc ?

je vote +1 pour le et-caetera

 
Encore une fois, /home n'existait pas a l'origine je pense.

je ne suis pas d'accord. dans / va tout ce qui est necessaire au fonctionnement et à la maintenance essentielle du système (pour l'admin en fait), dans /usr va tout ce qui est utilisation pratique du système c'est à dire les softs utilisateur.
 
de plus, je suis d'accord avec sartene, le /home est quelque chose d'assez batard (qui n'est d'ailleurs pas requis dans le FHS)

 
Le dernier Linux pratique en parle. Tu peux faire une recherche "unix system resource" sur google et tu trouveras /usr

 
   
 
Ici :
http://www.biozentrum.unibas.ch/~b [...] course.pdf
 
Tu verras que /home n'existe pas a la base . Par contre il y a avait un repertoire "users" qui a disparu...
 
/ : Is the root directory
/dev : Contains the different special files.
/etc : Contains the system configuration files.
/sbin : Contains the system binary and executable files
/tmp : Temporary file zone
/usr : Contains the UNIX System Resource files
/var : Contains the variable files like mail, news, spool,...
/users : Contains the users directories and files
vmunix : DEC UNIX kernel located under root

 
Je comprends la confusion : les gens ont fini par assimiler /users et /usr car ça se prononce de la même façon. C'est peut-être pour ça que home a été créé, pour éviter la confusion phonétique.
C'est très "bricolage", mais c'est marrant, ça ressemble à l'évolution en biologie.

pour info le /users n'a pas entierement disparu .... il etait encore present sur solaris (en tout cas a l'ecole ou je suis l'année dernière)

Sur Solaris 8 pour x86, le /home existe mais il est vide et inutilisable : il n'est present que pour des notions de compatibilité
 
Si je me souviens bien ,les repertoires des utilisateurs sont dans /users/home ou qqchose comme ça

Ah oui, je me souviens vaguement d'un lien entre /home et je_sais_plus_ou, mais ca fait pertpete que j'ai plus touche de Solaris...  

ah ben oué tiens, désolé, je savais pas !

Bon, et bien on a avancé quand même, on sait pourquoi /usr : unix system resource, et xxxx.d pour directory
 
Vos idées et connaissances sont encores bienvenues, il reste /etc (et caetera ?) et /opt ( optionnal ?)  à trouver.
 
et aussi si on pouvait avoir une certitude sur le rc de rc.local, rcX.d ...
 
A+  

opt je suis quasi sur que c'est effectivement optionnal
pour etc j'approuve le et caetera, mais c'est juste un avis perso
 
sinon, rc c'est pas resource control ou qqchose dans le genre ?

sbin
 
g tjrs compris ça comme "binaire secondaires" > pas indispensables au fonctionnement du système.
 

et /sbin/mount ? c'est pas indispensable a ton système ???
 
Pour moi : sbin => binaires du sysadmin

 
fo croire ke non puiske chez moi il est pas dans ce dossier (g une mandrake)
 
mount est dans le /bin.
 
Dans sbin g rien de vital.

oh que si, tu as init dans /sbin et c'est aps la peine d'espérer démarrer normalement sans lui
 
tu as ifconfig (laisse tomber le réseau sans lui)
 
et quelques autres trucs sympa

 
ls /sbin :
...
init
...
fsck
...
lilo
...
modprobe
...
depmod
...
shutdown
...
 
etc

 
 
je suis d'accord avec toi sbin regorge de truc très utils.
 
Ceci dit mon répertoire /bin contient lui aussi pas mal de programme permettant d'administrer le système.
 
Par exemple g /bin/kill et /sbin/killall, c dans ce sens ke je dit ke les binaires de /sbin sont secondaires.
 

 
Je pense plutot que les binaires de sbin sont "system binaries", vu que root est le seul a l'avoir dans son path par defaut.

 
ok, va pour les "system binaires"
 
Par contre je viens de regarder plus en détail les droits fixés sur les répertoires /bin et /sbin chez et ce sont exactement les mêmes
 
g une mandrake et g simplement spécifié un niveau de sécurité moyen sans plus me casser la tête, c déjà assez contraignante pour ce ke je fais de mon poste.
 
Bref je comprends de moins en moins bien la différence en tre /bin et /sbin (à moins peut-être qu'elle apparaisse à un niveau de sécurité plus élevé )
 
g fait qq test en lancant des executables depuis un compte normal et ça marche, heureusement les programmes les pus importants genre iptables sont sécurisés au niveau logiciel et réclame les privilèges d'administrateur.  
 
bah g encore beaucoup de choses à apprendre
 

 
 

En fait c'est plus une separation logique qu'autre chose...
C'est juste que normalement, un utilisateur n'a pas a faire de traceroute, de init (de toutes facons ca marchera pas...), d'installation de lilo, etc...
Donc ca sert a rien que ca traine dans son path...

Sous debian, je ne crois pas que les utilisateurs lambda aient accès à sbin.

Si l'utilisateur a acces a sbin mais celui-ci n'est pas dans son PATH donc il doit faire /sbin/lacommande.

 
il est pas dans le path mais on peut y accéder à la main (ou le mettre dans le patch bien entendu)
par exemple, which ifconfig ne renvoit rien
mais tu peux y accéder via /sbin/ifconfig