Pour info, NeXTSTEP marche bien sur VMware Fusion tournant sur Mac OS X sur
un Macintosh Intel. Et je dois dire qu'il marche nettement mieux que sur feu
VirtualPC sur Macintosh PPC : sans parler de la vitesse ou des drivers
VMware adaptés à NeXTSTEP, il s'agit surtout du bug sur le coprocesseur
mathématique des PPC mal émulé par Virtual PC qui perturbait Display
PostScript, fortement optimisé pour les processeurs Intel.
Ma nouvelle page sur VMware :
<http://www.levenez.com/NeXTSTEP/VMware.html>
Pour info mon ancienne page sur VirtualPC :
<http://www.levenez.com/NeXTSTEP/VirtualPC.html>
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Oui, Display Postscript était très rapide. En plus du "Live Scroll" il y avait aussi la gestion des déplacements des fenêtres. À l'époque quand on déplaçait une fenêtre sur un autre système, il y avait toujours des zones blanches et un attente avant que le blanc soit redessiné. Rien de tel sur NeXTSTEP.
Comment ont-ils fait ? Ce ne peut être une question de puissance: par comparaison, les Quadras embarquaient le même processeur (68040)
L'effet "gomme" des fenêtres non plus.
Peut-tu me rappeler ce qu'était cet effet ?
Cordialement,
Thierry
Eric Levenez wrote:
Oui, Display Postscript était très rapide. En plus du "Live Scroll" il y
avait aussi la gestion des déplacements des fenêtres. À l'époque quand on
déplaçait une fenêtre sur un autre système, il y avait toujours des zones
blanches et un attente avant que le blanc soit redessiné. Rien de tel sur
NeXTSTEP.
Comment ont-ils fait ? Ce ne peut être une question de puissance: par
comparaison, les Quadras embarquaient le même processeur (68040)
Oui, Display Postscript était très rapide. En plus du "Live Scroll" il y avait aussi la gestion des déplacements des fenêtres. À l'époque quand on déplaçait une fenêtre sur un autre système, il y avait toujours des zones blanches et un attente avant que le blanc soit redessiné. Rien de tel sur NeXTSTEP.
Comment ont-ils fait ? Ce ne peut être une question de puissance: par comparaison, les Quadras embarquaient le même processeur (68040)
L'effet "gomme" des fenêtres non plus.
Peut-tu me rappeler ce qu'était cet effet ?
Cordialement,
Thierry
Eric Levenez
Le 23/02/08 15:58, dans <1icrtmw.mv31vw12qvnazN%, « FiLH » a écrit :
Eric Levenez wrote:
Le 23/02/08 14:37, dans <1icrpxc.10r65zn198xvwaN%,
FiLH wrote:
Il y aurait sans doute un juste milieu à trouver... Mais encore faudrait-il s'en donner la peine.
Oui, l'optimisation n'est pas trouver des "hacks immondes" ou écrire en assembleur, c'est d'abord et principalement réfléchir. Ensuite cela consiste à trouver la bonne architecture logicielle et trouver les bons algorithmes.
Là c'est pas de l'optimisation hein... :) Toi qui aime jouer sur les mots exacts.
Et si, l'optimisation commence par l'optimisation des ressources et savoir utiliser ce que l'on a. Pierre-Olivier TAUBATY parle par exemple du multi-c¦ur qui doit être utilisé. Il y a beaucoup de choses possibles que le programmeur peut faire, et comme je l'ai dit il faut d'abord réfléchir.
Beaucoup de programmeurs commencent pas du couper/coller de vieux codes qu'ils ne connaissent pas mais qui est sensé faire plus ou moins ce qu'ils recherchent. Puis ils lancent leur programme qui plante et enfin ils debuguent en pas à pas à tour de bras pour essayer de plâtrer le tout. Dès que ça plante plus ils considèrent que c'est bon.
La première chose à interdire serait l'utilisation de debugger...
Et là ces nouveaux programmeurs ne savent que faire du couper/coller de codes écrits par d'autres du même niveau...
T'as raison « c'était mieux avant » (c) (tm) (r)..
Non, il existe de bons programmeurs à l'heure actuelle.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 23/02/08 15:58, dans <1icrtmw.mv31vw12qvnazN%filh@filh.orgie>, « FiLH »
<filh@filh.orgie> a écrit :
Eric Levenez <usenet@levenez.com> wrote:
Le 23/02/08 14:37, dans <1icrpxc.10r65zn198xvwaN%sebastienmarty@yahoo.fr>,
FiLH <filh@filh.orgie> wrote:
Il y aurait sans doute un juste milieu à trouver... Mais encore
faudrait-il s'en donner la peine.
Oui, l'optimisation n'est pas trouver des "hacks immondes" ou écrire en
assembleur, c'est d'abord et principalement réfléchir. Ensuite cela consiste
à trouver la bonne architecture logicielle et trouver les bons algorithmes.
Là c'est pas de l'optimisation hein... :) Toi qui aime jouer sur les
mots exacts.
Et si, l'optimisation commence par l'optimisation des ressources et savoir
utiliser ce que l'on a. Pierre-Olivier TAUBATY parle par exemple du
multi-c¦ur qui doit être utilisé. Il y a beaucoup de choses possibles que le
programmeur peut faire, et comme je l'ai dit il faut d'abord réfléchir.
Beaucoup de programmeurs commencent pas du couper/coller de vieux codes
qu'ils ne connaissent pas mais qui est sensé faire plus ou moins ce qu'ils
recherchent. Puis ils lancent leur programme qui plante et enfin ils
debuguent en pas à pas à tour de bras pour essayer de plâtrer le tout. Dès
que ça plante plus ils considèrent que c'est bon.
La première chose à interdire serait l'utilisation de debugger...
Et là ces nouveaux programmeurs ne savent que faire du couper/coller de
codes écrits par d'autres du même niveau...
T'as raison « c'était mieux avant » (c) (tm) (r)..
Non, il existe de bons programmeurs à l'heure actuelle.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 23/02/08 15:58, dans <1icrtmw.mv31vw12qvnazN%, « FiLH » a écrit :
Eric Levenez wrote:
Le 23/02/08 14:37, dans <1icrpxc.10r65zn198xvwaN%,
FiLH wrote:
Il y aurait sans doute un juste milieu à trouver... Mais encore faudrait-il s'en donner la peine.
Oui, l'optimisation n'est pas trouver des "hacks immondes" ou écrire en assembleur, c'est d'abord et principalement réfléchir. Ensuite cela consiste à trouver la bonne architecture logicielle et trouver les bons algorithmes.
Là c'est pas de l'optimisation hein... :) Toi qui aime jouer sur les mots exacts.
Et si, l'optimisation commence par l'optimisation des ressources et savoir utiliser ce que l'on a. Pierre-Olivier TAUBATY parle par exemple du multi-c¦ur qui doit être utilisé. Il y a beaucoup de choses possibles que le programmeur peut faire, et comme je l'ai dit il faut d'abord réfléchir.
Beaucoup de programmeurs commencent pas du couper/coller de vieux codes qu'ils ne connaissent pas mais qui est sensé faire plus ou moins ce qu'ils recherchent. Puis ils lancent leur programme qui plante et enfin ils debuguent en pas à pas à tour de bras pour essayer de plâtrer le tout. Dès que ça plante plus ils considèrent que c'est bon.
La première chose à interdire serait l'utilisation de debugger...
Et là ces nouveaux programmeurs ne savent que faire du couper/coller de codes écrits par d'autres du même niveau...
T'as raison « c'était mieux avant » (c) (tm) (r)..
Non, il existe de bons programmeurs à l'heure actuelle.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Eric Levenez
Le 23/02/08 18:27, dans <47c05779$0$2941$, « Thierry Mella » a écrit :
Eric Levenez wrote:
Oui, Display Postscript était très rapide. En plus du "Live Scroll" il y avait aussi la gestion des déplacements des fenêtres. À l'époque quand on déplaçait une fenêtre sur un autre système, il y avait toujours des zones blanches et un attente avant que le blanc soit redessiné. Rien de tel sur NeXTSTEP.
Comment ont-ils fait ? Ce ne peut être une question de puissance: par comparaison, les Quadras embarquaient le même processeur (68040)
Par défaut les fenêtres de NeXTSTEP (et de Mac OS X) sont bufferisées. Cela veut dire que le contenu de la fenêtre est mémorisé en bitmap dans une zone mémoire. Cela prend de la place mémoire, mais cela permet de redessiner très rapidement la fenêtre à l'écran, sans intervention de l'application.
Sur les autres systèmes (Mac OS, Windows), quand un bout d'une fenêtre se découvre (elle n'est plus cachée par une autre), le système affiche d'abord une zone blanche, puis demande à l'application qui gère la fenêtre découverte de la redessiner. Cela impose un délai et du CPU en plus du problème esthétique.
L'effet "gomme" des fenêtres non plus.
Peut-tu me rappeler ce qu'était cet effet ?
Quand une application (Mac OS ou Windows) est plantée, elle ne peut pas redessiner le contenu de ses fenêtres. Cela veut dire que dans ce cas, quand on déplace une fenêtre devant une fenêtre plantée, cette dernière affichera la trace de la fenêtre déplacée. Dans certains cas, c'est une zone blanche qui est laissée, comme pour le passage d'une gomme.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 23/02/08 18:27, dans <47c05779$0$2941$ba620e4c@news.skynet.be>, « Thierry
Mella » <thierry.mella@skynet.be> a écrit :
Eric Levenez wrote:
Oui, Display Postscript était très rapide. En plus du "Live Scroll" il y
avait aussi la gestion des déplacements des fenêtres. À l'époque quand on
déplaçait une fenêtre sur un autre système, il y avait toujours des zones
blanches et un attente avant que le blanc soit redessiné. Rien de tel sur
NeXTSTEP.
Comment ont-ils fait ? Ce ne peut être une question de puissance: par
comparaison, les Quadras embarquaient le même processeur (68040)
Par défaut les fenêtres de NeXTSTEP (et de Mac OS X) sont bufferisées. Cela
veut dire que le contenu de la fenêtre est mémorisé en bitmap dans une zone
mémoire. Cela prend de la place mémoire, mais cela permet de redessiner très
rapidement la fenêtre à l'écran, sans intervention de l'application.
Sur les autres systèmes (Mac OS, Windows), quand un bout d'une fenêtre se
découvre (elle n'est plus cachée par une autre), le système affiche d'abord
une zone blanche, puis demande à l'application qui gère la fenêtre
découverte de la redessiner. Cela impose un délai et du CPU en plus du
problème esthétique.
L'effet "gomme" des fenêtres non plus.
Peut-tu me rappeler ce qu'était cet effet ?
Quand une application (Mac OS ou Windows) est plantée, elle ne peut pas
redessiner le contenu de ses fenêtres. Cela veut dire que dans ce cas, quand
on déplace une fenêtre devant une fenêtre plantée, cette dernière affichera
la trace de la fenêtre déplacée. Dans certains cas, c'est une zone blanche
qui est laissée, comme pour le passage d'une gomme.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 23/02/08 18:27, dans <47c05779$0$2941$, « Thierry Mella » a écrit :
Eric Levenez wrote:
Oui, Display Postscript était très rapide. En plus du "Live Scroll" il y avait aussi la gestion des déplacements des fenêtres. À l'époque quand on déplaçait une fenêtre sur un autre système, il y avait toujours des zones blanches et un attente avant que le blanc soit redessiné. Rien de tel sur NeXTSTEP.
Comment ont-ils fait ? Ce ne peut être une question de puissance: par comparaison, les Quadras embarquaient le même processeur (68040)
Par défaut les fenêtres de NeXTSTEP (et de Mac OS X) sont bufferisées. Cela veut dire que le contenu de la fenêtre est mémorisé en bitmap dans une zone mémoire. Cela prend de la place mémoire, mais cela permet de redessiner très rapidement la fenêtre à l'écran, sans intervention de l'application.
Sur les autres systèmes (Mac OS, Windows), quand un bout d'une fenêtre se découvre (elle n'est plus cachée par une autre), le système affiche d'abord une zone blanche, puis demande à l'application qui gère la fenêtre découverte de la redessiner. Cela impose un délai et du CPU en plus du problème esthétique.
L'effet "gomme" des fenêtres non plus.
Peut-tu me rappeler ce qu'était cet effet ?
Quand une application (Mac OS ou Windows) est plantée, elle ne peut pas redessiner le contenu de ses fenêtres. Cela veut dire que dans ce cas, quand on déplace une fenêtre devant une fenêtre plantée, cette dernière affichera la trace de la fenêtre déplacée. Dans certains cas, c'est une zone blanche qui est laissée, comme pour le passage d'une gomme.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Thierry Mella
Eric Levenez wrote:
Par défaut les fenêtres de NeXTSTEP (et de Mac OS X) sont bufferisées. Cela veut dire que le contenu de la fenêtre est mémorisé en bitmap dans une zone mémoire. Cela prend de la place mémoire, mais cela permet de redessiner très rapidement la fenêtre à l'écran, sans intervention de l'application.
N'était-ce pas osé à l'époque, vu le prix et la taille des mémoires ?
Sur les autres systèmes (Mac OS, Windows), quand un bout d'une fenêtre se découvre (elle n'est plus cachée par une autre), le système affiche d'abord une zone blanche, puis demande à l'application qui gère la fenêtre découverte de la redessiner. Cela impose un délai et du CPU en plus du problème esthétique.
Je ne connais pas Vista, seulement XP. Mais M$ ne peut-il pas résoudre ce problème à cause de la sacro-sainte compatibilité ?
Eric Levenez wrote:
Par défaut les fenêtres de NeXTSTEP (et de Mac OS X) sont bufferisées. Cela
veut dire que le contenu de la fenêtre est mémorisé en bitmap dans une zone
mémoire. Cela prend de la place mémoire, mais cela permet de redessiner très
rapidement la fenêtre à l'écran, sans intervention de l'application.
N'était-ce pas osé à l'époque, vu le prix et la taille des mémoires ?
Sur les autres systèmes (Mac OS, Windows), quand un bout d'une fenêtre se
découvre (elle n'est plus cachée par une autre), le système affiche d'abord
une zone blanche, puis demande à l'application qui gère la fenêtre
découverte de la redessiner. Cela impose un délai et du CPU en plus du
problème esthétique.
Je ne connais pas Vista, seulement XP. Mais M$ ne peut-il pas résoudre
ce problème à cause de la sacro-sainte compatibilité ?
Par défaut les fenêtres de NeXTSTEP (et de Mac OS X) sont bufferisées. Cela veut dire que le contenu de la fenêtre est mémorisé en bitmap dans une zone mémoire. Cela prend de la place mémoire, mais cela permet de redessiner très rapidement la fenêtre à l'écran, sans intervention de l'application.
N'était-ce pas osé à l'époque, vu le prix et la taille des mémoires ?
Sur les autres systèmes (Mac OS, Windows), quand un bout d'une fenêtre se découvre (elle n'est plus cachée par une autre), le système affiche d'abord une zone blanche, puis demande à l'application qui gère la fenêtre découverte de la redessiner. Cela impose un délai et du CPU en plus du problème esthétique.
Je ne connais pas Vista, seulement XP. Mais M$ ne peut-il pas résoudre ce problème à cause de la sacro-sainte compatibilité ?
Eric Levenez
Le 23/02/08 23:03, dans <47c09839$0$2985$, « Thierry Mella » a écrit :
Eric Levenez wrote:
Par défaut les fenêtres de NeXTSTEP (et de Mac OS X) sont bufferisées. Cela veut dire que le contenu de la fenêtre est mémorisé en bitmap dans une zone mémoire. Cela prend de la place mémoire, mais cela permet de redessiner très rapidement la fenêtre à l'écran, sans intervention de l'application.
N'était-ce pas osé à l'époque, vu le prix et la taille des mémoires ?
À l'époque l'écran utilisait 2 bits par pixel. De plus NeXTSTEP est un unix et donc il gère la mémoire virtuelle en utilisant un swap disque. Et enfin le swap disque était compressé. Tout cela faisait que la bufferisation des fenêtres marchait bien. Quand les écrans couleurs sont sortis, la taille de la RAM disponible avait augmenté de même.
Sur les autres systèmes (Mac OS, Windows), quand un bout d'une fenêtre se découvre (elle n'est plus cachée par une autre), le système affiche d'abord une zone blanche, puis demande à l'application qui gère la fenêtre découverte de la redessiner. Cela impose un délai et du CPU en plus du problème esthétique.
Je ne connais pas Vista, seulement XP. Mais M$ ne peut-il pas résoudre ce problème à cause de la sacro-sainte compatibilité ?
Je ne connais pas non plus Vista (bien que je l'ai installé sur mon Mac justement pour l'apprendre). Mais entre ce que Microsoft pourrait faire et ce qu'ils sont, il y a 2 mondes.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 23/02/08 23:03, dans <47c09839$0$2985$ba620e4c@news.skynet.be>, « Thierry
Mella » <thierry.mella@skynet.be> a écrit :
Eric Levenez wrote:
Par défaut les fenêtres de NeXTSTEP (et de Mac OS X) sont bufferisées. Cela
veut dire que le contenu de la fenêtre est mémorisé en bitmap dans une zone
mémoire. Cela prend de la place mémoire, mais cela permet de redessiner très
rapidement la fenêtre à l'écran, sans intervention de l'application.
N'était-ce pas osé à l'époque, vu le prix et la taille des mémoires ?
À l'époque l'écran utilisait 2 bits par pixel. De plus NeXTSTEP est un unix
et donc il gère la mémoire virtuelle en utilisant un swap disque. Et enfin
le swap disque était compressé. Tout cela faisait que la bufferisation des
fenêtres marchait bien. Quand les écrans couleurs sont sortis, la taille de
la RAM disponible avait augmenté de même.
Sur les autres systèmes (Mac OS, Windows), quand un bout d'une fenêtre se
découvre (elle n'est plus cachée par une autre), le système affiche d'abord
une zone blanche, puis demande à l'application qui gère la fenêtre
découverte de la redessiner. Cela impose un délai et du CPU en plus du
problème esthétique.
Je ne connais pas Vista, seulement XP. Mais M$ ne peut-il pas résoudre
ce problème à cause de la sacro-sainte compatibilité ?
Je ne connais pas non plus Vista (bien que je l'ai installé sur mon Mac
justement pour l'apprendre). Mais entre ce que Microsoft pourrait faire et
ce qu'ils sont, il y a 2 mondes.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 23/02/08 23:03, dans <47c09839$0$2985$, « Thierry Mella » a écrit :
Eric Levenez wrote:
Par défaut les fenêtres de NeXTSTEP (et de Mac OS X) sont bufferisées. Cela veut dire que le contenu de la fenêtre est mémorisé en bitmap dans une zone mémoire. Cela prend de la place mémoire, mais cela permet de redessiner très rapidement la fenêtre à l'écran, sans intervention de l'application.
N'était-ce pas osé à l'époque, vu le prix et la taille des mémoires ?
À l'époque l'écran utilisait 2 bits par pixel. De plus NeXTSTEP est un unix et donc il gère la mémoire virtuelle en utilisant un swap disque. Et enfin le swap disque était compressé. Tout cela faisait que la bufferisation des fenêtres marchait bien. Quand les écrans couleurs sont sortis, la taille de la RAM disponible avait augmenté de même.
Sur les autres systèmes (Mac OS, Windows), quand un bout d'une fenêtre se découvre (elle n'est plus cachée par une autre), le système affiche d'abord une zone blanche, puis demande à l'application qui gère la fenêtre découverte de la redessiner. Cela impose un délai et du CPU en plus du problème esthétique.
Je ne connais pas Vista, seulement XP. Mais M$ ne peut-il pas résoudre ce problème à cause de la sacro-sainte compatibilité ?
Je ne connais pas non plus Vista (bien que je l'ai installé sur mon Mac justement pour l'apprendre). Mais entre ce que Microsoft pourrait faire et ce qu'ils sont, il y a 2 mondes.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Nina Popravka
On Sat, 23 Feb 2008 23:03:37 +0100, Thierry Mella wrote:
Sur les autres systèmes (Mac OS, Windows), quand un bout d'une fenêtre se découvre (elle n'est plus cachée par une autre), le système affiche d'abord une zone blanche, puis demande à l'application qui gère la fenêtre découverte de la redessiner. Cela impose un délai et du CPU en plus du problème esthétique.
Je ne connais pas Vista, seulement XP. Mais M$ ne peut-il pas résoudre ce problème à cause de la sacro-sainte compatibilité ?
Moi je me demande simplement si ce que dit Eric est vrai, parce que ça fait 10 mn que je tripote des fenêtres sous XP, et sur un PIV 512 Mo Ram, et je ne vois aucune zone blanche. -- Nina
On Sat, 23 Feb 2008 23:03:37 +0100, Thierry Mella
<thierry.mella@skynet.be> wrote:
Sur les autres systèmes (Mac OS, Windows), quand un bout d'une fenêtre se
découvre (elle n'est plus cachée par une autre), le système affiche d'abord
une zone blanche, puis demande à l'application qui gère la fenêtre
découverte de la redessiner. Cela impose un délai et du CPU en plus du
problème esthétique.
Je ne connais pas Vista, seulement XP. Mais M$ ne peut-il pas résoudre
ce problème à cause de la sacro-sainte compatibilité ?
Moi je me demande simplement si ce que dit Eric est vrai, parce que ça
fait 10 mn que je tripote des fenêtres sous XP, et sur un PIV 512 Mo
Ram, et je ne vois aucune zone blanche.
--
Nina
On Sat, 23 Feb 2008 23:03:37 +0100, Thierry Mella wrote:
Sur les autres systèmes (Mac OS, Windows), quand un bout d'une fenêtre se découvre (elle n'est plus cachée par une autre), le système affiche d'abord une zone blanche, puis demande à l'application qui gère la fenêtre découverte de la redessiner. Cela impose un délai et du CPU en plus du problème esthétique.
Je ne connais pas Vista, seulement XP. Mais M$ ne peut-il pas résoudre ce problème à cause de la sacro-sainte compatibilité ?
Moi je me demande simplement si ce que dit Eric est vrai, parce que ça fait 10 mn que je tripote des fenêtres sous XP, et sur un PIV 512 Mo Ram, et je ne vois aucune zone blanche. -- Nina
sebastienmarty
Nina Popravka wrote:
Moi je me demande simplement si ce que dit Eric est vrai, parce que ça fait 10 mn que je tripote des fenêtres sous XP, et sur un PIV 512 Mo Ram, et je ne vois aucune zone blanche.
Sur un XP je ne sais pas, mais sur un vénérable 3.1 c'était très nettement visible.
-- [SbM] <http://sebastienmarty.free.fr> - <http://tradintosh.free.fr> <http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr> "If the French were really intelligent, they'd speak English" (W. Sheed)
Nina Popravka <Nina@nospam.invalid> wrote:
Moi je me demande simplement si ce que dit Eric est vrai, parce que ça
fait 10 mn que je tripote des fenêtres sous XP, et sur un PIV 512 Mo
Ram, et je ne vois aucune zone blanche.
Sur un XP je ne sais pas, mais sur un vénérable 3.1 c'était très
nettement visible.
--
[SbM]
<http://sebastienmarty.free.fr> - <http://tradintosh.free.fr>
<http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr>
"If the French were really intelligent, they'd speak English" (W. Sheed)
Moi je me demande simplement si ce que dit Eric est vrai, parce que ça fait 10 mn que je tripote des fenêtres sous XP, et sur un PIV 512 Mo Ram, et je ne vois aucune zone blanche.
Sur un XP je ne sais pas, mais sur un vénérable 3.1 c'était très nettement visible.
-- [SbM] <http://sebastienmarty.free.fr> - <http://tradintosh.free.fr> <http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr> "If the French were really intelligent, they'd speak English" (W. Sheed)
filh
Erwan David wrote:
(FiLH) écrivait :
Erwan David wrote:
(FiLH) écrivait :
Well... on peut aussi considérer que des optimisations qui reposent sur des hacks immondes non portables...
On peut optiliser ET être portable. Je programme de l'embarqué, là on est bien obligé
Well portable dans l'embarqué ? (1) Optimisé en place oui là je veux bien.
ARM sous Symbian ou linux ou winCE, ou bien Mips32 ou Hitachi H8SX pour moi.
Rahh mais c'est de l'embarqué vachement sofistiqué ça ! :)
20 ms pour faire les 6 échanges nécessaires à l'ouverture d'un portillon du métro par une carte Navigo? Il ne s'agit pas de trainer, ni d'un côté ni de l'autre.
Oui, mais c'est pas prévu pour pouvoir embarquer un plugin video...un jour :)
Ça non... Jusqu'à ce qu'ils décident de comparer le porteur avec une photo dans la base centrale...
:) Disons que quand je vois le nombre de couches qui se balade dans certains soft (simplement le nb de bibliothèques quoi)... c'est difficile d'optimiser tout ça à la fois. Ou... si on veut optimiser de contrôler tout ça... Un prog un peu sofistiqué qui va gérer un peu de xml, un peu de ssl, un peu de web, un peu de snmp, pouvoir envoyé quelques mails d'alerte... :)
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Erwan David <erwan@rail.eu.org> wrote:
filh@filh.orgie (FiLH) écrivait :
Erwan David <erwan@rail.eu.org> wrote:
filh@filh.orgie (FiLH) écrivait :
Well... on peut aussi considérer que des optimisations qui reposent sur
des hacks immondes non portables...
On peut optiliser ET être portable. Je programme de l'embarqué, là on
est bien obligé
Well portable dans l'embarqué ? (1)
Optimisé en place oui là je veux bien.
ARM sous Symbian ou linux ou winCE, ou bien Mips32 ou Hitachi H8SX pour
moi.
Rahh mais c'est de l'embarqué vachement sofistiqué ça ! :)
20 ms pour faire les 6 échanges nécessaires à l'ouverture d'un portillon
du métro par une carte Navigo? Il ne s'agit pas de trainer, ni d'un côté
ni de l'autre.
Oui, mais c'est pas prévu pour pouvoir embarquer un plugin video...un
jour :)
Ça non... Jusqu'à ce qu'ils décident de comparer le porteur avec une
photo dans la base centrale...
:) Disons que quand je vois le nombre de couches qui se balade dans
certains soft (simplement le nb de bibliothèques quoi)... c'est
difficile d'optimiser tout ça à la fois. Ou... si on veut optimiser de
contrôler tout ça... Un prog un peu sofistiqué qui va gérer un peu de
xml, un peu de ssl, un peu de web, un peu de snmp, pouvoir envoyé
quelques mails d'alerte... :)
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
Well... on peut aussi considérer que des optimisations qui reposent sur des hacks immondes non portables...
On peut optiliser ET être portable. Je programme de l'embarqué, là on est bien obligé
Well portable dans l'embarqué ? (1) Optimisé en place oui là je veux bien.
ARM sous Symbian ou linux ou winCE, ou bien Mips32 ou Hitachi H8SX pour moi.
Rahh mais c'est de l'embarqué vachement sofistiqué ça ! :)
20 ms pour faire les 6 échanges nécessaires à l'ouverture d'un portillon du métro par une carte Navigo? Il ne s'agit pas de trainer, ni d'un côté ni de l'autre.
Oui, mais c'est pas prévu pour pouvoir embarquer un plugin video...un jour :)
Ça non... Jusqu'à ce qu'ils décident de comparer le porteur avec une photo dans la base centrale...
:) Disons que quand je vois le nombre de couches qui se balade dans certains soft (simplement le nb de bibliothèques quoi)... c'est difficile d'optimiser tout ça à la fois. Ou... si on veut optimiser de contrôler tout ça... Un prog un peu sofistiqué qui va gérer un peu de xml, un peu de ssl, un peu de web, un peu de snmp, pouvoir envoyé quelques mails d'alerte... :)
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Jerome Vernet
Je ne connais pas non plus Vista (bien que je l'ai installé sur mon Mac Que c'est affreux, de lire ça...
;-p
Cela dit, Vista, va falloir s'y mettre, sinon on va être largués...
-- ----- Jerome Vernet Petite Collection de vieux micros http://perso.orange.fr/jerome.vernet/
Je ne connais pas non plus Vista (bien que je l'ai installé sur mon Mac
Que c'est affreux, de lire ça...
;-p
Cela dit, Vista, va falloir s'y mettre, sinon on va être largués...
--
-----
Jerome Vernet
Petite Collection de vieux micros
http://perso.orange.fr/jerome.vernet/
