Humeur : Mosfet : Rage against the File System Standard
Posté par rouge13 (). Modéré le 22 novembre 2001.
Il soulève l'impossibilité de facto de maintenir son installation sans passer par les outils de paquetage.
![[en]](../images/en.png)
> Lire la dépêche (120 commentaires, moyenne: 4).
Vous avez demandé le commentaire #80603.
Run by 
Cette page a été générée par Templeet en 0.1544s (dont 0.0153 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
[+] je comprend pas non plus
c clair j ai aussi commencé sous redhat (5.2)et j ai jamais compris pourquoi tout ce mettais dans /usr ? ou sinon au moins cré une arborescence corcecte la dessous ; un repertoire pour X et tout c composant , un autre pour les lib , un /bin , un local , mais stop ; linux est pas simple (fo bien le reconnaitre ) mais simplifié l arorescence permettrais de simplifier l installation de tout autres logiciels . faut reconnaitre qu un /program file ca pourrais etre pratique non ?
La transparence et la clarté ne sont ils pas les mettre mots de linux ?
[^]Re: je comprend pas non plus
je n'ai pas bien compris ce que tu reproche a cette arborescence... le coup du programme files est le pire exemple que tu puisse trouver, a ce compte tout le pourrais faire un mkdir /opt/truc et tout mettre dedans.
Je n'ai pas lu moosfet, mais je trouve que l'arborescence est tres bien. /usr pour le system et ses amis, /usr/local pour les truc systeme moins important ou en test, /opt pour les appli genre gnome, mozilla, les jeux...
Le gros probleme c'est que cette arborescence est trop bien pense, on tombe souvent sur des cas ambigue,ou bien on oublie qu'il y a deja un repertoire pour ca. De plus tu as la possibilite de jongler avec plusieur disque dur, ce qui est vraiment sympa...
En plus il y a pas mal de doc sur l'organisation des repertoires...
^d^c
[^]Re: je comprend pas non plus
Je n'ai pas lu moosfet, mais je trouve que l'arborescence est tres bien. /usr pour le system et ses amis, /usr/local pour les truc systeme moins important ou en test, /opt pour les appli genre gnome, mozilla, les jeux...
Tu devrais lire le texte, car c'est justement un des reproche. Redhat (et les autres) mettent dans /usr gnome KDE, mozilla, etc ... alors que pour lui (et pour toi), c'est des programmes qui doivent aller dans /opt/
[^]Re: je comprend pas non plus
pour commencer, mosfet est une nana donc c'est 'elle' et pas 'lui' ;o)
Il ne faut pas croire que d'après mosfet toute application devrait avoir son répertoire (on se retrouverai avec 500 fichiers et 1000 sous-répertoires c'est pas beaucoup mieux que 2000 fichiers). Sa réflection, c'est que toute application *importante* comme gnome, kde, mozilla, openoffice... soit dans une sous-arborescence à part. ex: toutes les applis gnome (y compris gnome lui-même) dans usr/X11R6/gnome, avec un sous-répertoire lib pour gnome-lib, gnomeui, ...
En fait ce qu'il faudrait faire, c'est recréer l'ensemble de répertoires usr-lib-include-etc-... pour chaque projet important (je re-cite: x, gnome, kde, mozilla...)Vous remarquerez que c'est déjà le cas pour x... justement parce que X était standard avant l'arrivée des red hat et autres qui ont imposé de facto une arborescence simpliste des fichiers sous linux...
[^]Re: je comprend pas non plus
Euh justement non... Mosfet n'est pas une femme.
regarde ça : http://www.mandrakesoft.com/company/community/projects#kde(...)
tu verras son nom entre parenthèses... C'est pas celui d'une femme... :)
[+] [^]Re: je comprend pas non plus
> Mosfet n'est pas une femme.
Ah tiens ? Alors l'opération à très bien réussi.
Elle ressemble sacrément à une femme, goth, mais une femme quand même.
http://mosfet.org/about.html(...)
Bon, -1 parce que vie privée et sans intérêt.
[+] [^]Re: je comprend pas non plus
arg, je m'ai fais eu par des rumeurs :)
fabien ! a quand le cancel de posts ?
[+] [^]Re: je comprend pas non plus
Euh vaut mieux pas, parce que sinon je trolle un gros coup(*), et dès qu'il commence à y avoir des réponses, je me cancel...
(*)c'est normal que mosfet grogne sur le LFS, car il utilise une distrib de merde. Si il utilisait une vraie distrib comme debian, il n'aurait pas eu à ce poser ce genre de questions.
[^]Re: je comprend pas non plus
c'est normal que mosfet grogne sur le LFS, car il utilise une distrib de merde. Si il utilisait une vraie distrib comme debian, il n'aurait pas eu à ce poser ce genre de questions.
Non dans la Debian (pour la potato que j'utlise) tout est stocké dans /usr !!!
Je n'ai par exemple dans /usr/local que ce que j'ai compilé et /opt n'existe pas !!! De ce point de vue, la slackware est mieux foutue à mon goût.
[+] [^]Re: je comprend pas non plus
<gala>
Cette photo là est plus à son avantage :
http://www.kde.org/gallery/index.html#mosfet(...)
</gala>
-1
[^]Re: je comprend pas non plus
Plus que le terme application, je pense que c'est le terme sous-ensemble qu'il faut mieux utiliser dans sa proposition.
Dans un unix, on a un premier sous ensemble, qui permet de booter le système et de le réparer en cas de catastrophe. C'est dans /
Ensuite, on a un premier niveau qui est l'utilisation au niveau shell (pas de X encore). c'est /usr qui nous permet de faire ça.
Maintenant, au dessus du shell, on a X, qui va nous permettre de génrer nos fenêtres. et hop, /usr/X11
Ensuite, l'environnement de travail (KDE, gnome ou GNUStep), ca va dans /usr/X11/[gnome|KDE|GNUStep]
On remarquera que chaque nouvelle couche est au dessus de la précédente, et donc est dans un de ses sous répertoire.
Il y a de l'idée finalement.
[+] [^]Re: je comprend pas non plus
pour commencer, mosfet est une nana donc c'est 'elle' et pas 'lui' ;o)
non non, c'est bien 'lui' et pas 'elle', il a les cheveux longs, mais c'est bien un mec il me semble...
[^]Re: je comprend pas non plus
pour commencer, mosfet est une nana donc c'est 'elle' et pas 'lui' ;o)
Décidement cette rumeur à la vie dure, c'est bien un mec malgré les apparences, même si il joue sur cette ambiguité (ya qu'a voir la perruque verte).
Sinon, c'est une des voie à explorer pour l'arborescence que tu suggère. J'ai l'impression que Linux souffre de plus en plus de l'héritage d'Unix (le dinosaure des OS).
Linux n'est pas Unix, définitivement, réorganiser l'arborescence pour clarifier tout ça ne serait pas un luxe pour un système moderne.
[^]Re: je comprend pas non plus
le prob c'est plus l'héritage redhat que unix..
[^]Re: je comprend pas non plus
Tout a fait.
Sun avait mis Openview ds un répertoire spécial, et qd CDE est devenu le "bureau" par défaut, il a eu droit aussi a son répertoire bien à lui.
L'héritage Unix a disparu.
KDE et Gnome auraient mérité un rep à eux. La seule question a se poser est la place de Qt/gtk dans ce schéma (et encore...).
[^]Re: je comprend pas non plus
hmmm... ca devait etre openwin, pas openview :).
mea culpa.
[^]Re: je comprend pas non plus
On peut aussi dire que c'est l'héritage Unix qui a incité à faire des répertoires différents, puisque c'était le cas pour X11.
Mais pourquoi ne pas mettre tout le système dans /usr, en particulier X11 comme le reste, sans sous-répertoire particulier ? Evidemment usr/X11/ c'est devenu le standard...
Je verrais plutot le /usr pour le systeme (ie dans les distrib GNU/Linux, tout ce qui s'installe par des paquets), et usr/local pour les installations perso qui ne passent pas par le système de paquets. Parce que si on commence à prévoir un répertoire Gnome, KDE, Qt, on ne trouvera jamais de limite franche entre ce qui doit avoir son répertoire et ce qui doit aller dans /usr. Mozilla par exemple, pourquoi lui donner un répertoire ? Certains le préconisent, mais je ne vois pas trop pourquoi ?
[^]Re: je comprend pas non plus
je me souviens que les 1ere version de KDE le script d'install (apres compil) installé les fichiers dans /opt/kde/ (bin/lib/etc..)
le tout à été changé pour la compatibilité redhat ..
[^]Re: je comprend pas non plus
Ben en fait, le problème n'est pas vraiment la limite franche, c'est plutôt d'être obligé d'installer/désinstaller des trucs avec le gestionnaire de paquetage, parce qu'on est incapable de dire ce qui sert à une appli quand tout est mélangé dans /usr...
Si tu as /usr/X11/KDE par exemple, tu as la possibilité de recenser tous les binaires par exemple pour faire des liens dans ton interface graphique et regrouper tous les trucs KDE dans un menu... (je dis n'importe quoi). Et puis tu peux aussi tout désinstaller simplement en effaçant le dossier. Hormis le fait que ce soit dangereux pour, c'est quand même bien pratique non ?
[^]Re: je comprend pas non plus
c'est plutôt d'être obligé d'installer/désinstaller des trucs avec le gestionnaire de paquetage, parce qu'on est incapable de dire ce qui sert à une appli quand tout est mélangé dans /usr...
En fait je pensais plus à un très bon gestionnaire de paquetage, par lequel tu passes pour récupérer ces infos. Je crois que ça existe déja, avec apt-get ou rpm, la possibilité de savoir quel fichier vient de quel package, non ? Ensuite il faut traiter l'info, c'est sur, mais c'était plutot ça l'idée...
Si tu as /usr/X11/KDE par exemple, tu as la possibilité de recenser tous les binaires par exemple pour faire des liens dans ton interface graphique et regrouper tous les trucs KDE dans un menu... (je dis n'importe quoi).
Eh bien le cas idéal serait donc non pas de lire l'info simplement par lecture du répertoire, mais par un "apt-machin kde --binaries" qui serait équivalent à ton "ls /usr/X11/KDE/bin" par exemple.
Et puis tu peux aussi tout désinstaller simplement en effaçant le dossier. Hormis le fait que ce soit dangereux pour, c'est quand même bien pratique non ?
Idem. Il faudrait pouvoir tracer l'installation de dépendances, et déterminer ou non s'il faut les supprimer (une par une) lorsqu'on désinstalle le package qui les a réclamées à l'install.
Evidemment, cet outil idéal n'existe pas encore. Mais on voit ce qu'on y gagne à l'installation, les gestion automatisée des dépendances c'est bien appréciable. Donc je préférerais voir le FHS avec moins de /opt et autres, pour inciter à l'amélioration des gestionnaires de packages. En attendant, évidemment, un répertoire et du rm -f c'est plus simple...
[^]Re: je comprend pas non plus
En fait je pensais plus à un très bon gestionnaire de paquetage, par lequel tu passes pour récupérer ces infos. Je crois que ça existe déja, avec apt-get ou rpm, la possibilité de savoir quel fichier vient de quel package, non ? Ensuite il faut traiter l'info, c'est sur, mais c'était plutot ça l'idée...
avec urpmi(i)(f)(e)(q)(...) et rpm ca marche en effet
rpm -ql nom_du_package te sort les fichiers
urpmf nom du fichier te sort tous les paquetages
ou ce nom est contenu.
Idem. Il faudrait pouvoir tracer l'installation de dépendances, et déterminer ou non s'il faut les supprimer (une par une) lorsqu'on désinstalle le package qui les a réclamées à l'install.
rpm -q --requires nom_de_ton_truc te sort
les dependances
Entres autres choses urpm(X) gere les dependances
de packages
[^]Re: je comprend pas non plus
Entres autres choses urpm(X) gere les dependances de packages
Oui, mais je ne parle pas de ça, mais de la trace des installations de dépendance, et le "pourquoi" de ces installations.
J'ai précisé ça dans un autre post plus bas (exemple avec Gimp et GTK)
[^]Re: je comprend pas non plus
Oui mais pourquoi ne pas avoir des bons gestionnaires de paquetages qui installent les fichiers dans des dossiers/sous-dossiers plus hiérarchisés ? Je pense que c'est cela qu'il veut dire le Mosfet : pourquoi parce qu'on utilise un super (parfait même) gestionnaire de paquetage ne peut-on pas installer proprement nos logiciels ?
Et là j'avoue que je suis d'accord avec lui. Ce n'est pas parce que l'arborescence sera mieux que je n'utiliserai plus RPM ou APT, là n'est pas le problème. Le problème c'est qu'on se sert de ces outils comme prétextes pour ne rien ranger...
[+] [^]Re: je comprend pas non plus
bon alors ... moi je dis mosfet est un garçille
voila voila !
[+] [^]Si quelqu'un ...
... a une technique pour déterminer le sexe de ma coccimule visible ici :
http://kadreg.free.fr/perso/coccilimule.jpg(...)
Je suis preneur. Pourtant, elle a pas les cheveux long.
[+] [^]Re: Si quelqu'un ...
est-ce qu'elle a tendance à venir se frotter énergiquement sur ta jambe ? ça pourrait être un indice :)
(hop, +1 parce que je le vaut bien)
[^]Reorganisation
Je suis completement pour une reorgasiation et c'est bien une des raisons pour lesquelles je fait tourner un linux from scratch depuis presque un an.
Ca a l'avantage ne rien installer ou cela ne doit pas ^etre. Et si je veux mettre mon vim dans /usr/local/bin also je le fait....
Mais je veux dire reorganisation c'est cool, mais il faut que les gens s'y tiennent, et les distributions aussi
Nothing's impossible... Everything's relative!
[^]Re: je comprend pas non plus
non, Mosfet n'est pas une femme, mais bel et bien mec (son vrai nom est Daniel M. Dudley)
bon d'accord c'est pas evident quand tu le voit pour la premiere fois ;-)
http://www.chaussin.org | http://www.asni.fr
[+] [^]Re: je comprend pas non plus
Sans repeter pour la douzieme fois :
non, Mosfet n'est pas une femme, mais bel et bien mec (son vrai nom est Daniel M. Dudley)
bon d'accord c'est pas evident quand tu le voit pour la premiere fois ;-)
moi aussi je veut des XP
[^]Re: je comprend pas non plus
Et merde... oui, c'est bien un mec!
Pour en revenir à la hiérarchie: Le seul intérêt je trouve à tout mettre dans /usr, /usr/local ou /opt, c'est la simplification du PATH, qui est relativement chiant à gérer, et qu'il faudrait changer à chaque modif. Cela dit, ce serait pas très difficile à faire, après tout les distrib gèrent bien les /etc/rc?.d alors pourquoi pas /etc/path...
Surtout qu'il y aurait un moyen très simple de contourner le problème: tout programme installé dans son répertoire a un lien symbolique créé dans /usr ou /usr/X, ce qui permet de s'affranchir de modifier PATH.
Ce qu'il faudrait à tout prix éviter c'est le réflexe inverse: chaque application a son répertoire (technique à la "program files"). C'est horrible à gérer. SA PU LE PATé
Le mieux, ce serait que chaque "grosse" appli (grosse restant à définir...)) s'installe dans le répertoire du sous-système auquel elle appartient: système de base (/), système (/usr), X (/usr/X), desktop (/usr/X/mondesktop), sgbd (/usr/oracle), bloatware (/usr/X/mozilla), serveur web avec ses innombrables modules (/usr/httpd)
Mais il se pose toujours des pb supplémentaires: ex du programme d'admin graphique d'oracle (/usr/oracle ou /usr/X ?) ou du programme bateau avec des plug-ins gtk ET qt (licq par exemple, ou les dock-apps multi-wm) Dans ce cas, le plus pratique c'est toujours le plus grand dénominateur commun (ex de licq qu'on pourrait coller dans /usr/X/kde ou /usr/X/gnome -> hop dans /usr/X)
[^]Re: je comprend pas non plus
bah pour mozilla ca existe deja mais d une autre facon (sur une mandrake en tout cas )
t as pratiquement tout dans /usr/lib/mozilla
y a juste le script mozilla dans /usr/bin
et dans /usr/lib les librairies que d autres programmes utilisent ( genre galeon )
pareil pour staroffice , wine , netscape ...les gros trucs quoi.
[^]Re: je comprend pas non plus
personellement j'utilise un lfs et pour pas crader mon systeme a chaque recompilation je colle tout ce qui est pas indispensable dans opt, dans mon path j'ai ajoute /opt/bin et j'ai mis /opt/lib dans /etc/ls.so.conf. je fais des liens symboliques si besoin est et tout se passe tres bien lorsque je veux viere une aplis je'efface son repertoire dans /opt et j'enleve le liens. Pour les debutants des outils comme SYMLINK permettent de gerer ca facilement
je crois que c'est la solution la plus simple
et puis pour reparler des origines d'unix /usr contenait a la base les fichiers utilisateurs comme le nom l'indique comme quoi red hat a pas eu grand mal a prendre ca pour un depotoire (heritage ? :) )...
[^]Re: je comprend pas non plus
Ah non, viens pas nous mettre 1500 liens symboliques dans /usr
Etpour le path, ya un truc comme /etc/profile dans lequel on peut definier export PATH=$PATH:/usr/local/bla:/opt/bla....
et tout marche au mieu
Nothing's impossible... Everything's relative!
[^]Re: je comprend pas non plus
En fait ce qu'il faudrait faire, c'est recréer l'ensemble de répertoires usr-lib-include-etc-... pour chaque projet important (je re-cite: x, gnome, kde, mozilla...)Vous remarquerez que c'est déjà le cas pour x... justement parce que X était standard avant l'arrivée des red hat et autres qui ont imposé de facto une arborescence simpliste des fichiers sous linux...
En fait il y a deux approches, soit on crée un répertoire par "projet" et on met dedans un repertoire pour les libs, un pour les headers, un pour les programmes, un pour les docs, ...
Soit un cré un repertoire pour les libs (/usr/lib) avec un sous répertoire pour les différents projets (/usr/lib/gnome-libs), un répertoire pour les donnée (/usr/share/gnome), un répertoire pour les doc (/usr/doc/) et puis quelques répertoires pour les programmes (/usr/bin /usr/X11R6/bin /usr/local/bin ) pour mettre les programmes histoire de pas avoir un PATH trop long.
Il y a différents moyens de séparer les choses, l'orientation qui a été prise par RedHat en vaut bien une autre. Après c'est une question de goùt mais surtout d'habitude.
[^]Re: je comprend pas non plus
Disons que je partage en partie son point de vue. La localisation de progs dans ces répertoires est plus ou moins justifié pour les binaires car cela permet de les appeler depuis la ligne de commande facilement grâce au path. En revanche, les ressources de ces applications peuvent se trouver ailleurs dans des répertoires eux, bien spécifiques... C'est un peu ce qui se fait avec le répertoire /usr/share, mais il faut reconnaître que c'est un peu le bordel... un peu plus d'organisation ne serait pas pour nuire, c'est clair.
Ce que je reproche le plus aux packages (ceci dit, je ne connais pas toutes leurs fonctionnalités), c'est l'impossibilité de les installer pour un utilisateur lambda par le système de packages...
Le prob venant alors des versions multiples installées sur un même système du même programme plusieurs fois... évidemment. Mais il doit sans doute exister une parade à cela (un package installé par deux users pourrait partager les mêmes ressources par ex...)
Enfin, c'est déjà un tel bordel... ce ne sera sans doute jamais le cas : qu'on standardise déjà l'arborescence entre les différentes distribs, ce sera déjà un plus (je sais, c'est en cours)
[^]Re: je comprend pas non plus
Ce que je reproche le plus aux packages (ceci dit, je ne connais pas toutes leurs fonctionnalités), c'est l'impossibilité de les installer pour un utilisateur lambda par le système de packages...
Je ne veux pas dire de conneries, mais il me semble que ça doit être possible (mais sûrement pas de façon simple) avec apt. En effet, il peut être lancé par l'utilisateur, et reconfiguré de tout partout.
[^]Re: je comprend pas non plus
La transparence et la clarté sont aussi les maîtres mots de la grammaire, de l'orthographe et de la précision de la pensée.
Comme premier message dans une discussion, pour dégoûter le lecteur de continuer, il n'y a guère mieux...
[^]Re: je comprend pas non plus
Sur ce coup l`a.... Bing plein le chignon ;-)
Nothing's impossible... Everything's relative!
[+] [^]Re: je comprend pas non plus [le retour]
ce que je voulais dire par un repertoire program files , c est que le novice , tout comme l utilisateur un epu plus avancé (les gourous s en moquent je pense) vois ds tout c sous repertoires un "gros bordel" ; je sais bien que c un travers de windows zien , mais j aime avec une racine en windows avec winnt / prog file / et un repertoire de travail . je diférencie ainsi tres bien le system des appli et des documents . Bien sur sur un serveur on s en fou ; mais pourune workstation .... C d ailleur un gros prob pour ceux qui veuillent essayer ou passer sous linux : l arborescence est repoussante . Je ne suis pas assez fort pour repondre aux problemes technique que ca engendrerais (je parle du path de grde taille ) mais peut etre qu une bonne idée sserais la suivante :
un repertoir de commande system ; un repertoire de conf ( I LoVe /Etc ) idem pour var ; et un repertoire /usr , mais celui ci correctement ordonnancé : exemple de X11 ca c bien . pourkoi pas faire pareil et ranger ds /usr/X11R6/wm/gnome(kde , windowsmaker) les windows manager ET tout leur fichiers img ; combien de tps perdu a cherche tel ou tel image .
Plus serieusement , il me semble qu une news est passé sur un organisme qui essaye de standardisé les distrib linux , si qqu un retrouve cette newnews , ca serai cool de la faire defiler , histoire de voir ou ils en sont de leur reflexion
See u Soon ,
++++++++++++++++++
rm -d -force -extremforce -gotodirectpoubelle /bill\ gates
[^]Re: je comprend pas non plus [le retour]
Sur windows, t'as une arborescence a la /opt, c'est-a-dire que dans program files, t'as un repertoire par appli. C'est bien je pense.
Mais ca a un enorme inconvenient: la mise a jour de la variable ${PATH} ainsi que celle des repertoires de libs (ld.so.conf ou ${LD_LIBRARY_PATH}).
Je suis plutot pour des groupes d'applications. Un groupe admin (dans /sbin), un groupe de commandes de base (dans /usr), un groupe de commande X de base (dans /usr/X11). Puis pour le bureau, un repertoire pour gnome|kde|autre. Et enfin, un repertoire a applis diverses.
Quand une machine est dediee a une tache, on peut aussi creer un repertoire specifique a cette tache. Ainsi, on pourra trouver un repertoire apache+postgresql+php et un autre repertoire de documents (htdocs, cvs...)
Apres, et pour en revenir a windows, tous les utilisateurs accedent aux programmes via le menu demarrer. Sur mon gnome, le menu est bien fait et complet: je passe souvent par la quand je ne developpe pas.
Et pour les adeptes de la commande en ligne (j'en suis, malgre les apparences), rien n'empeche de maintenir la variable PATH a jour.
Windows n'a pas que du mauvais, il faut savoir s'en inspirer des fois. Mais il ne faut pas copier, car en copiant, on copie le truc bien et une dizaine de trucs pas bien sans s'en apercevoir. Faut comprendre ce dont on s'inspire.
Le bonjour chez vous,
Yves
[^]C'est vrai que windows est pas mal, si si :
que pensez vous du "menu démarrer" de windows, il affiche simplement le contenu d'un répertoire avec des liens vers les éxécutables.
Si on avait ça sous linux, on aurait les mêmes menus dans kde, gnome, windowmaker, twm, etc...
Et on aurait pas besoin de mettre à jour tous les menus quand on utilise plusieurs gestionnaires de fenêtres.
et je parle pas de la profondeur des menus quand on accède aux menus gnome depuis kde et vice-versa.
et aussi moi je me sers principalement de windowmaker, et pas un rpm sur les redhat ne met à jour les menus.
J'ai dis une connerie ou d'autres ici sont d'accord (ou presque).
[^]Re: C'est vrai que windows est pas mal, si si :
Bin, sous la derniere mandrake, j'ai les memes menus partout... Y'a un programme pour les éditer (menudrake), ca rend le tout pas trop compliqué. Bon, j'avoue, je m'en sers jamais, mais ca a le mérite d'exister ;)
[^]Re: C'est vrai que windows est pas mal, si si :
Je ne sais pas si tu dis une conn...
...mais sur le plan pratique, je suis bien d'accord ! Je ne vois aucune bonne raison pour maintenir plusieurs arborescences différentes pour les différents systèmes graphiques.
Ceci dit, le pb discuté relève plus de l'héritage (et l'utilisation) de la ligne de commande, qui doit pouvoir trouver 'tous' les executables facilement.
Mais dire que la seule solution, c'est d'avoir tous les binaires dans le me^me répertoire, ne me parait pas crédible, c'est effectivement de la facilité.
Plus haut, on dit qu'u répertoire par apps, c'est horrible, mais au moins ça a le mérite de la clarté !
[^]Re: C'est vrai que windows est pas mal, si si :
Tu ne vas pas me dire que la vue du contenu de c:/program files/ d'un systeme windows non formate depuis 6 mois te fais chaud au coeur. Avec 46 repertoires et 38 sous-repertoires...
Et pour etre honnete, le monsieur martin utilisation standard, il s'en moque ou se trouvent ses programmes, et si c'est le bordel dans le systeme de fichiers. Tant que ca tourne, tout va bien pour lui et d'un cote il a raison.
Ya que nous, les admins et les bidoulleurs qu'on s'enerve sur ces choses la.
Je ne vois pas de difference entre le type qui sous windows lance son install.exe et fait suivant, accepter la license, instalation standard, repertoire standard, suivant, copie de fichier, reboot.
et rpm -i bla.rpm && bla
La seule diff c'est qu'il n'y a pas de reboot et moins de clicks se souris. En installant un rpm (ou un deb) on ne se fait pas de soucis du repertoire ou cela va se trouver.
Il n'y a que lorsqu'on compile la soupe soit meme, qu'on y reflechit deux fois
Nothing's impossible... Everything's relative!
[+] [^]Re: C'est vrai que windows est pas mal, si si :
et pas un rpm sur les redhat ne met à jour les menus.
Installe une deb.
[+] [^]Re: C'est vrai que windows est pas mal, si si :
installe une deb
je vais répondre quand même :
je te merde ! ;o)
[^]Re: C'est vrai que windows est pas mal, si si :
installe une mandrake.
elle utilise le système de menus unifié de la debian et update-menus met les menus à jours ( rpm -mdk of course ).
[^]Re: C'est vrai que windows est pas mal, si si :
Le même principe existe sur MacOs (classic) où le menu Pomme correspond à un répertoire avec des racourcis. Les programmes sont stockés dans leur sous-répertoire dans Applications. Pour désinstaller un programme sous Mac, tu jettes le sous-répertoire de l'applicatif.
Je crois qu'il ont gardé la même idée pour MacOsX.
Comme ce dernier est basé sur un noyau Mach (*BSD), y'a de la graîne à prendre.
Simplification de l'organigramme, uniformisation des menus d'applications.
Bientot une distrib linuxfr ????
non pas la tête.
Aïe (bobo!)
[^]Re: C'est vrai que windows est pas mal, si si :
Le probleme est que kde et gnome gerent l internationalisation par default.
Les deux desktops utilisent pour les "raccourcis" ou les menus non pas des liens mais des toto.desktop (pour une application toto)
dans ce .desktop est contenu le chemin de l application , le nom qui apparait dans toutes les langues , des variables , s il doit s executer dans un terminal , des icones associées ( 16 , 256 et 16M de couleurs)...