Java, les outils libres et tutti quanti - Page 5

Nan mais sur ce coup c'est vrai que Linux est décevant.

C'est déjà mieux que rien ! Peut-être que ça rendrait inutile ou plus facile l'interopérabilité des paquets entre les distributions ?
Ca me tue cette mauvaise fois des combattants du djihad Linuxien

./118 > Ah ben alors il n'y a que PATH si c'est le cas, c'est encore pire
./119 > Bah pour le coup les chemins aléatoires ça serait marrant, mais c'est vraiment naze de devoir penser à des trucs tordu (qui ralentissent le système pour rien du coup) juste pour que les gens fassent un code propre là où il faut... (cf Vista + UAC)
Surtout que ça aurait pris quoi... 10 minutes (je compte large) au début du projet pour définir quelques fonctions qui gèrent les répertoires proprement et le reste vient tout seul... Il aurait même pu y avoir une librairie pour ça ça aurait été encore mieux pour tout le monde (enfin Linux et les standards hmm, une grande histoire )
./120 > Ce ne sont pas des symboles, mais des variables d'environnement (Certes des variables spéciales, mais ça marche aussi avec %TOTO% si tu prends soin de définir TOTO avant ^^)
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)

Ce qui nous fait 13 ans de retard pour Linux.

GoldenCrystal (./124) :
./119 > Bah pour le coup les chemins aléatoires ça serait marrant, mais c'est vraiment naze de devoir penser à des trucs tordu (qui ralentissent le système pour rien du coup) juste pour que les gens fassent un code propre là où il faut... (cf Vista + UAC)

Ben je vois pas pourquoi ça serait beaucoup plus long si %windir% = j:\95137c76 au lieu de c:\windows...

Surtout que ça aurait pris quoi... 10 minutes (je compte large) au début du projet pour définir quelques fonctions qui gèrent les répertoires proprement et le reste vient tout seul... Il aurait même pu y avoir une librairie pour ça ça aurait été encore mieux pour tout le monde (enfin Linux et les standards hmm, une grande histoire )

L'important n'est pas que ça soit facile à coder, mais que ça soit facile à vérifier... sinon au moins 10% des programmes seront buggés.

./124 > LD_LIBRARY_PATH est toujours comprise, c'est juste qu'elle a une valeur par défaut (si la variable n'est pas définie il va juste chercher dans les répertoires systèmes...)

./125 > les variables d'environnement ça existe aussi sous les unix hein ($HOME en particulier est toujours défini normalement ^^)

Sally (./127) :
./125 > les variables d'environnement ça existe aussi sous les unix hein ($HOME en particulier est toujours défini normalement ^^)

Ça ne dépend pas du shell ? genre si tu lances $HOME/.local/bin/monbinaire dans un cron, il ne va pas accepter parce qu'il n'est pas dans un shell ?

Pollux (./126) :

GoldenCrystal (./124) :
./119 > Bah pour le coup les chemins aléatoires ça serait marrant, mais c'est vraiment naze de devoir penser à des trucs tordu (qui ralentissent le système pour rien du coup) juste pour que les gens fassent un code propre là où il faut... (cf Vista + UAC)

Ben je vois pas pourquoi ça serait beaucoup plus long si %windir% = j:\95137c76 au lieu de c:\windows...

Ben car pour que les répertoires soient aléatoires il faut bien les rendre aléatoires quelque part, mais je pense que par aléatoire tu voulais dire aléatoire à l'installation (c'est moche, j'aime mon C:\WINDOWS moi ), moi je pensais aléatoire pour de vrai (soit au démarrage de l'OS, soit pour chaque appli, enfin un truc lourd et solide quoi )

Surtout que ça aurait pris quoi... 10 minutes (je compte large) au début du projet pour définir quelques fonctions qui gèrent les répertoires proprement et le reste vient tout seul... Il aurait même pu y avoir une librairie pour ça ça aurait été encore mieux pour tout le monde (enfin Linux et les standards hmm, une grande histoire )

L'important n'est pas que ça soit facile à coder, mais que ça soit facile à vérifier... sinon au moins 10% des programmes seront buggés.

Oui enfin pour le coup, il te suffit de faire tourner l'appli sur un chroot spécial derrière pour t'assurer que tout fonctionne, non ? ^^

Sally : Ben on dirait que non, d'après ce que les gens disent ici. Et puis pourquoi il y a besoin de recompiler les logiciels pour chaque distribution ? Ce n'est pas entre autres à cause de la structure différente des répertoires ?

C'est aussi à cause des versions différentes des binaires, d'une part par le n° et d'autre part par les patches (qui peuvent inclure les répertoires différents éventuellement).

Ce n'est pas « il n'y a pas de variables d'environnement » mais « il n'y a pas de variables d'environnement pour certains dossiers systèmes /bin, /var, /etc, et...)

GoldenCrystal (./129) :
Ben car pour que les répertoires soient aléatoires il faut bien les rendre aléatoires quelque part, mais je pense que par aléatoire tu voulais dire aléatoire à l'installation (c'est moche, j'aime mon C:\WINDOWS moi ), moi je pensais aléatoire pour de vrai (soit au démarrage de l'OS, soit pour chaque appli, enfin un truc lourd et solide quoi )

Ca peut être au démarrage de l'OS, je vois pas le problème

Oui enfin pour le coup, il te suffit de faire tourner l'appli sur un chroot spécial derrière pour t'assurer que tout fonctionne, non ? ^^

Il "suffit", mais si ça n'est pas évident dans un test "normal" il y aura toujours 10% de programmes buggés.

./130: GoldenCrystal a cité une des principales raisons, les versions différentes des librairies.
Ca vient simplement du fait que le logiciel évolue, et aussi des facteurs humains. Comme pour répondre à tous les besoins, il faut des distros stables (utilisation professionnelle, en production, ou pour utilisateurs novices) mais 'dépassées' ET des distros qui ont la dernière techno du jour (il faut les deuxièmes pour que les premières puissent exister...), le problème de la coexistence de versions différentes des librairies se pose.

Quel besoin y a-t-il de variables d'environnement pour /bin, /var et /etc ? Ces trois-là doivent justement pouvoir être codés en dur, même sur une distro qui ne suit pas pleinement le standard dont a parlé Kevin.

Pollux (./119) :
(prendre des chemins aléatoires par exemple )

C'est déjà le cas, hein... par exemple, les données utilisateur d'Outlook Express sont dans un dossier au nom généré de façon pseudo aléatoire (je pense qu'il est calculé à partir de données + d'une graine aléatoire). Pour être sûr d'avoir le bon chemin, il faut aller se référer à la base de registre. (Ca a un défaut : c'est assez chiant quand on fait des migrations de données d'un ordinateur à l'autre et qu'on veut éviter de passer par la chiante étape de reconstruction d'un profil OE).

./132 > oui il y a des dossiers qui ont des noms standard, par conséquent il n'est pas utile d'avoir des variables d'environnement pour les désigner (genre /bin, /etc, /dev, /lib et /proc, et aussi /usr/bin et /usr/lib ; je ne suis pas sûr que /var soit codé en dur dans le système de base, enfin son contenu est moins standard que celui des autres a priori)

./128 > euh je ne crois pas que ce soit le shell, mais ça doit être le login qui fait ça, donc oui si un programme est lancé par un service et pas par un utilisateur loggé il ne doit avoir accès à cette variable que si le service s'en est occupé je présume, effectivement (bon après je crois que cron s'en occupe, mais bon ^^)

Sally (./137) :
./128 > euh je ne crois pas que ce soit le shell, mais ça doit être le login qui fait ça, donc oui si un programme est lancé par un service et pas par un utilisateur loggé il ne doit avoir accès à cette variable que si le service s'en est occupé je présume, effectivement (bon après je crois que cron s'en occupe, mais bon ^^)

De mémoire, tout n'est pas exporté dans cron, ça m'avait emmerdé y a quelques temps ^^

oui oui mais je crois que HOME l'est ^^

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.

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

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

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

Folco (./122) :

Brunni (./120) :
C'est le cas sous les OS bien pensés tels que Windows (%SystemDrive%, %SystemRoot%, %AppData%, %HomePath%, %Temp%, ...).

Et il y a tout autant de programmes Win-only qui utilisent des chemins absolus et qui sont donc bogués (j'en ai installé un pas plus tard qu'il y a deux jours).
Donc cf ./119 de Pollux, non, un paquet de vars comme ça n'est pas une solution...

En fait ça fait très longtemps que je n'en ai plus vu, je serais intéressé si tu as des exemples "récents"? (de ce millénaire au moins)

Folco (./134) :

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

T'as pas l'air de comprendre que le fait que le choix soit diffétent de celui de ms n'implique pas qu'il est mauvais...

C'est pareil des deux côtés hein. Les linuxiens aiment bien critiquer systématiquement les choix de M$ quand ils sont différents des leurs, qu'ils soient justifiés ou pas.
En l'occurence je pense qu'on peut dire plus ou moins objectivement que le fait de coder en dur l'arborescence n'est pas une très bonne chose, et que d'avoir des variables d'environnement claires n'est pas un mal

Nil (./136) :

Pollux (./119) :
(prendre des chemins aléatoires par exemple )

C'est déjà le cas, hein... par exemple, les données utilisateur d'Outlook Express sont dans un dossier au nom généré de façon pseudo aléatoire (je pense qu'il est calculé à partir de données + d'une graine aléatoire). Pour être sûr d'avoir le bon chemin, il faut aller se référer à la base de registre. (Ca a un défaut : c'est assez chiant quand on fait des migrations de données d'un ordinateur à l'autre et qu'on veut éviter de passer par la chiante étape de reconstruction d'un profil OE).

Firefox/Thunderbird aussi ^^ Mais c'est pas pour des raisons de fiabilité, je crois que c'est plutôt pour éviter qu'une éventuelle faille qui permette d'accéder à file:// puisse récupérer file://c:/Users/Nil/Firefox/default/topsecret.dat...

Pollux (./142) :
Firefox/Thunderbird aussi ^^

A ceci près que ça n'est pas accessible depuis une fonctionnalité de l'OS (la base de registre, où on retrouve aussi les variables d'environnement plus globales) (donc que c'est moins bien intégré, mais que c'est sacrément plus pratique pour les migrations de comptes )

je crois que c'est plutôt pour éviter qu'une éventuelle faille qui permette d'accéder à [...]

Oui, c'est plus probable.

Nil (./143) :

Pollux (./142) :
Firefox/Thunderbird aussi ^^

A ceci près que ça n'est pas accessible depuis une fonctionnalité de l'OS (la base de registre, où on retrouve aussi les variables d'environnement plus globales) (donc que c'est moins bien intégré, mais que c'est sacrément plus pratique pour les migrations de comptes )

La BDR, LE truc qu'il faudrait virer de windows...

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.

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

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

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

Dans ce cas la les variables ne changent pas le problème . En effet certains exécutables sont installés dans /bin , /sbin, /local/bin ou même parfois dans /opt/bin.
Lequel de ces repertoires devrait indiquer la variable d'environement $PROGRAMFILES ?

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.

Thibaut > j'ai dit IL Y A DES répertoires qui ont des noms standards, et par conséquent il n'est pas utile d'avoir des variables d'environnement pour LES désigner. Tous les répertoires que j'ai cités sont standard. Pour d'autres répertoires il y a des variables d'environnement standard (HOME) comme sous windows.

Pour d'autres encore il n'y a rien, ou plus exactement chaque application fait un peu ce qu'elle veut (a ses propres variables d'environnement si elle est bien faite, code en dur les chemins lors de la compilation si elle est moins bien faite, contient des chemins codés en dur qui ne sont même pas changeables par des options de compilation si elle est vraiment très mal faite). 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 ^^)

Sinon firefox n'est particulièrement pas bien intégré au système, il s'installe dans un répertoire que tu peux mettre n'importe où et où il y a tout (ce qui n'est pas forcément mal en soi, ça a le mérite d'être facile à désinstaller notamment, et tu peux toujours faire un lien vers le binaire dans /usr/bin pour y avoir accès normalement) mais il ne cherche pas les plugins ailleurs que dans ce répertoire.
Du coup pour installer un plugin indépendamment c'est chiant : l'endroit où il faut mettre le fichier dépend où est installé firefox :-\

Flanker (./144) :
La BDR, LE truc qu'il faudrait virer de windows...

Réorganiser, épurer, alléger, oui, c'est clair. Virer, je ne pense pas. Mais c'est devenu tellement gros que c'est insupportable.

Nil (./148) :

Flanker (./144) :
La BDR, LE truc qu'il faudrait virer de windows...

Réorganiser, épurer, alléger, oui, c'est clair. Virer, je ne pense pas. Mais c'est devenu tellement gros que c'est insupportable.

Bah honnêtement, c'est tellement la merde quand tu veux réinstaller un Windows à cause de ça...

Elle ne devrait contenir que les variables d'environnement, pour pouvoir les changer facilement, mais là, c'est franchement inutilisable

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.
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. 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).
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...