[Truc pas KISS] Vous en pensez quoi de l'arborescence linux?

[farvardin]

Que pensez-vous de l'arborescence "traditionnelle" de linux ? Le plaisir d'avoir des /usr/bin/, /usr/local/bin, /usr/sbin/, voire pour les distributions datant du 17ème siècle des trucs inutiles comme /usr/games/ , /usr/local/games etc.
Je ne suis pas forcément contre le fait de bien séparer les binaires utilisateurs des binaires root, et j'apprécie que archlinux encourage via les pkgbuilds à n'avoir que des /usr/bin/ et non pas de /usr/local/bin/

Mais surtout, ce que je trouve bien lourdingue, c'est d'avoir par exemple une partie des données dans un /usr/share/projet, le binaire qui exécute le tout dans /usr/bin, la doc dans /usr/share/doc/projet ... (je ne parle même pas des fichiers de conf qui sont mis en vrac dans le $HOME, c'est un autre problème)

Seriez-vous favorable d'essayer de refondre cette arborescence un peu obsolète, qui trouve sa fondation et sa justification dans les systèmes unix "universitaires", où il y avait un administrateur de l'ordinateur, et 50 étudiants connectés dessus ? (c'est à dire encourager Archlinux à évoluer vers quelque chose d'autre)

Alors que maintenant on utilise les ordinateurs différemment, cette complication de l'arborescence pourrait être à revoir pour obtenir quelque chose de plus rationnel, de plus KISS en tout cas.

Exemple de GoboLinux http://www.gobolinux.org/?page=at_a_glance ou de Mac OS X. Sous Mac OS X, la désinstallation d'un programme se fait simplement en effaçant l'arborescence du programme qui contient tout ce qui est nécessaire : binaires, données, documentations. Le gestionnaire de paquet des distributions linux est un plus pour installer et déinstaller des logiciels, mais réorganiser l'arborescence pourrait (et devrait) être compatible avec ces gestionnaires de paquets.

[tuxce]

Il faudrait que tu documentes un peu plus:
http://www.pathname.com/fhs/

plusieurs points:
- tout d'abord, les répertoires "local" sont définis pour les applications/lib installés par l'utilisateur en dehors du système de paquetage ou au choix de l'administrateur, en gros, ça echappe au règles générales et c'est pour ça que tu ne trouveras aucune distribution qui y installe un paquet officiel, et si c'est le cas, c'est une erreur du mainteneur.

- ensuite la séparation des fichiers permet de ne pas se prendre la tête avec les chemins et tout ce qui va avec, un binaire "normal" est dans /usr/bin, pas besoin de connaître par coeur toutes les applications pour le savoir.
Une lib par répertoire d'applications revient à avoir la hierarchie de pc-bsd ou de windows, ce qui donne une lib par application, la multiplication de version de celle ci et automatiquement une plus grande difficulté pour débusquer les bugs sans compter les failles qu'on peut avoir à maintenir X versions d'une lib et sans parler de la difficulté pour un administrateur de suivre les liaisons pour chaque utilisateur (dont le niveau de difficulté diffère selon le cas).

- les fichiers de confs ne sont pas n'importe où dans le home, il suivent une hierarchie:
http://standards.freedesktop.org/basedi ... atest.html
si tous les softs ne la suivent pas, c'est une autre question.

pour en revenir à gobolinux, l'organisation n'est que virtuelle, en réalité, ça fonctionne comme toutes distributions linux en utilisant les liens.

Bref, la où tu vois une arborescence obsolète, j'en vois une pratique, homogène (c'est ce qui permet le portage ainsi que la réutilisation d'une distribution à l'autre) et limitant la maintenance et facilitant la recherche de bugs.

D'ailleurs si tu cherches bien, en ce qui concerne windows par exemple, les lib et programmes commum au soft microsoft sont pour la plupart regroupés dans un minimum de répertoires (pour mac os, pas assez utiliser pour en parler ).

c'est déjà un post assez long, mais il y a tellement d'avantage à cette arborescence, alors qu'à part le fait de désinstaller en supprimant (ce qui n'a pas de poids vu que c'est le gestionnaire qui s'en occupe) j'en vois pas énormément pour l'autre.

[xenom]

Bonjour.

Je préfère justement l'arborescence classique linux, même si il faudrait plusieurs améliorations. Le fait d'avoir un répertoire /etc avec les configurations, des répertoires /bin et /sbin, un repertoire /var... Ca permet un partitionnement particulier (par exemple /var/mail sur une partition particulière pour un serveur de mail,...), une sauvegarde des fichiers de conf qui sont dans /etc..
De plus cela permet de mieux gerer les droits et la sécurité (je pense par exemple à la variable PATH) et simplifie l'administration, la creation de script.

L'intérêt du regroupage par application est faible je trouve, même pour l'utilisateur, les gestionnaire de paquets sont la et s'occupent de tous bien classer/supprimer à l'(a) (des)installation.
Si je cherche le fichier de configuration du logiciel X, je sais qu'il sera dans /etc.
Pour les différentes versions d'un logiciel c'est bien mais l'arborescence classique le permet aussi.
Par contre il y a des choses à améliorer. Comme tu disais avoir un /usr/games c'est inutile comme d'autres repertoires.
Ou les fichiers de conf. utilisateurs directement dans le home, ils pourait etre placés dans un seul dossier (certaines applications le font avec le dossier .config (compiz,emesene,evince,...)).

[_alexmyself]

moi j'aime beaucoup le 'un reperoire par appli', je trouve ça d'une simpliçité..euh..oubliée

il y a surement des désavantages a cette pratique, mais mon petit cerveau aime beaucoup, c'est 'facile'.

[titoucha]

moi j'aime beaucoup le 'un reperoire par appli', je trouve ça d'une simpliçité..euh..oubliée

il y a surement des désavantages a cette pratique, mais mon petit cerveau aime beaucoup, c'est 'facile'.

Et si deux programmes utilisent la même librairie, on la copie deux fois dans chaque répertoire de programme.

[farvardin]

la séparation des fichiers permet de ne pas se prendre la tête avec les chemins et tout ce qui va avec, un binaire "normal" est dans /usr/bin, pas besoin de connaître par coeur toutes les applications pour le savoir.

si nécessaire, il est possible de faire des liens symboliques vers /usr/bin pour garder une compatibilité (voir plus bas pour gobolinux)

ce qui donne une lib par application, la multiplication de version de celle ci et automatiquement une plus grande difficulté pour débusquer les bugs sans compter les failles qu'on peut avoir à maintenir X versions d'une lib et sans parler de la difficulté pour un administrateur de suivre les liaisons pour chaque utilisateur .

l'intérêt également c'est que cela permet de séparer clairement le système de base des logiciels utilisateurs. Dans certains cas (qui n'est pas celui d'archlinux), cela peut être intéressant de garder une base stable, et de pouvoir quand même installer des logiciels récents. Toutes les bibliothèques arrivent en pack avec un logiciel fonctionnel, ce n'est pas forcément plus mal. Ayant installé des postes sous linux en entreprise, pour mon ordinateur perso ça va parce que je fais les mises à jour au fil de l'eau et je peux réparer les petits problèmes qu'il peut y avoir, mais pour la maintenance des postes des utilisateurs qui n'y connaissent rien, faire une mise à jour système complète juste parce qu'on a besoin d'avoir un firefox ou openoffice à jour, et se rendre compte ensuite que le pilote de la carte graphique est cassé ou que l'imprimante n'imprime plus, c'est plutôt galère. Honnêtement, je suis limite moins embêté avec les postes sous windows xp...

- les fichiers de confs ne sont pas n'importe où dans le home, il suivent une hierarchie:
http://standards.freedesktop.org/basedi ... atest.html
si tous les softs ne la suivent pas, c'est une autre question.

En pratique bien peu de logiciels suivent cette recommandation. Cela place la configuration utilisateur dans ~/.config/ mais on n'a que cela :

ls ~/.config/ |wc
46 46 426

à comparer avec :

ls -ad ~/.* |wc
628 628 13388

pour en revenir à gobolinux, l'organisation n'est que virtuelle, en réalité, ça fonctionne comme toutes distributions linux en utilisant les liens.

c'est plutôt l'inverse, l'organisation est réelle, et il y a des liens depuis l'arborescence classique unix vers la nouvelle organisation.

ex :

ls -al /usr/bin/less
/usr/bin/less -> ../../../Programs/Less/394/bin/less

En tout cas pour les fichiers de configuration c'est bien pratique de tout avoir dans /etc, mais là aussi, les liens symboliques peuvent permettre d'y accéder par ce biais.

Bref, la où tu vois une arborescence obsolète, j'en vois une pratique, homogène (c'est ce qui permet le portage ainsi que la réutilisation d'une distribution à l'autre) et limitant la maintenance et facilitant la recherche de bugs.

homogène, homogène, d'une distribution à l'autre je vois des différences.

Archlinux :
ls -al /usr/bin/soffice
lrwxrwxrwx 1 root root 36 janv. 26 22:35 /usr/bin/soffice -> ../../opt/openoffice/program/soffice

OpenSuse :
ls -al /usr/bin/soffice
lrwxrwxrwx 1 root root 32 août 13 13:34 /usr/bin/soffice -> /usr/lib/ooo-2.0/program/soffice

idem pour java. Chez debian on a le /usr/games, sur les bsd on a les binaires pour les gestionnaires de fenêtres ailleurs que dans la place "habituelle", genre /usr/bin/X11/

D'ailleurs pour compiler et empaqueter les logiciels d'une distribution à l'autre, chacun est obligé de faire sa propre recette et ne peut utiliser le travail des autres distribution, même sur les distributions avec la même base rpm.

Et si deux programmes utilisent la même librairie, on la copie deux fois dans chaque répertoire de programme.

Avec la place qu'ont les disques durs actuellement, dans beaucoup de cas cela ne serait pas vraiment un problème. On dirait que sous Mac OS X cela n'est pas vraiment un soucis.

[chipster]

Ça ressemble à du winwin ton organisation. Perso quand on voit la réflexion portée par les gars de chez crosoft sur l'arbo, ont peu émettre des doutes.
Par contre, les gars de chez unix, eux ils ont pensé leur arbo donc je ne vois pas pourquoi on remettrait en cause quelque chose qui fonctionne bien, qui casserait toutes les compatibilités, ...
En gros inutile pour ma part

[farvardin]

ben tu sais, les trucs issus de chez windows, je m'en méfie généralement. Mais bien avant windows il y avait un truc épatant qui s'appelait NeXT, et qui utilisait une arborescence similaire, que l'on retrouve maintenant sous Mac OS X qui est pourtant un Unix tout autant que Gnu/Linux...

[mélodie]

Mais bien avant windows il y avait un truc épatant qui s'appelait NeXT, et qui utilisait une arborescence similaire

Ça tournerait presque en troll, mais culturé hein ?

(......)C’est sur un ordinateur NeXT que Tim Berners-Lee inventa le World Wide Web au CERN. De son côté, John Carmack a utilisé un NeXT Cube pour développer ses deux jeux vedettes : Wolfenstein 3D et Doom.(.....)

[chipster]

ben tu sais, les trucs issus de chez windows, je m'en méfie généralement. Mais bien avant windows il y avait un truc épatant qui s'appelait NeXT, et qui utilisait une arborescence similaire, que l'on retrouve maintenant sous Mac OS X qui est pourtant un Unix tout autant que Gnu/Linux...

NeXT avait des bonnes choses comme des mauvaises.
Et puis comme je te l'ai dit, si tu changes, faut refaire l'intégralité des softs linux soit sur le paquet, soit sur la conseption interne. Paie ta galère et tes bug.
D'autres parts, ça serivrait à quoi ?
Perso une fois habitué, ça coule de source

[gyo]

ben tu sais, les trucs issus de chez windows, je m'en méfie généralement. Mais bien avant windows il y avait un truc épatant qui s'appelait NeXT, et qui utilisait une arborescence similaire, que l'on retrouve maintenant sous Mac OS X qui est pourtant un Unix tout autant que Gnu/Linux...

NeXT avait des bonnes choses comme des mauvaises.
Et puis comme je te l'ai dit, si tu changes, faut refaire l'intégralité des softs linux soit sur le paquet, soit sur la conseption interne. Paie ta galère et tes bug.
D'autres parts, ça serivrait à quoi ?
Perso une fois habitué, ça coule de source

Gobolinux s’en sort très bien de ce côté-là. Ça installe en dur dans chaque logiciel dans leur propre arbo et ensuite ça fait des liens dans les répertoires /usr/bin, /usr/lib, /usr/share, /etc, etc.
Du temps que j’étais sous LFS, j’utilisais un gestionnaire à la stow (que j’avais réimplémenté en bash).
Et c’était vraiment KISS à mettre en place et à gérer, la « BDD » étant représentée par l’arbo de chaque logiciel installé et en faisant un ls -l lebinaire, par exemple, ben on sait tout de suite quelle est la version, à quel logiciel ça appartient. En plus, ça respecte la FHS.

[tuxce]

si nécessaire, il est possible de faire des liens symboliques vers /usr/bin pour garder une compatibilité (voir plus bas pour gobolinux)

pour en revenir à gobolinux, l'organisation n'est que virtuelle, en réalité, ça fonctionne comme toutes distributions linux en utilisant les liens.

c'est plutôt l'inverse, l'organisation est réelle, et il y a des liens depuis l'arborescence classique unix vers la nouvelle organisation.

ex :

ls -al /usr/bin/less
/usr/bin/less -> ../../../Programs/Less/394/bin/less

c'est ce que je disais, enfin virtuelle/réelle, peu importe ce que je voulais dire par là, c'est que l'arborescence reste celle de linux pour l'application.

l'intérêt également c'est que cela permet de séparer clairement le système de base des logiciels utilisateurs. Dans certains cas (qui n'est pas celui d'archlinux), cela peut être intéressant de garder une base stable, et de pouvoir quand même installer des logiciels récents.

c'est à cela qu'est dédié le /usr/local, à y installer tout ce qui n'est pas en rapport direct avec le système, sinon, l'installation de soft n'est pas considéré comme faisant partie de l'espace utilisateur, sinon, un utilisateur peut très bien installer un soft sur son répertoire comme firefox par exemple, avec un rep par soft.

En pratique bien peu de logiciels suivent cette recommandation. Cela place la configuration utilisateur dans ~/.config/ mais on n'a que cela :

ls ~/.config/ |wc
46 46 426

à comparer avec :

ls -ad ~/.* |wc
628 628 13388

le ~/.* cible aussi les fichiers dans le "..", c'est ~/.??* plutôt
sinon, le fait que les applications ne suivent pas un standard ne rend pas pour autant ce standard inutile, le .config est par exemple suivi par tout ce qui est applications gnome.
de toute façon, pour la config, c'est dans les faits un repertoire/applications pour la plupart des softs récents, /etc/ pour une conf système d'un soft en dehors de l'utilisation utilisateur et $XDG_CONFIG_DIRS pour les softs liés à l'utilisateur et enfin $XDF_CONFIG_HOME (.config par défaut) pour ce qui est propre à l'utilisateur.

homogène, homogène, d'une distribution à l'autre je vois des différences.

Archlinux :
ls -al /usr/bin/soffice
lrwxrwxrwx 1 root root 36 janv. 26 22:35 /usr/bin/soffice -> ../../opt/openoffice/program/soffice

OpenSuse :
ls -al /usr/bin/soffice
lrwxrwxrwx 1 root root 32 août 13 13:34 /usr/bin/soffice -> /usr/lib/ooo-2.0/program/soffice

ce n'est qu'une histoire de lien, le binaire est au même endroit

idem pour java. Chez debian on a le /usr/games, sur les bsd on a les binaires pour les gestionnaires de fenêtres ailleurs que dans la place "habituelle", genre /usr/bin/X11/

/usr/bin/X11 sous debian est un lien vers /usr/bin, il existe pour garder une compatibilité avec de vieux soft X de l'époque X11R6

D'ailleurs pour compiler et empaqueter les logiciels d'une distribution à l'autre, chacun est obligé de faire sa propre recette et ne peut utiliser le travail des autres distribution, même sur les distributions avec la même base rpm.

Ce que fait un paquet est très différent de ce que fait une make && make install, le paquet applique des patch, configure et installe, chaque distribution a ses propres paramètres (et surtout quand ça se rapporte à des éléments système tel que le réseau ou autre), par contre, tu prends n'importe quel soft respectant les standards autotools (qui respectent fhs), specs freedesktop, (et j'en oublie surement), un

Code : Tout sélectionner

./configure --prefix=/usr&& make && make install

te l'installera toujours au bon endroit et fonctionnera pareil quelque soit la distribution.
et par défaut, il s'installe dans la hierarchie /usr/local pour pas géner le reste.


En clair, tu parles
- d'homogénéité, or de la même façon que 2 paquets installent différemment dans l'arborescence actuelle, il installeront différemment dans toute autre interface (un mainteneur mettra OO dans programs/OpenOffice, un autre dans programs/soffice etc...)
- de liens, ce qui revient à toujours avoir derrière l'arborescence actuelle, et rien n'empêche actuellement ce qui est le cas pour certains soft de tous placer dans par exemple /usr/lib/l'application et de lier ensuite (mais ça génera les admins pour la gestion des partitions/sauvegarde etc...)
- de facilité pour l'utilisateur, ce n'est qu'un avis, mais je trouve plus simple d'aller chercher dans /etc/ (au moins on a que la config) plutôt que de se pallucher tous les répertoires de l'appli pour trouver le bon fichier à modifier.

et juste pour finir mon post, l'utilisation d'un macos est très différente d'un linux, essaie de taper le nom de l'executable d'un programme sous un terminal, je me demande s'il se lance (si je me rappelle bien, il faut utiliser un équivalent du start de windows, open ?)