Bonjour.
Je poste ici, because, je ne sais pas où posté ma question.
En ce moment, j'ai affaire avec des pseudos admin windows. Le genre de
mecs qui sont devenu admin parce qu'ils étaient doué aux clicks de souris
(la lèche a dû aussi compter pas mal). Ils ont des pérjugés sur Unix, Linux et
tous les autres OS. C'est assez flippant. Est ce que quelqu'un a une url
qui donne un récapitulatif des capacités de Linux. Les architectures
supportés, etc. Ca m'arrangerait, parce que que ce que je trouve avec
google.com/linux. C'est pas top...
Merci d'avance.
On Mon, 3 Nov 2003 09:02:25 +0000 (UTC), Michel Talon wrote:
Entre nous aussi, des "process quasi temps réels" sous Windows, ça doit être une espèce de process qui tient de la licorne ou du minautaure, vu les latences de l'OS.
Les latences de NT sont d'expérience moins ridicules que sous Linux 2.2 ou antérieur (n'importe qui ayant codé un émulateur pour un hardware quelconque sous Linux et sous NT pourra confirmer). Et les trucs comme HyperKernel ça marche très bien aussi.
Tu parles de threads en priorité maximale, je suppose. Parceque pour des programmes normaux sous Windows tout le monde peut voir le temps que ça met à se charger quand la machine commence déjà un peu à ramer. Et même pour des taches prioritaires, comparé à Linux muni du patch low-latency posera encore des problèmes à Windows. Là où Windows mettra 10ms, Linux mettra moins d'une milliseconde sur un processeur déjà bien ancien.
--
Michel TALON
Sam Hocevar <sam+news@zoy.org> wrote:
On Mon, 3 Nov 2003 09:02:25 +0000 (UTC), Michel Talon wrote:
Entre nous aussi, des "process quasi temps réels" sous Windows, ça doit
être une espèce de process qui tient de la licorne ou du minautaure, vu
les latences de l'OS.
Les latences de NT sont d'expérience moins ridicules que sous Linux
2.2 ou antérieur (n'importe qui ayant codé un émulateur pour un hardware
quelconque sous Linux et sous NT pourra confirmer). Et les trucs comme
HyperKernel ça marche très bien aussi.
Tu parles de threads en priorité maximale, je suppose. Parceque pour des
programmes normaux sous Windows tout le monde peut voir le temps que ça
met à se charger quand la machine commence déjà un peu à ramer. Et
même pour des taches prioritaires, comparé à Linux muni du patch
low-latency posera encore des problèmes à Windows. Là où Windows
mettra 10ms, Linux mettra moins d'une milliseconde sur un processeur déjà
bien ancien.
On Mon, 3 Nov 2003 09:02:25 +0000 (UTC), Michel Talon wrote:
Entre nous aussi, des "process quasi temps réels" sous Windows, ça doit être une espèce de process qui tient de la licorne ou du minautaure, vu les latences de l'OS.
Les latences de NT sont d'expérience moins ridicules que sous Linux 2.2 ou antérieur (n'importe qui ayant codé un émulateur pour un hardware quelconque sous Linux et sous NT pourra confirmer). Et les trucs comme HyperKernel ça marche très bien aussi.
Tu parles de threads en priorité maximale, je suppose. Parceque pour des programmes normaux sous Windows tout le monde peut voir le temps que ça met à se charger quand la machine commence déjà un peu à ramer. Et même pour des taches prioritaires, comparé à Linux muni du patch low-latency posera encore des problèmes à Windows. Là où Windows mettra 10ms, Linux mettra moins d'une milliseconde sur un processeur déjà bien ancien.
--
Michel TALON
Patrice Karatchentzeff
"Olivier Souiry" writes:
"Michel Talon" a écrit dans le message news: bo37n7$510$
Maintenant, il est vrai que les sytèmes Unix sont plus performants, ce qui fait une (grosse?) différence.
tiens, parlons donc de X Window...
La plus belle des réalisations faîtes sous UNIX... une merveille ce truc-là.
Très copiée en plus... presque 20 ans après.
Tiens, cela me rappelle quelque chose... comment ? le noyau UNIX est encore plus vieux que X... Impossible donc qu'aujourd'hui ils soient encore utilisés... surtout dans des machines destinées au neu² comme les Mac..
Misère... Tous ces vieux trucs plein de poussière qui marchent tellement mal qu'on invente à la place des trucs tout neuf qui marchent bien... comme Windows.
"Michel Talon" <talon@lpthe.jussieu.fr> a écrit dans le message news:
bo37n7$510$1@asmodee.lpthe.jussieu.fr...
Maintenant, il est vrai que les sytèmes Unix sont plus performants, ce
qui fait une (grosse?) différence.
tiens, parlons donc de X Window...
La plus belle des réalisations faîtes sous UNIX... une merveille ce
truc-là.
Très copiée en plus... presque 20 ans après.
Tiens, cela me rappelle quelque chose... comment ? le noyau UNIX est
encore plus vieux que X... Impossible donc qu'aujourd'hui ils soient
encore utilisés... surtout dans des machines destinées au neu² comme
les Mac..
Misère... Tous ces vieux trucs plein de poussière qui marchent
tellement mal qu'on invente à la place des trucs tout neuf qui
marchent bien... comme Windows.
"Michel Talon" a écrit dans le message news: bo37n7$510$
Maintenant, il est vrai que les sytèmes Unix sont plus performants, ce qui fait une (grosse?) différence.
tiens, parlons donc de X Window...
La plus belle des réalisations faîtes sous UNIX... une merveille ce truc-là.
Très copiée en plus... presque 20 ans après.
Tiens, cela me rappelle quelque chose... comment ? le noyau UNIX est encore plus vieux que X... Impossible donc qu'aujourd'hui ils soient encore utilisés... surtout dans des machines destinées au neu² comme les Mac..
Misère... Tous ces vieux trucs plein de poussière qui marchent tellement mal qu'on invente à la place des trucs tout neuf qui marchent bien... comme Windows.
Puis c'est vrai qu'avec plus de 16 processeurs, FreeBSD est the best of the world depuis sa version 2.2 STABLE.
Oui, d'ailleurs c'est tellement connu que la version 5 de FreeBee est la première à supporter plus de deux procs, il me semble.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
talon
Emmanuel Florac wrote:
Dans article , disait...
Puis c'est vrai qu'avec plus de 16 processeurs, FreeBSD est the best of the world depuis sa version 2.2 STABLE.
Oui, d'ailleurs c'est tellement connu que la version 5 de FreeBee est la première à supporter plus de deux procs, il me semble.
Bien sûr vous n'avez pas fini de déconner à plein tuyaux. FreeBSD a été développé d'abord et avant tout pour l'architecture x86, sur laquelle les multiprocs les plus courants sont des biprocs et on trouve trés exceptionnellement des quadriprocs. FreeBSD n'avait pas le support multiproc jusqu'à la release 3, la plupart des gens pensant que ça ne servait à rien, ce qui n'est pas totalement faux (reste à prouver qu'un biproc est plus intéressant économiquement que deux machines à un proc). Toujours est-il qu'à la version 3 a été introduit un système SMP équivalent à celui qu'il y avait dans Linux, c'est à dire permettant de faire marcher des biprocs raisonnablement bien, des quadriprocs à peu prés, et le reste on n'en parle pas. L'exemple pour des systèmes plus "évolués" était fourni par Solaris, vu que Sun a mis le paquet sur des machines avec beaucoup de procs, la puissance unitaire de son proc étant minable. Tout le monde a copié ce que faisait Sun, Linux plus vite que FreeBSD, vu le nombre respectif de développeurs, vu aussi que Linux était porté sur Sparc et pas FreeBSD. A l'heure actuelle FreeBSD a un système avec du "fine grained locking" dans FreeBSD-5, exactement comme Linux, mais probablement dans un état moins avancé de développement. Dans le cycle de la durée de vie de la série FreeBSD-5 le système sera probablement exactement équivalent à Linux-2.6.
Celà étant, cette stratégie, celle de Solaris, a été vivement critiquée dans les cercles de développeurs FreeBSD. Notamment le principal développeur de la VM, John Dyson considérait que c'était un mauvais choix, beaucoup trop complexe, et qui entraînerait des problèmes de maintenance aigus. Il a fini par quitter l'équipe. Celui qui l'a plus ou moins remplacé, Matt Dillon, s'est aussi empaillé avec ses collègues et s'est fait virer. Il a créé son propre projet, DragonFlyBSD, avec précisément pour but de développer un SMP efficace sans "fine grained locking". Seul le futur montrera si ça marche, et si ça marche mieux ou pas.
Dans l'état actuel des choses, on peut construire des clusters d'une puissance considérable, laissant à des années lumières tous les multiprocs de la création, simplement avec des biprocs du marché, utilisant des OS du marché n'ayant aucun de ces perfectionnements soit disant essentiels. Il n'y a qu'à voir le cluster de l'université de Virginie, constitué de 1100 biprocesseurs mac G5 tournant sous Mac OS X, et qui arrive aux environs de 10 Teraflops, c'est à dire à la deuxième ou troisième place mondiale, pour un cout total dérisoire par rapport aux machines spécialisées ( 5M$ ).
--
Michel TALON
Emmanuel Florac <eflorac@verisign.com> wrote:
Dans article <slrnbqcmcp.m89.stephane@titanic.kirch>, stephane@unices.org
disait...
Puis c'est vrai qu'avec plus de 16 processeurs, FreeBSD est the best of
the world depuis sa version 2.2 STABLE.
Oui, d'ailleurs c'est tellement connu que la version 5 de FreeBee est la
première à supporter plus de deux procs, il me semble.
Bien sûr vous n'avez pas fini de déconner à plein tuyaux. FreeBSD a été
développé d'abord et avant tout pour l'architecture x86, sur laquelle
les multiprocs les plus courants sont des biprocs et on trouve trés
exceptionnellement des quadriprocs. FreeBSD n'avait pas le support
multiproc jusqu'à la release 3, la plupart des gens pensant que ça ne
servait à rien, ce qui n'est pas totalement faux (reste à prouver qu'un
biproc est plus intéressant économiquement que deux machines à un proc).
Toujours est-il qu'à la version 3 a été introduit un système SMP
équivalent à celui qu'il y avait dans Linux, c'est à dire permettant de
faire marcher des biprocs raisonnablement bien, des quadriprocs à peu
prés, et le reste on n'en parle pas. L'exemple pour des systèmes plus
"évolués" était fourni par Solaris, vu que Sun a mis le paquet sur des
machines avec beaucoup de procs, la puissance unitaire de son proc étant
minable. Tout le monde a copié ce que faisait Sun, Linux plus vite que
FreeBSD, vu le nombre respectif de développeurs, vu aussi que Linux
était porté sur Sparc et pas FreeBSD. A l'heure actuelle FreeBSD
a un système avec du "fine grained locking" dans FreeBSD-5, exactement
comme Linux, mais probablement dans un état moins avancé de
développement. Dans le cycle de la durée de vie de la série FreeBSD-5
le système sera probablement exactement équivalent à Linux-2.6.
Celà étant, cette stratégie, celle de Solaris, a été vivement critiquée
dans les cercles de développeurs FreeBSD. Notamment le principal
développeur de la VM, John Dyson considérait que c'était un mauvais
choix, beaucoup trop complexe, et qui entraînerait des problèmes de
maintenance aigus. Il a fini par quitter l'équipe. Celui qui l'a
plus ou moins remplacé, Matt Dillon, s'est aussi empaillé avec ses
collègues et s'est fait virer. Il a créé son propre projet,
DragonFlyBSD, avec précisément pour but de développer un SMP
efficace sans "fine grained locking". Seul le futur montrera si ça
marche, et si ça marche mieux ou pas.
Dans l'état actuel des choses, on peut construire des clusters d'une
puissance considérable, laissant à des années lumières tous les
multiprocs de la création, simplement avec des biprocs du marché,
utilisant des OS du marché n'ayant aucun de ces perfectionnements soit
disant essentiels. Il n'y a qu'à voir le cluster de l'université
de Virginie, constitué de 1100 biprocesseurs mac G5 tournant sous
Mac OS X, et qui arrive aux environs de 10 Teraflops, c'est à dire à
la deuxième ou troisième place mondiale, pour un cout total
dérisoire par rapport aux machines spécialisées ( 5M$ ).
Puis c'est vrai qu'avec plus de 16 processeurs, FreeBSD est the best of the world depuis sa version 2.2 STABLE.
Oui, d'ailleurs c'est tellement connu que la version 5 de FreeBee est la première à supporter plus de deux procs, il me semble.
Bien sûr vous n'avez pas fini de déconner à plein tuyaux. FreeBSD a été développé d'abord et avant tout pour l'architecture x86, sur laquelle les multiprocs les plus courants sont des biprocs et on trouve trés exceptionnellement des quadriprocs. FreeBSD n'avait pas le support multiproc jusqu'à la release 3, la plupart des gens pensant que ça ne servait à rien, ce qui n'est pas totalement faux (reste à prouver qu'un biproc est plus intéressant économiquement que deux machines à un proc). Toujours est-il qu'à la version 3 a été introduit un système SMP équivalent à celui qu'il y avait dans Linux, c'est à dire permettant de faire marcher des biprocs raisonnablement bien, des quadriprocs à peu prés, et le reste on n'en parle pas. L'exemple pour des systèmes plus "évolués" était fourni par Solaris, vu que Sun a mis le paquet sur des machines avec beaucoup de procs, la puissance unitaire de son proc étant minable. Tout le monde a copié ce que faisait Sun, Linux plus vite que FreeBSD, vu le nombre respectif de développeurs, vu aussi que Linux était porté sur Sparc et pas FreeBSD. A l'heure actuelle FreeBSD a un système avec du "fine grained locking" dans FreeBSD-5, exactement comme Linux, mais probablement dans un état moins avancé de développement. Dans le cycle de la durée de vie de la série FreeBSD-5 le système sera probablement exactement équivalent à Linux-2.6.
Celà étant, cette stratégie, celle de Solaris, a été vivement critiquée dans les cercles de développeurs FreeBSD. Notamment le principal développeur de la VM, John Dyson considérait que c'était un mauvais choix, beaucoup trop complexe, et qui entraînerait des problèmes de maintenance aigus. Il a fini par quitter l'équipe. Celui qui l'a plus ou moins remplacé, Matt Dillon, s'est aussi empaillé avec ses collègues et s'est fait virer. Il a créé son propre projet, DragonFlyBSD, avec précisément pour but de développer un SMP efficace sans "fine grained locking". Seul le futur montrera si ça marche, et si ça marche mieux ou pas.
Dans l'état actuel des choses, on peut construire des clusters d'une puissance considérable, laissant à des années lumières tous les multiprocs de la création, simplement avec des biprocs du marché, utilisant des OS du marché n'ayant aucun de ces perfectionnements soit disant essentiels. Il n'y a qu'à voir le cluster de l'université de Virginie, constitué de 1100 biprocesseurs mac G5 tournant sous Mac OS X, et qui arrive aux environs de 10 Teraflops, c'est à dire à la deuxième ou troisième place mondiale, pour un cout total dérisoire par rapport aux machines spécialisées ( 5M$ ).
--
Michel TALON
Richard Delorme
Richard Delorme wrote:
La littérature sur la gestion de la mémoire par Linux est quand même abondante. Il était notoire que Linux marchait mal sur les systèmes multiprocesseurs (> 16 CPU) qui faisaient tourner des milliers de processus, car il passait tout son temps dans le gestionnaire de VM, les I/O,... Désormais, ce problème semble résolu avec le noyau 2.6. Cf par exemple : http://dsoulayrol.free.fr/articles/wonderful_2.6.html, pour voir les améliorations aportés par le noyau 2.6
Puis c'est vrai qu'avec plus de 16 processeurs, FreeBSD est the best of the world depuis sa version 2.2 STABLE. C'est bien connu. Franchement les gars, si vos griefs contre la VM de Linux se situent a ce niveau, je suis plus mort de rire qu'inquiet tant il est vrai qu'on est sur le creneau de Solaris ou de HP-UX plutot que celui de FreeBSD (et je ne parle meme pas des autres BSD qui ne depassent meme pas le mono-proc).
Il est clair que le noyau 2.6 permet à Linux d'entrer en concurrence avec les Unix-pro comme Solaris ou HP-UX. Néanmoins, pour l'utilisateur lambda comme moi qui ne dispose (plus) que de machines pas cher et monoprocesseurs, cela a aussi des avantages. Voilà ce que dit Linus Torvalds a ce propos¹ : « I used to think that it made no sense to try to support huge machines in the same source tree as regular machines. I used to think that big iron issues are so different from regular hardware that it's better to have a fork and have some special code for machines with 256 CPUs or something like that. The thing is, the SMP scalability has helped even the UPKs just by cleaning stuff up and having to be a lot more careful about how you do things. And we've been able to keep all the overheads down. » L'amélioration du code pour le support des grosses machines a rejailli positivement pour la machine simplette de Monsieur tout-le-monde. Cela veut dire une machine toujours fluide, même par forte charge, et donc d'utilisation plus agréable.
La littérature sur la gestion de la mémoire par Linux est quand même
abondante. Il était notoire que Linux marchait mal sur les systèmes
multiprocesseurs (> 16 CPU) qui faisaient tourner des milliers de
processus, car il passait tout son temps dans le gestionnaire de VM, les
I/O,... Désormais, ce problème semble résolu avec le noyau 2.6. Cf par
exemple : http://dsoulayrol.free.fr/articles/wonderful_2.6.html, pour
voir les améliorations aportés par le noyau 2.6
Puis c'est vrai qu'avec plus de 16 processeurs, FreeBSD est the best of
the world depuis sa version 2.2 STABLE. C'est bien connu. Franchement
les gars, si vos griefs contre la VM de Linux se situent a ce niveau, je
suis plus mort de rire qu'inquiet tant il est vrai qu'on est sur le
creneau de Solaris ou de HP-UX plutot que celui de FreeBSD (et je ne
parle meme pas des autres BSD qui ne depassent meme pas le mono-proc).
Il est clair que le noyau 2.6 permet à Linux d'entrer en concurrence avec
les Unix-pro comme Solaris ou HP-UX. Néanmoins, pour l'utilisateur lambda
comme moi qui ne dispose (plus) que de machines pas cher et
monoprocesseurs, cela a aussi des avantages. Voilà ce que dit Linus
Torvalds a ce propos¹ :
« I used to think that it made no sense to try to support huge machines in
the same source tree as regular machines. I used to think that big iron
issues are so different from regular hardware that it's better to have a
fork and have some special code for machines with 256 CPUs or something
like that. The thing is, the SMP scalability has helped even the UPKs just
by cleaning stuff up and having to be a lot more careful about how you do
things. And we've been able to keep all the overheads down. »
L'amélioration du code pour le support des grosses machines a rejailli
positivement pour la machine simplette de Monsieur tout-le-monde. Cela veut
dire une machine toujours fluide, même par forte charge, et donc
d'utilisation plus agréable.
La littérature sur la gestion de la mémoire par Linux est quand même abondante. Il était notoire que Linux marchait mal sur les systèmes multiprocesseurs (> 16 CPU) qui faisaient tourner des milliers de processus, car il passait tout son temps dans le gestionnaire de VM, les I/O,... Désormais, ce problème semble résolu avec le noyau 2.6. Cf par exemple : http://dsoulayrol.free.fr/articles/wonderful_2.6.html, pour voir les améliorations aportés par le noyau 2.6
Puis c'est vrai qu'avec plus de 16 processeurs, FreeBSD est the best of the world depuis sa version 2.2 STABLE. C'est bien connu. Franchement les gars, si vos griefs contre la VM de Linux se situent a ce niveau, je suis plus mort de rire qu'inquiet tant il est vrai qu'on est sur le creneau de Solaris ou de HP-UX plutot que celui de FreeBSD (et je ne parle meme pas des autres BSD qui ne depassent meme pas le mono-proc).
Il est clair que le noyau 2.6 permet à Linux d'entrer en concurrence avec les Unix-pro comme Solaris ou HP-UX. Néanmoins, pour l'utilisateur lambda comme moi qui ne dispose (plus) que de machines pas cher et monoprocesseurs, cela a aussi des avantages. Voilà ce que dit Linus Torvalds a ce propos¹ : « I used to think that it made no sense to try to support huge machines in the same source tree as regular machines. I used to think that big iron issues are so different from regular hardware that it's better to have a fork and have some special code for machines with 256 CPUs or something like that. The thing is, the SMP scalability has helped even the UPKs just by cleaning stuff up and having to be a lot more careful about how you do things. And we've been able to keep all the overheads down. » L'amélioration du code pour le support des grosses machines a rejailli positivement pour la machine simplette de Monsieur tout-le-monde. Cela veut dire une machine toujours fluide, même par forte charge, et donc d'utilisation plus agréable.
puisse profiter pleinement de leur matériel avec autant de facilité qu'ils ont à allumer leur téléviseur pour regarder Star Academy. Pour le moment, ^^^^^^^^^^^^
windows est plus près de cette vision de l'informatique que linux. ^^^^^^^
Mais ça, on le savait déja.
-- David Lightman: Is this a game or is it real? Joshua: What's the difference? David Lightman: Oh, wow.
Le 01-11-2003, Thaeel <macpotato@free.fr> a écrit :
puisse profiter pleinement de leur matériel avec autant de facilité qu'ils
ont à allumer leur téléviseur pour regarder Star Academy. Pour le moment,
^^^^^^^^^^^^
windows est plus près de cette vision de l'informatique que linux.
^^^^^^^
Mais ça, on le savait déja.
--
David Lightman: Is this a game or is it real?
Joshua: What's the difference?
David Lightman: Oh, wow.
puisse profiter pleinement de leur matériel avec autant de facilité qu'ils ont à allumer leur téléviseur pour regarder Star Academy. Pour le moment, ^^^^^^^^^^^^
windows est plus près de cette vision de l'informatique que linux. ^^^^^^^
Mais ça, on le savait déja.
-- David Lightman: Is this a game or is it real? Joshua: What's the difference? David Lightman: Oh, wow.
Miod Vallat
C'est ça, personne n'a jamais constaté que la VM sous Linux 2.4 était un peu capricieuse!
1) ca a ete corrige depuis fort longtemps, ton troll frise le mensonge. 2) meme si cela n'etait pas le cas, les noyaux 2.0 et 2.2 sont d'excellents systemes. 3) au moins, sous Linux, la VM on sait comment elle marche.
Ne trouves-tu pas que cette dernière affirmation décrédibilise totalement ton propos ?
C'est ça, personne n'a jamais constaté que la VM sous Linux 2.4
était un peu capricieuse!
1) ca a ete corrige depuis fort longtemps, ton troll frise le mensonge.
2) meme si cela n'etait pas le cas, les noyaux 2.0 et 2.2 sont
d'excellents systemes.
3) au moins, sous Linux, la VM on sait comment elle marche.
Ne trouves-tu pas que cette dernière affirmation décrédibilise
totalement ton propos ?
C'est ça, personne n'a jamais constaté que la VM sous Linux 2.4 était un peu capricieuse!
1) ca a ete corrige depuis fort longtemps, ton troll frise le mensonge. 2) meme si cela n'etait pas le cas, les noyaux 2.0 et 2.2 sont d'excellents systemes. 3) au moins, sous Linux, la VM on sait comment elle marche.
Ne trouves-tu pas que cette dernière affirmation décrédibilise totalement ton propos ?
azathoth
In article (Dans l'article) , Sebastien Tanguy <seb+ wrote (écrivait) :
J'ai dit avoir eu des NT (sous entendu du 4.0) avec un à deux ans d'uptime. Comme ceux-ci étaient dans un environnement particulier, il n'y avait pas besoin de les patcher spécialement hormis les besoins spécifiques à la prod et à aux éléments validés.
Trop gros, passera pas. Même chez microsoft quand ils ont eu 3 mois d'uptime avec windows 2003, ils l'ont publié sur leur site tellement ca leur semblait fabuleux.
Je n'ai pas eu de windows 2000 suffisement sous la main récemment pour donner des chiffres exacts. Mais j'avoue que ça doit être désagréable pour toi d'entendre que la vraie vie, des gens arrivent à faire fonctionner des machines windows 2000 mieux que tu ne le ferais avec tes propres Linux.
Le problème de windows ce n'est pas trop que tu ne peux pas faire, c'est la façon dont tu dois le faire. La plupart des trucs tiennent de la magie noire ou de la bidouille monstrueuse. Le dernier exemple en date que j'ai est un windows XP qui refusait absolument de rentrer dans un domaine NT si une entrée du Lmhost n'avait pas exactement 20 caractères (il a fallu rajouter des espaces pour que cela cole) alors que ce n'est pas le cas pour le reste. Tu peux m'expliquer la raison logique de ce truc ?
Et je ne suis pas seul à en souffrir, j'ai pu le remarquer sur les appels aux hotlines : lors des appels concernant des systèmes Unix, la hotline voit très vite d'ou vient à peu près le problème ou une manière de le contourner.
Par contre quand ca concerne un système microsoft, bizarrement ca prend souvent des jours entiers avant de trouver d'ou peut venir le problème.
In article (Dans l'article)
<87sml5ttm3.fsf@meryllon.death-gate.fr.eu.org>, Sebastien Tanguy
<seb+news200309@death-gate.fr.eu.org> wrote (écrivait) :
J'ai dit avoir eu des NT (sous entendu du 4.0) avec un à deux ans
d'uptime. Comme ceux-ci étaient dans un environnement particulier, il
n'y avait pas besoin de les patcher spécialement hormis les besoins
spécifiques à la prod et à aux éléments validés.
Trop gros, passera pas. Même chez microsoft quand ils ont eu 3 mois
d'uptime avec windows 2003, ils l'ont publié sur leur site tellement ca
leur semblait fabuleux.
Je n'ai pas eu de windows 2000 suffisement sous la main récemment pour
donner des chiffres exacts. Mais j'avoue que ça doit être désagréable
pour toi d'entendre que la vraie vie, des gens arrivent à faire
fonctionner des machines windows 2000 mieux que tu ne le ferais avec
tes propres Linux.
Le problème de windows ce n'est pas trop que tu ne peux pas faire,
c'est la façon dont tu dois le faire. La plupart des trucs tiennent de
la magie noire ou de la bidouille monstrueuse. Le dernier exemple en
date que j'ai est un windows XP qui refusait absolument de rentrer dans
un domaine NT si une entrée du Lmhost n'avait pas exactement 20
caractères (il a fallu rajouter des espaces pour que cela cole) alors
que ce n'est pas le cas pour le reste. Tu peux m'expliquer la raison
logique de ce truc ?
Et je ne suis pas seul à en souffrir, j'ai pu le remarquer sur les
appels aux hotlines : lors des appels concernant des systèmes Unix, la
hotline voit très vite d'ou vient à peu près le problème ou une manière
de le contourner.
Par contre quand ca concerne un système microsoft, bizarrement ca prend
souvent des jours entiers avant de trouver d'ou peut venir le problème.
In article (Dans l'article) , Sebastien Tanguy <seb+ wrote (écrivait) :
J'ai dit avoir eu des NT (sous entendu du 4.0) avec un à deux ans d'uptime. Comme ceux-ci étaient dans un environnement particulier, il n'y avait pas besoin de les patcher spécialement hormis les besoins spécifiques à la prod et à aux éléments validés.
Trop gros, passera pas. Même chez microsoft quand ils ont eu 3 mois d'uptime avec windows 2003, ils l'ont publié sur leur site tellement ca leur semblait fabuleux.
Je n'ai pas eu de windows 2000 suffisement sous la main récemment pour donner des chiffres exacts. Mais j'avoue que ça doit être désagréable pour toi d'entendre que la vraie vie, des gens arrivent à faire fonctionner des machines windows 2000 mieux que tu ne le ferais avec tes propres Linux.
Le problème de windows ce n'est pas trop que tu ne peux pas faire, c'est la façon dont tu dois le faire. La plupart des trucs tiennent de la magie noire ou de la bidouille monstrueuse. Le dernier exemple en date que j'ai est un windows XP qui refusait absolument de rentrer dans un domaine NT si une entrée du Lmhost n'avait pas exactement 20 caractères (il a fallu rajouter des espaces pour que cela cole) alors que ce n'est pas le cas pour le reste. Tu peux m'expliquer la raison logique de ce truc ?
Et je ne suis pas seul à en souffrir, j'ai pu le remarquer sur les appels aux hotlines : lors des appels concernant des systèmes Unix, la hotline voit très vite d'ou vient à peu près le problème ou une manière de le contourner.
Par contre quand ca concerne un système microsoft, bizarrement ca prend souvent des jours entiers avant de trouver d'ou peut venir le problème.
Emmanuel Florac
Dans article <bo7rv2$18eb$, disait...
Dans l'état actuel des choses, on peut construire des clusters d'une puissance considérable, laissant à des années lumières tous les multiprocs de la création, simplement avec des biprocs du marché,
Mais oui, papy, allez, prend ta pilule :) Non, on ne peut pas tout faire avec des clusters. Et on peut mettre les supercalculateurs en clusters aussi bien que des PC à trois francs.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <bo7rv2$18eb$1@asmodee.lpthe.jussieu.fr>,
talon@lpthe.jussieu.fr disait...
Dans l'état actuel des choses, on peut construire des clusters d'une
puissance considérable, laissant à des années lumières tous les
multiprocs de la création, simplement avec des biprocs du marché,
Mais oui, papy, allez, prend ta pilule :) Non, on ne peut pas tout faire
avec des clusters. Et on peut mettre les supercalculateurs en clusters
aussi bien que des PC à trois francs.
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans l'état actuel des choses, on peut construire des clusters d'une puissance considérable, laissant à des années lumières tous les multiprocs de la création, simplement avec des biprocs du marché,
Mais oui, papy, allez, prend ta pilule :) Non, on ne peut pas tout faire avec des clusters. Et on peut mettre les supercalculateurs en clusters aussi bien que des PC à trois francs.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Vincent Bernat
OoO En cette nuit nuageuse du mardi 04 novembre 2003, vers 01:36, (Michel Talon) disait:
Dans l'état actuel des choses, on peut construire des clusters d'une puissance considérable, laissant à des années lumières tous les multiprocs de la création, simplement avec des biprocs du marché, utilisant des OS du marché n'ayant aucun de ces perfectionnements soit disant essentiels. Il n'y a qu'à voir le cluster de l'université de Virginie, constitué de 1100 biprocesseurs mac G5 tournant sous Mac OS X, et qui arrive aux environs de 10 Teraflops, c'est à dire à la deuxième ou troisième place mondiale, pour un cout total dérisoire par rapport aux machines spécialisées ( 5M$ ).
Encore faut-il que les calculs demandés soient distribuables entre les différents élèments du cluster et que ceux-ci ne doivent pas communiquer trop entre eux. -- panic("Detected a card I can't drive - whoopsn"); 2.2.16 /usr/src/linux/drivers/net/daynaport.c
OoO En cette nuit nuageuse du mardi 04 novembre 2003, vers 01:36,
talon@lpthe.jussieu.fr (Michel Talon) disait:
Dans l'état actuel des choses, on peut construire des clusters d'une
puissance considérable, laissant à des années lumières tous les
multiprocs de la création, simplement avec des biprocs du marché,
utilisant des OS du marché n'ayant aucun de ces perfectionnements soit
disant essentiels. Il n'y a qu'à voir le cluster de l'université
de Virginie, constitué de 1100 biprocesseurs mac G5 tournant sous
Mac OS X, et qui arrive aux environs de 10 Teraflops, c'est à dire à
la deuxième ou troisième place mondiale, pour un cout total
dérisoire par rapport aux machines spécialisées ( 5M$ ).
Encore faut-il que les calculs demandés soient distribuables entre les
différents élèments du cluster et que ceux-ci ne doivent pas
communiquer trop entre eux.
--
panic("Detected a card I can't drive - whoopsn");
2.2.16 /usr/src/linux/drivers/net/daynaport.c
OoO En cette nuit nuageuse du mardi 04 novembre 2003, vers 01:36, (Michel Talon) disait:
Dans l'état actuel des choses, on peut construire des clusters d'une puissance considérable, laissant à des années lumières tous les multiprocs de la création, simplement avec des biprocs du marché, utilisant des OS du marché n'ayant aucun de ces perfectionnements soit disant essentiels. Il n'y a qu'à voir le cluster de l'université de Virginie, constitué de 1100 biprocesseurs mac G5 tournant sous Mac OS X, et qui arrive aux environs de 10 Teraflops, c'est à dire à la deuxième ou troisième place mondiale, pour un cout total dérisoire par rapport aux machines spécialisées ( 5M$ ).
Encore faut-il que les calculs demandés soient distribuables entre les différents élèments du cluster et que ceux-ci ne doivent pas communiquer trop entre eux. -- panic("Detected a card I can't drive - whoopsn"); 2.2.16 /usr/src/linux/drivers/net/daynaport.c
