Choix de la distrib

Le Wed, 07 Apr 2004 22:06:39 +0000, Nicolas George a écrit :

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.

Si j'étais à court de place, le première chose que je ferais c'est
d'aller virer les programmes que je n'utilise pas, non?
Et là, dans des distrib genre Mandrake où tu as 3 traitements de texte,
5 tableurs, 3 environnements de bureau, 6 éditeurs de texte, etc., il y a
moyen de bien faire maigrir...

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.

C'est-à-dire?

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.

Ah oui?
Et quand le gestionnaire de paquetages prend comme base de référence ce
qu'il y sur les CD d'install (cas typique, on peut faire le même
raisonnement avec un mirroir), et que le libmachinchose qui se trouve sur
les CD est trop ancien, tu te tapes tout à la main, recherche des
libmachinchose sur le net comprise...

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

Mais c'est mon navigateur que je veux upgrader, pas mon système! La
nuance est quand même de taille!

De même, réinstaller un OS pour upgrader un pauvre programme, ça
ne te semble pas "excessif"? Moi, si!

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.

Toutes les distrib à base de paquetages ont ce genre de problèmes, donc
je dirais plutot mauvais procédé, changer procédé...

Jerome.

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

Si j'étais à court de place, le première chose que je ferais c'est
d'aller virer les programmes que je n'utilise pas, non?

Je n'ai pas de compte sur ta machine pour regarder ce que tu as en trop.
Chez moi j'ai ce dont je me sers, et pas grand chose de plus.

Ah oui?

Oui.

Et quand le gestionnaire de paquetages prend comme base de référence ce
qu'il y sur les CD d'install (cas typique, on peut faire le même
raisonnement avec un mirroir), et que le libmachinchose qui se trouve sur
les CD est trop ancien, tu te tapes tout à la main, recherche des
libmachinchose sur le net comprise...

Si tu ne sais pas configurer ton gestionnaire de packages, ne t'en
prends qu'à toi.

Mais c'est mon navigateur que je veux upgrader, pas mon système! La
nuance est quand même de taille!

Absolument pas. Si le programme a besoin de bibliothèques récentes, il
faut installer les bibliothèques récentes, tu n'y couperas pas. Dans ces
conditions, autant les installer globalement plutôt qu'isolément comme
tu le proposes : au moins ce sera déjà fait pour le prochain programme.

De même, réinstaller un OS pour upgrader un pauvre programme, ça
ne te semble pas "excessif"? Moi, si!

Qui parle de réinstaller ?

Toutes les distrib à base de paquetages ont ce genre de problèmes

Non.

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

Ca me rappelle d'ailleurs ce que l'on faisait sous DOS et OS/2: chaque
programme s'installait dans son répertoire sans embeter les autres,et
désinstaller un programme revenait à en supprimer le répertoire. D'après
ce que j'en ai vu, les Macintosh (y compris OS X) fonctionnent aussi de
cette manière.

Il y a mieux :
http://zero-install.sourceforge.net/

Avec Zero Install, il suffit d'executer /uri/0install/logiciel.org pour
telecharger (si c'est la 1ere fois) et lancer ton logiciel.
Et cela gere bien sur les dependances, tous les programmes qui ont besoin
de la libtruc version2 ouvriront /uri/0install/libtruc.org/version2.
J'ai pas encore teste, mais ca a l'air interessant ...

Michel Talon s'est exprimé en ces termes:

Oui, pourquoi pas? Sur un disque de 120 gigs, qu'est ce que ça peut bien
me faire d'avoir 20 gigs de système?

En supposant que le système pourrait tenir sur 10 Go, tu perds 8.33%
d'espace disque, ce qui est relativement dommage. Ta vision de
l'informatique me fait peur, j'espère que tu ne raisonnes pas pareil
pour le reste. Genre "l'eau ne coute pas cher, qu'est ce que ca peut
faire que je laisse un robinet ouvert toute la journée ?" ou "Y'a des
millions de sacs plastique dans la nature, qu'est-ce que ça peut faire
que j'y laisse les miens".


--
<bearclaw> tain, je dois avoir une evaluation version de xchat y'a pleins de
cases qui sont grisés...

Michel Talon s'est exprimé en ces termes:

Mais oui, pour moi la médiocrité c'est
de penser qu'on a fait oeuvre utile, voire même qu'on a fait quelque
chose, quand on a découpé en tronçons un logiciel que l'auteur n'a pas
prévu de livrer découpé. La moindre des politesses envers l'auteur,
c'est de laisser les headers qu'il a mis, et les docs qu'il a pondues
(dans le cas heureux où il y en a), l'espace disque ça ne coute rien.

Selon ton système de valeurs ça ne coute probablement pas grand chose
(parce qu'il est stupide de dire que ça ne coute rien), mais je connais
un paquet de gens qui seraient très loin d'être de ton avis.


--
<bearclaw> tain, je dois avoir une evaluation version de xchat y'a pleins de
cases qui sont grisés...

Jerome Lambert s'est exprimé en ces termes:

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.

Suis passé de Mozilla 0.9 à 1.0 à 1.1 à 1.2 à 1.3 à 1.4 sans souci. La
faute à pas de chance, dans ton cas, dirais-je.


--
<bearclaw> tain, je dois avoir une evaluation version de xchat y'a pleins de
cases qui sont grisés...

Nicolas George <george@clipper.ens.fr> wrote:

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.

Pourquoi? Toi qui es un si grand partisan du découpage, qu'est-ce que ça
peut bien te faire qu'on ait mis des fonctions spécifiques réentrantes
dans une librairie séparée au lieu de les mettre en vrac dans la libc?
Comme si Linux n'avait pas découpé un tas de choses hors de la libc de
façon tout aussi arbitraire.


asmodee% ar t libc_r.a
uthread_yield.o
uthread_waitpid.o
uthread_wait.o
uthread_vfork.o
.....
uthread_fd.o
uthread_cond.o
uthread_cancel.o
uthread_find_thread.o

Mais tu peux aussi utiliser libthread

asmodee% ar t libthr.a
thr_error.o
thr_yield.o
thr_suspend_np.o
thr_setschedparam.o
....
thr_printf.o
_curthread.o

et aussi libkse

asmodee% ar t libkse.a
thr_writev.o
thr_write.o
thr_waitpid.o
thr_wait4.o
thr_wait.o
thr_vfork.o
....
thr_error.o
lock.o
thr_printf.o

selon le modèle de threading que tu veux. Tu as même un mécanisme
(man libmap.conf) pour rediriger programme par programme ou par défaut
vers la librairie de thread que tu veux. Comment tout celà serait-il
possible sans découper ces librairies hors de libc?

Quand à deux versions de la libc dans le même programme c'est se moquer.

Je trouve aussi. FreeBSD est vraiment une merde.

Sauf que je n'y crois pas une seconde.

asmodee% ldd /usr/X11R6/lib/firebird/lib/mozilla-1.4b/MozillaFirebird-bin

libc_r.so.5 => /usr/lib/libthr.so.1 (0x2808a000)
libmozjs.so => /usr/X11R6/lib/firebird/lib/mozilla-1.4b/libmozjs.so (0x2809b000)
libxpcom.so => /usr/X11R6/lib/firebird/lib/mozilla-1.4b/libxpcom.so (0x28118000)
libplds4.so => /usr/X11R6/lib/firebird/lib/mozilla-1.4b/libplds4.so (0x281ff000)
libplc4.so => /usr/X11R6/lib/firebird/lib/mozilla-1.4b/libplc4.so (0x28202000)
libnspr4.so => /usr/X11R6/lib/firebird/lib/mozilla-1.4b/libnspr4.so (0x28207000)
libgtk12.so.2 => /usr/X11R6/lib/libgtk12.so.2 (0x2823a000)
libgdk12.so.2 => /usr/X11R6/lib/libgdk12.so.2 (0x28384000)
libgmodule12.so.3 => /usr/local/lib/libgmodule12.so.3 (0x283bc000)
libglib12.so.3 => /usr/local/lib/libglib12.so.3 (0x283bf000)
libintl.so.4 => /usr/local/lib/libintl.so.4 (0x283e4000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x283ec000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x283f4000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x28402000)
libm.so.2 => /lib/libm.so.2 (0x284c8000)
libstdc++.so.4 => /usr/lib/libstdc++.so.4 (0x284e1000)
libc.so.5 => /lib/libc.so.5 (0x2859f000)
libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28676000)

Je ne vois qu'une seule libc, et je vois la librairie réentrante
redirigée vers libthr par le mécanisme libmap.conf.

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.

C'est surtout que le dynamic loader de versions récentes est
incompatible avec des libc trop vieilles, et que donc tu l'as dans l'os
complètement. Une chose qui ne s'est jamais produite avec FreeBSD où tu
peux faire tourner sur les versions les plus récentes des programmes
datant du tout début de FreeBSD, à condition bien sûr d'avoir gardé les
libc correspondantes (mais elles existent en port). C'est encore plus
vrai pour Solaris où la libc ne bouge pas purement et simplement. S'il y
a un système qui est une grosse merde à ce niveau c'est bien Linux, et
ce à cause de U. Drepper qui est un semeur de zone incroyable.

Pour ce qui est des performances

Ce ne sont pas les performances brutes qui m'intéressent.

Bien sûr, tu viens pinailler sur de l'espace disque dont personne n'a
rien à faire et qu'au mieux tu vas remplir de porn, si jamais il y a un
jour quelque chose dessus, et tu te fous complètement de savoir si la
machine est une mollasse parceque Linus T. a décidé
d'optimiser le système pour qu'il donne de bons scores sous bonnie,
quitte à ce qu'il se traîne dés qu'il y a une charge >= 1.5.



--

Michel TALON

Le Wed, 07 Apr 2004 23:07:09 +0000, Nicolas George a écrit :

Et quand le gestionnaire de paquetages prend comme base de référence ce
qu'il y sur les CD d'install (cas typique, on peut faire le même
raisonnement avec un mirroir), et que le libmachinchose qui se trouve sur
les CD est trop ancien, tu te tapes tout à la main, recherche des
libmachinchose sur le net comprise...

Si tu ne sais pas configurer ton gestionnaire de packages, ne t'en
prends qu'à toi.

Il pointe vers les fichiers qui lui ont servi lors de l'install. Ca me
parait coherent comme configuration, non?

Mais c'est mon navigateur que je veux upgrader, pas mon système! La
nuance est quand même de taille!

Absolument pas. Si le programme a besoin de bibliothèques récentes, il
faut installer les bibliothèques récentes, tu n'y couperas pas. Dans ces
conditions, autant les installer globalement plutôt qu'isolément comme
tu le proposes : au moins ce sera déjà fait pour le prochain programme.

D'accord, mais j'ai l'impression qu'une distribution est un ensemble de
paquets coherents à une date d pour des versions v des programmes.
Si on a le malheur de vouloir installer un programme qui n'était pas
prévu lors de la création de cette distrib, genre rpm trouvé sur
rpmfind, bonjour la prise de tête.

Amha une seule distrib me semble ignorer ces problemes, c'est la Debian,
pour la simple raison que (presque) tous les paquetages sont prévus dès
le départ...

Enfin, il "suffit" effectivement de mettre à jour sa distrib de version n
à version n+1, mais à ce rythme-là on rentre dans des procédés
Windowziens (toujours plus gourmand, plus lourd) pour finalement arriver
à "comme la machine se traine, il faut en changer".
Déja que ma machine tire la langue avec KDE 3.0, j'ose pas imaginer ce
que ça donne avec KDE 4...

Jerome.

On 2004-04-08, Michel Talon <talon@lpthe.jussieu.fr> wrote:

Bien sûr, tu viens pinailler sur de l'espace disque dont personne n'a
rien à faire et qu'au mieux tu vas remplir de porn, si jamais il y a un
jour quelque chose dessus, et tu te fous complètement de savoir si la
machine est une mollasse parceque Linus T. a décidé
d'optimiser le système pour qu'il donne de bons scores sous bonnie,
quitte à ce qu'il se traîne dés qu'il y a une charge >= 1.5.

Espace disque dont *TU* n'as rien à faire, nuance.
Je ne te comprends pas, des packages découpés finement ne t'empechent
pas d'avoir tout ce que tu veux, par contre un gros package fourre tout
empeche potentiellement du monde de l'utiliser.
Pourquoi militer alors pour la deuxième solution alors que le quart du
temps que tu passes à écrire sur ce sujet te suffirait pour savoir faire
tout ce que tu veux avec un système de packages quelconque ?

--
Irvin Probst
There are 10 types of people in the world... those who understand binary
and those who don't.

Irvin Probst <irvin@trinity.irvinig.org> wrote:

Pourquoi militer alors pour la deuxième solution alors que le quart du
temps que tu passes à écrire sur ce sujet te suffirait pour savoir faire
tout ce que tu veux avec un système de packages quelconque ?

Je milite pour cette solution parceque je pense que ce découpage est une
perte de temps totale à la fois pour celui qui prépare les paquets et
pour tous les utilisateurs. Je ne suis pas loin de penser que le système
que préconise un autre posteur: mettre chaque programme dans sa propre
directory avec tout le bazar dont il a besoin, tous ses fichiers de
confs et de données est la meilleure solution, en d'autres termes,
supprimer tout système de paquetage. Ce n'est pas autre chose que ce qui
se fait couramment avec les programmes Java où on fourre tout dans un
jar, avec l'immense avantage qu'il suffit de faite java -jar toto.jar
pour que "ça marche" (y compris sur toute variante de Linux, FreeBSD,
Windows, Mac OS X) sans se poser plus de question. C'est l'une des
options envisagées pour le futur système de paquetages de dragonflybsd,
avec des jeux futés sur le vfs. Une fois qu'on a compris (ce qui ne
semble pas être encore bien rentré dans toutes les têtes) que l'espace
disque est un non problème, il y a beaucoup d'options.


--

Michel TALON