Mosfet : Rage against the File System Standard

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
22
nov.
2001
Linux
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.

Aller plus loin

  • # je comprend pas non plus

    Posté par  . Évalué à -10.

    c clair j ai aussi commencé sous redhat (5.2)et j ai jamais compris pourquoi tout ce mettais dans /usr ? ou sinon au moins cré une arborescence corcecte la dessous ; un repertoire pour X et tout c composant , un autre pour les lib , un /bin , un local , mais stop ; linux est pas simple (fo bien le reconnaitre ) mais simplifié l arorescence permettrais de simplifier l installation de tout autres logiciels . faut reconnaitre qu un /program file ca pourrais etre pratique non ?


    La transparence et la clarté ne sont ils pas les mettre mots de linux ?
    • [^] # Re: je comprend pas non plus

      Posté par  (site web personnel) . Évalué à 10.

      je n'ai pas bien compris ce que tu reproche a cette arborescence... le coup du programme files est le pire exemple que tu puisse trouver, a ce compte tout le pourrais faire un mkdir /opt/truc et tout mettre dedans.

      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  . É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...

        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  . Évalué à 10.

          pour commencer, mosfet est une nana donc c'est 'elle' et pas 'lui' ;o)

          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  (site web personnel) . Évalué à 1.

            Euh justement non... Mosfet n'est pas une femme.
            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  . Évalué à -10.

              > Mosfet n'est pas une femme.

              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  . Évalué à -10.

                arg, je m'ai fais eu par des rumeurs :)

                fabien ! a quand le cancel de posts ?
                • [^] # Re: je comprend pas non plus

                  Posté par  (site web personnel) . Évalué à -7.

                  Euh vaut mieux pas, parce que sinon je trolle un gros coup(*), et dès qu'il commence à y avoir des réponses, je me cancel...

                  (*)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  . Évalué à 10.

                    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.
                    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  (site web personnel) . Évalué à -5.

                <gala>
                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  . Évalué à 10.

            Plus que le terme application, je pense que c'est le terme sous-ensemble qu'il faut mieux utiliser dans sa proposition.

            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  (site web personnel) . Évalué à -4.

            pour commencer, mosfet est une nana donc c'est 'elle' et pas 'lui' ;o)

            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  . Évalué à 9.

            pour commencer, mosfet est une nana donc c'est 'elle' et pas 'lui' ;o)

            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  (site web personnel) . Évalué à 10.

              le prob c'est plus l'héritage redhat que unix..
              • [^] # Re: je comprend pas non plus

                Posté par  . Évalué à 10.

                Tout a fait.
                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  . Évalué à 0.

                  hmmm... ca devait etre openwin, pas openview :).
                  mea culpa.
                • [^] # Re: je comprend pas non plus

                  Posté par  . Évalué à 10.

                  On peut aussi dire que c'est l'héritage Unix qui a incité à faire des répertoires différents, puisque c'était le cas pour X11.

                  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  (site web personnel) . Évalué à 6.

                    je me souviens que les 1ere version de KDE le script d'install (apres compil) installé les fichiers dans /opt/kde/ (bin/lib/etc..)

                    le tout à été changé pour la compatibilité redhat ..
                  • [^] # Re: je comprend pas non plus

                    Posté par  . Évalué à 7.

                    Ben en fait, le problème n'est pas vraiment la limite franche, c'est plutôt d'être obligé d'installer/désinstaller des trucs avec le gestionnaire de paquetage, parce qu'on est incapable de dire ce qui sert à une appli quand tout est mélangé dans /usr...
                    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  . Évalué à 3.

                      c'est plutôt d'être obligé d'installer/désinstaller des trucs avec le gestionnaire de paquetage, parce qu'on est incapable de dire ce qui sert à une appli quand tout est mélangé dans /usr...

                      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  . Évalué à 5.

                        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...

                        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  . Évalué à 1.

                          Entres autres choses urpm(X) gere les dependances de packages

                          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  . Évalué à 1.

                        Oui mais pourquoi ne pas avoir des bons gestionnaires de paquetages qui installent les fichiers dans des dossiers/sous-dossiers plus hiérarchisés ? Je pense que c'est cela qu'il veut dire le Mosfet : pourquoi parce qu'on utilise un super (parfait même) gestionnaire de paquetage ne peut-on pas installer proprement nos logiciels ?

                        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  . Évalué à -6.

              bon alors ... moi je dis mosfet est un garçille

              voila voila !
            • [^] # Reorganisation

              Posté par  (site web personnel) . Évalué à 7.

              Je suis completement pour une reorgasiation et c'est bien une des raisons pour lesquelles je fait tourner un linux from scratch depuis presque un an.
              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  . Évalué à 3.

            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 ;-)
            • [^] # Re: je comprend pas non plus

              Posté par  . Évalué à -9.

              Sans repeter pour la douzieme fois :

              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  . Évalué à 10.

            Et merde... oui, c'est bien un mec!

            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  . Évalué à 0.

              bah pour mozilla ca existe deja mais d une autre facon (sur une mandrake en tout cas )
              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  . Évalué à 6.

              personellement j'utilise un lfs et pour pas crader mon systeme a chaque recompilation je colle tout ce qui est pas indispensable dans opt, dans mon path j'ai ajoute /opt/bin et j'ai mis /opt/lib dans /etc/ls.so.conf. je fais des liens symboliques si besoin est et tout se passe tres bien lorsque je veux viere une aplis je'efface son repertoire dans /opt et j'enleve le liens. Pour les debutants des outils comme SYMLINK permettent de gerer ca facilement
              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  (site web personnel) . Évalué à 0.

              Ah non, viens pas nous mettre 1500 liens symboliques dans /usr
              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  . É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  (site web personnel) . Évalué à 10.

      Disons que je partage en partie son point de vue. La localisation de progs dans ces répertoires est plus ou moins justifié pour les binaires car cela permet de les appeler depuis la ligne de commande facilement grâce au path. En revanche, les ressources de ces applications peuvent se trouver ailleurs dans des répertoires eux, bien spécifiques... C'est un peu ce qui se fait avec le répertoire /usr/share, mais il faut reconnaître que c'est un peu le bordel... un peu plus d'organisation ne serait pas pour nuire, c'est clair.
      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  (site web personnel) . Évalué à 7.

        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...

        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  . Évalué à 2.

      La transparence et la clarté sont aussi les maîtres mots de la grammaire, de l'orthographe et de la précision de la pensée.
      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 [le retour]

      Posté par  . Évalué à -2.

      ce que je voulais dire par un repertoire program files , c est que le novice , tout comme l utilisateur un epu plus avancé (les gourous s en moquent je pense) vois ds tout c sous repertoires un "gros bordel" ; je sais bien que c un travers de windows zien , mais j aime avec une racine en windows avec winnt / prog file / et un repertoire de travail . je diférencie ainsi tres bien le system des appli et des documents . Bien sur sur un serveur on s en fou ; mais pourune workstation .... C d ailleur un gros prob pour ceux qui veuillent essayer ou passer sous linux : l arborescence est repoussante . Je ne suis pas assez fort pour repondre aux problemes technique que ca engendrerais (je parle du path de grde taille ) mais peut etre qu une bonne idée sserais la suivante :
      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  . Évalué à 6.

        Sur windows, t'as une arborescence a la /opt, c'est-a-dire que dans program files, t'as un repertoire par appli. C'est bien je pense.

        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  . Évalué à 4.

          que pensez vous du "menu démarrer" de windows, il affiche simplement le contenu d'un répertoire avec des liens vers les éxécutables.

          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  . Évalué à 3.

            Bin, sous la derniere mandrake, j'ai les memes menus partout... Y'a un programme pour les éditer (menudrake), ca rend le tout pas trop compliqué. Bon, j'avoue, je m'en sers jamais, mais ca a le mérite d'exister ;)
          • [^] # Re: C'est vrai que windows est pas mal, si si :

            Posté par  . Évalué à 3.

            Je ne sais pas si tu dis une conn...

            ...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  (site web personnel) . Évalué à 6.

              Tu ne vas pas me dire que la vue du contenu de c:/program files/ d'un systeme windows non formate depuis 6 mois te fais chaud au coeur. Avec 46 repertoires et 38 sous-repertoires...
              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  . Évalué à -4.

            et pas un rpm sur les redhat ne met à jour les menus.

            Installe une deb.
          • [^] # Re: C'est vrai que windows est pas mal, si si :

            Posté par  (site web personnel, Mastodon) . Évalué à 5.

            Le même principe existe sur MacOs (classic) où le menu Pomme correspond à un répertoire avec des racourcis. Les programmes sont stockés dans leur sous-répertoire dans Applications. Pour désinstaller un programme sous Mac, tu jettes le sous-répertoire de l'applicatif.
            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  . Évalué à 1.

            Le probleme est que kde et gnome gerent l internationalisation par default.
            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  (site web personnel) . Évalué à 10.

    Soit on fait comme maintenant, avec un répertoire bin/, un lib/, un share/ et un etc/ pour tous, ou soit on a un répertoire par application.
    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  . Évalué à 7.

      Oui mais il reste toujours la possibilité de faire des liens symbolique de plus toutes les applications ne servent pas tout les jours et on peut surement demander à l utilisateur Lambda de taper le chemin complet ou de créer des alias si cette application est souvent utilisée.

      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  . Évalué à 6.

        pour les binaires , ta solution fonctionne peut etre
        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  . Évalué à 6.

          Non, la solution des liens marcherait aussi. C'est d'ailleurs celle retenue actuellement pour choisir une version d'une librairie a la compilation.
      • [^] # Re: Y'a pas 50 solutions

        Posté par  . Évalué à 0.

        "Le problemme du path trop long est un faut problemme enfin je pense."

        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  . Évalué à 10.

      La plupart des shells modernent conservent une liste des exécutables disponibles dans les répertoires du PATH ; celle-ci est généralement créée au premier appel d'un binaire sans en donner le chemin absolu, et peux-être mise à jour(par exemple lorsque l'utilisateur change son PATH), par des commandes ad hoc (hash -r, rehash, etc).
      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  (site web personnel) . Évalué à 10.

        Concernant le PATH, ce que tu dis est exact, mais valable uniquement si on n'utilise qu'un seul shell. Or malheureusement j'ai tendance à voir une dizaine d'xterm avec chacun un bash dedans, donc [pour moi] le temps de hashage devient non négligeable.
        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  . Évalué à 6.

          C'est vrai que le cache est local à un shell mais je ne pense pas que ce soit un problème. En effet je pense qu'en dehors des commandes "systèmes" (grep, find, cut, etc.) il n'y a finalement pas des masses de commandes que l'on utilise souvent.

          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  (site web personnel) . Évalué à 4.

      tout a fait d'accord /opt doit etre remis au gout du jour pour les grosse surcouche a l'os

      /opt/X11
      /opt/Kde
      /opt/Gnome
  • # Pas franchement d'accord

    Posté par  . Évalué à 10.

    Il soulève l'impossibilité de facto de maintenir son installation sans passer par les outils de paquetage.

    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  (site web personnel) . Évalué à -1.

      paquetages ?

      paquets...
    • [^] # Re: Pas franchement d'accord

      Posté par  . Évalué à 2.

      C'est d'autant plus vrai pour les gros projets comme Gnome, Kde et GNUStep.

      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  . Évalué à 6.

        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...)

        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  . Évalué à 1.

          C'est à implémenter, mais ça peut se faire (il faudrait tenir compte d'une sorte d'historique des installations).


          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  . Évalué à 1.

            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...

            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  (site web personnel) . Évalué à -1.

        Oui, mais pour la désinstall de progs compilés, il suffit de conserver le Makefile et de faire un make uninstall pour le ménage de printemps !
        • [^] # Re: Pas franchement d'accord

          Posté par  . Évalué à -1.

          Encore faut-il que l'application propose un make uninstall, ce qui est loin d'être une habitude répandue...

          Meuuuuuh ;)
  • # Faudra qu'il explique ça à Ken Thompson

    Posté par  (site web personnel) . Évalué à 0.

    Mossfet est bien gentil de critiquer mais il faudra qu'il explique ça aux créateurs initiaux d'Unix (tel Ken Thompson) qui ont fait ces choix il y a plus de 25 ans (voire 30...).

    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."
  • # Je suis d'accord avec lui.

    Posté par  . Évalué à 2.

    Et pour resoudre le probleme, je mets tout dans / .
    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  . Évalué à 2.

    Je pense que mosfet est un peu trop "vielle école". Pour maintenanir un system qui utilise des packets comme debian, REDHET, SUSE, MDK, etc. il ne viendrait jamais a l'idée de bidouiller ces fichier a la main. C la notion meme de ces systèmes qui gère tout pour vous. Meme si ce la n'est pas très bien fait, ca a le mérite de marcher tout le temps. Effectivement, on pourrait organiser tout cela par sous rep, mais il faudrait changer de shell :
    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  (site web personnel) . Évalué à 7.

      Effectivement, on pourrait organiser tout cela par sous rep, mais il faudrait changer de shell :
      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  . Évalué à 10.

        "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."

        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  (site web personnel) . Évalué à 9.

      >au diable la varice... je ne comprend pas déjà pkoi /etc est différent d'une distib a l'autre, alors /usr..............

      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  . Évalué à 2.

        > comme sous Windows et MacOS on installe la
        > 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  (site web personnel) . Évalué à 3.

          > 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...)

          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  . Évalué à 2.

      Je pense que mosfet est un peu trop "vielle école".

      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  . Évalué à 10.

    ...sur toute distribution, de taper "man hier" pour avoir un exposé de l'organisation du file system. Cela fait partie du Linux Programmer's Manual, et date dans ma debian patate de 1997. Bonne lecture !
    • [^] # Re: Et pourtant il suffit...

      Posté par  . Évalué à -4.

      Chuuuuut, faut pas dire que Debian est mieux, c'est mal vu sur DLFP (surement parce que c'est vrai).

      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  (site web personnel) . Évalué à 1.

      ...sur toute distribution, de taper "man hier"
      Moi j'utilise "man demain" pour toujours garder une longueur d'avance

      (-1 parce que je le vaux bien)
  • # Mouaissss

    Posté par  (site web personnel) . Évalué à 10.

    Je ne comprend pas ce que Mosfet critique.
    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  . Évalué à 5.

      moi j'aime bien ce que tu dis !!

      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  . Évalué à 3.

      La question est doit on sacrifier la puissance et la polivalence au profit de la convivialité ?

      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  (site web personnel) . Évalué à 4.

      1) Modifier le système de fichiers Unix, implique de modifier le formats des binaires Unix
      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  . Évalué à 4.

      "Modifier le système de fichiers Unix, implique de modifier le formats des binaires Unix"

      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  . Évalué à 6.

      > Je ne comprend pas ce que Mosfet critique.

      $ 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  . Évalué à 10.

      ce que Mosfet critique, et il est vrai que je suis d'accord avec elle,ce n'est pas l'arborescence du système Unix qui est vraiment excellent, mais c'est
      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  (site web personnel) . Évalué à 6.

    Un avantage qui n'a pas encore été sité et que je trouve intéressant :
    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  (site web personnel) . Évalué à -1.

      "Et je crois que c'est un avantage énorme sur un serveur de prod... "

      tu installe des applis a tester sur un serveur de prod ? c'est mal ;)
      • [^] # Re: Un avantage...

        Posté par  (site web personnel) . Évalué à 1.

        Mais une appli, meme testé pendant des jours et des jours sur différentes configurations, peut très bien planter au moment de l'installation sur ton serveur de prod...

        Donc dans ce cas, c'est bien un test...
  • # et imaginez ce que c'est pour un FS repartis !

    Posté par  (site web personnel) . Évalué à 8.

    Je crois que /bin et /usr/bin historiquement, ont
    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

  • # Le beurre et l'argent du beurre

    Posté par  . Évalué à 10.

    Connaissez vous http://www.gnu.org/software/stow/stow.html(...)

    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  (site web personnel) . Évalué à 3.

      Et avec stow, tu peux avoir la cremière en plus. D'un côté un répertoire = une appli, de l'autre une hiérarchie classique bin/ lib/ man/ include/ etc.
      (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  . Évalué à 2.

        ouaip. je suis surtout coupable ne n'avoir jamais ecrit une doc potable du systeme.
        Mais c'est parce que je suis trop occupé avec la crémière ;)
  • # FHS, LSB, etc.

    Posté par  . Évalué à 7.

    Pour l'arborescence des fichiers, il existe une "bible" à laquelle les distributions devraient se conformer :
    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.

    il serait interessant que les applications graphiques du projet GNOME aillent dans /usr/X11R6/gnome/bin ou /usr/bin/gnome/

    (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  . Évalué à 0.

    Les modérateurs peuvent-il expliqué ce qui les a motivé a passer cette article en première page?

    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  . Évalué à 2.

      Les modérateurs peuvent-il expliqué ce qui les a motivé a passer cette article en première page?

      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  . Évalué à 2.

      > Ce type attaque RedHat sans ce pencher sur le système rpm.

      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  (site web personnel) . Évalué à 1.

      Ouais je suis d'accord avec toi
      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  . Évalué à 4.

    Les distros utilisant un systeme de packetage deb ou rpm qui gerent autotomatiquement les dependances. Ces distros ne restent consistante que si l'on installe une appli que sous forme de rpm, deb voire src.rpm ou src.deb. De ce fait la localisation des applis dans differents repertoires n'est pas essentielle.

    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  . Évalué à 1.

      Si c'était si difficile de faire des packages, il ne faudrait pas quelques centièmes de secondes à X-Or^Wpouaite et consorts pour faire un package de wmcoincoin !
    • [^] # Re: to pack or not to pack that is the question ?

      Posté par  (site web personnel) . Évalué à 2.

      tu as raison .. dans SID et WOODY y a rien, c'est pas mis à jour depuis deux an ...

      va faloir expliquer combien de fois ?
      • [^] # Re: to pack or not to pack that is the question ?

        Posté par  . Évalué à 1.

        SID, c'est bien la version instable ou si tu installes un package et que tout plante, il faut pas venir te plaindre?

        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  (site web personnel) . Évalué à 5.

      > Dans les distros (genre slack) sans gestion des dependances

      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  (site web personnel) . Évalué à 8.

    Vu que tout le monde donne son avis, je vais pas me priver :)

    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  . Évalué à 1.

      Je suis globalement d'accord avec cette idée de liens symboliques, même si je ne suis pas un expert de la chose.

      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  . Évalué à 1.

      "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"

      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  . Évalué à 1.

        La solution est donc non pas de mettre un lien
        /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  (site web personnel) . Évalué à 1.

    Hello ;)

    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  (site web personnel) . Évalué à 1.

    Moi j'aime pas /usr

    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

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.