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.
Aller plus loin
- article sur Kuroshin (26 clics)
- GoboLinux (37 clics)
# Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par Hobgoblins Master (Mastodon) . Évalué à 3.
# Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par jeeeeeee . Évalué à 2.
# Bof,
Posté par schyzomarijks . Évalué à 4.
[^] # Re: Bof,
Posté par doublehp (site web personnel) . Évalué à 10.
[^] # Re: Bof,
Posté par Hobgoblins Master (Mastodon) . Évalué à 1.
[^] # Re: Bof,
Posté par doublehp (site web personnel) . Évalué à 7.
[^] # Re: Bof,
Posté par pa_pitufo_pa . Évalué à 1.
[^] # Re: Bof,
Posté par let antibarbie = xp <- xp - 1 . Évalué à 1.
Par contre les liens hard sur des repertoires.... hmmmpf! (quoi ca marche on m'aurait menti ?).
[^] # Re: Bof,
Posté par LupusMic (site web personnel, Mastodon) . Évalué à -1.
[^] # Re: Bof,
Posté par MrTout (site web personnel) . Évalué à 2.
[^] # Re: Bof,
Posté par Hobgoblins Master (Mastodon) . Évalué à 3.
Ç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 (site web personnel) . Évalué à 1.
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 Hobgoblins Master (Mastodon) . Évalué à 1.
Je pense qu'a cause de ces restrictions, c'est une solution économique (sur les plans temps, argent à cause de la place gagnée sur disque..., boulot) pour un réseau relativement restreint (je dirait < 500 machines en tout cas).
Après, je vois plus une archi avecun serveur de déploiement (type cfengine) qui est beaucoup plus souple.
# Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par Bruno Muller . Évalué à 7.
# Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par ccomb (site web personnel) . Évalué à 5.
[^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par un_brice (site web personnel) . Évalué à 5.
# Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par DiZ . Évalué à 9.
[^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par Nicolas Roard (site web personnel) . Évalué à 2.
[^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par snihf (site web personnel) . Évalué à 2.
[^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par Nicolas Roard (site web personnel) . Évalué à 3.
# Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par imr . Évalué à 5.
[^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par LupusMic (site web personnel, Mastodon) . Évalué à -2.
Quoi, tu as un problème avec cette application ? Redémarre la machine. Si ça marche pas, essaie de réinstaller le logiciel. Si ça marche pas, réinstalles Windows.
# Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par Gentoo][Gravis . Évalué à 4.
[^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par Gentoo][Gravis . Évalué à 5.
[^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par imr . Évalué à 1.
[^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par Annah C. Hue (site web personnel) . Évalué à 2.
[^] # La marmotte : elle revient, elle n'est pas contente, elle a faim, elle n'est pas végétarienne.
Posté par zyvad . Évalué à 9.
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 . Évalué à 6.
[^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par jmfayard . Évalué à 4.
en fait, non etc veut dire quelquechose comme editing text config,
c'est la config de ton ordinateur, et tu peux l'éditer avec VI
[^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par tfing . Évalué à 2.
ca correspond pas trop a un fichier de configuration
et des distribs ont tendance a y mettre vraiment n'importe quoi dans /etc
[^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par Jar Jar Binks (site web personnel) . Évalué à 7.
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 (site web personnel) . Évalué à 1.
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 (site web personnel) . Évalué à 4.
[^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par doublehp (site web personnel) . Évalué à 0.
[^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par reno . Évalué à 1.
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 (site web personnel) . Évalué à 1.
Pourquoi croyez vous que ca soit standard ??
Surement pour une uniformisation des *nix, mais aussi pour les humains ne pas se perdre dans les différents FHS si on laissait libre cours à différents FHS.
/etc == "editing text config" !!
Si c'est juste pour que "etc" soit renommé "conf" parce que cela sonne mieux aux oreilles de certains => aucun intérêt et perte de temps !
C'est déjà bien on n'a "que deux"(à qq choses prêts) familles d'Unix (sysV et BSD), changer son petit nom à un répertoire car son nom ne sonne pas bien serait relancer des débats et forké d'autres FHS, d'où de nouvelles mouvances et une perte de standard.
[^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par doublehp (site web personnel) . Évalué à 1.
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 . Évalué à 4.
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 (site web personnel) . Évalué à 1.
[^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par Yohann (site web personnel) . Évalué à 1.
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>
# Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par oucho . Évalué à 7.
# Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par poil oq . Évalué à 3.
[^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par NebuchadnezzaR . Évalué à -1.
[^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par ccomb (site web personnel) . Évalué à 2.
[^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par Jonathan ILIAS-PILLET (site web personnel) . Évalué à 1.
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 . Évalué à 1.
# Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par j . Évalué à 3.
[^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par Rage . Évalué à 2.
Mes alors les geeks nunuxiens seraient en fait des conservateurs? On m'aurait menti à l'insu de mon plein gré?
Moi qui croyait que les logiciels libres étaient un joyeux bazar de créateurs inspirés des universités... n'auraient-ils gardés de la science que ses comportements grégaires et obtus?
Dans la plupart des commentaires de cette news et dans ceux qu'on peut lire sur le site original je suis éffaré du conservatisme des nunuxiens sachant que ce système est concu pour justement s'interfacer en DOUCEUR avec les anciennes habitudes... snif.
# Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par Olivier Serve (site web personnel) . Évalué à 1.
# Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Le seul truc chiant est le mélange des repertoires selon l'application. /usr devrait avoir un repertoire par programme /usr/OOo ( en ro ) par exemple et un /var/OOo pour les donnés de l'application (les trucs qui ne sont pas relatifs aux utilisateurs, notament le .conf...). L'installeur ne devant pas avoir besoin d'être root.
"La première sécurité est la liberté"
[^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par nojhan (site web personnel, Mastodon) . Évalué à 1.
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 . Évalué à 1.
[^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par PLuG . Évalué à 4.
en tant que user normal:
tar xvzf openoffice
./configure --prefix=/usr/local/openoffice
make
en tant que user root:
preparation d'un environnement pour la nouvelle application:
- creation d'un repertoire d'install /usr/local/openoffice
- creation d'un user/group "openoffice" avec home dans /usr/local/openoffice mais sans shell.
- chown openoffice:openoffice /usr/local/openoffice
en tant que "openoffice"
make install
avec ce schema, il est necessaire d'etre root pour installer sur la machine,
ou alors il est necessaire que ROOT prepare l'environnement d'installation,
mais l'install en elle meme est faite par un user dédié a cette application,
et la compilation par un user lambda du systeme.
mais les packages on simplifié tout ca.
# Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par Anonyme . Évalué à 9.
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 Anonyme . Évalué à 0.
Pas le temps d'argumenter, de participer, mais celui de voter ?
[^] # Re: Une fois de plus, les votes
Posté par Nÿco (site web personnel) . Évalué à 1.
Ton post est argumenté, no pb !
[^] # Re: Une fois de plus, les votes
Posté par William Steve Applegate (site web personnel) . Évalué à 9.
Sinon, je rejoins assez ton avis : perso, je suis loin d'être un fan d'Unix et de ses idiosyncrasies, mais je pense que le système de fichiers n'est pas le truc le plus important à réformer. D'autant plus que l'argument généralement avancé (ça perd le débutant) est ridicule : vous avez déjà vu un Windows 2000 ? Vous avez 'Documents and Settings' qui joue le rôle de /home (avec plusieurs sous-répertoires par utilisateur), 'Program Files' (qui contient un peu tout et n'importe quoi : applis, DLL, fichiers de données, selon le bon vouloir du programmeur du soft), 'Winnt' et ses 'Inf', 'System', 'System32' (?!?), 'etc' (si, si), etc. Plus la base de registres et ses clés absconses. Allez donc y comprendre quelque chose ! À côté, Linux est beaucoup plus clair : un fichier de configuration ? Dans /etc. Un fichier verrou ? Dans /var/run, sûrement. On s'y fait assez vite, et en fin de compte, ce n'est pas gênant du tout. Le seul problème est celui de la désinstallation des applis, et comme on l'a dit, il y a les gestionnaires de paquets (ou ce bon vieux 'make uninstall', fourni par tous les programmeurs consciencieux). Certes, les /etc, /bin et autres /usr auraient gagné à être nommés de manière un peu plus claire, mais c'est secondaire. Alors, quel est le problème ?
Plus haut, un distingué co-posteur fait remarquer que tout ceci ressemble à une attitude assez conservatrice. Je suis d'accord... Néanmoins, il n'y a rien de mal à mes yeux à être conservateur s'il n'y a pas besoin de tout chambouler. Le changement pour le changement, ça n'apporte rien, et ça a tendance à tout casser. D'un autre côté, je ne suis pas contre une réflexion sur le système de fichiers et son organisation dans le cadre d'un effort plus vaste. Entre autres, il me semble (je dis bien « semble ») me souvenir que cette approche « un répertoire par appli » était celle adoptée par BeOS. Et ça ne me pose pas de problème. Néanmoins, un des grands atouts des Unix libres, c'est qu'ils « se tiennent sur les épaules de géants », pour paraphraser un certain physicien. Quel intérêt alors de se couper de tout cet héritage, et des bénéfices qu'il apporte (compatibilité avec l'existant, transfert aisé des connaissances, etc.) ? Bien sûr, l'auteur a prévu une solution (à coups de ln -s), mais un admin débarquant sur GoboLinux n'en sera pas moins paumé. Enfin, j'insiste sur le fait que je pense qu'il y a d'autres priorités (comme avoir un sous-système graphique au goût du jour, unifier/simplifier des pierres d'achoppement comme la configuration des pilotes de périphériques, mieux intégrer les différentes interfaces avec le système sous-jacent, etc.). Bref, chambouler le système de fichiers me semble donc une approche peu naturelle, et pas franchement prometteuse pour ce qui est des bénéfices qu'on pourrait en retirer. Je ne ferai donc pas, pour ma part, l'effort de réapprendre un autre système, à moins qu'il ne m'apporte vraiment quelque chose de plus.
[une petite note quand même : le site de GoboLinux semble avoir quelques problèmes de DNS et j'arrive pas à y accéder, je n'ai pu lire que l'article sur K5, j'ai donc peut-être raté une info importante. Une autre petite note : j'ai lu dans l'article qu'ils avaient aussi changé les scripts d'initialisation. Je ne pense pas non plus que l'init SysV soit une panacée universelle (il manque entre autres un moyen intégré de ne pas exécuter un script si tel ou tel autre a eu un problème). Néanmoins, je n'ai pas trop compris en quoi leur système se démarquait d'autres systèmes alternatifs comme simpleinit. Bref, rien de nouveau sous le Soleil, AMHA]
Envoyé depuis mon PDP 11/70
[^] # Re: Une fois de plus, les votes
Posté par Éric (site web personnel) . Évalué à 3.
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 (site web personnel) . Évalué à 2.
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 (site web personnel) . Évalué à 3.
[+++]
Vrai ! Marre de cette tonne de .merdes qui saoulent bien dans $HOME...
[^] # Re: Une fois de plus, les votes
Posté par Anonyme . Évalué à 1.
>
> Bof, si les clés de la base de registre ne sont pas claires, il y
> a une structure, pareil pour le système de fichier Unix classique.
> pas sur qu'un /usr/local/share soit plus logique qu'un
> HKEY_machin_chose.
Ça a au moins l'avantage d'utiliser une notion (le système de fichiers) que la plupart des admins, en culotte courte ou pas, connaissent.
>> un fichier de configuration ? Dans /etc
>
> ouais, enfin dans un des sous répertoires de /etc en général, et
> ce n'est pas toujours si simple à trouver si on ne connait pas le
> nom du fichier à l'avance.
Honnêtement, c'est de la mauvaise foi. S'il n'est pas directement dans /etc, ton fichier de configuration est dans /etc/<nom_du_prog>/conf...
> ou alors dans un .xxxx du répertoire home
Encore de la mauvaise foi. /etc est pour tout le monde, et chacun peut rajouter/remplacer/redéfinir ses options de configuration. C'est l'un des nombreux avantages d'Unix (par rapport à Windows), son support multi-utilisateur natif, propre et clair.
> ou alors dans une clé de gconf (ben oui, on a beau critiquer la
> base de registre c'est un concept pas idiot).
Gconf, je ne connais pas, je ne sais pas pourquoi ils ont utilisé ce principe, donc je ne vais pas critiquer, même si ça me parait idiot et inutile (zut, j'ai critiqué).
> ou alors dans un /usr/kde/version/..... planqué quelque part
Pour revenir in-topic, le rôle d'une distribution est justement d'éviter ce genre d'"héréries" en unifiant tout ça. Bien sûr, des types comme le concepteur de qmail râle quand on veut déplacer ses fichiers (et pour d'autres raisons, je sais), mais l'important c'est ce que veut l'utilisateur. Si, comme moi, il veut quelque chose d'unifié, il doit pouvoir l'obtenir.
>> Un fichier verrou ? Dans /var/run
>
> ou /var/tmp ou /tmp ou dans le profile
Cf. ma réponse sur le rôle d'unification des distributions.
> Bref, c'est organisé et ca marche, à mon avis c'est un truc
> suffisament fonctionnel pour éviter d'être changé à moins d'être
> vraiment sur que ca vaille le coup (parce que pendant la
> transistion il y aura un bordel immonde).
On se rejoint : le changement pour le changement, très peu pour moi.
> Mais franchement ca n'est pas tout à fait clair. Il n'y a qu'à
> voir les applications qui sont dans /usr /usr/lesoft
> /usr/kde/version/... /usr/local /usr/local/lesoft /var (sisi j'en
> ai vu) /opt/lesoft /bin suivant les cas. Chacun donnera sa vision
> de ce à quoi correspondent ces répertoires mais il faut avouer que
> suivant les versions et les distributions des softs équivalents ne
> se trouvent pas placés au même endroit.
Cf. ma réponse sur le rôle d'unification des distributions.
> Au contraire de toi je trouve l'archi Win meilleure (meme si
> _tres_ largement perfectible).
Beuah. Un ami avait du mal à me faire avouer que finalement je n'aime pas Windows, mais au final c'est clair : il n'y a pas que des arguments philosophiques... Windows, caca.
> Il y a plusieurs répertoires dans le home ? un pour les conf, un
> pour le menu, un pour les modèles de fichiers, un pour les video
> un pour la musique, un pour les autres docs ..... on aime ou on
> aime pas mais c'est cohérent.
Ah nan ! C'est la caricature de ce que je déteste sous Windows : on pense pour toi, on définit tes besoins quand il faudrait laisser le libre choix, et à côté de ça il y a une ribambelle de choses mal gérées ou codées avec les pieds... Je pense notamment à la gestion du réseau, par exemple le DNS... Argh, quelle horreur :-( Windows, caca !
Pour te répondre, *JE* veux décider de la manière dont je gère mes données : si je veux un répertoire images, un répertoire vidéos ou encore un répertoire musique, je suis largement capable de les créer moi-même, et je ne pense pas que l'utilisateur lamdba ne le soit pas...
> Perso j'aurai bien aimé avoir un simple .conf dans mon home, qui
> contient les répertoires de conf, plutot que plein de .xxxx
> mélangés avec les autres docs
C'est ce que je me suis dit à une époque. Et puis j'ai poussé la réflexion, j'ai cherché les raisons et les idées des personnes qui ont décidé de la manière dont ça se passerait, et qui avaient probablement passé beaucoup de temps dessus.
Et je me suis rendu compte que créer un répertoire spécialement pour les fichiers de configuration n'avait pas d'intérêt, puisqu'il ferait double emploi en quelque sorte avec les $HOME/.XXXX que tu décris tant. Quelle différence fondalement entre les deux systèmes ? Aucun, sinon que tu te retrouves peut-être avec un répertoire non caché pour ces fichiers de conf.
Et ça, je déteste plus que l'idée d'avoir tout plein de $HOME/.XXXX ! Je supprime par exemple systématiquement le répertoire Desktop que me crée KDE les rares fois où je le lance, ou encore le répertoire GNUStep de Window Maker...
En gros :
Fichiers non cachés : tes données, ton utilisation perso.
Fichiers cachés : les fichiers de configuration.
C'est propre, pratique, clair, bien pensé, c'est Unix ;-)
(Attention, un troll se cache dans la dernière phrase :-)
[^] # Re: Une fois de plus, les votes
Posté par helf (site web personnel) . Évalué à 2.
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 Anonyme . Évalué à 0.
C'est un fichier utilisé pour configurer ton shelle, non ?
> Les .xxxx ne sont pas que du stockage de config. Donc ce n'est pas
> homogène.
C'est sensé être homogène, parce que les .xxxx sont sensés être des fichiers de configuration...
> 2) quand j'ai trop de fichiers dans un repertoire, je cree des
> sous repertoires. Donc quand j'ai trop de .xxxx, je crée des
> repertoires ad'hoc.
Justement, tout l'intérêt est que tu ne les voies pas, donc pas besoin de les trier au fond. Il suffit juste de faire "cd ~/.<programmes>" quand tu en as besoin. Je me trompe peut-être, mais créer un sous-répertoire pour les fichiers de configuration ne reviendrait qu'à taper ".conf/" en plus dans la commande ci-dessus.
> Finalement, pourquoi ne pas créer un .conf, un .rc,
Un rc ? Ton environnement utilisateur est bootable ?
> un .data, un
Ça existe déjà, c'est $HOME...
> .desktops ?
Là par contre je suis d'accord, c'est de la configuration. Et je suis d'autant plus d'accord si c'est unifié et si KDE et GNOME peuvent l'utiliser de concert. Mais c'est un autre débat je crois, et je n'aime pas les bureaux :-)
[^] # Re: Une fois de plus, les votes
Posté par helf (site web personnel) . Évalué à 2.
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 Anonyme . Évalué à 1.
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 (site web personnel) . Évalué à 2.
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 (site web personnel) . Évalué à 1.
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 . Évalué à 2.
> 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 . Évalué à 1.
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 (site web personnel) . Évalué à 1.
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 (site web personnel) . Évalué à 1.
Envoyé depuis mon PDP 11/70
[^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par helf (site web personnel) . Évalué à 1.
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 Anonyme . Évalué à 1.
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 (site web personnel) . Évalué à 1.
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 . Évalué à 1.
http://linuxfr.org/comments_reply,2727,208129,5.html(...)
[^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par Anonyme . Évalué à 1.
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
Posté par huhuhu . Évalué à 1.
l'Antialiasing, pas installer kde. (Hein? Quoi? - C'est dans le fichier de conf /usr/share/lib/dev/qt3/conf/var/SuSeSaPu/qt3-conf.pouet à la ligne 1230)
# CiDepot et Files ?
Posté par Séverin Tagliante-Saracino . Évalué à 3.
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 . Évalué à 7.
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 . Évalué à 1.
Mais pourquoi diable ont-ils mis des majuscules à leur files system ?
[^] # Re: Depot et Files ?
Posté par Séverin Tagliante-Saracino . Évalué à 2.
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 (site web personnel) . Évalué à 5.
[^] # Re: Depot et Files ?
Posté par Julien Laumonier (site web personnel) . Évalué à 1.
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 . Évalué à 1.
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 Anonyme . Évalué à 1.
> espaces, c'est plus jolis.
Moi aussi, et la touche espace est plus facile à attraper que la toucher souligné.
Et comme les concepteurs de Shells furent du même avis que nous, ils ont eu la bonne idée de définir l'espace et non le souligné comme séparateur de commandes et autres options sur la ligne de commande.
;-)
[^] # Re: Depot et Files ?
Posté par Séverin Tagliante-Saracino . Évalué à 1.
[^] # Re: Depot et Files ?
Posté par Olivier Abad . Évalué à 2.
Ç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 (site web personnel) . Évalué à 1.
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 . Évalué à 1.
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 Anonyme . Évalué à 1.
> citroën -> CITROËN en canadien français
Allons bon, ce n'est qu'en canadien français qu'il faut mettre des accents aux majuscules ?
Moi qui suis tout content de cette possibilité de XFree, qui trouve ça joli et qui a pris l'habitude... :-/
Alors alors ? Verdict ?
[^] # Re: Depot et Files ?
Posté par helf (site web personnel) . Évalué à 0.
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 Anonyme . Évalué à 1.
Sinon, pour participer au troll quand même, parce que ça chatouille : avec des idées comme ça, on serait tous sous Windows, parce qu'un ordinateur est un PC, un système d'exploitation est Windows, et que la diversité c'est pas bien.
[^] # Re: Depot et Files ?
Posté par Nicolas Roard (site web personnel) . Évalué à 1.
Si on reprends de vieux manuscrits, ils ont les accents. Ne pas mettre d'accents sur les majuscules date au pifomètre de l'introduction des premières machines à écrire, d'origine anglo-saxone, et qui donc n'en disposaient pas. Mais c'est une erreur, car cela peut nuire à la compréhension, d'autant que ce n'est pas un problème de les utiliser sur les machines/OS actuels.
[^] # Re: Depot et Files ?
Posté par Anonyme . Évalué à 1.
Ok, et merci pour la réponse. D'autant plus que je trouve ça plus joli.
> d'autant que ce n'est pas un problème de les utiliser sur les
> machines/OS actuels.
Sans mauvaise blague, on peut y arriver facilement sous Windows ?
[^] # Re: Depot et Files ?
Posté par William Steve Applegate (site web personnel) . Évalué à 1.
Ça dépend de ce que tu nommes « facile ». Si je me rappelle bien :
<alt gr>+0171 pour le guillemet ouvrant [«]
<alt gr>+0187 pour le guillemet fermant [»]
<alt gr>+0192 pour le A accent grave [À]
<alt gr>+0199 pour le C cédille [Ç]
<alt gr>+0200 pour le E accent grave [È]
<alt gr>+0201 pour le E accent aigu [É]
En fait, c'est toujours <alt gr>+0<code ASCII décimal>. Tu peux obtenir le même effet sous la console Linux en te faisant une map clavier perso (voir man dumpkeys, man keymaps, etc.), et je l'ai utilisé pendant un certain temps, mais maintenant, je trouve quand même le système des séquences Compose plus naturel...
Et je confirme que c'est bien une Bonne Chose[tm] que d'utiliser ces caractères : ne vous laissez pas avoir par ce que vous a dit votre prof' de français ! Petit rappel au passage, un article pas mal sur la typo : [http://www.uzine.net/article1802.html(...)].
Envoyé depuis mon PDP 11/70
[^] # Re: Depot et Files ?
Posté par doublehp (site web personnel) . Évalué à 1.
-4 au brevet des collèges pour faute de conjugaison !
[^] # Re: Depot et Files ?
Posté par Nicolas Roard (site web personnel) . Évalué à 1.
ils sont durs quand même ..
[^] # Re: Depot et Files ?
Posté par Robert Palmer (site web personnel) . Évalué à 1.
citroën -> CITROEN en français, mais
citroën -> CITROËN en canadien français
Non, non même en français il faudrait mettre des majuscules accentuées :
http://www.langue-fr.net/d/maj_accent/maj_accent.htm(...) et la page désormais classique sur linuxfr http://academie-francaise.fr/langue/questions.html#accentuation(...)
Pensez à l'environnement avant d'imprimer ce commentaire - Please consider the environment before printing this comment
[^] # Re: CiDepot et Files ?
Posté par Emmanuel Blindauer (site web personnel) . Évalué à 3.
deja c'est pas "My Music" ou "My Program" mais ca serai plutot dans leur philosophie "Music" et "Program". ensuite la majuscule est explique aussi, il faut lire, mais de nos jours les gens preferent rabacher RTFM aux gens qui posent des questions plutot que de se demander en premiers si eux mêmes ont RTFMé. va dans un répertoire, et fait m, et regarde le nb de choix possible. fait ensuite M, et compte.
les fichiers qu'on cree comportent rarement des majuscules en premier caractère, donc en mettatn une majuscule, au nom du répertoire, ca completera plus aisément le nom.
Display all 1285 possibilities? (y or n)
[^] # Re: CiDepot et Files ?
Posté par doublehp (site web personnel) . Évalué à 1.
[^] # Re: CiDepot et Files ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 3.
# Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par Julien Duponchelle (site web personnel) . Évalué à 0.
[^] # Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par EppO (site web personnel) . Évalué à 2.
Gobolinux n'en a pas du tout cette philosophie, c'est le systeme de fichiers qui sert d'arbre de dépendances et base de données/registre en quelque sorte.
# Récapitulons.
Posté par Jar Jar Binks (site web personnel) . Évalué à 3.
Avec GoboLinux, il est impossible de mettre /usr sur une partition à part (à moins d'utiliser shadowfs et donc la hurde).
Avec GoboLinux, les données d'un même type ne sont pas dans les mêmes répertoires. Ainsi, impossible de séparer les fichiers dépendants et indépendants de l'architecture, de mettre certaines parties de /var sur des disques à part, de virer toutes les documentations d'un coup.
Avec GoboLinux, les bases de données de polices, de documentations, de plugins, et j'en oublie, deviennent un cauchemar à gérer.
Tout ça, pour avoir une gestion des dépendances moins évoluée qu'avec dpkg ou rpm. Bienvenue sous Windows. Euh, sous BogoLinux.
Au risque de me répéter, je recommande la lecture du FHS. On peut y comprendre que la structure des répertoires dans les Unix modernes n'a rien d'anarchique, et qu'elle répond à un certain nombre de besoins.
[^] # Re: Récapitulons.
Posté par Séverin Tagliante-Saracino . Évalué à 2.
Admettons que l'arborescence GoboLinux se fasse une place au soleil, ce qui n'est pas gagné, cela ne posera pas plus de problème que la co-existence de rpm et deb, et bien moins que la co-existence de KDE et de Gnome. (En effet l'arborescence classique demeure, en lien et caché). Je me doute bien que les administrateurs de grands réseaux ne vont pas changer un système de fichier qui permet des réglages fin juste pour gagner en convivialité.
Quant à moi j'en ai marre de devoir distinguer /bin, /sbin, /usr/bin, /usr/local/bin... et pareil pour les librairies et la doc. Je me fiche que l'on me reproche de vouloir rapprocher Linux de Windows et MacOS. Eux ne se gènent pas pour se rapprocher sans cesse de Unix, qu'ils le taisent ou le confessent.
Et la FAQ a achevé de me convaincre :
"Is it a newbie-oriented distribution? No, it is not. It is geared towards people who prefer to install applications from the original source packages. That is the main reason why each application gets its own directory: so you can install it from source there and then remove it with an "rm -rf". So, you see, GoboLinux is oriented at the experienced user who doesn't like things to be automagical."
Super pour avoir facilement plusieurs versions d'un même logiciel. Parceque s'il y a bien un truc que je n'aime ni sur Linux, ni sur Windows, c'est les procédures d'installation et de désinstallation : et vas-y que j'te mets des trucs bidules un peu partout. Avec les systèmes de package, soit on est super-user, soit on est super-newbies. Pas d'intermédiaire pour apprendre en douceur...
[^] # Re: Récapitulons.
Posté par Boa Treize (site web personnel) . Évalué à 1.
installpkg / upgradepkg / removepkg
Et vive /usr/local
[^] # Re: Récapitulons.
Posté par Erwan . Évalué à 1.
/usr/local/bin
/usr/local/lib
/usrl/local/share/monappli
etc.
[^] # Re: Récapitulons.
Posté par Boa Treize (site web personnel) . Évalué à 1.
Et de toutes façons pour les enlever,
# removepkg monappli
[^] # Re: Récapitulons.
Posté par Me Nut (site web personnel) . Évalué à 1.
./configure --prefix=/usr/local/stow && make && make install
cd /usr/local/stow
xstow tralala-1.5.2
désinstallation :
xstow -D tralala-1.5.2
rm -fr tralala-1.5.2
[^] # Re: Récapitulons.
Posté par Anonyme . Évalué à 1.
[^] # Re: Récapitulons.
Posté par Jar Jar Binks (site web personnel) . Évalué à 3.
Pas forcément.
Mettre /usr sur une partition séparée, c'est utile pour tout le monde.
Les bases de données qu'une arborescence intelligente permet de mettre en place, elles profitent à tout le monde. À moins que tu ne t'amuses à configurer tous les chemins de fontconfig et/ou defoma à la main...
Quant à moi j'en ai marre de devoir distinguer /bin, /sbin, /usr/bin, /usr/local/bin... et pareil pour les librairies et la doc.
Pour ça, la structure de Hurd, utilisant shadowfs pour séparer les partitions mais rendant ce processus transparent pour l'utilisateur, est à mon avis un progrès dans le bon sens. Éparpiller les fichiers n'importe où, par contre, ne l'est pas.
Le système de fichiers Unix est conçu suivant un principe simple : les fichiers d'un même type vont au même endroit. De la doc ? /usr/share/doc. Des polices ? /usr/share/fonts. Des icônes ? /usr/share/icons. Des bibliothèques partagées ? /usr/lib. Et franchement, une fois que c'est installé, qu'est-ce qu'on s'en tape que telle icône vienne de Gnome ou que telle police vient d'un bundle nommé Freefont ? L'utilisateur s'en contrefout, c'est le rôle du gestionnaire de paquets de gérer tout ça.
[^] # Re: Récapitulons.
Posté par Anonyme . Évalué à 4.
> /usr/bin, /usr/local/bin... et pareil pour les librairies et la
> doc.
Lis la documention du FHS... Avant, je raisonnais comme toi. Sa lecture m'a ouvert les yeux et m'a fait changé d'avis.
J'en aussi ai profité pour changer d'avis quand à ma position sur des choses sur lesquelles tout plein de gens se sont creusés la tête, et j'ai appris par commencer à respecter la position à laquelle ils sont arrivé, au lieu de commencer par vouloir tout remettre en cause sans savoir de quoi je parle.
On commence par rentrer dans un débat, par comprendre les arguments qui circulent, avant de vouloir participer. Ça évite d'être ridicule en avancant des idées qui ont déjà été démontées mille fois.
[^] # Re: Récapitulons.
Posté par Séverin Tagliante-Saracino . Évalué à 1.
Mais c'est pas ça qui me rendra moins (éternel) débutant...
Et tant que serais débutant, ça me soulera de voir Linux et Windows installer des petits bouts de fichiers de configuration et de librairie un peu partout. Surtout maintenant que j'ai découvert que ce n'est pas indispensable.
De plus j'ai beau connaître l'arborescence unix, dans la pratique ça m'embrouille. Et comme aucun des arguments entendu ici ne m'a convaincu que j'allai regretter l'échange (Je ne m'y attendais pas d'ailleurs, je pensais que j'avais encore dit une connerie facilement démontable), je vais être obligé de lire la doc du FHS (zzzzzzz).
Menfin sauf grosse surprise, je DL GoboLinux... on verra bien déjà si j'arrive à l'installer :-)
[^] # Re: Récapitulons.
Posté par Julien Laumonier (site web personnel) . Évalué à 2.
Certe elle répond à un certains nombres de besoins (notement des besoins réseaux). Cependant, je pense que ca ne correspond pas aux besoins de certains types d'utilisateurs. Par exemple ceux qui ne sont pas administrateur système et qui n'ont pas plein de machines en réseau chez eux. (comment ca, tous les utilisateurs de Linux ne sont pas comme ça ?)
L'inconvénient de l'arborescence FHS c'est qu'elle n'est pas toujours intuitive.
(j'ai toujours pas compris l'interet de /opt).
Et que l'on soit obligé de lire un PDF de 40 pages pour comprendre comment ca fonctionne me gene un peu. Pas pour moi mais pour les gens qui aimeraient bien se mettre a GNU/Linux mais qui ne comprennent rien à l'arborescence et qui laissent tomber.
Je pense qu'il faut trouver une nouvelle hierarchie qui propose les mêmes souplesses que FHS mais un peu plus intuitive. (non je n'ai pas la solution, désolé)
Julien
[^] # Re: Récapitulons.
Posté par Boa Treize (site web personnel) . Évalué à 2.
[^] # Re: Récapitulons.
Posté par gnumdk (site web personnel) . Évalué à 3.
[gnumdk@cassiope gnumdk]$ ls /opt
arkanae_0.6/ cube/ E16.tar.bz2 SoundStudio-1.0.3/ VD/ Xmusix/
babygimp/ e16/ e17/ phoenix/ stella/ wgm/
[gnumdk@cassiope gnumdk]$
[^] # Re: Récapitulons.
Posté par okeefe . Évalué à 1.
[^] # Re: Récapitulons.
Posté par Anonyme . Évalué à 1.
S'il veut aller plus loin, il devra commencer par admettre qu'il doit lire la documentation des personnes qui ont construit les outils qu'il veut utiliser.
[^] # Re: Récapitulons.
Posté par Anonyme . Évalué à 1.
> comment ca fonctionne me gene un peu. Pas pour moi mais pour les
> gens qui aimeraient bien se mettre a GNU/Linux mais qui ne
> comprennent rien à l'arborescence et qui laissent tomber.
Tu prends le problème à l'envers. Les personnes qui doivent lire un document, ce sont celles qui veulent participer au débat et savoir comment et pourquoi telle ou telle décision a été prise.
Les autres, ils suivent les décisions prises. S'ils veulent participer, ils doivent d'abord comprendre, et donc lire la documentation, parce que les personnes qui veulent participer au débat...
[^] # Re: Récapitulons.
Posté par Robert Palmer (site web personnel) . Évalué à 2.
De toute façon je crois qu'on se pose un peu trop de questions ici.
Pour l'utilisateur qui connait très bien Linux, la hiérarchie adoptée ne devrait pas poser de problèmes : une lecture du FHS et effectivement on sait de quoi on parle.
Pour l'utilisateur débutant ou celui qui ne veut pas comprendre comment fonctionne sa machine et ben il s'en fiche pas mal que 'frozen-bubble' soit dans /usr/bin plutôt que dans /Programs : il utilise rpmdrake ou tout autre gestionnaire de packages graphique il installe son logiciel et c'est tout.
Comme le disait quelqu'un plus haut il y a d'autres urgences pour Linux. Et puis je ne vois pas en quoi un système de dépendances basé sur des liens symboliques pourrait être aussi riche que rpm ou apt. Il n'y a qu'a voir le nombre d'options pour effectuer des requêtes avec ces outils...
Pensez à l'environnement avant d'imprimer ce commentaire - Please consider the environment before printing this comment
[^] # Re: Récapitulons.
Posté par Olivier Serve (site web personnel) . Évalué à 1.
Je comprends bien que l'arborescence proposée semble plus intuitive, mais au fond si ça doit au final générer une usine à gaz, je dis non. D'autant que l'arborescence qui gère les dépendances, je trouve ça moyen.
# Re: GoboLinux : une nouvelle hiérarchie de fichier pour votre distribution
Posté par zelyph . Évalué à 1.
Pour une distrib entière cela pourrait poser des problèmes par exemple pour les systèmes de sauvegardes (toute la config dans /etc, les logs dans /var/log c'est pratique ..) mais si le système est bien fait, il devrait gérer tout ça...
Cela dit les rpm et autres ont des scripts d'installation qui vont plus loin que la simple copie de fichier : gestion des dépendances fines, config auto des programmes, des menus kde gnome etc ..
Autre point : on pourrait voir un avantage du système de gobolinux pour faire des packages mutli-distrib mais comme les répertoires ne sont pas les même d'une distrib à l'autre c'est pas gagné (d'où la LSB).
En conclusion, la souplesse des liens symboliques peut être très utile mais ça ne règle pas forcément tous les problèmes ..
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.