Un débat intéressant et sans doute récurant que l'on voit apparaître
régulièrement sur les forums, et relatif quant au choix de la
distribution...
Linux pour quoi faire ? Tout d'abord clarifions la chose pour dire que
"linux" est le nom du kernel et non du system d'exploitation lui-même...
Petite précision pour les débutants linux. Il faut alors parler de
distribution GNU Linux...
Donc qu'attendez-vous d'un OS libre (par opposition à Windows) ?
Nous savons que Linux est une bonne solution s'il on veut faire un réseau ;
aussi peut-il est aussi une solution en terme de bureautique pure (Office) ?
La partie jeu reste une ombre pour ma part... peut-il concurrencer les
jeux sous Windows ?
Le choix de la distrib reste aussi, difficile dans la perspective des
mises à jour ? Je pense que c'est la que réside la difficulté. RPMS,
PKG, DEB, Yum, ou encore version type gentoo... , installation depuis les
sources, etc. Facilité, Rapidité ou encore prise de caféine, tels sont
les choix qui sont offerts. Un point important réside aussi dans la
sécurité...
Ayant tester une multitude de distrib (redhat, fedora, gentoo, mdk7.0 !,
archlinux, freebsd, solaris, etc), je ne sais sur quoi me baser afin de
trouver un bon compromis. L'on pourra consulter un site tel que
http://www.distrowatch.com afin d'y trouver un bref exposer des distribs
linux, avec les différents liens qui s'y rattachent.
Vos commentaires, et autres suggestions pour extrapoler ces propos seront
les bienvenus afin de clarifier certaines idées...
Le Wed, 07 Apr 2004 20:45:36 +0000, Nicolas George a écrit :
Jerome Lambert , dans le message , a écrit :
Il nécessite juste GTK2 et une glibc version ???
Xft, fontconfig, X11, OpenSSL, stdc++...
Oui, mais ceux-là me paraissaient "évidents"...
Sinon il vient avec les différentes bibliothèques nécessaires à son fonctionnement, qui sont dans des sous-reperoires de /usr/share/firefox, donc on n'a pas à se soucier des dépendances à ce niveau
Bref, si tu as deux programmes qui utilisent la même bibliothèque, tu as deux exemplaires de la bibliothèque, aussi bien sur disque qu'en mémoire.
A l'époque de 640Ko de ram et des disques de 10Mo, j'admets. A l'époque du giga de ram et des disques de 100Go, je trouve l'argument un peu "vieilli"...
Quand je vois ça: [ jerome]$ ls -l /usr/share/firefox/libnspr4.so -rwxr-xr-x 1 root root 171168 fév 8 02:36/usr/share/firefox/libnspr4.so
170Ko, c'est vraiment pas la mer à boire...
Super... Tu n'aurais pas appris la... ahem, disons informatique... sous windows, par hasard ?
Si, mais entre les messages d'insultes des gestionnaires de paquetages pour cause de conflits de bibliothèques, et les "voulez-vous remplacer trucmucheXX.dll par trucmucheYY.dll, qui est plus ancien" windowsien, je constate que les bibliothèques partagées posent de gros problèmes, apparemment insolubles. Donc une piste pourrait être de "départager".
D'autres systèmes (e.a. OS/2 et MacOS) le font (faisaient) bien...
Idem, dans des sous-repertoires de /usr/share/firefox, les fichiers propres aux utilisateurs étant bien entendu dans ~/.phoenix/
Tu n'as pas compris où est le problème. Si je modifie un fichier de config (par exemple unix.js pour y indiquer des font.directory.truetype.*), j'ai envie que quand je mets à jour le package, le gestionnaire de package me prévienne des modifications qu'il y a à faire. Je ne veux ni qu'il écrase silencieusement mes modifications (ce que ferait ton tar), ni qu'il ne mette pas à jour un fichier de config que je n'ai pas modifié et qui a changé depuis la version précédente.
Oui, mais ici c'est une version 0.8 livrée "en l'état", donc je peux imaginer qu'un programme d'installation un tant soit peu intelligemment conçu réglerait le problème, du genre de dpkg qui demande lors des mises à jour si on veut conserver les fichiers de configuration.
Jerome.
Le Wed, 07 Apr 2004 20:45:36 +0000, Nicolas George a écrit :
Jerome Lambert , dans le message
<pan.2004.04.07.20.36.08.26179@swing.aretirer.be>, a écrit :
Il nécessite juste GTK2 et une glibc version ???
Xft, fontconfig, X11, OpenSSL, stdc++...
Oui, mais ceux-là me paraissaient "évidents"...
Sinon il vient avec les différentes bibliothèques nécessaires à son
fonctionnement, qui sont dans des sous-reperoires de /usr/share/firefox,
donc on n'a pas à se soucier des dépendances à ce niveau
Bref, si tu as deux programmes qui utilisent la même bibliothèque, tu as
deux exemplaires de la bibliothèque, aussi bien sur disque qu'en
mémoire.
A l'époque de 640Ko de ram et des disques de 10Mo, j'admets.
A l'époque du giga de ram et des disques de 100Go, je trouve l'argument
un peu "vieilli"...
Quand je vois ça:
[jerome@torvalds jerome]$ ls -l /usr/share/firefox/libnspr4.so
-rwxr-xr-x 1 root root 171168 fév 8 02:36/usr/share/firefox/libnspr4.so
170Ko, c'est vraiment pas la mer à boire...
Super... Tu n'aurais pas appris la... ahem, disons
informatique... sous windows, par hasard ?
Si, mais entre les messages d'insultes des gestionnaires de paquetages
pour cause de conflits de bibliothèques, et les "voulez-vous remplacer
trucmucheXX.dll par trucmucheYY.dll, qui est plus ancien" windowsien, je
constate que les bibliothèques partagées posent de gros problèmes,
apparemment insolubles. Donc une piste pourrait être de "départager".
D'autres systèmes (e.a. OS/2 et MacOS) le font (faisaient) bien...
Idem, dans des sous-repertoires de /usr/share/firefox, les fichiers
propres aux utilisateurs étant bien entendu dans ~/.phoenix/
Tu n'as pas compris où est le problème. Si je modifie un fichier de
config (par exemple unix.js pour y indiquer des
font.directory.truetype.*), j'ai envie que quand je mets à jour le
package, le gestionnaire de package me prévienne des modifications qu'il
y a à faire. Je ne veux ni qu'il écrase silencieusement mes
modifications (ce que ferait ton tar), ni qu'il ne mette pas à jour un
fichier de config que je n'ai pas modifié et qui a changé depuis la
version précédente.
Oui, mais ici c'est une version 0.8 livrée "en l'état", donc je peux
imaginer qu'un programme d'installation un tant soit peu intelligemment
conçu réglerait le problème, du genre de dpkg qui demande lors des
mises à jour si on veut conserver les fichiers de configuration.
Le Wed, 07 Apr 2004 20:45:36 +0000, Nicolas George a écrit :
Jerome Lambert , dans le message , a écrit :
Il nécessite juste GTK2 et une glibc version ???
Xft, fontconfig, X11, OpenSSL, stdc++...
Oui, mais ceux-là me paraissaient "évidents"...
Sinon il vient avec les différentes bibliothèques nécessaires à son fonctionnement, qui sont dans des sous-reperoires de /usr/share/firefox, donc on n'a pas à se soucier des dépendances à ce niveau
Bref, si tu as deux programmes qui utilisent la même bibliothèque, tu as deux exemplaires de la bibliothèque, aussi bien sur disque qu'en mémoire.
A l'époque de 640Ko de ram et des disques de 10Mo, j'admets. A l'époque du giga de ram et des disques de 100Go, je trouve l'argument un peu "vieilli"...
Quand je vois ça: [ jerome]$ ls -l /usr/share/firefox/libnspr4.so -rwxr-xr-x 1 root root 171168 fév 8 02:36/usr/share/firefox/libnspr4.so
170Ko, c'est vraiment pas la mer à boire...
Super... Tu n'aurais pas appris la... ahem, disons informatique... sous windows, par hasard ?
Si, mais entre les messages d'insultes des gestionnaires de paquetages pour cause de conflits de bibliothèques, et les "voulez-vous remplacer trucmucheXX.dll par trucmucheYY.dll, qui est plus ancien" windowsien, je constate que les bibliothèques partagées posent de gros problèmes, apparemment insolubles. Donc une piste pourrait être de "départager".
D'autres systèmes (e.a. OS/2 et MacOS) le font (faisaient) bien...
Idem, dans des sous-repertoires de /usr/share/firefox, les fichiers propres aux utilisateurs étant bien entendu dans ~/.phoenix/
Tu n'as pas compris où est le problème. Si je modifie un fichier de config (par exemple unix.js pour y indiquer des font.directory.truetype.*), j'ai envie que quand je mets à jour le package, le gestionnaire de package me prévienne des modifications qu'il y a à faire. Je ne veux ni qu'il écrase silencieusement mes modifications (ce que ferait ton tar), ni qu'il ne mette pas à jour un fichier de config que je n'ai pas modifié et qui a changé depuis la version précédente.
Oui, mais ici c'est une version 0.8 livrée "en l'état", donc je peux imaginer qu'un programme d'installation un tant soit peu intelligemment conçu réglerait le problème, du genre de dpkg qui demande lors des mises à jour si on veut conserver les fichiers de configuration.
Jerome.
george
Michel Talon, dans le message <c51pbt$1m3q$, a écrit :
Quelles 3 versions de la libc?
libc.so.4, libc_r.so.4, libc.so.5
J'ai déjà vu des programmes qui chargeaient les trois, parce qu'on s'était dispensé de recompiler une bibliothèque après une upgrade majeure. Le blasphème !
S'il y a un système qui a des problèmes dramatiques de libc c'est bien Linux, et lui seul.
Ça fait longtemps qu'il n'y en a plus avec l'utilisation du ELF symbol versionning. J'ai actuellement sur mon système des programmes compilés quand j'étais en Woody et qui marchent parfaitement avec la nouvelle libc.
Michel Talon, dans le message <c51pbt$1m3q$1@asmodee.lpthe.jussieu.fr>,
a écrit :
Quelles 3 versions de la libc?
libc.so.4, libc_r.so.4, libc.so.5
J'ai déjà vu des programmes qui chargeaient les trois, parce qu'on
s'était dispensé de recompiler une bibliothèque après une upgrade
majeure. Le blasphème !
S'il y a un système qui a des problèmes dramatiques de libc c'est bien
Linux, et lui seul.
Ça fait longtemps qu'il n'y en a plus avec l'utilisation du ELF symbol
versionning. J'ai actuellement sur mon système des programmes compilés
quand j'étais en Woody et qui marchent parfaitement avec la nouvelle
libc.
Michel Talon, dans le message <c51pbt$1m3q$, a écrit :
Quelles 3 versions de la libc?
libc.so.4, libc_r.so.4, libc.so.5
J'ai déjà vu des programmes qui chargeaient les trois, parce qu'on s'était dispensé de recompiler une bibliothèque après une upgrade majeure. Le blasphème !
S'il y a un système qui a des problèmes dramatiques de libc c'est bien Linux, et lui seul.
Ça fait longtemps qu'il n'y en a plus avec l'utilisation du ELF symbol versionning. J'ai actuellement sur mon système des programmes compilés quand j'étais en Woody et qui marchent parfaitement avec la nouvelle libc.
Galkine
Le Wed, 07 Apr 2004 18:46:15 +0000, Nicolas George a écrit :
Je n'essaie pas d'imposer mes vues, j'explique les raisons pour lesquelles, à mon avis, le découpage est stupide.
Eh bien le découpage, à mon avis, est utile. Et comme plusieurs packages découpés permettent de faire un unique paquet monolithique, alors que la réciproque est fausse, tu admettras bien que le choix se fasse dans le sens du découpage. jusqu'ou veut-tu decouper ?
dans le cas de dvipdfm c'est 185Ko , pour tetex qui fait 3Mo la doc 12 la question n'est pas celle du découpage , mais de ce que l'on découpe et de l'intérêt réel de ce découpage
Le Wed, 07 Apr 2004 18:46:15 +0000, Nicolas George a écrit :
Je n'essaie pas d'imposer mes vues, j'explique les raisons pour
lesquelles, à mon avis, le découpage est stupide.
Eh bien le découpage, à mon avis, est utile. Et comme plusieurs packages
découpés permettent de faire un unique paquet monolithique, alors que la
réciproque est fausse, tu admettras bien que le choix se fasse dans le
sens du découpage.
jusqu'ou veut-tu decouper ?
dans le cas de dvipdfm c'est 185Ko , pour tetex qui fait 3Mo
la doc 12
la question n'est pas celle du découpage , mais de ce que l'on découpe
et de l'intérêt réel de ce découpage
Le Wed, 07 Apr 2004 18:46:15 +0000, Nicolas George a écrit :
Je n'essaie pas d'imposer mes vues, j'explique les raisons pour lesquelles, à mon avis, le découpage est stupide.
Eh bien le découpage, à mon avis, est utile. Et comme plusieurs packages découpés permettent de faire un unique paquet monolithique, alors que la réciproque est fausse, tu admettras bien que le choix se fasse dans le sens du découpage. jusqu'ou veut-tu decouper ?
dans le cas de dvipdfm c'est 185Ko , pour tetex qui fait 3Mo la doc 12 la question n'est pas celle du découpage , mais de ce que l'on découpe et de l'intérêt réel de ce découpage
george
Jerome Lambert , dans le message , a écrit :
Oui, mais ceux-là me paraissaient "évidents"...
Sauf qu'ils existent en plusieurs versions. En particulier, comme le c++ est un langage de guignols, il faut exactement la bonne version de libstdc++, sinon ça ne marche pas.
A l'époque de 640Ko de ram et des disques de 10Mo, j'admets. A l'époque du giga de ram et des disques de 100Go, je trouve l'argument un peu "vieilli"...
Mon adresse est sur ma page web, je t'invite à m'envoyer quelques barettes de mémoire (de bonne qualité de préférence, j'ai déjà eu des problèmes de RAM foireuse) et un gros disque dur. Merci d'avance.
170Ko, c'est vraiment pas la mer à boire...
Moi je vois surtout qu'un Firefox compilé avec toutes les bibliothèques partagées possibles partage près de 7 Mo avec les autres applications. C'est loin d'être négligeable.
Si, mais entre les messages d'insultes des gestionnaires de paquetages pour cause de conflits de bibliothèques, et les "voulez-vous remplacer trucmucheXX.dll par trucmucheYY.dll, qui est plus ancien" windowsien, je constate que les bibliothèques partagées posent de gros problèmes, apparemment insolubles.
Tu es en train de brûler un homme de paille monumental, là. Ce genre de problème n'existe que dans ton imagination (ou peut-être sous windows, je ne connais pas).
Oui, mais ici c'est une version 0.8 livrée "en l'état", donc je peux imaginer qu'un programme d'installation un tant soit peu intelligemment conçu réglerait le problème, du genre de dpkg qui demande lors des mises à jour si on veut conserver les fichiers de configuration.
Ben voilà, tu viens de comprendre un des avantages du gestionnaire de packages. Tu vois, quand tu veux.
Jerome Lambert , dans le message
<pan.2004.04.07.21.04.43.457281@swing.aretirer.be>, a écrit :
Oui, mais ceux-là me paraissaient "évidents"...
Sauf qu'ils existent en plusieurs versions. En particulier, comme le c++
est un langage de guignols, il faut exactement la bonne version de
libstdc++, sinon ça ne marche pas.
A l'époque de 640Ko de ram et des disques de 10Mo, j'admets.
A l'époque du giga de ram et des disques de 100Go, je trouve l'argument
un peu "vieilli"...
Mon adresse est sur ma page web, je t'invite à m'envoyer quelques
barettes de mémoire (de bonne qualité de préférence, j'ai déjà eu des
problèmes de RAM foireuse) et un gros disque dur. Merci d'avance.
170Ko, c'est vraiment pas la mer à boire...
Moi je vois surtout qu'un Firefox compilé avec toutes les bibliothèques
partagées possibles partage près de 7 Mo avec les autres applications.
C'est loin d'être négligeable.
Si, mais entre les messages d'insultes des gestionnaires de paquetages
pour cause de conflits de bibliothèques, et les "voulez-vous remplacer
trucmucheXX.dll par trucmucheYY.dll, qui est plus ancien" windowsien, je
constate que les bibliothèques partagées posent de gros problèmes,
apparemment insolubles.
Tu es en train de brûler un homme de paille monumental, là. Ce genre de
problème n'existe que dans ton imagination (ou peut-être sous windows,
je ne connais pas).
Oui, mais ici c'est une version 0.8 livrée "en l'état", donc je peux
imaginer qu'un programme d'installation un tant soit peu intelligemment
conçu réglerait le problème, du genre de dpkg qui demande lors des
mises à jour si on veut conserver les fichiers de configuration.
Ben voilà, tu viens de comprendre un des avantages du gestionnaire de
packages. Tu vois, quand tu veux.
Sauf qu'ils existent en plusieurs versions. En particulier, comme le c++ est un langage de guignols, il faut exactement la bonne version de libstdc++, sinon ça ne marche pas.
A l'époque de 640Ko de ram et des disques de 10Mo, j'admets. A l'époque du giga de ram et des disques de 100Go, je trouve l'argument un peu "vieilli"...
Mon adresse est sur ma page web, je t'invite à m'envoyer quelques barettes de mémoire (de bonne qualité de préférence, j'ai déjà eu des problèmes de RAM foireuse) et un gros disque dur. Merci d'avance.
170Ko, c'est vraiment pas la mer à boire...
Moi je vois surtout qu'un Firefox compilé avec toutes les bibliothèques partagées possibles partage près de 7 Mo avec les autres applications. C'est loin d'être négligeable.
Si, mais entre les messages d'insultes des gestionnaires de paquetages pour cause de conflits de bibliothèques, et les "voulez-vous remplacer trucmucheXX.dll par trucmucheYY.dll, qui est plus ancien" windowsien, je constate que les bibliothèques partagées posent de gros problèmes, apparemment insolubles.
Tu es en train de brûler un homme de paille monumental, là. Ce genre de problème n'existe que dans ton imagination (ou peut-être sous windows, je ne connais pas).
Oui, mais ici c'est une version 0.8 livrée "en l'état", donc je peux imaginer qu'un programme d'installation un tant soit peu intelligemment conçu réglerait le problème, du genre de dpkg qui demande lors des mises à jour si on veut conserver les fichiers de configuration.
Ben voilà, tu viens de comprendre un des avantages du gestionnaire de packages. Tu vois, quand tu veux.
talon
Nicolas George wrote:
Michel Talon, dans le message <c51pbt$1m3q$, a écrit :
Quelles 3 versions de la libc?
libc.so.4, libc_r.so.4, libc.so.5
libc_r c'est pour les programmes threadés. D'ailleurs dans FreeBSD-5 il
y a beaucoup de choix à ce niveau, y compris les threads N:M Quand à deux versions de la libc dans le même programme c'est se moquer. Il y a une libc de compatibilité pour les applications plus anciennes qui n'ont pas été recompilées et la libc courante. Bien loin des problèmes de Linux, et ça se voit que tu n'as pas connu l'époque héroique où c'était épouvantable, les programmes compilés sur FreeBSD il y a longtemps, des années, tournent encore sans problème. Avec les Linux récents, on dit adieu à des versions de Mathematica ou Maple qu'on avait achetées il n'y a pas si longtemps.
Pour ce qui est des performances comparées voici un benchmark qui va te mettre du baume au coeur, puisqu'il tend à prétendre que le kernel 2.6 de Linux fait enfin jeu à peu prés égal à FreeBSD: http://alfredo.cc.fer.hr/ En ce qui concerne les microbenchmarks, je n'accorde aucune valeur aux résultats qu'il donne, il est bien connu que Linux est à peu prés impossible à mesurer dans ses performances d'accés disque, car il cache tout et fait les écritures réélles dix minutes aprés.
--
Michel TALON
Nicolas George <george@clipper.ens.fr> wrote:
Michel Talon, dans le message <c51pbt$1m3q$1@asmodee.lpthe.jussieu.fr>,
a écrit :
Quelles 3 versions de la libc?
libc.so.4, libc_r.so.4, libc.so.5
libc_r c'est pour les programmes threadés. D'ailleurs dans FreeBSD-5 il
y a beaucoup de choix à ce niveau, y compris les threads N:M
Quand à deux versions de la libc dans le même programme c'est se moquer.
Il y a une libc de compatibilité pour les applications plus anciennes
qui n'ont pas été recompilées et la libc courante. Bien loin des
problèmes de Linux, et ça se voit que tu n'as pas connu l'époque
héroique où c'était épouvantable, les programmes compilés sur FreeBSD
il y a longtemps, des années, tournent encore sans problème. Avec les
Linux récents, on dit adieu à des versions de Mathematica ou Maple qu'on
avait achetées il n'y a pas si longtemps.
Pour ce qui est des performances comparées voici un benchmark qui va te
mettre du baume au coeur, puisqu'il tend à prétendre que le kernel 2.6
de Linux fait enfin jeu à peu prés égal à FreeBSD:
http://alfredo.cc.fer.hr/
En ce qui concerne les microbenchmarks, je n'accorde aucune valeur aux
résultats qu'il donne, il est bien connu que Linux est à peu prés
impossible à mesurer dans ses performances d'accés disque, car il cache
tout et fait les écritures réélles dix minutes aprés.
Michel Talon, dans le message <c51pbt$1m3q$, a écrit :
Quelles 3 versions de la libc?
libc.so.4, libc_r.so.4, libc.so.5
libc_r c'est pour les programmes threadés. D'ailleurs dans FreeBSD-5 il
y a beaucoup de choix à ce niveau, y compris les threads N:M Quand à deux versions de la libc dans le même programme c'est se moquer. Il y a une libc de compatibilité pour les applications plus anciennes qui n'ont pas été recompilées et la libc courante. Bien loin des problèmes de Linux, et ça se voit que tu n'as pas connu l'époque héroique où c'était épouvantable, les programmes compilés sur FreeBSD il y a longtemps, des années, tournent encore sans problème. Avec les Linux récents, on dit adieu à des versions de Mathematica ou Maple qu'on avait achetées il n'y a pas si longtemps.
Pour ce qui est des performances comparées voici un benchmark qui va te mettre du baume au coeur, puisqu'il tend à prétendre que le kernel 2.6 de Linux fait enfin jeu à peu prés égal à FreeBSD: http://alfredo.cc.fer.hr/ En ce qui concerne les microbenchmarks, je n'accorde aucune valeur aux résultats qu'il donne, il est bien connu que Linux est à peu prés impossible à mesurer dans ses performances d'accés disque, car il cache tout et fait les écritures réélles dix minutes aprés.
--
Michel TALON
george
Galkine , dans le message , a écrit :
jusqu'ou veut-tu decouper ?
Je suis plutôt satisfait des choix faits par Debian dans ce domaine. Parfois un découpage plus fin m'aurait plu, mais c'est rare.
Galkine , dans le message <pan.2004.04.07.21.21.15.629409@free.fr>, a
écrit :
jusqu'ou veut-tu decouper ?
Je suis plutôt satisfait des choix faits par Debian dans ce domaine.
Parfois un découpage plus fin m'aurait plu, mais c'est rare.
Je suis plutôt satisfait des choix faits par Debian dans ce domaine. Parfois un découpage plus fin m'aurait plu, mais c'est rare.
Jerome Lambert
Le Wed, 07 Apr 2004 21:23:57 +0000, Nicolas George a écrit :
Mon adresse est sur ma page web, je t'invite à m'envoyer quelques barettes de mémoire (de bonne qualité de préférence, j'ai déjà eu des problèmes de RAM foireuse) et un gros disque dur. Merci d'avance.
Je n'ai "que" un disque de 9Go, ma machine date de 1999 (P-II 450 avec 256Mo de Ram quand même), donc je suis loin d'avoir une bête de course selon les "standards" actuels, si c'est ce que tu sous-entends...
Pourtant la Fedora Core 1 qui est installée dessus prend 2.1 Go, donc il y de la place...
170Ko, c'est vraiment pas la mer à boire...
Moi je vois surtout qu'un Firefox compilé avec toutes les bibliothèques partagées possibles partage près de 7 Mo avec les autres applications. C'est loin d'être négligeable.
Mouais, bof!
Si, mais entre les messages d'insultes des gestionnaires de paquetages pour cause de conflits de bibliothèques, et les "voulez-vous remplacer trucmucheXX.dll par trucmucheYY.dll, qui est plus ancien" windowsien, je constate que les bibliothèques partagées posent de gros problèmes, apparemment insolubles.
Tu es en train de brûler un homme de paille monumental, là. Ce genre de problème n'existe que dans ton imagination (ou peut-être sous windows, je ne connais pas).
Euh visiblement tu n'as jamais essayé d'installer un programme un tant soit peu imposant sous Linux, toi...
Parce que faire une bête mise à jour de Mozilla 1.0 -> 1.4, j'ai abandonné. Soit on désinstalle l'ancien Mozilla, et la gestion des dépendances arrive à virer des choses aussi inutile que le Gnome qui était installé (!), soit on installe tellement de paquets (et dans le bon ordre de préférence) que cela revient carrément à installer la version supérieure de la distribution, ou encore on y va à coups de --force et --nodeps,et on fout tout en l'air.
Y'a pas à dire, les bibliothèques partagées, c'est génial!!!
Je pourrais encore t'en raconter sur d'autres (OpenOffice, ardour, etc.)
Donc maintenant, quand je veux passer à des versions supérieurs de mes programmes, j'attends un peu et j'installe la version suivante de la distribution. C'est idiot et bourrin, mais au moins ça marche!
Oui, mais ici c'est une version 0.8 livrée "en l'état", donc je peux imaginer qu'un programme d'installation un tant soit peu intelligemment conçu réglerait le problème, du genre de dpkg qui demande lors des mises à jour si on veut conserver les fichiers de configuration.
Ben voilà, tu viens de comprendre un des avantages du gestionnaire de packages. Tu vois, quand tu veux.
Par contre, pour les inconvénients, je suis aussi au courant...
Jerome.
Le Wed, 07 Apr 2004 21:23:57 +0000, Nicolas George a écrit :
Mon adresse est sur ma page web, je t'invite à m'envoyer quelques
barettes de mémoire (de bonne qualité de préférence, j'ai déjà eu des
problèmes de RAM foireuse) et un gros disque dur. Merci d'avance.
Je n'ai "que" un disque de 9Go, ma machine date de 1999 (P-II 450 avec
256Mo de Ram quand même), donc je suis loin d'avoir une bête de course
selon les "standards" actuels, si c'est ce que tu sous-entends...
Pourtant la Fedora Core 1 qui est installée dessus prend 2.1 Go, donc il
y de la place...
170Ko, c'est vraiment pas la mer à boire...
Moi je vois surtout qu'un Firefox compilé avec toutes les
bibliothèques partagées possibles partage près de 7 Mo avec les
autres applications. C'est loin d'être négligeable.
Mouais, bof!
Si, mais entre les messages d'insultes des gestionnaires de paquetages
pour cause de conflits de bibliothèques, et les "voulez-vous remplacer
trucmucheXX.dll par trucmucheYY.dll, qui est plus ancien" windowsien,
je constate que les bibliothèques partagées posent de gros
problèmes, apparemment insolubles.
Tu es en train de brûler un homme de paille monumental, là. Ce genre
de problème n'existe que dans ton imagination (ou peut-être sous
windows, je ne connais pas).
Euh visiblement tu n'as jamais essayé d'installer un programme un tant
soit peu imposant sous Linux, toi...
Parce que faire une bête mise à jour de Mozilla 1.0 -> 1.4, j'ai
abandonné. Soit on désinstalle l'ancien Mozilla, et la gestion des
dépendances arrive à virer des choses aussi inutile que le Gnome qui
était installé (!), soit on installe tellement de paquets (et dans le
bon ordre de préférence) que cela revient carrément à installer la
version supérieure de la distribution, ou encore on y va à coups de
--force et --nodeps,et on fout tout en l'air.
Y'a pas à dire, les bibliothèques partagées, c'est génial!!!
Je pourrais encore t'en raconter sur d'autres (OpenOffice, ardour, etc.)
Donc maintenant, quand je veux passer à des versions supérieurs de mes
programmes, j'attends un peu et j'installe la version suivante de la
distribution. C'est idiot et bourrin, mais au moins ça marche!
Oui, mais ici c'est une version 0.8 livrée "en l'état", donc je peux
imaginer qu'un programme d'installation un tant soit peu intelligemment
conçu réglerait le problème, du genre de dpkg qui demande lors des
mises à jour si on veut conserver les fichiers de configuration.
Ben voilà, tu viens de comprendre un des avantages du gestionnaire de
packages. Tu vois, quand tu veux.
Par contre, pour les inconvénients, je suis aussi au courant...
Le Wed, 07 Apr 2004 21:23:57 +0000, Nicolas George a écrit :
Mon adresse est sur ma page web, je t'invite à m'envoyer quelques barettes de mémoire (de bonne qualité de préférence, j'ai déjà eu des problèmes de RAM foireuse) et un gros disque dur. Merci d'avance.
Je n'ai "que" un disque de 9Go, ma machine date de 1999 (P-II 450 avec 256Mo de Ram quand même), donc je suis loin d'avoir une bête de course selon les "standards" actuels, si c'est ce que tu sous-entends...
Pourtant la Fedora Core 1 qui est installée dessus prend 2.1 Go, donc il y de la place...
170Ko, c'est vraiment pas la mer à boire...
Moi je vois surtout qu'un Firefox compilé avec toutes les bibliothèques partagées possibles partage près de 7 Mo avec les autres applications. C'est loin d'être négligeable.
Mouais, bof!
Si, mais entre les messages d'insultes des gestionnaires de paquetages pour cause de conflits de bibliothèques, et les "voulez-vous remplacer trucmucheXX.dll par trucmucheYY.dll, qui est plus ancien" windowsien, je constate que les bibliothèques partagées posent de gros problèmes, apparemment insolubles.
Tu es en train de brûler un homme de paille monumental, là. Ce genre de problème n'existe que dans ton imagination (ou peut-être sous windows, je ne connais pas).
Euh visiblement tu n'as jamais essayé d'installer un programme un tant soit peu imposant sous Linux, toi...
Parce que faire une bête mise à jour de Mozilla 1.0 -> 1.4, j'ai abandonné. Soit on désinstalle l'ancien Mozilla, et la gestion des dépendances arrive à virer des choses aussi inutile que le Gnome qui était installé (!), soit on installe tellement de paquets (et dans le bon ordre de préférence) que cela revient carrément à installer la version supérieure de la distribution, ou encore on y va à coups de --force et --nodeps,et on fout tout en l'air.
Y'a pas à dire, les bibliothèques partagées, c'est génial!!!
Je pourrais encore t'en raconter sur d'autres (OpenOffice, ardour, etc.)
Donc maintenant, quand je veux passer à des versions supérieurs de mes programmes, j'attends un peu et j'installe la version suivante de la distribution. C'est idiot et bourrin, mais au moins ça marche!
Oui, mais ici c'est une version 0.8 livrée "en l'état", donc je peux imaginer qu'un programme d'installation un tant soit peu intelligemment conçu réglerait le problème, du genre de dpkg qui demande lors des mises à jour si on veut conserver les fichiers de configuration.
Ben voilà, tu viens de comprendre un des avantages du gestionnaire de packages. Tu vois, quand tu veux.
Par contre, pour les inconvénients, je suis aussi au courant...
Jerome.
george
Michel Talon, dans le message <c51s5v$1n2q$, a écrit :
libc_r c'est pour les programmes threadés.
Je sais. C'est une des conneries de FreeBSD.
Quand à deux versions de la libc dans le même programme c'est se moquer.
Je trouve aussi. FreeBSD est vraiment une merde.
et ça se voit que tu n'as pas connu l'époque héroique où c'était épouvantable,
Je l'ai un peu connue. Et je m'en fous : les emmerdes que j'ai, c'est avec des FreeBD de maintenant, pas d'il y a six ans.
Avec les Linux récents, on dit adieu à des versions de Mathematica ou Maple qu'on avait achetées il n'y a pas si longtemps.
C'est qu'on n'est pas doué, hein.
Pour ce qui est des performances
Ce ne sont pas les performances brutes qui m'intéressent.
Michel Talon, dans le message <c51s5v$1n2q$1@asmodee.lpthe.jussieu.fr>,
a écrit :
libc_r c'est pour les programmes threadés.
Je sais. C'est une des conneries de FreeBSD.
Quand à deux versions de la libc dans le même programme c'est se moquer.
Je trouve aussi. FreeBSD est vraiment une merde.
et ça se voit que tu n'as pas connu l'époque
héroique où c'était épouvantable,
Je l'ai un peu connue. Et je m'en fous : les emmerdes que j'ai, c'est
avec des FreeBD de maintenant, pas d'il y a six ans.
Avec les
Linux récents, on dit adieu à des versions de Mathematica ou Maple qu'on
avait achetées il n'y a pas si longtemps.
C'est qu'on n'est pas doué, hein.
Pour ce qui est des performances
Ce ne sont pas les performances brutes qui m'intéressent.
Michel Talon, dans le message <c51s5v$1n2q$, a écrit :
libc_r c'est pour les programmes threadés.
Je sais. C'est une des conneries de FreeBSD.
Quand à deux versions de la libc dans le même programme c'est se moquer.
Je trouve aussi. FreeBSD est vraiment une merde.
et ça se voit que tu n'as pas connu l'époque héroique où c'était épouvantable,
Je l'ai un peu connue. Et je m'en fous : les emmerdes que j'ai, c'est avec des FreeBD de maintenant, pas d'il y a six ans.
Avec les Linux récents, on dit adieu à des versions de Mathematica ou Maple qu'on avait achetées il n'y a pas si longtemps.
C'est qu'on n'est pas doué, hein.
Pour ce qui est des performances
Ce ne sont pas les performances brutes qui m'intéressent.
george
Jerome Lambert , dans le message , a écrit :
Pourtant la Fedora Core 1 qui est installée dessus prend 2.1 Go,
Et là, tu réfléchis peut-être deux secondes, et tu te dis que tu es bien content que la plupart des programmes utilisent des bibliothèques partagées, parce que sinon, c'est une douzaine de Mo qu'il aurait fallu pour la même chose.
Euh visiblement tu n'as jamais essayé d'installer un programme un tant soit peu imposant sous Linux, toi...
Si, mais j'ai une distrib correcte.
soit on installe tellement de paquets (et dans le bon ordre de préférence)
Straw-man : n'importe quel gestionnaire de package correct fera automatiquement ça dans le bon ordre.
que cela revient carrément à installer la version supérieure de la distribution,
Oui, et alors ? Tu n'as pas l'impression d'être en train de dire une grosse banalité ? « Pour avoir un système à jour, il faut avoir un système à jour. »
Donc maintenant, quand je veux passer à des versions supérieurs de mes programmes, j'attends un peu et j'installe la version suivante de la distribution.
Mauvaise distrib, changer de distrib.
Jerome Lambert , dans le message
<pan.2004.04.07.21.44.52.816923@swing.aretirer.be>, a écrit :
Pourtant la Fedora Core 1 qui est installée dessus prend 2.1 Go,
Et là, tu réfléchis peut-être deux secondes, et tu te dis que tu es bien
content que la plupart des programmes utilisent des bibliothèques
partagées, parce que sinon, c'est une douzaine de Mo qu'il aurait fallu
pour la même chose.
Euh visiblement tu n'as jamais essayé d'installer un programme un tant
soit peu imposant sous Linux, toi...
Si, mais j'ai une distrib correcte.
soit on installe tellement de paquets (et dans le
bon ordre de préférence)
Straw-man : n'importe quel gestionnaire de package correct fera
automatiquement ça dans le bon ordre.
que cela revient carrément à installer la
version supérieure de la distribution,
Oui, et alors ? Tu n'as pas l'impression d'être en train de dire une
grosse banalité ? « Pour avoir un système à jour, il faut avoir un
système à jour. »
Donc maintenant, quand je veux passer à des versions supérieurs de mes
programmes, j'attends un peu et j'installe la version suivante de la
distribution.
Pourtant la Fedora Core 1 qui est installée dessus prend 2.1 Go,
Et là, tu réfléchis peut-être deux secondes, et tu te dis que tu es bien content que la plupart des programmes utilisent des bibliothèques partagées, parce que sinon, c'est une douzaine de Mo qu'il aurait fallu pour la même chose.
Euh visiblement tu n'as jamais essayé d'installer un programme un tant soit peu imposant sous Linux, toi...
Si, mais j'ai une distrib correcte.
soit on installe tellement de paquets (et dans le bon ordre de préférence)
Straw-man : n'importe quel gestionnaire de package correct fera automatiquement ça dans le bon ordre.
que cela revient carrément à installer la version supérieure de la distribution,
Oui, et alors ? Tu n'as pas l'impression d'être en train de dire une grosse banalité ? « Pour avoir un système à jour, il faut avoir un système à jour. »
Donc maintenant, quand je veux passer à des versions supérieurs de mes programmes, j'attends un peu et j'installe la version suivante de la distribution.
