🚲 Tanguy Ortolo a écrit 12361 commentaires

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.

postmaster, pas postmarter.

Et pour les exemples, il faut utiliser les noms de domaines dédiés à cela : example.com, example.net, example.org, example.edu.

Quant aux adresses IP, il faut les prendre dans les plages également dédiées à cela : 192.0.2.0/24 198.51.100.0/24 203.0.113.0/24 et 2001:db8::/32.

Nov 4 12:59:54 serveurA postfix/smtpd[20220]: lost connection after CONNECT from unknown[10.0.10.254]
Nov 4 12:59:54 serveurA postfix/smtpd[20220]: disconnect from unknown[10.0.10.254]

C'est simple, tu as un client SMTP, d'adresse IPv4 10.0.10.254, non résolvable en nom de domaine inverse, qui se connecte, puis se déconnecte immédiatement sans avoir rien envoyé. Que veux-tu savoir de plus au juste ?

RoundCube est un client IMAP à interface Web — un webmail, quoi — : ça n'a strictement rien à voir avec ton problème qui concerne un serveur de courrier, donc pas la peine de compliquer ton énoncé en en parlant.

Le pavé tactile, c'est indépendant du bureau, hein. Ça se règle par le serveur X.Org, soit de façon globale par le fichier de configuration, soit en balançant des commandes qui vont bien pour la modifier pendant l'éxécution. Donc un outil de configuration du pavé tactile, ou de la souris, ou du clavier, c'est indépendant du bureau.

Je dirais même plus, c'est un quorum.