🚲 Tanguy Ortolo a écrit 12252 commentaires

Tiens, d'ailleurs c'est le cas historiquement…

Et ça change pas que ton « si t'as pas le droit de l'utiliser en écriture, alors t'en as pas besoin en lecture » était une bonne grosse connerie.

Mais bordel, on a le choix ! Séparer /bin et /sbin permet aux gens de régler leur $PATH selon leurs besoin.

C'est ce que je dis. C'est la raison pour laquelle les serveurs empaquetés utilisent par défaut des répertoires de données dans /var. À l'administrateur d'organiser /srv et d'y faire pointer ses serveurs.

Ah mais oui il y a le gestionnaire de paquets pour s'occuper de cela... et pour les programmes compilés maison, c'est

… dans /opt/logiciel. Et ça reste très propre.

Plus urgent, il serait temps aussi de déplacer une fois pour toute ces cochonneries de .dossiers présents dans le ~/, dans un ~/.config ou autre.

http://standards.freedesktop.org/basedir-spec/latest/. De rien.

ça veut dire quoi, que les jeux c'est moins important que par exemple un éditeur xml ?

Non, ça veut dire qu'un type au travail n'en a pas besoin, et peut ainsi ne pas s'encombrer d'une autocomplétion sur les jeux, par exemple. Et s'il les veut, eh bien il change son $PATH, il a le droit aussi.

La séparation entre logiciels d'administration, logiciels d'utilisation et jeux est pertinente. On pourrait aller plus loin mais il faut un compromis ; celui-ci est probablement historique, et assez pratique pour qu'on n'ait pas envisagé de le changer.

Non non non, ça montre seulement que ce n'est pas compris. Dans l'immense majorité de ces abus, il existe un chemin standard qui conviendrait, seulement le responsable n'était pas au courant parce qu'il n'a pas la FHS en livre de chevet, c'est tout.

/var/opt c'est standard. /etc/opt aussi.

Il ne s'agit pas de sécurité mais de commodité. L'utilisateur ordinaire préfère probablement ne pas être encombré par des commandes qui ne lui servent pas. S'il préfère les avoir en autocomplétion, super, il a aussi le droit de modifier son $PATH.

Avec cette séparation bin/sbin, on a le choix entre disposer facilement de toutes les commandes ou seulement celles destinées à une simple utilisation. Sans cette séparation, ben on n'aurait pas le choix !

Pour l'admin, oui. Un utilisateur ordinaire qui n'a de toute façon pas accès à ces commandes en écriture se moque bien de les avoir en lecture seule.

J'ai eu du mal à comprendre, donc pour ceux qui seraient dans mon cas : swap.

Les répertoires, ça sert à faire une hiérarchie. Par conséquent, vous ne voulez pas de répertoire, donc vous n'avez pas besoin de liens physiques sur les répertoires.

Ça aurait plutôt sa place dans /srv en effet, mais l'organisation de /srv est laissée à discrétion de l'administrateur, par conséquent une distribution ne peut pas y imposer d'organisation a priori.

Ah, pour mtab, excellente idée, l'avoir sous /etc est une horreur.

/var/www c'est déprécié

Excusez-moi, je voulais bien sûr dire que c'était suranné.

/etc/local ce serait une bonne idée en effet. En revanche, il y a déjà /etc/opt, par exemple. Je ne sais pas où tu as vu un /usr/local/etc mais c'est horrible.

/var/www c'est déprécié, tu peux mettre tes sites sous /srv, avec une convention à ta discrétion, par exemple /srv/www. Les serveurs Web fournis par les distributions sont configurés avec /var/www parce que justement, comme l'organisation de /srv est laissé à la discrétion de l'administrateur, ils ne peuvent pas faire de choix arbitraire dedans.

Ah, exact. Pas de chance, c'est impossible, entre autre pour une raison imparable : dans un répertoire qui a plusieurs noms, c'est qui .. ?

D'ailleurs, on a inventé les liens pour contourner cette contrainte

Référence nécessaire. Les liens physiques sont une fonctionnalité normale d'un système de fichiers qui découple le nom du contenu, et les liens symboliques une fonctionnalité permettant une indirection, mais de là à dire qu'ils ont été introduit pour ça…

Bah, avec tous les outils Unix qu'on a on devrait bien y arriver. Avec des fichiers temporaires, hélas, certes. Mais bon, les outils pour lister en faisant des opérations ensemblistes sur des répertoires, ça se code…

Il dit qu'il n'a plus de genoux.

C'est pour ça qu'il faut lire DLFP aux toilettes !

Pourquoi Debian a pas repris la solution RPM ?

Mauvaise question. La bonne question, c'est : pourquoi RedHat n'a pas repris la solution DEB au lieu de développer son propre système RPM ? Désolé si je brise vos rêves, mais le premier système de gestion de paquets, c'est celui de Debian, hein.

Notez que, vu ce que j'en pense, j'aurais probablement mieux fait de s/vrac/bordel/…

Sous *nix, un fichier est identifié par le numéro majeur et le numéro mineur du périphérique sur lequel il est stocké, et par son numéro d'i-nœud. Il a par ailleurs un certain nombre de noms, ce nombre pouvant être positif ou nul — ce dernier cas se produisant lorsqu'on supprime le dernier nom d'un fichier qui est toujours ouvert par un processus.

En particulier, un fichier n'est pas identifié par son nom, et peut avoir plusieurs noms. Que te faut-il de plus ?

mkdir /vrac     # répertoire de stockage de tous les fichier
mkdir /pouet    # étiquette « pouet »
mkdir /pouic    # étiquette « pouic »
echo "Toto" > /vrac/toto
ln /vrac/toto /pouet/toto  # on étiquette le fichier toto par « pouet »
ls /pouet       # quels sont les fichiers étiquetés « pouet » ?

Exact, mais contrairement à ce délire de /usr, c'était une bonne idée.