Il soulève l'impossibilité de facto de maintenir son installation sans passer par les outils de paquetage.
Mosfet : Rage against the File System Standard
22
nov.
2001
Mosfet, célèbre (et turbulent) (ex)contributeur au projet KDE, nous livre ses impressions sur la hiérarchie des répertoires utilisés par les distributions Linux. Selon lui, le problème remonte aux premières versions de la RedHat. Les développeurs de cette distribution ont pris l'habitude de mettre tout dans /usr parce qu'ils sont fainéants et toutes les autres distributions ont suivi par soucis de compatibilité.
Il soulève l'impossibilité de facto de maintenir son installation sans passer par les outils de paquetage.
Il soulève l'impossibilité de facto de maintenir son installation sans passer par les outils de paquetage.
# je comprend pas non plus
Posté par snurpsss . Évalué à -10.
La transparence et la clarté ne sont ils pas les mettre mots de linux ?
[^] # Re: je comprend pas non plus
Posté par Yohann (site web personnel) . Évalué à 10.
Je n'ai pas lu moosfet, mais je trouve que l'arborescence est tres bien. /usr pour le system et ses amis, /usr/local pour les truc systeme moins important ou en test, /opt pour les appli genre gnome, mozilla, les jeux...
Le gros probleme c'est que cette arborescence est trop bien pense, on tombe souvent sur des cas ambigue,ou bien on oublie qu'il y a deja un repertoire pour ca. De plus tu as la possibilite de jongler avec plusieur disque dur, ce qui est vraiment sympa...
En plus il y a pas mal de doc sur l'organisation des repertoires...
[^] # Re: je comprend pas non plus
Posté par kadreg . Évalué à 10.
Tu devrais lire le texte, car c'est justement un des reproche. Redhat (et les autres) mettent dans /usr gnome KDE, mozilla, etc ... alors que pour lui (et pour toi), c'est des programmes qui doivent aller dans /opt/
[^] # Re: je comprend pas non plus
Posté par kalahann . Évalué à 10.
Il ne faut pas croire que d'après mosfet toute application devrait avoir son répertoire (on se retrouverai avec 500 fichiers et 1000 sous-répertoires c'est pas beaucoup mieux que 2000 fichiers). Sa réflection, c'est que toute application *importante* comme gnome, kde, mozilla, openoffice... soit dans une sous-arborescence à part. ex: toutes les applis gnome (y compris gnome lui-même) dans usr/X11R6/gnome, avec un sous-répertoire lib pour gnome-lib, gnomeui, ...
En fait ce qu'il faudrait faire, c'est recréer l'ensemble de répertoires usr-lib-include-etc-... pour chaque projet important (je re-cite: x, gnome, kde, mozilla...)Vous remarquerez que c'est déjà le cas pour x... justement parce que X était standard avant l'arrivée des red hat et autres qui ont imposé de facto une arborescence simpliste des fichiers sous linux...
[^] # Re: je comprend pas non plus
Posté par bad sheep (site web personnel) . Évalué à 1.
regarde ça : http://www.mandrakesoft.com/company/community/projects#kde(...)
tu verras son nom entre parenthèses... C'est pas celui d'une femme... :)
[^] # Re: je comprend pas non plus
Posté par Jean-Yves B. . Évalué à -10.
Ah tiens ? Alors l'opération à très bien réussi.
Elle ressemble sacrément à une femme, goth, mais une femme quand même.
http://mosfet.org/about.html(...)
Bon, -1 parce que vie privée et sans intérêt.
[^] # Re: je comprend pas non plus
Posté par Jean-Yves B. . Évalué à -10.
fabien ! a quand le cancel de posts ?
[^] # Re: je comprend pas non plus
Posté par Annah C. Hue (site web personnel) . Évalué à -7.
(*)c'est normal que mosfet grogne sur le LFS, car il utilise une distrib de merde. Si il utilisait une vraie distrib comme debian, il n'aurait pas eu à ce poser ce genre de questions.
[^] # Re: je comprend pas non plus
Posté par C2RIK . Évalué à 10.
Non dans la Debian (pour la potato que j'utlise) tout est stocké dans /usr !!!
Je n'ai par exemple dans /usr/local que ce que j'ai compilé et /opt n'existe pas !!! De ce point de vue, la slackware est mieux foutue à mon goût.
[^] # Re: je comprend pas non plus
Posté par Robert Palmer (site web personnel) . Évalué à -5.
Cette photo là est plus à son avantage :
http://www.kde.org/gallery/index.html#mosfet(...)
</gala>
-1
Pensez à l'environnement avant d'imprimer ce commentaire - Please consider the environment before printing this comment
[^] # Re: je comprend pas non plus
Posté par kadreg . Évalué à 10.
Dans un unix, on a un premier sous ensemble, qui permet de booter le système et de le réparer en cas de catastrophe. C'est dans /
Ensuite, on a un premier niveau qui est l'utilisation au niveau shell (pas de X encore). c'est /usr qui nous permet de faire ça.
Maintenant, au dessus du shell, on a X, qui va nous permettre de génrer nos fenêtres. et hop, /usr/X11
Ensuite, l'environnement de travail (KDE, gnome ou GNUStep), ca va dans /usr/X11/[gnome|KDE|GNUStep]
On remarquera que chaque nouvelle couche est au dessus de la précédente, et donc est dans un de ses sous répertoire.
Il y a de l'idée finalement.
[^] # Re: je comprend pas non plus
Posté par Sylvain (site web personnel) . Évalué à -4.
non non, c'est bien 'lui' et pas 'elle', il a les cheveux longs, mais c'est bien un mec il me semble...
[^] # Re: je comprend pas non plus
Posté par rouge13 . Évalué à 9.
Décidement cette rumeur à la vie dure, c'est bien un mec malgré les apparences, même si il joue sur cette ambiguité (ya qu'a voir la perruque verte).
Sinon, c'est une des voie à explorer pour l'arborescence que tu suggère. J'ai l'impression que Linux souffre de plus en plus de l'héritage d'Unix (le dinosaure des OS).
Linux n'est pas Unix, définitivement, réorganiser l'arborescence pour clarifier tout ça ne serait pas un luxe pour un système moderne.
[^] # Re: je comprend pas non plus
Posté par vrm (site web personnel) . Évalué à 10.
[^] # Re: je comprend pas non plus
Posté par Patrice Fortier . Évalué à 10.
Sun avait mis Openview ds un répertoire spécial, et qd CDE est devenu le "bureau" par défaut, il a eu droit aussi a son répertoire bien à lui.
L'héritage Unix a disparu.
KDE et Gnome auraient mérité un rep à eux. La seule question a se poser est la place de Qt/gtk dans ce schéma (et encore...).
[^] # Re: je comprend pas non plus
Posté par Patrice Fortier . Évalué à 0.
mea culpa.
[^] # Re: je comprend pas non plus
Posté par #3588 . Évalué à 10.
Mais pourquoi ne pas mettre tout le système dans /usr, en particulier X11 comme le reste, sans sous-répertoire particulier ? Evidemment usr/X11/ c'est devenu le standard...
Je verrais plutot le /usr pour le systeme (ie dans les distrib GNU/Linux, tout ce qui s'installe par des paquets), et usr/local pour les installations perso qui ne passent pas par le système de paquets. Parce que si on commence à prévoir un répertoire Gnome, KDE, Qt, on ne trouvera jamais de limite franche entre ce qui doit avoir son répertoire et ce qui doit aller dans /usr. Mozilla par exemple, pourquoi lui donner un répertoire ? Certains le préconisent, mais je ne vois pas trop pourquoi ?
[^] # Re: je comprend pas non plus
Posté par vrm (site web personnel) . Évalué à 6.
le tout à été changé pour la compatibilité redhat ..
[^] # Re: je comprend pas non plus
Posté par Thomas RIBO . Évalué à 7.
Si tu as /usr/X11/KDE par exemple, tu as la possibilité de recenser tous les binaires par exemple pour faire des liens dans ton interface graphique et regrouper tous les trucs KDE dans un menu... (je dis n'importe quoi). Et puis tu peux aussi tout désinstaller simplement en effaçant le dossier. Hormis le fait que ce soit dangereux pour, c'est quand même bien pratique non ?
[^] # Re: je comprend pas non plus
Posté par #3588 . Évalué à 3.
En fait je pensais plus à un très bon gestionnaire de paquetage, par lequel tu passes pour récupérer ces infos. Je crois que ça existe déja, avec apt-get ou rpm, la possibilité de savoir quel fichier vient de quel package, non ? Ensuite il faut traiter l'info, c'est sur, mais c'était plutot ça l'idée...
Si tu as /usr/X11/KDE par exemple, tu as la possibilité de recenser tous les binaires par exemple pour faire des liens dans ton interface graphique et regrouper tous les trucs KDE dans un menu... (je dis n'importe quoi).
Eh bien le cas idéal serait donc non pas de lire l'info simplement par lecture du répertoire, mais par un "apt-machin kde --binaries" qui serait équivalent à ton "ls /usr/X11/KDE/bin" par exemple.
Et puis tu peux aussi tout désinstaller simplement en effaçant le dossier. Hormis le fait que ce soit dangereux pour, c'est quand même bien pratique non ?
Idem. Il faudrait pouvoir tracer l'installation de dépendances, et déterminer ou non s'il faut les supprimer (une par une) lorsqu'on désinstalle le package qui les a réclamées à l'install.
Evidemment, cet outil idéal n'existe pas encore. Mais on voit ce qu'on y gagne à l'installation, les gestion automatisée des dépendances c'est bien appréciable. Donc je préférerais voir le FHS avec moins de /opt et autres, pour inciter à l'amélioration des gestionnaires de packages. En attendant, évidemment, un répertoire et du rm -f c'est plus simple...
[^] # Re: je comprend pas non plus
Posté par Prosper . Évalué à 5.
avec urpmi(i)(f)(e)(q)(...) et rpm ca marche en effet
rpm -ql nom_du_package te sort les fichiers
urpmf nom du fichier te sort tous les paquetages
ou ce nom est contenu.
Idem. Il faudrait pouvoir tracer l'installation de dépendances, et déterminer ou non s'il faut les supprimer (une par une) lorsqu'on désinstalle le package qui les a réclamées à l'install.
rpm -q --requires nom_de_ton_truc te sort
les dependances
Entres autres choses urpm(X) gere les dependances
de packages
[^] # Re: je comprend pas non plus
Posté par #3588 . Évalué à 1.
Oui, mais je ne parle pas de ça, mais de la trace des installations de dépendance, et le "pourquoi" de ces installations.
J'ai précisé ça dans un autre post plus bas (exemple avec Gimp et GTK)
[^] # Re: je comprend pas non plus
Posté par Thomas RIBO . Évalué à 1.
Et là j'avoue que je suis d'accord avec lui. Ce n'est pas parce que l'arborescence sera mieux que je n'utiliserai plus RPM ou APT, là n'est pas le problème. Le problème c'est qu'on se sert de ces outils comme prétextes pour ne rien ranger...
[^] # Re: je comprend pas non plus
Posté par EvilTheCat . Évalué à -6.
voila voila !
[^] # Si quelqu'un ...
Posté par kadreg . Évalué à -7.
http://kadreg.free.fr/perso/coccilimule.jpg(...)
Je suis preneur. Pourtant, elle a pas les cheveux long.
[^] # Re: Si quelqu'un ...
Posté par Troy McClure (site web personnel) . Évalué à -5.
(hop, +1 parce que je le vaut bien)
[^] # Reorganisation
Posté par Jean-Pierre Schwickerath (site web personnel) . Évalué à 7.
Ca a l'avantage ne rien installer ou cela ne doit pas ^etre. Et si je veux mettre mon vim dans /usr/local/bin also je le fait....
Mais je veux dire reorganisation c'est cool, mais il faut que les gens s'y tiennent, et les distributions aussi
[^] # Re: je comprend pas non plus
Posté par lorky . Évalué à 3.
bon d'accord c'est pas evident quand tu le voit pour la premiere fois ;-)
[^] # Re: je comprend pas non plus
Posté par pa_pitufo_pa . Évalué à -9.
non, Mosfet n'est pas une femme, mais bel et bien mec (son vrai nom est Daniel M. Dudley)
bon d'accord c'est pas evident quand tu le voit pour la premiere fois ;-)
moi aussi je veut des XP
[^] # Re: je comprend pas non plus
Posté par kalahann . Évalué à 10.
Pour en revenir à la hiérarchie: Le seul intérêt je trouve à tout mettre dans /usr, /usr/local ou /opt, c'est la simplification du PATH, qui est relativement chiant à gérer, et qu'il faudrait changer à chaque modif. Cela dit, ce serait pas très difficile à faire, après tout les distrib gèrent bien les /etc/rc?.d alors pourquoi pas /etc/path...
Surtout qu'il y aurait un moyen très simple de contourner le problème: tout programme installé dans son répertoire a un lien symbolique créé dans /usr ou /usr/X, ce qui permet de s'affranchir de modifier PATH.
Ce qu'il faudrait à tout prix éviter c'est le réflexe inverse: chaque application a son répertoire (technique à la "program files"). C'est horrible à gérer. SA PU LE PATé
Le mieux, ce serait que chaque "grosse" appli (grosse restant à définir...)) s'installe dans le répertoire du sous-système auquel elle appartient: système de base (/), système (/usr), X (/usr/X), desktop (/usr/X/mondesktop), sgbd (/usr/oracle), bloatware (/usr/X/mozilla), serveur web avec ses innombrables modules (/usr/httpd)
Mais il se pose toujours des pb supplémentaires: ex du programme d'admin graphique d'oracle (/usr/oracle ou /usr/X ?) ou du programme bateau avec des plug-ins gtk ET qt (licq par exemple, ou les dock-apps multi-wm) Dans ce cas, le plus pratique c'est toujours le plus grand dénominateur commun (ex de licq qu'on pourrait coller dans /usr/X/kde ou /usr/X/gnome -> hop dans /usr/X)
[^] # Re: je comprend pas non plus
Posté par Prosper . Évalué à 0.
t as pratiquement tout dans /usr/lib/mozilla
y a juste le script mozilla dans /usr/bin
et dans /usr/lib les librairies que d autres programmes utilisent ( genre galeon )
pareil pour staroffice , wine , netscape ...les gros trucs quoi.
[^] # Re: je comprend pas non plus
Posté par kael . Évalué à 6.
je crois que c'est la solution la plus simple
et puis pour reparler des origines d'unix /usr contenait a la base les fichiers utilisateurs comme le nom l'indique comme quoi red hat a pas eu grand mal a prendre ca pour un depotoire (heritage ? :) )...
[^] # Re: je comprend pas non plus
Posté par Jean-Pierre Schwickerath (site web personnel) . Évalué à 0.
Etpour le path, ya un truc comme /etc/profile dans lequel on peut definier export PATH=$PATH:/usr/local/bla:/opt/bla....
et tout marche au mieu
[^] # Re: je comprend pas non plus
Posté par Étienne . Évalué à 2.
En fait ce qu'il faudrait faire, c'est recréer l'ensemble de répertoires usr-lib-include-etc-... pour chaque projet important (je re-cite: x, gnome, kde, mozilla...)Vous remarquerez que c'est déjà le cas pour x... justement parce que X était standard avant l'arrivée des red hat et autres qui ont imposé de facto une arborescence simpliste des fichiers sous linux...
En fait il y a deux approches, soit on crée un répertoire par "projet" et on met dedans un repertoire pour les libs, un pour les headers, un pour les programmes, un pour les docs, ...
Soit un cré un repertoire pour les libs (/usr/lib) avec un sous répertoire pour les différents projets (/usr/lib/gnome-libs), un répertoire pour les donnée (/usr/share/gnome), un répertoire pour les doc (/usr/doc/) et puis quelques répertoires pour les programmes (/usr/bin /usr/X11R6/bin /usr/local/bin ) pour mettre les programmes histoire de pas avoir un PATH trop long.
Il y a différents moyens de séparer les choses, l'orientation qui a été prise par RedHat en vaut bien une autre. Après c'est une question de goùt mais surtout d'habitude.
[^] # Re: je comprend pas non plus
Posté par bad sheep (site web personnel) . Évalué à 10.
Ce que je reproche le plus aux packages (ceci dit, je ne connais pas toutes leurs fonctionnalités), c'est l'impossibilité de les installer pour un utilisateur lambda par le système de packages...
Le prob venant alors des versions multiples installées sur un même système du même programme plusieurs fois... évidemment. Mais il doit sans doute exister une parade à cela (un package installé par deux users pourrait partager les mêmes ressources par ex...)
Enfin, c'est déjà un tel bordel... ce ne sera sans doute jamais le cas : qu'on standardise déjà l'arborescence entre les différentes distribs, ce sera déjà un plus (je sais, c'est en cours)
[^] # Re: je comprend pas non plus
Posté par Jar Jar Binks (site web personnel) . Évalué à 7.
Je ne veux pas dire de conneries, mais il me semble que ça doit être possible (mais sûrement pas de façon simple) avec apt. En effet, il peut être lancé par l'utilisateur, et reconfiguré de tout partout.
[^] # Re: je comprend pas non plus
Posté par Orphée . Évalué à 2.
Comme premier message dans une discussion, pour dégoûter le lecteur de continuer, il n'y a guère mieux...
[^] # Re: je comprend pas non plus
Posté par Jean-Pierre Schwickerath (site web personnel) . Évalué à 1.
[^] # Re: je comprend pas non plus [le retour]
Posté par snurpsss . Évalué à -2.
un repertoir de commande system ; un repertoire de conf ( I LoVe /Etc ) idem pour var ; et un repertoire /usr , mais celui ci correctement ordonnancé : exemple de X11 ca c bien . pourkoi pas faire pareil et ranger ds /usr/X11R6/wm/gnome(kde , windowsmaker) les windows manager ET tout leur fichiers img ; combien de tps perdu a cherche tel ou tel image .
Plus serieusement , il me semble qu une news est passé sur un organisme qui essaye de standardisé les distrib linux , si qqu un retrouve cette newnews , ca serai cool de la faire defiler , histoire de voir ou ils en sont de leur reflexion
See u Soon ,
++++++++++++++++++
rm -d -force -extremforce -gotodirectpoubelle /bill\ gates
[^] # Re: je comprend pas non plus [le retour]
Posté par a_jr . Évalué à 6.
Mais ca a un enorme inconvenient: la mise a jour de la variable ${PATH} ainsi que celle des repertoires de libs (ld.so.conf ou ${LD_LIBRARY_PATH}).
Je suis plutot pour des groupes d'applications. Un groupe admin (dans /sbin), un groupe de commandes de base (dans /usr), un groupe de commande X de base (dans /usr/X11). Puis pour le bureau, un repertoire pour gnome|kde|autre. Et enfin, un repertoire a applis diverses.
Quand une machine est dediee a une tache, on peut aussi creer un repertoire specifique a cette tache. Ainsi, on pourra trouver un repertoire apache+postgresql+php et un autre repertoire de documents (htdocs, cvs...)
Apres, et pour en revenir a windows, tous les utilisateurs accedent aux programmes via le menu demarrer. Sur mon gnome, le menu est bien fait et complet: je passe souvent par la quand je ne developpe pas.
Et pour les adeptes de la commande en ligne (j'en suis, malgre les apparences), rien n'empeche de maintenir la variable PATH a jour.
Windows n'a pas que du mauvais, il faut savoir s'en inspirer des fois. Mais il ne faut pas copier, car en copiant, on copie le truc bien et une dizaine de trucs pas bien sans s'en apercevoir. Faut comprendre ce dont on s'inspire.
Le bonjour chez vous,
Yves
[^] # C'est vrai que windows est pas mal, si si :
Posté par poil oq . Évalué à 4.
Si on avait ça sous linux, on aurait les mêmes menus dans kde, gnome, windowmaker, twm, etc...
Et on aurait pas besoin de mettre à jour tous les menus quand on utilise plusieurs gestionnaires de fenêtres.
et je parle pas de la profondeur des menus quand on accède aux menus gnome depuis kde et vice-versa.
et aussi moi je me sers principalement de windowmaker, et pas un rpm sur les redhat ne met à jour les menus.
J'ai dis une connerie ou d'autres ici sont d'accord (ou presque).
[^] # Re: C'est vrai que windows est pas mal, si si :
Posté par Neryel . Évalué à 3.
[^] # Re: C'est vrai que windows est pas mal, si si :
Posté par Hugues . Évalué à 3.
...mais sur le plan pratique, je suis bien d'accord ! Je ne vois aucune bonne raison pour maintenir plusieurs arborescences différentes pour les différents systèmes graphiques.
Ceci dit, le pb discuté relève plus de l'héritage (et l'utilisation) de la ligne de commande, qui doit pouvoir trouver 'tous' les executables facilement.
Mais dire que la seule solution, c'est d'avoir tous les binaires dans le me^me répertoire, ne me parait pas crédible, c'est effectivement de la facilité.
Plus haut, on dit qu'u répertoire par apps, c'est horrible, mais au moins ça a le mérite de la clarté !
[^] # Re: C'est vrai que windows est pas mal, si si :
Posté par Jean-Pierre Schwickerath (site web personnel) . Évalué à 6.
Et pour etre honnete, le monsieur martin utilisation standard, il s'en moque ou se trouvent ses programmes, et si c'est le bordel dans le systeme de fichiers. Tant que ca tourne, tout va bien pour lui et d'un cote il a raison.
Ya que nous, les admins et les bidoulleurs qu'on s'enerve sur ces choses la.
Je ne vois pas de difference entre le type qui sous windows lance son install.exe et fait suivant, accepter la license, instalation standard, repertoire standard, suivant, copie de fichier, reboot.
et rpm -i bla.rpm && bla
La seule diff c'est qu'il n'y a pas de reboot et moins de clicks se souris. En installant un rpm (ou un deb) on ne se fait pas de soucis du repertoire ou cela va se trouver.
Il n'y a que lorsqu'on compile la soupe soit meme, qu'on y reflechit deux fois
[^] # Re: C'est vrai que windows est pas mal, si si :
Posté par benja . Évalué à -4.
Installe une deb.
[^] # Re: C'est vrai que windows est pas mal, si si :
Posté par poil oq . Évalué à -3.
je vais répondre quand même :
je te merde ! ;o)
[^] # Re: C'est vrai que windows est pas mal, si si :
Posté par Schneider Dark . Évalué à 1.
elle utilise le système de menus unifié de la debian et update-menus met les menus à jours ( rpm -mdk of course ).
[^] # Re: C'est vrai que windows est pas mal, si si :
Posté par Da Scritch (site web personnel, Mastodon) . Évalué à 5.
Je crois qu'il ont gardé la même idée pour MacOsX.
Comme ce dernier est basé sur un noyau Mach (*BSD), y'a de la graîne à prendre.
Simplification de l'organigramme, uniformisation des menus d'applications.
Bientot une distrib linuxfr ????
non pas la tête.
Aïe (bobo!)
[^] # Re: C'est vrai que windows est pas mal, si si :
Posté par Prosper . Évalué à 1.
Les deux desktops utilisent pour les "raccourcis" ou les menus non pas des liens mais des toto.desktop (pour une application toto)
dans ce .desktop est contenu le chemin de l application , le nom qui apparait dans toutes les langues , des variables , s il doit s executer dans un terminal , des icones associées ( 16 , 256 et 16M de couleurs)...
# Y'a pas 50 solutions
Posté par Annah C. Hue (site web personnel) . Évalué à 10.
Mais cette dernière solution, si elle présente l'avantage évident de faciliter la gestion (rm -fr /opt/application_name/ ), présente des inconvénient indéniables en terme de performances.
En effet, pour gérer ça il faut ajouter un répertoire au PATH, au LD_LIBRARY_PATH, au MAN_PATH et j'en path (désolé). Quand ces variables d'environnement font 50 km de long, le fait de lancer une commande oblige le shell à se balader dans les 50000 répertoire bin/ des applis, et ça met un temps certain.
Un compromis est sans doute de faire un répertoire /opt/ma_grosse_appli, et de mettre les outils standards ou avec peu de fichiers dans les répertoires normaux, mais un système de package reste nécessaire.
[^] # Re: Y'a pas 50 solutions
Posté par sbruchet . Évalué à 7.
Le problemme du path trop long est un faut problemme enfin je pense.
Moi je trouve qu'il serait preferable, il est vraie que toute application soit installé dans des répertoires organisés par fonction ou theme.
Enfin le mieux c'est quand meme de s'appuyer sur la norme FS2 qui a été sortie Nan ???
[^] # Re: Y'a pas 50 solutions
Posté par Prosper . Évalué à 6.
mais pour les librairies soit tu vas charger ton LD_LIBRARY_PATH soit ton /etc/ld.so.conf et ton shell il va souffrir si t as 1000 chemins
[^] # Re: Y'a pas 50 solutions
Posté par Johann Deneux . Évalué à 6.
[^] # Re: Y'a pas 50 solutions
Posté par Alphonse Oncle . Évalué à 0.
En csh, contrairement au bash, le path est limite a 255 caracteres (et le nom des vars d'environnment a 21 caracteres).
Ca peut donc etre genant.
[^] # Re: Y'a pas 50 solutions
Posté par sbruchet . Évalué à 1.
[^] # Re: Y'a pas 50 solutions
Posté par Da Scritch (site web personnel, Mastodon) . Évalué à 0.
Son seul inconvénient : si t'en a des dizaines de milliers, cela devient lourd pour tous les nettoyer s'il y a eu des installs/désinstalls
[^] # Re: Y'a pas 50 solutions
Posté par Antoine Labour . Évalué à 1.
[^] # Re: Y'a pas 50 solutions
Posté par Miod in the middle . Évalué à 10.
Seule cette opération de mise en cache est relativement longue; ensuite, il n'y a pas de pénalité à avoir un PATH de grande longueur.
Pour les bibliothèques, c'est un peu la même chose.
Sur un système correctement administré, la quasi totalité des bibliothèques dynamiques dont auront besoin les programmes sont dans les chemins du système (/etc/ld.so.conf), et une recherche prémachée à l'intention de ld.so, effectuée par les soins de ldconfig au démarrage du système, est disponible (/var/run/ld.so.cache ou approchant, selon le système).
Si l'utilisateur a besoin d'utiliser la variable LD_LIBRARY_PATH, ce ne sera que pour un ou deux répertoires et de manière occasionnelle.
La encore, on ne peut pas considérer qu'il y a une perte de performance.
[^] # Re: Y'a pas 50 solutions
Posté par Annah C. Hue (site web personnel) . Évalué à 10.
Pour les bibliothèques (et les mans) c'est plus un problème d'administration que de performance, ce qu'on gagne en mettant tout dans un répertoire, on le perd en devant modifier les fichiers de conf avant d'avoir une appli pleinement utilisable. Mais c'est ça qu'est beau avec unix, chacun fait comme il veut.
[^] # Re: Y'a pas 50 solutions
Posté par gabuzo . Évalué à 6.
Pour les commandes systèmes il n'y aurait pas de problème car elles seraient naturellement dans /usr/bin qui serait en début de PATH. Pour le reste (les appli qui auraient leur propre répertoire) je pense que l'impact serait en négligeable (passer 2 secondes de plus dans la lancement de gimp) et nul (si on les lance à partir d'un desktop manager qui aura la path complet).
Pour le man et les lib il faudrait effectivement faire qq chose mais c'est assez simple d'ajouter en perl une ligne dans un fichier de conf ...
[^] # Re: Y'a pas 50 solutions
Posté par vrm (site web personnel) . Évalué à 4.
/opt/X11
/opt/Kde
/opt/Gnome
# Pas franchement d'accord
Posté par kadreg . Évalué à 10.
De toutes façon, dès que tu commence à utiliser des bibliothèques partagées, il faut mieux utiliser les package (paquetages ?) pour connaitre (et donc maitriser) les impacts d'une bibliothèque (et là, même si range bien, tu va les sentir passer). On peut bien entendu utiliser des scripts a base de ld pour explorer les dépendences dynamiquement, mais quelle lourdeur.
De plus, certaines partie semblent en fouilli (/usr/bin est effectivement bien rempli), mais il s'agit également de minimiser le bordel dans le PATH. Je conseille d'aller voir dans /usr/libexec ou /usr/share (ou /opt pour ceux qui en ont un) pour ce rendre compte que le rangement par application existe également.
[^] # Re: Pas franchement d'accord
Posté par Yohann (site web personnel) . Évalué à -1.
paquets...
[^] # Re: Pas franchement d'accord
Posté par Anonyme . Évalué à 2.
Je vais prendre l'exemple de Gnome parce que c'est le seul que j'ai compilé moi même, mais je suppose que c'est pareil pour le reste.
L'ensemble des librairies de base de Gnome est important ; il faut une bonne dizaine de librairies pour installer une application Gnome. Chacune de ces librairies a besoin d'un certain nombre d'autres, ce qui fait que si on ne compile pas dans le bon ordre, on se retrouve avec des messages du genre "je trouve pas la lib truc" (eh merde !).
Une fois que tu as la lib truc, tu tentes de la compiler, et hop "je trouve pas la lib machin" (re eh merde !).
Et ainsi de suite...
Bon, ça, c'est quand tu veux pas gnome en entier, et que, comme moi, tu veux compiler une seule application gnome et que la dite application donne une liste de libs gnome incomplète ou pas dans le bon ordre...
Mais tout ça, avec la gestion des dépendances et avec des packages, c'est un vrai bonheur ; même pas à réfléchir :)
Ne parlons même pas de la désinstallation, où si tu ne gardes pas le répertoire d'install de chacun des packages (càd là où tu as fait le make install), tu peux toujours courir pour trouver tous les fichiers qu'il faut virer dans /usr/local . Ou alors, au mieux, il faut avoir la liste exacte des libs ou programmes que tu as installé...
Je suis récemment passé de gnome compilé à la main à gnome apt-geté, eh ben, pour désinstaller ma vieille version, j'ai fini par faire un rm -rf /usr/local et réinstaller les applis qui ne faisaient pas partie de gnome... ça m'a épargné une perte de temps non négligeable (heureusement que je n'avais pas grand chose d'autre que gnome...)
[^] # Re: Pas franchement d'accord
Posté par #3588 . Évalué à 6.
Je trouve que tu soulèves plus un problème concernant les système de packages.
Apt-get est très bon, mais pourrait etre encore mieux. D'ailleurs, son développement continue en ce sens. Je pense en particulier au "downgrade" et à l'annulation, le retour en arrière. Les dépendances sont très bien pour installer, rien ne manque. Pour désinstaller, effectivement, le problème est que virer le package principal laissera en place toutes les dépendances utilisées. Alors, actuellement il n'y a sans doute rien de convaincant pour ça, mais dans le gestionnaire de package idéal, les dépendances seraient aussi supprimées à la désinstallation. C'est à implémenter, mais ça peut se faire (il faudrait tenir compte d'une sorte d'historique des installations). Donc si actuellement, la solution "un répertoire pour Gnome" semble meilleure, c'est juste qu'on n'a pas de gestionnaire de package qui permette de supprimer aussi facilement qu'un "rm -rf". Mais avec un tel gestionnaire, l'installation dans un répertoire particulier ne serait plus pertinente.
[^] # Re: Pas franchement d'accord
Posté par corn . Évalué à 1.
Etant donne que l'on connait les dependances de chque paquet, il me semble qu'il suffirait de desinstaller recursivement chaque dependance et ses dependances, en verifiant qu'elles ne sont pas utilisees par autre chose... c'est peut etre pas si simple a faire et peut prendre du temps s'il y a beaucoup de paquets installes sur le systeme :-(
[^] # Re: Pas franchement d'accord
Posté par #3588 . Évalué à 1.
Eh non, ça ne suffit pas, je pense qu'il y a besoin de garder un une sorte d'historique des installations.
Exemple:
- Je n'ai pas GTK.
- Je démarre un projet dans lequel je compte développer avec GTK. Donc je l'installe avec le gestionnaire de package.
- Ensuite j'ai par exemple besoin de Gimp. Je l'installe par le gestionnaire de package. Il a besoin de GTK, mais GTK est déja installé.
- Plust tard, je décide de ne plus utiliser Gimp. Donc je le désinstalle avec le gestionnaire de package. Avec une simple désinstallation récursive des dépendances, en virant Gimp, le gestionnaire voit que GTK est une dépendance de Gimp et qu'aucun autre package installé n'en a besoin. Du coup il vire GTK. Ce qu'il ne faut pas puisque j'en ai besoin pour mon projet, et que je l'avais installé à part, avant.
Il faut donc savoir, pour chaque package qui est une dépendance d'un autre, s'il a été installé directement (besoin de ce package) ou en tant que dépendance d'un autre. C'est pour ça que je pense à une sorte d'historique. Ca ne résout pas tous les cas de figures, mais c'est déja mieux.
[^] # Re: Pas franchement d'accord
Posté par bad sheep (site web personnel) . Évalué à -1.
[^] # Re: Pas franchement d'accord
Posté par bmc . Évalué à -1.
Meuuuuuh ;)
# Faudra qu'il explique ça à Ken Thompson
Posté par Foxy (site web personnel) . Évalué à 0.
J'aime bien sa phrase à "l'emporte pièce" : "Typical Linux systems have over 2,000 programs sitting in one directory: /usr/bin. This is obscene."
[^] # Re: Faudra qu'il explique ça à Ken Thompson
Posté par Miod in the middle . Évalué à 10.
# Je suis d'accord avec lui.
Posté par Eddy . Évalué à 2.
Et j'interdit la creation de repertoires. Tout est gere par les permissions.
Comme ca, pas de pbs d'arborescence.
Hop, -1
# outils de packages
Posté par Gentoo][Gravis . Évalué à 2.
la variable PATH contient des repertoire. quand une application est cherchée par le systeme, elle n'est (heuresement) pas cherchée dans les sous rep.
Dans le cas contraire, /usr ne devrait contenir que des executables, et les fichier de config et autre se trouveraient dans un autre rep a la racine...
c'est une solution effectivement... reste a voir si quelqu'un se sent de lancer un révolution (mosfet?). je ne pense pas ...
au diable la varice... je ne comprend pas déjà pkoi /etc est différent d'une distib a l'autre, alors /usr..............
[^] # Re: outils de packages
Posté par Jar Jar Binks (site web personnel) . Évalué à 7.
la variable PATH contient des repertoire. quand une application est cherchée par le systeme, elle n'est (heuresement) pas cherchée dans les sous rep.
Pour modifier la façon dont est cherché le PATH, ce n'est pas le shell qu'il faudrait modifier, mais les appels système exec*. C'est effectivement une révolution, et je ne pense pas que ce soit une bonne idée, ne serait-ce qu'à cause de la lenteur d'un tel système.
[^] # Re: outils de packages
Posté par Olivier M. . Évalué à 10.
Ca ne serait pas forcement super lent. Il suffirait (comme suggeré plus haut) de garder une trace des différents repertoires de binaires existant, soit en mémoire (donc un premier accès a exec* plutot lent....), soit dans un fichier (mais rendre un appel systeme dependant d'un fichier de conf...brrrr....).
Une solution intermediaire est d'ecrire une couche d'encapsulation des exec*, mais la encore, qu'est-ce qui nous prouve que tout le monde va l'utiliser? (question rethorique, bien sur que PERSONNE ne l'utiliserait).
J'en profite, au passage, pour rappeler la méthode utilisée par l'envirronement graphique ROX: les applications directories. Chaque application "end user" (de préférence n'etant pas dependance d'une autre appli) est stockée dans un repertoire pour elle toute seule, avec un bin, un share (des equivalents en fait, les noms ne sont pas les memes). Un simple accès au repertoire de l'application execute/compile(si besoin) l'application. Il est a noter qu'un patch pour permettre a bash de gerer ces repertoires a été fourni.
Dans un autre ordre d'idées, il y avait une rumeur il y a quelques années d'un systeme de packages basé sur autoconf, avec l'énorme avantage de gérer ses dependances tout seul, et non sur un grosse base de donnée des softs installés; donc cohabitant parfaitement avec les softs installés "a la paluche". Quelqu'un a des nouvelles?
En melangeant toutes ces idées, on peut peut-etre arriver a une facon différente de gérer ses packages, personnelement j'experimente regulierement (mais ca marche tres mal, soyons honnetes).
[^] # Re: outils de packages
Posté par William Steve Applegate (site web personnel) . Évalué à 9.
Tu viens de mettre le doigt sur un truc très important (même si ce n'est pas exactement on-topic) : le VRAI problème n'est pas tant que KDE soit dans /usr et non dans /opt, c'est que chacun fait son petit mix à sa façon. Les répertoires dans /etc, dans /var, ne sont pas les mêmes, le /etc/X11 contient une procédure de démarrage différente sur Red Hat et Mandrake (bravo la compatibilité), etc.
Ce qui est bien plus important AMHA que de savoir si on fait un répertoire par application (bof...) qu'un répertoire par *type* d'applications, c'est bien délimiter dans le FHS quels types *précis* d'applications vont dans quels répertoires, où doivent être placés tels et tels fichiers de conf, et SURTOUT de faire en sorte que toutes les distribs, sans exception, s'y conforment. Lorsque ce niveau de compatibilité sera atteint, un grand pas aura été fait, car on ne passera plus son temps à se demander « est-ce que je peux installer ce package venant de Merdake sur ma Rat Head sans que ça foute le bordel ? ». Exactement comme sous Windows et MacOS on installe la plupart des programmes sans se poser de questions...
Enfin bon, c'est mon opinion, hein. Mais Dieu ce que je donnerais pas pour que ça arrive enfin !...
Envoyé depuis mon PDP 11/70
[^] # Re: outils de packages
Posté par Paerro Trime . Évalué à 2.
> plupart des programmes sans se poser de
> questions...
Sous MacOS, je veux bien, mais sous Windows, on se pose des questions avant d'installer la plupart des programmes (ne serais-ce que pour ce meeerrveilleux concept de la base de registre...)
> un répertoire par application (bof...)
sisi, c'est la meilleure solution.
En principe en package doit pouvoir être "relogé" si tu veux pas le mettre dans l'endroit "standard", ya des options pour ça, malheureusement c'est rarement testé et ça marche pas tellement.
[^] # Re: outils de packages
Posté par William Steve Applegate (site web personnel) . Évalué à 3.
Franchement, la base de registres a plein de problèmes (dont une structure absolument débile et gargantuesque, ainsi que sa nature de fourre-tout immonde), mais ce n'est pas pour autant que je me pose des questions. La plupart du temps sous Win32, je lance setup.exe et vogue la galère (exception faite des très vieux programmes pour win3.x qui peuvent poser des problèmes). Sous Linux, la première chose qu'on se demande, c'est : est-ce que les dépendances sont bonnes ? Généralement c'est « non » et RPM n'ira pas comme APT te chercher les bons paquets tout seul. La deuxième question c'est « est-ce que résoudre les dépendances va se faire sans conflit ? ». Et là, si ton paquet vient d'une autre distrib', tu l'as très profond dans un orifice que je me refuse à citer en public. Donc tu te retrouves à y aller à grands coups de rpm --force --nodeps --melesbroutepas... pour découvrir que le script d'init ne fonctionne pas correctement. Quelques bidouillages plus tard, ton démon fonctionne mais ton opinion de Linux n'est plus aussi bonne qu'avant. Idem quand tu es habitué à avoir tes zones dans /var/cache/bind et que ta nouvelle distrib te les met dans /var/named, etc. Je rejoins ici D.J. Bernstein lorsqu'il dit ( http://cr.yp.to/compatibility.html(...) ) que les logiciels devraient fonctionner de la même manière d'un système à l'autre. Je n'ai pas envie de passer mes journées à jouer à cache-cache avec mes fichiers, j'ai mieux à faire de mon temps !...
> sisi, c'est la meilleure solution.
Je suis pas d'accord[tm] :-)
L'avantage d'avoir des répertoires « thématiques », c'est que j'ai toutes mes applications système dans /sbin, mes applications standard dans /bin, etc. Là où ça devient merdique, et là, Mosfet a raison, c'est lorsque tout se retrouve en vrac dans /usr/bin. Déjà, les applis graphiques devraient logiquement être dans /usr/X11R6/bin... Et il y a d'autres trucs. Ainsi, /usr/lib contient nombre de trucs qui sont tout sauf des bibliothèques. Bref, c'est un beau foutoir. Quant à ce qui est de reloger des paquetages, je vois pas l'intérêt, si ce n'est risquer que le programme ne marche plus (genre tiens, le chemin était codé en dur dans le script d'init...). Bref, je me fiche perso de savoir où sont stockées mes applis, mais il faut que ce soit (1) logique (vraiment logique) et (2) standardisé de partout, afin que je puisse sauter d'une distrib (voire d'un système) à l'autre sans perdre mes marques. Mais là, je prends mes rêves pour la réalité...
Envoyé depuis mon PDP 11/70
[^] # Re: outils de packages
Posté par Thomas RIBO . Évalué à 2.
Je ne pense pas, au contraire. Je pense qu'il prône le fait d'utiliser des gestionnaires de paquetages ET que ceux-ci rangent correctement les applications dans des dossiers et sous-dossiers. Les deux sont conciliables facilement, alors pourquoi ne pas le faire ?
On dit souvent qu'Unix est plus propre que Windows, prouvons-le.
# Et pourtant il suffit...
Posté par Henri . Évalué à 10.
[^] # Re: Et pourtant il suffit...
Posté par pas_moi . Évalué à -4.
Le gars se plaint de l'arborescence RedHat, mais ça ne sert à rien; quand on utilise quelque chose qui n'est pas bien, il y a deux solutions: l'améliorer ou utiliser autre chose. Se plaindre ne fait pas avancer les choses.
[^] # Re: Et pourtant il suffit...
Posté par Annah C. Hue (site web personnel) . Évalué à 9.
Moi j'utilise "man demain" pour toujours garder une longueur d'avance
(-1 parce que je le vaux bien)
[^] # Re: Et pourtant il suffit...
Posté par Jean-Pierre Schwickerath (site web personnel) . Évalué à 1.
[^] # Re: Et pourtant il suffit...
Posté par Annah C. Hue (site web personnel) . Évalué à 1.
Moi j'utilise "man demain" pour toujours garder une longueur d'avance
(-1 parce que je le vaux bien)
# Mouaissss
Posté par Christophe Merlet (site web personnel) . Évalué à 10.
Tous les OS ont leur propre stantard de système de fichiers dont l'objectif et de répondre aux contraintes qui se sont fixés les développeurs.
Le plus convivial d'entre tous est incontestablement MacOS. Avec ce système vous pouvez déplacer comme bon vous semble application, fichiers et dossier système. MacOS retrouve toujours ces petits.
Le plus directif et Unix/Linux. Les fichiers doivent être à des endroits précis en fonction des besoins.
Il y a une raison toutes simples a ces contraintes.
MacOS est mono-utilisateur et est entièrement graphique
Unix est multi-utilisateurs et est en mode console et graphique
MacOS a été conçu pour permettre de bouger ses fichiers comme bon semble à l'utilisateur. Chaque fichier posséde un « ressource fork » (partie d'un binaire intégrant icones, traductions, code fat 68k et ppc, etc.) et un type. Une base de données intégré au système de fichier sait où se trouve chaque application et dossier système.
Unix a été conçu de sorte que chaque type de fichier doivent se trouver a un endroit précis.
La gestion des fichiers sous UNIX est conçu pour faciliter la tâche de l'administrateur système gérant des centaines d'utilisateurs et de machines d'architectures différentes en réseau avec des contraintes fortes de sécurité et de contrôles.
La gestion des fichiers sous MacOS est conçu pour faciliter la vie de l'utilisateur de base sans aucune contrainte.
Voilà pourquoi le système de fichiers Unix est le meilleur, tout simplement car il s'adapte aux besoins des utilisateurs des plus exigeants ayant les plus fortes contraintes.
La question est doit on sacrifier la puissance et la polivalence au profit de la convivialité ?
Modifier le système de fichiers Unix, implique de modifier le formats des binaires Unix, Est-ce envisageable sous GNU/Linux ?
Moi je dit ne toucher pas au système de fichier Unix, contentez vous de mieux classer vos fichiers.
Respectez la FHS (File Hierarchy Standard) http://www.pathname.com/fhs/(...) et tout ira pour le mieux dans le meilleur des mondes.
[^] # Re: Mouaissss
Posté par EvilTheCat . Évalué à 5.
J'suis d'accord avec toi et je trouve l'arborescence UNIX extremement pratique ... sauf les différences entre distrib dans leur gestion de /etc ... mais enfin FHS est la
[^] # Re: Mouaissss
Posté par rouge13 . Évalué à 3.
C'est effectivement la question centrale et même si tout tes arguments sont valables pour une utilisation intensive de Linux (plusieurs utilisateurs et un admin derrière).
Mais qui utilise encore Linux de cette façon, est-ce que la majorité des utilisateurs sont des admins système ?
Il exitera toujours des distribs Linux pour ce genre d'utilisation mais je ne crois pas que l'on puisse satisfaire tout les besoins en gardant une même organisation commune des fichiers et répertoires.
La cission est inévitable entre le monde serveur où Linux excelle et le mode du 'desktop' (j'aime pas ce terme) car les besoins sont trop différents.
[^] # Re: Mouaissss
Posté par Manu (site web personnel) . Évalué à 4.
Tu peux argumenter ?
:o)
2) Toutes les distribs ne respectent pas la FHS.
3) Je en vois pas en quoi cette nouvelle hiérarchisation ne satisferait pas les utilisateurs les plus exigeants. Ceux là n'ont qu'à faire comme bon leur semble.
[^] # Re: Mouaissss
Posté par Olivier M. . Évalué à 4.
Je suppose que tu fait reference a cela:
"Chaque fichier posséde un « ressource fork » (partie d'un binaire intégrant icones, traductions, code fat 68k et ppc, etc.)" [Sous MacOS]
Mais rien n'oblige a stocker ca DANS les binaires (cf mon post sur ROX plus haut).
Le systeme RiscOS utilisait une gestion similaire en foutant toutes les icones/traductions/aides/etc... dans l'application directory.
De meme sur ROX (peut etre sur RiscOS aussi?), on peut se permettre d'avoir différentes versions du binaire dans l'appdir, et meme de compiler pour l'archi en cours si aucun binaire natif n'existe encore.
[^] # Re: Mouaissss
Posté par Patrice Fortier . Évalué à 6.
$ ls /usr/bin/ | wc -l
1614
$ ls /usr/lib | wc -l
1127
J'ai une petite install linux est les 1600 binaires sont ds 1 (un seul) répertoire. J'ai 1100 bibliothèques dans un seul répertoire. Et la dedans on trouve de tout.
Ca fait un peu bordelique. Même ma chambre est mieux rangée :).
Si un jour tu dois faire un peu de ménage, bon courage!
> La question est doit on sacrifier la puissance et la polivalence au profit de la convivialité ?
Franchement, ajouter 2 entrées dans le PATH, MANPATH, et ld.so.conf, c'est vraiment pas la mort, et appeler ça un sacrifice est peut-etre un peu exagéré...
> Modifier le système de fichiers Unix, implique de modifier le formats des binaires Unix
Pourrais-tu développer?
> Moi je dit ne toucher pas au système de fichier Unix
L'article de Mosfet ne voulait pas dire que la philosophie unix de l'organisation des fichiers était pourrie, mais qu'il n'est pas normal que ma commande ftp (de base) soit dans le meme répertoire que nautilus.
Historiquement, même les boites comme Sun ou HP (ou d'autres) ont mis leurs usines à gaz ds des répertoires séparés (X11, OpenWin, CDE...).
Pourquoi les nouvelles usines à gaz des distribs linux (KDE, Gnome) sont remis ds /usr?
[^] # Re: Mouaissss
Posté par Jean-Baptiste NADAL . Évalué à 10.
de tout mettre comme des sagouins dans un même répertoire en prétendant que ce que l'on met est standard.
Elle dit que c'est également que c'est difficilement administrable.
L'exemple le plus facile est KDE. Je me souvient au début quand on récupérait les sources des premières
versions, que l'on devait compiler soit même le répertoire par défaut était /opt/kde/.
ce qui fait que l'on pouvait identifier rapidement l'origine d'un fichier.(kde n'étant pas
constitué de 4 fichiers). alors que maintenant tout est dans /usr. Donc s'il on a kde et les libs gnome,
il devient assez difficile d'identifier l'appartenance d'un fichier.
Moi ce qui me gêne lesplus c'est de ne pas pouvoir désactivé rapidement un version.
quand kde avait un sousrépertoire rien que pour lui ( que ce soit /opt/kde ou /usr/X11/kde)
si on veut pouvoir testé une nouvelle version on renomme le répertoire on en créé un nouveau
on test la nouvelle version, ça marche pas , hop on efface le nouveau et on rétablit l'ancien.
Maintenant c'est quand même plus difficile, si je fait la même chose avec /usr/, il risque d'y avoir quelques
problèmes... :-)
Je trouve que son coup de gueule est justifié.
# Un avantage...
Posté par Sylvain Rampacek (site web personnel) . Évalué à 6.
quand une appli s'installe dans un dossier différent, il est alors possible de tester d'autres versions de cette meme appli sans risquer d'effacer la première...
Et je crois que c'est un avantage énorme sur un serveur de prod... mais aussi sur ma linux box sur laquelle j'aime testé la nouvelle version avant de l'utiliser complètement.
[^] # Re: Un avantage...
Posté par Vincent Ternisien (site web personnel) . Évalué à -1.
tu installe des applis a tester sur un serveur de prod ? c'est mal ;)
[^] # Re: Un avantage...
Posté par Sylvain Rampacek (site web personnel) . Évalué à 1.
Donc dans ce cas, c'est bien un test...
# et imaginez ce que c'est pour un FS repartis !
Posté par Ben (site web personnel) . Évalué à 8.
ete faits pour que /bin contienne les applis qui doivent se charger rapidement
comme sh, ls, etc... (i.e sur un dique local) et que /usr/bin
contienne les applis moins critiques car, a l'epoque, stockees sur bande.
Par defaut, je place une copie de /bin sur chaque machine pour un acces local
et rapide, et je monte /usr/bin par NFS depuis un gros serveur de fichiers.
Je pense qu'il serait bon, comme pour X, de creer des sous-repertoires
pour les gros projets comme GNOME ou KDE dans /usr/X11/gnome
et /usr/X11/kde. D'ailleurs, certaines applis X sont dans
/usr/X11R6/bin au lieu de /usr/bin. Ce serait beaucoup plus simple
a gerer pour un FS reparti car cela accellererai le temps
de chargement des applis vu qu'on pourrait les distribuer sur
plusieurs serveurs de fichiers. De plus, si le serveur de /usr/X11/gnome
plante, le reste (i.e /usr/bin) fonctionne.
Donc : oui, RH nous fait des mouises !
Tout homme qui dirige, qui fait quelque chose, a contre lui ceux qui voudraient faire la même chose, ceux qui font précisément le contraire, et surtout la grande armée des gens d'autant plus sévères qu'ils ne font rien du tout. -- Jules Claretie
[^] # Re: et imaginez ce que c'est pour un FS repartis !
Posté par Olivier M. . Évalué à 2.
# Le beurre et l'argent du beurre
Posté par jobi . Évalué à 10.
ce soft permet d'avoir une arborescence de type un repertoire == une application, tout en gardant une totale compatibilité avec la hierarchie red/hat en utilisant des liens symboliques.
je vous invite aussi à regarder l'édito sur freashmeat qui traite du sujet :
http://freshmeat.net/articles/view/247/(...)
[^] # Re: Le beurre et l'argent du beurre
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
(le coupable c'est Shbrol, qui s'exprime de fois sur dlfp)
$ ls /export/shop/env/gnu
bin@ i686-pc-linux-gnu/ powerpc-apple-darwin1.3@
doc/ include/ share/
etc@ info/ sparc-sun-solaris2.6/
gnu.csh* lib/ sparc-sun-solaris2.7/
gnu.sh* man/ sparc-sun-solaris2.8/
hppa1.1-hp-hpux10.20/ mkenv.log sparc-unknown-linux-gnu/
$ ls /export/shop/stow
ACE-5.1/ freeciv-1.11.4/ gzip-1.2.4/ openssl-0.9.6b/
autoconf-2.13/ freetype-1.3.1/ gzip-1.2.4a/ patch-2.5.4/
[SNIP]
fop-0.17.0/ gtk+extra-0.99.6/ openssl-0.9.6a/
[^] # Re: Le beurre et l'argent du beurre
Posté par shbrol . Évalué à 2.
Mais c'est parce que je suis trop occupé avec la crémière ;)
# FHS, LSB, etc.
Posté par TyrandO . Évalué à 7.
http://www.pathname.com/fhs/(...)
Force est de constater que parmi les distributions majeures de GNU/Linux, seule la SuSE est conforme à 95%.
Pendant que j'y suis, il y a aussi la Linux Standard Base (LSB) qui devrait permettre d'homogénéiser l'initialisation du système.
http://www.linuxbase.org(...)
# un premier pas
Posté par - - . Évalué à 3.
(a voir ce qui serait le plus juste)
les libs devraient aller dans /usr/lib/ et separé si ca forme un trop gros ensemble de lib
les includes doivent etre separé
/usr/include/gnome-1.0/.....
par projets
en fait
les binaires (choses les plus utilisé par les utilisateurs) devraient pas etre melangé n importecomment
/usr/bin devrait contenir _que_ des commandes consoles ou systemes
et /usr/bin/gnome devraient avoir tout les applications de gnome
/usr/bin/kde de meme
/usr/bin/gnustep...
cependant
X a son propre sous rep dans /usr/X11R6
les gens de gnustep ont pris la meme habitude /usr/GNUstep
finalement et si on faisait :
/usr/gnome/...
/usr/kde/....
(cela dit , ou met on une application QT ou GTK ne faisant pas partie en tant que tel de kde ou gnome ? hmm ? )
on aurait donc au final :
/usr/X11R6/... (include, lib etc...)
/usr/gnome/.... (include, lib etc... )
/usr/kde/... (include lib etc...)
/usr/bin (binaires console et systeme)
les applications graphiques (tcl/tk, qt, motifi, gtk ... ) pourraient etre dans /usr/X11R6/bin/misc/ par exemple ) ou /usr/bin/X/
----------------------------------------
vient alors un autre principe, et si chaque "application" avait SON repertoire a elle
et dedans son manuel, aide, icone et ressources
on nommerait ce repertoire "trucmuche.app" et ca serait un "bundle" que le gestionnaire de fichier montrerait comme etant une "application" (on clique sur lme trucmuche.app et en fait ca execute trucmuche.app/binaries/x86/trucmuche )
on aurait le modele de Apple dans macosX
l'idée est bonne car l utilisateur peut bouger le "bundle" ou il veut et ca marche toujours
(les libraires sont standards et mises dans un repertoire dédié a ca que l utilisateur n'a pas a trifouiller)
PAR CONTRE :
comme on peut le voir dans macosX ,les 2 systemes existent , la maniere unix (un /usr/bin ) et la maniere macintosh/nextstep (les bundle .app )
parce qu on ne peut decemment pas faire un vi.app ou un httpd.app , ca serait ridicule
probleme donc, 2 logiques existent au sein de macosX . vous me direz l utilisateur lambda n a pas a fouiner le /usr/bin/httpd... et alors ? le jour il veut le faire, bang il doit reapprendre une autre logique de rangement)
sous linux, la meme logique est utilisé que ca soit au niveau de votre super konqueror zoli zoli et sympathique jusqu a l abominable mais fonctionnel vi
neanmoins plus de coherence serait bien
j ai pris l habitude de creer un repertoire /Applications sur mon linux et d y mettre des liens symboliques des binaires de mes applications favorites
quand je dis "applications" je pense programmes avec une interface graphique, genre gnumeric, gqview, scribus etc...
l'idée etant d'avoir un lieu facile a parcourir avec nautilus où je doubleclique, en sachant trés bien que tout ce qui est la a un zoli icone et affiche une fenetre, pas des utilitaires shell
pour rendre linux plus agreable et plus "fluide" a parcourir pour un debutant, il faudrait prendre l habitude de separer les binaires qui sont des applications graphiques des commandes shells.
ne serait ce que pour simplifier le parcours du repertoire des logiciels avec konqueror ou nautilus.
# beurck
Posté par matiasf . Évalué à 0.
Ce type attaque RedHat sans ce pencher sur le système rpm.
S'il veut fait des package kde dans /opt/kde, il peut.
si je veut connaitre les packages qui utilisent gnome-libs :
$ rpm -q --whatrequires gnome-libs
Je n'ai pas besoin qu'il soit dans /opt/gnome ou autre...
Si je veut avoir la liste des fichiers associés :
$ rpm -q -l --whatrequires gnome-libs
Mettre toute les libs dans /usr/lib et tous les include dans /usr/include est FORMIDABLE et c'est possible de façon controlé grace à rpm (ou apt de debian). Car avant il fallait :
./configure --with-truc=/opt/truc --with-truc-lib=/opt/truc/lib --with-toto ....
Alors vive le chois de RedHat, Debian, Mandrake, etc... C'est mille foi mieux que sous HP-UX avec les /usr/contrib, /usr/ccs, etc, etc...
[^] # Re: beurck
Posté par rouge13 . Évalué à 2.
J'ai posté cette news et c'est la première que je poste (snif !) mais je ne pensais pas être en première page :-)
Il n'attaque pas RedHat sur RPM mais sur la manière d'organiser les applis sous Linux et sur l'influence qu'a eu RedHat de par le choix initial de tout mettre dans un seul répertoire.
Le problème survient quand tu as envie de compiler/installer/maintenir toi même ton installation de Linux et que tu veux pouvoir le faire sans utiliser RPM.
Ex: un petit soft sympa mais pas de RPM ni de DEB dispo ou bien une mise à jour d'un gros projet et que t'as pas la patience d'attendre le package.
C'est tout de même chiant de nos jour de ne pas pouvoir mettre à jour simplement le noyau sur les distribs récentes (sans casser le système de paquetage) avec un simple make xconfig, make ...etc.
Se retrouver enfermé dans une hierarchie de répertoire complètement ubuesque et qui était adapté au système il ya 20 ans est pour le moins frustrant.
T'es obligé d'attendre le bon vouloir d'un packageur pour avoir un système à jour (et encore plus les paquets sont récents, plus le risque que le dit paquet soit buggé est grand.
[^] # Re: beurck
Posté par TyrandO . Évalué à 2.
http://www.linuxbase.org/test/results/index.html#LSB-FHS(...)
Etonnant, non ?
[^] # Re: beurck
Posté par Patrice Fortier . Évalué à 2.
RH n'est qu'un exemple. Ca marche aussi avec Mandrake (et peut-etre meme avec Debian).
> S'il veut fait des package kde dans /opt/kde, il peut.
Mais il ne veut pas faire de package. Il veut juste que kde ne soit pas installé ds /usr, et ne pas être obligé d'utiliser rpm pour le virer si l'envie lui prend.
> Mettre toute les libs dans /usr/lib et tous les include dans /usr/include est FORMIDABLE et c'est possible de façon controlé grace à rpm (ou apt de debian).
Le problème c'est que, effectivement, si tu veux controler quoique ce soit, tu es *obligé* d'utiliser rpm (ou apt), sinon tu deviens fou.
> Car avant il fallait :
./configure --with-truc=/opt/truc --with-truc-lib=/opt/truc/lib --with-toto ....
Tiens, pourquoi tu aurais besoin de compiler qqchose? Il y a pas le rpm?
Moi j'aime bien
$ rm -rf /opt/kde
Si kde est ds /usr, ça devient tres vite moins drole :).
[^] # Re: beurck
Posté par Fabio Parisi (site web personnel) . Évalué à 1.
Tout ce binz c pas un probleme si tu as un bon gestionnaire de package comme apt-get par exemple.
Si tu ve virer un truc tu lui dis.(dpkg --purge/--remove)
Si tu cherche un package ke ta installé dpkg -l et -L pour savoir où.
Si tu ve savoir a kel pakage apprtient un fichier ya pas de pb (dpkg -S).
Si tu ve ......
J'imagine ke tous ca est tres certainement ossi faisable avec RPM....
L'arborescence telle kelle est ojourdhui me va tres bien.Il suffit davoir le gestionnaire de package ki te plait.
Pis si ca vous plait pas libre a vous de le changer mais ce n'est pas une raison pour vouloir une refonte complete des distribs.
Je pense ke mosfet aurais du garder ca pour lui et pas declencher de polemique en ce moment ou les distrib on du mal mais essaye de s'accorder derriere des standards LSB etc...
Ciao :)
# to pack or not to pack that is the question ?
Posté par Jean-Marc Chapuzot . Évalué à 4.
Un utilisateur compilant ses sources non packetes brise deliberement la coherence de ces distros.
Dans les distros (genre slack) sans gestion des dependances la separtion des groupes d'applis est d'ailleurs comme mosfet le prefere dans des repertoires distincts, ce qui est essentiel car la gestion des dependances se fait a la main.
Cela dit une distro avec dependance est une bonne chose mais peu flexible. Les concepteurs de systeme de packetage devrait sortir de leur tour d'ivoire et enfin produire un systeme permettant a l'amateur eclaire de produire lui-meme ses paquets.
Produire un rpm n'est pas simple un deb une horreur
</TROLL>
Ce n'est pas etonant que les developpeurs de debian ne peuvent sortir une distro que tous les 2 ans
<TROLL/>
[^] # Re: to pack or not to pack that is the question ?
Posté par Anonyme . Évalué à 1.
[^] # Re: to pack or not to pack that is the question ?
Posté par Jean-Marc Chapuzot . Évalué à -1.
[^] # Re: to pack or not to pack that is the question ?
Posté par Anonyme . Évalué à 1.
Pour debian, ça a pas l'air beaucoup plus compliqué...
[^] # Re: to pack or not to pack that is the question ?
Posté par vrm (site web personnel) . Évalué à 2.
va faloir expliquer combien de fois ?
[^] # Re: to pack or not to pack that is the question ?
Posté par Patrice Fortier . Évalué à 1.
Et la derniere fois que j'ai lu les infos concernant le freeze de la Woody (~ une semaine), ils avaient toujours un probleme pour faire fonctionner php4 avec apache. C'est curieux, mais qd j'ai compilé les 2 sur mon serveur tout a fonctionné impec. Si c'est si simple de faire des packages, pourquoi les developpeurs Debian bloquent la dessus?
Ne te meprends pas. Je ne veux pas critiquer le travail des mecs de Debian. Ce que je veux montrer c'est que faire un package qui s'intègre bien ds une distrib, c'est pas déjà pas simple, alors faire une distrib entière bassée sur des packages et des dépendances.
PS: d'ailleurs sur ma mandrake, j'ai un certain nombre de rpm qui merdent et que j'ai du recompiler à la main (ex: sylpheed)...
[^] # Re: to pack or not to pack that is the question ?
Posté par Pierre Tramo (site web personnel) . Évalué à 5.
comment ca? et ca c'est quoi : http://slaktool.sourceforge.net/(...)
C'est - contraignant que les rpm ou les deb, ca verifie si un package est installé et si il ne le trouve pas, il vérifie dans les librairies. Et ceux qui ne veulent pas de dépendances, il suffit juste de régler ca dans les options.
# Liens symboliques
Posté par Infernal Quack (site web personnel) . Évalué à 8.
Je pense que le fait d'avoir pleins d'exécutables dans /usr/bin ou /usr/X11R6/bin doit être conservé et ce pour une rapidité de la recherche ou de l'autocomplétion chère à tout unixien converti.
Par contre ces exécutables devrait être des liens symboliques vers d'autres exécutables.
Par exemple : /usr/bin/xemacs -> /usr/share/xemacs/bin/xemacs
voir même /usr/bin/xemacs -> /usr/share/X11/editor/xemacs/bin/xemacs
On pourrait ainsi avoir une arborescence très propre et facile à maintenir. Et au pire, on utilise un outil comme "symlinks" pour retrouver les liens morts.
On pourrait de plus ranger les applications par domaines d'utilisation et/ou par couche. xawtv trouverait ainsi sa place dans /usr/share/X11/multimedia/tv/xawtv et aatv dans /usr/share/multimedia/tv/aatv. Dans chaque répertoire de l'application on retrouverait une hiérarchie similaire (/bin, /doc/txt, /doc/html, /img, /sound, ...)
Pour ce qui est des ressources qui n'appartiennent à aucun paquetage (fond d'écrans, sons, documentation générale sur linux,...), on pourrait les mettres dans un répertoire /usr/share/ressources/ tout en conservant une hiérarchie (/sounds, /wallpapers, /doc/system, /doc/devel,...)
On peut ensuite imaginer la même chose dans usr/lib avec des liens vers /usr/lib/multimedia/tv/xawtv/libxawtv.so par exemple.
Par contre pous les applications de maintenance ou lié aux shells, on les laissent dans /sbin (pour la maintenance et l'administration) et /bin car qd on crashe la partition /usr on aurait l'air fin si plus un seul lien ne marche :)
Pour ce qui est de l'utilisation de /opt, je pense qu'elle est à bannir. Premièrement parce que le cas d'utilisation de /opt est très mal définies (gros programmes,...). Et deuxièmement parce que pour l'avoir utilisé sur un Unix, je trouvais ça super chiant de chercher si mon application était dans /op /usr ou /usr/local ;)
Malheureusement, il y a peut-être un problème avec cette solution de lien symbolique. N'y a t-il pas une limite sur le nombre de liens symboliques que Linux ou un de ses système de fichier peut gérer ?
J'aimerais l'avis d'un expert sur cette question.
Pour ce qui est de la gestion de packages par des outils externes (dpkg, rpm, apt-get, urpmi,...), je trouve ça carrément pratique. Surtout autoirpm que je n'arrive plus à faire marcher. Qd on compile un prog, lors du ./configure si une librairie manque il nous propose de l'installer si elle se trouve dans une des sources (cd, ftp,...).
Je pense, que Mosfet n'est pas non plus contre les paquetages : preuve en est de son thême Liquid qu'il fournit en .tgz, .rpm et .deb
Voilà, c'était l'avis d'une moule qui si elle moulait moins et quelle avait le temps et les connaissances pour se faire son propre LFS choissirait cette solution :)
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Liens symboliques
Posté par Obsidian . Évalué à 1.
Ca permettrait effectivement d'éviter les $PATH kilométriques, et ce serait plus propre. Les rc.d/ fonctionnent d'ailleurs sur ce principe. Malheureusement, l'un des freins majeurs à l'intégration de ce concept au FHS est qu'à mon avis, les liens symboliques ne sont pas pris en charge par tous les systèmes Unix et ne sont pas Posix (ou alors seulement dans les normes récentes. Voir le bas de la page de man ln pour plus d'infos).
Maintenant, il n'y a rien qui nous empêche d'utiliser des liens durs ! Liens durs, qui à mon goût deviennent trop peu usités ces temps-ci. Avis perso.
Par contre, avis toujours perso, il y a quelque chose qui manque cruellement au FHS, c'est un répertoire etc dans son répertoire home. Il n'y a qu'à taper ls -a ~ pour s'en convaincre. Tous les .bashrc et approchés se trouvent soit dans /etc, soit à la racine du répertoire utilisateur. Je trouve que c'est un oubli, purement et simplement, et je regrette beaucoup de ne pas pouvoir placer moi-même tous mes fichiers .* dans un rép ~/etc car les programmes concernés (sauf exceptions configurables) ne retrouveraient plus leurs petits, et pire risqueraient d'en recréer d'autres.
Amitiés.
[^] # Re: Liens symboliques
Posté par Alphonse Oncle . Évalué à 1.
Par exemple : /usr/bin/xemacs -> /usr/share/xemacs/bin/xemacs
voir même /usr/bin/xemacs -> /usr/share/X11/editor/xemacs/bin/xemacs"
Ca doit marcher avec la plupart des programmes mais il me semble que pour certains progs comme gcc ou xemacs que tu compiles avec l'option --prefix
(ex pour xemacs dans ton cas --prefix=/usr/share/xemacs) les liens posent probleme. En effet ils se servent du lieu ou est lance le programme pour retrouver leurs petits (les autres sous rep comme bin, lib, share) et dans ce cas un lien vient foutre le bordel.
Apres pour la plupart tu peux contourner le probleme avec des vars d'environnement (style GCC_HOME, je donne un exemple c'est pas forcement le bon nom) mais c'est pas toujours prevu dans le source.
[^] # Re: Liens symboliques
Posté par Prosper . Évalué à 1.
/usr/bin/xemacs -> /usr/share/xemacs/bin/xemacs mais un petit script placé au meme endroit (/usr/bin/xemacs)
qui met les bonnes variables(genre XEMACS_HOME) et qui lance /usr/share/xemacs/bin xemacs avec .
Comme ca tu n as pas besoin de charger ni ton /etc/profile ni ton .le_shell_que_tu_utilises.rc
L'avantage est que meme si tu changes de shell ou si tu exportes ton /usr , tu n as pas besoin de
mettre a jour le home de chaque application.
# Système de fichiers Linux ????
Posté par Code34 (site web personnel) . Évalué à 1.
J apporte quelques précisions tirées de mon experience personnelle... J invoque votre tolérance quand à mon opinion, car je sais qu après ce post, je m attirerais la foudre de nombreux linuxiens , ou unixiens ....
J ai consulté des livres de références sur la conception d unix, et je n ai pas trouvé de chapitre concernant l organisation des systèmes de fichiers ...
Mis à part, sur les bibles, et autres livres qui vous permettent de pratiquer unix, ou linux en une dizaine de jours ... Il me semble que les bons livres ne se sont appliqués qu a décrire que le fonctionnement du système en lui meme, laissant au bon vouloir des praticiens l organisation du système ;)
L arborescence est libre d etre crée , et développé selon les exigences de l administrateur, et des utilisateurs.
A mon sens, les administrateurs sont confontrés à deux problemes majeurs (issus de problemes sous jaccents).
Celui de plus haut niveau qui se situe au niveau des distributions, qui ne fournissent pas une arboresence litteralement parlant lisible, clair, et efficace. (Celle ci n aura de sens que dans la mémoire de l administrateur qui l utilisera chaque jour)
L autre, est un probleme d applications (lié sans doute aux programmes permettant l'installation des binaires, des sources, etc ...) qui ne se conforme pas à l arborescence (litterale) du système. Je pense nottamment à l organisation d un système de fichiers entieremment composé par l administrateur.
Chaque dépendance requise par plus de deux packages est un trou béhant dans la cohérence, et la stabilitée du système.
Au plus bas niveau software, je ne conçois pas non plus que le kernel constitue l arborescence sémantique. Car Un inoeud reste un inoeud, et un nom de fichier: un lien vers l inoeud.
La phase de creation du système de fichiers se doit donc d etre plus permitive, en repondant à un ensemble de besoin, plutot qu a un besoin specifique.
Dans ce sens, j observe que les distributions linux s ecartent de la robustesse, au profit de la simplicité, et de la rapidité. (C est leurs bizness de democratiser, puis de vendre... ;)) )
La dépendance comme sont nom l indique, est sans doute le sujet le plus épineux. Toute la fragilité de l organisation du système de fichiers gravitent autour de la dépendance.
Quel programme en aura besoin, quand, ou, quelle version ? Une simple mise à jour, peut rendre le système completement instable.
A mon sens, la notion de dépendance reflète l esprit du du développement libre.
Pour l évolution du libre, Il serait interressant de développer les notions au dessus, et de les harmoniser.
Par la pratique, je pense notamment à l integration systématiques d une copie des dépendances, ou d une partie du code nécéssaire par programme spécifique qui serait lié dès l installation.
Cela bien sur engendrait plusieurs désagrements : surplus d informations sur les disques, mis à niveau générale plus difficile, etant donné qu il faut mettre toutes les applications à niveau ...
Mais, les programmes conservent ainsi leurs autonomies, et peuvent s organiser dans le système de fichiers. Hors de cela, une version de la dependence, la plus récente, indépendante jouerait le role de référence.
Le système de fichiers soumet implicitement d'autres questions. Pourquoi les binaires avec des bits, et des propriétés rwx root.root sont mélangés dans les memes repertoires que les binaires qui ont des bits wrx pour les autres users ?
Pourquoi l arborescence ne se conforme pas un modèle chroot ? Dans l absolu, il n y a aucune raison pour qu un user est acces à la racine du système, et puisse se déplacer dans /etc /proc ...
Tant de questions qui méritent d etre éxaminé de façon sérieuse ;) et qui pourrait sans doute trouver une réponse en examinant la conception meme du système de fichier.
J espere avoir abordé quelques petits détails qui feront avancer le débat ...
@++ Code34
# meuh linux
Posté par Yann Droneaud (site web personnel) . Évalué à 1.
sur mon systeme:
ln -s usr ..
ln -s local ..
plusieurs partitions LVM
/
/home
/tmp
/var
Dans /mnt tout les disques annexes et apres des liens
dans
/opt
et
/export
[^] # Re: meuh linux
Posté par Yann Droneaud (site web personnel) . Évalué à 1.
je sais pas faire de ln ou c'est a cause des exams ;)
je recommence
ln -s .. usr
ln -s .. local
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.