Linux? - Page 9

ça doit faire un an déjà (si ce n'est plus) qu'on avait parlé de ça, et mon avis reste le même.
C'est une pratique dégueulasse et qui incite grandement à faire des programmes buggués et non portables... Et pas plus transportables... Bref, de l'open-source quoi. De loin ça a l'air beau et intéressant, mais faut surtout pas chercher à y regarder de plus près.

le plus gros problème rencontré avec ça reste les distributions de GCC. Si tu fais pas des cheats de ouf, t'as intéret à installer un GCC dans le dossier ou tu l'as compilé, sinon il marche plus

Kochise (./239) :
Marrant, sous Windows y'a les clés de registre qui permettent de configurer les chemins propres aux applications (à défaut y'a aussi des variables système) Linux supérieur en tout ? Nope...

Ça ne résout pas du tout le problème, ça, ça règle juste le chemin des DLLs, bref ça remplace les rpaths, mais on peut aussi éditer les rpaths dans un exécutable déjà compilé. Mais un logiciel GNU/Linux a beaucoup plus d'objets à trouver que les .so! Il y a les traductions, les icônes, les fichiers représentant l'interface (qui sont dans certains cas chargés dynamiquement, cf. par exemple GtkBuilder), parfois des plugins (soit compilés, soit des scripts en Python, JavaScript, Scheme etc.) etc.

Et comme déjà dit, on n'a pas besoin de pouvoir déplacer un logiciel (si on l'installe en tant qu'admin comme prévu) parce que l'arborescence est standardisée.

squalyl (./242) :
Si tu fais pas des cheats de ouf

Comme les fait TIGCC d'ailleurs, surtout pour la version MinGW. (Sous GNU/Linux, ça ne dérange pas trop, les préfixes codés en dur.)

Kevin Kofler (./243) :

Kochise (./239) :
Marrant, sous Windows y'a les clés de registre qui permettent de configurer les chemins propres aux applications (à défaut y'a aussi des variables système) Linux supérieur en tout ? Nope...

Ça ne résout pas du tout le problème, ça, ça règle juste le chemin des DLLs, bref ça remplace les rpaths, mais on peut aussi éditer les rpaths dans un exécutable déjà compilé. Mais un logiciel GNU/Linux a beaucoup plus d'objets à trouver que les .so! Il y a les traductions, les icônes, les fichiers représentant l'interface (qui sont dans certains cas chargés dynamiquement, cf. par exemple GtkBuilder), parfois des plugins (soit compilés, soit des scripts en Python, JavaScript, Scheme etc.) etc.

Et comme déjà dit, on n'a pas besoin de pouvoir déplacer un logiciel (si on l'installe en tant qu'admin comme prévu) parce que l'arborescence est standardisée.

Oui, c'est vrai, il y a /bin, /usr/bin, /opt/bin, /usr/share/bin, /sbin, /usr/sbin,
Puis on peut tout à fait vouloir déplacer certains logiciels sur une partition spécifique, etc...
(sans compter que le système ne marche que quand on a une connexion permanente à internet...)

Flanker (./240) :

vince (./237) :
Si j'ai bien compris ça veut dire que les chemins sont indiqués en dur dans les scripts ???

Dans les binaires également

GCC en est le meilleur exemple

La FHS prescrit qu'un logiciel installé par un paquetage système (ceux qu'on installe déjà compilés, quoi; cette convention est généralement étendue aux dépôts tiers) s'installe dans /usr (en particulier, les binaires dans /usr/bin).

Installer directement dans /bin est réservé aux outils indispensables pour le démarrage du système.
/opt/bin est carrément interdit, /opt/identifiant quelconque/bin est réservé aux paquetages tiers (convention souvent utilisée par les grands logiciels propriétaires).
/usr/share/bin est également interdit: /usr/share est réservé aux données indépendantes de la plateforme, donc c'est absurde d'y mettre un sous-répertoire bin.
/sbin et /usr/sbin sont réservés aux outils système utilisés exclusivement ou presque exclusivement par root. Comme pour /bin, /sbin est pour les outils indispensables pour le démarrage du système.

Pour un logiciel "normal" installé à travers un paquetage système, il y a un seul endroit possible pour les binaires, c'est /usr/bin.

Et je sais que le paquetage RPM de TIGCC n'est pas conforme (ça devrait utiliser /usr/tigcc en correspondance à l'exception à la FHS pour les cross-compilateurs prévue par Fedora, pas /usr/local/tigcc, et ça devrait symlinker les 2 binaires à lancer directement dans /usr/bin, pas rajouter $TIGCC/bin au PATH), je compte changer ça dans la prochaine version, mais je ne veux pas mettre à jour le paquetage juste pour ça.

Et comment fais-tu si tu veux déplacer un binaire sur une autre partition ?

- non rien finalement -

Flanker (./247) :
Et comment fais-tu si tu veux déplacer un binaire sur une autre partition ?

Bah sous linux, pour être autonomes tous les utilisateurs doivent être root...

Ah oui, c'est vrai

Ou alors faut installer une machine virtuelle pour le logiciel, c'est tout de même nettement plus rentable

/usr/tigcc c'est standard ça? ça devrait être /opt/tigcc ou /usr

FHS... FHS... hum c'est pas le "standard" définie par RedHat, et qui impose l'utilisation du RPM ?

Ha non je confond, C'est le LSB qui découle du FHS qui est aussi définie par RedHat

Tiens je viens de remarquer qu'office 2007 sait ouvrir les fichiers opendocument? et sans en faire de la bouillie? super, je peux virer openoffice alors ?!

Flanker (./250) :
Ah oui, c'est vrai

Ou alors faut installer une machine virtuelle pour le logiciel, c'est tout de même nettement plus rentable

Bah, ça permet de vendre des stations de travail dodécacore avec 64 Go de RAM...
Et ça, faut bien pouvoir les justifier. Si le besoin n'existe pas du le crées, et hop.
On dit merci Tux.

Flanker (./247) :
Et comment fais-tu si tu veux déplacer un binaire sur une autre partition ?

Tu ne déplaces pas un binaire, tu déplaces un mountpoint, c'est-à-dire que tu peux assigner n'importe quel dossier à une partition, et la partition où se trouve le dossier n'a aucune importance pour les applications, les chemins restent les mêmes! De plus, il y a aussi LVM qui permet de grouper plusieurs partitions en un seul mountpoint, pratique si tu as plusieurs disques durs et si tu ne veux pas te casser la tête à prévoir quels dossiers auront besoin du plus de place.

Un système de fichiers qui expose les partitions aux applications est totalement pourri et obsolète.

vince (./249) :

Flanker (./247) :
Et comment fais-tu si tu veux déplacer un binaire sur une autre partition ?

Bah sous linux, pour être autonomes tous les utilisateurs doivent être root...

Bah oui, et c'est comme ça que ça doit l'être. Un utilisateur qui n'est pas administrateur n'a pas à faire le boulot de l'administrateur!

squalyl (./251) :
/usr/tigcc c'est standard ça? ça devrait être /opt/tigcc ou /usr

C'est la convention utilisée par Fedora: https://fedoraproject.org/wiki/Packaging:Guidelines#Filesystem_Layout:

There are notable exceptions to this guideline for libexecdir (as specified in the GNU Coding Standards) and /usr/target for cross-compilers.

Godzil (./252) :
FHS... FHS... hum c'est pas le "standard" définie par RedHat, et qui impose l'utilisation du RPM ?
Ha non je confond, C'est le LSB qui découle du FHS qui est aussi définie par RedHat

Le FHS n'est pas un standard de Red Hat, la preuve, Fedora prescrit 2 exceptions au FHS (cf. ci dessus) et RHEL utilise aussi les conventions de Fedora. Le LSB ne découle pas du FHS, il prescrit le FHS et beaucoup d'autres choses, et il n'est pas non plus défini par Red Hat, mais par un consortium dont Red Hat n'est qu'un des membres. Et il n'impose pas le RPM comme système de paquetages natif, il impose juste que des RPMs n'utilisant qu'un sous-ensemble très limité des fonctionnalités de RPM (les "RPMs LSB") soient installables, ce qui peut être obtenu par exemple à travers alien.

Kevin Kofler (./243) :
[bla-bla-bla]

Et comme déjà dit, on n'a pas besoin de pouvoir déplacer un logiciel (si on l'installe en tant qu'admin comme prévu) parce que l'arborescence est standardisée.

J'ai tendance à installer mes softs sur la partition D: chez moi, et mes données sur E:, plus facile pour synchroniser mes backups. Ensuite j'utilise un script qui extrait les clés de registre de chaque logiciel installé et me les sauvegardes en .reg comme ça en cas de réinstallation, y'a juste à importer le .reg précédent pour retrouver mon application (enfin c'est un peu plus compliqué puisqu'il y a aussi des fichiers partagés dans system32 et cie)

Ca me permet aussi très facilement de partager une application depuis Windows XP avec Windows 2000 (que j'utilise encore activement) en utilisant exactement la même ruse (les lettres de lecteurs sont les mêmes sous les deux systèmes)

Et puis la compilation en dur, mouarf, la pratique de noob...

Kochise

Kevin Kofler (./256) :

Flanker (./247) :
Et comment fais-tu si tu veux déplacer un binaire sur une autre partition ?

Tu ne déplaces pas un binaire, tu déplaces un mountpoint, c'est-à-dire que tu peux assigner n'importe quel dossier à une partition, et la partition où se trouve le dossier n'a aucune importance pour les applications, les chemins restent les mêmes! De plus, il y a aussi LVM qui permet de grouper plusieurs partitions en un seul mountpoint, pratique si tu as plusieurs disques durs et si tu ne veux pas te casser la tête à prévoir quels dossiers auront besoin du plus de place.
Un système de fichiers qui expose les partitions aux applications est totalement pourri et obsolète.

Mais quand je *veux* qu'une application spécifique soit installée sur une partition spécifique. Comment dois-je faire avec Synaptic ?

vince (./249) :

Flanker (./247) :
Et comment fais-tu si tu veux déplacer un binaire sur une autre partition ?

Bah sous linux, pour être autonomes tous les utilisateurs doivent être root...

Bah oui, et c'est comme ça que ça doit l'être. Un utilisateur qui n'est pas administrateur n'a pas à faire le boulot de l'administrateur!

Faudrait que tu découvres la vie réelle, un jour... Il y a pas mal de cas de figures où on peut vouloir que ce soient les utilisateurs qui doivent installer leurs propres logiciels dans leur HOME...

vince (./255) :
Linux, l'OS gratos qui te crie "Changes ton MATOS !!!"

C'est quand même limite, je tourne les derniers kernel et WM sans souci sur une vieille machine, sur laquelle ne tourne pas Win 7, faut pas abuser

Kevin Kofler (./256) :
Un système de fichiers qui expose les partitions aux applications est totalement pourri et obsolète.

Idéalement, si j'avais 10 partitions de données ici et là sur mes disques, je voudrais n'en voir qu'une seule appelée "Data", en me foutant bien qu'elle s'appelle sdatruc ou sdbmachin.

Kochise (./257) :
Ensuite j'utilise un script qui extrait les clés de registre de chaque logiciel installé et me les sauvegardes en .reg comme ça en cas de réinstallation, y'a juste à importer le .reg précédent pour retrouver mon application (enfin c'est un peu plus compliqué puisqu'il y a aussi des fichiers partagés dans system32 et cie)

Ca a l'air d'être une belle merde ton truc, et pas fiable (lettres des partitions), tu peux toujours dire que Linux c pas bien, t'en tiens une bonne couche avec ça. Rien de simple et de user friendly, et ça peut foutre la merde pour 50 raison...

Folco (./260) :

Kevin Kofler (./256) :
Un système de fichiers qui expose les partitions aux applications est totalement pourri et obsolète.

Idéalement, si j'avais 10 partitions de données ici et là sur mes disques, je voudrais n'en voir qu'une seule appelée "Data", en me foutant bien qu'elle s'appelle sdatruc ou sdbmachin.

Mais comment fais-tu pour mettre tout le système sur ton SSD kipootramor sauf FCP que tu veux mettre sur un autre disque parce qu'il va prendre 200Go à l'installation ?
Comment vas-tu décider que telle base de données sera sur un disque en eSATA pour la basculer facilement d'une machine à l'autre ?

Kochise (./257) :
J'ai tendance à installer mes softs sur la partition D: chez moi, et mes données sur E:, plus facile pour synchroniser mes backups.

Sous GNU/Linux, tes données sont dans /home, et à la limite /etc et /root, bien séparées des logiciels, qui sont dans /usr.

Ensuite j'utilise un script qui extrait les clés de registre de chaque logiciel installé et me les sauvegardes en .reg comme ça en cas de réinstallation, y'a juste à importer le .reg précédent pour retrouver mon application (enfin c'est un peu plus compliqué puisqu'il y a aussi des fichiers partagés dans system32 et cie)

Tu peux faire de même avec les fichiers de configuration dans /etc, c'est même plus simple et plus fiable qu'avec la base des registres. Et la configuration par utilisateur (c'est-à-dire la plupart des réglages!) se trouve dans le dossier home et est donc automatiquement restauré si tu restaures ton home (mais tu peux aussi les traîter comme les fichiers dans /etc, ils sont organisés de la même manière).

Ca me permet aussi très facilement de partager une application depuis Windows XP avec Windows 2000 (que j'utilise encore activement) en utilisant exactement la même ruse (les lettres de lecteurs sont les mêmes sous les deux systèmes)

Sous GNU/Linux, tu ne partages pas une application, tu partages ses réglages et données (ils sont dans le dossier home) et tu utilises des binaires compilés pour la bonne distribution et version.

Flanker (./258) :
Mais quand je *veux* qu'une application spécifique soit installée sur une partition spécifique. Comment dois-je faire avec Synaptic ?

Tu ne peux pas. Je ne vois pas du tout l'intérêt. Ce n'est pas comme ça que fonctionne GNU/Linux.

Faudrait que tu découvres la vie réelle, un jour... Il y a pas mal de cas de figures où on peut vouloir que ce soient les utilisateurs qui doivent installer leurs propres logiciels dans leur HOME...

Bah non, ce n'est pas comme ça que le système est conçu. Soit on engage un administrateur qui administre activement, soit on donne les droits d'administrateur aux utilisateurs (avec PackageKit, même pas besoin de leur donner le mot de passe root, d'ailleurs, il suffit de leur donner le droit d'installer des paquetages à travers PolicyKit, cf. la configuration par défaut de Fedora 12 à sa sortie qui a fait scandale).

Kevin Kofler (./262) :
Tu ne peux pas. Je ne vois pas du tout l'intérêt. Ce n'est pas comme ça que fonctionne GNU/Linux.

Ce n'est pas parce que *tu* n'en vois pas l'intérêt que c'est le cas de tout le monde...

J'ai pas mal de logiciels installés sur mon disque externe parce que je n'ai pas la place sur mon disque de portable...

Kochise (./258) :
Et puis la compilation en dur, mouarf, la pratique de noob...

optimisation en vitesse mon cher </gnu>

Kevin Kofler (./263) :
Bah non, ce n'est pas comme ça que le système est conçu

Donc il faut en changer.

Flanker (./263) :
J'ai pas mal de logiciels installés sur mon disque externe parce que je n'ai pas la place sur mon disque de portable...

Es-tu au courant que les disques durs sont parmi les rares composants des PCs portables qui sont standardisés et que tu peux donc remplacer ton disque dur par un disque dur pour PC portable à capacité plus élevée? Ce serait plus pratique que de te trimballer un disque externe à chaque fois.

Et puis les logiciels libres ne prennent pas 200 Go, je ne vois pas du tout ce que les éditeurs de logiciels propriétaires font pour que leurs logiciels prennent tellement de place. Même les paquetages Fedora les plus énormes ne font que de l'ordre de 1 Go décompressé!

ce n'est pas à toi d'imposer ce genre de conditions, mais depuis qu'on te le dit tu dois le savoir.

Kevin Kofler (./265) :

Flanker (./263) :
J'ai pas mal de logiciels installés sur mon disque externe parce que je n'ai pas la place sur mon disque de portable...

Es-tu au courant que les disques durs sont parmi les rares composants des PCs portables qui sont standardisés et que tu peux donc remplacer ton disque dur par un disque dur pour PC portable à capacité plus élevée? Ce serait plus pratique que de te trimballer un disque externe à chaque fois.

Ok. Tu me le paies ?

Et puis les logiciels libres ne prennent pas 200 Go, je ne vois pas du tout ce que les éditeurs de logiciels propriétaires font pour que leurs logiciels prennent tellement de place. Même les paquetages Fedora les plus énormes ne font que de l'ordre de 1 Go décompressé!

Je n'ai pas 1 Go de libre pour les logiciels que je n'utilise pas souvent.

GoldenCrystal (./254) :
stations de travail dodécacore avec 64 Go de RAM

Kevin Kofler (./265) :
Et puis les logiciels libres ne prennent pas 200 Go, je ne vois pas du tout ce que les éditeurs de logiciels propriétaires font pour que leurs logiciels prennent tellement de place. Même les paquetages Fedora les plus énormes ne font que de l'ordre de 1 Go décompressé!

Tu sais qu'une application, ce n'est pas que le binaire de l'application, mais aussi des données ? Et comme tu connais bien tout ce qui est en dehors de Linux, FCP == Final Cut Pro, c'est un logiciel d'édition video qui est parmis les plus utilisé dans le monde, et il a pas mal de donnée externe.

Non, mais TIGCC n'a pas de données externes, alors aucun logiciel n'en a

Kevin n'a jamais joué à autre chose que Wesnoth, et du coup, il ne sait pas non plus qu'un jeu moderne se trimballe bien plus que 100Mo de données...

Flanker (./267) :
Je n'ai pas 1 Go de libre pour les logiciels que je n'utilise pas souvent.

Le logiciel moyen ne fait que quelques ko! Au maximum 2 ou 3, limite 4 Mo. Un logiciel qui fait 10 Mo est déjà un logiciel plus lourd que la moyenne, un logiciel qui fait 100 Mo est un logiciel vraiment lourd, un logiciel qui fait 1 Go est énorme et ces logiciels se comptent sur les doigts d'une ou deux main(s)!

Godzil (./268) :
Tu sais qu'une application, ce n'est pas que le binaire de l'application, mais aussi des données ?

Oui. J'ai regardé les paquetages complets avec rpm -qi, sans oublier les sous-paquetages quand ils existent. N'oublie pas que je suis packageur, je sais ce que je fais!

Et comme tu connais bien tout ce qui est en dehors de Linux, FCP == Final Cut Pro, c'est un logiciel d'édition video qui est parmis les plus utilisé dans le monde, et il a pas mal de donnée externe.

Pourtant Kdenlive tient dans 13 Mo (déjà installé/décompressé) + 35 Mo pour le framework MLT, plus quelques libs que tu pourrais déjà avoir ou non selon le cas, mais au total, c'est une centaine de Mo, donc 2000 fois moins que Final Cut Pro! (Et oui, évidemment que ces chiffres sont données comprises, cf. le paragraphe précédent!)

Et sinon, chez nous, FCP == Fedora Community Portal. Mais je me doutais bien que ce n'était pas de ça qu'il était question.

Flanker (./269) :
Non, mais TIGCC n'a pas de données externes, alors aucun logiciel n'en a

TIGCC a bien des données externes, cf. tigcc.a, cf. les exemples, cf. la doc…

Kevin n'a jamais joué à autre chose que Wesnoth, et du coup, il ne sait pas non plus qu'un jeu moderne se trimballe bien plus que 100Mo de données...

Wesnoth (wesnoth-data en particulier) est justement un des paquetages énormes avec ses presque 300 Mo.