Quand le bureau KDE et toutes ses applications seront portés sur Windows
(on s'en rapproche pour ceux qui suivent, les applications deviennent de
plus en plus stables), celui-ci envahira Windows car, contrairement à
Linux qui possède des dizaines de bureaux, il sera l'unique alternative
au bureau Windows : KDE apporterait un souffle nouveau à Windows, en
tous cas plus que le bureau de Seven.
Du coup, l'utilisateur lambda (qui est l'utilisateur très largement
majoritaire) ne verra plus la différence entre un Windows et un linux
(ou un OpenSolaris ou un BSD) qui tournera derrière et au bout du
compte, il préférera naturellement se tourner vers l'OS qui lui coûte le
moins cher.
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 à cause de microsoft, intel et IBM. Marges arrière payé à microsoft aux constructeurs pour qu'ils installe sa bouse qu'ils récupèrent avec un bonus quand la machine et vendue, et le cercle vicieux est bouclé.
-- http://mikeread.tripod.com/archive.htm
In article <9E60n.15870$0U1.4218@newsfe16.iad>,
Dellara <paul.pygeon@gmail.com> writes:
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 à cause de microsoft, intel et IBM. Marges arrière payé à
microsoft aux constructeurs pour qu'ils installe sa bouse qu'ils
récupèrent avec un bonus quand la machine et vendue, et le cercle
vicieux est bouclé.
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 à cause de microsoft, intel et IBM. Marges arrière payé à microsoft aux constructeurs pour qu'ils installe sa bouse qu'ils récupèrent avec un bonus quand la machine et vendue, et le cercle vicieux est bouclé.
-- http://mikeread.tripod.com/archive.htm
yl
In article , P4nd1-P4nd4 writes:
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
Mais c'est faux. Tu ne peux pas comparer un rack qui ne peut pas marcher tout seul et qui n'est qu'un élément d'un supercalculateur et un PC. Les deux sont avcec une architecture i386 et c'est tout. Il y a dans top500g moyen de filtrer pour ne pas mettre les systèmes // mais que les systèmes avec une seule carte mère. Là Intel se retrouve radagué. Le développement d'un processeur coute énormément cher. C'est un consortium AMD/Intel+ d'autres qui paient la recherche, après ils se répartissent l'industrialisation. Si tu fais un processeur avec une auutre architecture, le développement coute aussi cher, mais comme tu n'as que 1% de parts de marché, l'amortissement de l'investissment est fait que le pricx doit etre multiplié par 10. Le seul avantage des PC c'est qu'ils ne coutent pas cher. Mais c'est pourri.
-- http://mikeread.tripod.com/archive.htm
In article <BKGdnVMxmc91Y93WnZ2dnUVZ8nidnZ2d@giganews.com>,
P4nd1-P4nd4 <P4nd1-P4nd4@.net> writes:
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
Mais c'est faux. Tu ne peux pas comparer un rack qui ne peut pas marcher
tout seul et qui n'est qu'un élément d'un supercalculateur et un PC. Les
deux sont avcec une architecture i386 et c'est tout. Il y a dans
top500g moyen de filtrer pour ne pas mettre les systèmes // mais que
les systèmes avec une seule carte mère. Là Intel se retrouve radagué.
Le développement d'un processeur coute énormément cher. C'est un
consortium AMD/Intel+ d'autres qui paient la recherche, après ils se
répartissent l'industrialisation. Si tu fais un processeur avec une
auutre architecture, le développement coute aussi cher, mais comme tu
n'as que 1% de parts de marché, l'amortissement de l'investissment est
fait que le pricx doit etre multiplié par 10. Le seul avantage des PC
c'est qu'ils ne coutent pas cher. Mais c'est pourri.
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
Mais c'est faux. Tu ne peux pas comparer un rack qui ne peut pas marcher tout seul et qui n'est qu'un élément d'un supercalculateur et un PC. Les deux sont avcec une architecture i386 et c'est tout. Il y a dans top500g moyen de filtrer pour ne pas mettre les systèmes // mais que les systèmes avec une seule carte mère. Là Intel se retrouve radagué. Le développement d'un processeur coute énormément cher. C'est un consortium AMD/Intel+ d'autres qui paient la recherche, après ils se répartissent l'industrialisation. Si tu fais un processeur avec une auutre architecture, le développement coute aussi cher, mais comme tu n'as que 1% de parts de marché, l'amortissement de l'investissment est fait que le pricx doit etre multiplié par 10. Le seul avantage des PC c'est qu'ils ne coutent pas cher. Mais c'est pourri.
-- http://mikeread.tripod.com/archive.htm
yl
In article , P4nd1-P4nd4 writes:
79,2 % utilisent des Intel X86 acec extensions 64 bits...
Il y en a combien d'Intel sur un supercalculateur, clown ?
-- http://mikeread.tripod.com/archive.htm
In article <fYCdnbsOm9rOm9zWnZ2dnUVZ8oCdnZ2d@giganews.com>,
P4nd1-P4nd4 <P4nd1-P4nd4@.net> writes:
79,2 % utilisent des Intel X86 acec extensions 64 bits...
Il y en a combien d'Intel sur un supercalculateur, clown ?
Venant de toi, c'est un compliment qui va droit au coeur.
-- http://unices.over-blog.com/ Un Francais en Chine
Stephane TOUGARD
Stéphane CARPENTIER a perdu son temps a nous dire:
Comment pourraient-ils avoir tort sur ce point puisque Debian a ses propres regles pour definir son propre environnement ?
c'est à toi de nous l'expliquer, c'est toi qui dit qu'il est scandaleux qu'ils changent les répertoires par défaut des softs.
Je dis pas que c'est scandaleux, il y a pas de scandale la dedans, les gens de Debian font ce qu'ils veulent.
Je dis simplement que c'est pas ma facon de bosser et que je n'utilise pas la Debian parce que je ne suis pas d'accord avec la facon de travailler des gens qui la font.
-- http://unices.over-blog.com/ Un Francais en Chine
Stéphane CARPENTIER a perdu son temps a nous dire:
Comment pourraient-ils avoir tort sur ce point puisque Debian a ses
propres regles pour definir son propre environnement ?
c'est à toi de nous l'expliquer, c'est toi qui dit qu'il est scandaleux
qu'ils changent les répertoires par défaut des softs.
Je dis pas que c'est scandaleux, il y a pas de scandale la dedans, les
gens de Debian font ce qu'ils veulent.
Je dis simplement que c'est pas ma facon de bosser et que je n'utilise
pas la Debian parce que je ne suis pas d'accord avec la facon de
travailler des gens qui la font.
--
http://unices.over-blog.com/ Un Francais en Chine
Stéphane CARPENTIER a perdu son temps a nous dire:
Comment pourraient-ils avoir tort sur ce point puisque Debian a ses propres regles pour definir son propre environnement ?
c'est à toi de nous l'expliquer, c'est toi qui dit qu'il est scandaleux qu'ils changent les répertoires par défaut des softs.
Je dis pas que c'est scandaleux, il y a pas de scandale la dedans, les gens de Debian font ce qu'ils veulent.
Je dis simplement que c'est pas ma facon de bosser et que je n'utilise pas la Debian parce que je ne suis pas d'accord avec la facon de travailler des gens qui la font.
-- http://unices.over-blog.com/ Un Francais en Chine
Stephane TOUGARD
Yves Lambert a perdu son temps a nous dire:
Dans l'OpenSource, je vois pas.
Voila. Et windows7 ne tourne pas sur vax, étonnant, non ?
Ah maintenant que j'y pense, il me semble qu'il y a un OS d'IBM qui est domaine publique, je crois qu'il s'agit de l'OS qui tournait sur les System/370 et qu'on peut maintenant faire tourner sur un emulateur Hercules.
-- http://unices.over-blog.com/ Un Francais en Chine
Yves Lambert a perdu son temps a nous dire:
Dans l'OpenSource, je vois pas.
Voila. Et windows7 ne tourne pas sur vax, étonnant, non ?
Ah maintenant que j'y pense, il me semble qu'il y a un OS d'IBM qui est
domaine publique, je crois qu'il s'agit de l'OS qui tournait sur les
System/370 et qu'on peut maintenant faire tourner sur un emulateur
Hercules.
--
http://unices.over-blog.com/ Un Francais en Chine
Voila. Et windows7 ne tourne pas sur vax, étonnant, non ?
Ah maintenant que j'y pense, il me semble qu'il y a un OS d'IBM qui est domaine publique, je crois qu'il s'agit de l'OS qui tournait sur les System/370 et qu'on peut maintenant faire tourner sur un emulateur Hercules.
-- http://unices.over-blog.com/ Un Francais en Chine
Stephane TOUGARD
Yves Lambert a perdu son temps a nous dire:
ça va se voir que tu ne sais pas lire. Il était juste question de softs qui ne sont supportés que sur la redhat et d'autres qui ne sont supporté que sur la suse, PK plussoie avec Solaris et ne parle certainement pas de stats.
Question de contexte, mais si ...
-- http://unices.over-blog.com/ Un Francais en Chine
Yves Lambert a perdu son temps a nous dire:
ça va se voir que tu ne sais pas lire. Il était juste question de softs qui
ne sont supportés que sur la redhat et d'autres qui ne sont supporté
que sur la suse, PK plussoie avec Solaris et ne parle certainement pas de
stats.
Question de contexte, mais si ...
--
http://unices.over-blog.com/ Un Francais en Chine
ça va se voir que tu ne sais pas lire. Il était juste question de softs qui ne sont supportés que sur la redhat et d'autres qui ne sont supporté que sur la suse, PK plussoie avec Solaris et ne parle certainement pas de stats.
Question de contexte, mais si ...
-- http://unices.over-blog.com/ Un Francais en Chine
Stephane TOUGARD
Yves Lambert a perdu son temps a nous dire:
Oui bon, après réflexion, je ne suis plus tout à fait d'accord avec PK et SC, mais j'ai mieux compris le souci. Si tu as une machine compromlise sur le réseau, et qu'elle dispose d'une chaine de compilation complète, celle ci peut etre utilisée pour installer le rootkit le plus vicieux, une bombe ou tout autre malware, alors que si ce n'est pas le cas, l'attaquant resterait dans son rootjail et ne peut rien faire d'autre que ce que tu lui permet. Ce n'est pas le code du logiciel qui est en jeu, mais le fait de le compiler sur le serveur de prod (et donc que celui ci embarque make, gcc et wget)
Tu m'expliques qu'est ce qui interdit de faire un rootkit avec un binaire statique deja importe d'une autre machine ? ou meme en Perl, en bash ou en whatever.
Faire tourner un programme n'est pas vraiment un probleme sur Unix, pas besoin d'un compilo pour ca.
-- http://unices.over-blog.com/ Un Francais en Chine
Yves Lambert a perdu son temps a nous dire:
Oui bon, après réflexion, je ne suis plus tout à fait d'accord avec PK et
SC, mais j'ai mieux compris le souci. Si tu as une machine compromlise
sur le réseau, et qu'elle dispose d'une chaine de compilation complète,
celle ci peut etre utilisée pour installer le rootkit le plus vicieux,
une bombe ou tout autre malware, alors que si ce n'est pas le cas,
l'attaquant resterait dans son rootjail et ne peut rien faire d'autre
que ce que tu lui permet. Ce n'est pas le code du logiciel qui est en
jeu, mais le fait de le compiler sur le serveur de prod (et donc que
celui ci embarque make, gcc et wget)
Tu m'expliques qu'est ce qui interdit de faire un rootkit avec un
binaire statique deja importe d'une autre machine ? ou meme en Perl, en
bash ou en whatever.
Faire tourner un programme n'est pas vraiment un probleme sur Unix, pas
besoin d'un compilo pour ca.
--
http://unices.over-blog.com/ Un Francais en Chine
Oui bon, après réflexion, je ne suis plus tout à fait d'accord avec PK et SC, mais j'ai mieux compris le souci. Si tu as une machine compromlise sur le réseau, et qu'elle dispose d'une chaine de compilation complète, celle ci peut etre utilisée pour installer le rootkit le plus vicieux, une bombe ou tout autre malware, alors que si ce n'est pas le cas, l'attaquant resterait dans son rootjail et ne peut rien faire d'autre que ce que tu lui permet. Ce n'est pas le code du logiciel qui est en jeu, mais le fait de le compiler sur le serveur de prod (et donc que celui ci embarque make, gcc et wget)
Tu m'expliques qu'est ce qui interdit de faire un rootkit avec un binaire statique deja importe d'une autre machine ? ou meme en Perl, en bash ou en whatever.
Faire tourner un programme n'est pas vraiment un probleme sur Unix, pas besoin d'un compilo pour ca.
-- http://unices.over-blog.com/ Un Francais en Chine
Stephane TOUGARD
Yves Lambert a perdu son temps a nous dire:
ça ne répond toujours pas à ma question : pourquoi c'est MAL de mettre un spamd sur le mx frontal (qu'il tourne en socket unix ou en socket tcp, sur le serveur de mail ou une autre machine n'entre pas en jeu dans la question) et que ce soit postfix ou exim4 ne change strictement rien au problème puisque les deux le permettent. Je n'y vois que des avantages (à part le temps machine). Je ne sais pas qui a dit que c'était mal, qu'il se dénonce et m'explique pourquoi.
Ce n'est pas une question de mettre le process spamd sur le serveur physique qui est frontal ou sur n'importe quel autre serveur. Le point est ou est-ce qu'on traite l'email avec l'anti-spam.
Si tu les traites par le smtpd, en cas d'attaque violente, tu vas te retrouver avec 120 process de spamd et un serveur par terre.
Si smtpd accepte tous les emails, les mets dans un spool, puis tu traites l'anti-spam avec un nombre connu de process, tu vas mettre du delai dans le traitement, mais ton service sera toujours debout.
Je prefere la seconde option a la premiere. Parce qu'il faut mieux gerer un delai sur un service qui tourne toujours qu'essayer de relever un serveur qui se tappe une charge de 120.
-- http://unices.over-blog.com/ Un Francais en Chine
Yves Lambert a perdu son temps a nous dire:
ça ne répond toujours pas à ma question : pourquoi c'est MAL de mettre un spamd
sur le mx frontal (qu'il tourne en socket unix ou en socket tcp, sur le
serveur de mail ou une autre machine n'entre pas en jeu dans la
question) et que ce soit postfix ou exim4 ne change strictement rien au
problème puisque les deux le permettent. Je n'y vois que des avantages
(à part le temps machine). Je ne sais pas qui a dit que c'était mal,
qu'il se dénonce et m'explique pourquoi.
Ce n'est pas une question de mettre le process spamd sur le serveur
physique qui est frontal ou sur n'importe quel autre serveur. Le point
est ou est-ce qu'on traite l'email avec l'anti-spam.
Si tu les traites par le smtpd, en cas d'attaque violente, tu vas te
retrouver avec 120 process de spamd et un serveur par terre.
Si smtpd accepte tous les emails, les mets dans un spool, puis tu
traites l'anti-spam avec un nombre connu de process, tu vas mettre du
delai dans le traitement, mais ton service sera toujours debout.
Je prefere la seconde option a la premiere. Parce qu'il faut mieux gerer
un delai sur un service qui tourne toujours qu'essayer de relever un
serveur qui se tappe une charge de 120.
--
http://unices.over-blog.com/ Un Francais en Chine
ça ne répond toujours pas à ma question : pourquoi c'est MAL de mettre un spamd sur le mx frontal (qu'il tourne en socket unix ou en socket tcp, sur le serveur de mail ou une autre machine n'entre pas en jeu dans la question) et que ce soit postfix ou exim4 ne change strictement rien au problème puisque les deux le permettent. Je n'y vois que des avantages (à part le temps machine). Je ne sais pas qui a dit que c'était mal, qu'il se dénonce et m'explique pourquoi.
Ce n'est pas une question de mettre le process spamd sur le serveur physique qui est frontal ou sur n'importe quel autre serveur. Le point est ou est-ce qu'on traite l'email avec l'anti-spam.
Si tu les traites par le smtpd, en cas d'attaque violente, tu vas te retrouver avec 120 process de spamd et un serveur par terre.
Si smtpd accepte tous les emails, les mets dans un spool, puis tu traites l'anti-spam avec un nombre connu de process, tu vas mettre du delai dans le traitement, mais ton service sera toujours debout.
Je prefere la seconde option a la premiere. Parce qu'il faut mieux gerer un delai sur un service qui tourne toujours qu'essayer de relever un serveur qui se tappe une charge de 120.
-- http://unices.over-blog.com/ Un Francais en Chine
Stephane TOUGARD
Yves Lambert a perdu son temps a nous dire:
Ceci dit, j'aimerai savoir quelle distribution linux lui suce la roue, à DC... je parie pour aucune.
Franchement la Debian a un systeme d'upgrade qui est tres adapte pour ca. Si il y en a une qui pourrait, c'est bien celle la.
Sinon, non aucune que je sache.
-- http://unices.over-blog.com/ Un Francais en Chine
Yves Lambert a perdu son temps a nous dire:
Ceci dit, j'aimerai savoir quelle distribution linux lui suce la roue, à
DC... je parie pour aucune.
Franchement la Debian a un systeme d'upgrade qui est tres adapte pour
ca. Si il y en a une qui pourrait, c'est bien celle la.
Sinon, non aucune que je sache.
--
http://unices.over-blog.com/ Un Francais en Chine
