🚲 Tanguy Ortolo a écrit 12091 commentaires

Ç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.

Non, /run. /var, c'est plutôt pensé pour les données variables de services, comme le courrier électronique. Il était utilisé pour les fichiers liés au fonctionnement des serveurs eux-mêmes, mais /run a été créé pour cet usage.

Et quel est le problème avec /etc au juste ?

Ce serait une grosse connerie, ça. /usr/(s)bin existe aujourd'hui précisément pour être séparé de /(s)bin afin de permettre des installation où, par exemple, /usr serait sur NFS, et ne pourrait être monté… qu'à une certaine étape du démarrage, avant laquelle /(s)bin suffirait.

Bref, dans Fedora et autre ils font ce qu'ils veulent, mais cette idée ne s'imposera pas de façon générale. Debian ne pourra pas y adhérer, notamment.

Je ne vois pas le rapport avec la lourdeur en mémoire. Un outil de configuration du pavé tactile n'a pas besoin de tourner en permanence. Il y a des outils de configuration de pavé tactile dans GNOME et dans KDE effectivement, mais ils sont interchangeables, et remplaçables par des outils indépendants.