Choix de la distrib

Le Thu, 08 Apr 2004 12:45:35 +0000, nicolas vigier a écrit :

Si tu installes une distribution recente sur une machine d'il y a 3 ans avec
les memes logiciels qu'il y a 3 ans, je pense que ca sera aussi rapide
qu'avant. Mais peu etre qu'il y a des exceptions ...

Ma machine: P-II 450, DD 10Go, 256Mo de Ram (achetée en 1999)
La première distrib installée fut une MDK 8, et elle a maintenant une
Fedora Core 1.

Si je regarde la fluidité, la Fedora semble est un poil plus rapide, par
contre c'est dramatique au niveau occupation mémoire, et encore j'ai
déja fait une partie du ménage en supprimant les programmes et services
non utilisés. X pompe déja 90Mo à lui tout seul.

Donc en utilisation classique, avec Xmms, OpenOffice, Pan, Evolution et
Mozilla lancés, ça a tendance à ramer. Alors si je charge un document de
75 pages avec images et tout le tralala dans OpenOffice, ça commence à
swapper...

Par contre je crois qu'en mettant une Debian ou une Gentoo avec le strict
minimum, ça devrait le faire (mais bon, ce sera pour quand je saurai
recompiler le noyau avec le support isa-pnp...)

Jerome.

Jerome Lambert <jerome.lambert@swing.aretirer.be> wrote:

A propos, ta distribution magique qui, visiblement gère les dépendances
comme un chef, c'est laquelle?

Debian bien sûr.

Jerome.

--

Michel TALON

Jerome Lambert , dans le message
<pan.2004.04.08.13.06.37.163912@swing.aretirer.be>, a écrit :

Donc j'installe libbar 42, qui nécessite libfoo 24 (on a la 22), qui,
elle, est incluse dans progbar 15 (on a la 11), qui lui-même ...

Voilà, tu commences à comprendre.

(on peut
continuer longtemps comme ça), ce qui revient la plupart du temps à
upgrader carrément (presque) toute la distribution.

Déjà, c'est faux. Quand tu upgrades un truc lié à Gnome, il y a de bonne
chance que tout Gnome suive, et peut-être les bibliothèques clientes X11
aussi, mais ça ne touchera pas à TeX. Réciproquement, si tu mets à jour
TeX pour faire marcher un package récent, ça ne touchera pas à Gnome.

Ensuite, le problème que tu soulignes n'est pas du tout _causé_ par le
gestionnaire de packages, il est intrinsèque à l'évolution des
programmes. Si tu veux installer un programme trop récent pour la moitié
des bibliothèques présentes sur ton système, tu _dois_ installer les
nouvelles versions, il n'y a pas d'alternative.

Le gestionnaire de package est justement là pour te simplifier la vie,
en :

- te prévenant qu'une mise à jour est nécessaire, plutôt que te laisser
te dépatouiller avec un message du style :

/tmp/kdetruc: error while loading shared libraries: libkmachin.so.42:
cannot open shared object file: No such file or directory

- garder trace des compatibilités et incompatibilités et te permettre
d'installer le minimum.

Ce que tu proposes demande, à chaque programme, d'installer l'équivalent
de la moitié de ton système, alors même que ce qui était déjà aurait pu
suffire. Bref, c'est complètement stupide.

Le Thu, 08 Apr 2004 13:47:28 +0000, Nicolas George a écrit :

Jerome Lambert , dans le message
<pan.2004.04.08.13.06.37.163912@swing.aretirer.be>, a écrit :

Donc j'installe libbar 42, qui nécessite libfoo 24 (on a la 22), qui,
elle, est incluse dans progbar 15 (on a la 11), qui lui-même ...

Voilà, tu commences à comprendre.

J'avais compris, merci, vu que c'est ce genre d'installation à rallonge
qui m'énerve...

(on peut
continuer longtemps comme ça), ce qui revient la plupart du temps à
upgrader carrément (presque) toute la distribution.

Déjà, c'est faux. Quand tu upgrades un truc lié à Gnome, il y a de bonne
chance que tout Gnome suive, et peut-être les bibliothèques clientes X11
aussi, mais ça ne touchera pas à TeX. Réciproquement, si tu mets à jour
TeX pour faire marcher un package récent, ça ne touchera pas à Gnome.

Ok, mais les programmes courants (genre Mozilla, OpenOffice, etc.) ont
plutot tendance à nécessiter une mise à jour de KDE/gnome, qui
eux-même réclament une version supérieure de X11, donc quelques (!) Mo
de mise-à-jour...

Ce que tu proposes demande, à chaque programme, d'installer l'équivalent
de la moitié de ton système, alors même que ce qui était déjà aurait pu
suffire. Bref, c'est complètement stupide.

Sauf si on se bloque une bonne fois pour toute sur la version des
bibliothèques installées, genre la distribution foo 1.2 a la
bibliothèque libbar 4.3, donc tout programme pour foo 1.2 ne peut
utiliser de version supérieure à libbar 4.3

Or, la pratique montre qu'on a plutot des messages du
style toto-foo1.2.i386.rpm needs libbar >= 4.4 !!! Grrr...

Donc pour résoudre ce problème, une des pistes serait que toto-foo1.2
contienne ce qu'il faut pour fonctionner.

C'est d'ailleurs amha un des avantages des OS proprio: chaque version de
l'OS vient avec une version des bibliothèques, et c'est à chaque
programme de s'adapter, alors que sous Linux on a plutot tendance à
adapter l'OS au programme, d'où la quantité industrielle de messages du
style "J'arrive pas à installer le programme foo sur la distribution bar
9.2" sur les forums de configuration...

Jerome.

Jerome Lambert , dans le message
<pan.2004.04.08.14.13.12.303885@swing.aretirer.be>, a écrit :

Sauf si on se bloque une bonne fois pour toute sur la version des
bibliothèques installées, genre la distribution foo 1.2 a la
bibliothèque libbar 4.3, donc tout programme pour foo 1.2 ne peut
utiliser de version supérieure à libbar 4.3

Sauf que personne n'a envie de faire ça : si libbar 4.4 sort, c'est
qu'elle apporte des améliorations, donc les développeurs ont envie de
s'en servir.

Donc pour résoudre ce problème, une des pistes serait que toto-foo1.2
contienne ce qu'il faut pour fonctionner.

Et l'autre serait que quand c'est nécessaire de mettre à jour cette
libbar.

Dans un cas tu installes une libbar 4.4 à chaque fois qu'un programme en
a besoin, dans l'autre cas tu l'installes une fois pour toute. Tu
commences à comprendre la différence, ou toujours pas ?

C'est d'ailleurs amha un des avantages des OS proprio: chaque version de
l'OS vient avec une version des bibliothèques, et c'est à chaque
programme de s'adapter

C'est vrai que je n'ai jamais entendu dire qu'il fallait upgrader
direct-machin pour le dernier jeu à la mode quand on n'a pas la toute
dernière version de windows.

Le Thu, 08 Apr 2004 14:18:15 +0000, Nicolas George a écrit :

Jerome Lambert , dans le message
<pan.2004.04.08.14.13.12.303885@swing.aretirer.be>, a écrit :

Sauf si on se bloque une bonne fois pour toute sur la version des
bibliothèques installées, genre la distribution foo 1.2 a la
bibliothèque libbar 4.3, donc tout programme pour foo 1.2 ne peut
utiliser de version supérieure à libbar 4.3

Sauf que personne n'a envie de faire ça : si libbar 4.4 sort, c'est
qu'elle apporte des améliorations, donc les développeurs ont envie de
s'en servir.

Et donc forcent les utilisateurs de libbar 4.3 à mettre leur système à
jour, même si libbar 4.3 leur convient parfaitement...

Dans un cas tu installes une libbar 4.4 à chaque fois qu'un programme en
a besoin, dans l'autre cas tu l'installes une fois pour toute. Tu
commences à comprendre la différence, ou toujours pas ?

Non, c'est toi qui ne comprends pas. Je vais essayer d'etre plus
explicite:
soit toto 1.2 qui fonctionne libbar 4.3
si j'installe foo 6.3 et que celui-ci nécessite libbar 4.4, je dois alors
installer libbar 4.4. Jusque là, on est d'accord.
Le problème, c'est qu'il y de forte chances qu'automatiquement le
gestionnaire va m'imposer toto 1.3, et ce même si toto 1.2 me convient.
On est alors reparti pour un tour car il est plus que probable que les
dépendances de toto 1.2 ne se limitent pas à libbar, mais bon, passons...

L'idée serait que toto 1.2 "contienne" libbar 4.3 (un peu comme firefox,
pour reprendre le début du fil)
Si je veux installer foo 6.3, comme celui-ci "contient" libbar 4.4, je ne
touche pas à toto, et donc les programmes peuvent fonctionner
indépendamment l'un de l'autre, et donc plus de conflits, de
dépendances, etc.

De même, la désinstallation de toto 1.2 n'influe aucunement sur foo 6.3,
et inversement...

Je pourrais même installer toto 1.4 avec libbar 4.5 sans que ça change
quoi que ce soit au système...

Il est clair que, si chaque programme graphique contient sa bibliothèque
X11, on est mal barré question place, mais on pourrait alors déterminer
un minimum commun, basé par exemple sur la version de X11 pour les
programmes graphiques.

C'est d'ailleurs amha un des avantages des OS proprio: chaque version de
l'OS vient avec une version des bibliothèques, et c'est à chaque
programme de s'adapter

C'est vrai que je n'ai jamais entendu dire qu'il fallait upgrader
direct-machin pour le dernier jeu à la mode quand on n'a pas la toute
dernière version de windows.

Gagné, mais c'est la seule exception, dans le sens où direct-machin
permet l'accès direct au matériel. Il est donc dépendant du matériel
et des versions du pilote.

Par contre la plupart des softs Windows vendus en 2004 s'installent encore
sur du Windows 98, ou encore des softs Mac sous Mac OS9...

Autre exemple (qui ne vient pas de moi): Java
La machine virtuelle définit un minimum de fonctionnalités, et si on
veut en amener de nouvelles, il faut l'implémenter au sein de son
programme, et donc les programmes fonctionnent indépendamment de la
version de la JVM.
Exception: les fonctions de cryptographie, ce qui explique que certaines
banques exigent une JVM version x.y minimum.

Jerome.

Jerome Lambert , dans le message
<pan.2004.04.08.14.52.50.731520@swing.aretirer.be>, a écrit :

Et donc forcent les utilisateurs de libbar 4.3 à mettre leur système à
jour, même si libbar 4.3 leur convient parfaitement...

Tu n'es pas obligé d'utiliser leurs programmes, hein. Mais tu ne peux
pas demander aux développeurs de travailler avec des versions de bibals
avec moins de fonctionnalités pratiques sous prétexte que tu as la
flemme de mettre à jour ton système.

soit toto 1.2 qui fonctionne libbar 4.3
si j'installe foo 6.3 et que celui-ci nécessite libbar 4.4, je dois alors
installer libbar 4.4. Jusque là, on est d'accord.
Le problème, c'est qu'il y de forte chances qu'automatiquement le
gestionnaire va m'imposer toto 1.3, et ce même si toto 1.2 me convient.

Ah, c'est là que tu te trompes ! Non, ce n'est pas comme ça que ça se
passe avec un bon gestionnaire de packages et des packages correctement
faits. Il y a deux possibilités :

- soit la libbar 4.4 asure la compatibilité avec la 4.3, et tu peux
garder toto 1.2 si tu veux (et le jour où tu veux passer à toto 1.3,
tu as déjà libbar 4.4) ;

- soit la libbar 4.4 n'assure pas la compatibilité, alors elle sera
installée en plus de la 4.3, et tu pourras également garder toto 1.3.

Par contre la plupart des softs Windows vendus en 2004 s'installent encore
sur du Windows 98, ou encore des softs Mac sous Mac OS9...

Cette affirmation m'a l'air pour le moins suspecte, pour ne pas dire
carrément fausse.

Autre exemple (qui ne vient pas de moi): Java
La machine virtuelle définit un minimum de fonctionnalités

Au prix d'une lourdeur monstrueuse. Java n'est vraiment pas un exemple
que j'ai envie de suivre.

In article <pan.2004.04.08.13.26.53.48493@swing.aretirer.be>,
Jerome Lambert wrote:

Donc en utilisation classique, avec Xmms, OpenOffice, Pan, Evolution et
Mozilla lancés, ça a tendance à ramer. Alors si je charge un document de
75 pages avec images et tout le tralala dans OpenOffice, ça commence à
swapper...

Et ca ne swappait pas en faisant la meme chose sur une MDK 8 ?

In article <pan.2004.04.08.14.13.12.303885@swing.aretirer.be>,
Jerome Lambert wrote:

Ok, mais les programmes courants (genre Mozilla, OpenOffice, etc.) ont
plutot tendance à nécessiter une mise à jour de KDE/gnome, qui
eux-même réclament une version supérieure de X11, donc quelques (!) Mo
de mise-à-jour...

Il me semble que Mozilla et OpenOffice sont independants de KDE ou Gnome,
il n'y a pas de raison qu'ils te demandent de changer de version.

Le Thu, 08 Apr 2004 15:21:30 +0000, Nicolas George a écrit :

Jerome Lambert , dans le message
<pan.2004.04.08.14.52.50.731520@swing.aretirer.be>, a écrit :

Et donc forcent les utilisateurs de libbar 4.3 à mettre leur système à
jour, même si libbar 4.3 leur convient parfaitement...

Tu n'es pas obligé d'utiliser leurs programmes, hein. Mais tu ne peux
pas demander aux développeurs de travailler avec des versions de bibals
avec moins de fonctionnalités pratiques sous prétexte que tu as la
flemme de mettre à jour ton système.

Le problème peut être posé autrement:
L'OS doit-il s'adapter au programme ou le programme doit-il s'adapter à
l'OS?
J'ai l'impression que nos réponses respectives sont différentes ;-)

soit toto 1.2 qui fonctionne libbar 4.3
si j'installe foo 6.3 et que celui-ci nécessite libbar 4.4, je dois alors
installer libbar 4.4. Jusque là, on est d'accord.
Le problème, c'est qu'il y de forte chances qu'automatiquement le
gestionnaire va m'imposer toto 1.3, et ce même si toto 1.2 me convient.

Ah, c'est là que tu te trompes ! Non, ce n'est pas comme ça que ça se
passe avec un bon gestionnaire de packages et des packages correctement
faits. Il y a deux possibilités :

- soit la libbar 4.4 asure la compatibilité avec la 4.3, et tu peux
garder toto 1.2 si tu veux (et le jour où tu veux passer à toto 1.3,
tu as déjà libbar 4.4) ;

- soit la libbar 4.4 n'assure pas la compatibilité, alors elle sera
installée en plus de la 4.3, et tu pourras également garder toto 1.3.

Ben, à rpm-land (yum et urpmi), ça se passe comme je le décris...

Par contre la plupart des softs Windows vendus en 2004 s'installent encore
sur du Windows 98, ou encore des softs Mac sous Mac OS9...

Cette affirmation m'a l'air pour le moins suspecte, pour ne pas dire
carrément fausse.

Je touche régulièrement à du Windows, donc je sais ce que je dis.
exemples:
- Office 2000, installé sans problèmes sur du Windows 95, 98 , et 2000
- Office 97 installé sur Windows XP

De même, j'ai acheté pour un copain en février de cette année et
installé Easy CD Creator, VidéoWave et McAfee Antivirus sur une machine
en Windows 2000, et ça tourne...

Maintenant, je dirais que, contrairement à toi, j'ai pas mal bourlingué
par différents systèmes, et certainement pas que des Windowseries ou des
Unix, donc je sais, pour l'avoir vu, qu'il y a d'autres manières
d'aborder le problème...

Je sais aussi que chaque système a ses avantages et ses inconvénients,
et qu'aucun n'a LA solution. Disons pour faire simple que chacun oriente
son compromis comme il veut...

Jerome.