Java, les outils libres et tutti quanti - Page 6

./149 > Bah la base de registres c'était une super idée à la base (de registres... haha), mais il faut avouer qu'actuellement c'est un peu un gros bordel, rien qu'au niveau du stockage des paramètres de Windows en lui-même (il n'y a qu'a regarder le système des classes de fichiers, il y a 50 manières de déclarer et associer une extension de fichiers, et aucune n'est parfaitement équivalente à une autre...).
Le pied ça serait d'avoir pour tout le système un système de paramètres comme celui utilisé par .NET: des paramètres d'application avec une valeur par défaut, et une portée utilisateur ou système entier, le tout dans un fichier xml tout propre (enfin "propre" peut-être pas mais au moins il est bien structure et c'est un format standard)

Brunni (./150) :
Par contre sur une nouvelle machine tu perdras systématiquement les paramètres. Perso ça ne me gêne pas, au contraire, mais je comprends que ce soit la merde.

Perso, ça me gonfle sévèrement, en fait que ça soit au niveau des réinstallations ou quand tu as plusieurs machines... j'aimerais bien pouvoir migrer mes préférences facilement d'une machine à l'autre, voire de faire de la synchro automatique

La meilleure solution à mon avis est bien le fichier .conf dans le répertoire de l'appli pour les paramètres propres à une application. Mais pas dans le répertoire du binaire bien sûr, plutôt %AppData%. A voir comment bien gérer l'arborescence et éviter les conflits (perso je n'aime pas les dossiers .monAppliTropPourrie dans mon dossier Home, c'est pas sa place je trouve, mais c'est une question de philosophie).

Bah il faut un dossier ~/Library avec toutes les préférences et autre données personnelles ^^ (ou je sais plus comment il s'appelle sous Windows, il existe même s'il est pas encore trop utilisé). C'est clair que les applications qui polluent la racine du $HOME, c'est

Par contre pour les paramètres partagés, alors là c'est autre chose, et la base de registres n'est pas forcément si mauvaise finalement...

bah tu as toujours le même problème en cas de réinstallation...

Brunni (./150) :
Attention, le plus souvent c'est la merde parce que les applis sont mal faites. En principe la base de registre ne devrait stocker QUE des paramètres, et elle devrait être initialisée lors du lancement de l'application. Ce n'était pas obligatoire avant Windows Vista, du coup certaines applis font un peu n'importe quoi (créent les valeurs dans la BDR à l'installation par exemple) et refusent de se lancer lorsque tu déplaces simplement leur répertoire sur une nouvelle machine.

Haha, la bonne blague : je suis précisément en train de réinstaller un logiciel qui avait été installé sous Vista (je suis sous XP) parce que la mise à jour refuse de fonctionner si la base de registre n'a pas de trace de l'installation (comme c'est un gros logiciel les mises à jours ne contiennent que les diffs par rapport à la première version). Donc le logiciel (non MS) fonctionne très bien mais l'installeur MS refuse de faire la mise à jour

Flanker (./152) :
Bah il faut un dossier ~/Library avec toutes les préférences et autre données personnelles ^^ (ou je sais plus comment il s'appelle sous Windows, il existe même s'il est pas encore trop utilisé). C'est clair que les applications qui polluent la racine du $HOME, c'est

Personnel ok, par contre comment gérer le fait que des applications peuvent avoir besoin de lire les paramètres système?
A la base, une lecture de la BDR du type LOCAL_MACHINE\System\UserInterface\... est une manière élégante de faire. Plus élégante à mon avis que d'ouvrir un fichier de configuration système et d'y chercher une info. Une autre manière de faire est à la UNIX avec des fichiers qui te "répondent" quand tu les lis, mais là ça peut aussi venir le bordel vu le nombre de paramètres.

Pollux> Oui. C'est vrai que ça ne m'est jamais arrivé ça, et c'est étonnant que rien ne soit prévu dans ce cas. C'est quand même lourd de devoir passer par l'installateur de Windows pour installer la plupart des applis, alors qu'il doit être lancé en tant qu'admin. Dans l'idéal une application devrait être un simple dossier, qui pourrait être où il veut, et les DLL pourraient être installées soit dans le dossier de celle-ci, soit dans celui du système. Mais Windows veut absolument contrôler les DLL présentes et les versionner dans ce terrible (que dis-je, horrible) dossier qu'est winsxs, du coup on a droit à cet installateur...

Brunni (./154) :
Personnel ok, par contre comment gérer le fait que des applications peuvent avoir besoin de lire les paramètres système?A la base, une lecture de la BDR du type LOCAL_MACHINE\System\UserInterface\... est une manière élégante de faire.

Tu fais un dossier All Users dans ton Documents and Settings ... un peu comme actuellement

En fait, je verrais bien uniquement les chemins principaux en base de registre, pas grand chose de plus

Pollux (./107) :
C'est surtout que l'impact d'une faille sur un téléphone est infiniment plus grave qu'une pauvre calculatrice...

Les développeurs du FreeRunner n'ont pas l'air de penser ça, eux: le firmware est libre et tu peux charger n'importe quel logiciel dessus.

Thibaut (./108) :
Au fait, pourquoi les paquets (et les logiciels au moment de l'exécution) ne peuvent pas savoir où se trouvent les différents répertoires du système sous Linux ?

Bah si, ils peuvent le savoir, c'est à ça que sert le standard FHS.

Il y a bien un symbole pour Home (~), qui permet de faire abstraction du chemin réel. Il n'y a pas de symboles pour les autres (share, bin, etc) ?

Ben non, parce qu'ils ne dépendent pas de l'utilisateur, ils sont fixés par le FHS.

Brunni (./110) :
on a une partition système (faut pas rêver le grub que t'as installé sur ton MBR te permet de booter depuis une partition, et pas depuis autre chose)

-> partition /boot, et après on peut mettre le système sur un LVM, une partition cryptée, ce qu'on veut quoi.

Bref c'est tout à fait discutable. Dans le cas de Windows, l'idéal serait un nommage un peu meilleur que C, D, E, comme par exemple sur PSP: flash0:/... pour la première partition système, ms0:/ pour la première Memory Stick, etc.

Ce serait toujours nul par rapport à une hiérarchie standard comme le FHS.

GoldenCrystal (./116) :
et encore je crois que LD_LIBRARY_PATH n'est pas utilisé par fedora (pas standard !)

C'est tout à fait standard de ne pas définir de LD_LIBRARY_PATH, c'est à ça que servent /etc/ld.so.conf et /etc/ld.so.conf.d/*. LD_LIBRARY_PATH ne sert qu'à rajouter des dossiers à rechercher temporairement pour un seul programme. (Et ce n'est pas spécifique à Fedora, c'est toi qui n'as pas compris comment fonctionne GNU/Linux.)

GoldenCrystal (./124) :
(enfin Linux et les standards hmm, une grande histoire )

L'OS qui n'a pas de standard pour la hiérarchie du système de fichiers, ce n'est pas GNU/Linux.

GoldenCrystal (./124) :
Et puis ces variables n'ont pas toujours existé, c'est assez récent d'ailleurs (spécifique à la plateforme NT dont a hérité XP si je ne me trompe pas), et les fonctions systèmes qui remplissent les mêmes rôles (SHGetKnownFolderPath ou GetWindowsDirectory par exemple) n'ont pas toujours existé non plus. En fait je crois qu'à l'époque de Windows 95 aucune fonction standard n'existait, mais c'est à partir de Win95 qu'elles ont commencé à apparaître. (C'est aussi à partir de Win95 que le système de fichiers de Windows à commencé à se structurer en fait)

et Thibaut qui nous répond:

Thibaut (./125) :
Ce qui nous fait 13 ans de retard pour Linux.

N'importe quoi, les variables pour les chemins ne servent pas sous GNU/Linux parce que ces chemins sont constants et fixés par le FHS, on ne va pas aller résoudre un problème qu'on n'a pas!

Thibaut (./140) :
Les répertoires n'ont pas l'air standard du tout... Sinon pourquoi Firefox est incapable de trouver le plugin Java IcedTea tout seul ? Il faut aller bidouiller des trucs soi-même (création de liens symboliques). Du coup, je n'ai pas de Java sur mon ordi 64 bits.

Parce que ta distribution n'a pas fait son boulot d'intégration. (Ou alors ton Firefox est-il un tarball du projet Mozilla qui s'installe dans un chemin non-standard pour éviter d'entrer en conflit avec la version de ta distribution? Si oui, c'est ça ton problème, il faut utiliser le Firefox de ta distribution!) Le chemin d'accès pour les plugins est défini par Firefox (et les autres navigateurs qui gèrent les plugins Mozilla), c'est à IcedTea de s'installer dans ce chemin (et ça marche très bien dans Fedora).

J'ai aussi entendu dire que certaines distributions installaient les logiciels dans /usr/local et d'autre dans /usr/bin.

Les premières ne sont pas conformes au FHS.

On peut aussi parler des chemins d'accès aux lecteurs amovibles. Certains sont dans /media, d'autres dans /mnt...

/mnt est obsolète.

Allez pas me dire que des variables d'environnement claires comme celles de Windows (%PROGRAMFILES%, etc) sont inutiles

Pourtant c'est exactement ce qu'on essaie de t'expliquer.

Uther (./145) :
Pour le plugin JAVA ca serait plutot a IcedTea de définir une variable $JAVA_PLUGIN_HOME pour donner son répertoire, qui pourrait être lue par firefox comme il existe un $JAVA_HOME.

N'importe quoi, c'est à IcedTea de s'installer dans le chemin réservé aux plugins Mozilla, pas à Firefox d'aller chercher IcedTea n'importe où.

Sally (./147) :
Quand je dis application, ça peut être un framework genre KDE (je ne connais pas bien, mais il utilise sûrement des variables d'environnement ^^)

Non, il utilise kde-config (KDE 3) ou kde4-config (KDE 4), tu lances kde4-config --install exe et tu sais où sont installés les binaires KDE 4 (/usr/bin/ dans un système bien fichu, cf. FHS).

mais [Firefox] ne cherche pas les plugins ailleurs que dans ce répertoire.

Euh si, au moins sous Fedora, il les cherche dans /usr/lib(64)/mozilla/plugins, et c'est là que le plugin OpenJDK/IcedTea est symlinké automatiquement par le système alternatives (qui te permet de choisir ton implémentation du plugin Java).

Brunni (./154) :
Mais Windows veut absolument contrôler les DLL présentes et les versionner dans ce terrible (que dis-je, horrible) dossier qu'est winsxs, du coup on a droit à cet installateur...

Tu perds tout l'intérêt des bibliothèques partagées si tu les fous dans le dossier de l'application. (AMHA, la meilleure solution est une gestion des dépendances automatique et transparente où les bibliothèques partagées sont téléchargées automatiquement depuis un dépôt... rappelle-moi où j'ai déjà vu ça... )

Kevin Kofler (./156) :

Pollux (./107) :
C'est surtout que l'impact d'une faille sur un téléphone est infiniment plus grave qu'une pauvre calculatrice...

Les développeurs du FreeRunner n'ont pas l'air de penser ça, eux: le firmware est libre et tu peux charger n'importe quel logiciel dessus.

Je voulais dire : une faille de sécurité. Quelqu'un qui exécute un programme Java sur son téléphone sans prendre de précautions (puisque c'est censé être sandboxé) ne doit pas se retrouver avec un rootkit qui espionne ses coups de fil...

Je doute que Microsoft décide de se débarrasser de la BDR, le sens de l'histoire serait au contraire de tout y mettre... Les dossiers, c'est bien pour mettre des données, la BDR, pour la conf. Si je ne m'abuse, c'est le choix qui a été fait pour WinCE/Mobile, où la BDR est extrêmement utilisée.

Sauf qu'elle a les défauts de ses qualités : elle devient trop lourde, est monolithique, elle n'est pas human readable quand le système n'est pas chargé, quand elle est cassée et qu'elle ne sait pas s'auto-réparer, on est face à une série de fichiers morts. C'est une boite noire qui a comme pré-requis fonctionnel que le système qui l'utilise soit fonctionnel. Dans le cas contraire, on ne peut rien en faire ou presque.
Cela dit, elle a d'autres atouts : elle est difficilement accessible par un processus nuisible (qui est obligé de passer par des requêtes systèmes, ce qui est une sécurité) ; elle peut faire l'office de transactions via un protocole réseau, ce qui permet de travailler avec les stratégies de groupe ; elle s'est vue grandement consolidée au niveau pérennité des données au fil des versions.

Ximoon (./158) :
Je doute que Microsoft décide de se débarrasser de la BDR, le sens de l'histoire serait au contraire de tout y mettre... Les dossiers, c'est bien pour mettre des données, la BDR, pour la conf. Si je ne m'abuse, c'est le choix qui a été fait pour WinCE/Mobile, où la BDR est extrêmement utilisée.

Microsoft ne l'abandonnera pas car sa poserait trop de problèmes de compatibilité mais il recommende depuis Windows XP de l'utiliser que lorsque c'est vraiment necessaire.
Le dossier Application Data peut permettre de gérer la Majorité des problèmes pour lesquel on a l'habitude d'utiliser la base de donnée tout en gardant l'avantage d'être moin fouilli et ne pas allourdir les temps d'accès au fur et à mesure.

Nil (./159) :
Sauf qu'elle a les défauts de ses qualités : elle devient trop lourde, est monolithique, elle n'est pas human readable quand le système n'est pas chargé, quand elle est cassée et qu'elle ne sait pas s'auto-réparer, on est face à une série de fichiers morts. C'est une boite noire qui a comme pré-requis fonctionnel que le système qui l'utilise soit fonctionnel. Dans le cas contraire, on ne peut rien en faire ou presque.
Cela dit, elle a d'autres atouts : elle est difficilement accessible par un processus nuisible (qui est obligé de passer par des requêtes systèmes, ce qui est une sécurité) ; elle peut faire l'office de transactions via un protocole réseau, ce qui permet de travailler avec les stratégies de groupe ; elle s'est vue grandement consolidée au niveau pérennité des données au fil des versions.

Mais que proposerais-tu pour qu'on puisse conserver ses paramètres facilement ? (tiens, ça serait cool que le fichier de bdr correspondant à current_user soit dans le $HOME, ça serait déjà ça de pris)

C'est déjà le cas, il s'appelle NTUSER.DAT et est dans ton home. Bon je l'aurais peut-être plutôt vu dans AppData\Roaming et AppData\Local mais soit. D'ailleurs on voit bien le bordel que c'est le répertoire HOME dès qu'on affiche les fichiers cachés, sans parler de tous les répertoires .quelquechose de linuxiens qu'il faut cacher à la main

[URL=http://imageshack.us][IMG]http://img254.imageshack.us/img254/4519/img03df0.png[/IMG][/URL]

Sinon comme Nil a dit c'est clair que ça a tous les défauts d'une base de données quoi (à part XML, qui reste human-readable, au prix des performances). Avoir un dossier de configuration (ou des "fichiers" écoutés par un processus à la UNIX) peut sembler meilleur à priori, mais il pose les mêmes problèmes que la BDR, en plus d'alourdir le système de fichiers (alors que sous Win ça ne pollue que la BDR, qui n'est pas utilisée en permanance à part par l'explorateur de fichiers).
Ca c'est pour le système. Par contre en tant que développeur d'applications, je suis partisan de mettre plutôt toute la configuration non-partagée dans un fichier XML dans AppData, même si la sécurité et les performances sont moins bonnes (à la limite la suppression volontaire ou la corruption de ce fichier ne poserait aucun problème, on aurait juste à avertir l'utilisateur et lui demander de reconfigurer). Ensuite pour la config à laquelle d'autres applications pourraient avoir accès, ou pour les éventuels "tweaks" que d'autres applications pourraient configurer, là autant utiliser la BDR, qui est optimisée pour ça.
(on a moins de risque de se planter en éditant la BDR avec regedit qu'un fichier de config avec VIM par exemple, et Windows versionne automatiquement la BDR donc au pire si on a tout cassé ça ne pose pas vraiment de problème)

Flanker (./161) :
Mais que proposerais-tu pour qu'on puisse conserver ses paramètres facilement ? (tiens, ça serait cool que le fichier de bdr correspondant à current_user soit dans le $HOME, ça serait déjà ça de pris)

Un dossier qui s'appellerait Config (un pour All users, un pour %CurrentUser, un pour Default User), accessible en écriture uniquement par un utilisateur système (via un service, qui peut aussi être un service réseau) dans lequel on aurait des fichiers de configuration lisible par un humain (en XML vu que c'est la mode actuelle et que les outils existent déjà pour traiter ce type d'informations). En cas de migration, on pourrait récupérer tout le dossier Config, et un utilitaire d'import permettrait de faire un rapatriement des données de façon simple, en sélectionnant ce qu'on veut récupérer ou pas.
Chaque application n'aurait droit qu'à un et un seul fichier, dont le nom serait codifié et généré par le système, au cours des premiers échanges avec l'installeur. On pourrait y retrouver les informations suivantes : {H/S}Société - Application - Version.xml (H ou S suivant s'il s'agit d'une configuration soft ou hard, mais on peut imaginer deux sous dossiers).
Ca permettrait aussi de savoir qui consomme beaucoup de place en fichiers de configuration, ça éviterait qu'une application ne s'autorise à titiller la configuration d'une autre.
Bon, c'est une idée pas trop réfléchie et qui mérite réflexion, mais voilà, quoi.

C'est un peu le système d'OS X que tu décris là, non ?

Nil (./164) :
Ca permettrait aussi de savoir qui consomme beaucoup de place en fichiers de configuration, ça éviterait qu'une application ne s'autorise à titiller la configuration d'une autre.

Titiller, ok, mais lire ça pourrait être le but justement. Avec ton système on aura beaucoup de peine.

Folco (./163) :
J'ai jamais compris cette propention qu'a Win d'appeler ses répertoires {354785418187154186718315157135154-azer5413vf4q1azr3r541qsd3f4aze16r8az3c453sv-2341234ERGTL2346HN?ear3qs8d1fqs3d48r13a8ze4r3qs5f13er78aze138r41qsc4r7az318e7r1qs5cf4qs5f13aze8tr-qsd54az138er41qs35df4qz138er4azer15qs4f}

C'est des GUID.

./165 > C'est aussi le système de configuration utilisé par les Applications .NET sous Windows

Brunni (./166) :

Nil (./164) :
Ca permettrait aussi de savoir qui consomme beaucoup de place en fichiers de configuration, ça éviterait qu'une application ne s'autorise à titiller la configuration d'une autre.

Titiller, ok, mais lire ça pourrait être le but justement. Avec ton système on aura beaucoup de peine.

Lire, non, sans aucun souci : le dossier est accessible en écriture uniquement à un utilisateur système, mais en lecture à tout le monde. On peut donc soit lire directement le XML, soit utiliser le service d'accès à la configuration (dans un cadre "propre", et c'est ce qu'il se passe à l'heure actuelle sous windows : toute lecture et écriture dans la BDD se fait à travers un service).

Ça ressemble aussi beaucoup au système sous GNU/Linux, on a /etc pour les réglages globaux qui fonctionne comme tu décris, et les réglages par utilisateur sont dans le HOME, en général dans des fichiers ou répertoires commençant par un point (= cachés), et par exemple tous les réglages par utilisateur de KDE se retrouvent dans ~/.kde (l'équivalent KDE du fameux "Application Data").

ça n'a rien à voir... Sous linux tous les fichiers de configuration utilisent une syntaxe différente, certains (fontconfig) sont en XML, d'autres (Apache) sont de mini scripts, d'autres fonctionnent comme des fichiers *.ini sous windows (cpufreqd, kdm...), certains sont de simples scripts shell, d'autres des semi-script shell, et chacun utilise sa structure de répertoire propre, c'est un gros bordel...

Toutes les configurations de KDE sont en un format INI.

Kevin Kofler (./169) :
Ça ressemble aussi beaucoup au système sous GNU/Linux, on a /etc pour les réglages globaux qui fonctionne comme tu décris, et les réglages par utilisateur sont dans le HOME, en général dans des fichiers ou répertoires commençant par un point (= cachés), et par exemple tous les réglages par utilisateur de KDE se retrouvent dans ~/.kde (l'équivalent KDE du fameux "Application Data").

Le gars qui s'incruste comme ça "Mais mon OS aussi il est bien hein"
./171> L'idéal ce serait que TOUT le système utilise la même syntaxe, et donc que la lecture et écriture soit géré par un service système.

Kevin Kofler (./169) :
Ça ressemble aussi beaucoup au système sous GNU/Linux, on a /etc pour les réglages globaux qui fonctionne comme tu décris, et les réglages par utilisateur sont dans le HOME, en général dans des fichiers ou répertoires commençant par un point (= cachés),

Et on se retrouve avec un $HOME complètement pollué par des dizaines de fichiers

Kevin Kofler (./171) :
Toutes les configurations de KDE sont en un format INI.

Linux ne se résume pas à KDE...

Flanker (./173) :
Et on se retrouve avec un $HOME complètement pollué par des dizaines de fichiers

fichiers qui sont "cachés", par défaut, avec la plupart des outils qui listent des fichiers
=> pas visibles, de base
=> pas génant

Et les logiciels KDE mettent tout dans .kde, pas directement dans HOME. Les autres, ben ils vont disparaître à terme.

Folco (./176) :
Et perso je trouve ça con de mettre des fichiers perso dans $HOME, donc je m'en fous.

c'est fait pour, pourtant ^^

Folco (./176) :
J'ai toujours mon ~ sur la partition système, donc prête sauter à la moindre réinstall.

Le problème est peut-être justement là

squale92 (./174) :

Flanker (./173) :
Et on se retrouve avec un $HOME complètement pollué par des dizaines de fichiers

fichiers qui sont "cachés", par défaut, avec la plupart des outils qui listent des fichiers
=> pas visibles, de base
=> pas génant

Si *au moins* tous ces sous dossiers étaient dans $HOME/.conf/ ou (pour faire Linux) $HOME/.etc/ ; mais là, c'est pire qu'un bordel (parce qu'il n'y a aucun plaisir).

Folco (./176) :

Flanker (./173) :
Et on se retrouve avec un $HOME complètement pollué par des dizaines de fichiers

Et perso je trouve ça con de mettre des fichiers perso dans $HOME, donc je m'en fous.

Alors ça c'est un peu une aberration La logique voudrait que tu aies une partition à part, mais qui soit montée sur /home ^^

Ah oui, effectivement... mais bon, je ne suis pas certain que ça pose tant de problèmes que ça, sauf si toi tu veux avoir des paramètres vraiment différents pour les applis de chaque distribution.