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

Michel Talon wrote:

Selon la technique habituelle à Linux, ils
ont pillé toutes les idées qui marchaient bien dans les autres systèmes
et les ont surajoutées à leur tacot

Comment? Tu n'écris plus «ils ont pillé à FreeBSD»? Au fait, ils en sont
rendus où avec XFS? Ce sera pour 2020 ou 2040?

Quant au pillage, je suis tout à fait pour. Ce n'est pas ça l'Open Source?
J'ai malheureusement l'impression que tout le monde cherche toujours à
réinventer la roue.

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

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?

Tu pourrais te dispenser des ad-hominem gratuites, surtout quand tu ne vaux
pas mieux toi-même.

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,

D'une part, cette affirmation est très exagérée. Les problèmes avec des DLL
qui viennent se faire écraser n'importe comment, on en entend parler à tout
bout de champ concernant windows, par exemple.

D'autre part, si la contrepartie est une baisse de réactivité, alors les
gens ne s'en plaindront pas simplement par manque d'un point de
comparaison : l'appréciation de la réactivité est une question d'habitude et
de feeling, pas quelque chose qui se mesure dans l'absolu. J'étais très
content de la réactivité de mon fixe basé sur un Athlon 1200 jusqu'au moment
où j'ai upgradé mon portable en Thurion64 ; et depuis que j'ai upgradé le
fixe à son tour, c'est le portable dont je trouve qu'il manque de
réactivité. Pourtant, il n'est pas devenu plus lent.

alors que l'une des lamentations
courantes des utilisateurs de Linux c'est le DLL hell

Non. Ça l'était il y a cinq ans, quand Debian était la seule distribution à
avoir un outil de résolution des dépendances.. Maintenant que toutes ont
leur propre yum/urpmi/swaret/whatever, le problème est beaucoup plus
anecdotique.

Yugo <yugo@noemailaddress.com> wrote:

Michel Talon wrote:

Selon la technique habituelle à Linux, ils
ont pillé toutes les idées qui marchaient bien dans les autres systèmes
et les ont surajoutées à leur tacot

Comment? Tu n'écris plus «ils ont pillé à FreeBSD»? Au fait, ils en sont
rendus où avec XFS? Ce sera pour 2020 ou 2040?

FreeBSD a certainement ses problèmes. La richesse de Linux en systèmes
de fichiers est un gros avantage. Et la journalisation est clairement
une meilleure solution que softupdates. En ce qui concerne reiserfs et
xfs il y a un support en lecture seule dans FreeBSD, ce qui est
évidemment moins bien qu'un support rw, mais mieux que rien. Si je
regarde sous Linux, le support de UFS est censément rw, mais en pratique
ro est la seule chose raisonnable, il y a, ô miracle un support rw de
ntfs, mais dés la première fois que je l'ai utilisé il a copé 2 fichiers
sur 10 et a refusé de copier les autres (au moins il n' arien bouzillé).
Donc c'est à peine un peu mieux.

Quant au pillage, je suis tout à fait pour. Ce n'est pas ça l'Open Source?
J'ai malheureusement l'impression que tout le monde cherche toujours à
réinventer la roue.

Si, l'opensource c'est le pillage, mais quand il s'agit à la fois de
dénigrer les produits "concurrents", par exemple d'exploiter les
problèmes de Hans Reiser pour dénigrer reiserfs et dans le même temps de
piller les innovations de ces systèmes concurrents pour arriver à leur
niveau de performance, ça ressemble fortement à de la malhonnêteté.


--

Michel TALON

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

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

Euh, si. Il y en a beaucoup, mais elles ne sont souvent pas très grosse
individuellement. Je viens de regarder le firefox qui tourne sur mon
système : environ 200 ko par bibliothèque en moyenne.

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

C'est vrai, mais ça vient en second après les accès disque. L'utilisateur
devant sa babasse, il s'en fiche, de savoir qu'il attend à cause d'une
bibliothèque qui n'était pas dans le cache ou à cause de l'édition des
liens : il attend, point.

D'autre part, il y a des solutions à l'édition dynamique des liens qui ne
passent pas par l'abandon des avantages des bibliothèques partagées. Le
prelink, par exemple.

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.

Oui, c'est là toute la différence sur ce benchmark, mais ce benchmark n'est
pas significatif dans le contexte qui nous intéresse ici : en utilisation
normale, les applications ne sont pas toujours dans le cache. Et justement,
une application liée de manière partagée sera, statistiquement, en plus
grande proportion dans le cache qu'une application liée statiquement.

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

Ce n'est pas de ses propos que je parle, mais de l'interprétation que tu en
fais.

Ce qui est faux et archi faux.

Tu le dis à loisir, mais ça ne le rend pas vrai. Tu as évoqué 50 Mo par
seconde pou un disque dur actuel. Tu pense qu'un processeur actuel fait de
l'édition de liens à quelle vitesse, à ton avis ?

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.

Je ne pense pas. Le bureau qui râme pendant cinq minutes après la fin
apparente du boot est à mon avis nettement plus horripilant qu'un boot
clairement marqué, à cause de l'absence de feedback.

Michel Talon wrote:

FreeBSD a certainement ses problèmes. La richesse de Linux en systèmes
de fichiers est un gros avantage. Et la journalisation est clairement
une meilleure solution que softupdates.

Fcold-iens, Fcold-ienens, sauvegardez-la bien celle-là!

En ce qui concerne reiserfs et
xfs il y a un support en lecture seule dans FreeBSD, ce qui est
évidemment moins bien qu'un support rw

Tu trouves :)

le support de UFS est censément rw, mais en pratique
ro est la seule chose raisonnable,

Honnêtement, je n'ai jamais essayé, et ce ne sera pas demain la veille.

il y a, ô miracle un support rw de
ntfs, mais dés la première fois que je l'ai utilisé il a copé 2 fichiers
sur 10 et a refusé de copier les autres (au moins il n' arien bouzillé).
Donc c'est à peine un peu mieux.

Et c'était quand ta «première fois»? Il n'y a pas longtemps que le NTFS est
officiellement reconnu rw.

Quant au pillage, je suis tout à fait pour. Ce n'est pas ça l'Open Source?
J'ai malheureusement l'impression que tout le monde cherche toujours à
réinventer la roue.

Si, l'opensource c'est le pillage, mais quand il s'agit à la fois de
dénigrer les produits "concurrents", par exemple d'exploiter les
problèmes de Hans Reiser pour dénigrer reiserfs

Quel développeur Linux a dénigré ReiserFS en exploitant les problèmes de Hans
Reiser? Sur les groupes, il se raconte n'importe quoi.

et dans le même temps de
piller les innovations de ces systèmes concurrents pour arriver à leur
niveau de performance, ça ressemble fortement à de la malhonnêteté.

Ce serait donc ReiserFS que ext4 aurait pillé? Tu as des références là-dessus?

Yugo <yugo@noemailaddress.com> wrote:

Michel Talon wrote:

FreeBSD a certainement ses problèmes. La richesse de Linux en systèmes
de fichiers est un gros avantage. Et la journalisation est clairement
une meilleure solution que softupdates.

Fcold-iens, Fcold-ienens, sauvegardez-la bien celle-là!

Ca fait longtemps que je dis ça et ici même. Je suis fort aise de voir
que maintenant, ce point de vue est partagé à peu prés unanimement par
les développeurs FreeBSD et DragonflyBSD, il n'y a que des utilisateurs
"lambda" qui maintiennent encore le contraire. Question performance,
softupdates est peut être légèrement plus performant que la
journalisation, mais question sécurité en cas de crash, softupdates a
amplement démontré sur plusieurs années, que ce n'était *pas* la
solution. Ce qui était un ennui avec des petits disques, je parle du
fsck en background, devient totalement rédhibitoire avec des gros
disques, chose qui était prévisible dés le début. A ça se sont ajoutés
des bugs perpétuels, et maintenant on découvre que softupdates taxe
fortement le SMP (car il faut verrouiller ses structures de données).
Bref c'était une fausse bonne idée, comme il y en a beaucoup.

Et c'était quand ta «première fois»? Il n'y a pas longtemps que le NTFS est
officiellement reconnu rw.

La première fois, ça veut dire dés la première fois (et unique) que je
l'ai utilisé, sur mon portable sous Ubuntu, il y a quelques jours. La
solution que j'ai utilisée c'est de rebooter sous Windows et faire venir
explore2fs. Ca au moins, ça marche.

et dans le même temps de
piller les innovations de ces systèmes concurrents pour arriver à leur
niveau de performance, ça ressemble fortement à de la malhonnêteté.

Ce serait donc ReiserFS que ext4 aurait pillé? Tu as des références là-dessus?

Je n'ai pas dit ça, j'ai dit que les tenants de ext2/3 ont
systématiquement dénigré les autres systèmes de fichiers, alors
qu'objectivement la seule caractéristique comparée qu'avait ext2/3 c'est
d'être beaucoup moins performant. Il a fallu que IBM sponsorise une
équipe complète de développeurs de très haut niveau pour amener ext3 au
même niveau de performances que les autres, en pillant leurs meilleures
idées. En fait le ext3 moderne n'a pas grand chose à voir avec le ext3
ancien, si ce n'est la compatibilité ascendante.

--

Michel TALON

Le Sun, 21 Jan 2007 18:25:49 +0000, Michel Talon a écrit :

il y a, ô miracle un support rw de ntfs, mais dés la
première fois que je l'ai utilisé il a copé 2 fichiers sur 10 et a
refusé de copier les autres (au moins il n' arien bouzillé). Donc c'est
à peine un peu mieux.

j'ai malencontreusement fait tourner pendant quelques semaines un Linux
en rw sur un SAN NTFS partagé par 7 ou 8 machines NT4, et Linux a
joyeusement écrit et rien bousillé :) Le support rw du NTFS de NT4 est
donc apparemment parfait :)

--
Sutor ne ultra Crepidam.

Le Sun, 21 Jan 2007 19:48:10 +0000, Michel Talon a écrit :

je parle du fsck
en background, devient totalement rédhibitoire avec des gros disques,

Avec les tailles qu'on peut obtenir dès aujourd'hui, un fsck _tout_court_
est devenu rédhibitoire. Un scan poussé d'un FS de quelques centaines de
To prend plus nettement plus longtemps qu'un mkfs suivi d'une restauration
(si on a le matériel qui va avec, bien sûr).
La capacité des disques a explosé, le débit aussi, mais les temps
d'accès n'ont quasiment pas bougé depuis 10 ans (une poignée de
millisecondes, en gros). Et les débits ont augmenté 10 fois moins vite
que les capacités, mais c'est surtout en terme d'IOPS que se situe le
problème.

--
Désormais, pour les nations et pour les peuples, une goutte de pétrole
a la valeur d'une goutte de sang.
Georges Clémenceau.

Le Sun, 21 Jan 2007 12:53:13 -0500, Yugo a écrit :

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

Si, pour les petits fichiers. Mais comme je l'ai mentionné, il est vrai
qu'avec du matériel "limite" reiserfs est dangereux.

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é? :)

Non, bug noyau mangeur de filesystem... C'était un noyau un peu
"expérimental", il est vrai.

--
De longs désirs, une longue admiration sans espérance, voilà le moyen
d'adorer les femmes, et de rendre l'amour une passion délicieuse!
N. Rétif de la Bretonne.

Le Sun, 21 Jan 2007 17:13:33 +0000, Miod Vallat a écrit :

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

Tu viendras quand même?

--
In girum imus nocte ecce et consumimur igni