Après pulseaudio, après avahi, après systemd, après le répertoire /run voilà que Lennart Poettering frappe à nouveau et propose de chambouler l'organisation de nos systèmes GNU/Linux.
Dans un post sur son blog Lennart vient d'annoncer une refonte des fichiers de configuration. Selon lui la transition vers un système d'init moderne comme systemd est l'occasion d'en finir avec la fragmentation (aka le bordel) qui règne entre les différentes distributions.
Voici son résumé de la situation actuelle des fichiers de configuration et des saletés qu'il a été obligé d'inclure dans le code de systemd pour pouvoir supporter les choix divergents des distributions:
Certains d'entre eux sont bien standardisés entre les distributions et donc le fait de les supporter dans notre implémentation en C a été facile et évident. Par exemple on peut citer
/etc/fstab
,/etc/crypttab
ou encore/etc/sysctl.conf
.
Cependant, pour d'autres fichiers de configuration, il n'existe aucune standardisation ce qui nous a forcé à introduire une orgie de #ifdef dans notre source afin de pouvoir interagir avec les différents emplacements utilisés par les distributions.
Pour améliorer la situation et pour bénéficier de force unificatrice qu'est systemd nous avons donc décidé que le support différencié des fichiers de configuration serait uniquement une solution de secours et que, par défaut, nous introduirions de nouveaux fichiers de configuration chaque fois que ce sera la meilleure solution.
Lennart cite ensuite plusieurs exemples de fichiers de configuration qui sont stockés de façon différente sur les multiples distros et il indique quelle est la solution retenue par les développeurs de systemd.
Par exemple le fichier host name est stocké sous /etc/sysconfig/network
dans Fedora et sous /etc/HOSTNAME
pour OpenSUSE. Il a été décidé de standardiser tout ça en s'alignant sur le système Debian en utilisant /etc/hostname
.
La locale utilisée par le système sera dans /etc/locale.conf
tandis que l'identification du système d'exploitation est standardisé dans /etc/os-release
(plus besoin de /etc/fedora-release
ou de /etc/debian_version
…regardez sur cette page la pagaille qui règne actuellement !).
Bien entendu Lennart annonce que ces emplacements standardisés ne lui ont pas été dictés par l'archange Gabriel et que tout ceci été discuté entre les différents responsables des distros (all of these files were discussed in one way or another with various folks from the various distributions).
Encore plus important, il dit clairement dans son post que la solution de fallback pour lire les anciens emplacements de fichiers a vocation a disparaitre:
De façon a pousser gentiment tout le monde a standardiser autour de ces fichiers nous voulons rendre clair que, tôt ou tard, nous allons supprimer le support des vieux fichiers de configuration dans systemd. Cela signifie que l'adoption de cette nouvelle organisation peut se faire lentement, petit à petit, mais que le but final de n'avoir qu'un seul schéma de configuration doit être clair.
Etant donné que systemd semble bien parti pour remplacer sysvinit sur nos systèmes il y a des chances pour que cet effort de standardisation proposé par Lennart et ses acolytes soit lui aussi bien accueilli. Certes la transition sera longue et il y aura sans nul doute des récalcitrants mais personne ne peut nier que cette unification représente un progrès.
Lennart nous demande donc a tous de l'aider à faire avancer cette transition:
help us standardizing Linux! Use the new configuration files! Adopt them upstream, adopt them downstream, adopt them all across the distributions!
On pense ce qu'on voudra de Lennart Poettering, de son code et de ses provocations, mais il ne fait aucun doute qu'il aura eu une influence énorme sur la façon dont nous utilisons tous nos systèmes GNU/Linux.
# Fichiers de configuration du système
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
J'ai eu une belle frayeur en listant le début de cet article, qui donne l'impression qu'il veut tout casser dans ''/etc''. Il n'en est rien, il s'agit des fichiers de configuration liés à l'utilisation du système de base, pas de ceux des logiciels qu'on fait tourner dessus.
Donc, nom d'hôte, paramètres de comportement du noyau (sysctl) et langue. Mais certainement pas configuration de Postfix et compagnie, ça ne le regarde pas.
# et LFS?
Posté par z . Évalué à 2.
Et LFS ? c'est pas son rôle de gérer ce merdier et d'imposer des normes ?
En tout cas, c'est une bonne nouvelle.
[^] # Re: et LFS?
Posté par z . Évalué à 2.
FHS pas LFS, désolé de la miss take
[^] # Re: et LFS?
Posté par patrick_g (site web personnel) . Évalué à 4.
Il en parle à propos du choix de
/etc/os-release
:[^] # Re: et LFS?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
LSB : Linux standard base. À ne pas confondre avec LFS, Linux from scratch, et LSD, Lysergesäurediethylamid.
[^] # Re: et LFS?
Posté par Bayet Thierry . Évalué à 2.
Heu... LSD, c'est pas Lucy in the Sky with Diamond ? On m'aurais menti?
[^] # Re: et LFS?
Posté par bubar🦥 (Mastodon) . Évalué à 5.
C'est ce qui est (me semble) intéressant ici, très justement :
La démarche propose une spec, une direction, qui a déjà été discutée par des développeurs, et qui a été crée de manière concertée. Ensuite ils demandent aux autres de bien vouloir se pencher sur la question.
Bref au lieu qu'il s'agisse d'une haute instance (LSB) ou d'un dictateuràvie (MS) qui impose une vision, là, on un process décidé et validé par les premiers concernés : les développeurs.
[^] # Re: et LFS?
Posté par lolop (site web personnel) . Évalué à 10.
"les premiers concernés : les développeurs."
Les premiers en ordre chronologique... parce qu'en nombre de personne, on doit avoir bien plus d'administrateurs systèmes.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: et LFS?
Posté par skeespin (site web personnel) . Évalué à 2.
Héhé, est ce appel au troll volontaire... ou pas
# Pour légèrement digresser
Posté par thor_tue . Évalué à 5.
Dans le même ordre d'idée, ça serait peut-être bien d'avoir quelque chose comme un répertoire "/home/utilisateur_untel/etc". Je trouve que les fichiers de configurations personnels sont vraiment dispersés en bordel, je les aimerais bien regroupés. D'autant plus que ce sont bien en pratique des fichiers de type "editable text configuration".
Mes 0,2€ ...
[^] # Re: Pour légèrement digresser
Posté par claudex . Évalué à 10.
Ça existe déjà, les fichiers de configuration sont censé se retrouver dans ~/.config http://www.freedesktop.org/wiki/Specifications/config-spec
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pour légèrement digresser
Posté par thor_tue . Évalué à 1.
OK, je n'avais pas vu le ".config". Ceci dit, il n'est pas bien rempli. J'espère qu'un jour il y aura un standard (au moins de fait). Pourquoi cacher avec le préfixe point ?
[^] # Re: Pour légèrement digresser
Posté par claudex . Évalué à 4.
À mon avis, parce que l'utilisateur de base n'est pas censé y accéder, c'est réserver aux utilisateurs confirmer qui savent ce qu'ils font, à ceux qui font des backup et qui le nomme directement (ou prennent tout le dossier de toute façon) ou aux programmeurs qui y accèdent via leur programme et qui ont intérêt à connaître son nom de toute façon.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pour légèrement digresser
Posté par barmic . Évalué à 10.
Oh ! Ne jamais y accéder par son nom ou en tout cas toujours vérifier avant que la variable d'environnement XDG_CONFIG_HOME n'est pas positionnée.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pour légèrement digresser
Posté par JGO . Évalué à 8.
Je fais ça
/etc/passwd →
jgo:x:1000:1000::/home/jgo/etc:/bin/bash
/home/jgo/etc/.bashrc →
if [
pwd` == "/home/jgo/etc" ]; thenfi`
Officiellement, mon home est /home/jgo/etc/, mais dolphin et bash sont configurés pour s'ouvrir dans /home/jgo. Je récupère ainsi un répertoire perso /home/jgo/ tout bien rangé où je peux créer mes répertoires utiles : ./pub/, ./travail/, ./photos/...
[^] # Re: Pour légèrement digresser
Posté par calandoa . Évalué à 1.
Ce .config est effectivement un grand pas en avant, mais je ne suis pas sûr que ça prenne en compte tout les cas habituels pour avoir un home bien rangé. Déjà, séparer les gros trucs qui prennent de la place des fichiers de configs important : par exemple les fichiers cache d'un navigateur ne devraient pas se retrouver là dedans. Je vois un .cache dans mon home, peut être est ce l'équivalent standardisé de .config? Il faudrait la même chose pour les données importantes et qui prennent de la place comme les mails (un .data?).
L'autre truc, c'est les fichiers crées par défaut par les applications que tu lances une fois dans ta vie pour les essayer et qui vont polluer ton home pendant 10 ans. Peut être un .defaut, avec le contenu propre à chaque app transféré vers .config dès qu'une modif est faire? Aussi, pouvoir faire la différence entre les préférences par utilisateur et celle globales à la machine... ce dernier point est plus compliqué à gérer par exemple au niveau de la sécurité. Les apps sous Windows proposent aussi souvent ce genre de choix, mais ça n'est pas toujours satisfaisant.
Le but serait de pouvoir facilement faire un backup d'une machine utilisé depuis longtemps sans devoir graver 12 dvds, en séparant clairement les données par défaut de celles modifiées par l'utilisateur. Juste un "mv ~/.config /media/flash" pour les trucs de base, éventuellement un "mv ~/.data" pour les grosses données. Malheureusement, tout cela reste un peu de la branlette. Avant que tous les développeurs se mettent d'accord sur un choix commun, il risque de se faire tard...
[^] # Re: Pour légèrement digresser
Posté par claudex . Évalué à 10.
Tout cela est décrit dans le lien donné par Tanguy: le $XDG_CACHE_HOME ($HOME/.cache par défaut), c'est pour le cache et le $XDG_DATA_HOME ($HOME/.local/share par défaut) pour les données de l'utilisateur (par contre, je ne comprend pas pourquoi ce n'est pas un .data ou .share comme les autre).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pour légèrement digresser
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Cadeau : http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html
[^] # Re: Pour légèrement digresser
Posté par fredix . Évalué à 1.
ça existe déjà dans le .config
[^] # Re: Pour légèrement digresser
Posté par bubar🦥 (Mastodon) . Évalué à 2.
C'est le .config (xdg_config_home) de ton ~ Mais quant on voit l'usage qu'en font encore aujourd'hui pas mal de softs, pour cette spec on comprends que dans /etc ils y aillent mollo mollo.
[^] # Re: Pour légèrement digresser
Posté par gouttegd . Évalué à 1.
Ça existe déjà, c’est le répertoire
/home/utilisateur/.config
, proposé par la XDG Base Directory Specification. Mais l’utilisation de ce répertoire n’est pas encore très répandue, même si j’ai l’impression que ça augmente peu à peu.[^] # Re: Pour légèrement digresser
Posté par Dr BG . Évalué à 10.
ça existe déjà, tout est expliqué ici :
[^] # Re: Pour légèrement digresser
Posté par Nicolas Évrard (site web personnel, Mastodon) . Évalué à 9.
Et il y a un excellent résumé là : https://linuxfr.org/nodes/85736/comments/1226854/answer#comment-1226854
(Je sors).
[^] # Re: Pour légèrement digresser
Posté par BFG . Évalué à 6.
À noter le projet libetc qui est une bibliothèque pour "forcer" les programmes à utiliser
~/.config
.# DANGER!
Posté par maxix . Évalué à 3.
Encore de la standardisation?
Mais que fait Riguidel?!?
[^] # Re: DANGER!
Posté par AnCaRioN . Évalué à 3.
Il va bosser sur l'optimalité avec Militello.
# miguel de icaza sort de ce corps
Posté par Joris Dedieu (site web personnel) . Évalué à 5.
Faire un fichier de configuration n'était pas envisageable ?
Je n'ai rien contre l'évolution et la standardisation attention. Mais ici le prétexte est clairement fallacieux.
Mes deux cents
Joris
# il pourrait d'abord finir un truc
Posté par Albert_ . Évalué à 10.
Visiblement il aime bien lancer des trolls et tous casser mais personnellement j'aimerai bien qu'il finisse un projet quelconque avant de se lancer dans la destruction d'une autre partie de linux.
[^] # Re: il pourrait d'abord finir un truc
Posté par bubar🦥 (Mastodon) . Évalué à 5.
PulseAduoi, ça fait bien longtemps que je m'en suis débarrassé. Terminé, rouasse. Au début râlante de voir un truc nouveau débarqué, en moins bien que l'existant. Ensuite, ferme de gueule parceque faut voir l'évolution vu que tout le monde ça ne peut pas être mauvais. Patience. Aujourd'hui ? à part me poser des soucis, je n'en vois pas l'intérêt. (quant des besoins de jongler avec des cables audio virtuels sont présents : jack) Sinon c'est : ALSA only, et tout fonctionne très bien comme cela.
[^] # Re: il pourrait d'abord finir un truc
Posté par Laurent A. . Évalué à 1.
Je n'ai pas de problèmes avec PulseAudio ni avec Avahi (au fait tu as des problèmes ou c'est juste que tu penses que tu as moins de services que sous MasOSX ?).
Pas de problèmes avec systemd depuis 3 semaines que je l'utilise.
Bref, ton attaque envers Lennart, c'est juste pour te calmer ? Comme d'habitude quoi...
[^] # Re: il pourrait d'abord finir un truc
Posté par Albert_ . Évalué à 1.
PA j'ai des problemes avec comme decrit au dessus avc plusieurs distribs differentes. Ca fait des annees que l'on se coltine se truc et si c'est si difficile a installer que meme 2 ou 3 distributions (toutes sauf RH/fedora quoi) n'arrive pas a faire en sorte que le branchement d'un microphone fonctionne c'est que l'outil est mal foutu/trop complexe/fait n'importe comment.
Avahi ca fonctionne pour les deux trucs que j'ai cite mais d'apres ce que me dise les collegues utilisant MacOSX, ils s'en servent aussi pour connecter deux ordis ensemble et en particulier servir de bornes wifi (en gros cela manage aussi les reseaux ad-hoc simplement et ca j'attend encore de voir cela sous linux). Et comme je l'ai dit pour le configurer il faut copier a la mano des fichiers dans /etc/avahi/services et ca c'est tout sauf user friendly (debian et ubuntu au minimum).
[^] # Re: il pourrait d'abord finir un truc
Posté par Ph Husson (site web personnel) . Évalué à 5.
Sur mandriva (on rigole pas.), j'ai rien de pariculier à faire:
% ls /etc/avahi/services
openssh.service proftpd.service sftp-ssh.service udisks.service
%
Enfin ça parait logique, il suffit que le package du serveur en question crée un fichier là..
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.