Articles précédents : Distribution
- [5] XtreemOS : utiliser une grille de calculateurs comme un PC
- [2] Toutou Linux 03-01 est disponible
- [91] Fedora 8: le loup-garou est lâché !
- [26] Présentation de la mini SliTaz GNU/Linux
- [55] Comment faire avancer le projet OLPC ?
- [0] Frugalware 0.7
- [110] Ubuntu 7.10 : lâchez le singe !
- [20] Mandriva passe à l'est
- [153] Déjà la nouvelle année 2008 pour Mandriva Linux
- [42] Sortie d'openSUSE 10.3
Liens connexes
- Les nouveautés de la version 014 (288 clics)
- La présentation de GoboLinux (1332 clics)
- La FAQ (232 clics)
- Copies d'écran de GoboLinux (1055 clics)
- Page de téléchargement (190 clics)
- DLFP (2003) : GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution (359 clics)
Dépêche modérée par
Dépêche éditée par
Distribution : Sortie de Gobolinux 014
Posté par patrick_g (page perso, ). Modéré le 08 janvier 2008.
Celle-ci contient KDE 3.5.8, Glibc 2.5 et Xorg 7.2 ainsi que des nouvelles versions des outils de gestion spécifiques de GoboLinux. L'ISO téléchargée ne contient aucun programme propriétaire et le CD gravé permet, outre l'installation en mode graphique, de tester GoboLinux en mode LiveCD.
Ce liveCD est extrêmement adaptable et il est possible d'utiliser les outils GoboLinux pour se construire une version spécifique adaptée à ses besoins.
![[en]](../../../images/en.png)
Les nouveautés de la version 014 (288 clics)![[fr]](../../../images/fr.png)
La présentation de GoboLinux (1332 clics)-
La FAQ (232 clics)
-
Copies d'écran de GoboLinux (1055 clics)
-
Page de téléchargement (190 clics)
-
DLFP (2003) : GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution (359 clics)
> Lire la suite (73 commentaires, moyenne: 2,9). [dépêche : 3445 caractères]
Normalement une application s'installe dans plusieurs répertoires : /etc, /usr/bin, /usr/share, etc. Avec GoboLinux chaque application possède sa propre arborescence dans /Programs. Ainsi le programme Firefox réside simplement dans /Programs/Firefox et la suppression de ce répertoire avec un simple rm -rf supprime complètement le programme.
Pour conserver la compatibilité avec l'existant GoboLinux utilise un système de liens symboliques qui masquent la nouvelle hiérarchie. Les scripts d'un programme n'ont donc pas à être modifiés car le mapping du système de fichier permet de respecter les prérequis de ces programmes.
Outre cette redéfinition du système de fichier GoboLinux propose également des outils spécifiques facilitant la gestion de la distribution.
Comme celle-ci est basée sur la compilation des sources le programme InstallPackage permet de télécharger facilement le tar.gz sur les dépôts de la distribution. Le programme Dependencies liste les dépendances du programme et le programme nommé Compile permet, vous l'aurez deviné, de compiler simplement les sources en suivant les recettes (des fichiers texte plus simples que les ebuild de Gentoo). Bien qu'on puisse supprimer un programme en effaçant son répertoire il existe également l'outil RemoveProgram qui s'occupe d'effacer tous les liens qui pointaient vers ce programme. Si on désire simplement désactiver temporairement un logiciel il est possible d'utiliser DisableProgram.
On voit qu'avec tous ces outils spécifiques GoboLinux propose une distribution particulière mais cohérente, un peu dans l'esprit de Pardus qui choisit d'écrire ses outils plutôt que de modifier l'existant.
Le problème, comme avec toute distribution originale et peu répandue, est l'absence de nombreux programmes sur les dépôts. Les deux premiers tests effectués dans l'interface de recherche (tellico et comix) ont renvoyé la réponse "No results match your query".
Dans bien des cas il faudra donc télécharger les sources sur le site officiel du programme en question et écrire la recette soi-même.
En conclusion on peut dire qu'en dépit de sa hiérarchie de fichiers simplifiée, rationnelle et uniforme la distribution ne vise pas les utilisateurs débutants. Le but est de se passer des gestionnaires de paquets classiques et d'administrer autrement sa machine. Comme le dit la FAQ : Nous ne prétendons pas que GoboLinux est plus facile, seulement qu'elle a "plus de sens".
étonnant
Bonjour,
C'est étonnant, cette arborescence.
Ma première pensée fut : "on dirait l'arborescence windows"
Je vais la tester en live. :-)
@+
-
[^]Re: étonnant
Posté par etham (page perso, ) le 08/01/2008 à 09:47. (lien). Évalué à 1.L'impression que j'avais de windows, c'est qu'un programme s'installe un peu partout (dll éparpillées, base de registre, raccourcis qui restent à traîner dans le menu une fois le programme désinstallé, etc.
L'idée de mettre un programme par répertoire est super, au contraire.
Là, l'intérêt de linux from scratch se fait partcuclièrement sentir.
Dès que j'ai le temps, je teste !-
[^]Re: étonnant
Posté par Simon Gillet (page perso, ) le 08/01/2008 à 10:39. (lien). Évalué à 3.C'est pas un peu comme ça que Mac OSX fonctionne?
/Applications/programme_name avec toute
l'arboresence dedans?-
[^]Re: étonnant
Posté par Larry Cow () le 08/01/2008 à 10:48. (lien). Évalué à 2.Oui et non. Le principe des Bundles de MacOSX/GNUstep (qui est également celui des "Application directories" de RiscOS et descendants) fait de l'application quelque-chose de manipulable par l'utilisateur. Il peut la balader où il veut, et pas uniquement dans /Programmes ou /Applications. S'il veut la lancer depuis un CD ou une image-disque, il peut aussi (bon, si l'appli est mal faite et veut écrire dans son propre répertoire, ça sera une autre paire de manches).
Enfin, il n'y a pas de liens symboliques vers l'application. Même dans le cas des librairies (Frameworks, en terminologie *Step), l'éditeur de liens est censé les trouver tout seul (grâce à un index tenu à jour automatiquement, je présume) et non via des symlinks. Bon, dans la pratique, ça marche pas sur GNUstep (en tous cas tant qu'il repose sur Linux ou un BSD classique), mais MacOSX fait manifestement comme ça.-
[^]Re: étonnant
Posté par oops (page perso, ) le 08/01/2008 à 10:51. (lien). Évalué à 2.>Bon, dans la pratique, ça marche pas sur GNUstep (en tous cas tant
>qu'il repose sur Linux ou un BSD classique), mais MacOSX fait
>manifestement comme ça.
Il me semble plutôt que cela ne fonctionne pas sous GNUstep/Windows.
Je pense que cela fonctionne sur GNUstep/*nix.-
[^]Re: étonnant
Posté par Larry Cow () le 08/01/2008 à 11:54. (lien). Évalué à 2.Je n'ai pas joué avec GNUstep depuis plusieurs années, mais à l'époque le linker de Linux (ld?) refusait de charger les libraires depuis une liste dynamiques de répertoires - ce qui aurait été nécessaire pour le comportement que je décrit plus haut. Donc les librairies GNUstep étaient, même sous Linux, installées en un point bien précis de l'arborescence.
Cela dit, ça a pu changer (et j'aimerais autant, à vrai dire).
-
-
-
[^]Re: étonnant
Posté par patrick_g (page perso, ) le 08/01/2008 à 10:49. (lien). Évalué à 1.Je crois que MacOS X n'a pas de bibliothèques partagés et a choisi de dupliquer toutes les bibliothèques dans chaque répertoire de programme.
C'est vrai que c'est simple et pas prise de tête mais c'est du gâchis d'espace et ce n'est pas très satisfaisant intellectuellement.-
[^]Re: étonnant
Posté par Philippe Fremy (page perso, ) le 08/01/2008 à 11:02. (lien). Évalué à 1.T'es sur qu'ils copient les bibliothèques en entier ? A mon avis, ils font juste des liens hard. C'est simple et économique.
-
[^]Re: étonnant
Posté par GeneralZod () le 08/01/2008 à 11:10. (lien). Évalué à 6.Euh, si les bibliothèques partagées existent sous OS X: les fameuses dynamic libraries souvent encapsulés dans un"framework" (un bundle contenant la dylib, les headers, la doc etc ..)
http://developer.apple.com/documentation/DeveloperTools/Conc(...)
-
[^]Re: étonnant
-
-
-
[^]Re: étonnant
Posté par Sytoka Modon (page perso, ) le 08/01/2008 à 11:25. (lien). Évalué à 3.> L'idée de mettre un programme par répertoire est super, au
> contraire.
Oui, mais pour tout ce qui est partagée : bibliothèque, fontes des polices...
Finalement, sous Linux aussi, cela se simplifie car il n'y a plus de dossier /usr/X11/bin donc plus de sépcificité pour X11.
De même, les programmes qui en ont besoin ont un dossier sous /usr/lib a leur nom...
J'ai parlé pour debian que je connais mais je pense que les autres vont dans le même sens...
Au final, les deux approches convergent.-
[^]Re: étonnant
Posté par Thomas Preud'homme (Jabber id, ) le 14/01/2008 à 22:24. (lien). Évalué à 1.Sans compter le problème du partitionnement. Actuellement c'est bien agréable de se dire que toute la conf tient sur une partition. Avec cette hiérarchie de fichier la conf est éparpillé dans toutes les applis. Bonjour l'intérêt ...
--
Don't run, we are your friends : IFM (http://intergalacticfm.com)-
[^]Re: étonnant
Posté par mirak mirak () le 15/01/2008 à 14:47. (lien). Évalué à 2.je me vois pas réutiliser entièrement /etc, je l'ai jamais fait tel quel, j'ai toujours sauver /etc et récupéré ce que je voulais dedans
-
-
-
Plus de sens ?
En quoi cette hiérarchie à t-elle plus de sens ? Et pour qui ?
Parce que Windows a 50 répertoire pour 50 applications ?
C'est une philosophie différente d'organisation, d'accord, mais qu'elle ait plus de sens me dépasse.
-
[^]Re: Plus de sens ?
Posté par etham (page perso, ) le 08/01/2008 à 09:52. (lien). Évalué à 3.Un intérêt que je vois c'est que la personne qui débarque sans connaître unix, et qui se ballade dans son arborescence de fichiers n'est pas assommée par la complexité du système.
-
[^]Re: Plus de sens ?
Posté par benja () le 08/01/2008 à 17:25. (lien). Évalué à 0.Un intérêt que je vois c'est que la personne qui débarque sans connaître unix, [...]
Peut-on encore appeller cela un unix ?-
[^]Re: Plus de sens ?
Posté par Philippe Fremy (page perso, ) le 08/01/2008 à 17:41. (lien). Évalué à 4.Un aspect intéressant, c'est que c'est une des distribution les plus LFS compliant. Comme la partie LFS est entièrement "émulée", ils ne s'embêtent pas avec tout l'historique qu'ont les autres distributions et peuvent être 100% compatible :-)
-
-
-
[^]Re: Plus de sens ?
Posté par ercete () le 08/01/2008 à 10:02. (lien). Évalué à 4.Je découvre Gobolinux et je trouve l'idée intéressente.
Moi je trouve qu'elle a plus de sens, mais tu fais bien de souligner le POUR QUI ?
Pour quelqu'un habitué à comprendre l'organisatiopn actuelle des distribs linux, celle-ci est cohérente et a donc un sens. Celle de GoboLinux a également un sens qui je suis d'accord ressemble à celle de windows.
Je trouve que c'est pas un mal.
Prenons maintenant mon jeune ami Bob, comédien dans le théatre qui n'a connu que Macintosh dans sa jeunesse et Windows ensuite.
Bob n'est pas féru d'informatique et ne veut pas le devenir, il veux bien passer à Linux mais ne veux pas apprendre trop de choses compliquées.
Lorsqu'on présente à cette personne une arborescence / Linux
ou bien même une arborescence C:/ à la windows,
Pardonnez-moi mais Il reste perplexe.
A mon avis si je lui montre l'arborescence de Gobo :
* Programs
* Users
* System
* Files
* Mount
* Depot
C'est quand même déjà plus frais, plus clair et plus aéré.
En revanche un habitué de linux la trouvera peut-être "limitée", mais dire qu'elle est moins claire, ce serait de la mauvaise foi.
"la suppression de ce répertoire avec un simple rm -rf supprime complètement le programme."
Je suis sceptique sur ce genre de fonctionnement, mais si c'est effectivement le cas, c'est assez pratique.
Qui n'a jamais eu de "petit frère" qui supprimait les programmes de cette façon ?--
- SIGNER TUE-
[^]Re: Plus de sens ?
Posté par Pinaraf (Jabber id, ) le 08/01/2008 à 10:07. (lien). Évalué à 4.Dis moi, Bob il a quoi à foutre de l'arborescence de son système ?
Il a juste à connaître son dossier personnel, qui est accessible par l'icône maison.-
[^]Re: Plus de sens ?
Posté par ercete () le 08/01/2008 à 11:58. (lien). Évalué à 3.Effectivement, mais ta remarque n'est pas toujours vérifiée, surtout sur une machine desktop pour papa/maman/Bob.
Lorsque cherches un fichier sur ton disque dur usb par exemple,
et que tu l'ouvre avec un logiciel un peu 'oldschool'.
Tu es bien forcé de passer par /mnt ?
Donc tu passes devant une énorme arborescence à l'aspect déroutant pour un novice.
Il existe évidemment les Volume Manager dans KDE et GNOME mais personellement je ne suis pas fan, pour la bonne et simple raison qu'il n'ont déjà pas le même fonctionnement :
les liens genre /:media me paraissent rarement standard de l'un à l'autre; à moins que ce ne soit du freedesktop mais bon j'ai souvent été dérouté en passant des applis gnome à kde sur ce point.
Et ce n'est qu'un exemple, il ne t'es jamais arrivé de devoir aller fouiller dans /usr/share pour des icones ou dieu sait quoi d'autre ?
Attention je ne dis pas que Gobolinux résoud tous ces problèmes, mais plutôt que c'est une bonne initiative de ce pencher dessus.--
- SIGNER TUE-
[^]Re: Plus de sens ?
Posté par Mathieu Stumpf (Jabber id, page perso, ) le 08/01/2008 à 13:00. (lien). Évalué à 3.Oui mais si j'en crois ce que tu écris plus haut, pour ton exemple, l'utilisateur devra aller chercher son répertoire dans /mount au lieu de /mnt... Autant lui faire un lien /disques_usb -> /mnt et dans ce cas pas besoin de gobolinux.
Enfin je ne dis pas que gobolinux n'a aucun intérêt, mais ton exemple ne me paraît pas vraiment pertinent.
-
[^]Re: Plus de sens ?
Posté par farvardin () le 08/01/2008 à 13:38. (lien). Évalué à 6.Si j'adore tout le concept d'Unix et la manière de fonctionner de ces système, je trouve au contraire que la "hérarchie" des fichiers c'est un beau bordel.
Entre les fichiers dans /opt/gnome (comme il fut un temps sous opensuse), les /usr/bin avec tout en vrac dedans, les /usr/local/bin, les /usr/sbin/, les /bin, les /sbin, les /usr/games, les /usr/local/sbin et puis quoi encore, tout cela pour mettre des binaires à la *@*#"*%, sans compter que la doc se trouvera dans /usr/local/doc ou /usr/share/doc, le reste des fichiers dans /usr/share/programme ou /usr/local/share/programme, les bibliothèques dans /usr/lib, dans /usr/local/lib/, dans /lib etc, bref c'est pas super propre. (je sais, sans doute certains d'entre vous vont pouvoir démontrer que c'est très propre au contraire, correctement hiérarchisé selon des principes valables peut-être sur des serveurs mais plus trop maintenant...à
Maintenant si on compare avec MacOSX, tous les programmes vont dans /Applications, mais si on n'a pas accès à ce dossier en installation ou selon ses goûts, on peut ranger les dossiers des programmes où on veut. Chez moi j'ai mis les utilitaires réseaux dans /Applications/Internet, les logiciels systèmes dans /Applications/systeme etc
Honnêtement je trouve le système des paquets sous linux excellent, même plus pratiques que télécharger des logiciels individuels, mais il faut reconnaître les avantages des deux :
- j'ai planté le disque dur de mon ibook, j'ai pu faire une sauvegarde du dossier d'applications avant, une fois le nouveau disque réinstallé, j'ai juste eu à copier la sauvegarde dans /Applications ainsi que mon dossier "libraries" pour tout avoir de refonctionnel comme avant (même pas eu besoin d'être connecté à internet).
- j'ai planté un disque ayant Linux Debian, là aussi j'ai pu tout sauvegarder avant (fichiers de conf et perso), j'ai récupéré la liste de mes paquets avec dpkg --get-selections , j'ai pu tout réinstaller à l'identique ensuite (mais il a fallu une connexion internet)
Un système de gestion centralisé de paquets, mais ayant tous l'ensemble des fichiers nécessaire à faire fonctionner ces paquets, et permettant de les déplacer comme sous osx, cela serait vraiment bien.
Quand au surcoût de place, je doute qu'il soit si important. Sans doute qu'il serait possible d'avoir des briques de base commune (surtout si le système est centralisé comme Linux), genre gtk, qt, libc etc, et tout les trucs un peu exotiques et un peu pénible à gérer, pas trop utilisés par ailleurs (genre mod:perl:libfinance:timezone), cela pourrait se retrouver dans le "pack".
Non vraiment les /usr/share/X11/lib/bin/locale/doc j'en peux plus...
Pour GoboLinux, je trouve que c'est une bonne initiative, même si ce n'est pas encore suffisant. Mais c'est déjà un pas dans le bon sens. Tout comme la norme de freedesktop concernant less fichiers de configuration dans le .config de l'utilisateur au lieu d'avoir tout en vrac dans son dossier perso.--
If you can't use GNU/Debian GNU/Linux, you shouldn't be using GNU/Linux at GNU/all.-
[^]Re: Plus de sens ?
Posté par ercete () le 08/01/2008 à 14:15. (lien). Évalué à 2."Pour GoboLinux, je trouve que c'est une bonne initiative, même si ce n'est pas encore suffisant. Mais c'est déjà un pas dans le bon sens. Tout comme la norme de freedesktop concernant less fichiers de configuration dans le .config de l'utilisateur au lieu d'avoir tout en vrac dans son dossier perso."
Quoi ca existe !!
Wahoo ! j'attends ce genre d'initiative depuis que je connais linux.
Vive freedesktop \o/
Bon c'est pas demain la veille que tous les programmes vont migrer de cette façon mais bon, c'est déjà un début.
Heu, je suis HS là ? quoi que on parle d'organisation, ça vaut son pesant de cacahuètes...--
- SIGNER TUE-
[^]Re: Plus de sens ?
Posté par farvardin () le 08/01/2008 à 16:07. (lien). Évalué à 4.compiz, xfce, qcad, rox, openbox, qtdesigner, entre autres, stockent leurs fichiers de configuration dans ~.config
Vivement que les autres s'y mettent !--
If you can't use GNU/Debian GNU/Linux, you shouldn't be using GNU/Linux at GNU/all.
-
-
-
-
-
-
[^]Re: Plus de sens ?
Posté par reno () le 08/01/2008 à 13:53. (lien). Évalué à 4.>En quoi cette hiérarchie à t-elle plus de sens ? Et pour qui ?
Pour tout le monde!
Prend quelqu'un qui ne connait pas Unix ou Windows, montre lui les deux arborescence celle d'un Linux normal et celle de GoboLinux, demande lui laquelle est plus simple, plus intuitive?
La réponse sera celle de GoboLinux.
J'aime bien l'idée de laisser tomber des complications inutiles qui existent juste pour des raisons de compatibilité avec l'existant..
>C'est une philosophie différente d'organisation, d'accord, mais qu'elle ait plus de sens me dépasse.
Bah, c'est juste que tu es tellement habitué a l'arborescence Unix que tu ne vois pas a quelle point elle est ridicule: etc pour la configuration, usr pour les programmes..-
[^]Re: Plus de sens ?
Posté par zul (Jabber id, page perso, ) le 08/01/2008 à 14:56. (lien). Évalué à 5.Sauf que si tout marche, l'utilisateur ne doit pas voir l'arborescence de fichiers. Il veut installer un nouveau logiciel, il va dans son gestionnaire de package, il installe. Les paquets utiles apparaissent dans le menu d'applications. L'utilisateur voit sa petite maison et c'est tout ce qu'il devrait avoir à voir.
Perso, je ne vois pas non plus l'interêt d'un gobolinux a par augmenter d'un niveau d'indirection tous les chemins (vu que les programmes vont chercher dans /lib:/usr/lib:/usr/local/lib:.... les bibliothèques). La hiérarchie semble plus simple au premier abord, sauf que quand on regarde la tonne de simlink tiré dans tous les sens, ca devient bien moins évident. Ca ne résoult même pas (si j'ai bien compris) le problème des multiples versions d'une même librairie partagée). Et si tu te contente de rm -rf ton /applications/firefox, tu 'detruit' toute gestion de dépendance dans ton système de pkg et tu laisse des symlinks dans tous les sens.
Après j'ai peut-être du mal à saisir le concept.-
[^]Re: Plus de sens ?
Posté par reno () le 08/01/2008 à 16:40. (lien). Évalué à 7.>L'utilisateur voit sa petite maison et c'est tout ce qu'il devrait avoir à voir.
1) Tu présuppose que tout marche parfaitement, et quand ce n'est pas le cas?
Ce n'est pas si rare malheureusement, pour se débrouiller il vaut mieux avoir un environnement cohérent, facile a decouvrir.
2) Il y a certains cas ou la ligne de commande est plus utile que l'interface graphique, dans ce cas la il est bien agréable d'avoir une hiérarchie de fichier qui est logique!
> augmenter d'un niveau d'indirection tous les chemins
Moi je vois ça comme une étape vers une organisation plus cohérente, a terme on pourrait evoluer vers une installation directe dans les bon repertoire avec moins de liens..-
[^]Re: Plus de sens ?
Posté par farvardin () le 08/01/2008 à 17:31. (lien). Évalué à 3.je pense aussi que le but est de faire une transition en douceur. Si cela fonctionne et que cela devient populaire, ces liens seront supprimées pour ne plus garder que la nouvelle organisation en dur.
--
If you can't use GNU/Debian GNU/Linux, you shouldn't be using GNU/Linux at GNU/all.
-
-
-
-
[^]Re: Plus de sens ? Installation de plusieurs version de programme
Posté par mirak mirak () le 10/01/2008 à 10:22. (lien). Évalué à 2.l'intérêt majeur est que ça parmet d'installer en parallele plusieurs versions de programmes
de façon très simple, un peu comme une compilation dans /opt/
sous debian tenter de le faire romp la philisophie de l'éparpillement des fichiers.
l'eparpillement des fichiers n'a aucun sens, de nos jours, c'est juste une relique, un héritage du passé.
Ca n'a aucune justification sur le plan technique
« Système de fichiers » : terme inapproprié ici
Attention !
Un « système de fichiers » est quelque chose de bien précis.
Si j'ai bien compris, c'est la hiérarchie de fichiers, qui est spéciale, et non le système de fichiers.
Salutations
-
[^]Re: « Système de fichiers » : terme inapproprié ici
Posté par patrick_g (page perso, ) le 08/01/2008 à 10:15. (lien). Évalué à 3.Très juste.
La news entretient involontairement cette confusion entre la notion de système de fichiers (Ext3 par exemple) et la hierarchie de fichiers (/usr/bin par exemple).
J'ai pas fait assez gaffe.
Bibliothèques partagées ?
Comment ça fonctionne pour les bibliothèques partagées entre plusieurs applications ?
-
[^]Re: Bibliothèques partagées ?
Posté par Philippe Fremy (page perso, ) le 08/01/2008 à 10:32. (lien). Évalué à 4.Des lib partagées entre plusieurs appli, il y en a des centaines, cf "ls /lib /usr/lib" sur ton système.
Elles sont installées dans leur propre repertoire et des liens symboliques sont mis dans /usr/lib vers lesdites librairies.
Ca permet par exemple en un tour de main de passer de la version X à la version Y : juste une mise a jour des liens à faire dans /usr/lib, je suis sur qu'il y a le petit programme qu'il faut pour faire ca bien.
C'est un peu la philosophie de je-sais-plus-quel-outil qui installait un grand jeu de lien symbolique.
Pour ma part, je trouve ca super propre et intuitif : un programme est isolé dans son repertoire, donc on n'a pas la question de savoir si il a installé des saloperies ailleurs.
Le mélange se fait uniquement au niveau système, via le jeu de lien, et pas au niveau du programme lui-même.-
[^]Re: Bibliothèques partagées ?
Posté par hocwp (Jabber id, page perso, ) le 08/01/2008 à 10:49. (lien). Évalué à 2.> C'est un peu la philosophie de je-sais-plus-quel-outil qui installait un grand jeu de lien symbolique.
Stow ? http://www.gnu.org/software/stow/stow.html-
[^]Re: Bibliothèques partagées ?
Posté par Philippe Fremy (page perso, ) le 08/01/2008 à 11:05. (lien). Évalué à 1.Voilà. C'est la logique de stow poussée au niveau système.
Je mets mon programme/ma lib dans un répertoire et j'ajoute un lien / une entrée dans un index / un fichier .desktop dans une location centrale pour donner les infos.
A noter que c'est une logique utilisée dans d'autres situations. C'est comme ça que les plugins eclipse se listent auprès du système, que les .desktop sont gérés, etc.-
[^]Re: Bibliothèques partagées ?
Posté par Sytoka Modon (page perso, ) le 08/01/2008 à 11:38. (lien). Évalué à 5.C'est effectivement la génralisation du /etc/alternatives de debian.
Plutôt que /Program, je mettrais un /pkg
Cela a un défaut aussi, l'arborescence d'UNIX a été faite pour être mise sur des points de montage différents ayant des droits différents...
Les données de type /var/www, elles sont ou ?
Les log, ils se retrouvent ou ? Sous Windows, les programmes écrivent parfois dans leur dossier et c'est TRES pénible.
-
-
-
[^]Re: Bibliothèques partagées ?
Posté par guillaje (page perso, ) le 08/01/2008 à 11:31. (lien). Évalué à 1.Du coup :
Ainsi le programme Firefox réside simplement dans /Programs/Firefox et la suppression de ce répertoire avec un simple rm -rf supprime complètement le programme.
... n'est pas aussi évident qu'il y parait...
Finalement, on n'a plus de fichiers disséminés partout, mais des liens...-
[^]Re: Bibliothèques partagées ?
Posté par Thomas Petazzoni (page perso, ) le 08/01/2008 à 11:37. (lien). Évalué à 1.Exactement. Ma question c'était pas "comment ça marche les bibliothèques partagées", mais "comment ça marche dans le contexte de Gobolinux avec la promesse que faire rm -rf /Programs/MonProgramme/" efface le programme, sans laisser de saletés derrière.
-
[^]Re: Bibliothèques partagées ?
Posté par patrick_g (page perso, ) le 08/01/2008 à 11:40. (lien). Évalué à 5.Mais l'outil RemoveProgram s'en occupe : http://gobo.kundor.org/wiki/RemoveProgram
-
[^]Re: Bibliothèques partagées ?
Posté par JoeltheLion (page perso, ) le 08/01/2008 à 12:00. (lien). Évalué à 9.A ce compte là, le gestionnaire de package de n'importe quelle distrib' s'en charge aussi... Je peine un peu à saisir l'intérêt de la chose.
-
-
-
module noyau masquant
y a t il un module noyau servant à masquer complètement l' arborescence réelle de gobolinux ? (ou un autre système, je pense à celui ci car une autre distro ayant fait le même choix de "pleins de liens partout" avait ce truc permettant d' avoir une bonne visibilité sur l' arborescence mise en valeur, en masquant la partie "compatibilité" assurée par qq centaines de liens symboliques).
-
[^]Re: module noyau masquant
Posté par patrick_g (page perso, ) le 08/01/2008 à 11:36. (lien). Évalué à 4.Y'a GoboHide qui cache l'arborescence réelle : http://www.gobolinux.org/index.php?page=doc/articles/gobohid(...)
-
[^]Re: module noyau masquant
Posté par FRLinux (page perso, ) le 08/01/2008 à 12:06. (lien). Évalué à 3.Tiens ca a quelque chose d'un rootkit, mais bon ici il cache les fichiers pour ton bien :)
=>[] Je vois la lumiere!
-
[^]Re: module noyau masquant
-
[^]Re: module noyau masquant
Posté par imalip (page perso, ) le 08/01/2008 à 15:47. (lien). Évalué à 3.Il me semble qu'en théorie le Hurd permettrait de faire ca en jouant avec les translators. Le contenu de chaque paquet est a un endroit propre avec son arborescence, et le reste du systeme voit le contenu de tous les packages dans l'arborescence classique.
Je suppose que ce serait également possible avec unionfs ou fuse (?).--
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal-
[^]Re: module noyau masquant
Posté par benja () le 08/01/2008 à 18:34. (lien). Évalué à 5.Plan9 fait cela depuis +15 ans... En gros, le $PATH n'existe pas. Il n'y a qu'une arborescence pour les binaire, /bin. Les librairies restent dans /$objtype/lib, le loader les trouvera tout seul. Les scripts de demarrage s'occupent de monter en union les bon répertoires aux bon endroits, par exemple /$cputype/bin sur /bin. Idem pour les scripts de connexion, un utilisateur peut personnaliser son système en ajoutant des "union-mount" à son ".profile". Cf. http://www.cs.bell-labs.com/magic/man2html/1/0intro
Cela est très pratique quand on a un serveur de fichiers avec le système installé et que l'on se connecte depuis des terminaux "diskless" qui ne sont pas toujours de la même architecture. Tout fonctionne de manière transparente et sans gros hack (comme peuvent l'être le ld_preload et autres joyeusetés).
Il devrait être possible de faire pareil avec un gestionnaire de paquets modifié et une bonne dose voodoo d'union-mounts*. Cela aurait pas mal d'avantages, comme restreindre les paquets disponibles par rapport à un utilisateur. Maintenant, je ne sais pas quelle mesure cela est réalisable: j'imagine qu'avoir 8000 répertoires - un par paquet - attachés à son namespace entraînerait une certaine pénalité au regard des performances d'accès au système de fichiers.
*: cf. les shared subtrees, private namespace et autres joyeusetés qui nécessitent un linux pas trop vieux.
-
-
[^]Re: module noyau masquant
Posté par mirak mirak () le 10/01/2008 à 10:29. (lien). Évalué à 1.gobohide masque l'arborescence virtuelle en fait
-
Fausse bonne idée
Avec la FHS http://www.pathname.com/fhs/ si on veut tout mettre dans un répertoire pour essayer, on utilise /opt , c'est fait pour ça.
On retrouve avec GoboLinux dans les inconvénients de Microsoft. Cette simplification est un leurre, surtout du point de vue sécurité.
L'intérêt de la FHS est de regrouper tous les fichiers de configuration dans /etc, tous les programmes dans /usr/bin, les bibliothèques dans /lib et /usr/lib, les icônes dans /usr/share/icons, etc.
Ce la permet de gérer les droits des utilisateurs et de monter en lecture seule des arborescences qui n'ont pas à être modifiées. On peut ainsi mettre /usr sur un CD-ROM et être tranquille car personne ne pourra en modifier le contenu.
Je trouve aussi qu'il est très commode de sauver /etc pour sauvegarder toutes mes configurations.
En conclusion, GoboLinux met en avant une fausse bonne idée.
-
[^]Re: Fausse bonne idée
Posté par Benjamin Poulain (page perso, ) le 08/01/2008 à 13:29. (lien). Évalué à 3.Ta remarque sur /usr est bonne, on peut monter le système en lecture seule.
D'un autre coté pour la sécurité, je suis pas convaincu qu'il soit moins intéressant de séparer le contenu par logiciel. Pour configurer SELinux ou AppArmor, on aurait moins de références un peu partout.--
Visitez Linux Certif, le site qu'il est bien pour les Linuxiens. (Passez voir aussi OpenYourCode pour les développeurs)-
[^]Re: Fausse bonne idée
Posté par PsychoFox () le 08/01/2008 à 15:28. (lien). Évalué à 5.oui mais ce qu'il explique plus haut, c'est que si ça t'intéresse de mettre toutes tes applis au bon endroit /opt existe déja pour cela.
A vrai dire rien n'empêche d'organiser sa hierarchie comme on veut sur une distrib classique, ça impose seulement de ne plus utiliser son gestionnaire de paquet pour installer n'importe quelle appli, mais le faire à la mano ou d'utiliser un système comme zeroinstall.
Plutôt que de renier la hierarchie unix et de la cacher (alors qu'au final c'est bourré de symlink derrière) comme le fait gobolinux, je trouverai plus intelligent de faire comme les BSD qui séparent lle système de base et les applis installées par les utilisateurs via les ports/packages et qui se retrouvent dans /usr/local (avec les fichiers de conf dans /usr/local/etc).
Parce que sinon quite à tout révolutionner, autant faire un nouvel OS qui n'a rien à voir avec linux ou un unix ou contribuer à Haïku ou syllabe. Gobolinux ça fait surtout bricolage.-
[^]Re: Fausse bonne idée
Posté par mirak mirak () le 10/01/2008 à 10:34. (lien). Évalué à 0.je pene que gogolinux est une bonne idée, car elle part au moins dans l'idée de faire table rase des archaismes, et héritages techniques inutiles.
On à la chance d'avoir un systeme totalement ouvert dont on a toutes les sources, et maléable à souhait et on en profite pas pour l'améliorer.
Je suis d'accord avec toi cependant pour l'idée de séparer système de base et application utilisateur.
Selon moi le cycle de vie des distribs comme ubuntu devrait être ainsi : les mises à jours de packages d'applis utilisateurs se font en continue selon le cycle de vie de chaque application, et les mises à jours majeures du système de base se font selon leur rythme, par exemple tous les 6 mois ou une fois par an c'est suffisant
-
-
-
[^]Re: Fausse bonne idée
Posté par bubar () le 08/01/2008 à 15:43. (lien). Évalué à 2.La description ci-dessus n' enlève pas le fait indéniable que c' est un beau bordel, souvent. (les libexec /usr/lib / usr/share/lib /usr/games etc etc etc) Chaque distribution partant de l' arbo stricte rajoute sa sauce et on finit toujours pas un beau bordel :)
Perso je serais plus pour du :
"Retour à une arborescence STRICTE" plutot que "départ vers du gobolinux"
Et utilisation 'massive' de /opt pour les progr privateurs ou les progs chiants (qui a dit firefox ?). Mais aussi /opt pour les jeux, non ?
j' en ai marre de voir Skype dans /usr/bin !!! Skype dans /opt bordel de m**** :)) C' est moins sale (bon okok le mieux c' est de n' avoir aucun prog de ce type...)
en fait d' une manière plus global, le système pour les progs pris en charge par le distributeur (sauf exception prog. privateur, ça arrive...) et sa communauté, et /opt pour tout le reste.
J' irai pas jusqu' à dire, comme toi, Pierre, que GoboLinux fait fausse route avec une fausse bonne idée, seulement que GoboLinux est bordel de plus ;)
/mode_user_qui_(tente_de)_penser-
[^]Re: Fausse bonne idée
-
-
[^]Re: Fausse bonne idée
Posté par Matthieu Moy (page perso, ) le 08/01/2008 à 16:25. (lien). Évalué à 1.> Ce la permet de gérer les droits des utilisateurs et de monter en lecture seule des arborescences qui n'ont pas à être modifiées.
Je ne comprends pas le rapport avec le FHS justement.
Qu'est-ce que ça change que /usr/share/, /usr/lib/ et /usr/bin soient dans des répertoires distincts ?
A une époque où les disques étaient très chers, y'avait des histoires de mettre les trucs dépendants de l'architecture sur une partition, et les autres sur une autre partition qui du coup pouvait être un NFS partagé avec des machines d'architectures différentes. Je ne sais pas si ça a vraiment été utile un jour, mais franchement aujourd'hui, le mec qui met /usr/share en NFS, et pas /usr/lib/, je demande à voir.
Au final, y'a deux catégories de fichiers : ceux qu'on a besoin de modifier, et les autres. Pour la gestion des droits, on aurait besoin de deux répertoires, genre Applications/ et Data/, et on pourrait très bien dire qu'une applie X s'installe dans Applications/X/ et trouve ses données (configuration entre autre) dans Data/X/.
Pour l'instant, j'ai ça sur ma machine :
/usr$ ls
bin/ games/ include/ info/ lib/ lib64/ local/ man/ sbin/ share/ src/ X11R6/
Et une application peut éparpiller ses données dedans. En bref, le classement est du style $type_de_fichier/$application, et je vois pas trop l'intérêt par rapport à $application/$type_de_fichier.-
[^]Re: Fausse bonne idée
Posté par Pierre Jarillon (page perso, ) le 08/01/2008 à 22:58. (lien). Évalué à 4.Et une application peut éparpiller ses données dedans.
Les packages avec urpmi et apt-get sont chargés d'installer et d'enlever proprement les programmes et de les configurer.
Il suffit de regarder leur contenu par exemple avec urpmf --files paquet.rpm pour savoir tout ce qu'ils installent.
Donc on a le choix :
1- tout au même endroit : des tar.gz faciles à installer et à enlever, mais des liens partout et droits difficiles à gérer.
2- des paquets faciles à installer et à enlever et une architecture dont la sécurité est simple à gérer avec par exemple msec.-
[^]Re: Fausse bonne idée
Posté par Philippe Fremy (page perso, ) le 09/01/2008 à 09:35. (lien). Évalué à 1.Je sais pas d"où tu sors les problèmes de sécurité. Il est au contraire très facile de gérer la sécurité programme par programme, ou groupe de programme par groupe de programme avec une architecture Gobolinux.
Tu tous-entends aussi que tout serait simple sous une distribution normale à condition d'utiliser le gestionnaire de paquet. Dans la pratique, entre /bin, /usr/bin, /usr/lib, /usr/local/lib, /opt, on est loin d'avoir un système propre.
Mon expérience est que le gestionnaire de paquet se casse régulièrement les dents. Et si tu as le malheur de vouloir gérer un ou deux programme toi-même, ça devient vite ingérable.-
[^]Re: Fausse bonne idée
Posté par zul (Jabber id, page perso, ) le 09/01/2008 à 09:53. (lien). Évalué à 5.Mauvais système, changer système.
Les systèmes que j'utilise ont une hierarchie claire (et Unix)
/bin et /sbin sont là pour le système. Il s'agit du minimum vital pour booter le système, l'initiliaser (vu que /usr peut-être sur une partition différente).
/usr/bin et /usr/sbin appartiennent aussi au système. C'est le reste des outils nécessaires à la configuration du système en tant que telle
/usr/local/bin et /usr/local/sbin sont les logiciels que j'installe "à la main", en tant qu'administrateur. Il est globalement vide parce que c'est mal de pas utiliser son système de package.
/usr/pkg/bin et /usr/pkg/sbin c'est là où sont installés tous les logiciels tiers installés par pkgsrc.
/opt n'a jamais existé sur mes machines et c'est probablement une hérésie, je te l'accorde.
Si je veux savoir quel fichier appartient à quel package, j'utilise mon gestionnaire de package. Tout ça est très ordonné et hiérarchisé. Je ne vois pas ce qui est complexe, voir même la partie ou il est dur de gerer plusieurs programmes à la main (l'installer dans /usr/local et mettre /usr/local/{bin,sbin} dans le $PATH à la main ?
-
-
-
-
[^]Re: Fausse bonne idée
Posté par mirak mirak () le 10/01/2008 à 10:42. (lien). Évalué à 1./etc et une partie de /var est vraiment la seul chose bonne et utile dans la FHS sur le plan de la sauvegarde, et encore !! quand je dois migrer ou réinstaller je réutilise jamais /etc tel quel, c'est impossible, j'en fais une sauvegarde ailleurs, et je rapatrie ce dont j'ai besoin. Donc avec gobolinux ce probleme serait réglé en fesant un repertoire config qui repertorie par lien symbolique les dossiers et fichiers de config, et un cp -r de ce dossier permettra de sauver toutes les configs
le reste le découpage /usr/bin /usr/share, /usr/share/pixmaps etcetera est une hérésie
/opt est juste une nécéssitée obligatoire, parceque les programmes binaires et proprios ne pouvaient pas s'accomoder des multiples variations de hiérachie entre les distributions, probleme que gobolinux résoud en partie en fesant que une appli dans son propre dossier est la norme-
[^]Re: Fausse bonne idée
Posté par imalip (page perso, ) le 10/01/2008 à 17:10. (lien). Évalué à 4.C'est vrai quoi, j'ai seulement 450 packages de lib installés sur ma machine. On gere ca comment pour trouver celle dont on a besoin ? Le loader se ballaie toute l'arborescence (j'ai 1271 packages) ? On hardcode le chemin ? Et si on a plusieurs versions de la meme, comment on sait laquelle utiliser ? La premiere qui passe ?
Et on gere comment l'acces aux manpages ? aux icones de mimetypes ajoutés par certaines applis ? J'ai aussi 371 packages qui ajoutent des applis dans /usr/bin. Si je veux executer la commande de l'un d'eux, il faut que je me paye l'arbo complet ou mettre ce dont j'ai besoin dans le PATH ?--
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal
-
-
[^]Re: Fausse bonne idée
Posté par fmaz fmaz () le 10/01/2008 à 13:01. (lien). Évalué à 0.Ce n'est pas parce que le système ne permet pas d'interdire vraiment l'accès en écriture à des sous répertoires que cette approche est mauvaise.
À coup de SE-Linux, on doit pouvoir s'arranger pour que le programme foo de puisse écrire que dans
/program/foo
voir dans
/program/foo/config-
[^]Re: Fausse bonne idée
Posté par mirak mirak () le 10/01/2008 à 15:42. (lien). Évalué à 1.l'argument que je trouve tout de même falacieux c'est quand même de pretexter que Linux c'est pas Windows pour rejeter cette idée ^^
c'est tout de même une évidence que si on devait penser une hierarchie depuis le début, ça viendrait à personne de pondre un truc comme la FHS Linux, et ça serait même ridiculisé ^^
l'idée de vouloir avoir un système minimal qui boutera toujours peut tenir la route, mais seulement si on imagine qu'il puisse se produire un truc grave au niveau du disque dur, mais même là tout le systeme serait imbootable.
J'ai bien fait la connerie d'extraire un initrd de noyau powerpc en me trompant de commande cpio dans mon / de x86.
Le systeme était totalement inutilisable, et le systeme m'a jamais prévenu que je fesais une connerie énorme.
Si j'avais pas été en root à cette occasion ça ne serait pas arrivé, mais bon voilà c'est arrivé ^^-
[^]Re: Fausse bonne idée
Posté par zul (Jabber id, page perso, ) le 10/01/2008 à 17:16. (lien). Évalué à 4.Je pense au contraire que la hiérarchie de système unix correspond à des choix réfléchis et intelligent.
La distinction entre bin et sbin est importante. sbin devrait contenir des utilitaires permettant la configuration du système. Le fait que tous ces utilitaires restent dans sbin permet de restreindre facilement qui a le droit de les utiliser (en utilisant simplement les acl de base unix, pas un truc over complexe à configurer genre SeLinux). A noter que seul les fichiers dans bin et sbin devraient avoir le bit +x.
Les répertoires lib et include sont a mon avis important si on ne veut pas se taper 50 000 répertoires en dépendances (ou alors the great union hack).
La distinction est assez clair entre / /usr /usr/local ... Elles representent chacune des sources distinctes de provenance ou d'utilisation des fichiers (typiquement single user, multi user (system), systeme de package).
/usr/games existe parce que tout le monde n'a pas le droit de jouer :). Il faut être un copain de root pour le faire. Ca serait assez pénible de modifier les droits fichier par fichier plutot que de changer globalement les droits du répertoire /usr/games (et /usr/local/games).
share, libdata et libexec ont une importance un peu moins forte et pourrait peut-être être simplifié.
Globalement, la hiérarchie de fichier est pensé pour être facilement sécurisé, en mettant en place des politiques globales et simples à mettre en place (par rapport à des choses très fines et un peu overkill dans ce cas comme SeLinux, Mac sous FreeBSD, ....).
A propos du rm -rf. Je n'y crois absolument pas. Ca laisse le système de lien completement en vrac et ca casse tout le système de dépendance. C'est la meilleur façon de créer des problèmes (le seul cas ou ca serait possible, c'est dêtre sur à 100% qu'il n'y ait aucune dépendance). En plus, les rm -rf en root, j'evite :). Enfin c'est assez facile de pas supprimer le bon truc :)
Il est possible que de nombreuses distributions prennnent leur aise avec la FHS, elles n'ont qu'a être strictes envers ce FHS.
Evidemment, ces remarques s'entendent majoritairement pour une utilisation multi utilisateur. Pour une utilisation mono utilisateur ou l'utilisateur peut tout faire, les deux architectures n'ont qu'assez peu d'importance.
Notons au passage qu'une de vos critiques du FHS c'est de retrouver nos fichiers. Il est vrai qu'il est facile de deviner que ping est caché dans Netkit ou que ls va se trouver cacher dans CoreUtils ...-
[^]Re: Fausse bonne idée
Posté par Pierre Jarillon (page perso, ) le 11/01/2008 à 00:50. (lien). Évalué à 4.la hiérarchie de système unix correspond à des choix réfléchis et intelligents
Je le pense aussi. Je crois que le problème vient de personnes qui n'ont pas compris les raisons de cette hiérarchie. Sans doute est-ce parce que c'est mal expliqué ?-
[^]Re: Fausse bonne idée
Posté par mirak mirak () le 11/01/2008 à 01:12. (lien). Évalué à 0.la hierachie linux est basé sur des choix réfléchis et intelligents pour l'époque, c'est à dire il y a plus de 15 ans, où on se batait pour 3 kilos octets de ram et de disque dur.
l'argument du rm -fr n'en est pas à un, c'est pas un argument, c'est juste un exemple pour démontrer la simplicité
en ce qui concerne les droits d'éxécution je vois pas ce que ça change
et je met au défis qqun de remetre tous les droits bien comme il faut après avoir fait un chmod -R 777 / :p-
[^]Re: Fausse bonne idée
Posté par zul (Jabber id, page perso, ) le 11/01/2008 à 13:00. (lien). Évalué à 4.Je suis fatigué des gens qui répondent sans lire les commentaires.
Je ne vois pas le rapport entre ce que j'ai dit et la taille des disques durs ...
rm -rf démontre surtout de la facilité de détruire la cohérence du système de gestion de package. Si on a ecrit des systèmes de gestion de package, c'est qu'il y'a des problèmes autrement plus compliqués que de simplement supprimer les packages (oui on devrait supprimer le principe de dépendance et faire des gros statiques partout, on a de la place aussi ... \o/).
Si tu es un administrateur du dimanche qui fait n'importe quoi avec ton système, le système ne peut pas t'aider. C'est hautement débile de faire un chmod -R 777 /. Déja que chmod -R 777 n'importe quoi c'est hautement stupide en général, sur la racine, on atteint des sommets.
A la main, c'est probablement difficile à réparer, probablement pas impossible en reprenant les régles de bases ci-dessus pour tout ce qui est système. Une solution envisageable est d'utiliser mtree(8) pour générer une spécification du système à un temps t et de vérifier à t+1 que c'est la même ( et de corriger sinon). (mtree est un utilitaire qui génère le hash des différents fichiers, stocke leur attributs et cie, des choses qui ne doivent normalement pas bougé sauf si intervention de l'administrateur, plus ou moins intelligente (ca permet entre autre de "vérifier" basiquement l'intégrité d'un système).
En quoi GoboLinux améliorerait l'efficacité de l'administrateur dans ce cadre ?-
[^]Re: Fausse bonne idée
Posté par mirak mirak () le 11/01/2008 à 14:34. (lien). Évalué à 0.>Je suis fatigué des gens qui répondent sans lire les commentaires.
>Je ne vois pas le rapport entre ce que j'ai dit et la taille des disques durs ...
>rm -rf démontre surtout de la facilité de détruire la cohérence du système de gestion de package. Si on a ecrit des systèmes de gestion de package, c'est qu'il y'a des problèmes autrement plus compliqués que de simplement supprimer les packages (oui on devrait supprimer le principe de dépendance et faire des gros statiques partout, on a de la place aussi ... \o/).
benh c'est exactement pour ça que je te fais la remarque sur le rm -fr.
l'exemple du rm -fr sert pas à montrer qu'on peut flinguer le systeme hyper facilement, ou que ça augmente le risque que quelqu'un soit tenté de le faire, ça illustre juste qu'on a plu une hérarchie de fichier éclatée et éparpillée avec une cohérence certe, mais qui ne se justifie plu.
> Si tu es un administrateur du dimanche qui fait n'importe quoi avec ton système, le système ne peut pas t'aider. C'est hautement débile de faire un chmod -R 777 /. Déja que chmod -R 777 n'importe quoi c'est hautement stupide en général, sur la racine, on atteint des sommets.
personne ne parle pas de faire un chmod -R 777 , c'est juste un exemple pour illustrer une situation donnée, tout comme le rm -fr .
C'est là ou je trouve que l'argument de dire que le systeme de package gere tout est pris à l'envers. Il y a plutot un systeme de package parceque la hierarchie est ingérable. ^^
> A la main, c'est probablement difficile à réparer, probablement pas impossible en reprenant les régles de bases ci-dessus pour tout ce qui est système. Une solution envisageable est d'utiliser mtree(8) pour générer une spécification du système à un temps t et de vérifier à t+1 que c'est la même ( et de corriger sinon). (mtree est un utilitaire qui génère le hash des différents fichiers, stocke leur attributs et cie, des choses qui ne doivent normalement pas bougé sauf si intervention de l'administrateur, plus ou moins intelligente (ca permet entre autre de "vérifier" basiquement l'intégrité d'un système).
> En quoi GoboLinux améliorerait l'efficacité de l'administrateur dans ce cadre ?
je dis juste que je suis pas d'accord avec le fait que ça la rende plus compliquée
L'as tu éssayé ?
Je l'ai éssayé en livecd il y a quelques temps, mais sans l'installer. C'est KDE par défaut et je suis plutot Gnome, et ça me botait pas de compiler ^^-
[^]Re: Fausse bonne idée
Posté par imalip (page perso, ) le 11/01/2008 à 15:34. (lien). Évalué à 3.Il y a plutot un systeme de package parceque la hierarchie est ingérable. ^^
Et avec un systeme comme tu le voudrais, il te faudrait un systeme de package pour que chacun déclare qu'il a des binaires, des bibliotheques partagées, des pages d'aides, des icones, des plugins, ou tout ce petit monde est rangé, que tel soft est capable d'ouvrir tel ou tel type de fichier, etc...
Un truc qui ressemble de plus en plus la base de registres de Windows en fait.--
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal
-
-
-
-
-
[^]Re: Fausse bonne idée
Posté par reno () le 11/01/2008 à 13:38. (lien). Évalué à 2.>Je pense au contraire que la hiérarchie de système unix correspond à des choix réfléchis et intelligent.
Ah? Moi, j'ai plutôt l'impression qu'elle a évolué beaucoup de manière assez anarchique avec pour contrainte principale la compatibilité entre les divers Unix et les applications, sans tenir compte d'une quelconque cohérence pour l'utilisateur et que le résultat est assez bordélique..
>sbin devrait contenir des utilitaires permettant la configuration du système.
Bof, pas très intuitif comme nom, tellement que tu est obligé de l'expliquer! Pareil pour /usr, c'est evidemment l'endroit ou on stockes les programmes \o/..
Sinon je suis d'accord avec toi que le 'rm -rf' pour effacer un package n'est pas une bonne idée a cause des librairies en dépendance et ce quelque soit la hierarchie.
>Notons au passage qu'une de vos critiques du FHS c'est de retrouver nos fichiers. Il est vrai qu'il est facile de deviner que ping est caché dans Netkit ou que ls va se trouver cacher dans CoreUtils ...
Très bonne remarque, je me demande si toute hiérarchie n'est pas fondamentalement défectueuse et si on ne devrait pas passer par un système de gestion par "étiquette", au départ je pensais que ce n'était utile que pour gérer les photos, mais par exemple ping serait marqué 'exécutable' et 'package: Netkit' donc dans la vue 'exécutable' tu verrais ping et dans la vue package tu verrais netkit/ping..
En fait avec les divers systèmes de liens, on 'simule' ce comportement mais forcément de manière rudimentaire.-
[^]Re: Fausse bonne idée
Posté par mirak mirak () le 11/01/2008 à 14:45. (lien). Évalué à 1.> Bof, pas très intuitif comme nom, tellement que tu est obligé de l'expliquer! Pareil pour /usr, c'est evidemment l'endroit ou on stockes les programmes \o/..
C'est sur que rien que pour le fait d'avoir des noms de dossier qui tiennent sur plus de 3 lettres c'est déjà ratraper 15 ans de retard.
> Sinon je suis d'accord avec toi que le 'rm -rf' pour effacer un package n'est pas une bonne idée a cause des librairies en dépendance et ce quelque soit la hierarchie.
Certe mais ça simpliferait déjà grandement le packing.
enfin pas le rm -fr mais le fait qu'une application possède sa propre racine :-)
> Très bonne remarque, je me demande si toute hiérarchie n'est pas fondamentalement défectueuse et si on ne devrait pas passer par un système de gestion par "étiquette", au départ je pensais que ce n'était utile que pour gérer les photos, mais par exemple ping serait marqué 'exécutable' et 'package: Netkit' donc dans la vue 'exécutable' tu verrais ping et dans la vue package tu verrais netkit/ping..
> En fait avec les divers systèmes de liens, on 'simule' ce comportement mais forcément de manière rudimentaire.
ça ressemble à ce que microsoft voulait faire avec winfs, j'imagine qu'avec tracker ou certains projets fuse que j'ai vu on pourra avoir ce genre de comportement.
c'est vrai que ça serait pas mal par exemple d'appeller un programme en ligne de commande en posant des questions sémantiques
ptetre un peu lourdingue
en tout cas ça serait bien un moteur de recherche d'application à installer, sur ce procédé.
un peu comme le moteur qui permetait de retrouver des objets ou mots quand on lui pose des questions.
-
[^]Re: Fausse bonne idée
Posté par zul (Jabber id, page perso, ) le 11/01/2008 à 15:48. (lien). Évalué à 3.usr signifie Unix System Ressource (j'admets c'est pas completement evident)
sbin signifie System Binary (qui pour le coup dit bien ce qu'il fait).
Le terme intuitif est un terme très galvaudé (surtout chez les utilisateurs de Windows mais ils semblent que ca atteint aussi les utilisateurs de Linux). Le terme intuitif n'est souvent synonyme que "on a vu ça un milliard de fois donc c'est la norme", ce qui tient plus de l'apprentissage que de l'intuitif. (question HS: l'homme moderne est il encore intuitif d'une quelconque manière ?).
Un système de fichier sur une base relationnelle, c'est intéressant, mais je n'ai pas encore vu d'implémentation convaincantes. Mais en soit c'est une idée intéressante qui permettrait de faire repenser beaucoup de choses.
Sinon, non je n'ai pas testé GoboLinux, je me suis juste posé des questions sur "cette nouveauté" et en quoi techniquement ca apporterait quelquechose. Notons qu'ils ont au moins fait le bon choix niveau desktop (troll inside, vendreci c'est permis).-
[^]Re: Fausse bonne idée
Posté par reno () le 11/01/2008 à 20:05. (lien). Évalué à 2.>usr signifie Unix System Ressource (j'admets c'est pas completement evident)
Je me demande si ce n'est un acronyme qui a été fait 'après coup': certains Unix avaient leur /home dans /usr (users) et depuis que ça a été changé, le sens de /usr a été changé mais bof.
>sbin signifie System Binary (qui pour le coup dit bien ce qu'il fait).
Uniquement quand on sait!
Un truc du genre /System/Binary tout le monde comprend par contre, pas besoin de mode d'emploi..-
[^]Re: Fausse bonne idée
Posté par Pierre Jarillon (page perso, ) le 12/01/2008 à 12:28. (lien). Évalué à 2.Autrefois /etc était un fourre-tout. J'y ai même vu des binaires (HP-UX 1990).
Maintenant ce ne sont que des fichiers de configuration.
La FHS a permis d'assainir l'usage des répertoires. C'est une initiative linuxienne et les Unix qui n'avaient jamais fait cette démarche ont spontanément demandé à y participer.
Le résultat actuel est dans http://proton.pathname.com/fhs/2.2/-
[^]Re: Fausse bonne idée
Posté par mirak mirak () le 12/01/2008 à 17:25. (lien). Évalué à 1.woaw c'est donc plein d'espoir allors :-D
certaines des idées de gobolinux seront peut être reprises un jour
-
-
-
-
-
-
-
Cette page a été générée par Templeet en 0.2517s (dont 0.0426 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.