KDE tuera Windows

JKB

03/01/2010 à 21:00

Le 03-01-2010, ? propos de
Re: KDE tuera Windows,
pipantal ?crivait dans fr.comp.os.linux.debats :

JKB a écrit :

C'est sûr qu'en consommation brute et en chauffage d'appoint, c'est
pas mal du tout. Mes sparcs à 32 voies consomment 2A/230V en pleine
charge. Le jour où je trouve un i386 capable de faire ça, je
reviendrai sur ma position.

Certes, mais ça donne quoi vos sparcs en terme de puissance brut !
Il faut quel (et combien d'x86) pour en arriver au même résultat ?

Il en faut quelques uns. Je fais actuellement du calcul parallèle et
la puissance brute entre naturellement dans le critère. Les sparcs
sont plus avantageux même si chaque coeur est plus lent qu'un coeur
de x86 (ce sont des T1/T2).

Non. Les procs x86 consomment peu lorsqu'ils ne fichent rien. Dès
qu'on met les pieds dedans, ils se transforment en grille-pain (il y
a des raisons qui proviennent du design de la puce et d'autres qui
viennent directement de la conception du langage d'assemblage).

à une époque bien lointaine ou je bricolais mon Amiga 2000 et son 68000,
je trouvais que c'était d'une simplicité déconcertante, je n'ai jamais
compris l'x86, et notamment l'adressage mémoire !

L'adressage mémoire n'est pas un problème une fois qu'on a compris
la différence entre saut et branchements et le fait que l'absence de
branchement implique la segmentation de la mémoire pour rendre le
programme relogeable. Le problème de l'architecture x86 et le
fonctionnement par accumulateur. Tu ne peux pas faire des trucs
aussi triviaux que ADD R1,R2,R3, ce qui a des conséquences énormes
sur les performances finales.

Ouaips. L'alpha est mort, mais l'UltraSPARC VII/FX est là. De même
que le POWER6 et quelques autres.

Mais qui fait fabrique ces machines, quels périphériques utilise-t-il ?

Sun et Fujitsu. Tous les périphériques USB standard sont supportés
ainsi que tout ce qui est en PCI-X ou PCI-E.

Le développement d'OS alternatif très mature à ce jour, ne peut-il
envisager une concurrence du point de vue de l'architecture des coeurs ?

Moi pas comprendre.

Le SATA c'est bien ?

Si j'ai le choix entre SATA, SAS et SCSI-U320, c'est immédiatement
le SCSI-U320 qui l'emporte. Si on rajoute le FCAL, c'est une autre
histoire.

le PCI express c'est bien ?

J'ai un gros faible pour le PCI-X. Le PCI-E, c'est un bricolage
infâme électroniquement parlant. Disons que le PCI-X est moins moisi
que le PCI-E.

Parce qu'on ne peut pas révolutionner tout, tout de suite.

Et combien coutent les architectures alternatives ?

Pas forcément beaucoup plus cher qu'un PC équivalent (d'autant que
l'amortissement comptable n'est pas le même).

Moi je reverrai d'avoir un ordinateur personnel qui consomme rien et
rapide et surtout peu cher ! ça existe ?

Cette remarque m'insite à te demander de chercher par toi même les
prix de ces machines.

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 03-01-2010, ? propos de
Re: KDE tuera Windows,
pipantal ?crivait dans fr.comp.os.linux.debats :

JKB a écrit :

C'est sûr qu'en consommation brute et en chauffage d'appoint, c'est
pas mal du tout. Mes sparcs à 32 voies consomment 2A/230V en pleine
charge. Le jour où je trouve un i386 capable de faire ça, je
reviendrai sur ma position.

Certes, mais ça donne quoi vos sparcs en terme de puissance brut !
Il faut quel (et combien d'x86) pour en arriver au même résultat ?

Il en faut quelques uns. Je fais actuellement du calcul parallèle et
la puissance brute entre naturellement dans le critère. Les sparcs
sont plus avantageux même si chaque coeur est plus lent qu'un coeur
de x86 (ce sont des T1/T2).

Non. Les procs x86 consomment peu lorsqu'ils ne fichent rien. Dès
qu'on met les pieds dedans, ils se transforment en grille-pain (il y
a des raisons qui proviennent du design de la puce et d'autres qui
viennent directement de la conception du langage d'assemblage).

à une époque bien lointaine ou je bricolais mon Amiga 2000 et son 68000,
je trouvais que c'était d'une simplicité déconcertante, je n'ai jamais
compris l'x86, et notamment l'adressage mémoire !

L'adressage mémoire n'est pas un problème une fois qu'on a compris
la différence entre saut et branchements et le fait que l'absence de
branchement implique la segmentation de la mémoire pour rendre le
programme relogeable. Le problème de l'architecture x86 et le
fonctionnement par accumulateur. Tu ne peux pas faire des trucs
aussi triviaux que ADD R1,R2,R3, ce qui a des conséquences énormes
sur les performances finales.

Ouaips. L'alpha est mort, mais l'UltraSPARC VII/FX est là. De même
que le POWER6 et quelques autres.

Mais qui fait fabrique ces machines, quels périphériques utilise-t-il ?

Sun et Fujitsu. Tous les périphériques USB standard sont supportés
ainsi que tout ce qui est en PCI-X ou PCI-E.

Le développement d'OS alternatif très mature à ce jour, ne peut-il
envisager une concurrence du point de vue de l'architecture des coeurs ?

Moi pas comprendre.

Le SATA c'est bien ?

Si j'ai le choix entre SATA, SAS et SCSI-U320, c'est immédiatement
le SCSI-U320 qui l'emporte. Si on rajoute le FCAL, c'est une autre
histoire.

le PCI express c'est bien ?

J'ai un gros faible pour le PCI-X. Le PCI-E, c'est un bricolage
infâme électroniquement parlant. Disons que le PCI-X est moins moisi
que le PCI-E.

Parce qu'on ne peut pas révolutionner tout, tout de suite.

Et combien coutent les architectures alternatives ?

Pas forcément beaucoup plus cher qu'un PC équivalent (d'autant que
l'amortissement comptable n'est pas le même).

Moi je reverrai d'avoir un ordinateur personnel qui consomme rien et
rapide et surtout peu cher ! ça existe ?

Cette remarque m'insite à te demander de chercher par toi même les
prix de ces machines.

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.

Vous avez filtré cet utilisateur ! Consultez son message

Le 03-01-2010, ? propos de
Re: KDE tuera Windows,
pipantal ?crivait dans fr.comp.os.linux.debats :

JKB a écrit :

C'est sûr qu'en consommation brute et en chauffage d'appoint, c'est
pas mal du tout. Mes sparcs à 32 voies consomment 2A/230V en pleine
charge. Le jour où je trouve un i386 capable de faire ça, je
reviendrai sur ma position.

Certes, mais ça donne quoi vos sparcs en terme de puissance brut !
Il faut quel (et combien d'x86) pour en arriver au même résultat ?

Il en faut quelques uns. Je fais actuellement du calcul parallèle et
la puissance brute entre naturellement dans le critère. Les sparcs
sont plus avantageux même si chaque coeur est plus lent qu'un coeur
de x86 (ce sont des T1/T2).

Non. Les procs x86 consomment peu lorsqu'ils ne fichent rien. Dès
qu'on met les pieds dedans, ils se transforment en grille-pain (il y
a des raisons qui proviennent du design de la puce et d'autres qui
viennent directement de la conception du langage d'assemblage).

à une époque bien lointaine ou je bricolais mon Amiga 2000 et son 68000,
je trouvais que c'était d'une simplicité déconcertante, je n'ai jamais
compris l'x86, et notamment l'adressage mémoire !

L'adressage mémoire n'est pas un problème une fois qu'on a compris
la différence entre saut et branchements et le fait que l'absence de
branchement implique la segmentation de la mémoire pour rendre le
programme relogeable. Le problème de l'architecture x86 et le
fonctionnement par accumulateur. Tu ne peux pas faire des trucs
aussi triviaux que ADD R1,R2,R3, ce qui a des conséquences énormes
sur les performances finales.

Ouaips. L'alpha est mort, mais l'UltraSPARC VII/FX est là. De même
que le POWER6 et quelques autres.

Mais qui fait fabrique ces machines, quels périphériques utilise-t-il ?

Sun et Fujitsu. Tous les périphériques USB standard sont supportés
ainsi que tout ce qui est en PCI-X ou PCI-E.

Le développement d'OS alternatif très mature à ce jour, ne peut-il
envisager une concurrence du point de vue de l'architecture des coeurs ?

Moi pas comprendre.

Le SATA c'est bien ?

Si j'ai le choix entre SATA, SAS et SCSI-U320, c'est immédiatement
le SCSI-U320 qui l'emporte. Si on rajoute le FCAL, c'est une autre
histoire.

le PCI express c'est bien ?

J'ai un gros faible pour le PCI-X. Le PCI-E, c'est un bricolage
infâme électroniquement parlant. Disons que le PCI-X est moins moisi
que le PCI-E.

Parce qu'on ne peut pas révolutionner tout, tout de suite.

Et combien coutent les architectures alternatives ?

Pas forcément beaucoup plus cher qu'un PC équivalent (d'autant que
l'amortissement comptable n'est pas le même).

Moi je reverrai d'avoir un ordinateur personnel qui consomme rien et
rapide et surtout peu cher ! ça existe ?

Cette remarque m'insite à te demander de chercher par toi même les
prix de ces machines.

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.

P4nd1-P4nd4

03/01/2010 à 21:32

Dellara a présenté l'énoncé suivant :

Eric Masson a papoté sur Usenet le janvier 3, 2010 02:35 PM:

Au niveau des io, n'importe quel midrange met une taule aux archis à
base pc. Et lorsque l'on est obligé pour des raisons commerciales de
mettre en place un serveur x86 en lieu et place d'un véritable serveur
pour une appli transactionnelle, les coûts sont supérieurs pour un
résultat largement inférieur.

Mais la question est (et ce n'est pas un troll mais une vraie question):
Comment se fait-il que les constructeurs restent sur cette architecture
pourrie s'il y a mieux?

C'est que justement, le mieux n'est pas si mieux que cela

Les différents intervrnants comparent généralement des architectures de
15 ans en arrière en zapant les nouveautés

--
P4nd1-P4nd4 vous salue, et annonce que le petit ourson possède
désormais son blog
p4nd1-p4nd4.over-blog.com

Eric Masson

03/01/2010 à 21:35

Dellara writes:

'Lut,

Mais la question est (et ce n'est pas un troll mais une vraie question):
Comment se fait-il que les constructeurs restent sur cette architecture
pourrie s'il y a mieux?

Parce que la demande va sur ce type de matériel du fait que les droids
décisionnaires pensent que les versions "server" de Windows sont la
solution de leur problèmes du fait que les midranges sont
"propriétaires" et que les compétences sur ces plateformes sont plus
chères.

Un véritable admin Windows qui connait le produit et est capable de
l'administrer de façon efficace, ça ne court pas les rues, et ça se
paye, mais bon, les mythes ont la vie dure.

--
> Mais bon, c'est pas moi qui lancerais l'AAD là-dessus (mais s'il passe
> je voterai certainement pour si ça peut éviter aux dinosaures de bloquer
> systèmatiquement toutes les initiatives des linuxiens).
-+- EF in Guide du linuxien pervers : "Les dinos ont changé de camps !" -+-

JKB

03/01/2010 à 21:40

Le 03-01-2010, ? propos de
Re: KDE tuera Windows,
P4nd1-P4nd4 ?crivait dans fr.comp.os.linux.debats :

Dellara a présenté l'énoncé suivant :
Eric Masson a papoté sur Usenet le janvier 3, 2010 02:35 PM:

Au niveau des io, n'importe quel midrange met une taule aux archis à
base pc. Et lorsque l'on est obligé pour des raisons commerciales de
mettre en place un serveur x86 en lieu et place d'un véritable serveur
pour une appli transactionnelle, les coûts sont supérieurs pour un
résultat largement inférieur.

Mais la question est (et ce n'est pas un troll mais une vraie question):
Comment se fait-il que les constructeurs restent sur cette architecture
pourrie s'il y a mieux?

C'est que justement, le mieux n'est pas si mieux que cela

Les différents intervrnants comparent généralement des architectures de
15 ans en arrière en zapant les nouveautés

Tu me dis quand est sorti le T2+ ou US VII/FX ? Je t'aide :
http://regmedia.co.uk/2009/09/11/sun_sparc_roadmap.jpg

Comme tu peux le voir, le truc le plus ancien date de 2006.

Guignol !

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.

pipantal

03/01/2010 à 21:48

JKB a écrit :

Le développement d'OS alternatif très mature à ce jour, ne peut-il
envisager une concurrence du point de vue de l'architecture des coeurs ?

Moi pas comprendre.

En gros s'il existe des architecture efficace techniquement et
économiquement, le fait que des OS à de base de linux permettent de
faire un tas de chose, cela permet d'envisager d'avoir plus facilement
des utilisateurs qui se tournent vers d'autres architecture que l'x86.
Si une application (comme des jeux aussi) tournant sous Linux avec par
exemple un carte 3D dernier cri en PCI-E, le fait d'avoir une archi
autre que x86, mais utilisant les périphérique standard à ce jour (je
m'entend par là, le fait que les développeurs travaillent avec) cela
permet une autre ouverture et donc plus de concurrence et donc d'efficacité.

Le SATA c'est bien ?

Si j'ai le choix entre SATA, SAS et SCSI-U320, c'est immédiatement
le SCSI-U320 qui l'emporte. Si on rajoute le FCAL, c'est une autre
histoire.

pour un ordinateur personnel ça change quelque chose ?

le PCI express c'est bien ?

J'ai un gros faible pour le PCI-X. Le PCI-E, c'est un bricolage
infâme électroniquement parlant. Disons que le PCI-X est moins moisi
que le PCI-E.

oui mais en efficacité ?
On ne parle là que d'un bus, si ça transit mieux en PCI-E moisi ou pas,
je ne comprend pas ...

Pas forcément beaucoup plus cher qu'un PC équivalent (d'autant que
l'amortissement comptable n'est pas le même).

L'amortissement n'en réduit pas le coût !

Moi je reverrai d'avoir un ordinateur personnel qui consomme rien et
rapide et surtout peu cher ! ça existe ?

Cette remarque m'insite à te demander de chercher par toi même les
prix de ces machines.

mais voilà, je ne sais pas où chercher !
Car je ne sais même pas ce qui existe et qui peut revendre !

P4nd1-P4nd4

03/01/2010 à 22:04

Le 03.01.2010, JKB a supposé :

Le 03-01-2010, ? propos de
Re: KDE tuera Windows,
P4nd1-P4nd4 ?crivait dans fr.comp.os.linux.debats :
Dellara a présenté l'énoncé suivant :
Eric Masson a papoté sur Usenet le janvier 3, 2010 02:35 PM:

Au niveau des io, n'importe quel midrange met une taule aux archis à
base pc. Et lorsque l'on est obligé pour des raisons commerciales de
mettre en place un serveur x86 en lieu et place d'un véritable serveur
pour une appli transactionnelle, les coûts sont supérieurs pour un
résultat largement inférieur.

Mais la question est (et ce n'est pas un troll mais une vraie question):
Comment se fait-il que les constructeurs restent sur cette architecture
pourrie s'il y a mieux?

C'est que justement, le mieux n'est pas si mieux que cela

Les différents intervrnants comparent généralement des architectures de
15 ans en arrière en zapant les nouveautés

Tu me dis quand est sorti le T2+ ou US VII/FX ? Je t'aide :
http://regmedia.co.uk/2009/09/11/sun_sparc_roadmap.jpg

Comme tu peux le voir, le truc le plus ancien date de 2006.

Guignol !

JKB

Comme tu peux le voir

http://www.top500.org/stats/list/34/procfam

2 machines sur 500 des TOP-COMPUTERS utilisent des SPARCS, et elle sont
loin d'être devant...

Par contre,

79,2 % utilisent des Intel X86 acec extensions 64 bits...

et 8,4 % des machines utilisent les AMD x86_64, ce qui revient à dire
que

88 % des supercalulateurs utiisent l'architecture "pourrie et minable"
de X86

Alors, guignol, va te branler plus loin

D'ailleurs, compare un processeur Nehalem et SPARC, et regarde le
rapport prix/performance

(Demande à ton papa des explications supplémentaires...)

Ciao, Pantin !

--
P4nd1-P4nd4 vous salue, et annonce que le petit ourson possède
désormais son blog
p4nd1-p4nd4.over-blog.com

P4nd1-P4nd4

03/01/2010 à 22:07

pipantal avait énoncé :

JKB a écrit :

Le SATA c'est bien ?

Si j'ai le choix entre SATA, SAS et SCSI-U320, c'est immédiatement
le SCSI-U320 qui l'emporte. Si on rajoute le FCAL, c'est une autre
histoire.

Ahahaha

J'ai un gros faible pour le PCI-X. Le PCI-E, c'est un bricolage
infâme électroniquement parlant. Disons que le PCI-X est moins moisi
que le PCI-E.

Hohohohohoho

--
P4nd1-P4nd4 vous salue, et annonce que le petit ourson possède
désormais son blog
p4nd1-p4nd4.over-blog.com

JKB

03/01/2010 à 22:13

Le 03-01-2010, ? propos de
Re: KDE tuera Windows,
pipantal ?crivait dans fr.comp.os.linux.debats :

JKB a écrit :

Le développement d'OS alternatif très mature à ce jour, ne peut-il
envisager une concurrence du point de vue de l'architecture des coeurs ?

Moi pas comprendre.

En gros s'il existe des architecture efficace techniquement et
économiquement, le fait que des OS à de base de linux permettent de
faire un tas de chose, cela permet d'envisager d'avoir plus facilement
des utilisateurs qui se tournent vers d'autres architecture que l'x86.
Si une application (comme des jeux aussi) tournant sous Linux avec par
exemple un carte 3D dernier cri en PCI-E, le fait d'avoir une archi
autre que x86, mais utilisant les périphérique standard à ce jour (je
m'entend par là, le fait que les développeurs travaillent avec) cela
permet une autre ouverture et donc plus de concurrence et donc d'efficacité.

Qu'est-ce qui empêche d'utiliser une carte PCI dans une blade 2000
tant qu'on n'essaye pas de booter dessus ?

Le SATA c'est bien ?

Si j'ai le choix entre SATA, SAS et SCSI-U320, c'est immédiatement
le SCSI-U320 qui l'emporte. Si on rajoute le FCAL, c'est une autre
histoire.

pour un ordinateur personnel ça change quelque chose ?

Oui.

le PCI express c'est bien ?

J'ai un gros faible pour le PCI-X. Le PCI-E, c'est un bricolage
infâme électroniquement parlant. Disons que le PCI-X est moins moisi
que le PCI-E.

oui mais en efficacité ?
On ne parle là que d'un bus, si ça transit mieux en PCI-E moisi ou pas,
je ne comprend pas ...

Le PCI-E permet de faire économique au détriment de tout le reste
parce qu'on ne cherche pas à synchroniser des signaux. Par rapport à
du PCI-X, c'est _mauvais_. D'ailleurs lorsque j'achète mes serveurs
en rack, j'ai le choix entre un riser PCI-E et un PCI-X. Le PCI-E
est proposé parce que toutes les cartes du monde PC fonctionnent à
peu près, le PCI-X, pour pouvoir mettre des cartes avec des taux de
transferts en soutenu plus sérieux.

Pas forcément beaucoup plus cher qu'un PC équivalent (d'autant que
l'amortissement comptable n'est pas le même).

L'amortissement n'en réduit pas le coût !

À toi de voir s'il faut acheter un serveur à 4000 euros amortissable
en 6 ans ou un serveur x86 cd 2500 euros amortissable en 3 ans. Mon
choix est fait.

Moi je reverrai d'avoir un ordinateur personnel qui consomme rien et
rapide et surtout peu cher ! ça existe ?

Cette remarque m'insite à te demander de chercher par toi même les
prix de ces machines.

mais voilà, je ne sais pas où chercher !
Car je ne sais même pas ce qui existe et qui peut revendre !

Sun, Fujitsu, HP (les prix sont public), IBM si tu téléphones.

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 03-01-2010, ? propos de
Re: KDE tuera Windows,
pipantal ?crivait dans fr.comp.os.linux.debats :

JKB a écrit :

Le développement d'OS alternatif très mature à ce jour, ne peut-il
envisager une concurrence du point de vue de l'architecture des coeurs ?

Moi pas comprendre.

En gros s'il existe des architecture efficace techniquement et
économiquement, le fait que des OS à de base de linux permettent de
faire un tas de chose, cela permet d'envisager d'avoir plus facilement
des utilisateurs qui se tournent vers d'autres architecture que l'x86.
Si une application (comme des jeux aussi) tournant sous Linux avec par
exemple un carte 3D dernier cri en PCI-E, le fait d'avoir une archi
autre que x86, mais utilisant les périphérique standard à ce jour (je
m'entend par là, le fait que les développeurs travaillent avec) cela
permet une autre ouverture et donc plus de concurrence et donc d'efficacité.

Qu'est-ce qui empêche d'utiliser une carte PCI dans une blade 2000
tant qu'on n'essaye pas de booter dessus ?

Le SATA c'est bien ?

Si j'ai le choix entre SATA, SAS et SCSI-U320, c'est immédiatement
le SCSI-U320 qui l'emporte. Si on rajoute le FCAL, c'est une autre
histoire.

pour un ordinateur personnel ça change quelque chose ?

Oui.

le PCI express c'est bien ?

J'ai un gros faible pour le PCI-X. Le PCI-E, c'est un bricolage
infâme électroniquement parlant. Disons que le PCI-X est moins moisi
que le PCI-E.

oui mais en efficacité ?
On ne parle là que d'un bus, si ça transit mieux en PCI-E moisi ou pas,
je ne comprend pas ...

Le PCI-E permet de faire économique au détriment de tout le reste
parce qu'on ne cherche pas à synchroniser des signaux. Par rapport à
du PCI-X, c'est _mauvais_. D'ailleurs lorsque j'achète mes serveurs
en rack, j'ai le choix entre un riser PCI-E et un PCI-X. Le PCI-E
est proposé parce que toutes les cartes du monde PC fonctionnent à
peu près, le PCI-X, pour pouvoir mettre des cartes avec des taux de
transferts en soutenu plus sérieux.

Pas forcément beaucoup plus cher qu'un PC équivalent (d'autant que
l'amortissement comptable n'est pas le même).

L'amortissement n'en réduit pas le coût !

À toi de voir s'il faut acheter un serveur à 4000 euros amortissable
en 6 ans ou un serveur x86 cd 2500 euros amortissable en 3 ans. Mon
choix est fait.

Moi je reverrai d'avoir un ordinateur personnel qui consomme rien et
rapide et surtout peu cher ! ça existe ?

Cette remarque m'insite à te demander de chercher par toi même les
prix de ces machines.

mais voilà, je ne sais pas où chercher !
Car je ne sais même pas ce qui existe et qui peut revendre !

Sun, Fujitsu, HP (les prix sont public), IBM si tu téléphones.

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.

Vous avez filtré cet utilisateur ! Consultez son message

Le 03-01-2010, ? propos de
Re: KDE tuera Windows,
pipantal ?crivait dans fr.comp.os.linux.debats :

JKB a écrit :

Le développement d'OS alternatif très mature à ce jour, ne peut-il
envisager une concurrence du point de vue de l'architecture des coeurs ?

Moi pas comprendre.

En gros s'il existe des architecture efficace techniquement et
économiquement, le fait que des OS à de base de linux permettent de
faire un tas de chose, cela permet d'envisager d'avoir plus facilement
des utilisateurs qui se tournent vers d'autres architecture que l'x86.
Si une application (comme des jeux aussi) tournant sous Linux avec par
exemple un carte 3D dernier cri en PCI-E, le fait d'avoir une archi
autre que x86, mais utilisant les périphérique standard à ce jour (je
m'entend par là, le fait que les développeurs travaillent avec) cela
permet une autre ouverture et donc plus de concurrence et donc d'efficacité.

Qu'est-ce qui empêche d'utiliser une carte PCI dans une blade 2000
tant qu'on n'essaye pas de booter dessus ?

Le SATA c'est bien ?

Si j'ai le choix entre SATA, SAS et SCSI-U320, c'est immédiatement
le SCSI-U320 qui l'emporte. Si on rajoute le FCAL, c'est une autre
histoire.

pour un ordinateur personnel ça change quelque chose ?

Oui.

le PCI express c'est bien ?

J'ai un gros faible pour le PCI-X. Le PCI-E, c'est un bricolage
infâme électroniquement parlant. Disons que le PCI-X est moins moisi
que le PCI-E.

oui mais en efficacité ?
On ne parle là que d'un bus, si ça transit mieux en PCI-E moisi ou pas,
je ne comprend pas ...

Le PCI-E permet de faire économique au détriment de tout le reste
parce qu'on ne cherche pas à synchroniser des signaux. Par rapport à
du PCI-X, c'est _mauvais_. D'ailleurs lorsque j'achète mes serveurs
en rack, j'ai le choix entre un riser PCI-E et un PCI-X. Le PCI-E
est proposé parce que toutes les cartes du monde PC fonctionnent à
peu près, le PCI-X, pour pouvoir mettre des cartes avec des taux de
transferts en soutenu plus sérieux.

Pas forcément beaucoup plus cher qu'un PC équivalent (d'autant que
l'amortissement comptable n'est pas le même).

L'amortissement n'en réduit pas le coût !

À toi de voir s'il faut acheter un serveur à 4000 euros amortissable
en 6 ans ou un serveur x86 cd 2500 euros amortissable en 3 ans. Mon
choix est fait.

Moi je reverrai d'avoir un ordinateur personnel qui consomme rien et
rapide et surtout peu cher ! ça existe ?

Cette remarque m'insite à te demander de chercher par toi même les
prix de ces machines.

mais voilà, je ne sais pas où chercher !
Car je ne sais même pas ce qui existe et qui peut revendre !

Sun, Fujitsu, HP (les prix sont public), IBM si tu téléphones.

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.

yl

03/01/2010 à 22:13

In article ,
Stephane TOUGARD writes:

Inconvenient, ca prend de l'espace disque. Mais je m'en contrefous, j'ai
des applications qui generent plusieurs GB de logs par semaine, les 3Mb
pris par une vieille version de Apache ne me genent pas plus que ca.

Je crois que tu n'as pas compris, mais en fait c'est hypothétique :
c'est au cas ou tu as besoin des bibiothèques d'Apache pour un autre
soft que tu risques de te retrouver avec des liens dynamiques un peu
hasardeux.

Je t'explique comment je vois les choses si tu utilises une ditribution
(on va prendre debian parce qu'on connait tous les duex un peu).

ça va pas te plaire.

Tu installes la nouvelle version (packagée en binaire mais portée et
patchée vu que tu as besoin d'une version ad hoc d'Apache sur une machine
qui ne te sert qu'à ça (compiler). Tu empaquètes et tu déploies sur les
machines qui ne sont pas en production, tu fais les tests d'usine sur
ces machines et si c'est OK tu les mets en production à la place des
autres. Tout ça se scripte. Tu as juste à programmer le batch et à
regarder les logs pendant le processus (ça va en faire quelques
kilomètres il faut les parser.) Au lieu d'avoir 5'' d'interruption
de service tu as 50ms. Tu peux réduire les timeouts d'autant sur
tout ton réseau client.

Description de la machine pour compiler (tu peux simplifier la
configuration parce que tous les paramètres ne sont pas essentiel
pour un bon fonctionnement dans tous les environnement : là c'est
le convoyeur que je décris. Tu n'as peut-etre besoin que d'un
triporteur.

- Le FS adéquat. Il y a des benchmarks pour ça et selon l'usage
ce n'est pas forcément le meme système de fichier qui est le plus
adéquat.
/usr/lib/include et /lib/include complets
(tu n'as pas besoin des bibliothèques qui ne servent pas à la
compilation, tu les vires manu militari. Sur debian c'est simplissime :

aptitude install toto toto-dev
dpkg --force-depend --remove toto

Ce qui peut se faire aussi :

dpkg --force-depend --install toto-dev.deb {paquets dev des dépendancs de toto}

Va faire ça proprement avec un autre système de paquets que dpkg...

La place tu vas en avoir besoin pour que le code soit optimisé
en plusieurs passes (la compilation en plusieurs passe ne sert
à rien c'est une affaire entendue, mais tu ne déploie pas forcément
pour une seule architecture. Aussi une compilation en deux passes est
tout à fait envisageable (avec un byte-code différent par type
d'architecture (gros-boutistes, petits-boutistes, taille du bus physique
etc.)))
Tu as intéret à avoir un calculateur puissant. Si tu ne disposes que de
systèmes hétéroclites, tu peux aussi envisager de déployer sur une
machine virtuelle répartie (c'est beaucoup plus facile à déployer sur
une grille homogène (c'est meme totalement transparent pour
l'utilisateur qui dispose alors d'une machine unix dont la capacité
totale varie en fonction de ses besoins) mais c'est tout à fait
envisageable aussi sur un parc hétérogène.

Une fois ton code compilé tu l'installes sur les machines de préprod par un
mécanisme standard et automatisé (pourquoi s'emmerder et utiliser autre
chose que dpkg mais rien ne t'interdit de te servir de ce que tu veux y
compris un outil ad-hoc. Le meilleur moyen de déployer automatiquement
avec l'outil ad-hoc ou un outil standard (rmp deb ou yum ou autres),
si tu disposes d'un parc hétérogène qui sont en round robin par exemple...
ce sont des acteurs réseau (JavAct est le seul que je connais. Je connais
plus ses limites théoriques que ses limites pratiques ceci dit. Je sais
ce que ça ne peut pas encore faire avec :) et je sais comment faire ce
qu'on sait que ça peut déjà faire mais je suis un piètre programmeur.

http://www.irit.fr/ http://www.irit.fr/JavAct http://www.javact.org/

Une fois déployé sur tes serveurs de préproduction, tu peux faire des
tests d'usine dessus. Si c'est OK tu swappe les DNS de tes serveurs. Je
présuppose que ton réseau local est en TCP/IP. Si ce n'est pas le cas il
faut adapter. Bref tu mets à jour tes pages blanches - quel que soit le
réseau déployé ça parle, en principe à part si c'est un réseau stupide
(comme TCP/IP, par exemple).

Si tu as besoin de beaucoup de machines sur ton round robin, tu fais
tourner deux machines virtuelles sur chaque système de ton réseau
départemental machine-a.on.4242.MAN.local.example,
machine-b.on.4242.LAN.local.example par exemple.

Tu déploies les jours pairs sur les a, les jours impairs sur les b. Les
mois sans r tu fais des tests d'usine sur ton LAN.

et tu utilises pour le RR les machines n-paires avec le serveur à jour, et
les machines congrues à zéro modulo ton nombre premier préféré avec le
serveur à latest-stable. Les autres du MAN sont en testing. Si tu
constate une régression tu déploie sur les machines virtuelles qui
sont en testing. Si ça diverge tu augmentes n (tu passe d'une machine/16
à une machine/32 par exemple... Si tu constate une
régression, tu redéploie sur les machines b (si le jour est pair et
qu'elles sont de repos) la version stale-stable c'est à dire la version
la plus prometteuse que tu as abandonné au profit d'une version plus
prometteuse (dans la file, elle se trouve en avant-dernière position.
La file n'a pas besoin d'etre longue, le gain des versions plus anciennes
étant réputées inférieures à la meilleure des r plus récentes.
0<r<capacité/taille et tu vires du tampon circulaire la version buguée.
De temps en temps tu redistribues les cartes : tu change l'ordre de
passage dans ton round robin pour favoriser les versions qui semblent le
plus stable. Si les versions en testing pepsent tu les promeut et donc
tu vires du tampon circulaire la version la moins efficace (tu déploie
la version promue sur la moitié des machines, celles qui sont en repos
(b si jour pair, a si jour impair)

Si tu n'as vraiment pas de souci d'espace de stockage sur la ferme de
compilation, tu n'as pas besoin de virer manu militari les
bibliothèques pour gagner de la place, toute la ribambelle d'interprètes
et de compileurs (perl, python, lua, etc.) les parsers et les générateurs
bison, (j)flex etc. y seront par contre bienvenus si tu dois manipuler
des formats : tout ça ne s'applique pas à Apache, par contre à la chaine
graphique oui. La charge de tes serveurs ne bouge pas d'un iota, aucune
embrouille, aucune interruption de service juste le temps de swapper tes
pages blanches. Et si en plus tu as un serveur de pages jaunes tu peux
meme le faire plus subtilement. C'est la machine (a ou b) qui va
s'annoncer : bonjour, je suis monsieur B, mon immatriculation est 314159
je dispose de la version stale-stable. Bonjour, je suis madame A, j'ai le
privilège de disposer de la version testing. Mon indicatif est le 8867.
Bonjour, je suis monsieur w, ma version elle est pile poil celle qu'il
vous faut. ne demandez le service à personne d'autre qu'à moi, je suis
numéro 1. (monsieur w est un bad boy, installé par un kiddy-script sur
une des machines de ton LAN) etc. Si tu n'as pas de pages jaunes de
temps en temps tu redistribues les adresses dans le Round Robin, ou
bien tu le fais en fonction de tes constats d'efficacité des différentes
versions déployées sur ton réseau.

--
http://mikeread.tripod.com/archive.htm

In article <mfg617-3rp1.ln1@gulliver.unices.org>,
Stephane TOUGARD <jkb@unices.org> writes:

Inconvenient, ca prend de l'espace disque. Mais je m'en contrefous, j'ai
des applications qui generent plusieurs GB de logs par semaine, les 3Mb
pris par une vieille version de Apache ne me genent pas plus que ca.

Je crois que tu n'as pas compris, mais en fait c'est hypothétique :
c'est au cas ou tu as besoin des bibiothèques d'Apache pour un autre
soft que tu risques de te retrouver avec des liens dynamiques un peu
hasardeux.

Je t'explique comment je vois les choses si tu utilises une ditribution
(on va prendre debian parce qu'on connait tous les duex un peu).

ça va pas te plaire.

Tu installes la nouvelle version (packagée en binaire mais portée et
patchée vu que tu as besoin d'une version ad hoc d'Apache sur une machine
qui ne te sert qu'à ça (compiler). Tu empaquètes et tu déploies sur les
machines qui ne sont pas en production, tu fais les tests d'usine sur
ces machines et si c'est OK tu les mets en production à la place des
autres. Tout ça se scripte. Tu as juste à programmer le batch et à
regarder les logs pendant le processus (ça va en faire quelques
kilomètres il faut les parser.) Au lieu d'avoir 5'' d'interruption
de service tu as 50ms. Tu peux réduire les timeouts d'autant sur
tout ton réseau client.

Description de la machine pour compiler (tu peux simplifier la
configuration parce que tous les paramètres ne sont pas essentiel
pour un bon fonctionnement dans tous les environnement : là c'est
le convoyeur que je décris. Tu n'as peut-etre besoin que d'un
triporteur.

- Le FS adéquat. Il y a des benchmarks pour ça et selon l'usage
ce n'est pas forcément le meme système de fichier qui est le plus
adéquat.
/usr/lib/include et /lib/include complets
(tu n'as pas besoin des bibliothèques qui ne servent pas à la
compilation, tu les vires manu militari. Sur debian c'est simplissime :

aptitude install toto toto-dev
dpkg --force-depend --remove toto

Ce qui peut se faire aussi :

dpkg --force-depend --install toto-dev.deb {paquets dev des dépendancs de toto}

Va faire ça proprement avec un autre système de paquets que dpkg...

La place tu vas en avoir besoin pour que le code soit optimisé
en plusieurs passes (la compilation en plusieurs passe ne sert
à rien c'est une affaire entendue, mais tu ne déploie pas forcément
pour une seule architecture. Aussi une compilation en deux passes est
tout à fait envisageable (avec un byte-code différent par type
d'architecture (gros-boutistes, petits-boutistes, taille du bus physique
etc.)))
Tu as intéret à avoir un calculateur puissant. Si tu ne disposes que de
systèmes hétéroclites, tu peux aussi envisager de déployer sur une
machine virtuelle répartie (c'est beaucoup plus facile à déployer sur
une grille homogène (c'est meme totalement transparent pour
l'utilisateur qui dispose alors d'une machine unix dont la capacité
totale varie en fonction de ses besoins) mais c'est tout à fait
envisageable aussi sur un parc hétérogène.

Une fois ton code compilé tu l'installes sur les machines de préprod par un
mécanisme standard et automatisé (pourquoi s'emmerder et utiliser autre
chose que dpkg mais rien ne t'interdit de te servir de ce que tu veux y
compris un outil ad-hoc. Le meilleur moyen de déployer automatiquement
avec l'outil ad-hoc ou un outil standard (rmp deb ou yum ou autres),
si tu disposes d'un parc hétérogène qui sont en round robin par exemple...
ce sont des acteurs réseau (JavAct est le seul que je connais. Je connais
plus ses limites théoriques que ses limites pratiques ceci dit. Je sais
ce que ça ne peut pas encore faire avec :) et je sais comment faire ce
qu'on sait que ça peut déjà faire mais je suis un piètre programmeur.

http://www.irit.fr/ http://www.irit.fr/JavAct http://www.javact.org/

Une fois déployé sur tes serveurs de préproduction, tu peux faire des
tests d'usine dessus. Si c'est OK tu swappe les DNS de tes serveurs. Je
présuppose que ton réseau local est en TCP/IP. Si ce n'est pas le cas il
faut adapter. Bref tu mets à jour tes pages blanches - quel que soit le
réseau déployé ça parle, en principe à part si c'est un réseau stupide
(comme TCP/IP, par exemple).

Si tu as besoin de beaucoup de machines sur ton round robin, tu fais
tourner deux machines virtuelles sur chaque système de ton réseau
départemental machine-a.on.4242.MAN.local.example,
machine-b.on.4242.LAN.local.example par exemple.

Tu déploies les jours pairs sur les a, les jours impairs sur les b. Les
mois sans r tu fais des tests d'usine sur ton LAN.

et tu utilises pour le RR les machines n-paires avec le serveur à jour, et
les machines congrues à zéro modulo ton nombre premier préféré avec le
serveur à latest-stable. Les autres du MAN sont en testing. Si tu
constate une régression tu déploie sur les machines virtuelles qui
sont en testing. Si ça diverge tu augmentes n (tu passe d'une machine/16
à une machine/32 par exemple... Si tu constate une
régression, tu redéploie sur les machines b (si le jour est pair et
qu'elles sont de repos) la version stale-stable c'est à dire la version
la plus prometteuse que tu as abandonné au profit d'une version plus
prometteuse (dans la file, elle se trouve en avant-dernière position.
La file n'a pas besoin d'etre longue, le gain des versions plus anciennes
étant réputées inférieures à la meilleure des r plus récentes.
0<r<capacité/taille et tu vires du tampon circulaire la version buguée.
De temps en temps tu redistribues les cartes : tu change l'ordre de
passage dans ton round robin pour favoriser les versions qui semblent le
plus stable. Si les versions en testing pepsent tu les promeut et donc
tu vires du tampon circulaire la version la moins efficace (tu déploie
la version promue sur la moitié des machines, celles qui sont en repos
(b si jour pair, a si jour impair)

Si tu n'as vraiment pas de souci d'espace de stockage sur la ferme de
compilation, tu n'as pas besoin de virer manu militari les
bibliothèques pour gagner de la place, toute la ribambelle d'interprètes
et de compileurs (perl, python, lua, etc.) les parsers et les générateurs
bison, (j)flex etc. y seront par contre bienvenus si tu dois manipuler
des formats : tout ça ne s'applique pas à Apache, par contre à la chaine
graphique oui. La charge de tes serveurs ne bouge pas d'un iota, aucune
embrouille, aucune interruption de service juste le temps de swapper tes
pages blanches. Et si en plus tu as un serveur de pages jaunes tu peux
meme le faire plus subtilement. C'est la machine (a ou b) qui va
s'annoncer : bonjour, je suis monsieur B, mon immatriculation est 314159
je dispose de la version stale-stable. Bonjour, je suis madame A, j'ai le
privilège de disposer de la version testing. Mon indicatif est le 8867.
Bonjour, je suis monsieur w, ma version elle est pile poil celle qu'il
vous faut. ne demandez le service à personne d'autre qu'à moi, je suis
numéro 1. (monsieur w est un bad boy, installé par un kiddy-script sur
une des machines de ton LAN) etc. Si tu n'as pas de pages jaunes de
temps en temps tu redistribues les adresses dans le Round Robin, ou
bien tu le fais en fonction de tes constats d'efficacité des différentes
versions déployées sur ton réseau.

--
http://mikeread.tripod.com/archive.htm

Vous avez filtré cet utilisateur ! Consultez son message

In article ,
Stephane TOUGARD writes:

Inconvenient, ca prend de l'espace disque. Mais je m'en contrefous, j'ai
des applications qui generent plusieurs GB de logs par semaine, les 3Mb
pris par une vieille version de Apache ne me genent pas plus que ca.

Je crois que tu n'as pas compris, mais en fait c'est hypothétique :
c'est au cas ou tu as besoin des bibiothèques d'Apache pour un autre
soft que tu risques de te retrouver avec des liens dynamiques un peu
hasardeux.

Je t'explique comment je vois les choses si tu utilises une ditribution
(on va prendre debian parce qu'on connait tous les duex un peu).

ça va pas te plaire.

Tu installes la nouvelle version (packagée en binaire mais portée et
patchée vu que tu as besoin d'une version ad hoc d'Apache sur une machine
qui ne te sert qu'à ça (compiler). Tu empaquètes et tu déploies sur les
machines qui ne sont pas en production, tu fais les tests d'usine sur
ces machines et si c'est OK tu les mets en production à la place des
autres. Tout ça se scripte. Tu as juste à programmer le batch et à
regarder les logs pendant le processus (ça va en faire quelques
kilomètres il faut les parser.) Au lieu d'avoir 5'' d'interruption
de service tu as 50ms. Tu peux réduire les timeouts d'autant sur
tout ton réseau client.

Description de la machine pour compiler (tu peux simplifier la
configuration parce que tous les paramètres ne sont pas essentiel
pour un bon fonctionnement dans tous les environnement : là c'est
le convoyeur que je décris. Tu n'as peut-etre besoin que d'un
triporteur.

- Le FS adéquat. Il y a des benchmarks pour ça et selon l'usage
ce n'est pas forcément le meme système de fichier qui est le plus
adéquat.
/usr/lib/include et /lib/include complets
(tu n'as pas besoin des bibliothèques qui ne servent pas à la
compilation, tu les vires manu militari. Sur debian c'est simplissime :

aptitude install toto toto-dev
dpkg --force-depend --remove toto

Ce qui peut se faire aussi :

dpkg --force-depend --install toto-dev.deb {paquets dev des dépendancs de toto}

Va faire ça proprement avec un autre système de paquets que dpkg...

La place tu vas en avoir besoin pour que le code soit optimisé
en plusieurs passes (la compilation en plusieurs passe ne sert
à rien c'est une affaire entendue, mais tu ne déploie pas forcément
pour une seule architecture. Aussi une compilation en deux passes est
tout à fait envisageable (avec un byte-code différent par type
d'architecture (gros-boutistes, petits-boutistes, taille du bus physique
etc.)))
Tu as intéret à avoir un calculateur puissant. Si tu ne disposes que de
systèmes hétéroclites, tu peux aussi envisager de déployer sur une
machine virtuelle répartie (c'est beaucoup plus facile à déployer sur
une grille homogène (c'est meme totalement transparent pour
l'utilisateur qui dispose alors d'une machine unix dont la capacité
totale varie en fonction de ses besoins) mais c'est tout à fait
envisageable aussi sur un parc hétérogène.

Une fois ton code compilé tu l'installes sur les machines de préprod par un
mécanisme standard et automatisé (pourquoi s'emmerder et utiliser autre
chose que dpkg mais rien ne t'interdit de te servir de ce que tu veux y
compris un outil ad-hoc. Le meilleur moyen de déployer automatiquement
avec l'outil ad-hoc ou un outil standard (rmp deb ou yum ou autres),
si tu disposes d'un parc hétérogène qui sont en round robin par exemple...
ce sont des acteurs réseau (JavAct est le seul que je connais. Je connais
plus ses limites théoriques que ses limites pratiques ceci dit. Je sais
ce que ça ne peut pas encore faire avec :) et je sais comment faire ce
qu'on sait que ça peut déjà faire mais je suis un piètre programmeur.

http://www.irit.fr/ http://www.irit.fr/JavAct http://www.javact.org/

Une fois déployé sur tes serveurs de préproduction, tu peux faire des
tests d'usine dessus. Si c'est OK tu swappe les DNS de tes serveurs. Je
présuppose que ton réseau local est en TCP/IP. Si ce n'est pas le cas il
faut adapter. Bref tu mets à jour tes pages blanches - quel que soit le
réseau déployé ça parle, en principe à part si c'est un réseau stupide
(comme TCP/IP, par exemple).

Si tu as besoin de beaucoup de machines sur ton round robin, tu fais
tourner deux machines virtuelles sur chaque système de ton réseau
départemental machine-a.on.4242.MAN.local.example,
machine-b.on.4242.LAN.local.example par exemple.

Tu déploies les jours pairs sur les a, les jours impairs sur les b. Les
mois sans r tu fais des tests d'usine sur ton LAN.

et tu utilises pour le RR les machines n-paires avec le serveur à jour, et
les machines congrues à zéro modulo ton nombre premier préféré avec le
serveur à latest-stable. Les autres du MAN sont en testing. Si tu
constate une régression tu déploie sur les machines virtuelles qui
sont en testing. Si ça diverge tu augmentes n (tu passe d'une machine/16
à une machine/32 par exemple... Si tu constate une
régression, tu redéploie sur les machines b (si le jour est pair et
qu'elles sont de repos) la version stale-stable c'est à dire la version
la plus prometteuse que tu as abandonné au profit d'une version plus
prometteuse (dans la file, elle se trouve en avant-dernière position.
La file n'a pas besoin d'etre longue, le gain des versions plus anciennes
étant réputées inférieures à la meilleure des r plus récentes.
0<r<capacité/taille et tu vires du tampon circulaire la version buguée.
De temps en temps tu redistribues les cartes : tu change l'ordre de
passage dans ton round robin pour favoriser les versions qui semblent le
plus stable. Si les versions en testing pepsent tu les promeut et donc
tu vires du tampon circulaire la version la moins efficace (tu déploie
la version promue sur la moitié des machines, celles qui sont en repos
(b si jour pair, a si jour impair)

Si tu n'as vraiment pas de souci d'espace de stockage sur la ferme de
compilation, tu n'as pas besoin de virer manu militari les
bibliothèques pour gagner de la place, toute la ribambelle d'interprètes
et de compileurs (perl, python, lua, etc.) les parsers et les générateurs
bison, (j)flex etc. y seront par contre bienvenus si tu dois manipuler
des formats : tout ça ne s'applique pas à Apache, par contre à la chaine
graphique oui. La charge de tes serveurs ne bouge pas d'un iota, aucune
embrouille, aucune interruption de service juste le temps de swapper tes
pages blanches. Et si en plus tu as un serveur de pages jaunes tu peux
meme le faire plus subtilement. C'est la machine (a ou b) qui va
s'annoncer : bonjour, je suis monsieur B, mon immatriculation est 314159
je dispose de la version stale-stable. Bonjour, je suis madame A, j'ai le
privilège de disposer de la version testing. Mon indicatif est le 8867.
Bonjour, je suis monsieur w, ma version elle est pile poil celle qu'il
vous faut. ne demandez le service à personne d'autre qu'à moi, je suis
numéro 1. (monsieur w est un bad boy, installé par un kiddy-script sur
une des machines de ton LAN) etc. Si tu n'as pas de pages jaunes de
temps en temps tu redistribues les adresses dans le Round Robin, ou
bien tu le fais en fonction de tes constats d'efficacité des différentes
versions déployées sur ton réseau.

--
http://mikeread.tripod.com/archive.htm

JKB

03/01/2010 à 22:13

Le 03-01-2010, ? propos de
Re: KDE tuera Windows,
P4nd1-P4nd4 ?crivait dans fr.comp.os.linux.debats :

pipantal avait énoncé :
JKB a écrit :

Le SATA c'est bien ?

Si j'ai le choix entre SATA, SAS et SCSI-U320, c'est immédiatement
le SCSI-U320 qui l'emporte. Si on rajoute le FCAL, c'est une autre
histoire.

Ahahaha

Tiens, des chiffres.

J'ai un gros faible pour le PCI-X. Le PCI-E, c'est un bricolage
infâme électroniquement parlant. Disons que le PCI-X est moins moisi
que le PCI-E.

Hohohohohoho

C'est un peu court, jeune homme.

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.

KDE tuera Windows

10 réponses

Veuillez sélectionner un problème