Bonsoir Andr�.je n'ai jamais demand� un interface tout graphique, je suis le premier � employer les raccourcis clavier... mais quand on les change r�guli�rement �a fait ch... genre commnde shift N pour un nouveua dossier ou commande H du X pour ouvrir sa fen�tre "home" qui devient commande shift H en X.1 (ou X.2, je me souviens plus)... que le terminal existe et que certains en soient heureux, tant mieux pour eux... si le mode texte me plaisait, en 89 quand j'ai choisi le mac, j'aurais choisi un pc sous dos... ce qui ressemble furieusement au terminal... m�me qu'il y a plein de commande en commun...ce qui me fait surtout ch... c'est que l� o� l'interface graphique du 9 �tait rapide, celle du X a bu du jus de limace... Et je maintiens que d�brayer la transparence et les ombres devraient am�liorer les choses... na! ps: quelqu'un pour warcraft? :-)
Woaw, que de r�actions ... j'en reviens toujours pas ;-)
Je comprends bien la situation avec ses modifs de raccourcis, etc... et vu ton experience dans OS.9 et probablement les versions ant�rieures, je me doute de l'aspect critique (� juste titre) que tu �prouves devant le comportement de OS.X
Pour les merdouillages (j'adore l'expression, je garde) sans trop entrer dans les d�tails je peux un peu d�grossir ...
Mac OS->9.x utilise un GUI qui fait partie int�grante du "coeur" de l'O.S. tout comme Wind... ok je me tais... ;-)
Donc, c'est hyper rapide car il n'y a pas de "protocole de dialogue" entre la couche "drivers/API" et les fonctions bas niveau du "Coeur". C'est un peu "pr�c�bl�" en quelques sorte. Le r�sultat entraine 2 choses:
1) La vitesse d'affichage n'est pas frein�e, car le processus d'affichage est prioritaire, car int�gr� au coeur (lui m�me high priority, mais je ne sais pas si OS.9 int�gre une notion de priorit� dans les thread ... ca fait partie de mes trop nombreuses lacunes).
2) Si la GUI crash => Le Kernel est crash� => reboot.
Mac OS.X, tout comme Linux, utilise un "GUI Launcher" type X11 ou d�riv� � la sauce Cuppertino (Vu qu'Aqua reste sous la coupole de notre ami Jobs). Cela est une source de complication, et n�cessite des couches d'abstractions.
Bref, Mac OS.X n'est pas "au courant" qu'il est dot� d'un GUI. En fait le GUI (Aqua dans le cas Mac OS.X, Gnome,KDE, ... dans le monde Linux) est un programme (plut�t un service) comme un autre...
Mach Kernel fait tourner le service 'Aqua' (l� je fais un super raccourci technique, j'esp�re que mes amis d�veloppeurs ne m'en voudront pas trop) comme un autre process (Pid, priority level, privilege mode, ...). Or mach Kernel est apparement (d'apr�s mes constatations) configur� pour r�partir sa puissance sur le nombre de t�ches en cours... Donc le GUI n'est pas prioritaire, ou pas � chaques secondes du moins.
Voil� pourquoi c'est infiniment plus lent.
Parce que on peut le voir comme un service, qu'il n�cessite des couches d'abstractions suppl�mentaires par rapport � un OS avec GUI au m�me niveau que le Kernel.
Les avantages sont multiples :
1) Si le process 'Aqua' (autre super raccourci d�sol�) tombe, ton Mac reste 'up & ready'. Il suffit (merde je parle comme moin boss), comme un autre process de le relancer � la main (restart)
2) Le GUI est compl�tement ind�pendant du Kernel, et de plus, peut �tre d�tourn� vers une autre adr ip que "localhost" => tu as un VNC/Remote GUI pour pas 1 fr. (utile surtout avant, �poque MainFrame sous Unix avec 1 ordi et 50 terminaux VT100, etc... ou tu pouvais 'aiguiller' l'affichage vers 1 ou plusieurs Terminaux ....
3) Le Kernel est exempt (l� je parle au niveau programmatique, pas au niveau utilisateur) de code propre � l'affichage. Donc hyper "clean", ce qui est un des buts recherch�.
Je ne vois qu'un d�faut � cette architecture :
Sa lenteur ... Plusieurs Mo par sec � envoy� vers Aqua. Ca explique pourquoi reduire les options d'affichage tels les ombres, etc... n'acc�l�re que de fa�on minime l'affichage, et que Apple a pr�f�r� utiliser la puce graphique sous openGL (quartz extreme) qui elle, poss�de une architecture optimis�e pour l'affichage et fait des "mov" en m�moire bien plus rapidement que le G3/G4 car optimis�e pour ... (openGL est le layer utilis�).
Voil� pourquoi :
1) Mac os.x peut tr�s bien tourner sans Aqua.
2) Enabler ou disabler les fonctions d'affichage ne changent pas vraiment �norm�ment la vitesse (enfin la lenteur). C'est juste 5% de travail en moins pour le processeur => pas tr�s significatif.
3) La lenteur tr�s significative de l'affichage sous OS.X. si on n'utilise pas quartz extreme.
Si �a peut t'�clairer un peu ... Mais l� techniquement des d�veloppeurs d'Apple, vu cette architecture n'auraient pas pu faire plus rapide, si tu savais la quantit� astonomique de ressource que cela prend avant d'afficher un pixel � l'�cran ... Ca prend 260 pages A4 en Arial 8 sans aucun dessins ... Alors le malheureux PPC ... Ben �a mouline dur ....
Maintenant, du c�t� utilisateur, pour paraphraser ma tendre moiti� : "M'en fou moi de tout ce que tu me sorts ... C'est immonde de lenteur .... pppffff ... en plus parfois j'appuie pour avoir les accents et tout se fige pendant 1sec ou 2 ... etc..."
Et moi de r�pondre : "C'est le prix � payer pour avoir une fiabilit�".
En fait, globalement on peut presque dire (le 100% n'existe pas) : Fiabilit� != performance. Parce que pour faire du fiable, il faut �crire en tenant compte de tout ce qui peut ne pas aller, pour enfin ex�cuter une ligne d'instructions.
En programmation "performance" on �crit pas pour "tous les cas o� ...", on �crit direct un truc quelque part en m�moire. Si ca plait pas � l'OS, ben il ira au Diable (=> d�brancher la prise).
Quand je faisais des d�mos sur Amiga, on "outrepassait" l'O.S. avec nos propres routines d'affichage, etc... et on allait direct dans la ram vid�o (dont l'adresse �tait retourn�e par des co-processeurs) �crire. Comme il n'y avait pas de notions de m�moire prot�g�e, on pouvait �crire "violement" dans la ram ... Quand �a marchait c'�tait innoui. Mais au moindre octets de d�rapage, c'�tait le reboot assur� ...
Si on avait d� faire nos d�mos en utilisant les "r�gles de l'Art" et utiliser les fonctions d'AmigaOS, notre belle d�mo aurait saccad� violement .... On comptait m�me en "cycles d'horloge" pour se faire une id�e du WaitVBL appropri� pour un rafraichissement (swap screen) de l'affichage (alors qu'il existe 3 fonctions AmigaOS pour le savoir ... mais on perdait environ 230 cycles. Et � partir de 50 cycles, c'est 1/2 image de perdues en vitesse d'affichage => scintillements, ...).
Voil� voil� en super gros r�sum� le pourquoi du comment (d�sol� pour les puristes qui ont probablement d� avoir des probl�mes intestinaux, mais bon ... la complexit� pour la complexit� n'aurait rien apport�).
Allez, sur ce, je vais me laisser tenter par un p'tit Columbo ... et prendre une douche ... Quoi ??? tout le monde s'en fou ??? Bon ok ...
Bien � tou(te)s ... Ben oui il faut pr�voir "l'autre sexe" aussi ;-)
JM.
_________________________________________________________________
--
Avec i-mode, vivez une toute nouvelle experience de la communication et des services en ligne. Plus d�info sur http://www.imode.be
CyberCafe 2.0 <http://www.cybercafe.tv> Chaque Mardi 19h15 sur La 2!
Desabonnement par email : <mailto:[EMAIL PROTECTED]>
