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. GoboLinux a choisi de repenser les présupposés des systèmes Unix afin de simplifier leur utilisation. Pour cela les développeurs partent de zéro en construisant la distribution selon la méthode de Linux From Scratch et ils redéfinissent radicalement la hiérarchie de fichiers.
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".
Aller plus loin
- Les nouveautés de la version 014 (3 clics)
- La présentation de GoboLinux (15 clics)
- La FAQ (2 clics)
- Copies d'écran de GoboLinux (3 clics)
- Page de téléchargement (11 clics)
- DLFP (2003) : GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution (0 clic)
# étonnant
Posté par H. Guillaume . Évalué à 4.
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 (site web personnel) . Évalué à 1.
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 (site web personnel) . Évalué à 3.
/Applications/programme_name avec toute
l'arboresence dedans?
[^] # Re: étonnant
Posté par Larry Cow . Évalué à 2.
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 (site web personnel) . Évalué à 2.
>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 . Évalué à 2.
Cela dit, ça a pu changer (et j'aimerais autant, à vrai dire).
[^] # Re: étonnant
Posté par patrick_g (site web personnel) . Évalué à 1.
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 F (site web personnel) . Évalué à 1.
[^] # Re: étonnant
Posté par GeneralZod . Évalué à 6.
http://developer.apple.com/documentation/DeveloperTools/Conc(...)
[^] # Re: étonnant
Posté par pikapika . Évalué à 4.
donc il faut croire que ca a rien a voir
[^] # Re: étonnant
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
> 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 . Évalué à 1.
[^] # Re: étonnant
Posté par mirak mirak . Évalué à 2.
# Plus de sens ?
Posté par Anthony Jaguenaud . Évalué à 1.
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 (site web personnel) . Évalué à 3.
[^] # Re: Plus de sens ?
Posté par benja . Évalué à 0.
Peut-on encore appeller cela un unix ?
[^] # Re: Plus de sens ?
Posté par Philippe F (site web personnel) . Évalué à 4.
[^] # Re: Plus de sens ?
Posté par ercete . Évalué à 4.
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 ?
[^] # Re: Plus de sens ?
Posté par Pinaraf . Évalué à 4.
Il a juste à connaître son dossier personnel, qui est accessible par l'icône maison.
[^] # Re: Plus de sens ?
Posté par ercete . Évalué à 3.
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.
[^] # Re: Plus de sens ?
Posté par psychoslave__ (site web personnel) . Évalué à 3.
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 B16F4RV4RD1N . Évalué à 6.
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.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Plus de sens ?
Posté par ercete . Évalué à 2.
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...
[^] # Re: Plus de sens ?
Posté par B16F4RV4RD1N . Évalué à 4.
Vivement que les autres s'y mettent !
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Plus de sens ?
Posté par reno . Évalué à 4.
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 (site web personnel) . Évalué à 5.
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 . Évalué à 7.
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 B16F4RV4RD1N . Évalué à 3.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Plus de sens ? Installation de plusieurs version de programme
Posté par mirak mirak . Évalué à 2.
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
Posté par ttamttam . Évalué à 9.
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 (site web personnel) . Évalué à 3.
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 ?
Posté par Thomas Petazzoni (site web personnel) . Évalué à 2.
[^] # Re: Bibliothèques partagées ?
Posté par Philippe F (site web personnel) . Évalué à 4.
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 (site web personnel) . Évalué à 2.
Stow ? http://www.gnu.org/software/stow/stow.html
[^] # Re: Bibliothèques partagées ?
Posté par Philippe F (site web personnel) . Évalué à 1.
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 (site web personnel) . Évalué à 5.
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 (site web personnel) . Évalué à 1.
... 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 (site web personnel) . Évalué à 1.
[^] # Re: Bibliothèques partagées ?
Posté par patrick_g (site web personnel) . Évalué à 5.
[^] # Re: Bibliothèques partagées ?
Posté par JoeltheLion (site web personnel) . Évalué à 9.
# module noyau masquant
Posté par bubar🦥 (site web personnel) . Évalué à 3.
[^] # Re: module noyau masquant
Posté par patrick_g (site web personnel) . Évalué à 4.
[^] # Re: module noyau masquant
Posté par FRLinux (site web personnel) . Évalué à 3.
=>[] Je vois la lumiere!
[^] # Re: module noyau masquant
Posté par bubar🦥 (site web personnel) . Évalué à 2.
alors c' était bien GoboLinux ;)
[^] # Re: module noyau masquant
Posté par imalip . Évalué à 3.
Je suppose que ce serait également possible avec unionfs ou fuse (?).
[^] # Re: module noyau masquant
Posté par benja . Évalué à 5.
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 . Évalué à 1.
# Fausse bonne idée
Posté par Pierre Jarillon (site web personnel) . Évalué à 8.
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 (site web personnel) . Évalué à 3.
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.
[^] # Re: Fausse bonne idée
Posté par Psychofox (Mastodon) . Évalué à 5.
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 . Évalué à 0.
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🦥 (site web personnel) . Évalué à 2.
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
Posté par bubar🦥 (site web personnel) . Évalué à 2.
[^] # Re: Fausse bonne idée
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
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 (site web personnel) . Évalué à 4.
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 F (site web personnel) . Évalué à 1.
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 (site web personnel) . Évalué à 5.
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 . Évalué à 1.
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 . Évalué à 4.
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 ?
[^] # Re: Fausse bonne idée
Posté par fmaz fmaz . Évalué à 0.
À 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 . Évalué à 1.
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 (site web personnel) . Évalué à 4.
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 (site web personnel) . Évalué à 4.
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 . Évalué à 0.
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 (site web personnel) . Évalué à 4.
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 . Évalué à 0.
>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 . Évalué à 3.
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.
[^] # Re: Fausse bonne idée
Posté par reno . Évalué à 2.
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 . Évalué à 1.
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 (site web personnel) . Évalué à 3.
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 . Évalué à 2.
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 (site web personnel) . Évalué à 2.
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 . Évalué à 1.
certaines des idées de gobolinux seront peut être reprises un jour
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.