Ca y est les premier macintel sont là... (du moins une imac intel et un
powerbook pro).
Et donc macos X pour intel aussi.
J'aimerai avoir un éclairsissement sur deux ou trois petites choses
1) si j'ai bien compris, les application peuvent être compilée pour PPC
et Intel via Xcode (du moins en cocoa). Mais certaines ne sont pas
encore passée (comme photospop). Mais elle peuvent tourner via Rosetta.
Alors ma question, est-ce que Rosetta, c'est la même chose que Classic
sur PPC (une sorte d'émulation) ou bien est-ce totalement transparent
pour l'utilisateur ?
2) En combien de temps pensez vous que nous aurons les applications
principales en version native intel (histoire de planifié mon switch) ?
En tous cas Mac OS X pour ces machines-là, sous Intel, oui.
1) si j'ai bien compris, les application peuvent être compilée pour PPC et Intel via Xcode
Oui
(du moins en cocoa).
Non. Aucune discrimination du framework utilisé là. Cocoa, Carbon, même combat cette-fois ci.
Mais certaines ne sont pas encore passée (comme photospop). Mais elle peuvent tourner via Rosetta.
La majorité oui. Il y a des exclusions (code spécifique G5, plugins d'applications [comme les Preferences Pane qui sont des plugins de System Preferences, les elements de Menu contextuels, etc], et d'autres
Alors ma question, est-ce que Rosetta, c'est la même chose que Classic sur PPC (une sorte d'émulation) ou bien est-ce totalement transparent pour l'utilisateur ?
C'est transparent. C'est proche (dans sa transparence et dans son utilisation de tous les jours) de l'émulation 68K qu'on avait lors de la transition vers le PowerPC en 94: pas moyen de se rendre compte rapidement si ça tourne nativement ou de manière émulée.
2) En combien de temps pensez vous que nous aurons les applications principales en version native intel (histoire de planifié mon switch) ?
Cela dépendra de la réactivité de l'entreprise et de ses priorités...
-- Stephane
David Remacle (Clampin) wrote:
Et donc macos X pour intel aussi.
En tous cas Mac OS X pour ces machines-là, sous Intel, oui.
1) si j'ai bien compris, les application peuvent être compilée pour PPC
et Intel via Xcode
Oui
(du moins en cocoa).
Non. Aucune discrimination du framework utilisé là. Cocoa, Carbon, même
combat cette-fois ci.
Mais certaines ne sont pas
encore passée (comme photospop). Mais elle peuvent tourner via Rosetta.
La majorité oui. Il y a des exclusions (code spécifique G5, plugins
d'applications [comme les Preferences Pane qui sont des plugins de
System Preferences, les elements de Menu contextuels, etc], et d'autres
Alors ma question, est-ce que Rosetta, c'est la même chose que Classic
sur PPC (une sorte d'émulation) ou bien est-ce totalement transparent
pour l'utilisateur ?
C'est transparent. C'est proche (dans sa transparence et dans son
utilisation de tous les jours) de l'émulation 68K qu'on avait lors de la
transition vers le PowerPC en 94: pas moyen de se rendre compte
rapidement si ça tourne nativement ou de manière émulée.
2) En combien de temps pensez vous que nous aurons les applications
principales en version native intel (histoire de planifié mon switch) ?
Cela dépendra de la réactivité de l'entreprise et de ses priorités...
En tous cas Mac OS X pour ces machines-là, sous Intel, oui.
1) si j'ai bien compris, les application peuvent être compilée pour PPC et Intel via Xcode
Oui
(du moins en cocoa).
Non. Aucune discrimination du framework utilisé là. Cocoa, Carbon, même combat cette-fois ci.
Mais certaines ne sont pas encore passée (comme photospop). Mais elle peuvent tourner via Rosetta.
La majorité oui. Il y a des exclusions (code spécifique G5, plugins d'applications [comme les Preferences Pane qui sont des plugins de System Preferences, les elements de Menu contextuels, etc], et d'autres
Alors ma question, est-ce que Rosetta, c'est la même chose que Classic sur PPC (une sorte d'émulation) ou bien est-ce totalement transparent pour l'utilisateur ?
C'est transparent. C'est proche (dans sa transparence et dans son utilisation de tous les jours) de l'émulation 68K qu'on avait lors de la transition vers le PowerPC en 94: pas moyen de se rendre compte rapidement si ça tourne nativement ou de manière émulée.
2) En combien de temps pensez vous que nous aurons les applications principales en version native intel (histoire de planifié mon switch) ?
Cela dépendra de la réactivité de l'entreprise et de ses priorités...
-- Stephane
JMGB
Stephane Madrau wrote:
Mais certaines ne sont pas encore passée (comme photospop). Mais elle peuvent tourner via Rosetta.
La majorité oui. Il y a des exclusions (code spécifique G5, plugins d'applications [comme les Preferences Pane qui sont des plugins de System Preferences, les elements de Menu contextuels, etc], et d'autres
Quand on voit que certains plugs PSD viennent seulement, il y a quelques mois, de passer "compatibles OSX" on peut se poser des questions sur les plugs "optimisés MacIntel", je pense...
On va pouvoir attendre 2 ans, je pense, avant que tout ça ne soit décanté, pour le principal seulement.
-- Le génie fait ce qu'il doit. Le talent fait ce qu'il peut. *Virer les minuscules pour me répondre*
Stephane Madrau <stephane@madrau.com> wrote:
Mais certaines ne sont pas
encore passée (comme photospop). Mais elle peuvent tourner via Rosetta.
La majorité oui. Il y a des exclusions (code spécifique G5, plugins
d'applications [comme les Preferences Pane qui sont des plugins de
System Preferences, les elements de Menu contextuels, etc], et d'autres
Quand on voit que certains plugs PSD viennent seulement, il y a quelques
mois, de passer "compatibles OSX" on peut se poser des questions sur les
plugs "optimisés MacIntel", je pense...
On va pouvoir attendre 2 ans, je pense, avant que tout ça ne soit
décanté, pour le principal seulement.
--
Le génie fait ce qu'il doit.
Le talent fait ce qu'il peut.
*Virer les minuscules pour me répondre*
Mais certaines ne sont pas encore passée (comme photospop). Mais elle peuvent tourner via Rosetta.
La majorité oui. Il y a des exclusions (code spécifique G5, plugins d'applications [comme les Preferences Pane qui sont des plugins de System Preferences, les elements de Menu contextuels, etc], et d'autres
Quand on voit que certains plugs PSD viennent seulement, il y a quelques mois, de passer "compatibles OSX" on peut se poser des questions sur les plugs "optimisés MacIntel", je pense...
On va pouvoir attendre 2 ans, je pense, avant que tout ça ne soit décanté, pour le principal seulement.
-- Le génie fait ce qu'il doit. Le talent fait ce qu'il peut. *Virer les minuscules pour me répondre*
Stephane Madrau
JmG wrote:
Quand on voit que certains plugs PSD viennent seulement, il y a quelques mois, de passer "compatibles OSX" on peut se poser des questions sur les plugs "optimisés MacIntel", je pense...
Possible.
Reste la possibilité de faire tourner les plugs ET l'application principale dans Rosetta. Aucun intérêt du point de vue de la vitesse, par contre, juste utile *si* le plugin est absolument indispensable....
C'est un inconvénient, par rapport à la transition 68K-PPC, pour laquelle on pouvait faire tourner toute combinaison (plugin 68K ou PPC sur appli PPC) et attendre plus sereinement la nouvelle version du plugin:
-- Stephane
JmG wrote:
Quand on voit que certains plugs PSD viennent seulement, il y a quelques
mois, de passer "compatibles OSX" on peut se poser des questions sur les
plugs "optimisés MacIntel", je pense...
Possible.
Reste la possibilité de faire tourner les plugs ET l'application
principale dans Rosetta. Aucun intérêt du point de vue de la vitesse,
par contre, juste utile *si* le plugin est absolument indispensable....
C'est un inconvénient, par rapport à la transition 68K-PPC, pour
laquelle on pouvait faire tourner toute combinaison (plugin 68K ou PPC
sur appli PPC) et attendre plus sereinement la nouvelle version du plugin:
Quand on voit que certains plugs PSD viennent seulement, il y a quelques mois, de passer "compatibles OSX" on peut se poser des questions sur les plugs "optimisés MacIntel", je pense...
Possible.
Reste la possibilité de faire tourner les plugs ET l'application principale dans Rosetta. Aucun intérêt du point de vue de la vitesse, par contre, juste utile *si* le plugin est absolument indispensable....
C'est un inconvénient, par rapport à la transition 68K-PPC, pour laquelle on pouvait faire tourner toute combinaison (plugin 68K ou PPC sur appli PPC) et attendre plus sereinement la nouvelle version du plugin:
-- Stephane
JMGB
Stephane Madrau wrote:
Reste la possibilité de faire tourner les plugs ET l'application principale dans Rosetta. Aucun intérêt du point de vue de la vitesse, par contre, juste utile *si* le plugin est absolument indispensable....
C'est un inconvénient, par rapport à la transition 68K-PPC, pour laquelle on pouvait faire tourner plus de combinaisons (plugin 68K ou PPC sur appli PPC) et attendre plus sereinement la nouvelle version du plugin:
Perso, je trouve de plus en plus que tous les soit-disants avantages apportés par les changements de stratégie de Cuppertino depuis quelques années nous apporte un paquet d'emmerdes diverses et variées, au fond.
A commencer par le niveau pécunier évidemment.
Mais bon... on va encore me taxer de mauvaise foi, je suis bien sûr... :)
-- Le génie fait ce qu'il doit. Le talent fait ce qu'il peut. *Virer les minuscules pour me répondre*
Stephane Madrau <stephane@madrau.com> wrote:
Reste la possibilité de faire tourner les plugs ET l'application
principale dans Rosetta. Aucun intérêt du point de vue de la vitesse,
par contre, juste utile *si* le plugin est absolument indispensable....
C'est un inconvénient, par rapport à la transition 68K-PPC, pour
laquelle on pouvait faire tourner plus de combinaisons (plugin 68K ou
PPC sur appli PPC) et attendre plus sereinement la nouvelle version du
plugin:
Perso, je trouve de plus en plus que tous les soit-disants avantages
apportés par les changements de stratégie de Cuppertino depuis quelques
années nous apporte un paquet d'emmerdes diverses et variées, au fond.
A commencer par le niveau pécunier évidemment.
Mais bon... on va encore me taxer de mauvaise foi, je suis bien sûr...
:)
--
Le génie fait ce qu'il doit.
Le talent fait ce qu'il peut.
*Virer les minuscules pour me répondre*
Reste la possibilité de faire tourner les plugs ET l'application principale dans Rosetta. Aucun intérêt du point de vue de la vitesse, par contre, juste utile *si* le plugin est absolument indispensable....
C'est un inconvénient, par rapport à la transition 68K-PPC, pour laquelle on pouvait faire tourner plus de combinaisons (plugin 68K ou PPC sur appli PPC) et attendre plus sereinement la nouvelle version du plugin:
Perso, je trouve de plus en plus que tous les soit-disants avantages apportés par les changements de stratégie de Cuppertino depuis quelques années nous apporte un paquet d'emmerdes diverses et variées, au fond.
A commencer par le niveau pécunier évidemment.
Mais bon... on va encore me taxer de mauvaise foi, je suis bien sûr... :)
-- Le génie fait ce qu'il doit. Le talent fait ce qu'il peut. *Virer les minuscules pour me répondre*
marcantispam
JmG wrote:
Stephane Madrau wrote:
Reste la possibilité de faire tourner les plugs ET l'application principale dans Rosetta. Aucun intérêt du point de vue de la vitesse, par contre, juste utile *si* le plugin est absolument indispensable....
C'est un inconvénient, par rapport à la transition 68K-PPC, pour laquelle on pouvait faire tourner plus de combinaisons (plugin 68K ou PPC sur appli PPC) et attendre plus sereinement la nouvelle version du plugin:
Perso, je trouve de plus en plus que tous les soit-disants avantages apportés par les changements de stratégie de Cuppertino depuis quelques années nous apporte un paquet d'emmerdes diverses et variées, au fond.
A commencer par le niveau pécunier évidemment.
Mais bon... on va encore me taxer de mauvaise foi, je suis bien sûr... :)
Tu sais bien que c'est ni notre genre ni celui du forum :-)
En plus pourl e coup j'aurais tendance à être d'accord avec toi.
-- Marc de Ferrière
JmG <JMGB@antipourrielsLACASE.COM> wrote:
Stephane Madrau <stephane@madrau.com> wrote:
Reste la possibilité de faire tourner les plugs ET l'application
principale dans Rosetta. Aucun intérêt du point de vue de la vitesse,
par contre, juste utile *si* le plugin est absolument indispensable....
C'est un inconvénient, par rapport à la transition 68K-PPC, pour
laquelle on pouvait faire tourner plus de combinaisons (plugin 68K ou
PPC sur appli PPC) et attendre plus sereinement la nouvelle version du
plugin:
Perso, je trouve de plus en plus que tous les soit-disants avantages
apportés par les changements de stratégie de Cuppertino depuis quelques
années nous apporte un paquet d'emmerdes diverses et variées, au fond.
A commencer par le niveau pécunier évidemment.
Mais bon... on va encore me taxer de mauvaise foi, je suis bien sûr...
:)
Tu sais bien que c'est ni notre genre ni celui du forum :-)
En plus pourl e coup j'aurais tendance à être d'accord avec toi.
Reste la possibilité de faire tourner les plugs ET l'application principale dans Rosetta. Aucun intérêt du point de vue de la vitesse, par contre, juste utile *si* le plugin est absolument indispensable....
C'est un inconvénient, par rapport à la transition 68K-PPC, pour laquelle on pouvait faire tourner plus de combinaisons (plugin 68K ou PPC sur appli PPC) et attendre plus sereinement la nouvelle version du plugin:
Perso, je trouve de plus en plus que tous les soit-disants avantages apportés par les changements de stratégie de Cuppertino depuis quelques années nous apporte un paquet d'emmerdes diverses et variées, au fond.
A commencer par le niveau pécunier évidemment.
Mais bon... on va encore me taxer de mauvaise foi, je suis bien sûr... :)
Tu sais bien que c'est ni notre genre ni celui du forum :-)
En plus pourl e coup j'aurais tendance à être d'accord avec toi.
-- Marc de Ferrière
olivier.marti
Stephane Madrau wrote:
C'est transparent. C'est proche (dans sa transparence et dans son utilisation de tous les jours) de l'émulation 68K qu'on avait lors de la transition vers le PowerPC en 94: pas moyen de se rendre compte rapidement si ça tourne nativement ou de manière émulée.
Est-il possible de faire des 'fat binaries', c'est dire contenant le binaire pour les deux types de processeurs ?
Olivier
Stephane Madrau <stephane@madrau.com> wrote:
C'est transparent. C'est proche (dans sa transparence et dans son
utilisation de tous les jours) de l'émulation 68K qu'on avait lors de la
transition vers le PowerPC en 94: pas moyen de se rendre compte
rapidement si ça tourne nativement ou de manière émulée.
Est-il possible de faire des 'fat binaries', c'est dire contenant le
binaire pour les deux types de processeurs ?
C'est transparent. C'est proche (dans sa transparence et dans son utilisation de tous les jours) de l'émulation 68K qu'on avait lors de la transition vers le PowerPC en 94: pas moyen de se rendre compte rapidement si ça tourne nativement ou de manière émulée.
Est-il possible de faire des 'fat binaries', c'est dire contenant le binaire pour les deux types de processeurs ?
Olivier
Patrick Stadelmann
In article <1h90qjc.1diw20a1mo3ttsN%, (Olivier Marti) wrote:
Est-il possible de faire des 'fat binaries', c'est dire contenant le binaire pour les deux types de processeurs ?
Oui, ça s'appelle des "Universal Binaries". C'est utilisé pour iLife 06 d'après l'annonce faite hier.
Patrick -- Patrick Stadelmann
In article <1h90qjc.1diw20a1mo3ttsN%olivier.marti@ensta.org>,
olivier.marti@ensta.org (Olivier Marti) wrote:
Est-il possible de faire des 'fat binaries', c'est dire contenant le
binaire pour les deux types de processeurs ?
Oui, ça s'appelle des "Universal Binaries". C'est utilisé pour iLife 06
d'après l'annonce faite hier.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1h90qjc.1diw20a1mo3ttsN%, (Olivier Marti) wrote:
Est-il possible de faire des 'fat binaries', c'est dire contenant le binaire pour les deux types de processeurs ?
Oui, ça s'appelle des "Universal Binaries". C'est utilisé pour iLife 06 d'après l'annonce faite hier.
Patrick -- Patrick Stadelmann
Eric Levenez
Le 11/01/06 21:24, dans <1h90qjc.1diw20a1mo3ttsN%, « Olivier Marti » a écrit :
Est-il possible de faire des 'fat binaries', c'est dire contenant le binaire pour les deux types de processeurs ?
C'est le principe même de la chose. Un seul exécutable (fichier) pour N architectures et sous-architectures. Pour dégraisser (ou engraisser) un binaire on utilise lipo. Cette notion est différence de la notion de multi-architecture des wrappers des applications (qui utilisent eux des sous-répertoires par architecture).
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 11/01/06 21:24, dans <1h90qjc.1diw20a1mo3ttsN%olivier.marti@ensta.org>,
« Olivier Marti » <olivier.marti@ensta.org> a écrit :
Est-il possible de faire des 'fat binaries', c'est dire contenant le
binaire pour les deux types de processeurs ?
C'est le principe même de la chose. Un seul exécutable (fichier) pour N
architectures et sous-architectures. Pour dégraisser (ou engraisser) un
binaire on utilise lipo. Cette notion est différence de la notion de
multi-architecture des wrappers des applications (qui utilisent eux des
sous-répertoires par architecture).
Le 11/01/06 21:24, dans <1h90qjc.1diw20a1mo3ttsN%, « Olivier Marti » a écrit :
Est-il possible de faire des 'fat binaries', c'est dire contenant le binaire pour les deux types de processeurs ?
C'est le principe même de la chose. Un seul exécutable (fichier) pour N architectures et sous-architectures. Pour dégraisser (ou engraisser) un binaire on utilise lipo. Cette notion est différence de la notion de multi-architecture des wrappers des applications (qui utilisent eux des sous-répertoires par architecture).
