🚲 Tanguy Ortolo a écrit 12570 commentaires

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.

J'imagine que c'est un gros sac où tous les fichiers sont mis en vrac, sans noms ni hiérarchie, mais avec des étiquettes clef=valeur. Au lieu de ranger, on étiquette, et au lieu d'aller consulter par un nom précis, on cherche.

ce serait confondre la fonction avec l'usage

Argh. Ce serait confondre la nature avec la fonction.

/me se flagelle à coup de fibre monomode.

câble catégorie 5 ou 6, pas câble Ethernet, ce serait confondre la fonction avec l'usage. D'ailleurs tu en fais un usage légitime qui n'a rien à voir avec le protocole Ethernet, à ce que je vois.

Il y a aussi des systèmes qui n'ont pas d'initrd du tout, des BSD par exemple, je pense. Or la FHS n'est pas spécifique à Linux, même si on sait déjà que Lennart n'en a rien à foutre des autres Unices.

Pas besoin de préciser « à l'origine » : c'est toujours le cas.

Non en effet, il n'est pas dans la FHS pour le moment, mais il a été adopté par plusieurs distributions afin de simplifier le démarrage, justement. Parce qu'au démarrage, on a besoin d'un tel répertoire, et que /var/{run|lock} ne sont pas forcément disponibles à ce moment-là.

• les freins à main électroniques

Oui, alors ça justement je trouve ça choquant. À une époque il était obligatoire d'avoir un frein de secours à transmission directe par câble, qui était la plupart du temps couplé au frein de parcage. Visiblement cette obligation a disparu, résultat, sur pas mal de voitures modernes, si l'alimentation en courant électrique tombe en panne, on n'a plus aucun moyen de freiner : le frein hydraulique principal ne fonctionne que tant qu'il reste de la pression, et le frein de parcage électrique ne fonctionne pas du tout.