GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

Posté par (page perso) . Modéré par Nÿco.
Tags : aucun
1
13
mai
2003
Linux
Nous connaissons tous l'organisation classique d'une distribution Linux et ses problèmes : difficulté d'isoler l'installation et surtout la désinstallation d'un programme dans le système, complexité de la gestion de PATH et des bibliothèques, gestion des dépendances. Ce sont ces problèmes qui ont conduit au développement des outils tels que rpm, apt-get ou portage.

L'auteur de GoboLinux nous propose ici une approche nouvelle : réorganiser le système de fichier.

Très souple, le système permet de garder un répertoire par programme installé et miroire tout à coup de liens symboliques vers des emplacements centraux, avec une philosophie qu'on peut retrouver sous MacOs X. Plus besoin de base de donnée des paquets installés, le système de fichier est la base de donnée. Le système peut s'essayer sur une distribution existante. A tester donc.
  • # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

    Posté par (page perso) . Évalué à 3.

    Ça me rappelle le système utilisé par ROX non ?
  • # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

    Posté par . Évalué à 2.

    ça me fait penser à Stow en mieux aller, je vais voir ça de plus près ;-)
  • # Bof,

    Posté par . Évalué à 4.

    Je n'ai pas compris : - Comment il gérait les dépendances avec ce système. - Comment il savait qu'une bibliothèque n'était plus utilisée. Franchement ca n'apporte aucune solution à ces problèmes mais il a raison de chercher si ca l'amuse :-)
    • [^] # Re: Bof,

      Posté par (page perso) . Évalué à 10.

      En bref : tu installe prog qui utilise la LIB1.0, puis prog2 qui as aussi besoin de la lib1.0, prog2 constate que la lib1.0 existe deja, il fait met juste dans son repertoire personel un lien vers elle ... tu installe prog3 qui propose la lib1.1(qui suporte toutes les fonctions de la lib1.0) : a l installe il en informe la lib1.0, et lui propose de se substituer a elle; le prog1 demande juste la lib1.0 ou superieure; tu va dans le repertoire du prog1, et tu met a jour le lien symbolique vers la lib1.1. Le prog2 lui ne veut QUE la lib1.0 refuse la mise a jour. On lui laisse juste pour lui : - le prog1 a profite de l update proposee par le prog3 - le prog2 conserve sa vieille lib1.0 - le jour ou tu met a jour prog2, ou que tu le suprime, le lien de prog2 vers lib1.0 sera suprime(eventuelement remplace par un autre lien vers libb1.2); par definition de tout system de fichier base sur les inodes, quand tu suprime le dernier lien qui pointe vers un inode, tu suprime cet inode: l ancienne version lib1.0 qui n est plus utilisee par personne est suprimee ipso facto. Donc ca gere a la fois les dependances, et la supression des lib inutiles. Des questions ?
      • [^] # Re: Bof,

        Posté par (page perso) . Évalué à 1.

        La, tu implique que tous les progs soient installés sur le même système de fichier (liens hard) c'est quand même un peu réducteur non ? Moi, j'ai l'habitude d'avoir certaines applis dans un /usr/net ou bien qui sont sur un montage nfs et j'utilise les liens hard le moins possible.
        • [^] # Re: Bof,

          Posté par (page perso) . Évalué à 7.

          Oui il semble preferable d avoire tout le /programme sur le meme disque physique ( local ou distant ) J'aimerai toute fois parler du problème des PATH : rien n'empeche de conserver un vieux /usr/bin qui contienne une liste de liens symboliques vers les versions courantes des programmes installes, et/ou d implementer un system qui permet que quand un tape "$ xfree", il aille chercher /programs/xfree qui pointe vers /programme/xreee-latest/xfree ... Au lieu d attaquer un system qui a du potentiel, essayez plutot de voire ses bons cotes et d en tirer profit.
          • [^] # Re: Bof,

            Posté par . Évalué à 1.

            sa bouffe pas de l'espace disque pour rien ?
            • [^] # Re: Bof,

              Posté par . Évalué à 1.

              Non justement a cause des liens.
              Par contre les liens hard sur des repertoires.... hmmmpf! (quoi ca marche on m'aurait menti ?).
            • [^] # Re: Bof,

              Posté par (page perso) . Évalué à -1.

              Les noms de fichiers, faut les supprimer, ça bouffe de l'espace disque. Rien ne vaut les inodes.
              • [^] # Re: Bof,

                Posté par (page perso) . Évalué à 2.

                La table des inodes, ca bouffe de l'espace disque. Rien ne vaut les raw data.
          • [^] # Re: Bof,

            Posté par (page perso) . Évalué à 3.

            Je suis loin d'attaquer, au contraire, ça me semble interressant, j'essaie de comprendre plus en profondeur les tenants et aboutissants car je travail sur un projet de déploiement sur plusieurs dixaines de machines. Tout ce qui peut simplifier la maintenance d'un tel système est bienvenue, le but est quand même un peu que les techniciens n'aient pas à sortir de leur bureau (presque) pour gérer le système.
            Ça me semble prometteur comme approche, j'ai déja un peu tendance à utiliser le même principe lorsque je compile des progs à la main :

            cd foo
            ./configure --prefix=/usr/local/foo
            make && make install
            ln -s /usr/local/foo/bin/* /usr/local/bin # qui est dans le PATH
            ln -s /usr/local/foo/lib/* /usr/local/lib

            Ça permet une bonne gestion à la mano, automatiser ça me semble être une bonne chose...
            • [^] # Re: Bof,

              Posté par (page perso) . Évalué à 1.

              Je suis loin d'attaquer,

              Désolé si tu l'as mal pris, mais ma dernière phrase n'était pas tournée contre ton post :/
              J'avais besoin de le dire, mais j'ai eu la flemme de le faire dans un commentaire diff'rent.

              /me se bat avec des verges.
              [-3] -> []

              Mais puisque tu as l'air d'aimer la simplicité; je te soumet une idée comme ça:
              Y as-t-il moyen de faire dans un cluster un /usr ou un /programmes qui soit en RO sur un server NFS ... comme ca tu met le server NFS a jour, et hop tout est upgradé en même temps ?
              NB: le server NFS peut être lui même un élément d'un cluster de clients, juste question d'accélérer les installs ...
              • [^] # Re: Bof,

                Posté par (page perso) . Évalué à 1.

                L'idée est en effet interressante, à condition pour un nombre "consistant" de machines que le cluster soit haute dispo, que les disques soient très rapides (imagine 25 users qui lancent kde ou openoffice en même temps ce que ça donne en bande passante ?
                Je pense qu'a cause de ces restrictions, c'est une solution économique (sur les plans temps, argent à cause de la place gagnée sur disque..., boulot) pour un réseau relativement restreint (je dirait < 500 machines en tout cas).
                Après, je vois plus une archi avecun serveur de déploiement (type cfengine) qui est beaucoup plus souple.
  • # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

    Posté par . Évalué à 7.

    heu, c'est pas nouveau comme approche... c'est le principe de stow*. j'ai même pas envie d'essayer... * http://www.gnu.org/software/stow/stow.html
  • # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

    Posté par (page perso) . Évalué à 5.

    Ce systeme parait naturel et intéressant, mais le fait de retirer completement le systeme de paquetage n'est pas une bonne chose. D'autant plus qu'il est tout à fait possible de faire la meme chose avec rpm ou dpkg. Il suffirait que chaque paquetage fasse le boulot lui meme, en installant ses fichiers dans /usr/logiciel_machin, puis en faisant les liens symboliques dans les scripts de post-install. Je pense que c'est meme faisable directement sur n'importe quelle distrib. Et son probleme avec les paquets "compat" n'en est pas un, parce qu'on peut très bien installer un paquet glibc3.2 en meme temps qu'un glibc3.1. Il faut juste que les noms de base des paquets soient différents. (quoique le dernier rpm permet maintenant d'installer en meme temps toto-1 et toto-2 s'il n'ya pas de conflit)
    • [^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

      Posté par (page perso) . Évalué à 5.

      <blockquote> Il faut juste que les noms de base des paquets soient différents. </blockquote> Dans le cas de Gentoo, le problème est géré par un système de "slots" : deux même apps de slots diffèrents sont considérées comme diffèrentes dans certains cas (par example on remplace pas une version par celle venant d'un autre slot lors d'une mise à jour). De plus chacun des packages (qui sont en fait des scripts) a la posiblité de spécifier un masque ou une version relative (comme "<2.4.18") dans ses dépendances. Voilà, j'voulais pas rester le dernier à pas avoir fait de pub pour ma distrib (comment ça elle gère pas les dépendances à la désinstallation? -_^)
  • # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

    Posté par . Évalué à 9.

    Non ce n'est pas nouveau, faire cela sur *nix date de la fin des années 80 avec NeXTSTEP. un autre hierarchie de type *Step/OSX http://www.linuxstep.org/documentation/LSFH-1.3/LSFH-1.3.txt
  • # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

    Posté par . Évalué à 5.

    difficulté d'isoler l'installation et surtout la désinstallation d'un programme dans le système, complexité de la gestion de PATH et des bibliothèques, gestion des dépendances. ET Ce sont ces problèmes qui ont conduit au développement des outils tels que rpm, apt-get ou portage = le probléme a déja été réglé. le système permet de garder un répertoire par programme installé le systéme actuel aussi: --prefix=/usr/local/kde (par défaut), je n'ai jamais eu de probléme. Peu de gens utilisent /opt/gnome2 ou /opt/kde, donc est que cette distro répond à une vraie demande des "utilisateur"? Très souple vraie question: le chemin /Programs/Netkit-Base/0.17 ne me plait pas, je veux /programmes/Netkit-Base/017 à la place. Le soi disant "front end user" qui a besoin de s'y retrouver dans sa hiérarchie de fichier parce qu'avant il ne trouvait pas intuitif de trouver et modifier /etc/fstab, ce front end user là il va pouvoir modifier lobo facilement pour obtenir /programmes/Netkit-Base/017? c'est intuitif ces scripts? Ou est ce qu'on a juste remplacer un "espace mental" (kuro5hin tm) par un autre? Est ce que le gain à s'y retrouver dans sa hiérarchie de fichier a été évalué par rapport au gain qu'on a à obtenir de l'aide sur le net quand on a un probléme avec l'ancienne : "bon keskya dans ton /etc/fstab ? fais 'cat /etc/fstab' et ecris moi keskya d'écrit. je vois le probléme fais rm -vf /proc/kcore"
    • [^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

      Posté par (page perso) . Évalué à -2.

      Est ce que le gain à s'y retrouver dans sa hiérarchie de fichier a été évalué par rapport au gain qu'on a à obtenir de l'aide sur le net quand on a un probléme avec l'ancienne

      Quoi, tu as un problème avec cette application ? Redémarre la machine. Si ça marche pas, essaie de réinstaller le logiciel. Si ça marche pas, réinstalles Windows.
  • # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

    Posté par (page perso) . Évalué à 4.

    Voilà qui est interressant !! c'est vrai que l'arborescence des *nix n'est évidente pour personne, encore moins pour des non initiés. De plus, cela d'une distribution à l'autre, et on hésite souvent où mettre de nouveaux programmes, ou de nouvelles données ! Par exemple, un répertoire commun à toutes les personnes qui utilisent la machine pour y placer des mp3, ou des videos. Tout le monde va mettre ca à un endroit différent (/home /var /usr /ceketuveux). Il devrait y avoir un emplacement du type /media, /programs, etc. C'est pour cela que je pense que l'arbo *nix est dépassée, et doit être revue. Ce projet semble prométeur, et je le soutiens complètement dans son action. Bravo, il faut oser le changement ! tout le monde s'en portera mieux (sauf les inconditionnels, mais bon.......).
    • [^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

      Posté par (page perso) . Évalué à 5.

      J'allais oublier : /etc sert maintenant à regouper tous les fichiers de config (+ les 'init') Pour moi, ca devrait dégager en /conf ou /config et /etc/rc* + /etc/init.d/ devrait aller dans /init ou mieux /boot/init/ Appelons un chat un chat après tout ! /etc porte bien son nom, on met là tout ce qu'on a pas réussi à classer. La fonction est aujourd'hui bien différente, et l'archi doit être revue
      • [^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

        Posté par . Évalué à 1.

        Pour reprendre ton exemple : mettons que /media, /programs existent. Qu'est ce qui empechent tes exemples d'utilisateurs du début qui mettaient des videos dans /home /var /usr /ceketuveux de les mettres dans /programs /config /bibliotheques /ceketuveux ???
        • [^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

          Posté par (page perso) . Évalué à 2.

          Il faudra adapter les commandes de gestion de fichiers pour qu'elles prennent en compte ce rangement différent. Ainsi "mv" fera appel à "file" pour déterminer le type de fichier, et si c'est pas un type accepté par le répertoire destination, il refuse "type de fichier incompatible avec le répertoire destination". Reste à savoir si beaucoup de personnes seront intéressées par ce genre de barrières... À la limite je ne suis pas contre ça me forcerait peut-être à ranger mon bord^W $HOME...
          • [^] # La marmotte : elle revient, elle n'est pas contente, elle a faim, elle n'est pas végétarienne.

            Posté par . Évalué à 9.

            C'est con : avant, déplacer un fichier était une opération relativement rapide et peu coûteuse. Désormais, il faudra créer un processus et charger un binaire qui consulte magic(5) (ou, mieux, son équivelent en XML méta-distribué via CORBA over HTTPv6 sur load-balancer), tout ça pour perdre du temps les 99% du temps où on sait ce qu'on fait[*].

            Encore, tu me dirais "je suis sysadmin et je veux faire Ch#@r mes utilisateurs", je comprendrais le concept. Mais là, si tu tiens vraiment à ralentir ta machine tout ça pour avoir le droit de te construire des barrières.... ben... je sais pas si un Unix est très adapté. à la limite, libre à toi d'écrire quelques scripts pour wrapper les commandes de base et te les infliger.

            C'est quand même marrant de demander à du logiciel +/- libre de fournir des limites à sa propre utilisation.

            [*] ça ressemble à un troll sur le typage fort, mais ce n'est pas un troll sur le typage fort
      • [^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

        Posté par . Évalué à 6.

        ln -s /etc /config Voilà tu la ton répertoire config :o=)
      • [^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

        Posté par . Évalué à 4.

        Appelons un chat un chat après tout ! /etc porte bien son nom, on met là tout ce qu'on a pas réussi à classer.
        en fait, non etc veut dire quelquechose comme editing text config,
        c'est la config de ton ordinateur, et tu peux l'éditer avec VI
      • [^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

        Posté par (page perso) . Évalué à 7.

        /etc porte bien son nom, on met là tout ce qu'on a pas réussi à classer. La fonction est aujourd'hui bien différente, et l'archi doit être revue

        Et donc tu veux changer le nom pour ça ?

        Je te conseille la lecture du FHS, ça pourrait t'ôter quelques escarbilles de l'œil. De même pour tous ceux qui pensent que la hiérarchie Unix n'est pas structurée.
        • [^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

          Posté par (page perso) . Évalué à 1.

          Je dirais pas qu'elle est non structurée, ni mal documentée, ni mal pensée, mais à l'exemple de l'IPV4, je pense que la hiérarchie est vieille, et qu'un petit lifting lui ferait le plus grand bien. Je ne dénigre pas le FHS que je ne connais que de nom, mais quel que soit le bien que tu pense du FHS, d'autre projets comme GoboLinux ne peuvent qu'aporter des idées neuves dans le cadre d'uin renouveau à longtermes :
          même si GoboLinux ne reste à jamais utilisé que par ses developeurs, plus on le fait avancer, plus ça donnera d'idées à ses sucesseurs: les noyeaux Linux, *BSD, mach et L4 sont autant de projets qui s'enrichissent mutuellement, tout comme KDE et Gnome, idem pour XFree et son fork ( enfin j'éspère ) [je passe sur les FS que je trouve toujours très proches entre eux] ... pourquoi pas la même pour les hiérarchies ?
    • [^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

      Posté par (page perso) . Évalué à 4.

      Tant qu'à oser le changement, autant l'oser complètement, et aussi remplacer linux par le Hurd, remplacer X par Fresco. Le changement est bon quand il est proposé sur des produits complètements différents. Tant qu'on reste dans GNU/Linux, autant en profiter pour respecter un minimum de cohérences, de standards et d'unité. Quand on en sera à GNU/Hurd/L4/Fresco, ce sera intéressant de proposer une arborescence différente d'Unix (puisque "GNU n'est pas Unix").
      • [^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

        Posté par (page perso) . Évalué à 0.

        <Trolle detector> BIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIP BIIIIIIIIIIIIIIIIIIIIIIIP BIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIP </Troll detector>
      • [^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

        Posté par . Évalué à 1.

        Pas d'accord avec toi: la raison pour laquelle, on n'utilise pas Hurd/L4/Fresco est technique: ils ne sont pas prèts.

        Tant qu'ils ne seront pas meilleurs que l'existant, on n'a aucune raison de changer.

        Une nouvelle hiérarchie de fichier comme sous MacOSX, n'est pas un problème technique, c'est un problème humain!
        L'intérét d'une organisation standard pour le système de fichier est qu'elle est standard justement, a cause des guéguerres entre les différents Unix commerciaux, le système de fichier standard n'a pas évolué et on se retrouve avec des abérrations du style /etc au lieu de /conf.

        La "guerre" entre les distributions Linux empècherait probablement d'avoir une nouvelle hiérarchie standard:
        - faut-il traduire les noms? (avis perso: non)
        - User ou Users ou user ou users ? (avis perso: user)
        - VideoFiles, "Video Files", video_files (avis perso: video_files)
        etc...
        On n'est même pas fichu d'avoir un seul système de packaging pour les divers Linux + BSD, ou un seul type de script de démarrage, alors avoir un nouveau système de fichier commun..
        • [^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

          Posté par (page perso) . Évalué à 1.

          >L'intérét d'une organisation standard pour le système de fichier est qu'elle est >standard justement, a cause des guéguerres entre les différents Unix >commerciaux, le système de fichier standard n'a pas évolué et on se retrouve >avec des abérrations du style /etc au lieu de /conf.

          Pourquoi croyez vous que ca soit standard ??
          Surement pour une uniformisation des *nix, mais aussi pour les humains ne pas se perdre dans les différents FHS si on laissait libre cours à différents FHS.

          /etc == "editing text config" !!
          Si c'est juste pour que "etc" soit renommé "conf" parce que cela sonne mieux aux oreilles de certains => aucun intérêt et perte de temps !

          C'est déjà bien on n'a "que deux"(à qq choses prêts) familles d'Unix (sysV et BSD), changer son petit nom à un répertoire car son nom ne sonne pas bien serait relancer des débats et forké d'autres FHS, d'où de nouvelles mouvances et une perte de standard.
        • [^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

          Posté par (page perso) . Évalué à 1.

          Le fait que l'on soit incapables d'avoir un system de boot-script commun est peut justement du au fait que l'on utilise la hiérarchie différement ... /etc est tellement floue que chacun y fait sa sauce ... même entre les distribes c'est la guerre : un jour /etc/init.d, un jour /etc/rc.d/ini.d, puis /etc/rc/init ... (je ne dénonce personne !)
          Il faut peut être voire une hiérarchie commune comme un premier pas vers la standardisation que tu réclame ... peut être :?

          Enfin quand je vois que dans une même débian, je me perds entre kde2 et kde3 qui sont organiées très differement, que la conf user de kdm et xdm sont ... je dirai ... rien a voire ... ( kdm dans /etc/kde, xdm dans /etx/X11 ... ) alors bon ... je suis très philosophe, et je prends mon mal en patience en attendant de jours meilleurs :(
      • [^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

        Posté par (page perso) . Évalué à 4.

        D'ailleur a mon avis ca serait la seule vrai solution pour qu'on s'interesse à Hurd/Fresco et autre. C'est qu'ensemble ils forment un nouveau système qui offre quelque chose de différent.
        D'ailleur on pourrait très bien imaginer :
        Hurd/Fresco & Cie pour le desktop
        Linux pour les serveurs
        Biensur il y aura toujours des gens pour utiliser l'un à la place de l'autre et vis et versa mais ca serait interessé et peu perturbant pour les EndUsers
  • # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

    Posté par . Évalué à 7.

    ok, mais le fhs la dedans, il devient quoi ?
  • # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

    Posté par . Évalué à 3.

    j'ai un fichier de 61 Mo dans /proc, c'est normal ?
  • # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

    Posté par . Évalué à 3.

    C'est en gros le système proposé depuis des années par DJB : http://cr.yp.to/slashpackage.html Un système qui a d'ailleurs été globalement très mal accepté, car trop en contradictions avec les coutumes d'antan. Le meilleur compromis reste à mon avis le systeme de Gentoo Linux, qui évite d'avoir 36000 répertoires tout en permettant malgré tout de faire joyeusement cohabiter plusieurs versions majeures d'un meme logiciel. Pour l'utilisateur c'est transparent grace à env-update, les dépendances sont correctement gérées, bref que demander de plus ?
    • [^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

      Posté par . Évalué à 2.

      trop de contradictions avec les coutumes d'antan?
      Mes alors les geeks nunuxiens seraient en fait des conservateurs? On m'aurait menti à l'insu de mon plein gré?
      Moi qui croyait que les logiciels libres étaient un joyeux bazar de créateurs inspirés des universités... n'auraient-ils gardés de la science que ses comportements grégaires et obtus?
      Dans la plupart des commentaires de cette news et dans ceux qu'on peut lire sur le site original je suis éffaré du conservatisme des nunuxiens sachant que ce système est concu pour justement s'interfacer en DOUCEUR avec les anciennes habitudes... snif.
  • # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

    Posté par (page perso) . Évalué à 1.

    C'est déjà dans MultiDeskOS ! oui, je sais -->[]
  • # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

    Posté par . Évalué à 1.

    bofbof de tout renomé comme ça...

    Le seul truc chiant est le mélange des repertoires selon l'application. /usr devrait avoir un repertoire par programme /usr/OOo ( en ro ) par exemple et un /var/OOo pour les donnés de l'application (les trucs qui ne sont pas relatifs aux utilisateurs, notament le .conf...). L'installeur ne devant pas avoir besoin d'être root.

    "La première sécurité est la liberté"

    • [^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

      Posté par (page perso) . Évalué à 1.

      L'installeur ne devant pas avoir besoin d'être root.

      Alors ça, je trouve que c'est plus que discutable... quel intérêt?
      • [^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

        Posté par (page perso) . Évalué à 1.

        pour des raisons de sécurité ou pour éviter qu'un soft bousille tout le système...
      • [^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

        Posté par . Évalué à 4.

        En fait la "bonne pratique" sous unix avant les packages c'etait un truc du genre:

        en tant que user normal:
        tar xvzf openoffice
        ./configure --prefix=/usr/local/openoffice
        make

        en tant que user root:
        preparation d'un environnement pour la nouvelle application:
        - creation d'un repertoire d'install /usr/local/openoffice
        - creation d'un user/group "openoffice" avec home dans /usr/local/openoffice mais sans shell.
        - chown openoffice:openoffice /usr/local/openoffice

        en tant que "openoffice"
        make install

        avec ce schema, il est necessaire d'etre root pour installer sur la machine,
        ou alors il est necessaire que ROOT prepare l'environnement d'installation,
        mais l'install en elle meme est faite par un user dédié a cette application,
        et la compilation par un user lambda du systeme.

        mais les packages on simplifié tout ca.
  • # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

    Posté par (page perso) . Évalué à 9.

    « Nous connaissons tous l'organisation classique d'une distribution Linux et ses problèmes : difficulté d'isoler l'installation et surtout la désinstallation d'un programme dans le système, complexité de la gestion de PATH et des bibliothèques, gestion des dépendances. Ce sont ces problèmes qui ont conduit au développement des outils tels que rpm, apt-get ou portage. »

    La plupart des distributions classiques comportent un système de gestion de paquet.

    Le problème est mal posé : les dépendances complexes, les lieux d'installation ont des avantages. Ce n'est pas un problème, c'est pensé pour être ainsi.

    Pour simplifier cette gestion - c'est à dire profiter des avantages en supprimant les inconvenient - les outils de gestion de paquets ont été inventé.

    L'affaire est close : ces outils existent en apporte quelque chose d'unique. On peut installer des programmes sans même se soucier de savoir quels sont les prerequis.

    « philosophie qu'on peut retrouver sous MacOs X »

    Mac OS X est invention récente qui signifie pour Apple de tendre vers les *BSD et systèmes libres en général. En quoi Mac OS X correspond à un modèle à suivre ? Parce que des gugusses d'O'Reilly prétendent que Mac OS X et MS Windows sont les SE les plus fabuleux de la terre (cf Interview) ?

    Je ne vois pas en quoi la gestion des paquets est mauvaise sous GNU/Linux. Tout est géré. D'autant qu'on parle souvent de 1000 paquets différents ! Une diversité de logiciels qui n'a rien à voir avec ce qu'on trouve sous d'autres SE.
    • [^] # Une fois de plus, les votes

      Posté par (page perso) . Évalué à 0.

      Merci à ceux qui ont voté moins de faire connaitre leur avis ?
      Pas le temps d'argumenter, de participer, mais celui de voter ?
      • [^] # Re: Une fois de plus, les votes

        Posté par (page perso) . Évalué à 1.

        ...laisse tomber, ils ont exprimé leur "pasdaccorisme"...

        Ton post est argumenté, no pb !
      • [^] # Re: Une fois de plus, les votes

        Posté par (page perso) . Évalué à 9.

        Effectivement, je comprends pas non plus, surtout que ton opinion semble être majoritaire dans le coin... Il reste donc l'option « tête qui revient pas » pour expliquer. M'enfin bon, ça m'étonne plus vraiment...

        Sinon, je rejoins assez ton avis : perso, je suis loin d'être un fan d'Unix et de ses idiosyncrasies, mais je pense que le système de fichiers n'est pas le truc le plus important à réformer. D'autant plus que l'argument généralement avancé (ça perd le débutant) est ridicule : vous avez déjà vu un Windows 2000 ? Vous avez 'Documents and Settings' qui joue le rôle de /home (avec plusieurs sous-répertoires par utilisateur), 'Program Files' (qui contient un peu tout et n'importe quoi : applis, DLL, fichiers de données, selon le bon vouloir du programmeur du soft), 'Winnt' et ses 'Inf', 'System', 'System32' (?!?), 'etc' (si, si), etc. Plus la base de registres et ses clés absconses. Allez donc y comprendre quelque chose ! À côté, Linux est beaucoup plus clair : un fichier de configuration ? Dans /etc. Un fichier verrou ? Dans /var/run, sûrement. On s'y fait assez vite, et en fin de compte, ce n'est pas gênant du tout. Le seul problème est celui de la désinstallation des applis, et comme on l'a dit, il y a les gestionnaires de paquets (ou ce bon vieux 'make uninstall', fourni par tous les programmeurs consciencieux). Certes, les /etc, /bin et autres /usr auraient gagné à être nommés de manière un peu plus claire, mais c'est secondaire. Alors, quel est le problème ?

        Plus haut, un distingué co-posteur fait remarquer que tout ceci ressemble à une attitude assez conservatrice. Je suis d'accord... Néanmoins, il n'y a rien de mal à mes yeux à être conservateur s'il n'y a pas besoin de tout chambouler. Le changement pour le changement, ça n'apporte rien, et ça a tendance à tout casser. D'un autre côté, je ne suis pas contre une réflexion sur le système de fichiers et son organisation dans le cadre d'un effort plus vaste. Entre autres, il me semble (je dis bien « semble ») me souvenir que cette approche « un répertoire par appli » était celle adoptée par BeOS. Et ça ne me pose pas de problème. Néanmoins, un des grands atouts des Unix libres, c'est qu'ils « se tiennent sur les épaules de géants », pour paraphraser un certain physicien. Quel intérêt alors de se couper de tout cet héritage, et des bénéfices qu'il apporte (compatibilité avec l'existant, transfert aisé des connaissances, etc.) ? Bien sûr, l'auteur a prévu une solution (à coups de ln -s), mais un admin débarquant sur GoboLinux n'en sera pas moins paumé. Enfin, j'insiste sur le fait que je pense qu'il y a d'autres priorités (comme avoir un sous-système graphique au goût du jour, unifier/simplifier des pierres d'achoppement comme la configuration des pilotes de périphériques, mieux intégrer les différentes interfaces avec le système sous-jacent, etc.). Bref, chambouler le système de fichiers me semble donc une approche peu naturelle, et pas franchement prometteuse pour ce qui est des bénéfices qu'on pourrait en retirer. Je ne ferai donc pas, pour ma part, l'effort de réapprendre un autre système, à moins qu'il ne m'apporte vraiment quelque chose de plus.

        [une petite note quand même : le site de GoboLinux semble avoir quelques problèmes de DNS et j'arrive pas à y accéder, je n'ai pu lire que l'article sur K5, j'ai donc peut-être raté une info importante. Une autre petite note : j'ai lu dans l'article qu'ils avaient aussi changé les scripts d'initialisation. Je ne pense pas non plus que l'init SysV soit une panacée universelle (il manque entre autres un moyen intégré de ne pas exécuter un script si tel ou tel autre a eu un problème). Néanmoins, je n'ai pas trop compris en quoi leur système se démarquait d'autres systèmes alternatifs comme simpleinit. Bref, rien de nouveau sous le Soleil, AMHA]

        Envoyé depuis mon PDP 11/70

        • [^] # Re: Une fois de plus, les votes

          Posté par (page perso) . Évalué à 3.

          > À côté, Linux est beaucoup plus clair

          Bof, si les clés de la base de registre ne sont pas claires, il y a une structure, pareil pour le système de fichier Unix classique. pas sur qu'un /usr/local/share soit plus logique qu'un HKEY_machin_chose.

          > un fichier de configuration ? Dans /etc

          ouais, enfin dans un des sous répertoires de /etc en général, et ce n'est pas toujours si simple à trouver si on ne connait pas le nom du fichier à l'avance.

          ou alors dans un .xxxx du répertoire home

          ou alors dans une clé de gconf (ben oui, on a beau critiquer la base de registre c'est un concept pas idiot).

          ou alors dans un /usr/kde/version/..... planqué quelque part

          > Un fichier verrou ? Dans /var/run

          ou /var/tmp ou /tmp ou dans le profile



          Bref, c'est organisé et ca marche, à mon avis c'est un truc suffisament fonctionnel pour éviter d'être changé à moins d'être vraiment sur que ca vaille le coup (parce que pendant la transistion il y aura un bordel immonde).
          Mais franchement ca n'est pas tout à fait clair. Il n'y a qu'à voir les applications qui sont dans /usr /usr/lesoft /usr/kde/version/... /usr/local /usr/local/lesoft /var (sisi j'en ai vu) /opt/lesoft /bin suivant les cas. Chacun donnera sa vision de ce à quoi correspondent ces répertoires mais il faut avouer que suivant les versions et les distributions des softs équivalents ne se trouvent pas placés au même endroit.

          Au contraire de toi je trouve l'archi Win meilleure (meme si _tres_ largement perfectible). Il y a plusieurs répertoires dans le home ? un pour les conf, un pour le menu, un pour les modèles de fichiers, un pour les video un pour la musique, un pour les autres docs ..... on aime ou on aime pas mais c'est cohérent.
          Perso j'aurai bien aimé avoir un simple .conf dans mon home, qui contient les répertoires de conf, plutot que plein de .xxxx mélangés avec les autres docs
          • [^] # Re: Une fois de plus, les votes

            Posté par (page perso) . Évalué à 2.

            <i>> un fichier de configuration ? Dans /etc

            ouais, enfin dans un des sous répertoires de /etc en général, et ce n'est pas toujours si simple à trouver si on ne connait pas le nom du fichier à l'avance.

            ou alors dans un .xxxx du répertoire home

            ou alors dans une clé de gconf (ben oui, on a beau critiquer la base de registre c'est un concept pas idiot).

            ou alors dans un /usr/kde/version/..... planqué quelque part

            Ben en fait, si c'est une config système editable en texte c'est dans /etc, si c'est une config perso c'est dans $HOME/.xxx
            Après c'est vrai que les environnements graphiques monstres, à mon avis vaut mieux pas toucher à la config en direct même si je le regrette.

            L'idée du .conf dans le $HOME est pas mal, mais à mon avis c'est un peu plus compliqué à mettre en oeuvre vu qu'il faut demander à chaque appli de modifier son comportement par defaut.
            Question: existe-t-il une option dans les installeurs rpm/apt/yast pour pouvoir préciser lors d'un déploiement d'appli que les fichiers de conf seront à tel ou tel endroit?
          • [^] # Re: Une fois de plus, les votes

            Posté par (page perso) . Évalué à 3.

            > Perso j'aurai bien aimé avoir un simple .conf dans mon home, qui contient les répertoires de conf, plutot que plein de .xxxx mélangés avec les autres docs

            [+++]

            Vrai ! Marre de cette tonne de .merdes qui saoulent bien dans $HOME...
          • [^] # Re: Une fois de plus, les votes

            Posté par . Évalué à 1.

            >> À côté, Linux est beaucoup plus clair
            >
            > Bof, si les clés de la base de registre ne sont pas claires, il y
            > a une structure, pareil pour le système de fichier Unix classique.
            > pas sur qu'un /usr/local/share soit plus logique qu'un
            > HKEY_machin_chose.

            Ça a au moins l'avantage d'utiliser une notion (le système de fichiers) que la plupart des admins, en culotte courte ou pas, connaissent.

            >> un fichier de configuration ? Dans /etc
            >
            > ouais, enfin dans un des sous répertoires de /etc en général, et
            > ce n'est pas toujours si simple à trouver si on ne connait pas le
            > nom du fichier à l'avance.

            Honnêtement, c'est de la mauvaise foi. S'il n'est pas directement dans /etc, ton fichier de configuration est dans /etc/<nom_du_prog>/conf...

            > ou alors dans un .xxxx du répertoire home

            Encore de la mauvaise foi. /etc est pour tout le monde, et chacun peut rajouter/remplacer/redéfinir ses options de configuration. C'est l'un des nombreux avantages d'Unix (par rapport à Windows), son support multi-utilisateur natif, propre et clair.

            > ou alors dans une clé de gconf (ben oui, on a beau critiquer la
            > base de registre c'est un concept pas idiot).

            Gconf, je ne connais pas, je ne sais pas pourquoi ils ont utilisé ce principe, donc je ne vais pas critiquer, même si ça me parait idiot et inutile (zut, j'ai critiqué).

            > ou alors dans un /usr/kde/version/..... planqué quelque part

            Pour revenir in-topic, le rôle d'une distribution est justement d'éviter ce genre d'"héréries" en unifiant tout ça. Bien sûr, des types comme le concepteur de qmail râle quand on veut déplacer ses fichiers (et pour d'autres raisons, je sais), mais l'important c'est ce que veut l'utilisateur. Si, comme moi, il veut quelque chose d'unifié, il doit pouvoir l'obtenir.

            >> Un fichier verrou ? Dans /var/run
            >
            > ou /var/tmp ou /tmp ou dans le profile

            Cf. ma réponse sur le rôle d'unification des distributions.

            > Bref, c'est organisé et ca marche, à mon avis c'est un truc
            > suffisament fonctionnel pour éviter d'être changé à moins d'être
            > vraiment sur que ca vaille le coup (parce que pendant la
            > transistion il y aura un bordel immonde).

            On se rejoint : le changement pour le changement, très peu pour moi.

            > Mais franchement ca n'est pas tout à fait clair. Il n'y a qu'à
            > voir les applications qui sont dans /usr /usr/lesoft
            > /usr/kde/version/... /usr/local /usr/local/lesoft /var (sisi j'en
            > ai vu) /opt/lesoft /bin suivant les cas. Chacun donnera sa vision
            > de ce à quoi correspondent ces répertoires mais il faut avouer que
            > suivant les versions et les distributions des softs équivalents ne
            > se trouvent pas placés au même endroit.

            Cf. ma réponse sur le rôle d'unification des distributions.

            > Au contraire de toi je trouve l'archi Win meilleure (meme si
            > _tres_ largement perfectible).

            Beuah. Un ami avait du mal à me faire avouer que finalement je n'aime pas Windows, mais au final c'est clair : il n'y a pas que des arguments philosophiques... Windows, caca.

            > Il y a plusieurs répertoires dans le home ? un pour les conf, un
            > pour le menu, un pour les modèles de fichiers, un pour les video
            > un pour la musique, un pour les autres docs ..... on aime ou on
            > aime pas mais c'est cohérent.

            Ah nan ! C'est la caricature de ce que je déteste sous Windows : on pense pour toi, on définit tes besoins quand il faudrait laisser le libre choix, et à côté de ça il y a une ribambelle de choses mal gérées ou codées avec les pieds... Je pense notamment à la gestion du réseau, par exemple le DNS... Argh, quelle horreur :-( Windows, caca !

            Pour te répondre, *JE* veux décider de la manière dont je gère mes données : si je veux un répertoire images, un répertoire vidéos ou encore un répertoire musique, je suis largement capable de les créer moi-même, et je ne pense pas que l'utilisateur lamdba ne le soit pas...

            > Perso j'aurai bien aimé avoir un simple .conf dans mon home, qui
            > contient les répertoires de conf, plutot que plein de .xxxx
            > mélangés avec les autres docs

            C'est ce que je me suis dit à une époque. Et puis j'ai poussé la réflexion, j'ai cherché les raisons et les idées des personnes qui ont décidé de la manière dont ça se passerait, et qui avaient probablement passé beaucoup de temps dessus.

            Et je me suis rendu compte que créer un répertoire spécialement pour les fichiers de configuration n'avait pas d'intérêt, puisqu'il ferait double emploi en quelque sorte avec les $HOME/.XXXX que tu décris tant. Quelle différence fondalement entre les deux systèmes ? Aucun, sinon que tu te retrouves peut-être avec un répertoire non caché pour ces fichiers de conf.
            Et ça, je déteste plus que l'idée d'avoir tout plein de $HOME/.XXXX ! Je supprime par exemple systématiquement le répertoire Desktop que me crée KDE les rares fois où je le lance, ou encore le répertoire GNUStep de Window Maker...

            En gros :
            Fichiers non cachés : tes données, ton utilisation perso.
            Fichiers cachés : les fichiers de configuration.

            C'est propre, pratique, clair, bien pensé, c'est Unix ;-)

            (Attention, un troll se cache dans la dernière phrase :-)
            • [^] # Re: Une fois de plus, les votes

              Posté par (page perso) . Évalué à 2.

              Fichiers non cachés : tes données, ton utilisation perso.
              Fichiers cachés : les fichiers de configuration.


              1) pb le .bashrc c'est de la conf ou de l'exec? Les .xxxx ne sont pas que du stockage de config. Donc ce n'est pas homogène.

              2) quand j'ai trop de fichiers dans un repertoire, je cree des sous repertoires. Donc quand j'ai trop de .xxxx, je crée des repertoires ad'hoc.


              Finalement, pourquoi ne pas créer un .conf , un .rc, un .data, un .desktops ?
              • [^] # Re: Une fois de plus, les votes

                Posté par . Évalué à 0.

                1) pb le .bashrc c'est de la conf ou de l'exec?

                C'est un fichier utilisé pour configurer ton shelle, non ?

                > Les .xxxx ne sont pas que du stockage de config. Donc ce n'est pas
                > homogène.

                C'est sensé être homogène, parce que les .xxxx sont sensés être des fichiers de configuration...

                > 2) quand j'ai trop de fichiers dans un repertoire, je cree des
                > sous repertoires. Donc quand j'ai trop de .xxxx, je crée des
                > repertoires ad'hoc.

                Justement, tout l'intérêt est que tu ne les voies pas, donc pas besoin de les trier au fond. Il suffit juste de faire "cd ~/.<programmes>" quand tu en as besoin. Je me trompe peut-être, mais créer un sous-répertoire pour les fichiers de configuration ne reviendrait qu'à taper ".conf/" en plus dans la commande ci-dessus.

                > Finalement, pourquoi ne pas créer un .conf, un .rc,

                Un rc ? Ton environnement utilisateur est bootable ?

                > un .data, un

                Ça existe déjà, c'est $HOME...

                > .desktops ?

                Là par contre je suis d'accord, c'est de la configuration. Et je suis d'autant plus d'accord si c'est unifié et si KDE et GNOME peuvent l'utiliser de concert. Mais c'est un autre débat je crois, et je n'aime pas les bureaux :-)
                • [^] # Re: Une fois de plus, les votes

                  Posté par (page perso) . Évalué à 2.

                  Pour moi un fichier de configuration, çà n'exécute pas de code, alors le .bashrc en fichier de conf, c'est discutable. D'ailleurs le rc, c'est "run command" non?

                  Le .rc, c'est justement pour stocker les fichiers .rc
                  .rc çà n'a pas grand chose à voir avec le boot, sauf si tu considères que le démarrage des services est obligatoirement lié au boot, auquel cas, il faudra que je revoie mes cours sur unix...Moi souvent, je fais un /etc/init.d/network restart, ou bien un init 1 suivi d'un init 3, sans rebooter la machine.

                  Le .data dans mon esprit n'est pas un $HOME, ce serait plutot un repertoire contenant des données applicatives qui ne sont ni des .rc, ni des config. Par exemple, des fichiers de swp de vi.

                  .desktops: pour tout le magma, .kde .gnome .wm .bidule_interface_graphique
                  • [^] # Re: Une fois de plus, les votes

                    Posté par (page perso) . Évalué à 1.

                    L'intérêt des bashrc executés, c'est ça : http://stock.coleumes.org/doc.php?i=/.bashrc(...)

                    Propose moi un format de configuration me permettant une telle finesse de configuration.

                    Un fichier de conf doit à un moment où un autre être interpreté. Pourquoi réinventer un interpreteur alors qu'on dispose de super interpreteurs (bash, perl etc...) ?
                    • [^] # Re: Une fois de plus, les votes

                      Posté par (page perso) . Évalué à 2.

                      L'objet de la discussion, c'est principalement de savoir s'il faut ou non trier les repertoires en .xxx dans le $HOME. L'essentiel n'est pas de savoir si un xxxrc est une conf ou un exec.
                      Je pense qu'actuellement les .xxxx encombrent le $HOME. Alors pourquoi ne pas faire un tri?
              • [^] # Re: Une fois de plus, les votes

                Posté par (page perso) . Évalué à 1.

                1) pb le .bashrc c'est de la conf ou de l'exec? Les .xxxx ne sont pas que du stockage de config. Donc ce n'est pas homogène.

                Je te renvoie a mon journal : http://linuxfr.org/~dhp/2648.html(...) qui montre à quel point fichier de conf, scripte, source, ou fichier executable est un concepte unique sous unix . Mon journal montre comment utiliser des sources C aussi simplement que des scripts PERL ...

                Mais le meilleur exemple que je conaisse est encore le fichier de conf de rp-pppoe, qui est une liste de paramètres, mais dans la premiere ligne tu met le chemin du démon, tu rends le fichier executable, et du coup, c est en executant la conf, que le demon se lance tout seul: je trouve cette utilisation tout simplement GENIALE, et evite d avoir a taper :
                $ demon -c .conf
                Il suffit aliors de taper:
                $ /etc/demon/conf
                ou encore
                $ ~//conf
                et ca roule tout seul ...

                Oui je sais, ce principe est fort criticable, n'est pas aplicable à tout, et va un poil à l'encontre des usages et coutumes, mais il exploite 100% des spécificités des UNIX, et n'est pas dénué d'intérret ...
            • [^] # Re: Une fois de plus, les votes

              Posté par . Évalué à 2.

              > En gros :
              > Fichiers non cachés : tes données, ton utilisation perso.
              > Fichiers cachés : les fichiers de configuration.

              C'est vrais que c'est très clair, sauf que certains logiciels t'ouvrent une boite d'ouverture de fichiers qui les listent tous (cachés et non cachés) et ça c'est très gonflant de s'appuyer a chaque fois la liste des x repetroires de conf avant ses propres répertoires.
              Voilà, simple avis de simple utilisateur.
          • [^] # Re: Une fois de plus, les votes

            Posté par . Évalué à 1.

            <blockquote>Au contraire de toi je trouve l'archi Win meilleure (meme si _tres_ largement perfectible). Il y a plusieurs répertoires dans le home ? un pour les conf, un pour le menu, un pour les modèles de fichiers, un pour les video un pour la musique, un pour les autres docs ..... on aime ou on aime pas mais c'est cohérent.</blockquote>

            J'allais dire OUI. Mais en fait non. Regardons ce qu'il y a à l'intérieur du Home made in Windows (Documents and Settings, super pratique en ligne de commande :-) :

            Application Data, Bureau, Cookies, Favoris, Local Settings, Menu Démarrer, Mes documents, Mes documents récents, Modèles, SendTo, UserData, Voisinage d'impression

            Et les sous-répertoire sont pas mal non plus. C'est vraiement trop le bordel pour servir de modèle, et pour s'y repérer confortablement. En pratique on va directement dans "Mes documents". Et KDE et GNOME ont aussi un répertoire Documents dans lequel je vais directement. Bref, en réalité, il y a aucune différence : Windows s'est unixifié, et Unix s'est windozifié.

            Quant à la localisation (partiel) des répertoire est une idiotie sans nom, qui ne fait et ne fera jamais que compliquer les choses. La meilleure solution est définitivement de localiser éventuellement les liens sur le bureau. Je ne parle même pas des noms à rallonge avec espace. Ce serait un répertoire qui contient un album de MP3, je dis pas, mais là pour un répertoire système, c'est vraiment se foutre de la gueulle de la ligne de commande.

            Quant au répertoire système (Windows), c'est encore plus un bordel sans nom. Bref, je préfère sans aucun doute l'arborescence Unix classique. Enfin je préferais, parceque maintenant je préfère celle de GoboLinux, Na !
        • [^] # Re: Une fois de plus, les votes

          Posté par (page perso) . Évalué à 1.

          [...]et pas franchement prometteuse pour ce qui est des bénéfices qu'on pourrait en retirer.

          Je n'ai rien contre le début du paragraphe, mais là, je te trouve trop "économe" : les LL ne se veulent pas "rentables", mais nu fouillis innomable d'idées d'adolescents qui s'ennuient. Si le mec a envie de faire un thèse sur les arbres de données, et de prendre comme exemple de thèse une nouvelle hiérarchie, je trouve déplacé de ta part de le lui reprocher ... et là, il publie son travail ... (même si en pratique c'est pas du tout ça)
          • [^] # Re: Une fois de plus, les votes

            Posté par (page perso) . Évalué à 1.

            Bah franchement, j'ai plus vu ça comme l'énième tentative de mettre le so^H^H^W^W^H^H'imposer sa vision des choses (à la DJB. D'ailleurs, j'ai lu dans un autre thread que lui aussi a proposé une hiérarchie de ce genre) plutôt qu'une tentative expérimentale. Je serais plus d'accord par exemple s'il avait créé un nouveau type de FS avec des caractéristiques novatrices. Sans compter qu'on peut faire du neuf avec du vieux, regarde OBSD : leur nouveau pare-feu, pf, est compatible avec l'ancien, et pourtant il a de nouvelles fonctionnalités... M'enfin, de toute manière, je ne vais pas hurler à la mort si Gobolinux continue son petit bonhomme de chemin. C'est juste que, perso, je vais pas l'utiliser parce que j'y vois pas d'intérêt...

            Envoyé depuis mon PDP 11/70

    • [^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

      Posté par (page perso) . Évalué à 1.

      Je ne vois pas en quoi la gestion des paquets est mauvaise sous GNU/Linux.

      Ben, comment je fais quand j'ai cassé ma base rpm et que les rpm me sortent un "Seg fault" ?
      Bien sûr il aurait fallu faire des sauvegardes, bien sûr le système rpm n'est pas le meilleur, etc...
      Mais bon, un système qui permet de se passer d'une base de données "fermée" enfin pas trop ouverte, je pense que çà peut être bien.
      • [^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

        Posté par (page perso) . Évalué à 1.

        RPM marche bien.

        Je n'ai « cassé » de base de données RPM que lorsque j'ai découvert GNU/Linux. J'ai utilisé des RedHat pendant 3 ans sans m'en plaindre.
        Il y a d'ailleurs une option --rebuild qui reconstruit la base en cas de problème.

        Je ne vois pas l'intérêt de « faire des sauvegardes » des RPM. Un RPM est un logiciel. Il suffit de reinstaller le RPM - à quoi bon le sauvegarder, suffit d'avoir un CD avec ces RPM.
        En cas de pépin avec un RPM, rpm -e --force $paquet_brisé && rpm -ivh
        $paquet_brisé.

        Je ne vois pas où est le malentendu !

        Au contraire, tu ne peux pas virer un paquet qui à des dépendances. Tu peux très bien virer DirectX d'un ordi même si t'as StarCraft installé...
    • [^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

      Posté par . Évalué à 1.

      Je connais un Monsieur qui n'est sans doute pas d'accord avec toi:
      http://linuxfr.org/comments_reply,2727,208129,5.html(...)
      • [^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

        Posté par (page perso) . Évalué à 1.

        Je pense que monsieur découvre Debian.

        Je copie-colle ici pour faciliter la lecture :
        "apt-get install qt3-qtconfig ... il a besoin de jarter tous les packages liés à KDE ...
        Bon je desinstalle le tout et j' essaye un apt-get install kde ... il a besoin de retirer deux packages libqtmt et qt-config ...
        Faut qu' on m' explique la ^^ "

        Si cet utilisateur à besoin de KDE, pourquoi se soucie t-il de qt3-qtconfig ?
        Qu'il fasse un simple
        apt-get install kdebase
        Ca lui demandera peut-être de virer certains paquets. S'il veut comprendre pourquoi, qu'il lise les listes de discussion des devs. Certains paquets sont en conflits entre eux, proposant les même programmes souvent. L'utilisateur doit se soucier uniquement des logiciels. A vrai dire, les paquets prévus dépendent des responsables debian qui font des choix en théorie en connaissance de cause.

        Je n'ai aucun qt-config installé et j'ai KDE 3.1
        J'ai
        777. libqt2_3:2.3.1-22
        778. libqt3c102-mt_3:3.1.1-8
        Mais je n'en ai cure, je me soucie juste d'avoir
        380. kdebase_4:3.1.1-1
        qui m'a choisi les lib* qu'il faut.
  • # CiDepot et Files ?

    Posté par . Évalué à 3.

    "Here's what ls / looks like on GoboLinux [avec un patch noyau pour cacher l'arborescence classique]
    Depot
    Mount
    System
    Files
    Programs
    Users"

    "Each program directory (for example, /Programs/KDE) holds version directories (/Programs/KDE/3.0, /Programs/KDE/3.1.1), and a version-neutral directory for settings (/Programs/KDE/Settings), to keep files that would normally be in /etc."

    "/bin, /sbin, /usr/bin, /usr/local/bin (and so on) are all symlinks to /System/Links/Executables" [idem pour Libraries, Headers, Shared and Manuals]

    Mount remplace Mnt. Et Users remplace Home, en y intègrant le repertoire du "root", qui s'appelle maintenant par défaut Gobo :-)

    Je me suis demandé à quoi correspondait entre autre "Depot" et "Files".... J'ai trouvé ça dans la discussion sur kuro5hin : "

    "Files" holds extra files needed by applications that are not part of the app package itself: plugins, codecs, audio patchsets... In other words, things you won't replace when you upgrade your app in /Programs.

    "Depot" is more like a 'common user area'. Its contents are not dictated by the GoboLinux hierarchy, the user uses it and sets permissions as/if he/she sees fit. Think of it as a /pub directory. Maybe it does make more sense in a single-user machine, but I can see it being useful in a multi-user setup. For example, I keep my MP3s in /Depot/Music.

    /proc is on /System/Status, and /var is on /System/Variable. They work as usual. Their symlinks at the root directory were hidden with GoboHide. /log is /var/log, in other words, /System/Variable/log. Whether Files (actually Depot) should be separate from Users or not, it's a matter for the users to decide. I'd rather share stuff with other users of my machine putting them on /Depot than opening up permissions of specific directories of my $HOME (I like to keep it rwx------). But that's just me."

    Moi j'aime bien.

    Par ailleurs, pendant que l'on est dans les concepts radicaux, existe-t-il un logiciel "mime center" qui recense les fichiers Mime de différents programmes connus, qui attribue à un de ces logiciels le statut de "mime master" (konqueror par exemple), et qui récrivent régulièrement par dessus les fichiers de configurations des autres, les "mime slaves" ?
    • [^] # Re: CiDepot et Files ?

      Posté par . Évalué à 7.

      Moi j'aime pas
      Pourquoi mettre des majuscules à ces noms de dossiers ?
      C'est chiant lorsqu'on navigue dans le sytème de fichiers
      par la ligne de commande. Ou alors, quitte à ne pas être conservateur,
      on leur rajoute des espaces, comme dans
      $ ls [shift]my[tab]
      My Documents
      My Music
      merde
      $ ls [shift]my[antislash][espace]D[tab]
      • [^] # Re: Depot et Files ?

        Posté par . Évalué à 1.

        J'avais par remarqué :-( Je dirais bien vive le "case insensitive" et le "_" qui équivaut à " " et réciproquement, juste pour t'agacer et pour montrer que je suis vraiment radical, mais ce serait trahir ma pensée.

        Mais pourquoi diable ont-ils mis des majuscules à leur files system ?
        • [^] # Re: Depot et Files ?

          Posté par . Évalué à 2.

          En fait si. En tout cas je pose la question :

          A quoi ça sert concrètement de distinguer readme, ReadMe, readME, README dans un même répertoire ?

          Pourquoi ne pas rendre " " et "_" interchangeable, de façon à avoir à la fois des jolis noms de fichiers (undercore beurk) et des fichiers faciles à utiliser en ligne de commande ?
          • [^] # Re: Depot et Files ?

            Posté par (page perso) . Évalué à 5.

            Il parait qu'il y a un OS qui fait ca mais c'est plus cher.
          • [^] # Re: Depot et Files ?

            Posté par (page perso) . Évalué à 1.

            A quoi ça sert concrètement de distinguer readme, ReadMe, readME, README dans un même répertoire ?

            Les fichiers qui commencent avec une majuscules sont affichés en premier quand tu fait un ls. (tu le savais peut etre déjà). Ce qui fait que README (qui est sensé etre un fichier important) est affiché dans les premiers. Donc readme et README n'ont pas la même utilité. l'un va etre planqué dans toute la liste des fichiers l'autre sera au début.

            Tout ca pour dire pas grand chose finalement.

            par contre, je suis contre les espaces, les soulignés et les majuscules dans les noms de répertoires... pas facile à taper pour se déplacer dans l'arborescence. (en ligne de commande évidement)
            • [^] # Re: Depot et Files ?

              Posté par . Évalué à 1.

              Je pensais qu'il y avait une raison précise. Cela dit, je n'aimerais pas du tout que Gnu/Linux implémente le "case insensitive". Ca fait brouillon, pas rigoureux. Et puis avec la touche Tab et les recherche "insensitive" ça ne pose du coup plus aucun problème. Et puis ça emmerde les windoziens quand ils hébergent leur site web sur un serveur Unix.

              Par contre je trouve toujours les _ très moches, je préfère les espaces, c'est plus jolis. Le probleme c'est qu'un espace c'est joli, mais avec un \ devant et entouré de guillemet, c'est tout de suite moins bien. Rendre équivalent _ et " " me semblait une idée marrante, mais tout bien réfléchi ça pose plus de problèmes que ça en résoud.

              Boaf, finalement c'est très bien comme c'est avec le \ devant le " ".
              • [^] # Re: Depot et Files ?

                Posté par . Évalué à 1.

                > Par contre je trouve toujours les _ très moches, je préfère les
                > espaces, c'est plus jolis.

                Moi aussi, et la touche espace est plus facile à attraper que la toucher souligné.

                Et comme les concepteurs de Shells furent du même avis que nous, ils ont eu la bonne idée de définir l'espace et non le souligné comme séparateur de commandes et autres options sur la ligne de commande.

                ;-)
            • [^] # Re: Depot et Files ?

              Posté par . Évalué à 2.

              Les fichiers qui commencent avec une majuscules sont affichés en premier quand tu fait un ls.

              Ça dépend de la localisation utilisée. En français, par exemple, ls affiche "foobar" avant "README". Et en plus il ignore les "." : un ls -a dans $HOME affiche les répertoires et fichiers cachés au milieu des autres...
            • [^] # Re: Depot et Files ?

              Posté par (page perso) . Évalué à 1.

              Les fichiers qui commencent avec une majuscules sont affichés en premier quand tu fait un ls.

              Désolé de te contredire, mais dans ma Debian ou j'ai activé tous les alias du .bashrc, "ls" mixe les cases, et encore pire : "ls -a" me met les .* en vrac dans le reste

              NB : alias ls='ls --color=auto'
              NB2 : exemple : $ls -a
              [...]
              hurd
              .ICEauthority
              .irssi
              iteam
              Jan1903.jpg
              .java
              [...]

              oui je sais c'est horrible :(
          • [^] # Re: Depot et Files ?

            Posté par . Évalué à 1.

            Parce que, l'insensibilité à la casse, ça n'a aucun sens, et c'est beaucoup
            plus difficile une fois sorti des caractère anglais [a-z] ==> [A-Z]

            Quelques exemples ?
            en allemand , il y a le ß qui en majuscule devient ss
            tchüß -> TCHÜSS
            maintenant, si tu le remets en minuscule, ça va donner
            TCHÜSS -> tchüss

            De plus, le passage en majuscule change suivant les langues :
            citroën -> CITROEN en français, mais
            citroën -> CITROËN en canadien français

            Si tu veux gérer tout ça, non seulement le système de fichers devra
            être au courant des petits détails de chaque jeu de caractères,
            mais en plu chaque opération dessus aura à regarder quelle locale
            est utilisée pour déterminer si deux noms sont équivalents.
            Si tu pense que c'est simplle, lit la FAQ d'unicode http://unicode.org(...)
            et je pense que tu ne suggèrera plus un système de fichiers insensible
            à la casse.

            Moi en tout cas, ça me convient très bien comme ça.
            • [^] # Re: Depot et Files ?

              Posté par . Évalué à 1.

              > citroën -> CITROEN en français, mais
              > citroën -> CITROËN en canadien français

              Allons bon, ce n'est qu'en canadien français qu'il faut mettre des accents aux majuscules ?

              Moi qui suis tout content de cette possibilité de XFree, qui trouve ça joli et qui a pris l'habitude... :-/

              Alors alors ? Verdict ?
              • [^] # Re: Depot et Files ?

                Posté par (page perso) . Évalué à 0.

                Pour moi un système d'exploitation se doit d'être fiable avant d'être joli.

                Par conséquent, un caractère est un caractère, pas un ensemble aux limites floues.
                Un 'A' est un 'A'. Un 'a' est un 'a'.
                Si quelqu'un veut mettre sa touche "mes gouts et mes couleurs" il n'a qu'à developper son frontal. Pourquoi pas?
                Pour ma part, rien que les espaces dans les noms de fichiers çà me gêne, rien que pour la programmation en shell. Faut tout mettre en double cotes et quand on doit faire des scripts m4 ou similaires ca devient le bazar...
                • [^] # Re: Depot et Files ?

                  Posté par . Évalué à 1.

                  Tu es à côté de la plaque, parce que moi aussi. Je ne participe pas au débat (enfin pas avec ce commentaire en tout cas), je pose une question de linguistique, enfin d'orthographe.

                  Sinon, pour participer au troll quand même, parce que ça chatouille : avec des idées comme ça, on serait tous sous Windows, parce qu'un ordinateur est un PC, un système d'exploitation est Windows, et que la diversité c'est pas bien.
                  • [^] # Re: Depot et Files ?

                    Posté par (page perso) . Évalué à 1.

                    Si ça peut te rassurer, on DOIT (dixit l'Imprimerie Nationale) mettre des accents aux majuscules en Français. Exemple connu : "le palais des congrès" => "LE PALAIS DES CONGRES"

                    Si on reprends de vieux manuscrits, ils ont les accents. Ne pas mettre d'accents sur les majuscules date au pifomètre de l'introduction des premières machines à écrire, d'origine anglo-saxone, et qui donc n'en disposaient pas. Mais c'est une erreur, car cela peut nuire à la compréhension, d'autant que ce n'est pas un problème de les utiliser sur les machines/OS actuels.
                    • [^] # Re: Depot et Files ?

                      Posté par . Évalué à 1.

                      > Mais c'est une erreur, car cela peut nuire à la compréhension,

                      Ok, et merci pour la réponse. D'autant plus que je trouve ça plus joli.

                      > d'autant que ce n'est pas un problème de les utiliser sur les
                      > machines/OS actuels.

                      Sans mauvaise blague, on peut y arriver facilement sous Windows ?
                      • [^] # Re: Depot et Files ?

                        Posté par (page perso) . Évalué à 1.



                        Ça dépend de ce que tu nommes « facile ». Si je me rappelle bien :

                        <alt gr>+0171 pour le guillemet ouvrant [«]
                        <alt gr>+0187 pour le guillemet fermant [»]
                        <alt gr>+0192 pour le A accent grave [À]
                        <alt gr>+0199 pour le C cédille [Ç]
                        <alt gr>+0200 pour le E accent grave [È]
                        <alt gr>+0201 pour le E accent aigu [É]

                        En fait, c'est toujours <alt gr>+0<code ASCII décimal>. Tu peux obtenir le même effet sous la console Linux en te faisant une map clavier perso (voir man dumpkeys, man keymaps, etc.), et je l'ai utilisé pendant un certain temps, mais maintenant, je trouve quand même le système des séquences Compose plus naturel...

                        Et je confirme que c'est bien une Bonne Chose[tm] que d'utiliser ces caractères : ne vous laissez pas avoir par ce que vous a dit votre prof' de français ! Petit rappel au passage, un article pas mal sur la typo : [http://www.uzine.net/article1802.html(...)].

                        Envoyé depuis mon PDP 11/70

                    • [^] # Re: Depot et Files ?

                      Posté par (page perso) . Évalué à 1.

                      "A l'école, les tables sont en bois."
                      -4 au brevet des collèges pour faute de conjugaison !
            • [^] # Re: Depot et Files ?

              Posté par (page perso) . Évalué à 1.

              De plus, le passage en majuscule change suivant les langues :
              citroën -> CITROEN en français, mais
              citroën -> CITROËN en canadien français


              Non, non même en français il faudrait mettre des majuscules accentuées :

              http://www.langue-fr.net/d/maj_accent/maj_accent.htm(...) et la page désormais classique sur linuxfr http://academie-francaise.fr/langue/questions.html#accentuation(...)

              Pensez à l'environnement avant d'imprimer ce commentaire - Please consider the environment before printing this comment

      • [^] # Re: CiDepot et Files ?

        Posté par (page perso) . Évalué à 3.

        T'aimes pas surtout parce que tu n'as pas lu le pourquoi de la chose!
        deja c'est pas "My Music" ou "My Program" mais ca serai plutot dans leur philosophie "Music" et "Program". ensuite la majuscule est explique aussi, il faut lire, mais de nos jours les gens preferent rabacher RTFM aux gens qui posent des questions plutot que de se demander en premiers si eux mêmes ont RTFMé. va dans un répertoire, et fait m, et regarde le nb de choix possible. fait ensuite M, et compte.
        les fichiers qu'on cree comportent rarement des majuscules en premier caractère, donc en mettatn une majuscule, au nom du répertoire, ca completera plus aisément le nom.

        Display all 1285 possibilities? (y or n)
      • [^] # Re: CiDepot et Files ?

        Posté par (page perso) . Évalué à 3.

        Ce n'est pas chiant, c'est une question d'habitude. Personnelement, je nommes naturellement mes fichiers avec des espaces et autres caractères étranges. Et puis c'est con de ne pas utiliser les caractères accentués et majuscules ;)
  • # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

    Posté par (page perso) . Évalué à 0.

    En faite sa revient un peu au Program files de Windows à la différence qu'il y a une gestion des dépandance
    • [^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

      Posté par (page perso) . Évalué à 2.

      Pas du tout, cela n'a rien a voir. Vas lire l'article tu verras que tu te trompes. Je m'explique: lorsque tu installes un prog dans le rep poubelle (Program Files), ca te fout plein de truc dans ta base de registres, mais ca regarde dans Windows/System(32) pour les gestions de lib (dll si tu preferes), etc...
      Gobolinux n'en a pas du tout cette philosophie, c'est le systeme de fichiers qui sert d'arbre de dépendances et base de données/registre en quelque sorte.
  • # Récapitulons.

    Posté par (page perso) . Évalué à 3.

    Avec GoboLinux, la configuration du système est éparpillée aux 4 vents.
    Avec GoboLinux, il est impossible de mettre /usr sur une partition à part (à moins d'utiliser shadowfs et donc la hurde).
    Avec GoboLinux, les données d'un même type ne sont pas dans les mêmes répertoires. Ainsi, impossible de séparer les fichiers dépendants et indépendants de l'architecture, de mettre certaines parties de /var sur des disques à part, de virer toutes les documentations d'un coup.
    Avec GoboLinux, les bases de données de polices, de documentations, de plugins, et j'en oublie, deviennent un cauchemar à gérer.

    Tout ça, pour avoir une gestion des dépendances moins évoluée qu'avec dpkg ou rpm. Bienvenue sous Windows. Euh, sous BogoLinux.

    Au risque de me répéter, je recommande la lecture du FHS. On peut y comprendre que la structure des répertoires dans les Unix modernes n'a rien d'anarchique, et qu'elle répond à un certain nombre de besoins.
    • [^] # Re: Récapitulons.

      Posté par . Évalué à 2.

      On peut y comprendre que la structure des répertoires dans les Unix modernes n'a rien d'anarchique, et qu'elle répond à un certain nombre de besoins... dont se passe la grande majorité des utilisateurs.

      Admettons que l'arborescence GoboLinux se fasse une place au soleil, ce qui n'est pas gagné, cela ne posera pas plus de problème que la co-existence de rpm et deb, et bien moins que la co-existence de KDE et de Gnome. (En effet l'arborescence classique demeure, en lien et caché). Je me doute bien que les administrateurs de grands réseaux ne vont pas changer un système de fichier qui permet des réglages fin juste pour gagner en convivialité.

      Quant à moi j'en ai marre de devoir distinguer /bin, /sbin, /usr/bin, /usr/local/bin... et pareil pour les librairies et la doc. Je me fiche que l'on me reproche de vouloir rapprocher Linux de Windows et MacOS. Eux ne se gènent pas pour se rapprocher sans cesse de Unix, qu'ils le taisent ou le confessent.

      Et la FAQ a achevé de me convaincre :
      "Is it a newbie-oriented distribution? No, it is not. It is geared towards people who prefer to install applications from the original source packages. That is the main reason why each application gets its own directory: so you can install it from source there and then remove it with an "rm -rf". So, you see, GoboLinux is oriented at the experienced user who doesn't like things to be automagical."

      Super pour avoir facilement plusieurs versions d'un même logiciel. Parceque s'il y a bien un truc que je n'aime ni sur Linux, ni sur Windows, c'est les procédures d'installation et de désinstallation : et vas-y que j'te mets des trucs bidules un peu partout. Avec les systèmes de package, soit on est super-user, soit on est super-newbies. Pas d'intermédiaire pour apprendre en douceur...
      • [^] # Re: Récapitulons.

        Posté par (page perso) . Évalué à 1.

        checkinstall
        installpkg / upgradepkg / removepkg

        Et vive /usr/local
        • [^] # Re: Récapitulons.

          Posté par (page perso) . Évalué à 1.

          Tu as beau utiliser /usr/local tes fichier seront eparpilles:
          /usr/local/bin
          /usr/local/lib
          /usrl/local/share/monappli
          etc.
          • [^] # Re: Récapitulons.

            Posté par (page perso) . Évalué à 1.

            Grosse nuance, ils sont répartis comme d'habitude !
            Et de toutes façons pour les enlever,
            # removepkg monappli
          • [^] # Re: Récapitulons.

            Posté par (page perso) . Évalué à 1.

            installation :

            ./configure --prefix=/usr/local/stow && make && make install
            cd /usr/local/stow
            xstow tralala-1.5.2


            désinstallation :

            xstow -D tralala-1.5.2
            rm -fr tralala-1.5.2
          • [^] # Re: Récapitulons.

            Posté par . Évalué à 1.

            Eparpillés ou au contraire triés par type de données ?
      • [^] # Re: Récapitulons.

        Posté par (page perso) . Évalué à 3.

        On peut y comprendre que la structure des répertoires dans les Unix modernes n'a rien d'anarchique, et qu'elle répond à un certain nombre de besoins... dont se passe la grande majorité des utilisateurs.
        Pas forcément.
        Mettre /usr sur une partition séparée, c'est utile pour tout le monde.
        Les bases de données qu'une arborescence intelligente permet de mettre en place, elles profitent à tout le monde. À moins que tu ne t'amuses à configurer tous les chemins de fontconfig et/ou defoma à la main...

        Quant à moi j'en ai marre de devoir distinguer /bin, /sbin, /usr/bin, /usr/local/bin... et pareil pour les librairies et la doc.
        Pour ça, la structure de Hurd, utilisant shadowfs pour séparer les partitions mais rendant ce processus transparent pour l'utilisateur, est à mon avis un progrès dans le bon sens. Éparpiller les fichiers n'importe où, par contre, ne l'est pas.
        Le système de fichiers Unix est conçu suivant un principe simple : les fichiers d'un même type vont au même endroit. De la doc ? /usr/share/doc. Des polices ? /usr/share/fonts. Des icônes ? /usr/share/icons. Des bibliothèques partagées ? /usr/lib. Et franchement, une fois que c'est installé, qu'est-ce qu'on s'en tape que telle icône vienne de Gnome ou que telle police vient d'un bundle nommé Freefont ? L'utilisateur s'en contrefout, c'est le rôle du gestionnaire de paquets de gérer tout ça.
      • [^] # Re: Récapitulons.

        Posté par . Évalué à 4.

        > Quant à moi j'en ai marre de devoir distinguer /bin, /sbin,
        > /usr/bin, /usr/local/bin... et pareil pour les librairies et la
        > doc.

        Lis la documention du FHS... Avant, je raisonnais comme toi. Sa lecture m'a ouvert les yeux et m'a fait changé d'avis.

        J'en aussi ai profité pour changer d'avis quand à ma position sur des choses sur lesquelles tout plein de gens se sont creusés la tête, et j'ai appris par commencer à respecter la position à laquelle ils sont arrivé, au lieu de commencer par vouloir tout remettre en cause sans savoir de quoi je parle.

        On commence par rentrer dans un débat, par comprendre les arguments qui circulent, avant de vouloir participer. Ça évite d'être ridicule en avancant des idées qui ont déjà été démontées mille fois.
        • [^] # Re: Récapitulons.

          Posté par . Évalué à 1.

          Bon, bon, je vais la lire cette documentation.

          Mais c'est pas ça qui me rendra moins (éternel) débutant...
          Et tant que serais débutant, ça me soulera de voir Linux et Windows installer des petits bouts de fichiers de configuration et de librairie un peu partout. Surtout maintenant que j'ai découvert que ce n'est pas indispensable.

          De plus j'ai beau connaître l'arborescence unix, dans la pratique ça m'embrouille. Et comme aucun des arguments entendu ici ne m'a convaincu que j'allai regretter l'échange (Je ne m'y attendais pas d'ailleurs, je pensais que j'avais encore dit une connerie facilement démontable), je vais être obligé de lire la doc du FHS (zzzzzzz).

          Menfin sauf grosse surprise, je DL GoboLinux... on verra bien déjà si j'arrive à l'installer :-)
    • [^] # Re: Récapitulons.

      Posté par (page perso) . Évalué à 2.

      Au risque de me répéter, je recommande la lecture du FHS. On peut y comprendre que la structure des répertoires dans les Unix modernes n'a rien d'anarchique, et qu'elle répond à un certain nombre de besoins.

      Certe elle répond à un certains nombres de besoins (notement des besoins réseaux). Cependant, je pense que ca ne correspond pas aux besoins de certains types d'utilisateurs. Par exemple ceux qui ne sont pas administrateur système et qui n'ont pas plein de machines en réseau chez eux. (comment ca, tous les utilisateurs de Linux ne sont pas comme ça ?)

      L'inconvénient de l'arborescence FHS c'est qu'elle n'est pas toujours intuitive.
      (j'ai toujours pas compris l'interet de /opt).

      Et que l'on soit obligé de lire un PDF de 40 pages pour comprendre comment ca fonctionne me gene un peu. Pas pour moi mais pour les gens qui aimeraient bien se mettre a GNU/Linux mais qui ne comprennent rien à l'arborescence et qui laissent tomber.

      Je pense qu'il faut trouver une nouvelle hierarchie qui propose les mêmes souplesses que FHS mais un peu plus intuitive. (non je n'ai pas la solution, désolé)

      Julien
      • [^] # Re: Récapitulons.

        Posté par (page perso) . Évalué à 2.

        Perso, je cherche également un moyen d'avoir le beurre et l'argent du beurre.
      • [^] # Re: Récapitulons.

        Posté par (page perso) . Évalué à 3.

        /opt est utilisé pour les programme qui ne s'integrent pas a l'arborescence d'unix. Malheureusement, beaucoup de gens ignorent ce fait et installent tout dans /usr/local. Pourtant /usr/local doit etre utilisé pour les programmes installés a la main mais s'intégrant dans l'arborescence unix.

        [gnumdk@cassiope gnumdk]$ ls /opt
        arkanae_0.6/ cube/ E16.tar.bz2 SoundStudio-1.0.3/ VD/ Xmusix/
        babygimp/ e16/ e17/ phoenix/ stella/ wgm/
        [gnumdk@cassiope gnumdk]$
        • [^] # Re: Récapitulons.

          Posté par . Évalué à 1.

          le problème c'est que le débutant ne saura pas trop si le programme va s'intégrer dans l'arborescence de unix...
          • [^] # Re: Récapitulons.

            Posté par . Évalué à 1.

            Le débutant, il utilise le système de paquets de sa distribution.

            S'il veut aller plus loin, il devra commencer par admettre qu'il doit lire la documentation des personnes qui ont construit les outils qu'il veut utiliser.
      • [^] # Re: Récapitulons.

        Posté par . Évalué à 1.

        > Et que l'on soit obligé de lire un PDF de 40 pages pour comprendre
        > comment ca fonctionne me gene un peu. Pas pour moi mais pour les
        > gens qui aimeraient bien se mettre a GNU/Linux mais qui ne
        > comprennent rien à l'arborescence et qui laissent tomber.

        Tu prends le problème à l'envers. Les personnes qui doivent lire un document, ce sont celles qui veulent participer au débat et savoir comment et pourquoi telle ou telle décision a été prise.

        Les autres, ils suivent les décisions prises. S'ils veulent participer, ils doivent d'abord comprendre, et donc lire la documentation, parce que les personnes qui veulent participer au débat...
    • [^] # Re: Récapitulons.

      Posté par (page perso) . Évalué à 2.

      Moui je suis assez d'accord avec tout ça.

      De toute façon je crois qu'on se pose un peu trop de questions ici.
      Pour l'utilisateur qui connait très bien Linux, la hiérarchie adoptée ne devrait pas poser de problèmes : une lecture du FHS et effectivement on sait de quoi on parle.
      Pour l'utilisateur débutant ou celui qui ne veut pas comprendre comment fonctionne sa machine et ben il s'en fiche pas mal que 'frozen-bubble' soit dans /usr/bin plutôt que dans /Programs : il utilise rpmdrake ou tout autre gestionnaire de packages graphique il installe son logiciel et c'est tout.

      Comme le disait quelqu'un plus haut il y a d'autres urgences pour Linux. Et puis je ne vois pas en quoi un système de dépendances basé sur des liens symboliques pourrait être aussi riche que rpm ou apt. Il n'y a qu'a voir le nombre d'options pour effectuer des requêtes avec ces outils...

      Pensez à l'environnement avant d'imprimer ce commentaire - Please consider the environment before printing this comment

      • [^] # Re: Récapitulons.

        Posté par (page perso) . Évalué à 1.

        Je continuerais à installer avec urpmi le_prog et désinstaller avec urpme le_prog sans me poser la question de savoir où est installé le logiciel. Il se lance quand je tape son nom, c'est tout ce que je veux.

        Je comprends bien que l'arborescence proposée semble plus intuitive, mais au fond si ça doit au final générer une usine à gaz, je dis non. D'autant que l'arborescence qui gère les dépendances, je trouve ça moyen.
  • # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution

    Posté par . Évalué à 1.

    Souvent pour une installation à la main d'un programme (surtout avec des mises à jour +ou- fréquentes et plusieurs versions stables/unstables) c'est une très bonne idée de compiler et installer dans des rep différents et utiliser des liens symboliques dans /usr/bin ou autre pour l'utilisation courante.

    Pour une distrib entière cela pourrait poser des problèmes par exemple pour les systèmes de sauvegardes (toute la config dans /etc, les logs dans /var/log c'est pratique ..) mais si le système est bien fait, il devrait gérer tout ça...

    Cela dit les rpm et autres ont des scripts d'installation qui vont plus loin que la simple copie de fichier : gestion des dépendances fines, config auto des programmes, des menus kde gnome etc ..

    Autre point : on pourrait voir un avantage du système de gobolinux pour faire des packages mutli-distrib mais comme les répertoires ne sont pas les même d'une distrib à l'autre c'est pas gagné (d'où la LSB).

    En conclusion, la souplesse des liens symboliques peut être très utile mais ça ne règle pas forcément tous les problèmes ..

Suivre le flux des commentaires

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