- On parle technique lorsque çà arrange : Le débat autour du multi-tâche préemptif vs. coopératif. En pratique, tout le monde s'en foutait, çà ne faisait aucune différence pour l'utilisateur final.
Je ne connais pas très bien MacOS classique, mais le multitache préemptif est incomparablement plus fiable et performant pour de nombreux systèmes, en particulier ceux qui doivent être multi-utilisateurs ou bien encore les serveurs. Et même pour ma machine de particulier, je ne voudrais pas d'un système coopératif!
Voir par exemple http://fr.wikipedia.org/wiki/Multitâches
Mais les supporters de Redmond insistaient sur la prétendue supériorité du choix de leur camp (préemptif) par rapport à l'autre.
Et ils avaient bien raison. AMHA MacOS avait une longueur de retard sur pas mal d'autres OS à ce niveau, y compris Windows, BeOS et même AmigaOS!
Jaypee wrote:
- On parle technique lorsque çà arrange : Le débat autour du
multi-tâche préemptif vs. coopératif. En pratique, tout le monde
s'en foutait, çà ne faisait aucune différence pour l'utilisateur
final.
Je ne connais pas très bien MacOS classique, mais le multitache
préemptif est incomparablement plus fiable et performant pour de
nombreux systèmes, en particulier ceux qui doivent être
multi-utilisateurs ou bien encore les serveurs.
Et même pour ma machine de particulier, je ne voudrais pas d'un système
coopératif!
Voir par exemple http://fr.wikipedia.org/wiki/Multitâches
Mais les supporters de Redmond insistaient sur la prétendue
supériorité du choix de leur camp (préemptif) par rapport à l'autre.
Et ils avaient bien raison. AMHA MacOS avait une longueur de retard sur
pas mal d'autres OS à ce niveau, y compris Windows, BeOS et même AmigaOS!
- On parle technique lorsque çà arrange : Le débat autour du multi-tâche préemptif vs. coopératif. En pratique, tout le monde s'en foutait, çà ne faisait aucune différence pour l'utilisateur final.
Je ne connais pas très bien MacOS classique, mais le multitache préemptif est incomparablement plus fiable et performant pour de nombreux systèmes, en particulier ceux qui doivent être multi-utilisateurs ou bien encore les serveurs. Et même pour ma machine de particulier, je ne voudrais pas d'un système coopératif!
Voir par exemple http://fr.wikipedia.org/wiki/Multitâches
Mais les supporters de Redmond insistaient sur la prétendue supériorité du choix de leur camp (préemptif) par rapport à l'autre.
Et ils avaient bien raison. AMHA MacOS avait une longueur de retard sur pas mal d'autres OS à ce niveau, y compris Windows, BeOS et même AmigaOS!
Michel Goldberg
dans l'article dpri05$pha$02$, Olivier Croquette à a écrit le 8/01/06 18:26 :
Je ne connais pas très bien MacOS classique, mais le multitache préemptif est incomparablement plus fiable et performant pour de nombreux systèmes, Un poil 'off topic', non ???
Merci
dans l'article dpri05$pha$02$1@news.t-online.com, Olivier Croquette à
ocroquette@ocroquette.free.fr a écrit le 8/01/06 18:26 :
Je ne connais pas très bien MacOS classique, mais le multitache
préemptif est incomparablement plus fiable et performant pour de
nombreux systèmes,
Un poil 'off topic', non ???
dans l'article dpri05$pha$02$, Olivier Croquette à a écrit le 8/01/06 18:26 :
Je ne connais pas très bien MacOS classique, mais le multitache préemptif est incomparablement plus fiable et performant pour de nombreux systèmes, Un poil 'off topic', non ???
Merci
Francois LE COAT
Bonjour Xavier,
Sous PPC, Windows devait utiliser l'émulation little endian, non ?
Ce n'est pas une émulation, mais un (des) mode(s) de fonctionnement.
Oui. Le PPC est un processeur de "transition" ... Mais est-ce que le big endian est définitivement enterré ?
Je pense personnellement que les processeurs big endian sont plus faciles à programmer. Ce qui explique selon moi pourquoi les OS fondés sur des processeurs little endian sont aussi instables.
ATARIstiquement,
-- François LE COAT Auteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D) http://eureka.atari.org
Bonjour Xavier,
Sous PPC, Windows devait utiliser l'émulation little endian, non ?
Ce n'est pas une émulation, mais un (des) mode(s) de fonctionnement.
Oui. Le PPC est un processeur de "transition" ... Mais est-ce que le
big endian est définitivement enterré ?
Je pense personnellement que les processeurs big endian sont plus
faciles à programmer. Ce qui explique selon moi pourquoi les OS
fondés sur des processeurs little endian sont aussi instables.
ATARIstiquement,
-- François LE COAT
Auteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D)
http://eureka.atari.org
Sous PPC, Windows devait utiliser l'émulation little endian, non ?
Ce n'est pas une émulation, mais un (des) mode(s) de fonctionnement.
Oui. Le PPC est un processeur de "transition" ... Mais est-ce que le big endian est définitivement enterré ?
Je pense personnellement que les processeurs big endian sont plus faciles à programmer. Ce qui explique selon moi pourquoi les OS fondés sur des processeurs little endian sont aussi instables.
ATARIstiquement,
-- François LE COAT Auteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D) http://eureka.atari.org
Gerald
Michel Goldberg wrote:
Donnez moi de bon arguments contre ce système !!!!
Le prix de la configuration minimum permettant de le faire tourner ? (qui n'est pas annoncée, afaik) -- Gérald
Michel Goldberg <michel.goldberg@wanadoo.fr> wrote:
Donnez moi de bon arguments contre ce système !!!!
Le prix de la configuration minimum permettant de le faire tourner ?
(qui n'est pas annoncée, afaik)
--
Gérald
Je pense personnellement que les processeurs big endian sont plus faciles à programmer. Ce qui explique selon moi pourquoi les OS fondés sur des processeurs little endian sont aussi instables.
ATARIstiquement,
-- François LE COAT Auteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D) http://eureka.atari.org
-- Le sage montre la lune, l'imbécile regarde le doigt.
Francois LE COAT <lecoat@atari.org> wrote:
Bonjour Xavier,
Sous PPC, Windows devait utiliser l'émulation little endian, non ?
Ce n'est pas une émulation, mais un (des) mode(s) de fonctionnement.
Oui. Le PPC est un processeur de "transition" ... Mais est-ce que le
big endian est définitivement enterré ?
Je pense personnellement que les processeurs big endian sont plus
faciles à programmer. Ce qui explique selon moi pourquoi les OS
fondés sur des processeurs little endian sont aussi instables.
ATARIstiquement,
-- François LE COAT
Auteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D)
http://eureka.atari.org
--
Le sage montre la lune, l'imbécile regarde le doigt.
Je pense personnellement que les processeurs big endian sont plus faciles à programmer. Ce qui explique selon moi pourquoi les OS fondés sur des processeurs little endian sont aussi instables.
ATARIstiquement,
-- François LE COAT Auteur de Eurêka 2.12 (Grapheur 2D, Modeleur 3D) http://eureka.atari.org
-- Le sage montre la lune, l'imbécile regarde le doigt.
Christophe Cuq
(Benoit Leraillez) writes:
Lotus et les problèmes de fuite... c'est la base de leur communication. C'est pour ça qu'ils en vendent tant dans les hypermarché.
Lotus et les problèmes de fuite... c'est la base de leur communication. C'est pour ça qu'ils en vendent tant dans les hypermarché.
-- Les gens sans humour manquent de sérieux.
:)
-- CHC
Jaypee
Olivier Croquette wrote:
Jaypee wrote:
- On parle technique lorsque çà arrange : Le débat autour du multi-tâche préemptif vs. coopératif. En pratique, tout le monde s'en foutait, çà ne faisait aucune différence pour l'utilisateur final.
Je ne connais pas très bien MacOS classique, mais le multitache préemptif est incomparablement plus fiable et performant pour de nombreux systèmes, en particulier ceux qui doivent être multi-utilisateurs ou bien encore les serveurs. Et même pour ma machine de particulier, je ne voudrais pas d'un système coopératif!
Voir par exemple http://fr.wikipedia.org/wiki/Multitâches
Mais les supporters de Redmond insistaient sur la prétendue supériorité du choix de leur camp (préemptif) par rapport à l'autre.
Et ils avaient bien raison. AMHA MacOS avait une longueur de retard sur pas mal d'autres OS à ce niveau, y compris Windows, BeOS et même AmigaOS! Je n'essayais pas de défendre le coopératif, mon point est
que la solution en principe meilleure (le préemptif) est si mal représentée par W95, qu'au final le résultat était aussi mauvais que Mac OS, du fait que Windows n'a pas de "window manager" et que les applis dessinant elles-même leur fenêtre, si l'appli stagne, ou gèle, la fenêtre ne peut être déplacée. C'est toujours vrai pour XP
Et dans ce sens, *on se sert d'un argument technique valide* mais qui n'est pas observable concrètement dans l'expérience de l'utilisateur final.
Voilà, j'essaye de placer la discussion au niveau des modes d' argumentation, pas de tel ou tel argument.
J-P
Olivier Croquette wrote:
Jaypee wrote:
- On parle technique lorsque çà arrange : Le débat autour du
multi-tâche préemptif vs. coopératif. En pratique, tout le monde
s'en foutait, çà ne faisait aucune différence pour l'utilisateur
final.
Je ne connais pas très bien MacOS classique, mais le multitache
préemptif est incomparablement plus fiable et performant pour de
nombreux systèmes, en particulier ceux qui doivent être
multi-utilisateurs ou bien encore les serveurs.
Et même pour ma machine de particulier, je ne voudrais pas d'un système
coopératif!
Voir par exemple http://fr.wikipedia.org/wiki/Multitâches
Mais les supporters de Redmond insistaient sur la prétendue
supériorité du choix de leur camp (préemptif) par rapport à l'autre.
Et ils avaient bien raison. AMHA MacOS avait une longueur de retard sur
pas mal d'autres OS à ce niveau, y compris Windows, BeOS et même AmigaOS!
Je n'essayais pas de défendre le coopératif, mon point est
que la solution en principe meilleure (le préemptif) est si mal
représentée par W95, qu'au final le résultat était aussi mauvais
que Mac OS, du fait que Windows n'a pas de "window manager" et que les
applis dessinant elles-même leur fenêtre, si l'appli stagne, ou gèle, la
fenêtre ne peut être déplacée. C'est toujours vrai pour XP
Et dans ce sens, *on se sert d'un argument technique valide*
mais qui n'est pas observable concrètement dans l'expérience de
l'utilisateur final.
Voilà, j'essaye de placer la discussion au niveau des modes d'
argumentation, pas de tel ou tel argument.
- On parle technique lorsque çà arrange : Le débat autour du multi-tâche préemptif vs. coopératif. En pratique, tout le monde s'en foutait, çà ne faisait aucune différence pour l'utilisateur final.
Je ne connais pas très bien MacOS classique, mais le multitache préemptif est incomparablement plus fiable et performant pour de nombreux systèmes, en particulier ceux qui doivent être multi-utilisateurs ou bien encore les serveurs. Et même pour ma machine de particulier, je ne voudrais pas d'un système coopératif!
Voir par exemple http://fr.wikipedia.org/wiki/Multitâches
Mais les supporters de Redmond insistaient sur la prétendue supériorité du choix de leur camp (préemptif) par rapport à l'autre.
Et ils avaient bien raison. AMHA MacOS avait une longueur de retard sur pas mal d'autres OS à ce niveau, y compris Windows, BeOS et même AmigaOS! Je n'essayais pas de défendre le coopératif, mon point est
que la solution en principe meilleure (le préemptif) est si mal représentée par W95, qu'au final le résultat était aussi mauvais que Mac OS, du fait que Windows n'a pas de "window manager" et que les applis dessinant elles-même leur fenêtre, si l'appli stagne, ou gèle, la fenêtre ne peut être déplacée. C'est toujours vrai pour XP
Et dans ce sens, *on se sert d'un argument technique valide* mais qui n'est pas observable concrètement dans l'expérience de l'utilisateur final.
Voilà, j'essaye de placer la discussion au niveau des modes d' argumentation, pas de tel ou tel argument.
J-P
Eric Levenez
Le 8/01/06 21:46, dans <43c17a21$0$29218$, « Jaypee » a écrit :
Je n'essayais pas de défendre le coopératif, mon point est que la solution en principe meilleure (le préemptif) est si mal représentée par W95, qu'au final le résultat était aussi mauvais que Mac OS, du fait que Windows n'a pas de "window manager" et que les applis dessinant elles-même leur fenêtre, si l'appli stagne, ou gèle, la fenêtre ne peut être déplacée. C'est toujours vrai pour XP
Ce qui est "amusant", c'est que Mac OS X a aussi le même problème dans certains cas où la fenêtre ne peut être déplacée parce que l'application est plantée. Il n'y avait pas cela dans NeXTSTEP qui avait un vrai Window Manager (et pas une version light comme sous Mac OS X). Je suppose que cela vient du type d'API utilisée ou de la façon de configurer les fenêtres sous Mac OS X.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 8/01/06 21:46, dans <43c17a21$0$29218$8fcfb975@news.wanadoo.fr>,
« Jaypee » <rf.oodanaw@sd.eepyaj> a écrit :
Je n'essayais pas de défendre le coopératif, mon point est
que la solution en principe meilleure (le préemptif) est si mal
représentée par W95, qu'au final le résultat était aussi mauvais
que Mac OS, du fait que Windows n'a pas de "window manager" et que les
applis dessinant elles-même leur fenêtre, si l'appli stagne, ou gèle, la
fenêtre ne peut être déplacée. C'est toujours vrai pour XP
Ce qui est "amusant", c'est que Mac OS X a aussi le même problème dans
certains cas où la fenêtre ne peut être déplacée parce que l'application est
plantée. Il n'y avait pas cela dans NeXTSTEP qui avait un vrai Window
Manager (et pas une version light comme sous Mac OS X). Je suppose que cela
vient du type d'API utilisée ou de la façon de configurer les fenêtres sous
Mac OS X.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 8/01/06 21:46, dans <43c17a21$0$29218$, « Jaypee » a écrit :
Je n'essayais pas de défendre le coopératif, mon point est que la solution en principe meilleure (le préemptif) est si mal représentée par W95, qu'au final le résultat était aussi mauvais que Mac OS, du fait que Windows n'a pas de "window manager" et que les applis dessinant elles-même leur fenêtre, si l'appli stagne, ou gèle, la fenêtre ne peut être déplacée. C'est toujours vrai pour XP
Ce qui est "amusant", c'est que Mac OS X a aussi le même problème dans certains cas où la fenêtre ne peut être déplacée parce que l'application est plantée. Il n'y avait pas cela dans NeXTSTEP qui avait un vrai Window Manager (et pas une version light comme sous Mac OS X). Je suppose que cela vient du type d'API utilisée ou de la façon de configurer les fenêtres sous Mac OS X.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
l'indien
On Sun, 08 Jan 2006 17:59:32 +0100, Francois LE COAT wrote:
Bonjour Laurent,
Mais historiquement Windows n'a toujours tourné nativement que sur des processeurs Intel (little endian)
Et aussi sur Alpha et sur PPC, enfin, au moins quelques versions de NT.
Je parle de versions "commerciales", et pas d'expérimentations douteuses ;)
Le CD commercial de Windows NT 4 comprends les version x86, PowerPC, Alpha et Mips.
Sinon, le processeur Aplha était un processeur little endian dont les P4 et les Xéons ont hérité le l'hyperthreading. Sous PPC, Windows devait utiliser l'émulation little endian, non ?
Apparement, il ne tournait pas entièrement en mode little-endian. Si je ne me trompe pas, il faisait comme OS/2: il utilisait le mode little-endian pour les drivers, ce qui permettait un portage plus rapide, mais devait lancer les applications en mode natif big-endian (à vérifier...).
On Sun, 08 Jan 2006 17:59:32 +0100, Francois LE COAT wrote:
Bonjour Laurent,
Mais historiquement Windows n'a toujours tourné nativement
que sur des processeurs Intel (little endian)
Et aussi sur Alpha et sur PPC, enfin, au moins quelques versions de NT.
Je parle de versions "commerciales", et pas d'expérimentations
douteuses ;)
Le CD commercial de Windows NT 4 comprends les version x86, PowerPC, Alpha
et Mips.
Sinon, le processeur Aplha était un processeur little endian
dont les P4 et les Xéons ont hérité le l'hyperthreading. Sous
PPC, Windows devait utiliser l'émulation little endian, non ?
Apparement, il ne tournait pas entièrement en mode little-endian.
Si je ne me trompe pas, il faisait comme OS/2: il utilisait le mode
little-endian pour les drivers, ce qui permettait un portage plus rapide,
mais devait lancer les applications en mode natif big-endian (à vérifier...).
On Sun, 08 Jan 2006 17:59:32 +0100, Francois LE COAT wrote:
Bonjour Laurent,
Mais historiquement Windows n'a toujours tourné nativement que sur des processeurs Intel (little endian)
Et aussi sur Alpha et sur PPC, enfin, au moins quelques versions de NT.
Je parle de versions "commerciales", et pas d'expérimentations douteuses ;)
Le CD commercial de Windows NT 4 comprends les version x86, PowerPC, Alpha et Mips.
Sinon, le processeur Aplha était un processeur little endian dont les P4 et les Xéons ont hérité le l'hyperthreading. Sous PPC, Windows devait utiliser l'émulation little endian, non ?
Apparement, il ne tournait pas entièrement en mode little-endian. Si je ne me trompe pas, il faisait comme OS/2: il utilisait le mode little-endian pour les drivers, ce qui permettait un portage plus rapide, mais devait lancer les applications en mode natif big-endian (à vérifier...).
