• [^] # Re: Ce n'est pas un troll

    Posté par (site web personnel, Mastodon) . En réponse au journal Emplacement des fichiers de configuration. Évalué à 9.

    Quel rapport avec KDE? A part le fait que le gars qui semble avoir écrit ça a un email de kde.org, ce qui signifie simplement qu'il est contributeur kde, pas que cette spécification a été faite pour KDE.
    D'ailleurs comme c'est dit dans le billet principal et plus tard dans les réponses, au contraire dans KDE, ils suivent pas cette norme.

    En outre, ce que tu dis n'a aucun sens vis à vis du fonctionnement de Linux. Déjà, on n'est pas sous Windows. Il n'y a pas pas de "répertoire du logiciel". Tout logiciel est justement réparti dans divers emplacements standards en fonction de sa fonctionnalité et d'un préfixe (voire les standards GNU pour ça: http://www.gnu.org/prep/standards/ ).

    Ces standards ont un peu évolué avec le temps, mais globalement voici l'idée à l'heure actuelle:

    - Le préfixe dépend de la fonctionnalité global du logiciel, ou des besoins d'installation. A l'heure actuelle, si le préfixe est '/', il s'agit de logiciel système (donc typiquement tous les outils GNU sous une distrib GNU/Linux).
    Puis en général /usr est utilisé pour les logiciels installés par la distribution (convention qu'ont pris beaucoup de distribs répandues).
    Enfin /usr/local est pour les logiciels qu'on va installer à la main.

    Dans certains cas, le /usr et /usr/local pourraient plutôt séparer les logiciels installés en partagés dans un réseau de logiciels locaux (c'est en fait l'origine du truc, mais comme le Desktop se pose pas ce genre de questions, de nouvelles normes ont émergées avec l'arrivée des gestionnaires de paquetage). Et dans ce cas, c'est /opt qui sert plutôt de préfixe pour les logiciels installés à la main (ou en test).

    - Enfin les sous-dossiers d'install dépendent des fonctionnalités à un niveau plus bas, c'est à dire des sous-modules d'un programme. Par exemple, les librairies dans lib/, les fichiers "header" (.h en c par ex) pour les développeurs dans include/, les fichiers de config dans etc/, les manuels dans man/, les données communes à tout utilisateur qui ne sont pas destinées à être modifiées dans share/, les données communes destinées à être modifiées par le programme dans var/, les exécutables dans bin/ et ceux réservés au root dans sbin/, etc.

    Le temps a changé quelques unes de ces normes aussi. Souvent des progs vont pas utiliser $prefix/etc pour leur config, mais plutôt /etc, de même pour /var au lieu de $prefix/var.

    Et enfin les données perso utilisateurs, sans partage, sont totalement à part, dans /home.

    Le gros avantage de ces conventions d'installation?
    C'est que par exemple, en partitionnant bien, on peut sécuriser les systèmes (la plupart des emplacements n'ont besoin que d'être en lecture seule).
    Mais également on améliore aussi les possibilités de relation entres les programmes. C'est grâce à ça que les programmes ayant besoin d'une librairie ou d'un exécutable tiers savent très souvent où les trouver et donc qu'on peut utiliser des mêmes librairies ou outils pour divers logiciels. Donc gain de place, gain de mémoire, gain de temps (librairie chargée une seule fois...), etc.

    D'ailleurs en ce sens, je suis pas d'accord avec Zenitram plus haut qui trouve que c'est le bordel sous GNU et bien rangé sous Win. Pour moi c'est vraiment tout l'inverse. C'est grâce à ça qu'on arrive à réinstaller un système très rapidement, sans perdre la moindre config de logiciel au petit oignon (que ce soit perso ou système), en gardant certaines parties et en réinstallant d'autres (par ex, mes logiciels installés à la main ou développés en privé, pas besoin de les réinstaller, je garde juste /usr/local ou /opt), etc.

    En tous cas Brazz, je pense que tu as vu que tes idées que tu trouvais plus logique ne le sont plus du tout, voire n'ont aucun sens dans l'organisation de GNU.

    Sinon vis à vis de ces spécs, l'idée est très bonne car c'est en effet une norme qui manque gravement dans la réalité des développements Libres actuels sous nux. Cependant je vais envoyer un mail au gars de ce pas car je trouve plusieurs points problématiques:

    - /etc/xdg : je vois pas trop l'intérêt de ce choix. Ca fait un répertoire en trop car etc/ sert déjà à mettre les fichiers de conf, pourquoi rajouter un étage? Soit on utilise /etc comme les gens font actuellement, soit on va dans $prefix/etc comme le voudrait la norme GNU, mais je vois pas pquoi rajouter ce "xdg" qui fait double emploi.

    - Pquoi ne pas mettre les répertoires utilisateurs dans les listes par défaut comme il paraît logique de faire? Par ex $XDG_DATA_DIRS est par défaut à "/usr/local/share/:/usr/share/" alors qu'il devrait être à "$XDG_DATA_HOME:/usr/local/share/:/usr/share/ " selon la logique que les modifications utilisateurs doivent toujours être prises en comptes et précéder les confs système.

    - Le répertoire .config/ (il change l'appellation, pourquoi pas. C'est vrai que "etc" n'a pas bcp de sens et n'est là que par raison historique) devrait être sous $HOME/.local, pas directement sous $HOME. Là ça fait un rép de trop alors que le but d'une telle spéc serait justement de libérer un peu le $HOME.

    - De même pour le rép "cache".

    - Quitte à changer les appelations historiques pour l'environnement perso, autant remplacement aussi "share". C'est un nom parfait dans le concept "données système multi-utilisateur" (share = partage en anglais). Mais puisqu'on parle de données perso, ça devrait se transformer par exemple en "data" (ou autre)...

    - Et pis il aurait pu aller plus loin en mettant un var/ sous son $HOME/.local, ainsi que d'autres répertoires pris dans la norme système actuelle.

    En gros, l'idée est là, mais ça manque encore beaucoup de cohérence. Je pense que si cette spéc s'améliore dans ce sens, ce sera vraiment génial et j'espère que les dévs du monde entier la suivront alors.

    Bye.

    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]