JKB a couché sur son écran :Le Wed, 28 Sep 2011 08:15:31 +0200,
NiKo écrivait :Le 27/09/2011 20:27, JKB a écrit :Le Tue, 27 Sep 2011 06:59:00 -0700 (PDT),
Toxico Nimbus écrivait :Le lundi 26 septembre 2011 22:15:40 UTC+2, P4nd1-P4nd4 a écrit :Toujous dans les choux
Et ?.. Tu as peur qu'ils perdent des sous ?Imaginez si c'était la dédense américaine ;>)
En quoi la défense américaine est-elle une référence ? Ils font du LL
là-bas ?
Disons qu'en virant VMS 6.3 pour NT4, ils ont déjà eu des
porte-avions qui ont fait des ronds dans le Pacifique durant
quelques jours... C'est donc une référence.
JKB
Microsoft aurait dû se réjouir d'avoir enfin une version de Windows qui
tournait correctement !
C'est vrai que vu comme ça...
"sources", "Preuves" ???
JKB a couché sur son écran :
Le Wed, 28 Sep 2011 08:15:31 +0200,
NiKo <NiKo@nomail.svp> écrivait :
Le 27/09/2011 20:27, JKB a écrit :
Le Tue, 27 Sep 2011 06:59:00 -0700 (PDT),
Toxico Nimbus <tox.nimbus@gmail.com> écrivait :
Le lundi 26 septembre 2011 22:15:40 UTC+2, P4nd1-P4nd4 a écrit :
Toujous dans les choux
Et ?.. Tu as peur qu'ils perdent des sous ?
Imaginez si c'était la dédense américaine ;>)
En quoi la défense américaine est-elle une référence ? Ils font du LL
là-bas ?
Disons qu'en virant VMS 6.3 pour NT4, ils ont déjà eu des
porte-avions qui ont fait des ronds dans le Pacifique durant
quelques jours... C'est donc une référence.
JKB
Microsoft aurait dû se réjouir d'avoir enfin une version de Windows qui
tournait correctement !
C'est vrai que vu comme ça...
"sources", "Preuves" ???
JKB a couché sur son écran :Le Wed, 28 Sep 2011 08:15:31 +0200,
NiKo écrivait :Le 27/09/2011 20:27, JKB a écrit :Le Tue, 27 Sep 2011 06:59:00 -0700 (PDT),
Toxico Nimbus écrivait :Le lundi 26 septembre 2011 22:15:40 UTC+2, P4nd1-P4nd4 a écrit :Toujous dans les choux
Et ?.. Tu as peur qu'ils perdent des sous ?Imaginez si c'était la dédense américaine ;>)
En quoi la défense américaine est-elle une référence ? Ils font du LL
là-bas ?
Disons qu'en virant VMS 6.3 pour NT4, ils ont déjà eu des
porte-avions qui ont fait des ronds dans le Pacifique durant
quelques jours... C'est donc une référence.
JKB
Microsoft aurait dû se réjouir d'avoir enfin une version de Windows qui
tournait correctement !
C'est vrai que vu comme ça...
"sources", "Preuves" ???
JKB a exposé le 28.09.2011 :Le Wed, 28 Sep 2011 12:25:42 +0200,
Damien Wyart écrivait :* JKB in fr.comp.os.linux.debats:Et toi, tu es juste con. Recherche un peu "USS Yorktown"
http://fr.wikipedia.org/wiki/USS_Yorktown_(CV-5)
[/SNIP/]
AHAHAHAHAHAHAH
?NT was never the cause of any problem on the ship,? Rushton said. ?The
problems were all in programs, database and code within the individual
pieces of software
that we were using.?
JKB a exposé le 28.09.2011 :
Le Wed, 28 Sep 2011 12:25:42 +0200,
Damien Wyart <damien.wyart@free.fr> écrivait :
* JKB <jkb@koenigsberg.invalid> in fr.comp.os.linux.debats:
Et toi, tu es juste con. Recherche un peu "USS Yorktown"
http://fr.wikipedia.org/wiki/USS_Yorktown_(CV-5)
[/SNIP/]
AHAHAHAHAHAHAH
?NT was never the cause of any problem on the ship,? Rushton said. ?The
problems were all in programs, database and code within the individual
pieces of software
that we were using.?
JKB a exposé le 28.09.2011 :Le Wed, 28 Sep 2011 12:25:42 +0200,
Damien Wyart écrivait :* JKB in fr.comp.os.linux.debats:Et toi, tu es juste con. Recherche un peu "USS Yorktown"
http://fr.wikipedia.org/wiki/USS_Yorktown_(CV-5)
[/SNIP/]
AHAHAHAHAHAHAH
?NT was never the cause of any problem on the ship,? Rushton said. ?The
problems were all in programs, database and code within the individual
pieces of software
that we were using.?
Bref si tu connaissais l'informatique, tu aurais appris que cela n'a
aucun rapport avec le système d'exploitation,
Bref si tu connaissais l'informatique, tu aurais appris que cela n'a
aucun rapport avec le système d'exploitation,
Bref si tu connaissais l'informatique, tu aurais appris que cela n'a
aucun rapport avec le système d'exploitation,
On 09/28/2011 01:45 PM, P4nd1-P4nd4 wrote:Le système n'a tout simplement pas été suffisemment testé...
Ça, on le sait depuis longtemps...
On 09/28/2011 01:45 PM, P4nd1-P4nd4 wrote:
Le système n'a tout simplement pas été suffisemment testé...
Ça, on le sait depuis longtemps...
On 09/28/2011 01:45 PM, P4nd1-P4nd4 wrote:Le système n'a tout simplement pas été suffisemment testé...
Ça, on le sait depuis longtemps...
Le Wed, 28 Sep 2011 17:00:19 +0200,
Toxico Nimbus écrivait :JKB wrote:Le système n'a tout simplement pas été suffisemment testé...
Le différence, c'est que l'OS utilisé avant cette belle installation
était capable de résister à une disivion par zéro liée à un buffer
overflow (et pour cause, sous VMS, il y a des descripteurs de
chaîne). Sous Unix, le même problème aurait pu survenir en utilisant
les fonctions de la libc, mais ça _n'aurait pas planté tous les
systèmes_ !
Sauf que d'après larticle de gcn.com cité par Damien, ce n'est pas un
système mais plusieurs en réseau qui sont plantés, et d'autre part la fin
de l'article explique que les mécanismes de protection étaient
volontairement désactivés après étude des risques.
Où ai-je dis le contraire ?
Le Wed, 28 Sep 2011 17:00:19 +0200,
Toxico Nimbus <ToxN@free.fr> écrivait :
JKB wrote:
Le système n'a tout simplement pas été suffisemment testé...
Le différence, c'est que l'OS utilisé avant cette belle installation
était capable de résister à une disivion par zéro liée à un buffer
overflow (et pour cause, sous VMS, il y a des descripteurs de
chaîne). Sous Unix, le même problème aurait pu survenir en utilisant
les fonctions de la libc, mais ça _n'aurait pas planté tous les
systèmes_ !
Sauf que d'après larticle de gcn.com cité par Damien, ce n'est pas un
système mais plusieurs en réseau qui sont plantés, et d'autre part la fin
de l'article explique que les mécanismes de protection étaient
volontairement désactivés après étude des risques.
Où ai-je dis le contraire ?
Le Wed, 28 Sep 2011 17:00:19 +0200,
Toxico Nimbus écrivait :JKB wrote:Le système n'a tout simplement pas été suffisemment testé...
Le différence, c'est que l'OS utilisé avant cette belle installation
était capable de résister à une disivion par zéro liée à un buffer
overflow (et pour cause, sous VMS, il y a des descripteurs de
chaîne). Sous Unix, le même problème aurait pu survenir en utilisant
les fonctions de la libc, mais ça _n'aurait pas planté tous les
systèmes_ !
Sauf que d'après larticle de gcn.com cité par Damien, ce n'est pas un
système mais plusieurs en réseau qui sont plantés, et d'autre part la fin
de l'article explique que les mécanismes de protection étaient
volontairement désactivés après étude des risques.
Où ai-je dis le contraire ?
JKB wrote:Le Wed, 28 Sep 2011 17:00:19 +0200,
Toxico Nimbus écrivait :JKB wrote:Le système n'a tout simplement pas été suffisemment testé...
Le différence, c'est que l'OS utilisé avant cette belle installation
était capable de résister à une disivion par zéro liée à un buffer
overflow (et pour cause, sous VMS, il y a des descripteurs de
chaîne). Sous Unix, le même problème aurait pu survenir en utilisant
les fonctions de la libc, mais ça _n'aurait pas planté tous les
systèmes_ !
Sauf que d'après larticle de gcn.com cité par Damien, ce n'est pas un
système mais plusieurs en réseau qui sont plantés, et d'autre part la fin
de l'article explique que les mécanismes de protection étaient
volontairement désactivés après étude des risques.
Où ai-je dis le contraire ?
Je ne prétends pas que tu ai dit le contraire, mais simplement la diffusion
de l'"exception" sur le réseau et la désactivation des mécanismes de
protection montrent que le problème n'est pas au niveau de l'OS et que la
même appli sous VMS n'aurait pas mieux marché. On en serait sans doute resté
à relancer l'appli au lieu de rebooter tout le système, mais la propulsion
n'en aurait pas été plus éfficiente.
JKB wrote:
Le Wed, 28 Sep 2011 17:00:19 +0200,
Toxico Nimbus <ToxN@free.fr> écrivait :
JKB wrote:
Le système n'a tout simplement pas été suffisemment testé...
Le différence, c'est que l'OS utilisé avant cette belle installation
était capable de résister à une disivion par zéro liée à un buffer
overflow (et pour cause, sous VMS, il y a des descripteurs de
chaîne). Sous Unix, le même problème aurait pu survenir en utilisant
les fonctions de la libc, mais ça _n'aurait pas planté tous les
systèmes_ !
Sauf que d'après larticle de gcn.com cité par Damien, ce n'est pas un
système mais plusieurs en réseau qui sont plantés, et d'autre part la fin
de l'article explique que les mécanismes de protection étaient
volontairement désactivés après étude des risques.
Où ai-je dis le contraire ?
Je ne prétends pas que tu ai dit le contraire, mais simplement la diffusion
de l'"exception" sur le réseau et la désactivation des mécanismes de
protection montrent que le problème n'est pas au niveau de l'OS et que la
même appli sous VMS n'aurait pas mieux marché. On en serait sans doute resté
à relancer l'appli au lieu de rebooter tout le système, mais la propulsion
n'en aurait pas été plus éfficiente.
JKB wrote:Le Wed, 28 Sep 2011 17:00:19 +0200,
Toxico Nimbus écrivait :JKB wrote:Le système n'a tout simplement pas été suffisemment testé...
Le différence, c'est que l'OS utilisé avant cette belle installation
était capable de résister à une disivion par zéro liée à un buffer
overflow (et pour cause, sous VMS, il y a des descripteurs de
chaîne). Sous Unix, le même problème aurait pu survenir en utilisant
les fonctions de la libc, mais ça _n'aurait pas planté tous les
systèmes_ !
Sauf que d'après larticle de gcn.com cité par Damien, ce n'est pas un
système mais plusieurs en réseau qui sont plantés, et d'autre part la fin
de l'article explique que les mécanismes de protection étaient
volontairement désactivés après étude des risques.
Où ai-je dis le contraire ?
Je ne prétends pas que tu ai dit le contraire, mais simplement la diffusion
de l'"exception" sur le réseau et la désactivation des mécanismes de
protection montrent que le problème n'est pas au niveau de l'OS et que la
même appli sous VMS n'aurait pas mieux marché. On en serait sans doute resté
à relancer l'appli au lieu de rebooter tout le système, mais la propulsion
n'en aurait pas été plus éfficiente.
Le Thu, 29 Sep 2011 10:44:33 +0200,
Toxico Nimbus écrivait :JKB wrote:Le Wed, 28 Sep 2011 17:00:19 +0200,
Toxico Nimbus écrivait :JKB wrote:Le système n'a tout simplement pas été suffisemment testé...
Le différence, c'est que l'OS utilisé avant cette belle installation
était capable de résister à une disivion par zéro liée à un buffer
overflow (et pour cause, sous VMS, il y a des descripteurs de
chaîne). Sous Unix, le même problème aurait pu survenir en utilisant
les fonctions de la libc, mais ça _n'aurait pas planté tous les
systèmes_ !
Sauf que d'après larticle de gcn.com cité par Damien, ce n'est pas un
système mais plusieurs en réseau qui sont plantés, et d'autre part la
fin de l'article explique que les mécanismes de protection étaient
volontairement désactivés après étude des risques.
Où ai-je dis le contraire ?
Je ne prétends pas que tu ai dit le contraire, mais simplement la
diffusion de l'"exception" sur le réseau et la désactivation des
mécanismes de protection montrent que le problème n'est pas au niveau de
l'OS et que la même appli sous VMS n'aurait pas mieux marché. On en
serait sans doute resté à relancer l'appli au lieu de rebooter tout le
système, mais la propulsion n'en aurait pas été plus éfficiente.
Si, elle aurait mieux fonctionné parce que les buffers (chaînes et
autres) sont associés à un descripteur sous VMS. Tu ne peux donc pas
dépasser sans te prendre un coup de pied au cul. Tu me diras que tu peux
toujours utiliser les str* de la libc comme un goret, mais non, même
pas, puisque les API de RDB (c'est de ça qu'on cause) s'attaquaient
au moins à l'époque au travers de la bibliothèque STR$. Je ne sais
pas ce qu'il en est aujourd'hui car je n'ai plus touché à RDB depuis
que ce joyau a été vendu à Oracle, mais comme elle n'est disponible
que sous VMS, je doute fort que cela ait changé.
Le Thu, 29 Sep 2011 10:44:33 +0200,
Toxico Nimbus <ToxN@free.fr> écrivait :
JKB wrote:
Le Wed, 28 Sep 2011 17:00:19 +0200,
Toxico Nimbus <ToxN@free.fr> écrivait :
JKB wrote:
Le système n'a tout simplement pas été suffisemment testé...
Le différence, c'est que l'OS utilisé avant cette belle installation
était capable de résister à une disivion par zéro liée à un buffer
overflow (et pour cause, sous VMS, il y a des descripteurs de
chaîne). Sous Unix, le même problème aurait pu survenir en utilisant
les fonctions de la libc, mais ça _n'aurait pas planté tous les
systèmes_ !
Sauf que d'après larticle de gcn.com cité par Damien, ce n'est pas un
système mais plusieurs en réseau qui sont plantés, et d'autre part la
fin de l'article explique que les mécanismes de protection étaient
volontairement désactivés après étude des risques.
Où ai-je dis le contraire ?
Je ne prétends pas que tu ai dit le contraire, mais simplement la
diffusion de l'"exception" sur le réseau et la désactivation des
mécanismes de protection montrent que le problème n'est pas au niveau de
l'OS et que la même appli sous VMS n'aurait pas mieux marché. On en
serait sans doute resté à relancer l'appli au lieu de rebooter tout le
système, mais la propulsion n'en aurait pas été plus éfficiente.
Si, elle aurait mieux fonctionné parce que les buffers (chaînes et
autres) sont associés à un descripteur sous VMS. Tu ne peux donc pas
dépasser sans te prendre un coup de pied au cul. Tu me diras que tu peux
toujours utiliser les str* de la libc comme un goret, mais non, même
pas, puisque les API de RDB (c'est de ça qu'on cause) s'attaquaient
au moins à l'époque au travers de la bibliothèque STR$. Je ne sais
pas ce qu'il en est aujourd'hui car je n'ai plus touché à RDB depuis
que ce joyau a été vendu à Oracle, mais comme elle n'est disponible
que sous VMS, je doute fort que cela ait changé.
Le Thu, 29 Sep 2011 10:44:33 +0200,
Toxico Nimbus écrivait :JKB wrote:Le Wed, 28 Sep 2011 17:00:19 +0200,
Toxico Nimbus écrivait :JKB wrote:Le système n'a tout simplement pas été suffisemment testé...
Le différence, c'est que l'OS utilisé avant cette belle installation
était capable de résister à une disivion par zéro liée à un buffer
overflow (et pour cause, sous VMS, il y a des descripteurs de
chaîne). Sous Unix, le même problème aurait pu survenir en utilisant
les fonctions de la libc, mais ça _n'aurait pas planté tous les
systèmes_ !
Sauf que d'après larticle de gcn.com cité par Damien, ce n'est pas un
système mais plusieurs en réseau qui sont plantés, et d'autre part la
fin de l'article explique que les mécanismes de protection étaient
volontairement désactivés après étude des risques.
Où ai-je dis le contraire ?
Je ne prétends pas que tu ai dit le contraire, mais simplement la
diffusion de l'"exception" sur le réseau et la désactivation des
mécanismes de protection montrent que le problème n'est pas au niveau de
l'OS et que la même appli sous VMS n'aurait pas mieux marché. On en
serait sans doute resté à relancer l'appli au lieu de rebooter tout le
système, mais la propulsion n'en aurait pas été plus éfficiente.
Si, elle aurait mieux fonctionné parce que les buffers (chaînes et
autres) sont associés à un descripteur sous VMS. Tu ne peux donc pas
dépasser sans te prendre un coup de pied au cul. Tu me diras que tu peux
toujours utiliser les str* de la libc comme un goret, mais non, même
pas, puisque les API de RDB (c'est de ça qu'on cause) s'attaquaient
au moins à l'époque au travers de la bibliothèque STR$. Je ne sais
pas ce qu'il en est aujourd'hui car je n'ai plus touché à RDB depuis
que ce joyau a été vendu à Oracle, mais comme elle n'est disponible
que sous VMS, je doute fort que cela ait changé.
JKB wrote:Le Thu, 29 Sep 2011 10:44:33 +0200,
Toxico Nimbus écrivait :JKB wrote:Le Wed, 28 Sep 2011 17:00:19 +0200,
Toxico Nimbus écrivait :JKB wrote:Le système n'a tout simplement pas été suffisemment testé...
Le différence, c'est que l'OS utilisé avant cette belle installation
était capable de résister à une disivion par zéro liée à un buffer
overflow (et pour cause, sous VMS, il y a des descripteurs de
chaîne). Sous Unix, le même problème aurait pu survenir en utilisant
les fonctions de la libc, mais ça _n'aurait pas planté tous les
systèmes_ !
Sauf que d'après larticle de gcn.com cité par Damien, ce n'est pas un
système mais plusieurs en réseau qui sont plantés, et d'autre part la
fin de l'article explique que les mécanismes de protection étaient
volontairement désactivés après étude des risques.
Où ai-je dis le contraire ?
Je ne prétends pas que tu ai dit le contraire, mais simplement la
diffusion de l'"exception" sur le réseau et la désactivation des
mécanismes de protection montrent que le problème n'est pas au niveau de
l'OS et que la même appli sous VMS n'aurait pas mieux marché. On en
serait sans doute resté à relancer l'appli au lieu de rebooter tout le
système, mais la propulsion n'en aurait pas été plus éfficiente.
Si, elle aurait mieux fonctionné parce que les buffers (chaînes et
autres) sont associés à un descripteur sous VMS. Tu ne peux donc pas
dépasser sans te prendre un coup de pied au cul. Tu me diras que tu peux
toujours utiliser les str* de la libc comme un goret, mais non, même
pas, puisque les API de RDB (c'est de ça qu'on cause) s'attaquaient
au moins à l'époque au travers de la bibliothèque STR$. Je ne sais
pas ce qu'il en est aujourd'hui car je n'ai plus touché à RDB depuis
que ce joyau a été vendu à Oracle, mais comme elle n'est disponible
que sous VMS, je doute fort que cela ait changé.
Oui mais quelque soit l'OS, si tu ne gères pas le "coup de pied au cul", ton
appli se gauffre lamentablement.
JKB wrote:
Le Thu, 29 Sep 2011 10:44:33 +0200,
Toxico Nimbus <ToxN@free.fr> écrivait :
JKB wrote:
Le Wed, 28 Sep 2011 17:00:19 +0200,
Toxico Nimbus <ToxN@free.fr> écrivait :
JKB wrote:
Le système n'a tout simplement pas été suffisemment testé...
Le différence, c'est que l'OS utilisé avant cette belle installation
était capable de résister à une disivion par zéro liée à un buffer
overflow (et pour cause, sous VMS, il y a des descripteurs de
chaîne). Sous Unix, le même problème aurait pu survenir en utilisant
les fonctions de la libc, mais ça _n'aurait pas planté tous les
systèmes_ !
Sauf que d'après larticle de gcn.com cité par Damien, ce n'est pas un
système mais plusieurs en réseau qui sont plantés, et d'autre part la
fin de l'article explique que les mécanismes de protection étaient
volontairement désactivés après étude des risques.
Où ai-je dis le contraire ?
Je ne prétends pas que tu ai dit le contraire, mais simplement la
diffusion de l'"exception" sur le réseau et la désactivation des
mécanismes de protection montrent que le problème n'est pas au niveau de
l'OS et que la même appli sous VMS n'aurait pas mieux marché. On en
serait sans doute resté à relancer l'appli au lieu de rebooter tout le
système, mais la propulsion n'en aurait pas été plus éfficiente.
Si, elle aurait mieux fonctionné parce que les buffers (chaînes et
autres) sont associés à un descripteur sous VMS. Tu ne peux donc pas
dépasser sans te prendre un coup de pied au cul. Tu me diras que tu peux
toujours utiliser les str* de la libc comme un goret, mais non, même
pas, puisque les API de RDB (c'est de ça qu'on cause) s'attaquaient
au moins à l'époque au travers de la bibliothèque STR$. Je ne sais
pas ce qu'il en est aujourd'hui car je n'ai plus touché à RDB depuis
que ce joyau a été vendu à Oracle, mais comme elle n'est disponible
que sous VMS, je doute fort que cela ait changé.
Oui mais quelque soit l'OS, si tu ne gères pas le "coup de pied au cul", ton
appli se gauffre lamentablement.
JKB wrote:Le Thu, 29 Sep 2011 10:44:33 +0200,
Toxico Nimbus écrivait :JKB wrote:Le Wed, 28 Sep 2011 17:00:19 +0200,
Toxico Nimbus écrivait :JKB wrote:Le système n'a tout simplement pas été suffisemment testé...
Le différence, c'est que l'OS utilisé avant cette belle installation
était capable de résister à une disivion par zéro liée à un buffer
overflow (et pour cause, sous VMS, il y a des descripteurs de
chaîne). Sous Unix, le même problème aurait pu survenir en utilisant
les fonctions de la libc, mais ça _n'aurait pas planté tous les
systèmes_ !
Sauf que d'après larticle de gcn.com cité par Damien, ce n'est pas un
système mais plusieurs en réseau qui sont plantés, et d'autre part la
fin de l'article explique que les mécanismes de protection étaient
volontairement désactivés après étude des risques.
Où ai-je dis le contraire ?
Je ne prétends pas que tu ai dit le contraire, mais simplement la
diffusion de l'"exception" sur le réseau et la désactivation des
mécanismes de protection montrent que le problème n'est pas au niveau de
l'OS et que la même appli sous VMS n'aurait pas mieux marché. On en
serait sans doute resté à relancer l'appli au lieu de rebooter tout le
système, mais la propulsion n'en aurait pas été plus éfficiente.
Si, elle aurait mieux fonctionné parce que les buffers (chaînes et
autres) sont associés à un descripteur sous VMS. Tu ne peux donc pas
dépasser sans te prendre un coup de pied au cul. Tu me diras que tu peux
toujours utiliser les str* de la libc comme un goret, mais non, même
pas, puisque les API de RDB (c'est de ça qu'on cause) s'attaquaient
au moins à l'époque au travers de la bibliothèque STR$. Je ne sais
pas ce qu'il en est aujourd'hui car je n'ai plus touché à RDB depuis
que ce joyau a été vendu à Oracle, mais comme elle n'est disponible
que sous VMS, je doute fort que cela ait changé.
Oui mais quelque soit l'OS, si tu ne gères pas le "coup de pied au cul", ton
appli se gauffre lamentablement.