Articles précédents : Articles
- [104] DCE, Quartz et Fresco
- [57] Un écran 3D
- [7] GIMPCon 2003 en août à Berlin
- [23] Ouverture de mentors.debian.net
- [20] Xine supporte Sorenson SVQ3
- [121] Les modéros LinuxFR
- [64] La bataille d'Espagne s'intensifie
- [78] EUCD.info : « Moins de copie privée et des mouchards sur les oeuvres »
- [225] Un petit vent d'hiver
- [117] Disponibilité des packs Mandrake 9.1
Articles : GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par Philippe Fremy (page perso, ). Modéré le 13 mai 2003.
L'auteur de GoboLinux nous propose ici une approche nouvelle : réorganiser le système de fichier.
Très souple, le système permet de garder un répertoire par programme installé et miroire tout à coup de liens symboliques vers des emplacements centraux, avec une philosophie qu'on peut retrouver sous MacOs X. Plus besoin de base de donnée des paquets installés, le système de fichier est la base de donnée. Le système peut s'essayer sur une distribution existante. A tester donc.
![[en]](../../../images/en.png)
article sur Kuroshin (1349 hits)-
GoboLinux (2176 hits)
> Lire la dépêche (122 commentaires, moyenne: 2,3).
Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Ça me rappelle le système utilisé par ROX non ?
Bof,
Je n'ai pas compris : - Comment il gérait les dépendances avec ce système. - Comment il savait qu'une bibliothèque n'était plus utilisée. Franchement ca n'apporte aucune solution à ces problèmes mais il a raison de chercher si ca l'amuse :-)
-
[^]Re: Bof,
Posté par doublehp (page perso, ) le 13/05/2003 à 13:39. (lien). Évalué à 15.En bref : tu installe prog qui utilise la LIB1.0, puis prog2 qui as aussi besoin de la lib1.0, prog2 constate que la lib1.0 existe deja, il fait met juste dans son repertoire personel un lien vers elle ... tu installe prog3 qui propose la lib1.1(qui suporte toutes les fonctions de la lib1.0) : a l installe il en informe la lib1.0, et lui propose de se substituer a elle; le prog1 demande juste la lib1.0 ou superieure; tu va dans le repertoire du prog1, et tu met a jour le lien symbolique vers la lib1.1. Le prog2 lui ne veut QUE la lib1.0 refuse la mise a jour. On lui laisse juste pour lui : - le prog1 a profite de l update proposee par le prog3 - le prog2 conserve sa vieille lib1.0 - le jour ou tu met a jour prog2, ou que tu le suprime, le lien de prog2 vers lib1.0 sera suprime(eventuelement remplace par un autre lien vers libb1.2); par definition de tout system de fichier base sur les inodes, quand tu suprime le dernier lien qui pointe vers un inode, tu suprime cet inode: l ancienne version lib1.0 qui n est plus utilisee par personne est suprimee ipso facto. Donc ca gere a la fois les dependances, et la supression des lib inutiles. Des questions ?
-
[^]Re: Bof,
Posté par Landry MINOZA (page perso, ) le 13/05/2003 à 13:43. (lien). Évalué à 1.La, tu implique que tous les progs soient installés sur le même système de fichier (liens hard) c'est quand même un peu réducteur non ? Moi, j'ai l'habitude d'avoir certaines applis dans un /usr/net ou bien qui sont sur un montage nfs et j'utilise les liens hard le moins possible.
-
[^]Re: Bof,
Posté par doublehp (page perso, ) le 13/05/2003 à 14:01. (lien). Évalué à 7.Oui il semble preferable d avoire tout le /programme sur le meme disque physique ( local ou distant ) J'aimerai toute fois parler du problème des PATH : rien n'empeche de conserver un vieux /usr/bin qui contienne une liste de liens symboliques vers les versions courantes des programmes installes, et/ou d implementer un system qui permet que quand un tape "$ xfree", il aille chercher /programs/xfree qui pointe vers /programme/xreee-latest/xfree ... Au lieu d attaquer un system qui a du potentiel, essayez plutot de voire ses bons cotes et d en tirer profit.
-
[^]Re: Bof,
Posté par pa_pitufo_pa () le 13/05/2003 à 22:08. (lien). Évalué à 1.sa bouffe pas de l'espace disque pour rien ?
-
[^]Re: Bof,
Posté par let antibarbie = xp <- xp - 1 (page perso, ) le 13/05/2003 à 22:17. (lien). Évalué à 1.Non justement a cause des liens.
Par contre les liens hard sur des repertoires.... hmmmpf! (quoi ca marche on m'aurait menti ?).
-
[+] [^]Re: Bof,
Posté par LupusMic (page perso, ) le 14/05/2003 à 02:02. (lien). Évalué à -1.Les noms de fichiers, faut les supprimer, ça bouffe de l'espace disque. Rien ne vaut les inodes.
-
[^]Re: Bof,
Posté par MrTout (page perso, ) le 14/05/2003 à 06:36. (lien). Évalué à 2.La table des inodes, ca bouffe de l'espace disque. Rien ne vaut les raw data.
-
-
-
[^]Re: Bof,
Posté par Landry MINOZA (page perso, ) le 14/05/2003 à 08:09. (lien). Évalué à 3.Je suis loin d'attaquer, au contraire, ça me semble interressant, j'essaie de comprendre plus en profondeur les tenants et aboutissants car je travail sur un projet de déploiement sur plusieurs dixaines de machines. Tout ce qui peut simplifier la maintenance d'un tel système est bienvenue, le but est quand même un peu que les techniciens n'aient pas à sortir de leur bureau (presque) pour gérer le système.
Ça me semble prometteur comme approche, j'ai déja un peu tendance à utiliser le même principe lorsque je compile des progs à la main :
cd foo
./configure --prefix=/usr/local/foo
make && make install
ln -s /usr/local/foo/bin/* /usr/local/bin # qui est dans le PATH
ln -s /usr/local/foo/lib/* /usr/local/lib
Ça permet une bonne gestion à la mano, automatiser ça me semble être une bonne chose...-
[^]Re: Bof,
Posté par doublehp (page perso, ) le 14/05/2003 à 13:30. (lien). Évalué à 1.Je suis loin d'attaquer,
Désolé si tu l'as mal pris, mais ma dernière phrase n'était pas tournée contre ton post :/
J'avais besoin de le dire, mais j'ai eu la flemme de le faire dans un commentaire diff'rent.
/me se bat avec des verges.
[-3] -> []
Mais puisque tu as l'air d'aimer la simplicité; je te soumet une idée comme ça:
Y as-t-il moyen de faire dans un cluster un /usr ou un /programmes qui soit en RO sur un server NFS ... comme ca tu met le server NFS a jour, et hop tout est upgradé en même temps ?
NB: le server NFS peut être lui même un élément d'un cluster de clients, juste question d'accélérer les installs ...-
[^]Re: Bof,
Posté par Landry MINOZA (page perso, ) le 14/05/2003 à 14:58. (lien). Évalué à 1.L'idée est en effet interressante, à condition pour un nombre "consistant" de machines que le cluster soit haute dispo, que les disques soient très rapides (imagine 25 users qui lancent kde ou openoffice en même temps ce que ça donne en bande passante ?
Je pense qu'a cause de ces restrictions, c'est une solution économique (sur les plans temps, argent à cause de la place gagnée sur disque..., boulot) pour un réseau relativement restreint (je dirait < 500 machines en tout cas).
Après, je vois plus une archi avecun serveur de déploiement (type cfengine) qui est beaucoup plus souple.
-
-
-
-
-
Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
heu, c'est pas nouveau comme approche... c'est le principe de stow*. j'ai même pas envie d'essayer... * http://www.gnu.org/software/stow/stow.html
Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Ce systeme parait naturel et intéressant, mais le fait de retirer completement le systeme de paquetage n'est pas une bonne chose. D'autant plus qu'il est tout à fait possible de faire la meme chose avec rpm ou dpkg. Il suffirait que chaque paquetage fasse le boulot lui meme, en installant ses fichiers dans /usr/logiciel_machin, puis en faisant les liens symboliques dans les scripts de post-install. Je pense que c'est meme faisable directement sur n'importe quelle distrib. Et son probleme avec les paquets "compat" n'en est pas un, parce qu'on peut très bien installer un paquet glibc3.2 en meme temps qu'un glibc3.1. Il faut juste que les noms de base des paquets soient différents. (quoique le dernier rpm permet maintenant d'installer en meme temps toto-1 et toto-2 s'il n'ya pas de conflit)
-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par Brice Arnould ( un_brice ) (page perso, ) le 13/05/2003 à 14:13. (lien). Évalué à 5.<blockquote> Il faut juste que les noms de base des paquets soient différents. </blockquote> Dans le cas de Gentoo, le problème est géré par un système de "slots" : deux même apps de slots diffèrents sont considérées comme diffèrentes dans certains cas (par example on remplace pas une version par celle venant d'un autre slot lors d'une mise à jour). De plus chacun des packages (qui sont en fait des scripts) a la posiblité de spécifier un masque ou une version relative (comme "<2.4.18") dans ses dépendances. Voilà, j'voulais pas rester le dernier à pas avoir fait de pub pour ma distrib (comment ça elle gère pas les dépendances à la désinstallation? -_^)
--
Respect à RMS.
Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Non ce n'est pas nouveau, faire cela sur *nix date de la fin des années 80 avec NeXTSTEP. un autre hierarchie de type *Step/OSX http://www.linuxstep.org/documentation/LSFH-1.3/LSFH-1.3.txt
-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par Nicolas Roard (page perso, ) le 13/05/2003 à 14:03. (lien). Évalué à 2.Et puis, LinuxSTEP est plus ambiteux à mon avis... ils n'ont pas hésité à tout casser ... :-) Donc ça avance plus doucement. Par contre leur hièrarchie pour le FileSystem est vraiment pas mal fichue, ils y ont passé du temps.
-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par snihf (page perso, ) le 13/05/2003 à 14:07. (lien). Évalué à 2.c'est quoi la difference entre linuxStep et GnuStep ?
-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par Nicolas Roard (page perso, ) le 13/05/2003 à 14:25. (lien). Évalué à 3.LinuxSTEP a pour but de fournir un OS complet, en utilisant un kernel linux et un bureau basé sur GNUstep comme environnement. GNUstep est un framework de programmation (orienté desktop).
-
-
Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
difficulté d'isoler l'installation et surtout la désinstallation d'un programme dans le système, complexité de la gestion de PATH et des bibliothèques, gestion des dépendances. ET Ce sont ces problèmes qui ont conduit au développement des outils tels que rpm, apt-get ou portage = le probléme a déja été réglé. le système permet de garder un répertoire par programme installé le systéme actuel aussi: --prefix=/usr/local/kde (par défaut), je n'ai jamais eu de probléme. Peu de gens utilisent /opt/gnome2 ou /opt/kde, donc est que cette distro répond à une vraie demande des "utilisateur"? Très souple vraie question: le chemin /Programs/Netkit-Base/0.17 ne me plait pas, je veux /programmes/Netkit-Base/017 à la place. Le soi disant "front end user" qui a besoin de s'y retrouver dans sa hiérarchie de fichier parce qu'avant il ne trouvait pas intuitif de trouver et modifier /etc/fstab, ce front end user là il va pouvoir modifier lobo facilement pour obtenir /programmes/Netkit-Base/017? c'est intuitif ces scripts? Ou est ce qu'on a juste remplacer un "espace mental" (kuro5hin tm) par un autre? Est ce que le gain à s'y retrouver dans sa hiérarchie de fichier a été évalué par rapport au gain qu'on a à obtenir de l'aide sur le net quand on a un probléme avec l'ancienne : "bon keskya dans ton /etc/fstab ? fais 'cat /etc/fstab' et ecris moi keskya d'écrit. je vois le probléme fais rm -vf /proc/kcore"
-
[+] [^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par LupusMic (page perso, ) le 13/05/2003 à 21:28. (lien). Évalué à -2.Est ce que le gain à s'y retrouver dans sa hiérarchie de fichier a été évalué par rapport au gain qu'on a à obtenir de l'aide sur le net quand on a un probléme avec l'ancienne
Quoi, tu as un problème avec cette application ? Redémarre la machine. Si ça marche pas, essaie de réinstaller le logiciel. Si ça marche pas, réinstalles Windows.
Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Voilà qui est interressant !! c'est vrai que l'arborescence des *nix n'est évidente pour personne, encore moins pour des non initiés. De plus, cela d'une distribution à l'autre, et on hésite souvent où mettre de nouveaux programmes, ou de nouvelles données ! Par exemple, un répertoire commun à toutes les personnes qui utilisent la machine pour y placer des mp3, ou des videos. Tout le monde va mettre ca à un endroit différent (/home /var /usr /ceketuveux). Il devrait y avoir un emplacement du type /media, /programs, etc. C'est pour cela que je pense que l'arbo *nix est dépassée, et doit être revue. Ce projet semble prométeur, et je le soutiens complètement dans son action. Bravo, il faut oser le changement ! tout le monde s'en portera mieux (sauf les inconditionnels, mais bon.......).
-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par Gentoo][Gravis (page perso, ) le 13/05/2003 à 13:59. (lien). Évalué à 5.J'allais oublier : /etc sert maintenant à regouper tous les fichiers de config (+ les 'init') Pour moi, ca devrait dégager en /conf ou /config et /etc/rc* + /etc/init.d/ devrait aller dans /init ou mieux /boot/init/ Appelons un chat un chat après tout ! /etc porte bien son nom, on met là tout ce qu'on a pas réussi à classer. La fonction est aujourd'hui bien différente, et l'archi doit être revue
-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par imr () le 13/05/2003 à 14:17. (lien). Évalué à 1.Pour reprendre ton exemple : mettons que /media, /programs existent. Qu'est ce qui empechent tes exemples d'utilisateurs du début qui mettaient des videos dans /home /var /usr /ceketuveux de les mettres dans /programs /config /bibliotheques /ceketuveux ???
-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par Annah C. Hue (page perso, ) le 13/05/2003 à 14:28. (lien). Évalué à 2.Il faudra adapter les commandes de gestion de fichiers pour qu'elles prennent en compte ce rangement différent. Ainsi "mv" fera appel à "file" pour déterminer le type de fichier, et si c'est pas un type accepté par le répertoire destination, il refuse "type de fichier incompatible avec le répertoire destination". Reste à savoir si beaucoup de personnes seront intéressées par ce genre de barrières... À la limite je ne suis pas contre ça me forcerait peut-être à ranger mon bord^W $HOME...
-
[^]La marmotte : elle revient, elle n'est pas contente, elle a faim, elle n'est pas végétarienne.
Posté par zyvad () le 13/05/2003 à 15:19. (lien). Évalué à 9.C'est con : avant, déplacer un fichier était une opération relativement rapide et peu coûteuse. Désormais, il faudra créer un processus et charger un binaire qui consulte magic(5) (ou, mieux, son équivelent en XML méta-distribué via CORBA over HTTPv6 sur load-balancer), tout ça pour perdre du temps les 99% du temps où on sait ce qu'on fait[*].
Encore, tu me dirais "je suis sysadmin et je veux faire Ch#@r mes utilisateurs", je comprendrais le concept. Mais là, si tu tiens vraiment à ralentir ta machine tout ça pour avoir le droit de te construire des barrières.... ben... je sais pas si un Unix est très adapté. à la limite, libre à toi d'écrire quelques scripts pour wrapper les commandes de base et te les infliger.
C'est quand même marrant de demander à du logiciel +/- libre de fournir des limites à sa propre utilisation.
[*] ça ressemble à un troll sur le typage fort, mais ce n'est pas un troll sur le typage fort
-
-
-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par malin nicolas () le 13/05/2003 à 14:26. (lien). Évalué à 6.ln -s /etc /config Voilà tu la ton répertoire config :o=)
-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par jmfayard () le 13/05/2003 à 17:57. (lien). Évalué à 4.Appelons un chat un chat après tout ! /etc porte bien son nom, on met là tout ce qu'on a pas réussi à classer.
en fait, non etc veut dire quelquechose comme editing text config,
c'est la config de ton ordinateur, et tu peux l'éditer avec VI-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
-
-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par Jar Jar Binks (page perso, ) le 13/05/2003 à 20:35. (lien). Évalué à 7./etc porte bien son nom, on met là tout ce qu'on a pas réussi à classer. La fonction est aujourd'hui bien différente, et l'archi doit être revue
Et donc tu veux changer le nom pour ça ?
Je te conseille la lecture du FHS, ça pourrait t'ôter quelques escarbilles de l'il. De même pour tous ceux qui pensent que la hiérarchie Unix n'est pas structurée.-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par doublehp (page perso, ) le 14/05/2003 à 13:37. (lien). Évalué à 1.Je dirais pas qu'elle est non structurée, ni mal documentée, ni mal pensée, mais à l'exemple de l'IPV4, je pense que la hiérarchie est vieille, et qu'un petit lifting lui ferait le plus grand bien. Je ne dénigre pas le FHS que je ne connais que de nom, mais quel que soit le bien que tu pense du FHS, d'autre projets comme GoboLinux ne peuvent qu'aporter des idées neuves dans le cadre d'uin renouveau à longtermes :
même si GoboLinux ne reste à jamais utilisé que par ses developeurs, plus on le fait avancer, plus ça donnera d'idées à ses sucesseurs: les noyeaux Linux, *BSD, mach et L4 sont autant de projets qui s'enrichissent mutuellement, tout comme KDE et Gnome, idem pour XFree et son fork ( enfin j'éspère ) [je passe sur les FS que je trouve toujours très proches entre eux] ... pourquoi pas la même pour les hiérarchies ?
-
-
-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par ccomb (Jabber id, page perso, ) le 13/05/2003 à 14:05. (lien). Évalué à 4.Tant qu'à oser le changement, autant l'oser complètement, et aussi remplacer linux par le Hurd, remplacer X par Fresco. Le changement est bon quand il est proposé sur des produits complètements différents. Tant qu'on reste dans GNU/Linux, autant en profiter pour respecter un minimum de cohérences, de standards et d'unité. Quand on en sera à GNU/Hurd/L4/Fresco, ce sera intéressant de proposer une arborescence différente d'Unix (puisque "GNU n'est pas Unix").
-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par doublehp (page perso, ) le 13/05/2003 à 14:17. (lien). Évalué à 0.<Trolle detector> BIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIP BIIIIIIIIIIIIIIIIIIIIIIIP BIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIP </Troll detector>
-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par reno () le 13/05/2003 à 20:29. (lien). Évalué à 1.Pas d'accord avec toi: la raison pour laquelle, on n'utilise pas Hurd/L4/Fresco est technique: ils ne sont pas prèts.
Tant qu'ils ne seront pas meilleurs que l'existant, on n'a aucune raison de changer.
Une nouvelle hiérarchie de fichier comme sous MacOSX, n'est pas un problème technique, c'est un problème humain!
L'intérét d'une organisation standard pour le système de fichier est qu'elle est standard justement, a cause des guéguerres entre les différents Unix commerciaux, le système de fichier standard n'a pas évolué et on se retrouve avec des abérrations du style /etc au lieu de /conf.
La "guerre" entre les distributions Linux empècherait probablement d'avoir une nouvelle hiérarchie standard:
- faut-il traduire les noms? (avis perso: non)
- User ou Users ou user ou users ? (avis perso: user)
- VideoFiles, "Video Files", video_files (avis perso: video_files)
etc...
On n'est même pas fichu d'avoir un seul système de packaging pour les divers Linux + BSD, ou un seul type de script de démarrage, alors avoir un nouveau système de fichier commun..-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par Christophe Lucas (page perso, ) le 14/05/2003 à 08:22. (lien). Évalué à 1.>L'intérét d'une organisation standard pour le système de fichier est qu'elle est >standard justement, a cause des guéguerres entre les différents Unix >commerciaux, le système de fichier standard n'a pas évolué et on se retrouve >avec des abérrations du style /etc au lieu de /conf.
Pourquoi croyez vous que ca soit standard ??
Surement pour une uniformisation des *nix, mais aussi pour les humains ne pas se perdre dans les différents FHS si on laissait libre cours à différents FHS.
/etc == "editing text config" !!
Si c'est juste pour que "etc" soit renommé "conf" parce que cela sonne mieux aux oreilles de certains => aucun intérêt et perte de temps !
C'est déjà bien on n'a "que deux"(à qq choses prêts) familles d'Unix (sysV et BSD), changer son petit nom à un répertoire car son nom ne sonne pas bien serait relancer des débats et forké d'autres FHS, d'où de nouvelles mouvances et une perte de standard.--
- Christophe -
-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par doublehp (page perso, ) le 14/05/2003 à 13:47. (lien). Évalué à 1.Le fait que l'on soit incapables d'avoir un system de boot-script commun est peut justement du au fait que l'on utilise la hiérarchie différement ... /etc est tellement floue que chacun y fait sa sauce ... même entre les distribes c'est la guerre : un jour /etc/init.d, un jour /etc/rc.d/ini.d, puis /etc/rc/init ... (je ne dénonce personne !)
Il faut peut être voire une hiérarchie commune comme un premier pas vers la standardisation que tu réclame ... peut être :?
Enfin quand je vois que dans une même débian, je me perds entre kde2 et kde3 qui sont organiées très differement, que la conf user de kdm et xdm sont ... je dirai ... rien a voire ... ( kdm dans /etc/kde, xdm dans /etx/X11 ... ) alors bon ... je suis très philosophe, et je prends mon mal en patience en attendant de jours meilleurs :(
-
-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par Pascal EISELE (page perso, ) le 14/05/2003 à 07:20. (lien). Évalué à 4.D'ailleur a mon avis ca serait la seule vrai solution pour qu'on s'interesse à Hurd/Fresco et autre. C'est qu'ensemble ils forment un nouveau système qui offre quelque chose de différent.
D'ailleur on pourrait très bien imaginer :
Hurd/Fresco & Cie pour le desktop
Linux pour les serveurs
Biensur il y aura toujours des gens pour utiliser l'un à la place de l'autre et vis et versa mais ca serait interessé et peu perturbant pour les EndUsers-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par doublehp (page perso, ) le 14/05/2003 à 13:48. (lien). Évalué à 1.Pourquoi pas BSD sur les servers ?
-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par Silence (page perso, ) le 14/05/2003 à 14:45. (lien). Évalué à 1.<et hop, allons y gaiment>
Peu etre parce que IBM ne remplace pas toute sa salle de machine par un serveur BSD... Relis tes mail, c'etait un Linux ;^)
<raaah, c'est trop facile>--
^d^c
-
-
-
Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
j'ai un fichier de 61 Mo dans /proc, c'est normal ?
-
[+] [^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par NebuchadnezzaR () le 13/05/2003 à 14:07. (lien). Évalué à -1.nan faut le supprimer, c'est un core dump ça sert pas :-)
-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par ccomb (Jabber id, page perso, ) le 13/05/2003 à 14:09. (lien). Évalué à 2.oui et il faut supprimer /dev/mem aussi, c'est énorme et ça sert à rien. Mouhouhaharrff
-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par Jonathan ILIAS (Jabber id, page perso, ) le 14/05/2003 à 06:16. (lien). Évalué à 1.nan, le supprimer (rm) ne suffit pas, il faut d'abord l'effacer :
dd if=/dev/zero of=/dev/mem bs=1
-
-
-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par Pat Le Nain (Jabber id, page perso, ) le 13/05/2003 à 14:09. (lien). Évalué à 1.nan, efface ;)
--
Demat le bouchot !
Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
C'est en gros le système proposé depuis des années par DJB : http://cr.yp.to/slashpackage.html Un système qui a d'ailleurs été globalement très mal accepté, car trop en contradictions avec les coutumes d'antan. Le meilleur compromis reste à mon avis le systeme de Gentoo Linux, qui évite d'avoir 36000 répertoires tout en permettant malgré tout de faire joyeusement cohabiter plusieurs versions majeures d'un meme logiciel. Pour l'utilisateur c'est transparent grace à env-update, les dépendances sont correctement gérées, bref que demander de plus ?
-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par Rage () le 13/05/2003 à 15:13. (lien). Évalué à 2.trop de contradictions avec les coutumes d'antan?
Mes alors les geeks nunuxiens seraient en fait des conservateurs? On m'aurait menti à l'insu de mon plein gré?
Moi qui croyait que les logiciels libres étaient un joyeux bazar de créateurs inspirés des universités... n'auraient-ils gardés de la science que ses comportements grégaires et obtus?
Dans la plupart des commentaires de cette news et dans ceux qu'on peut lire sur le site original je suis éffaré du conservatisme des nunuxiens sachant que ce système est concu pour justement s'interfacer en DOUCEUR avec les anciennes habitudes... snif.
Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
C'est déjà dans MultiDeskOS ! oui, je sais -->[]
Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
bofbof de tout renomé comme ça...
Le seul truc chiant est le mélange des repertoires selon l'application. /usr devrait avoir un repertoire par programme /usr/OOo ( en ro ) par exemple et un /var/OOo pour les donnés de l'application (les trucs qui ne sont pas relatifs aux utilisateurs, notament le .conf...). L'installeur ne devant pas avoir besoin d'être root.
-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par Noj Han (Jabber id, page perso, ) le 13/05/2003 à 19:14. (lien). Évalué à 1.L'installeur ne devant pas avoir besoin d'être root.
Alors ça, je trouve que c'est plus que discutable... quel intérêt?-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par free2.org (page perso, ) le 14/05/2003 à 00:59. (lien). Évalué à 1.pour des raisons de sécurité ou pour éviter qu'un soft bousille tout le système...
-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par PLuG () le 14/05/2003 à 07:11. (lien). Évalué à 4.En fait la "bonne pratique" sous unix avant les packages c'etait un truc du genre:
en tant que user normal:
tar xvzf openoffice
./configure --prefix=/usr/local/openoffice
make
en tant que user root:
preparation d'un environnement pour la nouvelle application:
- creation d'un repertoire d'install /usr/local/openoffice
- creation d'un user/group "openoffice" avec home dans /usr/local/openoffice mais sans shell.
- chown openoffice:openoffice /usr/local/openoffice
en tant que "openoffice"
make install
avec ce schema, il est necessaire d'etre root pour installer sur la machine,
ou alors il est necessaire que ROOT prepare l'environnement d'installation,
mais l'install en elle meme est faite par un user dédié a cette application,
et la compilation par un user lambda du systeme.
mais les packages on simplifié tout ca.
-
Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
« Nous connaissons tous l'organisation classique d'une distribution Linux et ses problèmes : difficulté d'isoler l'installation et surtout la désinstallation d'un programme dans le système, complexité de la gestion de PATH et des bibliothèques, gestion des dépendances. Ce sont ces problèmes qui ont conduit au développement des outils tels que rpm, apt-get ou portage. »
La plupart des distributions classiques comportent un système de gestion de paquet.
Le problème est mal posé : les dépendances complexes, les lieux d'installation ont des avantages. Ce n'est pas un problème, c'est pensé pour être ainsi.
Pour simplifier cette gestion - c'est à dire profiter des avantages en supprimant les inconvenient - les outils de gestion de paquets ont été inventé.
L'affaire est close : ces outils existent en apporte quelque chose d'unique. On peut installer des programmes sans même se soucier de savoir quels sont les prerequis.
« philosophie qu'on peut retrouver sous MacOs X »
Mac OS X est invention récente qui signifie pour Apple de tendre vers les *BSD et systèmes libres en général. En quoi Mac OS X correspond à un modèle à suivre ? Parce que des gugusses d'O'Reilly prétendent que Mac OS X et MS Windows sont les SE les plus fabuleux de la terre (cf Interview) ?
Je ne vois pas en quoi la gestion des paquets est mauvaise sous GNU/Linux. Tout est géré. D'autant qu'on parle souvent de 1000 paquets différents ! Une diversité de logiciels qui n'a rien à voir avec ce qu'on trouve sous d'autres SE.
-
[^]Une fois de plus, les votes
Posté par gnap gnap (page perso, ) le 13/05/2003 à 20:37. (lien). Évalué à 0.Merci à ceux qui ont voté moins de faire connaitre leur avis ?
Pas le temps d'argumenter, de participer, mais celui de voter ?-
[^]Re: Une fois de plus, les votes
Posté par Nÿco (Jabber id, page perso, ) le 13/05/2003 à 21:13. (lien). Évalué à 1....laisse tomber, ils ont exprimé leur "pasdaccorisme"...
Ton post est argumenté, no pb !--
Jabber ID : xmpp:Nyco@jabber.fr
-
[^]Re: Une fois de plus, les votes
Posté par William Steve Applegate (page perso, ) le 13/05/2003 à 22:21. (lien). Évalué à 9.Effectivement, je comprends pas non plus, surtout que ton opinion semble être majoritaire dans le coin... Il reste donc l'option « tête qui revient pas » pour expliquer. M'enfin bon, ça m'étonne plus vraiment...
Sinon, je rejoins assez ton avis : perso, je suis loin d'être un fan d'Unix et de ses idiosyncrasies, mais je pense que le système de fichiers n'est pas le truc le plus important à réformer. D'autant plus que l'argument généralement avancé (ça perd le débutant) est ridicule : vous avez déjà vu un Windows 2000 ? Vous avez 'Documents and Settings' qui joue le rôle de /home (avec plusieurs sous-répertoires par utilisateur), 'Program Files' (qui contient un peu tout et n'importe quoi : applis, DLL, fichiers de données, selon le bon vouloir du programmeur du soft), 'Winnt' et ses 'Inf', 'System', 'System32' (?!?), 'etc' (si, si), etc. Plus la base de registres et ses clés absconses. Allez donc y comprendre quelque chose ! À côté, Linux est beaucoup plus clair : un fichier de configuration ? Dans /etc. Un fichier verrou ? Dans /var/run, sûrement. On s'y fait assez vite, et en fin de compte, ce n'est pas gênant du tout. Le seul problème est celui de la désinstallation des applis, et comme on l'a dit, il y a les gestionnaires de paquets (ou ce bon vieux 'make uninstall', fourni par tous les programmeurs consciencieux). Certes, les /etc, /bin et autres /usr auraient gagné à être nommés de manière un peu plus claire, mais c'est secondaire. Alors, quel est le problème ?
Plus haut, un distingué co-posteur fait remarquer que tout ceci ressemble à une attitude assez conservatrice. Je suis d'accord... Néanmoins, il n'y a rien de mal à mes yeux à être conservateur s'il n'y a pas besoin de tout chambouler. Le changement pour le changement, ça n'apporte rien, et ça a tendance à tout casser. D'un autre côté, je ne suis pas contre une réflexion sur le système de fichiers et son organisation dans le cadre d'un effort plus vaste. Entre autres, il me semble (je dis bien « semble ») me souvenir que cette approche « un répertoire par appli » était celle adoptée par BeOS. Et ça ne me pose pas de problème. Néanmoins, un des grands atouts des Unix libres, c'est qu'ils « se tiennent sur les épaules de géants », pour paraphraser un certain physicien. Quel intérêt alors de se couper de tout cet héritage, et des bénéfices qu'il apporte (compatibilité avec l'existant, transfert aisé des connaissances, etc.) ? Bien sûr, l'auteur a prévu une solution (à coups de ln -s), mais un admin débarquant sur GoboLinux n'en sera pas moins paumé. Enfin, j'insiste sur le fait que je pense qu'il y a d'autres priorités (comme avoir un sous-système graphique au goût du jour, unifier/simplifier des pierres d'achoppement comme la configuration des pilotes de périphériques, mieux intégrer les différentes interfaces avec le système sous-jacent, etc.). Bref, chambouler le système de fichiers me semble donc une approche peu naturelle, et pas franchement prometteuse pour ce qui est des bénéfices qu'on pourrait en retirer. Je ne ferai donc pas, pour ma part, l'effort de réapprendre un autre système, à moins qu'il ne m'apporte vraiment quelque chose de plus.
[une petite note quand même : le site de GoboLinux semble avoir quelques problèmes de DNS et j'arrive pas à y accéder, je n'ai pu lire que l'article sur K5, j'ai donc peut-être raté une info importante. Une autre petite note : j'ai lu dans l'article qu'ils avaient aussi changé les scripts d'initialisation. Je ne pense pas non plus que l'init SysV soit une panacée universelle (il manque entre autres un moyen intégré de ne pas exécuter un script si tel ou tel autre a eu un problème). Néanmoins, je n'ai pas trop compris en quoi leur système se démarquait d'autres systèmes alternatifs comme simpleinit. Bref, rien de nouveau sous le Soleil, AMHA]--
Ce message vous a été présenté par les trollomètres de compétition Prumpleffer™-
[^]Re: Une fois de plus, les votes
Posté par Éric (Jabber id, page perso, ) le 14/05/2003 à 01:13. (lien). Évalué à 3.> À côté, Linux est beaucoup plus clair
Bof, si les clés de la base de registre ne sont pas claires, il y a une structure, pareil pour le système de fichier Unix classique. pas sur qu'un /usr/local/share soit plus logique qu'un HKEY_machin_chose.
> un fichier de configuration ? Dans /etc
ouais, enfin dans un des sous répertoires de /etc en général, et ce n'est pas toujours si simple à trouver si on ne connait pas le nom du fichier à l'avance.
ou alors dans un .xxxx du répertoire home
ou alors dans une clé de gconf (ben oui, on a beau critiquer la base de registre c'est un concept pas idiot).
ou alors dans un /usr/kde/version/..... planqué quelque part
> Un fichier verrou ? Dans /var/run
ou /var/tmp ou /tmp ou dans le profile
Bref, c'est organisé et ca marche, à mon avis c'est un truc suffisament fonctionnel pour éviter d'être changé à moins d'être vraiment sur que ca vaille le coup (parce que pendant la transistion il y aura un bordel immonde).
Mais franchement ca n'est pas tout à fait clair. Il n'y a qu'à voir les applications qui sont dans /usr /usr/lesoft /usr/kde/version/... /usr/local /usr/local/lesoft /var (sisi j'en ai vu) /opt/lesoft /bin suivant les cas. Chacun donnera sa vision de ce à quoi correspondent ces répertoires mais il faut avouer que suivant les versions et les distributions des softs équivalents ne se trouvent pas placés au même endroit.
Au contraire de toi je trouve l'archi Win meilleure (meme si _tres_ largement perfectible). Il y a plusieurs répertoires dans le home ? un pour les conf, un pour le menu, un pour les modèles de fichiers, un pour les video un pour la musique, un pour les autres docs ..... on aime ou on aime pas mais c'est cohérent.
Perso j'aurai bien aimé avoir un simple .conf dans mon home, qui contient les répertoires de conf, plutot que plein de .xxxx mélangés avec les autres docs-
[^]Re: Une fois de plus, les votes
Posté par helf (page perso, ) le 14/05/2003 à 06:58. (lien). Évalué à 2.<i>> un fichier de configuration ? Dans /etc
ouais, enfin dans un des sous répertoires de /etc en général, et ce n'est pas toujours si simple à trouver si on ne connait pas le nom du fichier à l'avance.
ou alors dans un .xxxx du répertoire home
ou alors dans une clé de gconf (ben oui, on a beau critiquer la base de registre c'est un concept pas idiot).
ou alors dans un /usr/kde/version/..... planqué quelque part
Ben en fait, si c'est une config système editable en texte c'est dans /etc, si c'est une config perso c'est dans $HOME/.xxx
Après c'est vrai que les environnements graphiques monstres, à mon avis vaut mieux pas toucher à la config en direct même si je le regrette.
L'idée du .conf dans le $HOME est pas mal, mais à mon avis c'est un peu plus compliqué à mettre en oeuvre vu qu'il faut demander à chaque appli de modifier son comportement par defaut.
Question: existe-t-il une option dans les installeurs rpm/apt/yast pour pouvoir préciser lors d'un déploiement d'appli que les fichiers de conf seront à tel ou tel endroit?
-
[^]Re: Une fois de plus, les votes
Posté par Nÿco (Jabber id, page perso, ) le 14/05/2003 à 09:10. (lien). Évalué à 3.> Perso j'aurai bien aimé avoir un simple .conf dans mon home, qui contient les répertoires de conf, plutot que plein de .xxxx mélangés avec les autres docs
[+++]
Vrai ! Marre de cette tonne de .merdes qui saoulent bien dans $HOME...--
Jabber ID : xmpp:Nyco@jabber.fr
-
[^]Re: Une fois de plus, les votes
Posté par Aurélien Le Provost - Ribaltch (page perso, ) le 14/05/2003 à 09:44. (lien). Évalué à 1.>> À côté, Linux est beaucoup plus clair
>
> Bof, si les clés de la base de registre ne sont pas claires, il y
> a une structure, pareil pour le système de fichier Unix classique.
> pas sur qu'un /usr/local/share soit plus logique qu'un
> HKEY_machin_chose.
Ça a au moins l'avantage d'utiliser une notion (le système de fichiers) que la plupart des admins, en culotte courte ou pas, connaissent.
>> un fichier de configuration ? Dans /etc
>
> ouais, enfin dans un des sous répertoires de /etc en général, et
> ce n'est pas toujours si simple à trouver si on ne connait pas le
> nom du fichier à l'avance.
Honnêtement, c'est de la mauvaise foi. S'il n'est pas directement dans /etc, ton fichier de configuration est dans /etc/<nom_du_prog>/conf...
> ou alors dans un .xxxx du répertoire home
Encore de la mauvaise foi. /etc est pour tout le monde, et chacun peut rajouter/remplacer/redéfinir ses options de configuration. C'est l'un des nombreux avantages d'Unix (par rapport à Windows), son support multi-utilisateur natif, propre et clair.
> ou alors dans une clé de gconf (ben oui, on a beau critiquer la
> base de registre c'est un concept pas idiot).
Gconf, je ne connais pas, je ne sais pas pourquoi ils ont utilisé ce principe, donc je ne vais pas critiquer, même si ça me parait idiot et inutile (zut, j'ai critiqué).
> ou alors dans un /usr/kde/version/..... planqué quelque part
Pour revenir in-topic, le rôle d'une distribution est justement d'éviter ce genre d'"héréries" en unifiant tout ça. Bien sûr, des types comme le concepteur de qmail râle quand on veut déplacer ses fichiers (et pour d'autres raisons, je sais), mais l'important c'est ce que veut l'utilisateur. Si, comme moi, il veut quelque chose d'unifié, il doit pouvoir l'obtenir.
>> Un fichier verrou ? Dans /var/run
>
> ou /var/tmp ou /tmp ou dans le profile
Cf. ma réponse sur le rôle d'unification des distributions.
> Bref, c'est organisé et ca marche, à mon avis c'est un truc
> suffisament fonctionnel pour éviter d'être changé à moins d'être
> vraiment sur que ca vaille le coup (parce que pendant la
> transistion il y aura un bordel immonde).
On se rejoint : le changement pour le changement, très peu pour moi.
> Mais franchement ca n'est pas tout à fait clair. Il n'y a qu'à
> voir les applications qui sont dans /usr /usr/lesoft
> /usr/kde/version/... /usr/local /usr/local/lesoft /var (sisi j'en
> ai vu) /opt/lesoft /bin suivant les cas. Chacun donnera sa vision
> de ce à quoi correspondent ces répertoires mais il faut avouer que
> suivant les versions et les distributions des softs équivalents ne
> se trouvent pas placés au même endroit.
Cf. ma réponse sur le rôle d'unification des distributions.
> Au contraire de toi je trouve l'archi Win meilleure (meme si
> _tres_ largement perfectible).
Beuah. Un ami avait du mal à me faire avouer que finalement je n'aime pas Windows, mais au final c'est clair : il n'y a pas que des arguments philosophiques... Windows, caca.
> Il y a plusieurs répertoires dans le home ? un pour les conf, un
> pour le menu, un pour les modèles de fichiers, un pour les video
> un pour la musique, un pour les autres docs ..... on aime ou on
> aime pas mais c'est cohérent.
Ah nan ! C'est la caricature de ce que je déteste sous Windows : on pense pour toi, on définit tes besoins quand il faudrait laisser le libre choix, et à côté de ça il y a une ribambelle de choses mal gérées ou codées avec les pieds... Je pense notamment à la gestion du réseau, par exemple le DNS... Argh, quelle horreur :-( Windows, caca !
Pour te répondre, *JE* veux décider de la manière dont je gère mes données : si je veux un répertoire images, un répertoire vidéos ou encore un répertoire musique, je suis largement capable de les créer moi-même, et je ne pense pas que l'utilisateur lamdba ne le soit pas...
> Perso j'aurai bien aimé avoir un simple .conf dans mon home, qui
> contient les répertoires de conf, plutot que plein de .xxxx
> mélangés avec les autres docs
C'est ce que je me suis dit à une époque. Et puis j'ai poussé la réflexion, j'ai cherché les raisons et les idées des personnes qui ont décidé de la manière dont ça se passerait, et qui avaient probablement passé beaucoup de temps dessus.
Et je me suis rendu compte que créer un répertoire spécialement pour les fichiers de configuration n'avait pas d'intérêt, puisqu'il ferait double emploi en quelque sorte avec les $HOME/.XXXX que tu décris tant. Quelle différence fondalement entre les deux systèmes ? Aucun, sinon que tu te retrouves peut-être avec un répertoire non caché pour ces fichiers de conf.
Et ça, je déteste plus que l'idée d'avoir tout plein de $HOME/.XXXX ! Je supprime par exemple systématiquement le répertoire Desktop que me crée KDE les rares fois où je le lance, ou encore le répertoire GNUStep de Window Maker...
En gros :
Fichiers non cachés : tes données, ton utilisation perso.
Fichiers cachés : les fichiers de configuration.
C'est propre, pratique, clair, bien pensé, c'est Unix ;-)
(Attention, un troll se cache dans la dernière phrase :-)--
Encryption is not magic pixie dust to sprinkle on things to make them more secure.-
[^]Re: Une fois de plus, les votes
Posté par helf (page perso, ) le 14/05/2003 à 10:06. (lien). Évalué à 2.Fichiers non cachés : tes données, ton utilisation perso.
Fichiers cachés : les fichiers de configuration.
1) pb le .bashrc c'est de la conf ou de l'exec? Les .xxxx ne sont pas que du stockage de config. Donc ce n'est pas homogène.
2) quand j'ai trop de fichiers dans un repertoire, je cree des sous repertoires. Donc quand j'ai trop de .xxxx, je crée des repertoires ad'hoc.
Finalement, pourquoi ne pas créer un .conf , un .rc, un .data, un .desktops ?-
[^]Re: Une fois de plus, les votes
Posté par Aurélien Le Provost - Ribaltch (page perso, ) le 14/05/2003 à 10:16. (lien). Évalué à 0.1) pb le .bashrc c'est de la conf ou de l'exec?
C'est un fichier utilisé pour configurer ton shelle, non ?
> Les .xxxx ne sont pas que du stockage de config. Donc ce n'est pas
> homogène.
C'est sensé être homogène, parce que les .xxxx sont sensés être des fichiers de configuration...
> 2) quand j'ai trop de fichiers dans un repertoire, je cree des
> sous repertoires. Donc quand j'ai trop de .xxxx, je crée des
> repertoires ad'hoc.
Justement, tout l'intérêt est que tu ne les voies pas, donc pas besoin de les trier au fond. Il suffit juste de faire "cd ~/.<programmes>" quand tu en as besoin. Je me trompe peut-être, mais créer un sous-répertoire pour les fichiers de configuration ne reviendrait qu'à taper ".conf/" en plus dans la commande ci-dessus.
> Finalement, pourquoi ne pas créer un .conf, un .rc,
Un rc ? Ton environnement utilisateur est bootable ?
> un .data, un
Ça existe déjà, c'est $HOME...
> .desktops ?
Là par contre je suis d'accord, c'est de la configuration. Et je suis d'autant plus d'accord si c'est unifié et si KDE et GNOME peuvent l'utiliser de concert. Mais c'est un autre débat je crois, et je n'aime pas les bureaux :-)--
Encryption is not magic pixie dust to sprinkle on things to make them more secure.-
[^]Re: Une fois de plus, les votes
Posté par helf (page perso, ) le 14/05/2003 à 12:00. (lien). Évalué à 2.Pour moi un fichier de configuration, çà n'exécute pas de code, alors le .bashrc en fichier de conf, c'est discutable. D'ailleurs le rc, c'est "run command" non?
Le .rc, c'est justement pour stocker les fichiers .rc
.rc çà n'a pas grand chose à voir avec le boot, sauf si tu considères que le démarrage des services est obligatoirement lié au boot, auquel cas, il faudra que je revoie mes cours sur unix...Moi souvent, je fais un /etc/init.d/network restart, ou bien un init 1 suivi d'un init 3, sans rebooter la machine.
Le .data dans mon esprit n'est pas un $HOME, ce serait plutot un repertoire contenant des données applicatives qui ne sont ni des .rc, ni des config. Par exemple, des fichiers de swp de vi.
.desktops: pour tout le magma, .kde .gnome .wm .bidule_interface_graphique-
[^]Re: Une fois de plus, les votes
Posté par gnap gnap (page perso, ) le 14/05/2003 à 14:51. (lien). Évalué à 1.L'intérêt des bashrc executés, c'est ça : http://stock.coleumes.org/doc.php?i=/.bashrc(...)
Propose moi un format de configuration me permettant une telle finesse de configuration.
Un fichier de conf doit à un moment où un autre être interpreté. Pourquoi réinventer un interpreteur alors qu'on dispose de super interpreteurs (bash, perl etc...) ?-
[^]Re: Une fois de plus, les votes
Posté par helf (page perso, ) le 14/05/2003 à 20:50. (lien). Évalué à 2.L'objet de la discussion, c'est principalement de savoir s'il faut ou non trier les repertoires en .xxx dans le $HOME. L'essentiel n'est pas de savoir si un xxxrc est une conf ou un exec.
Je pense qu'actuellement les .xxxx encombrent le $HOME. Alors pourquoi ne pas faire un tri?
-
-
-
-
[^]Re: Une fois de plus, les votes
Posté par doublehp (page perso, ) le 14/05/2003 à 14:11. (lien). Évalué à 1.1) pb le .bashrc c'est de la conf ou de l'exec? Les .xxxx ne sont pas que du stockage de config. Donc ce n'est pas homogène.
Je te renvoie a mon journal : http://linuxfr.org/~dhp/2648.html(...) qui montre à quel point fichier de conf, scripte, source, ou fichier executable est un concepte unique sous unix . Mon journal montre comment utiliser des sources C aussi simplement que des scripts PERL ...
Mais le meilleur exemple que je conaisse est encore le fichier de conf de rp-pppoe, qui est une liste de paramètres, mais dans la premiere ligne tu met le chemin du démon, tu rends le fichier executable, et du coup, c est en executant la conf, que le demon se lance tout seul: je trouve cette utilisation tout simplement GENIALE, et evite d avoir a taper :
$ demon -c .conf
Il suffit aliors de taper:
$ /etc/demon/conf
ou encore
$ ~//conf
et ca roule tout seul ...
Oui je sais, ce principe est fort criticable, n'est pas aplicable à tout, et va un poil à l'encontre des usages et coutumes, mais il exploite 100% des spécificités des UNIX, et n'est pas dénué d'intérret ...
-
-
[^]Re: Une fois de plus, les votes
Posté par Philippe () le 14/05/2003 à 12:15. (lien). Évalué à 2.> En gros :
> Fichiers non cachés : tes données, ton utilisation perso.
> Fichiers cachés : les fichiers de configuration.
C'est vrais que c'est très clair, sauf que certains logiciels t'ouvrent une boite d'ouverture de fichiers qui les listent tous (cachés et non cachés) et ça c'est très gonflant de s'appuyer a chaque fois la liste des x repetroires de conf avant ses propres répertoires.
Voilà, simple avis de simple utilisateur.
-
-
[^]Re: Une fois de plus, les votes
Posté par Séverin Tagliante-Saracino () le 14/05/2003 à 19:09. (lien). Évalué à 1.<blockquote>Au contraire de toi je trouve l'archi Win meilleure (meme si _tres_ largement perfectible). Il y a plusieurs répertoires dans le home ? un pour les conf, un pour le menu, un pour les modèles de fichiers, un pour les video un pour la musique, un pour les autres docs ..... on aime ou on aime pas mais c'est cohérent.</blockquote>
J'allais dire OUI. Mais en fait non. Regardons ce qu'il y a à l'intérieur du Home made in Windows (Documents and Settings, super pratique en ligne de commande :-) :
Application Data, Bureau, Cookies, Favoris, Local Settings, Menu Démarrer, Mes documents, Mes documents récents, Modèles, SendTo, UserData, Voisinage d'impression
Et les sous-répertoire sont pas mal non plus. C'est vraiement trop le bordel pour servir de modèle, et pour s'y repérer confortablement. En pratique on va directement dans "Mes documents". Et KDE et GNOME ont aussi un répertoire Documents dans lequel je vais directement. Bref, en réalité, il y a aucune différence : Windows s'est unixifié, et Unix s'est windozifié.
Quant à la localisation (partiel) des répertoire est une idiotie sans nom, qui ne fait et ne fera jamais que compliquer les choses. La meilleure solution est définitivement de localiser éventuellement les liens sur le bureau. Je ne parle même pas des noms à rallonge avec espace. Ce serait un répertoire qui contient un album de MP3, je dis pas, mais là pour un répertoire système, c'est vraiment se foutre de la gueulle de la ligne de commande.
Quant au répertoire système (Windows), c'est encore plus un bordel sans nom. Bref, je préfère sans aucun doute l'arborescence Unix classique. Enfin je préferais, parceque maintenant je préfère celle de GoboLinux, Na !
-
-
[^]Re: Une fois de plus, les votes
Posté par doublehp (page perso, ) le 14/05/2003 à 14:01. (lien). Évalué à 1.[...]et pas franchement prometteuse pour ce qui est des bénéfices qu'on pourrait en retirer.
Je n'ai rien contre le début du paragraphe, mais là, je te trouve trop "économe" : les LL ne se veulent pas "rentables", mais nu fouillis innomable d'idées d'adolescents qui s'ennuient. Si le mec a envie de faire un thèse sur les arbres de données, et de prendre comme exemple de thèse une nouvelle hiérarchie, je trouve déplacé de ta part de le lui reprocher ... et là, il publie son travail ... (même si en pratique c'est pas du tout ça)-
[^]Re: Une fois de plus, les votes
Posté par William Steve Applegate (page perso, ) le 14/05/2003 à 18:32. (lien). Évalué à 1.Bah franchement, j'ai plus vu ça comme l'énième tentative de mettre le so^H^H^W^W^H^H'imposer sa vision des choses (à la DJB. D'ailleurs, j'ai lu dans un autre thread que lui aussi a proposé une hiérarchie de ce genre) plutôt qu'une tentative expérimentale. Je serais plus d'accord par exemple s'il avait créé un nouveau type de FS avec des caractéristiques novatrices. Sans compter qu'on peut faire du neuf avec du vieux, regarde OBSD : leur nouveau pare-feu, pf, est compatible avec l'ancien, et pourtant il a de nouvelles fonctionnalités... M'enfin, de toute manière, je ne vais pas hurler à la mort si Gobolinux continue son petit bonhomme de chemin. C'est juste que, perso, je vais pas l'utiliser parce que j'y vois pas d'intérêt...
--
Ce message vous a été présenté par les trollomètres de compétition Prumpleffer™
-
-
-
-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par helf (page perso, ) le 13/05/2003 à 22:33. (lien). Évalué à 1.Je ne vois pas en quoi la gestion des paquets est mauvaise sous GNU/Linux.
Ben, comment je fais quand j'ai cassé ma base rpm et que les rpm me sortent un "Seg fault" ?
Bien sûr il aurait fallu faire des sauvegardes, bien sûr le système rpm n'est pas le meilleur, etc...
Mais bon, un système qui permet de se passer d'une base de données "fermée" enfin pas trop ouverte, je pense que çà peut être bien.-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par gnap gnap (page perso, ) le 14/05/2003 à 14:55. (lien). Évalué à 1.RPM marche bien.
Je n'ai « cassé » de base de données RPM que lorsque j'ai découvert GNU/Linux. J'ai utilisé des RedHat pendant 3 ans sans m'en plaindre.
Il y a d'ailleurs une option --rebuild qui reconstruit la base en cas de problème.
Je ne vois pas l'intérêt de « faire des sauvegardes » des RPM. Un RPM est un logiciel. Il suffit de reinstaller le RPM - à quoi bon le sauvegarder, suffit d'avoir un CD avec ces RPM.
En cas de pépin avec un RPM, rpm -e --force $paquet_brisé && rpm -ivh
$paquet_brisé.
Je ne vois pas où est le malentendu !
Au contraire, tu ne peux pas virer un paquet qui à des dépendances. Tu peux très bien virer DirectX d'un ordi même si t'as StarCraft installé...-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par helf (page perso, ) le 14/05/2003 à 20:54. (lien). Évalué à 1.en fait quand la base est hs, ca donne
rpm -e ce_que_tu_veux
Segmentation fault
rpm -i pareil_ca_marchera_pas
Segmentation fault
:(
Là j'aurais été content de pouvoir réparer à la main.
-
-
-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par huhuhu () le 14/05/2003 à 06:59. (lien). Évalué à 1.Je connais un Monsieur qui n'est sans doute pas d'accord avec toi:
http://linuxfr.org/comments_reply,2727,208129,5.html(...)-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par gnap gnap (page perso, ) le 14/05/2003 à 15:01. (lien). Évalué à 1.Je pense que monsieur découvre Debian.
Je copie-colle ici pour faciliter la lecture :
"apt-get install qt3-qtconfig ... il a besoin de jarter tous les packages liés à KDE ...
Bon je desinstalle le tout et j' essaye un apt-get install kde ... il a besoin de retirer deux packages libqtmt et qt-config ...
Faut qu' on m' explique la ^^ "
Si cet utilisateur à besoin de KDE, pourquoi se soucie t-il de qt3-qtconfig ?
Qu'il fasse un simple
apt-get install kdebase
Ca lui demandera peut-être de virer certains paquets. S'il veut comprendre pourquoi, qu'il lise les listes de discussion des devs. Certains paquets sont en conflits entre eux, proposant les même programmes souvent. L'utilisateur doit se soucier uniquement des logiciels. A vrai dire, les paquets prévus dépendent des responsables debian qui font des choix en théorie en connaissance de cause.
Je n'ai aucun qt-config installé et j'ai KDE 3.1
J'ai
777. libqt2_3:2.3.1-22
778. libqt3c102-mt_3:3.1.1-8
Mais je n'en ai cure, je me soucie juste d'avoir
380. kdebase_4:3.1.1-1
qui m'a choisi les lib* qu'il faut.-
[^]Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
-
-
CiDepot et Files ?
"Here's what ls / looks like on GoboLinux [avec un patch noyau pour cacher l'arborescence classique]
Depot
Mount
System
Files
Programs
Users"
"Each program directory (for example, /Programs/KDE) holds version directories (/Programs/KDE/3.0, /Programs/KDE/3.1.1), and a version-neutral directory for settings (/Programs/KDE/Settings), to keep files that would normally be in /etc."
"/bin, /sbin, /usr/bin, /usr/local/bin (and so on) are all symlinks to /System/Links/Executables" [idem pour Libraries, Headers, Shared and Manuals]
Mount remplace Mnt. Et Users remplace Home, en y intègrant le repertoire du "root", qui s'appelle maintenant par défaut Gobo :-)
Je me suis demandé à quoi correspondait entre autre "Depot" et "Files".... J'ai trouvé ça dans la discussion sur kuro5hin : "
"Files" holds extra files needed by applications that are not part of the app package itself: plugins, codecs, audio patchsets... In other words, things you won't replace when you upgrade your app in /Programs.
"Depot" is more like a 'common user area'. Its contents are not dictated by the GoboLinux hierarchy, the user uses it and sets permissions as/if he/she sees fit. Think of it as a /pub directory. Maybe it does make more sense in a single-user machine, but I can see it being useful in a multi-user setup. For example, I keep my MP3s in /Depot/Music.
/proc is on /System/Status, and /var is on /System/Variable. They work as usual. Their symlinks at the root directory were hidden with GoboHide. /log is /var/log, in other words, /System/Variable/log. Whether Files (actually Depot) should be separate from Users or not, it's a matter for the users to decide. I'd rather share stuff with other users of my machine putting them on /Depot than opening up permissions of specific directories of my $HOME (I like to keep it rwx------). But that's just me."
Moi j'aime bien.
Par ailleurs, pendant que l'on est dans les concepts radicaux, existe-t-il un logiciel "mime center" qui recense les fichiers Mime de différents programmes connus, qui attribue à un de ces logiciels le statut de "mime master" (konqueror par exemple), et qui récrivent régulièrement par dessus les fichiers de configurations des autres, les "mime slaves" ?
-
[^]Re: CiDepot et Files ?
Posté par jmfayard () le 13/05/2003 à 17:50. (lien). Évalué à 7.Moi j'aime pas
Pourquoi mettre des majuscules à ces noms de dossiers ?
C'est chiant lorsqu'on navigue dans le sytème de fichiers
par la ligne de commande. Ou alors, quitte à ne pas être conservateur,
on leur rajoute des espaces, comme dans
$ ls [shift]my[tab]
My Documents
My Music
merde
$ ls [shift]my[antislash][espace]D[tab]-
[^]Re: Depot et Files ?
Posté par Séverin Tagliante-Saracino () le 13/05/2003 à 19:45. (lien). Évalué à 1.J'avais par remarqué :-( Je dirais bien vive le "case insensitive" et le "_" qui équivaut à " " et réciproquement, juste pour t'agacer et pour montrer que je suis vraiment radical, mais ce serait trahir ma pensée.
Mais pourquoi diable ont-ils mis des majuscules à leur files system ?-
[^]Re: Depot et Files ?
Posté par Séverin Tagliante-Saracino () le 13/05/2003 à 19:52. (lien). Évalué à 2.En fait si. En tout cas je pose la question :
A quoi ça sert concrètement de distinguer readme, ReadMe, readME, README dans un même répertoire ?
Pourquoi ne pas rendre " " et "_" interchangeable, de façon à avoir à la fois des jolis noms de fichiers (undercore beurk) et des fichiers faciles à utiliser en ligne de commande ?-
[^]Re: Depot et Files ?
Posté par MrTout (page perso, ) le 13/05/2003 à 20:31. (lien). Évalué à 5.Il parait qu'il y a un OS qui fait ca mais c'est plus cher.
-
[^]Re: Depot et Files ?
Posté par Julien Laumonier (page perso, ) le 13/05/2003 à 21:13. (lien). Évalué à 1.A quoi ça sert concrètement de distinguer readme, ReadMe, readME, README dans un même répertoire ?
Les fichiers qui commencent avec une majuscules sont affichés en premier quand tu fait un ls. (tu le savais peut etre déjà). Ce qui fait que README (qui est sensé etre un fichier important) est affiché dans les premiers. Donc readme et README n'ont pas la même utilité. l'un va etre planqué dans toute la liste des fichiers l'autre sera au début.
Tout ca pour dire pas grand chose finalement.
par contre, je suis contre les espaces, les soulignés et les majuscules dans les noms de répertoires... pas facile à taper pour se déplacer dans l'arborescence. (en ligne de commande évidement)-
[^]Re: Depot et Files ?
Posté par Séverin Tagliante-Saracino () le 13/05/2003 à 22:08. (lien). Évalué à 1.Je pensais qu'il y avait une raison précise. Cela dit, je n'aimerais pas du tout que Gnu/Linux implémente le "case insensitive". Ca fait brouillon, pas rigoureux. Et puis avec la touche Tab et les recherche "insensitive" ça ne pose du coup plus aucun problème. Et puis ça emmerde les windoziens quand ils hébergent leur site web sur un serveur Unix.
Par contre je trouve toujours les _ très moches, je préfère les espaces, c'est plus jolis. Le probleme c'est qu'un espace c'est joli, mais avec un \ devant et entouré de guillemet, c'est tout de suite moins bien. Rendre équivalent _ et " " me semblait une idée marrante, mais tout bien réfléchi ça pose plus de problèmes que ça en résoud.
Boaf, finalement c'est très bien comme c'est avec le \ devant le " ".-
[^]Re: Depot et Files ?
Posté par Aurélien Le Provost - Ribaltch (page perso, ) le 14/05/2003 à 09:50. (lien). Évalué à 1.> Par contre je trouve toujours les _ très moches, je préfère les
> espaces, c'est plus jolis.
Moi aussi, et la touche espace est plus facile à attraper que la toucher souligné.
Et comme les concepteurs de Shells furent du même avis que nous, ils ont eu la bonne idée de définir l'espace et non le souligné comme séparateur de commandes et autres options sur la ligne de commande.
;-)--
Encryption is not magic pixie dust to sprinkle on things to make them more secure.-
[^]Re: Depot et Files ?
Posté par Séverin Tagliante-Saracino () le 14/05/2003 à 17:05. (lien). Évalué à 1.Ca se défend, en effet :-)
-
-
-
[^]Re: Depot et Files ?
Posté par Olivier Abad () le 13/05/2003 à 22:28. (lien). Évalué à 2.Les fichiers qui commencent avec une majuscules sont affichés en premier quand tu fait un ls.
Ça dépend de la localisation utilisée. En français, par exemple, ls affiche "foobar" avant "README". Et en plus il ignore les "." : un ls -a dans $HOME affiche les répertoires et fichiers cachés au milieu des autres...
-
[^]Re: Depot et Files ?
Posté par doublehp (page perso, ) le 14/05/2003 à 14:29. (lien). Évalué à 1.Les fichiers qui commencent avec une majuscules sont affichés en premier quand tu fait un ls.
Désolé de te contredire, mais dans ma Debian ou j'ai activé tous les alias du .bashrc, "ls" mixe les cases, et encore pire : "ls -a" me met les .* en vrac dans le reste
NB : alias ls='ls --color=auto'
NB2 : exemple : $ls -a
[...]
hurd
.ICEauthority
.irssi
iteam
Jan1903.jpg
.java
[...]
oui je sais c'est horrible :(
-
-
[^]Re: Depot et Files ?
Posté par jmfayard () le 14/05/2003 à 09:42. (lien). Évalué à 1.Parce que, l'insensibilité à la casse, ça n'a aucun sens, et c'est beaucoup
plus difficile une fois sorti des caractère anglais [a-z] ==> [A-Z]
Quelques exemples ?
en allemand , il y a le ß qui en majuscule devient ss
tchüß -> TCHÜSS
maintenant, si tu le remets en minuscule, ça va donner
TCHÜSS -> tchüss
De plus, le passage en majuscule change suivant les langues :
citroën -> CITROEN en français, mais
citroën -> CITROËN en canadien français
Si tu veux gérer tout ça, non seulement le système de fichers devra
être au courant des petits détails de chaque jeu de caractères,
mais en plu chaque opération dessus aura à regarder quelle locale
est utilisée pour déterminer si deux noms sont équivalents.
Si tu pense que c'est simplle, lit la FAQ d'unicode http://unicode.org(...)
et je pense que tu ne suggèrera plus un système de fichiers insensible
à la casse.
Moi en tout cas, ça me convient très bien comme ça.-
[^]Re: Depot et Files ?
Posté par Aurélien Le Provost - Ribaltch (page perso, ) le 14/05/2003 à 09:54. (lien). Évalué à 1.> citroën -> CITROEN en français, mais
> citroën -> CITROËN en canadien français
Allons bon, ce n'est qu'en canadien français qu'il faut mettre des accents aux majuscules ?
Moi qui suis tout content de cette possibilité de XFree, qui trouve ça joli et qui a pris l'habitude... :-/
Alors alors ? Verdict ?--
Encryption is not magic pixie dust to sprinkle on things to make them more secure.-
[^]Re: Depot et Files ?
Posté par helf (page perso, ) le 14/05/2003 à 10:15. (lien). Évalué à 0.Pour moi un système d'exploitation se doit d'être fiable avant d'être joli.
Par conséquent, un caractère est un caractère, pas un ensemble aux limites floues.
Un 'A' est un 'A'. Un 'a' est un 'a'.
Si quelqu'un veut mettre sa touche "mes gouts et mes couleurs" il n'a qu'à developper son frontal. Pourquoi pas?
Pour ma part, rien que les espaces dans les noms de fichiers çà me gêne, rien que pour la programmation en shell. Faut tout mettre en double cotes et quand on doit faire des scripts m4 ou similaires ca devient le bazar...-
[^]Re: Depot et Files ?
Posté par Aurélien Le Provost - Ribaltch (page perso, ) le 14/05/2003 à 10:19. (lien). Évalué à 1.Tu es à côté de la plaque, parce que moi aussi. Je ne participe pas au débat (enfin pas avec ce commentaire en tout cas), je pose une question de linguistique, enfin d'orthographe.
Sinon, pour participer au troll quand même, parce que ça chatouille : avec des idées comme ça, on serait tous sous Windows, parce qu'un ordinateur est un PC, un système d'exploitation est Windows, et que la diversité c'est pas bien.--
Encryption is not magic pixie dust to sprinkle on things to make them more secure.-
[^]Re: Depot et Files ?
Posté par Nicolas Roard (page perso, ) le 14/05/2003 à 10:47. (lien). Évalué à 1.Si ça peut te rassurer, on DOIT (dixit l'Imprimerie Nationale) mettre des accents aux majuscules en Français. Exemple connu : "le palais des congrès" => "LE PALAIS DES CONGRES"
Si on reprends de vieux manuscrits, ils ont les accents. Ne pas mettre d'accents sur les majuscules date au pifomètre de l'introduction des premières machines à écrire, d'origine anglo-saxone, et qui donc n'en disposaient pas. Mais c'est une erreur, car cela peut nuire à la compréhension, d'autant que ce n'est pas un problème de les utiliser sur les machines/OS actuels.
-
-
-
-
-
-
-
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.