>>>> Pas mal vis-à-vis d'une installation Windows de plusieurs heures et 50
>>>> reboot, d'installations d'anti tout, de recherches de vrais pilotes
>>>> constructeurs, ...
>>> et toujours tout ramener à vos obsessions. Vous êtes un malade !
>>
>> Mais quel est l'intéret d'une telle intervention ?
>
> Rien de plus que ce qu'elle a et beaucoup plus que l'intervention à laquelle
> elle répond.
>
> > Appliquez-vous à
>> vous-même ce que vous attendez des autres, ça nous fera des vacances.
>
> Appliquez le aussi au troll obsessionnel.
La maladie de Monsieur Doucet est contagieuse
De nombreuses personnes, avalant ses écrits, se découvrent tout à coup
porteuses d'une Vérité Dogmatique sur la "chose"
Prêts à impressionner leurs petits frères ou leurs mamans, ils portent
haut les couleurs du Pingouin comme un étendard, s'agenouillant même
devant lui comme devant le veau d'or
La différence est tout de même que le veau était en or, alors que Linux
est en code libre, soit quelque chose qui, en dehors d'un phénomène de
mode (que pour ma part je qualifierai plutôt d'un phénomène de cirque)
ne représente rien)
Le jour, où, effaré, le monde s'apercevra qu'il s'agit d'une
technologie vieille de 40, sa valeur diminuera aussi rapidement que
l'Euro après avoir découvert l'endettement de la Grèce (+celle des pays
qui marchent avec cette monnaie)
Partis de rien, Linux est condamné à arriver à pas grand-chose
Tu crois que les techniciens ont le temps de passer 2 heures à regarder un système booter ?
Pour quoi faire ? La secrétaire s'en occupe.
on sait. avec une passerelle nagios -> excel
JKB
Le 27-05-2010, ? propos de Re: Monsieur Doucet et la Grèce (Où il pourrait aller se faire voir...), Kojak ?crivait dans fr.comp.os.linux.debats :
Le Thu, 27 May 2010 08:52:45 +0000 (UTC), JKB a écrit :
> Sacré Philibert !
Ce n'est pas Philibert, ducon, c'est l'autre !
Heu !
Tu peux m'expliquer, là ? Ne te serais-tu pas trompé d'interlocuteur, par hasard ?
Je croyais répondre à branli-branla... Si mon slrn m'a fait des choses bizarres, je te prie de bien vouloir m'en excuser.
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 27-05-2010, ? propos de
Re: Monsieur Doucet et la Grèce (Où il pourrait aller se faire voir...),
Kojak ?crivait dans fr.comp.os.linux.debats :
Le Thu, 27 May 2010 08:52:45 +0000 (UTC),
JKB <knatschke@koenigsberg.fr> a écrit :
> Sacré Philibert !
Ce n'est pas Philibert, ducon, c'est l'autre !
Heu !
Tu peux m'expliquer, là ? Ne te serais-tu pas trompé d'interlocuteur,
par hasard ?
Je croyais répondre à branli-branla... Si mon slrn m'a fait des
choses bizarres, je te prie de bien vouloir m'en excuser.
Cordialement,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 27-05-2010, ? propos de Re: Monsieur Doucet et la Grèce (Où il pourrait aller se faire voir...), Kojak ?crivait dans fr.comp.os.linux.debats :
Le Thu, 27 May 2010 08:52:45 +0000 (UTC), JKB a écrit :
> Sacré Philibert !
Ce n'est pas Philibert, ducon, c'est l'autre !
Heu !
Tu peux m'expliquer, là ? Ne te serais-tu pas trompé d'interlocuteur, par hasard ?
Je croyais répondre à branli-branla... Si mon slrn m'a fait des choses bizarres, je te prie de bien vouloir m'en excuser.
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
JKB
Le 27-05-2010, ? propos de Re: Monsieur Doucet et la Grèce (Où il pourrait aller se faire voir...), debug this fifo ?crivait dans fr.comp.os.linux.debats :
JKB wrote:
ce qui est _très_ fort avec deux CPU aux fraises sur les deux de la machine ;-)
c'était pas un lsi11 dans la console de boot ?
Non, pas de mémoire (mais c'est vieux, c'était de mémoire un 6220 ou quelque chose de ce genre et je ne suis pas sûr que cette génération ait encore un LSI11.). Il me semble bien que la PAL s'occupait de ce genre de chose.
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 27-05-2010, ? propos de
Re: Monsieur Doucet et la Grèce (Où il pourrait aller se faire voir...),
debug this fifo ?crivait dans fr.comp.os.linux.debats :
JKB wrote:
ce qui est _très_ fort avec deux CPU aux fraises sur les deux de la
machine ;-)
c'était pas un lsi11 dans la console de boot ?
Non, pas de mémoire (mais c'est vieux, c'était de mémoire un 6220 ou
quelque chose de ce genre et je ne suis pas sûr que cette génération
ait encore un LSI11.). Il me semble bien que la PAL s'occupait de ce
genre de chose.
Cordialement,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 27-05-2010, ? propos de Re: Monsieur Doucet et la Grèce (Où il pourrait aller se faire voir...), debug this fifo ?crivait dans fr.comp.os.linux.debats :
JKB wrote:
ce qui est _très_ fort avec deux CPU aux fraises sur les deux de la machine ;-)
c'était pas un lsi11 dans la console de boot ?
Non, pas de mémoire (mais c'est vieux, c'était de mémoire un 6220 ou quelque chose de ce genre et je ne suis pas sûr que cette génération ait encore un LSI11.). Il me semble bien que la PAL s'occupait de ce genre de chose.
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
totof01 wrote: > L'intéret des mainframes est dans la capacité à traiter de nombre uses > transactions simultanées, un accès IO des plus efficaces et une > stabilité à toute épreuve, capitale dans les domaines ou ceux-ci sont > employés.
et le hotplug de la plupart des composants aussi.
Oui, je l'avais oublié. Mais ma liste ne se voulait pas exhaustive.
On 27 mai, 09:33, debug this fifo <de...@fifo.invalid> wrote:
totof01 wrote:
> L'intéret des mainframes est dans la capacité à traiter de nombre uses
> transactions simultanées, un accès IO des plus efficaces et une
> stabilité à toute épreuve, capitale dans les domaines ou ceux-ci sont
> employés.
et le hotplug de la plupart des composants aussi.
Oui, je l'avais oublié. Mais ma liste ne se voulait pas exhaustive.
totof01 wrote: > L'intéret des mainframes est dans la capacité à traiter de nombre uses > transactions simultanées, un accès IO des plus efficaces et une > stabilité à toute épreuve, capitale dans les domaines ou ceux-ci sont > employés.
et le hotplug de la plupart des composants aussi.
Oui, je l'avais oublié. Mais ma liste ne se voulait pas exhaustive.
totof01
On 27 mai, 10:36, JKB wrote:
Le 27-05-2010, ? propos de Re: Monsieur Doucet et la Grèce (Où il pourrait aller se faire voir.. .), totof01 ?crivait dans fr.comp.os.linux.debats :
> On 27 mai, 06:42, ST wrote: >> totof01 a perdu son temps a nous dire:
>> > Va faire un tour dans les banques, intéresse-toi à des trucs com me le >> > nombre de transactions que peuvent traiter ces engins, la gestion de s >> > disques, la haute disponibilité demandée par les applis qui tour nent >> > dessus et on en reparle après. Même Linux ne serait pas capable de les >> > remplacer de façon aussi efficace.
>> En meme temps, Linux n'est qu'un Unix. C'est a dire un amas de couches >> qui s'empilent les unes sur les autres et ou le niveau de performance >> reste tres moyen. > Oui, mais l'avantage de Linux, c'est que ça reste un système ouvert > que l'on peut adapter en fonction de ses besoins. On peut désactiver > les couches qui ne nous intéressent pas, par exemple, ou optimiser > certaines partie du noyau pour augmenter les perfs. C'est plutôt rare , > mais je sais que ça se fait dans certains labos par exemple.
Ouaips, enfin, si tu veux des performances brutes, regard e du côté de NetBSD. Le noyau est compact et ne contient que le n écessaire.
Je suis déjà allé voir le noyau, que j'ai trouvé bien plus clair qu 'un noyau Linux. Je reconnais cependant que ça fait longtemps que je ne m'y suis plus intéressé. Et à l'époque ou je m'y intéressais j'av ais cru comprendre que sous Linux on préférait sacrifier la portabilité à la performance, et que certains bouts de code NetBSD quant à eux favorisaient la portabilité au détriment de la performance, et que ça pouvait expliquer en partie les moindres performances de NetBSD par rapport à Linux.
Patcher du Linux, j'ai fait, et je continue à faire lor sque je n'ai pas le choix. Vu la stabilité de l'API du noyau, c'est une gageure : lorsque tu arrives à stabiliser ton patch, il est obsol ète vis à vis du nouveau noyau et tu peux recommencer...
Effectivement, si on veut optimiser du NetBSD, et le patcher pour améliorer les perfs en optimisant les bouts de codes ajoutés pour la portabilité, ça doit à mon avis être plus simple étant donné qu e les API ne changent pas tousles 36 du mois ...
On 27 mai, 10:36, JKB <knatsc...@koenigsberg.fr> wrote:
Le 27-05-2010, ? propos de
Re: Monsieur Doucet et la Grèce (Où il pourrait aller se faire voir.. .),
totof01 ?crivait dans fr.comp.os.linux.debats :
> On 27 mai, 06:42, ST <s...@democrate.org> wrote:
>> totof01 a perdu son temps a nous dire:
>> > Va faire un tour dans les banques, intéresse-toi à des trucs com me le
>> > nombre de transactions que peuvent traiter ces engins, la gestion de s
>> > disques, la haute disponibilité demandée par les applis qui tour nent
>> > dessus et on en reparle après. Même Linux ne serait pas capable de les
>> > remplacer de façon aussi efficace.
>> En meme temps, Linux n'est qu'un Unix. C'est a dire un amas de couches
>> qui s'empilent les unes sur les autres et ou le niveau de performance
>> reste tres moyen.
> Oui, mais l'avantage de Linux, c'est que ça reste un système ouvert
> que l'on peut adapter en fonction de ses besoins. On peut désactiver
> les couches qui ne nous intéressent pas, par exemple, ou optimiser
> certaines partie du noyau pour augmenter les perfs. C'est plutôt rare ,
> mais je sais que ça se fait dans certains labos par exemple.
Ouaips, enfin, si tu veux des performances brutes, regard e du côté
de NetBSD. Le noyau est compact et ne contient que le n écessaire.
Je suis déjà allé voir le noyau, que j'ai trouvé bien plus clair qu 'un
noyau Linux. Je reconnais cependant que ça fait longtemps que je ne
m'y suis plus intéressé. Et à l'époque ou je m'y intéressais j'av ais
cru comprendre que sous Linux on préférait sacrifier la portabilité à
la performance, et que certains bouts de code NetBSD quant à eux
favorisaient la portabilité au détriment de la performance, et que ça
pouvait expliquer en partie les moindres performances de NetBSD par
rapport à Linux.
Patcher du Linux, j'ai fait, et je continue à faire lor sque je n'ai
pas le choix. Vu la stabilité de l'API du noyau, c'est une gageure :
lorsque tu arrives à stabiliser ton patch, il est obsol ète vis à vis
du nouveau noyau et tu peux recommencer...
Effectivement, si on veut optimiser du NetBSD, et le patcher pour
améliorer les perfs en optimisant les bouts de codes ajoutés pour la
portabilité, ça doit à mon avis être plus simple étant donné qu e les
API ne changent pas tousles 36 du mois ...
Le 27-05-2010, ? propos de Re: Monsieur Doucet et la Grèce (Où il pourrait aller se faire voir.. .), totof01 ?crivait dans fr.comp.os.linux.debats :
> On 27 mai, 06:42, ST wrote: >> totof01 a perdu son temps a nous dire:
>> > Va faire un tour dans les banques, intéresse-toi à des trucs com me le >> > nombre de transactions que peuvent traiter ces engins, la gestion de s >> > disques, la haute disponibilité demandée par les applis qui tour nent >> > dessus et on en reparle après. Même Linux ne serait pas capable de les >> > remplacer de façon aussi efficace.
>> En meme temps, Linux n'est qu'un Unix. C'est a dire un amas de couches >> qui s'empilent les unes sur les autres et ou le niveau de performance >> reste tres moyen. > Oui, mais l'avantage de Linux, c'est que ça reste un système ouvert > que l'on peut adapter en fonction de ses besoins. On peut désactiver > les couches qui ne nous intéressent pas, par exemple, ou optimiser > certaines partie du noyau pour augmenter les perfs. C'est plutôt rare , > mais je sais que ça se fait dans certains labos par exemple.
Ouaips, enfin, si tu veux des performances brutes, regard e du côté de NetBSD. Le noyau est compact et ne contient que le n écessaire.
Je suis déjà allé voir le noyau, que j'ai trouvé bien plus clair qu 'un noyau Linux. Je reconnais cependant que ça fait longtemps que je ne m'y suis plus intéressé. Et à l'époque ou je m'y intéressais j'av ais cru comprendre que sous Linux on préférait sacrifier la portabilité à la performance, et que certains bouts de code NetBSD quant à eux favorisaient la portabilité au détriment de la performance, et que ça pouvait expliquer en partie les moindres performances de NetBSD par rapport à Linux.
Patcher du Linux, j'ai fait, et je continue à faire lor sque je n'ai pas le choix. Vu la stabilité de l'API du noyau, c'est une gageure : lorsque tu arrives à stabiliser ton patch, il est obsol ète vis à vis du nouveau noyau et tu peux recommencer...
Effectivement, si on veut optimiser du NetBSD, et le patcher pour améliorer les perfs en optimisant les bouts de codes ajoutés pour la portabilité, ça doit à mon avis être plus simple étant donné qu e les API ne changent pas tousles 36 du mois ...
totof01
On 27 mai, 10:41, P4nd1-P4nd4 <P4nd1-P4nd4@> wrote:
JKB a émis l'idée suivante :
> Le 27-05-2010, ? propos de > Re: Monsieur Doucet et la Grèce (Où il pourrait aller se faire voir ...), > P4nd1-P4nd4 ?crivait dans fr.comp.os.linux.debats : >> Il se trouve que JKB a formulé : >>> Le 27-05-2010, ? propos de >>> Re: Monsieur Doucet et la Grèce (Où il pourrait aller se faire vo ir...), >>> debug this fifo ?crivait dans fr.comp.os.linux.debats : >>>> totof01 wrote:
>>>>> L'intéret des mainframes est dans la capacité à traiter de no mbreuses >>>>> transactions simultanées, un accès IO des plus efficaces et une >>>>> stabilité à toute épreuve, capitale dans les domaines ou ceux -ci sont >>>>> employés.
>>>> et le hotplug de la plupart des composants aussi.
>>> Pire ! J'ai souvenir d'un VAX (le genre de truc qui met _deux_ >>> heures à effectuer son POST avec plein de loupiottes qui >>> clignotent... Heureusement que l'uptime se compte en _années _...) >>> qui avait fait tout son post grâce à sa PAL et qui au mome nt >>> d'afficher :
>>> CPU0 booting
>>> a afficher un superbe
>>> CPU0 not responding >>> CPU1 not responding >>> Shutting down boot process to SRM console
>>> PCÿff19A5
>>> ce qui est _très_ fort avec deux CPU aux fraises sur les deu x de la >>> machine ;-)
>>> JKB
>> Merde, 2 heures pour ca, je préfère encore un écran bleu tout de suite >> ;>))
> Mais quel con...
> JKB
Arrête de te la péter, aujourd'hui le BIOS te signalerai ca de suite après 2 secondes
Ridicule. Le bios te signalerait rien du tout, il ne pourrait pas démarrer sans processeur.
Tu crois que les techniciens ont le temps de passer 2 heures à regarder un système booter ?
Sous windows, les reboot sont tellement fréquents qu'il faut effectivement qu'ils soient rapides.
C'est juste une farce
On 27 mai, 10:41, P4nd1-P4nd4 <P4nd1-P4nd4@> wrote:
JKB a émis l'idée suivante :
> Le 27-05-2010, ? propos de
> Re: Monsieur Doucet et la Grèce (Où il pourrait aller se faire voir ...),
> P4nd1-P4nd4 ?crivait dans fr.comp.os.linux.debats :
>> Il se trouve que JKB a formulé :
>>> Le 27-05-2010, ? propos de
>>> Re: Monsieur Doucet et la Grèce (Où il pourrait aller se faire vo ir...),
>>> debug this fifo ?crivait dans fr.comp.os.linux.debats :
>>>> totof01 wrote:
>>>>> L'intéret des mainframes est dans la capacité à traiter de no mbreuses
>>>>> transactions simultanées, un accès IO des plus efficaces et une
>>>>> stabilité à toute épreuve, capitale dans les domaines ou ceux -ci sont
>>>>> employés.
>>>> et le hotplug de la plupart des composants aussi.
>>> Pire ! J'ai souvenir d'un VAX (le genre de truc qui met _deux_
>>> heures à effectuer son POST avec plein de loupiottes qui
>>> clignotent... Heureusement que l'uptime se compte en _années _...)
>>> qui avait fait tout son post grâce à sa PAL et qui au mome nt
>>> d'afficher :
>>> CPU0 booting
>>> a afficher un superbe
>>> CPU0 not responding
>>> CPU1 not responding
>>> Shutting down boot process to SRM console
>>> PC=ffff19A5
>>> ce qui est _très_ fort avec deux CPU aux fraises sur les deu x de la
>>> machine ;-)
>>> JKB
>> Merde, 2 heures pour ca, je préfère encore un écran bleu tout de suite
>> ;>))
> Mais quel con...
> JKB
Arrête de te la péter, aujourd'hui le BIOS te signalerai ca de suite
après 2 secondes
Ridicule. Le bios te signalerait rien du tout, il ne pourrait pas
démarrer sans processeur.
Tu crois que les techniciens ont le temps de passer 2 heures à regarder
un système booter ?
Sous windows, les reboot sont tellement fréquents qu'il faut
effectivement qu'ils soient rapides.
On 27 mai, 10:41, P4nd1-P4nd4 <P4nd1-P4nd4@> wrote:
JKB a émis l'idée suivante :
> Le 27-05-2010, ? propos de > Re: Monsieur Doucet et la Grèce (Où il pourrait aller se faire voir ...), > P4nd1-P4nd4 ?crivait dans fr.comp.os.linux.debats : >> Il se trouve que JKB a formulé : >>> Le 27-05-2010, ? propos de >>> Re: Monsieur Doucet et la Grèce (Où il pourrait aller se faire vo ir...), >>> debug this fifo ?crivait dans fr.comp.os.linux.debats : >>>> totof01 wrote:
>>>>> L'intéret des mainframes est dans la capacité à traiter de no mbreuses >>>>> transactions simultanées, un accès IO des plus efficaces et une >>>>> stabilité à toute épreuve, capitale dans les domaines ou ceux -ci sont >>>>> employés.
>>>> et le hotplug de la plupart des composants aussi.
>>> Pire ! J'ai souvenir d'un VAX (le genre de truc qui met _deux_ >>> heures à effectuer son POST avec plein de loupiottes qui >>> clignotent... Heureusement que l'uptime se compte en _années _...) >>> qui avait fait tout son post grâce à sa PAL et qui au mome nt >>> d'afficher :
>>> CPU0 booting
>>> a afficher un superbe
>>> CPU0 not responding >>> CPU1 not responding >>> Shutting down boot process to SRM console
>>> PCÿff19A5
>>> ce qui est _très_ fort avec deux CPU aux fraises sur les deu x de la >>> machine ;-)
>>> JKB
>> Merde, 2 heures pour ca, je préfère encore un écran bleu tout de suite >> ;>))
> Mais quel con...
> JKB
Arrête de te la péter, aujourd'hui le BIOS te signalerai ca de suite après 2 secondes
Ridicule. Le bios te signalerait rien du tout, il ne pourrait pas démarrer sans processeur.
Tu crois que les techniciens ont le temps de passer 2 heures à regarder un système booter ?
Sous windows, les reboot sont tellement fréquents qu'il faut effectivement qu'ils soient rapides.
C'est juste une farce
JKB
Le 27-05-2010, ? propos de Re: Monsieur Doucet et la Grèce (Où il pourrait aller se faire voir...), totof01 ?crivait dans fr.comp.os.linux.debats :
On 27 mai, 10:36, JKB wrote:
Le 27-05-2010, ? propos de Re: Monsieur Doucet et la Grèce (Où il pourrait aller se faire voir...), totof01 ?crivait dans fr.comp.os.linux.debats :
> On 27 mai, 06:42, ST wrote: >> totof01 a perdu son temps a nous dire:
>> > Va faire un tour dans les banques, intéresse-toi à des trucs comme le >> > nombre de transactions que peuvent traiter ces engins, la gestion des >> > disques, la haute disponibilité demandée par les applis qui tournent >> > dessus et on en reparle après. Même Linux ne serait pas capable de les >> > remplacer de façon aussi efficace.
>> En meme temps, Linux n'est qu'un Unix. C'est a dire un amas de couches >> qui s'empilent les unes sur les autres et ou le niveau de performance >> reste tres moyen. > Oui, mais l'avantage de Linux, c'est que ça reste un système ouvert > que l'on peut adapter en fonction de ses besoins. On peut désactiver > les couches qui ne nous intéressent pas, par exemple, ou optimiser > certaines partie du noyau pour augmenter les perfs. C'est plutôt rare, > mais je sais que ça se fait dans certains labos par exemple.
Ouaips, enfin, si tu veux des performances brutes, regarde du côté de NetBSD. Le noyau est compact et ne contient que le nécessaire.
Je suis déjà allé voir le noyau, que j'ai trouvé bien plus clair qu'un noyau Linux. Je reconnais cependant que ça fait longtemps que je ne m'y suis plus intéressé. Et à l'époque ou je m'y intéressais j'avais cru comprendre que sous Linux on préférait sacrifier la portabilité à la performance, et que certains bouts de code NetBSD quant à eux favorisaient la portabilité au détriment de la performance, et que ça pouvait expliquer en partie les moindres performances de NetBSD par rapport à Linux.
Les moindres performances, il ne faut pas exagérer non plus.
Patcher du Linux, j'ai fait, et je continue à faire lorsque je n'ai pas le choix. Vu la stabilité de l'API du noyau, c'est une gageure : lorsque tu arrives à stabiliser ton patch, il est obsolète vis à vis du nouveau noyau et tu peux recommencer...
Effectivement, si on veut optimiser du NetBSD, et le patcher pour améliorer les perfs en optimisant les bouts de codes ajoutés pour la portabilité, ça doit à mon avis être plus simple étant donné que les API ne changent pas tousles 36 du mois ...
Si ce n'était que tous les 36...
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 27-05-2010, ? propos de
Re: Monsieur Doucet et la Grèce (Où il pourrait aller se faire voir...),
totof01 ?crivait dans fr.comp.os.linux.debats :
On 27 mai, 10:36, JKB <knatsc...@koenigsberg.fr> wrote:
Le 27-05-2010, ? propos de
Re: Monsieur Doucet et la Grèce (Où il pourrait aller se faire voir...),
totof01 ?crivait dans fr.comp.os.linux.debats :
> On 27 mai, 06:42, ST <s...@democrate.org> wrote:
>> totof01 a perdu son temps a nous dire:
>> > Va faire un tour dans les banques, intéresse-toi à des trucs comme le
>> > nombre de transactions que peuvent traiter ces engins, la gestion des
>> > disques, la haute disponibilité demandée par les applis qui tournent
>> > dessus et on en reparle après. Même Linux ne serait pas capable de les
>> > remplacer de façon aussi efficace.
>> En meme temps, Linux n'est qu'un Unix. C'est a dire un amas de couches
>> qui s'empilent les unes sur les autres et ou le niveau de performance
>> reste tres moyen.
> Oui, mais l'avantage de Linux, c'est que ça reste un système ouvert
> que l'on peut adapter en fonction de ses besoins. On peut désactiver
> les couches qui ne nous intéressent pas, par exemple, ou optimiser
> certaines partie du noyau pour augmenter les perfs. C'est plutôt rare,
> mais je sais que ça se fait dans certains labos par exemple.
Ouaips, enfin, si tu veux des performances brutes, regarde du côté
de NetBSD. Le noyau est compact et ne contient que le nécessaire.
Je suis déjà allé voir le noyau, que j'ai trouvé bien plus clair qu'un
noyau Linux. Je reconnais cependant que ça fait longtemps que je ne
m'y suis plus intéressé. Et à l'époque ou je m'y intéressais j'avais
cru comprendre que sous Linux on préférait sacrifier la portabilité à
la performance, et que certains bouts de code NetBSD quant à eux
favorisaient la portabilité au détriment de la performance, et que ça
pouvait expliquer en partie les moindres performances de NetBSD par
rapport à Linux.
Les moindres performances, il ne faut pas exagérer non plus.
Patcher du Linux, j'ai fait, et je continue à faire lorsque je n'ai
pas le choix. Vu la stabilité de l'API du noyau, c'est une gageure :
lorsque tu arrives à stabiliser ton patch, il est obsolète vis à vis
du nouveau noyau et tu peux recommencer...
Effectivement, si on veut optimiser du NetBSD, et le patcher pour
améliorer les perfs en optimisant les bouts de codes ajoutés pour la
portabilité, ça doit à mon avis être plus simple étant donné que les
API ne changent pas tousles 36 du mois ...
Si ce n'était que tous les 36...
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 27-05-2010, ? propos de Re: Monsieur Doucet et la Grèce (Où il pourrait aller se faire voir...), totof01 ?crivait dans fr.comp.os.linux.debats :
On 27 mai, 10:36, JKB wrote:
Le 27-05-2010, ? propos de Re: Monsieur Doucet et la Grèce (Où il pourrait aller se faire voir...), totof01 ?crivait dans fr.comp.os.linux.debats :
> On 27 mai, 06:42, ST wrote: >> totof01 a perdu son temps a nous dire:
>> > Va faire un tour dans les banques, intéresse-toi à des trucs comme le >> > nombre de transactions que peuvent traiter ces engins, la gestion des >> > disques, la haute disponibilité demandée par les applis qui tournent >> > dessus et on en reparle après. Même Linux ne serait pas capable de les >> > remplacer de façon aussi efficace.
>> En meme temps, Linux n'est qu'un Unix. C'est a dire un amas de couches >> qui s'empilent les unes sur les autres et ou le niveau de performance >> reste tres moyen. > Oui, mais l'avantage de Linux, c'est que ça reste un système ouvert > que l'on peut adapter en fonction de ses besoins. On peut désactiver > les couches qui ne nous intéressent pas, par exemple, ou optimiser > certaines partie du noyau pour augmenter les perfs. C'est plutôt rare, > mais je sais que ça se fait dans certains labos par exemple.
Ouaips, enfin, si tu veux des performances brutes, regarde du côté de NetBSD. Le noyau est compact et ne contient que le nécessaire.
Je suis déjà allé voir le noyau, que j'ai trouvé bien plus clair qu'un noyau Linux. Je reconnais cependant que ça fait longtemps que je ne m'y suis plus intéressé. Et à l'époque ou je m'y intéressais j'avais cru comprendre que sous Linux on préférait sacrifier la portabilité à la performance, et que certains bouts de code NetBSD quant à eux favorisaient la portabilité au détriment de la performance, et que ça pouvait expliquer en partie les moindres performances de NetBSD par rapport à Linux.
Les moindres performances, il ne faut pas exagérer non plus.
Patcher du Linux, j'ai fait, et je continue à faire lorsque je n'ai pas le choix. Vu la stabilité de l'API du noyau, c'est une gageure : lorsque tu arrives à stabiliser ton patch, il est obsolète vis à vis du nouveau noyau et tu peux recommencer...
Effectivement, si on veut optimiser du NetBSD, et le patcher pour améliorer les perfs en optimisant les bouts de codes ajoutés pour la portabilité, ça doit à mon avis être plus simple étant donné que les API ne changent pas tousles 36 du mois ...
Si ce n'était que tous les 36...
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Richard
Le 27/05/2010 09:38, JKB a écrit :
On ne peut pas nier que ça a progressé. Et pour les domaines devenus accessibles : il y avait combien de supercalculateurs sous Windows il y a 5 ans ? Dans les 500 premiers ils sont maintenant 7 (www.top500.org).
J'aimerais surtout savoir ce que les utilisateurs font avec ça. Que ça permette de dire 'on peut faire tourner nos supercalculateurs sous Windows', je veux bien. Personnellement, je fais dans le calcul intensif et je ne connais pas un seul utilisateur qui accepterait de faire tourner un calcul sur une machine tournant sous Windows en raison de l'uptime moyen de la chose et de la gestion par l'OS du matériel. Dans un benchmark, ça a son intérêt car Windows gérant le matériel sans complexe, tu peux assez rapidement gagner les quelques pourcents de performance qui te permettent de passer devant le concurrent. Mais cela n'est pas une configuration de production, juste une configuration de test.
Personnellement, j'ai des doutes sur les possibilités de performance de Windows, en particulier quand on veut accélérer un programme avec du multitâche. J'ai écrit un programme d'Othello qui se veut relativement fort et qui tourne sous Linux, Mac OS X et Windows(de XP à 7), le tout en 64 bits. Compilé sous les trois OS avec gcc, la version Linux est 15% plus rapide que la version MS-Windows et la version Mac OS X 12%. Le compilateur de Microsoft (Visual C++ 2010) ne fait pas mieux que gcc, et quand je vois que la version 64 bits de Visual C++ n'accepte plus d'assembleur en ligne, j'ai des doutes sur la volonté de Microsoft de produire des programmes performants.
PS: Pour les sceptiques, ils peuvent vérifier par eux-mêmes. Ce programme d'Othello est disponible en téléchargement ici : http://abulmo.perso.neuf.fr/edax/4.0/edax.4-0-5.zip
Le test de performance que je fais est (sur une machine avec 2 cores) : $ lEdax -n 2 -l 60 -h 24 solve problem/fforum-40-59.script sous Mac OS X, changer lEdax par mEdax, et sous Windows (64 bits) par wEdax. A noter que le code source est aussi disponible et que les gens qui pense que je ne sais pas compiler un programme sous Windows sont bienvenus pour me signaler les bonnes options de compilation.
-- Richard
Le 27/05/2010 09:38, JKB a écrit :
On ne peut pas nier que ça a progressé.
Et pour les domaines devenus accessibles : il y avait combien de
supercalculateurs sous Windows il y a 5 ans ? Dans les 500 premiers ils
sont maintenant 7 (www.top500.org).
J'aimerais surtout savoir ce que les utilisateurs font avec ça. Que
ça permette de dire 'on peut faire tourner nos supercalculateurs
sous Windows', je veux bien. Personnellement, je fais dans le calcul
intensif et je ne connais pas un seul utilisateur qui accepterait de
faire tourner un calcul sur une machine tournant sous Windows en
raison de l'uptime moyen de la chose et de la gestion par l'OS du
matériel. Dans un benchmark, ça a son intérêt car Windows gérant le
matériel sans complexe, tu peux assez rapidement gagner les quelques
pourcents de performance qui te permettent de passer devant le
concurrent. Mais cela n'est pas une configuration de production,
juste une configuration de test.
Personnellement, j'ai des doutes sur les possibilités de performance de
Windows, en particulier quand on veut accélérer un programme avec du
multitâche. J'ai écrit un programme d'Othello qui se veut relativement
fort et qui tourne sous Linux, Mac OS X et Windows(de XP à 7), le tout
en 64 bits. Compilé sous les trois OS avec gcc, la version Linux est 15%
plus rapide que la version MS-Windows et la version Mac OS X 12%. Le
compilateur de Microsoft (Visual C++ 2010) ne fait pas mieux que gcc, et
quand je vois que la version 64 bits de Visual C++ n'accepte plus
d'assembleur en ligne, j'ai des doutes sur la volonté de Microsoft de
produire des programmes performants.
PS: Pour les sceptiques, ils peuvent vérifier par eux-mêmes. Ce
programme d'Othello est disponible en téléchargement ici :
http://abulmo.perso.neuf.fr/edax/4.0/edax.4-0-5.zip
Le test de performance que je fais est (sur une machine avec 2 cores) :
$ lEdax -n 2 -l 60 -h 24 solve problem/fforum-40-59.script
sous Mac OS X, changer lEdax par mEdax, et sous Windows (64 bits) par wEdax.
A noter que le code source est aussi disponible et que les gens qui
pense que je ne sais pas compiler un programme sous Windows sont
bienvenus pour me signaler les bonnes options de compilation.
On ne peut pas nier que ça a progressé. Et pour les domaines devenus accessibles : il y avait combien de supercalculateurs sous Windows il y a 5 ans ? Dans les 500 premiers ils sont maintenant 7 (www.top500.org).
J'aimerais surtout savoir ce que les utilisateurs font avec ça. Que ça permette de dire 'on peut faire tourner nos supercalculateurs sous Windows', je veux bien. Personnellement, je fais dans le calcul intensif et je ne connais pas un seul utilisateur qui accepterait de faire tourner un calcul sur une machine tournant sous Windows en raison de l'uptime moyen de la chose et de la gestion par l'OS du matériel. Dans un benchmark, ça a son intérêt car Windows gérant le matériel sans complexe, tu peux assez rapidement gagner les quelques pourcents de performance qui te permettent de passer devant le concurrent. Mais cela n'est pas une configuration de production, juste une configuration de test.
Personnellement, j'ai des doutes sur les possibilités de performance de Windows, en particulier quand on veut accélérer un programme avec du multitâche. J'ai écrit un programme d'Othello qui se veut relativement fort et qui tourne sous Linux, Mac OS X et Windows(de XP à 7), le tout en 64 bits. Compilé sous les trois OS avec gcc, la version Linux est 15% plus rapide que la version MS-Windows et la version Mac OS X 12%. Le compilateur de Microsoft (Visual C++ 2010) ne fait pas mieux que gcc, et quand je vois que la version 64 bits de Visual C++ n'accepte plus d'assembleur en ligne, j'ai des doutes sur la volonté de Microsoft de produire des programmes performants.
PS: Pour les sceptiques, ils peuvent vérifier par eux-mêmes. Ce programme d'Othello est disponible en téléchargement ici : http://abulmo.perso.neuf.fr/edax/4.0/edax.4-0-5.zip
Le test de performance que je fais est (sur une machine avec 2 cores) : $ lEdax -n 2 -l 60 -h 24 solve problem/fforum-40-59.script sous Mac OS X, changer lEdax par mEdax, et sous Windows (64 bits) par wEdax. A noter que le code source est aussi disponible et que les gens qui pense que je ne sais pas compiler un programme sous Windows sont bienvenus pour me signaler les bonnes options de compilation.
-- Richard
Emmanuel Florac
Le Thu, 27 May 2010 07:38:52 +0000, JKB a écrit:
J'aimerais surtout savoir ce que les utilisateurs font avec ça.
On peut supposer qu'ils font de l'excel. Sans rire, il y a une demande pour des calculs de tableaux monstrueux en finance, qui demande un vrai cluster. Bon, je suis à peu près sûr que c'est le genre de truc qu'un programmeur peut faire avec R ou autre et avoir le résultat en deux heures sur un PC normal, mais ce n'est pas aussi chic que d'avoir un super calculateur excel.
-- Le travail est la malédiction des classes qui boivent. O. Wilde.
Le Thu, 27 May 2010 07:38:52 +0000, JKB a écrit:
J'aimerais surtout savoir ce que les utilisateurs font avec ça.
On peut supposer qu'ils font de l'excel. Sans rire, il y a une demande
pour des calculs de tableaux monstrueux en finance, qui demande un vrai
cluster. Bon, je suis à peu près sûr que c'est le genre de truc qu'un
programmeur peut faire avec R ou autre et avoir le résultat en deux
heures sur un PC normal, mais ce n'est pas aussi chic que d'avoir un
super calculateur excel.
--
Le travail est la malédiction des classes qui boivent.
O. Wilde.
J'aimerais surtout savoir ce que les utilisateurs font avec ça.
On peut supposer qu'ils font de l'excel. Sans rire, il y a une demande pour des calculs de tableaux monstrueux en finance, qui demande un vrai cluster. Bon, je suis à peu près sûr que c'est le genre de truc qu'un programmeur peut faire avec R ou autre et avoir le résultat en deux heures sur un PC normal, mais ce n'est pas aussi chic que d'avoir un super calculateur excel.
-- Le travail est la malédiction des classes qui boivent. O. Wilde.
