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 construite une version spécifique adaptée à ses besoins.
![[en]](../images/en.png)
Les nouveautés de la version 014 (271 hits)![[fr]](../images/fr.png)
La présentation de GoboLinux (1303 hits)-
La FAQ (220 hits)
-
Copies d'écran de GoboLinux (1042 hits)
-
Page de téléchargement (181 hits)
-
DLFP (2003) : GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution (342 hits)
> Lire la dépêche (73 commentaires, moyenne: 2,9).
Vous avez demandé le commentaire #894488.
Run by 
Cette page a été générée par Templeet en 0.0906s (dont 0.0073 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
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
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
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
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
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
J' ai zappé le mot de la fin : Longue Vie à GoboLinux :)
[^]Re: Fausse bonne idée
> 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
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
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.
phil.freehackers.org
[^]Re: Fausse bonne idée
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
/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
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
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
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
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
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
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
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
>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
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
>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
> 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
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
>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
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
woaw c'est donc plein d'espoir allors :-D
certaines des idées de gobolinux seront peut être reprises un jour