mais que se passe-t-il dans fr.comp.os.linux.debats ?

Jerome Lambert , dans le message <51hgvkF1kp060U1@mid.individual.net>, a
écrit :

Dans le cas de MacOS X, une base commune fournie par l'OS, les
applications sachant quoi y trouver au minimum. Si elles veulent plus,
elles l'apportent elles-même en gardant leurs petits fichiers dans leur
répertoire, sans aller trifouiller dans le système. Celui reste donc
intact, et l'installation/désinstallation consiste à copier/supprimer
l'application sur le disque dur, en se préoccupant uniquement de
respecter les recommandations de version minimale de l'OS. D'après ce
que j'ai vu, PC-BSD fonctionne grosso-modo via le même principe.

En d'autres termes, un mélange d'immobilisme et d'inefficacité...

Jerome Lambert , dans le message <51hgvkF1kp060U1@mid.individual.net>, a

Dans le cas de MacOS X, une base commune fournie par l'OS, les
applications sachant quoi y trouver au minimum. Si elles veulent plus,
elles l'apportent elles-même en gardant leurs petits fichiers dans leur
répertoire, sans aller trifouiller dans le système. Celui reste donc
intact, et l'installation/désinstallation consiste à copier/supprimer
l'application sur le disque dur, en se préoccupant uniquement de
respecter les recommandations de version minimale de l'OS. D'après ce
que j'ai vu, PC-BSD fonctionne grosso-modo via le même principe.

En d'autres termes, un mélange d'immobilisme et d'inefficacité...

A voir à l'usage: en 2 ans de MacOS X, je n'ai eu *aucun* problème
d'installation/désinstallation de programmes, chose que je n'ai connue
ni sous Linux, ni sous Windows, alors la supériorité des autres méthodes
ne me semble que toute théorique...

"Nicolas George" <nicolas$george@salle-s.org> a écrit dans le message
de news: eoveuj$2ka3$2@nef.ens.fr

"pehache grmpf" , dans le message

Pour augmenter la sécurité et avoir 10 points de plus, FF devrait
interdire d'aller sur internet.

Dommage qu'outlook n'interdise pas d'aller sur les news.

Prononcée par un défenseur du "libre", cette petite phrase est savoureuse...

--
pehache
enlever NOSPAM. etc... pour répondre / remove NOSPAM... to reply
http://pehache.free.fr/public.html

Jerome Lambert , dans le message <51hhejF1j26eiU1@mid.individual.net>, a
écrit :

A voir à l'usage: en 2 ans de MacOS X, je n'ai eu *aucun* problème
d'installation/désinstallation de programmes, chose que je n'ai connue
ni sous Linux, ni sous Windows, alors la supériorité des autres méthodes
ne me semble que toute théorique...

D'un autre côté, macos est notoirement moins réactif que Linux sur une même
machine. Chacun son choix.

Il n'y a pas de stand BSD à ce salon cette année.

Rhôôô mais comment ça se fait ?

A priori un micmac d'organisation. M'enfin ça n'a pas l'air très clair

non plus.

Nicolas George <nicolas$george@salle-s.org> wrote:

Michel Talon, dans le message <eovvb1$2lcg$1@asmodee.lpthe.jussieu.fr>,
a écrit :

Totalement faux. Un disque peut débiter 40 Mo/s, donc en une seconde
amener toutes les librairies partagées de KDE en mémoire.

C'est le débit brut. Il faut compter nettement moins quand on a un
filesystem et des fichiers relativement petits.

Certes, mais enfin quand tu vois les librairies de KDE, de OpenOffice ou
de mozilla c'est pas des petits formats non plus.

- quitte ta session KDE ;
- depuis le réseau ou la console, force la lecture de gros fichiers pour
virer les bibliothèques de KDE du cache ;
- lance une session KDE, et chronomètre le temps qu'elle met à s'ouvrir ;
- quitte à nouveau la session ;
- lance immédiatement une nouvelle session, et chronomètre le temps.

Tu constateras que la seconde ouverture est _beaucoup_ plus rapide que la
première.

L'essai en question je l'ai fait bien des fois, et ce que tu dis est
exact, il y a évidemment un temps de chargement depuis le disque. Mais
il y a aussi un temps de résolution des symboles qui peut être tout à
fait conséquent notamment pour le C++.
http://dot.kde.org/1042261456/1042284669/1042289649/1042299867/1042301998/1042311150/
par exemple:
linking is *every bit* as bad of an issue as kde developers make it
sound like. fully 50% of the cpu time during a kde login (on my system,
probably closer to 30% on yours - I have some local work not yet
committed in fontconfig that really helps speed that up, raising the
percentages for everything else) is spent, in the linker, before
reaching main().

Je ne sais pas si John Dyson sait de quoi il parle, mais toi, ce n'est pas
le cas, parce que les benchmarks que tu évoques ici sont complètement
non-pertinents : lors de l'exécution d'un ./configure, les shells invoqués
le sont toujours depuis le cache.

Oui et alors? Si c'est un shell dynamique, il faut quand même
réappliquer le linker dynamique sur chaque nouveau shell, alors qu'avec
un shell statique, il est tout autant dans le cache, mais il est prêt à
démarrer immédiatement. C'est là toute la différence. Tu ferais mieux
une fois de plus de downgrader le ton de tes interventions quand tu parles
du mec qui a développé la totalité de la VM de FreeBSD, et qui est un
hacker mille fois plus compétent que la totalité des développeurs de
Linux réunis, la preuve étant qu'en dix ans ils n'ont pas réussi à
faire aussi bien que lui.

Ça ne contredit donc absolument pas mon affirmation, qui est que le temps
d'édition dynamique des liens est négligeable devant le temps de chargement
depuis le disque.

Ce qui est faux et archi faux.

Dans l'ensemble, je trouve la situation sous Linux très satisfaisante.

Pas moi, et je suis loin d'être le seul.

Windows boote plus vite, mais
tout n'est pas fonctionnel loin de là quand le "desktop" apparaît.

Tu permets que je traduise ta phrase en français ? « Windows boote plus
lentement. » Voilà, c'est plus clair comme ça.

Sauf que pour le péquin qui est devant l'écran il a l'air de booter plus
vite et c'est la seule chose qui compte.

--

Michel TALON


Voici ce que j'ai pu trouver des vieilles discussions de John Dyson


What do people think the advantage of dynamic
linking is?

De : John Dyson - afficher le profil
Date : Ven 22 août 2003 04:44
E-mail : John Dyson <s...@jdyson.com>
Groupes : comp.unix.bsd.freebsd.misc

Dave Uhring wrote:

On Thu, 21 Aug 2003 17:30:08 -0500, John Dyson wrote:

I sure hope that the motivation for a dynamic root isn't the same
as the silly building of the GCC compiler as a shared object!!!

GCC-3.3 built itself from 2.95.3 on Solaris 10-beta with no problems.
The
compiler is hardly a shared object. It is not static linked to any
system
library.

I don't think that you understand what I meant: they were building the
compiler engine itself shared!!! EEEK!!! That has horrible register
allocation
overhead, and the compile times were significantly longer. (The
compiler
'phases' resided in a shared object, thereby creating more register
pressure, more spills and slower compile times.) I seem to remember
compiler
speed decreases on the order of 20-30% or more!!! The typical shared
lib scheme on X86 machines TENDS to cause more register pressure and
uglier (slower code), even ignoring the cache occupancy issues due
to the shared libraries being more sparse than a properly built
archive library. In the case of the compiler, just linking with the
libc type libs doesn't really affect performance much, because the
compiler is already large and I/O rates are more limited by the
compiler operation itself (and not the inefficiency of the libraries.)

Building everything shared is yet another performance regressive step
that makes faster machines appear to be slower than they really should
be :-).

Removal of static linked binaries seems to be a "good" thing. I'm
still
awaiting the CVS tag RELENG_5.

Again, why is it a good thing? Note that the actual image in memory is
larger when linking medium/small programs as 'shared', and the start-up
times are longer, and fork/exec times (for programs that do forks) are
longer... Library only bugfixes are mostly specious for the small api's
like libc... For Xwindows or DirectX it might make sense to fix some
bugs in the
libraries. EVEN THE CACHE FOOTPRINTS ARE LARGER WHEN LINKING PROGRAMS
SHARED!!! There is possibly lost 'common knowledge' over time. (The
Xwindows library is seldom a performance bottleneck, but stdio can
certainly be a performance bottleneck on small cusp type programs.)

I sure HOPE that if they make the default 'everything shared', that the
reason is for maintenance reasons (implausible in reality), and not
for some misguided improvement in performance!!! If there is a
possibility
that the system API will change (system calls might change), then
changing
libc could be useful for that, but is it really that likely to need to
change the API that much?

In reality (except for the possibility of fixing bugs in the libraries),
it would be better to build everything that doesn't use the 'big
X,perl,etc libs'
static by default (assuming that
performance is paramount, and disk space is relatively unimportant.)

Last time that I heard, disk space is dirt cheap!!! :-). I guess that
an incompetently sized root or usr filesystem will cause problems, but
I seldom trust the default sizing (even if I don't rebuild the
apropriate
programs -static.)

The only real advantage is a small amount of disk space (in reality, the
larger sized disk imaged static programs use less memory!!!) Even the
STARTUP TIMES are longer for the smaller dynamically linked programs.

Again, where is the advantage for building the typical /sbin, /bin
binaries? Unless there is a specific reason, it appears to be typical
of the uninformed attempt of somehow 'saving resorces' because part
of the images are shared.

So, I sure hope that performance isn't being used as a reason for
building
the system 'shared' -- that is an almost guaranteed loss except in very
limited cases.

John

Nicolas George <nicolas$george@salle-s.org> wrote:

Jerome Lambert , dans le message <51hgvkF1kp060U1@mid.individual.net>, a
écrit :

Dans le cas de MacOS X, une base commune fournie par l'OS, les
applications sachant quoi y trouver au minimum. Si elles veulent plus,
elles l'apportent elles-même en gardant leurs petits fichiers dans leur
répertoire, sans aller trifouiller dans le système. Celui reste donc
intact, et l'installation/désinstallation consiste à copier/supprimer
l'application sur le disque dur, en se préoccupant uniquement de
respecter les recommandations de version minimale de l'OS. D'après ce
que j'ai vu, PC-BSD fonctionne grosso-modo via le même principe.

En d'autres termes, un mélange d'immobilisme et d'inefficacité...

En d'autres termes, chassez le naturel il revient au galop, tu ne peux
pas t'empêcher de parler de façon prétentieuse et péremptoire et dans
la plupart des cas c'est pour dire des conneries. A chaque fois je fais
des efforts surhumains pour rester poli, mais avec toi c'est
radicalement impossible. On ne t'a jamais enseigné le B-A-BA minimal
de la vie en société à l'ENS? Dans le cas d'espèce, si aussi bien
Windows que Mac OS X et d'autres utilisent des applications packagées en
bloc, dont les gens semblent contents, alors que l'une des lamentations
courantes des utilisateurs de Linux c'est le DLL hell, c'est peut être
pas parceque 99% des gens sont des cons sauf toi qui es un génie, mais
tout simplement parceque les autres ont raison et que les sytèmes de
paquetages "rationnels" à la Linux sont le type de la soit disant bonne
idée qui marche bien dans un monde idéal mais qui est intenable dans le
monde concret, qui nécessite des efforts surhumains pour entretenir une
collection cohérente qui est toujours périmée quand elle devient
satisfaisante.


--

Michel TALON

Nicolas George <nicolas$george@salle-s.org> wrote:

Jerome Lambert , dans le message <51hhejF1j26eiU1@mid.individual.net>, a
écrit :

A voir à l'usage: en 2 ans de MacOS X, je n'ai eu *aucun* problème
d'installation/désinstallation de programmes, chose que je n'ai connue
ni sous Linux, ni sous Windows, alors la supériorité des autres méthodes
ne me semble que toute théorique...

D'un autre côté, macos est notoirement moins réactif que Linux sur une même
machine. Chacun son choix.

Et le micor moyau Mach n'est évidemment pour rien dans ce manque de
réactivité.

--

Michel TALON

Emmanuel Florac wrote:

Dans les benchmarks cités par les dévs d'ext4 dans Linux mag de ce mois,
les performances affichées d'ext2/3/4 sont énormément supérieures à
tous les autres FS dans tous les cas de figure. Je suis parfaitement prêt
à croire qu'il y ait eu des améliorations notables, et même qu'ext3/4
soit désormais plus rapide que les autres, mais je ne crois pas à la
magie : xfs ayant une courbe de performance qui colle au plus près le
matériel sous-jacent, il n'y a tout simplement pas moyen d'aller beaucoup
plus vite que lui (mais très légèrement, c'est possible).

Je constate qu'on ne parle plus guère de ReiserFS...

Quant à la question de la fiabilité, j'y réfléchirai. Cependant je ne
peux pas dire avoir rencontré de nombreux problèmes avec xfs (en tout et
pour tout, 1 seul, en fait), sur environ 500 machines et sur environ 3 ans.

Le UPS n'a pas fonctionné? :)

Nicolas George <nicolas$george@salle-s.org> wrote:

John Dyson avait fait des benchmarks se
scripts "configure" qui lancent une grande quantité de shells, il y
avait des différences tout à fait significatives sur le temps total
d'exécution entre shell statique et dynamique.

Je ne sais pas si John Dyson sait de quoi il parle, mais toi, ce n'est pas

Une autre référence:
http://groups.google.fr/group/mailing.freebsd.security/browse_thread/thread/fde5b2e96b4ea910/154db23ffe3fe717?lnk=st&q=john+Dyson+static+dynamic+linking&rnum=4&hl=fr#154db23ffe3fe717
Snob Art Genre said:

On Wed, 22 Apr 1998, John S. Dyson wrote:

I'll scream terribly loudly if we even passingly consider making a
shell shared!!! Shells are almost never advatageously made shared.

I haven't been watching this discussion carefully, but here
are the costs of shared libs:

fork() performance is slower.
exec() performance is effectively slower (due to ld.so.)
data and shared lib bss is packed much less effectively,
and locality of reference, both at the sub-page level,
and the page level is worse.
Shared libs often require additional page table pages
to map them.

Here are the non-advantages:

Shared libs don't help .text sharing, if a process has more than
a few static occurances (shared .text works really well
on our system.)

Here are the advantages:

Shared libs are great for processes where the libraries are large
relative to the program size.
Shared libs are great for processes that don't have many static
or dynamic instances.


Reiterating, with clarification:

More than 3-4 copies running at the same time: static
Forks like a shell: static
Must be able to run without shared libs: static
If library CPU performance is critical: static
Executes for a "long time", and doesn't fork often: shared
Huge libraries: shared
Not often used: shared