Ca fait des années que tous les sites techniques (non Mac) démontrent la
supériorité d'un RISC IBM à tout point de vue. Alors j'espère
sérieusement que si ça se fait, c'est qu'Intel a un truc dans les
tiroir. Qu'ils ne nous refilent pas ces saloperies de centrino...
Mais c'est vrai que l'essentiel, c'est l'OS. Et tant qu'Apple continuera
à assurer, je resterai fidèle.
Ce qui me travaille, c'est que je ne suis pas certain que la raison
avancé par Steve soit vraie (pb avec IBM et tout ça).
Si ma mémoire est bonne (n'hésitez pas à corriger), lors de la
présentation du Mac mini, il avait dit qu'ils avaient une stratégie de
reconquête du marché en 3 phases :
- 1 - Le couple iPod + iTunes sur PC, afin de montrer à ceux qui n'ont
pas de Mac à quel point Apple est cool et sexy (pour reprendre les
termes à la mode)
- 2 - Le Mac mini, afin que plus personne ne puisse parler de prix, et
qu'un utilisateur Wintel puisse switcher pour pas grand chose
- 3 - La 3ème étape, il a juste dit qu'on la découvrirait plus tard, et
qu'elle serait révolutionnaire.
Alors, avait-il l'intention de passer Intel depuis longtemps ? Auquel
cas les raisons avancées, même si elles ont un fond de vérité, ne l'ont
été que pour faire avaler la pilule aux macounets.
Pour être "pire", est-ce que ça n'aurait pas été fait en accord avec
IBM, qui finalement n'a peut-être pas l'intention de s'investir pour "si
peu" ?
On Fri, 10 Jun 2005 13:42:15 +0200, Patrick Stadelmann wrote:
In article , Grrrr wrote:
Il n'est pas si difficile de faire du code portable et utilisable pour toutes les architectures communes (x86, PPC, ARM, MIPS, sh, par ex).
"pas si difficile" ne veut pas dire facile. Ton code théoriquement portable aura en fait des bugs qui n'apparaîtront qu'à l'exécution sur une autre plateforme. Il ne suffit donc pas d'écrire du code portable, il faut encore le tester et le débugger sur l'autre plateforme.
Bof, je viens de passer une semaine à porter un environnement complet sur une nouvelle architecture. Ce n'est pourtant pas du code merveilleux, il y en a quelques centaines de milliers de lignes, mais au bout d'une semaine (tout seul), j'ai toute la base de mon environnement qui marche à nouveau. Et pourtant, je suis dans le cas le plus défavorable: un CPU que je ne connais pas ou très peu et une carte mère en développement pas encore débuggée (donc je débugge le hardware en même temps que le soft...). Donc, quand on me dit que c'est difficile, c'est le code doit vraiment être pourri...
Les problèmes se situent généralement dans le noyau et la libc. Pour le reste, si on code pas trop crade, il suffit généralement de recompiler.
En général, oui. Mais il y a plein de cas particulier où le comportement sera différent. Dès que tu bosses avec des nombres flottant par exemple, le code donnera facilement des résultats différents.
Comme signalé, s'il y a des écarts dans les flottants, c'est soit que le CPU est buggé, soit que celui qui a écrit le code ne sait pas se servir des flottants. Tous les CPU donnent _exactement_ les mêmes résultats en flottant, vu qu'ils suivent tous la norme IEEE. Et même en émulation flotante, le fait est qu'il peut y avoir des écarts (pour des raisons de performances, on utilise rarement les émulations "bit exact"), mais si ils posent des problèmes, il est plus sur de jeter le code et de le ré-écrire.
Et rien que réoptimiser pour SSE au lieu d'AltiVec, c'est un sacré boulot.
Non. C'est à ça que servent les librairies. Il faut écrire la lib une fois pour chaque architecture, et l'utiliser dans les programmes.
Dans la cas du port de Mac OS X sur Intel, il a bien fallu réécrire cette librairie !
Lesroutines de bas niveau, oui. Mais ces routines sont très petites (ou alors, c'est mal codé) et le portage est simple vu que les principes de bases de l'Altivec et du SSE sont les mêmes. Ca doit représenter quelques jours de travail pour une personne motivée. A la rigueur, le plus c'est de bien tester et surtout de ne pas oublier de tester les fameux cas aux limites, sinon gare aux bugs surprise... Mais, en principe quand on a ce genre de librairie, on a aussi un programme de test plus ou moins automatisé, donc les bugs sont vites trouvés.
Ca localise les problèmes et les rends très simple à résoudre (une telle lib est généralement assez petite pour être portée en très peu de temps sur une nouvelle architecture).
Selon le niveau d'optimisation recherché, pour du code vectoriel, non.
C'est nouveau, ça... Il y a à tout casser ~ une centaine de fonctions de bases codées en assembleur (inline, si on privilégie la performance) que ce soit pour l'Altivec ou le SSE. Ensuite, les API sont entièrement en C, et n'ont pas de raison de changer entre les implémentations. Donc, non, le fait de faire du SIMD n'impose pas d'avoir du code difficile à porter.
On Fri, 10 Jun 2005 13:42:15 +0200, Patrick Stadelmann wrote:
In article <pan.2005.06.10.11.10.41.622944@Grrr.org.invalid>,
Grrrr <Grrr@Grrr.org.invalid> wrote:
Il n'est pas si difficile de faire du code portable et utilisable pour
toutes les architectures communes (x86, PPC, ARM, MIPS, sh, par ex).
"pas si difficile" ne veut pas dire facile. Ton code théoriquement
portable aura en fait des bugs qui n'apparaîtront qu'à l'exécution sur
une autre plateforme. Il ne suffit donc pas d'écrire du code portable,
il faut encore le tester et le débugger sur l'autre plateforme.
Bof, je viens de passer une semaine à porter un environnement complet sur
une nouvelle architecture. Ce n'est pourtant pas du code merveilleux, il y
en a quelques centaines de milliers de lignes, mais au bout d'une semaine
(tout seul), j'ai toute la base de mon environnement qui marche à
nouveau. Et pourtant, je suis dans le cas le plus défavorable: un CPU
que je ne connais pas ou très peu et une carte mère en développement
pas encore débuggée (donc je débugge le hardware en même temps que le
soft...).
Donc, quand on me dit que c'est difficile, c'est le code doit vraiment
être pourri...
Les problèmes se situent généralement dans le noyau et la libc.
Pour le reste, si on code pas trop crade, il suffit généralement de
recompiler.
En général, oui. Mais il y a plein de cas particulier où le comportement
sera différent. Dès que tu bosses avec des nombres flottant par exemple,
le code donnera facilement des résultats différents.
Comme signalé, s'il y a des écarts dans les flottants, c'est soit que le
CPU est buggé, soit que celui qui a écrit le code ne sait pas se servir
des flottants.
Tous les CPU donnent _exactement_ les mêmes résultats en flottant, vu
qu'ils suivent tous la norme IEEE. Et même en émulation flotante, le
fait est qu'il peut y avoir des écarts (pour des raisons de performances,
on utilise rarement les émulations "bit exact"), mais si ils posent des
problèmes, il est plus sur de jeter le code et de le ré-écrire.
Et rien que réoptimiser pour SSE au lieu d'AltiVec,
c'est un sacré boulot.
Non. C'est à ça que servent les librairies. Il faut écrire la lib une
fois pour chaque architecture, et l'utiliser dans les programmes.
Dans la cas du port de Mac OS X sur Intel, il a bien fallu réécrire
cette librairie !
Lesroutines de bas niveau, oui. Mais ces routines sont très petites (ou
alors, c'est mal codé) et le portage est simple vu que les principes de
bases de l'Altivec et du SSE sont les mêmes.
Ca doit représenter quelques jours de travail pour une personne motivée.
A la rigueur, le plus c'est de bien tester et surtout de ne pas oublier de
tester les fameux cas aux limites, sinon gare aux bugs surprise...
Mais, en principe quand on a ce genre de librairie, on a aussi un
programme de test plus ou moins automatisé, donc les bugs sont vites
trouvés.
Ca localise les problèmes et les rends très simple à résoudre (une
telle lib est généralement assez petite pour être portée en très peu
de temps sur une nouvelle architecture).
Selon le niveau d'optimisation recherché, pour du code vectoriel, non.
C'est nouveau, ça... Il y a à tout casser ~ une centaine de fonctions de
bases codées en assembleur (inline, si on privilégie la performance) que
ce soit pour l'Altivec ou le SSE. Ensuite, les API sont entièrement en C,
et n'ont pas de raison de changer entre les implémentations.
Donc, non, le fait de faire du SIMD n'impose pas d'avoir du code difficile
à porter.
On Fri, 10 Jun 2005 13:42:15 +0200, Patrick Stadelmann wrote:
In article , Grrrr wrote:
Il n'est pas si difficile de faire du code portable et utilisable pour toutes les architectures communes (x86, PPC, ARM, MIPS, sh, par ex).
"pas si difficile" ne veut pas dire facile. Ton code théoriquement portable aura en fait des bugs qui n'apparaîtront qu'à l'exécution sur une autre plateforme. Il ne suffit donc pas d'écrire du code portable, il faut encore le tester et le débugger sur l'autre plateforme.
Bof, je viens de passer une semaine à porter un environnement complet sur une nouvelle architecture. Ce n'est pourtant pas du code merveilleux, il y en a quelques centaines de milliers de lignes, mais au bout d'une semaine (tout seul), j'ai toute la base de mon environnement qui marche à nouveau. Et pourtant, je suis dans le cas le plus défavorable: un CPU que je ne connais pas ou très peu et une carte mère en développement pas encore débuggée (donc je débugge le hardware en même temps que le soft...). Donc, quand on me dit que c'est difficile, c'est le code doit vraiment être pourri...
Les problèmes se situent généralement dans le noyau et la libc. Pour le reste, si on code pas trop crade, il suffit généralement de recompiler.
En général, oui. Mais il y a plein de cas particulier où le comportement sera différent. Dès que tu bosses avec des nombres flottant par exemple, le code donnera facilement des résultats différents.
Comme signalé, s'il y a des écarts dans les flottants, c'est soit que le CPU est buggé, soit que celui qui a écrit le code ne sait pas se servir des flottants. Tous les CPU donnent _exactement_ les mêmes résultats en flottant, vu qu'ils suivent tous la norme IEEE. Et même en émulation flotante, le fait est qu'il peut y avoir des écarts (pour des raisons de performances, on utilise rarement les émulations "bit exact"), mais si ils posent des problèmes, il est plus sur de jeter le code et de le ré-écrire.
Et rien que réoptimiser pour SSE au lieu d'AltiVec, c'est un sacré boulot.
Non. C'est à ça que servent les librairies. Il faut écrire la lib une fois pour chaque architecture, et l'utiliser dans les programmes.
Dans la cas du port de Mac OS X sur Intel, il a bien fallu réécrire cette librairie !
Lesroutines de bas niveau, oui. Mais ces routines sont très petites (ou alors, c'est mal codé) et le portage est simple vu que les principes de bases de l'Altivec et du SSE sont les mêmes. Ca doit représenter quelques jours de travail pour une personne motivée. A la rigueur, le plus c'est de bien tester et surtout de ne pas oublier de tester les fameux cas aux limites, sinon gare aux bugs surprise... Mais, en principe quand on a ce genre de librairie, on a aussi un programme de test plus ou moins automatisé, donc les bugs sont vites trouvés.
Ca localise les problèmes et les rends très simple à résoudre (une telle lib est généralement assez petite pour être portée en très peu de temps sur une nouvelle architecture).
Selon le niveau d'optimisation recherché, pour du code vectoriel, non.
C'est nouveau, ça... Il y a à tout casser ~ une centaine de fonctions de bases codées en assembleur (inline, si on privilégie la performance) que ce soit pour l'Altivec ou le SSE. Ensuite, les API sont entièrement en C, et n'ont pas de raison de changer entre les implémentations. Donc, non, le fait de faire du SIMD n'impose pas d'avoir du code difficile à porter.
Patrick Stadelmann
In article , Grrrr wrote:
Bof, je viens de passer une semaine à porter un environnement complet sur une nouvelle architecture.
Oui, et il y avait 20 lignes à changer dans Mathematica pour faire le portage. Bien sûr, on oublie de préciser que Mathematica est multiplateforme depuis des lustres, donc le gros du boulot a déjà été fait. Mais ce n'était pas aussi simple pour Mac OS X. Steve nous dit que dès le premier jour, il a été pensé portable, pourtant le Finder par exemple utilisait PowerPlant et était compilé avec CodeWarrior parce qu'avant d'être facilement portable sur Intel, il devait surtout pouvoir hériter de pas mal de code existant du Finder de Mac OS X.
Comme signalé, s'il y a des écarts dans les flottants, c'est soit que le CPU est buggé, soit que celui qui a écrit le code ne sait pas se servir des flottants. Tous les CPU donnent _exactement_ les mêmes résultats en flottant, vu qu'ils suivent tous la norme IEEE.
C'est fort possible. Reste que tu peux avoir du code qui se comporte différemment. Quand tu écris du code, tu essaies de la faire sans bugs, normalement. Est-ce que ça suffit à faire du code bug-free ? Non, il faudra toujours débugguer. Tout ce que je dis c'est que c'est la même chose pour du code portable. On essaie de faire du code portable, on débug sur une plateforme, mais il y aura des bouts de code qui ne causeront des bugs que sur une autre plateforme. Même si ce n'est qu'une ligne de code à corriger, en débug le souci c'est souvent d'identifier précisément le bug, d'où coût en ressources et en temps, multiplié par le nombre de bug... on en revient à ce que je disais au début.
Lesroutines de bas niveau, oui. Mais ces routines sont très petites (ou alors, c'est mal codé) et le portage est simple vu que les principes de bases de l'Altivec et du SSE sont les mêmes.
Mais l'architecture des deux est très différentes, le coût de chaque opération également.
Ca doit représenter quelques jours de travail pour une personne motivée.
Déjà pour revoir le séquencement et l'allocation de ressources ça risque de prendra plus que ça.
Mais, en principe quand on a ce genre de librairie, on a aussi un programme de test plus ou moins automatisé, donc les bugs sont vites trouvés.
Ce qui n'est pas automatique, c'est l'optimisation.
Bon, on va s'arrêter là, hein ? Je maintiens ce que j'ai écrit dans mon premier message dans ce fil, libre à toi de ne pas être d'accord.
Patrick -- Patrick Stadelmann
In article <pan.2005.06.10.23.54.22.811486@Grrr.org.invalid>,
Grrrr <Grrr@Grrr.org.invalid> wrote:
Bof, je viens de passer une semaine à porter un environnement complet sur
une nouvelle architecture.
Oui, et il y avait 20 lignes à changer dans Mathematica pour faire le
portage. Bien sûr, on oublie de préciser que Mathematica est
multiplateforme depuis des lustres, donc le gros du boulot a déjà été
fait. Mais ce n'était pas aussi simple pour Mac OS X. Steve nous dit que
dès le premier jour, il a été pensé portable, pourtant le Finder par
exemple utilisait PowerPlant et était compilé avec CodeWarrior parce
qu'avant d'être facilement portable sur Intel, il devait surtout pouvoir
hériter de pas mal de code existant du Finder de Mac OS X.
Comme signalé, s'il y a des écarts dans les flottants, c'est soit que le
CPU est buggé, soit que celui qui a écrit le code ne sait pas se servir
des flottants.
Tous les CPU donnent _exactement_ les mêmes résultats en flottant, vu
qu'ils suivent tous la norme IEEE.
C'est fort possible. Reste que tu peux avoir du code qui se comporte
différemment. Quand tu écris du code, tu essaies de la faire sans bugs,
normalement. Est-ce que ça suffit à faire du code bug-free ? Non, il
faudra toujours débugguer. Tout ce que je dis c'est que c'est la même
chose pour du code portable. On essaie de faire du code portable, on
débug sur une plateforme, mais il y aura des bouts de code qui ne
causeront des bugs que sur une autre plateforme. Même si ce n'est qu'une
ligne de code à corriger, en débug le souci c'est souvent d'identifier
précisément le bug, d'où coût en ressources et en temps, multiplié par
le nombre de bug... on en revient à ce que je disais au début.
Lesroutines de bas niveau, oui. Mais ces routines sont très petites (ou
alors, c'est mal codé) et le portage est simple vu que les principes de
bases de l'Altivec et du SSE sont les mêmes.
Mais l'architecture des deux est très différentes, le coût de chaque
opération également.
Ca doit représenter quelques jours de travail pour une personne motivée.
Déjà pour revoir le séquencement et l'allocation de ressources ça risque
de prendra plus que ça.
Mais, en principe quand on a ce genre de librairie, on a aussi un
programme de test plus ou moins automatisé, donc les bugs sont vites
trouvés.
Ce qui n'est pas automatique, c'est l'optimisation.
Bon, on va s'arrêter là, hein ? Je maintiens ce que j'ai écrit dans mon
premier message dans ce fil, libre à toi de ne pas être d'accord.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Bof, je viens de passer une semaine à porter un environnement complet sur une nouvelle architecture.
Oui, et il y avait 20 lignes à changer dans Mathematica pour faire le portage. Bien sûr, on oublie de préciser que Mathematica est multiplateforme depuis des lustres, donc le gros du boulot a déjà été fait. Mais ce n'était pas aussi simple pour Mac OS X. Steve nous dit que dès le premier jour, il a été pensé portable, pourtant le Finder par exemple utilisait PowerPlant et était compilé avec CodeWarrior parce qu'avant d'être facilement portable sur Intel, il devait surtout pouvoir hériter de pas mal de code existant du Finder de Mac OS X.
Comme signalé, s'il y a des écarts dans les flottants, c'est soit que le CPU est buggé, soit que celui qui a écrit le code ne sait pas se servir des flottants. Tous les CPU donnent _exactement_ les mêmes résultats en flottant, vu qu'ils suivent tous la norme IEEE.
C'est fort possible. Reste que tu peux avoir du code qui se comporte différemment. Quand tu écris du code, tu essaies de la faire sans bugs, normalement. Est-ce que ça suffit à faire du code bug-free ? Non, il faudra toujours débugguer. Tout ce que je dis c'est que c'est la même chose pour du code portable. On essaie de faire du code portable, on débug sur une plateforme, mais il y aura des bouts de code qui ne causeront des bugs que sur une autre plateforme. Même si ce n'est qu'une ligne de code à corriger, en débug le souci c'est souvent d'identifier précisément le bug, d'où coût en ressources et en temps, multiplié par le nombre de bug... on en revient à ce que je disais au début.
Lesroutines de bas niveau, oui. Mais ces routines sont très petites (ou alors, c'est mal codé) et le portage est simple vu que les principes de bases de l'Altivec et du SSE sont les mêmes.
Mais l'architecture des deux est très différentes, le coût de chaque opération également.
Ca doit représenter quelques jours de travail pour une personne motivée.
Déjà pour revoir le séquencement et l'allocation de ressources ça risque de prendra plus que ça.
Mais, en principe quand on a ce genre de librairie, on a aussi un programme de test plus ou moins automatisé, donc les bugs sont vites trouvés.
Ce qui n'est pas automatique, c'est l'optimisation.
Bon, on va s'arrêter là, hein ? Je maintiens ce que j'ai écrit dans mon premier message dans ce fil, libre à toi de ne pas être d'accord.
Patrick -- Patrick Stadelmann
verdoux
Milosz Hermanowicz wrote:
surtout qu'il a gardé en interne depuis le début de MacOS X Rapshody une équipe d'ingénieurs chargé de maintenir une version Intel d'OS X. Lors de la keynote, il a même dit que MacOS X est cross-platform depuis l'origine....
Jusqu'à la sortie de Mac OS X, SJ utilisait toujours un portable PC avec NextStep. Après il a sans doute utilisé OS X, mais on sait pas sur quelle machine ;)
Milosz Hermanowicz wrote:
surtout qu'il a gardé en interne depuis le début de MacOS X Rapshody une
équipe d'ingénieurs chargé de maintenir une version Intel d'OS X. Lors
de la keynote, il a même dit que MacOS X est cross-platform depuis
l'origine....
Jusqu'à la sortie de Mac OS X, SJ utilisait toujours un portable PC avec
NextStep.
Après il a sans doute utilisé OS X, mais on sait pas sur quelle machine ;)
surtout qu'il a gardé en interne depuis le début de MacOS X Rapshody une équipe d'ingénieurs chargé de maintenir une version Intel d'OS X. Lors de la keynote, il a même dit que MacOS X est cross-platform depuis l'origine....
Jusqu'à la sortie de Mac OS X, SJ utilisait toujours un portable PC avec NextStep. Après il a sans doute utilisé OS X, mais on sait pas sur quelle machine ;)
ludovic.cynomys
Serge Pajak wrote:
Mais ces rumeurs ne sont pas allées très loin tant la transition paraissait impensable.
Oui, voilà ! On *savait* effectivement qu'il devait bien exister une version d'OS X tournant sur processeur Intel... -- mais on pensait que c'était pour EUX (porter Mac OS X pour les pécéistes) -- et pas pour NOUS (mettre un un processeur Intel sur NOS bécanes)
D'où le choc ;->
-- Qu'est-ce qu'on fout là tous, dans ce petit coin d'Univers ?
Serge Pajak <serge@alussinan.org> wrote:
Mais ces rumeurs ne sont pas allées très loin tant la transition
paraissait impensable.
Oui, voilà !
On *savait* effectivement qu'il devait bien exister une version d'OS X
tournant sur processeur Intel...
-- mais on pensait que c'était pour EUX (porter Mac OS X pour les
pécéistes)
-- et pas pour NOUS (mettre un un processeur Intel sur NOS bécanes)
D'où le choc ;->
--
Qu'est-ce qu'on fout là tous, dans ce petit coin d'Univers ?
Mais ces rumeurs ne sont pas allées très loin tant la transition paraissait impensable.
Oui, voilà ! On *savait* effectivement qu'il devait bien exister une version d'OS X tournant sur processeur Intel... -- mais on pensait que c'était pour EUX (porter Mac OS X pour les pécéistes) -- et pas pour NOUS (mettre un un processeur Intel sur NOS bécanes)
D'où le choc ;->
-- Qu'est-ce qu'on fout là tous, dans ce petit coin d'Univers ?
lists
Pierre-Alain Dorange wrote:
5/ DRM. Je ne pense pas non plus que ça pèse vraiment dans la balance.
J'espère que tu as raison.
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
5/ DRM.
Je ne pense pas non plus que ça pèse vraiment dans la balance.
J'espère que tu as raison.
--
R: Parce que ça renverse bêtement l'ordre naturel de lecture!
Q: Mais pourquoi citer en fin d'article est-il si effroyable?
R: Citer en fin d'article
Q: Quelle est la chose la plus désagréable sur les groupes de news?
5/ DRM. Je ne pense pas non plus que ça pèse vraiment dans la balance.
J'espère que tu as raison.
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
francois.jacquemin
JmG wrote:
Sur ce point là, à force d'encenser aveuglément Steve depuis des années, les Macounets devraient penser que dans ce domaine comme dans bien d'autres bien plus proches de nous en France, c'est toujours pareil: il faut mentir, toujours et tout le temps, ce qui compte, c'est la façon de présenter les mensonges.
Moi, je ne vois aucun mensonge. Je ne distingue pas bien non plus la légitimité ou la nécessité de mentir. Je ne pense pas que le patron d'Apple doive à quiconque d'autre que son conseil d'administration tout l'éclairage sur des décisions stratégiques qui ont été prises à froid, collectivement, et d'une manière bien préparée.
À sa clientèle, il doit simplement donner les éléments qui lui permettent d'être rassurée sur la rationalité des choix et la pérennité de la marque et du choix Apple. -- F. Jacquemin
JmG <JMGB@antipourrielsLACASE.COM> wrote:
Sur ce point là, à force d'encenser aveuglément Steve depuis des années,
les Macounets devraient penser que dans ce domaine comme dans bien
d'autres bien plus proches de nous en France, c'est toujours pareil: il
faut mentir, toujours et tout le temps, ce qui compte, c'est la façon de
présenter les mensonges.
Moi, je ne vois aucun mensonge. Je ne distingue pas bien non plus la
légitimité ou la nécessité de mentir. Je ne pense pas que le patron
d'Apple doive à quiconque d'autre que son conseil d'administration tout
l'éclairage sur des décisions stratégiques qui ont été prises à froid,
collectivement, et d'une manière bien préparée.
À sa clientèle, il doit simplement donner les éléments qui lui
permettent d'être rassurée sur la rationalité des choix et la pérennité
de la marque et du choix Apple.
--
F. Jacquemin
Sur ce point là, à force d'encenser aveuglément Steve depuis des années, les Macounets devraient penser que dans ce domaine comme dans bien d'autres bien plus proches de nous en France, c'est toujours pareil: il faut mentir, toujours et tout le temps, ce qui compte, c'est la façon de présenter les mensonges.
Moi, je ne vois aucun mensonge. Je ne distingue pas bien non plus la légitimité ou la nécessité de mentir. Je ne pense pas que le patron d'Apple doive à quiconque d'autre que son conseil d'administration tout l'éclairage sur des décisions stratégiques qui ont été prises à froid, collectivement, et d'une manière bien préparée.
À sa clientèle, il doit simplement donner les éléments qui lui permettent d'être rassurée sur la rationalité des choix et la pérennité de la marque et du choix Apple. -- F. Jacquemin
sanji
Jean-Daniel SEYRES wrote:
reconquête du marché en 3 phases : - 1 - Le couple iPod + iTunes sur PC, afin de montrer à ceux qui n'ont pas de Mac à quel point Apple est cool et sexy (pour reprendre les termes à la mode) - 2 - Le Mac mini, afin que plus personne ne puisse parler de prix, et qu'un utilisateur Wintel puisse switcher pour pas grand chose - 3 - La 3ème étape, il a juste dit qu'on la découvrirait plus tard, et qu'elle serait révolutionnaire.
Alors, avait-il l'intention de passer Intel depuis longtemps ? Auquel cas les raisons avancées, même si elles ont un fond de vérité, ne l'ont été que pour faire avaler la pilule aux macounets. Pour être "pire", est-ce que ça n'aurait pas été fait en accord avec IBM, qui finalement n'a peut-être pas l'intention de s'investir pour "si peu" ?
Je vous l'disais... <http://www.pbs.org/cringely/pulpit/pulpit20050609.html>
reconquête du marché en 3 phases :
- 1 - Le couple iPod + iTunes sur PC, afin de montrer à ceux qui n'ont
pas de Mac à quel point Apple est cool et sexy (pour reprendre les
termes à la mode)
- 2 - Le Mac mini, afin que plus personne ne puisse parler de prix, et
qu'un utilisateur Wintel puisse switcher pour pas grand chose
- 3 - La 3ème étape, il a juste dit qu'on la découvrirait plus tard, et
qu'elle serait révolutionnaire.
Alors, avait-il l'intention de passer Intel depuis longtemps ? Auquel
cas les raisons avancées, même si elles ont un fond de vérité, ne l'ont
été que pour faire avaler la pilule aux macounets.
Pour être "pire", est-ce que ça n'aurait pas été fait en accord avec
IBM, qui finalement n'a peut-être pas l'intention de s'investir pour "si
peu" ?
Je vous l'disais...
<http://www.pbs.org/cringely/pulpit/pulpit20050609.html>
reconquête du marché en 3 phases : - 1 - Le couple iPod + iTunes sur PC, afin de montrer à ceux qui n'ont pas de Mac à quel point Apple est cool et sexy (pour reprendre les termes à la mode) - 2 - Le Mac mini, afin que plus personne ne puisse parler de prix, et qu'un utilisateur Wintel puisse switcher pour pas grand chose - 3 - La 3ème étape, il a juste dit qu'on la découvrirait plus tard, et qu'elle serait révolutionnaire.
Alors, avait-il l'intention de passer Intel depuis longtemps ? Auquel cas les raisons avancées, même si elles ont un fond de vérité, ne l'ont été que pour faire avaler la pilule aux macounets. Pour être "pire", est-ce que ça n'aurait pas été fait en accord avec IBM, qui finalement n'a peut-être pas l'intention de s'investir pour "si peu" ?
Je vous l'disais... <http://www.pbs.org/cringely/pulpit/pulpit20050609.html>
-- Sanji iChat : jdseyres
Schmurtz
Grrrr wrote:
On Fri, 10 Jun 2005 12:09:19 +0200, Patrick Stadelmann wrote:
Même avec du bête code algorithmique, le passage de PC à Mac n'est pas toujours évident. Compiler le soft c'est une chose, encore faut-il qu'il fonctionne correctement, ça n'est pas immédiat.
Il n'est pas si difficile de faire du code portable et utilisable pour toutes les architectures communes (x86, PPC, ARM, MIPS, sh, par ex). Les problèmes se situent généralement dans le noyau et la libc. Pour le reste, si on code pas trop crade, il suffit généralement de recompiler.
Tu oublies deux choses :
- les programmes évolués faisant beaucoup de traitement de signal (son ou image) utilisent les instructions Altivec / SSE spécifiquent aux processeurs PPC / x86. Aucun langage à ma connaissance ne propose de système générique pour utiliser ces instructions, il est donc nécessaire d'utiliser des extensions pour se servir des ces instructions. Et bien sûr ses extensions sont différentes pour altivec et sse et sont non facilement convertibles de l'un dans l'autre.
- les PPC sont des processeurs big endian et les x86 sont little endian. Ça veux dire en gros que si un programme compilé pour PPC écrit 0x12345678 dans un fichier, le même programme compilé pour x86 lisant le fichier créer par sa version PPC lira 0x78563412. C'est trivial à résoudre en théorie, mais dans la pratique c'est beaucoup plus compliqué (il y a des milliers de lignes de code à modifier).
-- Schmurtz
Grrrr <Grrr@Grrr.org.invalid> wrote:
On Fri, 10 Jun 2005 12:09:19 +0200, Patrick Stadelmann wrote:
Même avec du bête code algorithmique, le passage de PC à Mac n'est pas
toujours évident. Compiler le soft c'est une chose, encore faut-il qu'il
fonctionne correctement, ça n'est pas immédiat.
Il n'est pas si difficile de faire du code portable et utilisable pour
toutes les architectures communes (x86, PPC, ARM, MIPS, sh, par ex).
Les problèmes se situent généralement dans le noyau et la libc.
Pour le reste, si on code pas trop crade, il suffit généralement de
recompiler.
Tu oublies deux choses :
- les programmes évolués faisant beaucoup de traitement de signal (son
ou image) utilisent les instructions Altivec / SSE spécifiquent aux
processeurs PPC / x86. Aucun langage à ma connaissance ne propose de
système générique pour utiliser ces instructions, il est donc nécessaire
d'utiliser des extensions pour se servir des ces instructions. Et bien
sûr ses extensions sont différentes pour altivec et sse et sont non
facilement convertibles de l'un dans l'autre.
- les PPC sont des processeurs big endian et les x86 sont little endian.
Ça veux dire en gros que si un programme compilé pour PPC écrit
0x12345678 dans un fichier, le même programme compilé pour x86 lisant le
fichier créer par sa version PPC lira 0x78563412. C'est trivial à
résoudre en théorie, mais dans la pratique c'est beaucoup plus compliqué
(il y a des milliers de lignes de code à modifier).
On Fri, 10 Jun 2005 12:09:19 +0200, Patrick Stadelmann wrote:
Même avec du bête code algorithmique, le passage de PC à Mac n'est pas toujours évident. Compiler le soft c'est une chose, encore faut-il qu'il fonctionne correctement, ça n'est pas immédiat.
Il n'est pas si difficile de faire du code portable et utilisable pour toutes les architectures communes (x86, PPC, ARM, MIPS, sh, par ex). Les problèmes se situent généralement dans le noyau et la libc. Pour le reste, si on code pas trop crade, il suffit généralement de recompiler.
Tu oublies deux choses :
- les programmes évolués faisant beaucoup de traitement de signal (son ou image) utilisent les instructions Altivec / SSE spécifiquent aux processeurs PPC / x86. Aucun langage à ma connaissance ne propose de système générique pour utiliser ces instructions, il est donc nécessaire d'utiliser des extensions pour se servir des ces instructions. Et bien sûr ses extensions sont différentes pour altivec et sse et sont non facilement convertibles de l'un dans l'autre.
- les PPC sont des processeurs big endian et les x86 sont little endian. Ça veux dire en gros que si un programme compilé pour PPC écrit 0x12345678 dans un fichier, le même programme compilé pour x86 lisant le fichier créer par sa version PPC lira 0x78563412. C'est trivial à résoudre en théorie, mais dans la pratique c'est beaucoup plus compliqué (il y a des milliers de lignes de code à modifier).
-- Schmurtz
Saïd
Schmurtz :
Grrrr wrote:
On Fri, 10 Jun 2005 12:09:19 +0200, Patrick Stadelmann wrote:
Même avec du bête code algorithmique, le passage de PC à Mac n'est pas toujours évident. Compiler le soft c'est une chose, encore faut-il qu'il fonctionne correctement, ça n'est pas immédiat.
Il n'est pas si difficile de faire du code portable et utilisable pour toutes les architectures communes (x86, PPC, ARM, MIPS, sh, par ex). Les problèmes se situent généralement dans le noyau et la libc. Pour le reste, si on code pas trop crade, il suffit généralement de recompiler.
- les PPC sont des processeurs big endian et les x86 sont little endian. Ça veux dire en gros que si un programme compilé pour PPC écrit 0x12345678 dans un fichier, le même programme compilé pour x86 lisant le fichier créer par sa version PPC lira 0x78563412. C'est trivial à résoudre en théorie, mais dans la pratique c'est beaucoup plus compliqué (il y a des milliers de lignes de code à modifier).
C'est que le programme est mal ecrit. Ca rentre dans la categorie du code crade. En C++ il suffit de faire v >> file; pour ecrire proprement et portablement. En tout cas c'est un zélote de C++ qui m'a explique ca. Perso, je reste au C (dans l'espoir d'etre immortel->signature ;-) ).
-- Saïd. C programmers never die - they're just cast into void.
Schmurtz :
Grrrr <Grrr@Grrr.org.invalid> wrote:
On Fri, 10 Jun 2005 12:09:19 +0200, Patrick Stadelmann wrote:
Même avec du bête code algorithmique, le passage de PC à Mac n'est pas
toujours évident. Compiler le soft c'est une chose, encore faut-il qu'il
fonctionne correctement, ça n'est pas immédiat.
Il n'est pas si difficile de faire du code portable et utilisable pour
toutes les architectures communes (x86, PPC, ARM, MIPS, sh, par ex).
Les problèmes se situent généralement dans le noyau et la libc.
Pour le reste, si on code pas trop crade, il suffit généralement de
recompiler.
- les PPC sont des processeurs big endian et les x86 sont little endian.
Ça veux dire en gros que si un programme compilé pour PPC écrit
0x12345678 dans un fichier, le même programme compilé pour x86 lisant le
fichier créer par sa version PPC lira 0x78563412. C'est trivial à
résoudre en théorie, mais dans la pratique c'est beaucoup plus compliqué
(il y a des milliers de lignes de code à modifier).
C'est que le programme est mal ecrit. Ca rentre dans la categorie du code
crade. En C++ il suffit de faire v >> file; pour ecrire proprement et
portablement. En tout cas c'est un zélote de C++ qui m'a explique ca.
Perso, je reste au C (dans l'espoir d'etre immortel->signature ;-) ).
--
Saïd.
C programmers never die - they're just cast into void.
On Fri, 10 Jun 2005 12:09:19 +0200, Patrick Stadelmann wrote:
Même avec du bête code algorithmique, le passage de PC à Mac n'est pas toujours évident. Compiler le soft c'est une chose, encore faut-il qu'il fonctionne correctement, ça n'est pas immédiat.
Il n'est pas si difficile de faire du code portable et utilisable pour toutes les architectures communes (x86, PPC, ARM, MIPS, sh, par ex). Les problèmes se situent généralement dans le noyau et la libc. Pour le reste, si on code pas trop crade, il suffit généralement de recompiler.
- les PPC sont des processeurs big endian et les x86 sont little endian. Ça veux dire en gros que si un programme compilé pour PPC écrit 0x12345678 dans un fichier, le même programme compilé pour x86 lisant le fichier créer par sa version PPC lira 0x78563412. C'est trivial à résoudre en théorie, mais dans la pratique c'est beaucoup plus compliqué (il y a des milliers de lignes de code à modifier).
C'est que le programme est mal ecrit. Ca rentre dans la categorie du code crade. En C++ il suffit de faire v >> file; pour ecrire proprement et portablement. En tout cas c'est un zélote de C++ qui m'a explique ca. Perso, je reste au C (dans l'espoir d'etre immortel->signature ;-) ).
-- Saïd. C programmers never die - they're just cast into void.
Schmurtz
Saïd wrote:
C'est que le programme est mal ecrit. Ca rentre dans la categorie du code crade. En C++ il suffit de faire v >> file; pour ecrire proprement et portablement. En tout cas c'est un zélote de C++ qui m'a explique ca. Perso, je reste au C (dans l'espoir d'etre immortel->signature ;-) ).
T'an connais beaucoup des gens qui utilisent les libs standards c++ à chaque fois qu'ils ont besoin de sérialiser des données ?
-- Schmurtz
Saïd <said@brian.lan> wrote:
C'est que le programme est mal ecrit. Ca rentre dans la categorie du code
crade. En C++ il suffit de faire v >> file; pour ecrire proprement et
portablement. En tout cas c'est un zélote de C++ qui m'a explique ca.
Perso, je reste au C (dans l'espoir d'etre immortel->signature ;-) ).
T'an connais beaucoup des gens qui utilisent les libs standards c++ à
chaque fois qu'ils ont besoin de sérialiser des données ?
C'est que le programme est mal ecrit. Ca rentre dans la categorie du code crade. En C++ il suffit de faire v >> file; pour ecrire proprement et portablement. En tout cas c'est un zélote de C++ qui m'a explique ca. Perso, je reste au C (dans l'espoir d'etre immortel->signature ;-) ).
T'an connais beaucoup des gens qui utilisent les libs standards c++ à chaque fois qu'ils ont besoin de sérialiser des données ?
