> La seule raison pouvant faire que ce fonctionne dans Rosetta à l'inst ant
> T ne fonctionne plus à l'instant T+1, c'est que Apple enlève l'OS d es
> composants logiciels utilisés par Rosetta. Il n'y a qu'à continuer à
> fournir ces composants logiciels, et le problème est réglé.
Sauf que ces composants interagissent directement avec l'OS natif,
Rosetta n'est pas équivalent à une application qui est isolée de l' OS
l'interface étant les frameworks de l'OS. Rosetta interagit avec l'OS
natif au niveau inférieur, donc se sont ses propres frameworks qui
doivent assurer la compatibilité.
> Quand on voit que certaines applications Win32 qui ont plus de 15 ans e t
> tounaient sous Windows 98 peuvent encore tourner sur Windows 8, il faut
> arrêter de chercher des excuses à Apple pour Rosetta.
Tu confonds excuses et explications.
Rosetta a toujours été présenté
comme une technologie de transition. SL, et donc Rosetta, a été suppo rté
jusqu'en 2013, soit 8 ans après l'annonce de la transition vers Intel,
et 7 ans après l'achèvement de cette transition.
> La seule raison pouvant faire que ce fonctionne dans Rosetta à l'inst ant
> T ne fonctionne plus à l'instant T+1, c'est que Apple enlève l'OS d es
> composants logiciels utilisés par Rosetta. Il n'y a qu'à continuer à
> fournir ces composants logiciels, et le problème est réglé.
Sauf que ces composants interagissent directement avec l'OS natif,
Rosetta n'est pas équivalent à une application qui est isolée de l' OS
l'interface étant les frameworks de l'OS. Rosetta interagit avec l'OS
natif au niveau inférieur, donc se sont ses propres frameworks qui
doivent assurer la compatibilité.
> Quand on voit que certaines applications Win32 qui ont plus de 15 ans e t
> tounaient sous Windows 98 peuvent encore tourner sur Windows 8, il faut
> arrêter de chercher des excuses à Apple pour Rosetta.
Tu confonds excuses et explications.
Rosetta a toujours été présenté
comme une technologie de transition. SL, et donc Rosetta, a été suppo rté
jusqu'en 2013, soit 8 ans après l'annonce de la transition vers Intel,
et 7 ans après l'achèvement de cette transition.
> La seule raison pouvant faire que ce fonctionne dans Rosetta à l'inst ant
> T ne fonctionne plus à l'instant T+1, c'est que Apple enlève l'OS d es
> composants logiciels utilisés par Rosetta. Il n'y a qu'à continuer à
> fournir ces composants logiciels, et le problème est réglé.
Sauf que ces composants interagissent directement avec l'OS natif,
Rosetta n'est pas équivalent à une application qui est isolée de l' OS
l'interface étant les frameworks de l'OS. Rosetta interagit avec l'OS
natif au niveau inférieur, donc se sont ses propres frameworks qui
doivent assurer la compatibilité.
> Quand on voit que certaines applications Win32 qui ont plus de 15 ans e t
> tounaient sous Windows 98 peuvent encore tourner sur Windows 8, il faut
> arrêter de chercher des excuses à Apple pour Rosetta.
Tu confonds excuses et explications.
Rosetta a toujours été présenté
comme une technologie de transition. SL, et donc Rosetta, a été suppo rté
jusqu'en 2013, soit 8 ans après l'annonce de la transition vers Intel,
et 7 ans après l'achèvement de cette transition.
Des explications de ce genre ressembles à de mauvaises excuses, en fait .
Des explications de ce genre ressembles à de mauvaises excuses, en fait .
Des explications de ce genre ressembles à de mauvaises excuses, en fait .
Le lundi 20 octobre 2014 09:37:35 UTC+2, Patrick Stadelmann a écrit :
>
> > La seule raison pouvant faire que ce fonctionne dans Rosetta à l'instant
> > T ne fonctionne plus à l'instant T+1, c'est que Apple enlève l'OS des
> > composants logiciels utilisés par Rosetta. Il n'y a qu'à continuer à
> > fournir ces composants logiciels, et le problème est réglé.
>
> Sauf que ces composants interagissent directement avec l'OS natif,
> Rosetta n'est pas équivalent à une application qui est isolée de l'OS
> l'interface étant les frameworks de l'OS. Rosetta interagit avec l'OS
> natif au niveau inférieur, donc se sont ses propres frameworks qui
> doivent assurer la compatibilité.
Les frameworks de Rosetta n'ont aucune raison d'avoir à être modifiés
si les composants logiciels au niveau inférieur (dans OS X lui-même)
ne changent pas ou ne sont pas supprimés.
> Rosetta a toujours été présenté
> comme une technologie de transition. SL, et donc Rosetta, a été supporté
> jusqu'en 2013, soit 8 ans après l'annonce de la transition vers Intel,
> et 7 ans après l'achèvement de cette transition.
>
Et donc ?
Le lundi 20 octobre 2014 09:37:35 UTC+2, Patrick Stadelmann a écrit :
>
> > La seule raison pouvant faire que ce fonctionne dans Rosetta à l'instant
> > T ne fonctionne plus à l'instant T+1, c'est que Apple enlève l'OS des
> > composants logiciels utilisés par Rosetta. Il n'y a qu'à continuer à
> > fournir ces composants logiciels, et le problème est réglé.
>
> Sauf que ces composants interagissent directement avec l'OS natif,
> Rosetta n'est pas équivalent à une application qui est isolée de l'OS
> l'interface étant les frameworks de l'OS. Rosetta interagit avec l'OS
> natif au niveau inférieur, donc se sont ses propres frameworks qui
> doivent assurer la compatibilité.
Les frameworks de Rosetta n'ont aucune raison d'avoir à être modifiés
si les composants logiciels au niveau inférieur (dans OS X lui-même)
ne changent pas ou ne sont pas supprimés.
> Rosetta a toujours été présenté
> comme une technologie de transition. SL, et donc Rosetta, a été supporté
> jusqu'en 2013, soit 8 ans après l'annonce de la transition vers Intel,
> et 7 ans après l'achèvement de cette transition.
>
Et donc ?
Le lundi 20 octobre 2014 09:37:35 UTC+2, Patrick Stadelmann a écrit :
>
> > La seule raison pouvant faire que ce fonctionne dans Rosetta à l'instant
> > T ne fonctionne plus à l'instant T+1, c'est que Apple enlève l'OS des
> > composants logiciels utilisés par Rosetta. Il n'y a qu'à continuer à
> > fournir ces composants logiciels, et le problème est réglé.
>
> Sauf que ces composants interagissent directement avec l'OS natif,
> Rosetta n'est pas équivalent à une application qui est isolée de l'OS
> l'interface étant les frameworks de l'OS. Rosetta interagit avec l'OS
> natif au niveau inférieur, donc se sont ses propres frameworks qui
> doivent assurer la compatibilité.
Les frameworks de Rosetta n'ont aucune raison d'avoir à être modifiés
si les composants logiciels au niveau inférieur (dans OS X lui-même)
ne changent pas ou ne sont pas supprimés.
> Rosetta a toujours été présenté
> comme une technologie de transition. SL, et donc Rosetta, a été supporté
> jusqu'en 2013, soit 8 ans après l'annonce de la transition vers Intel,
> et 7 ans après l'achèvement de cette transition.
>
Et donc ?
> Les frameworks de Rosetta n'ont aucune raison d'avoir à être modifi és
> si les composants logiciels au niveau inférieur (dans OS X lui-même )
> ne changent pas ou ne sont pas supprimés.
Justement, ils changent, quand OS X subit une mise à jour majeure, il y
a des modifications à tous les niveaux.
> Et donc ?
Comme toute technologie de transition, elle est vouée à disparaître tôt
ou tard. En achetant des logiciels PowerPC en juin 2005 ou plus tard, on
devait s'attendre à ce qu'il cesse un jour d'être compatible avec les
nouveaux OS. Ce jour est venu 8 ans plus tard, je ne considère pas que
c'est anormalement court.
> Les frameworks de Rosetta n'ont aucune raison d'avoir à être modifi és
> si les composants logiciels au niveau inférieur (dans OS X lui-même )
> ne changent pas ou ne sont pas supprimés.
Justement, ils changent, quand OS X subit une mise à jour majeure, il y
a des modifications à tous les niveaux.
> Et donc ?
Comme toute technologie de transition, elle est vouée à disparaître tôt
ou tard. En achetant des logiciels PowerPC en juin 2005 ou plus tard, on
devait s'attendre à ce qu'il cesse un jour d'être compatible avec les
nouveaux OS. Ce jour est venu 8 ans plus tard, je ne considère pas que
c'est anormalement court.
> Les frameworks de Rosetta n'ont aucune raison d'avoir à être modifi és
> si les composants logiciels au niveau inférieur (dans OS X lui-même )
> ne changent pas ou ne sont pas supprimés.
Justement, ils changent, quand OS X subit une mise à jour majeure, il y
a des modifications à tous les niveaux.
> Et donc ?
Comme toute technologie de transition, elle est vouée à disparaître tôt
ou tard. En achetant des logiciels PowerPC en juin 2005 ou plus tard, on
devait s'attendre à ce qu'il cesse un jour d'être compatible avec les
nouveaux OS. Ce jour est venu 8 ans plus tard, je ne considère pas que
c'est anormalement court.
Le lundi 20 octobre 2014 15:26:09 UTC+2, Patrick Stadelmann a écrit :
>
> > Les frameworks de Rosetta n'ont aucune raison d'avoir à être modifiés
> > si les composants logiciels au niveau inférieur (dans OS X lui-même)
> > ne changent pas ou ne sont pas supprimés.
>
> Justement, ils changent, quand OS X subit une mise à jour majeure, il y
> a des modifications à tous les niveaux.
Ce que tu appelles "mise à jour majeure" d'OS X c'est juste l'équivalent
d'un Service Pack sous Windows, hein... Tout n'est pas repeint du sol au
plafond, loin de là. Notamment les API système sont stables d'une version à
l'autre, et heureusement.
- qu'est-ce qui empêchait Apple de continuer à fournir ces composants dans
10.6 en package avec Rosetta, quitte à le faire par le MAS ?
Trouverais-tu normal qu'un logiciel x86 sorti en 2006 ne puisse plus tourner
sur OS X 10.8 ?
Le lundi 20 octobre 2014 15:26:09 UTC+2, Patrick Stadelmann a écrit :
>
> > Les frameworks de Rosetta n'ont aucune raison d'avoir à être modifiés
> > si les composants logiciels au niveau inférieur (dans OS X lui-même)
> > ne changent pas ou ne sont pas supprimés.
>
> Justement, ils changent, quand OS X subit une mise à jour majeure, il y
> a des modifications à tous les niveaux.
Ce que tu appelles "mise à jour majeure" d'OS X c'est juste l'équivalent
d'un Service Pack sous Windows, hein... Tout n'est pas repeint du sol au
plafond, loin de là. Notamment les API système sont stables d'une version à
l'autre, et heureusement.
- qu'est-ce qui empêchait Apple de continuer à fournir ces composants dans
10.6 en package avec Rosetta, quitte à le faire par le MAS ?
Trouverais-tu normal qu'un logiciel x86 sorti en 2006 ne puisse plus tourner
sur OS X 10.8 ?
Le lundi 20 octobre 2014 15:26:09 UTC+2, Patrick Stadelmann a écrit :
>
> > Les frameworks de Rosetta n'ont aucune raison d'avoir à être modifiés
> > si les composants logiciels au niveau inférieur (dans OS X lui-même)
> > ne changent pas ou ne sont pas supprimés.
>
> Justement, ils changent, quand OS X subit une mise à jour majeure, il y
> a des modifications à tous les niveaux.
Ce que tu appelles "mise à jour majeure" d'OS X c'est juste l'équivalent
d'un Service Pack sous Windows, hein... Tout n'est pas repeint du sol au
plafond, loin de là. Notamment les API système sont stables d'une version à
l'autre, et heureusement.
- qu'est-ce qui empêchait Apple de continuer à fournir ces composants dans
10.6 en package avec Rosetta, quitte à le faire par le MAS ?
Trouverais-tu normal qu'un logiciel x86 sorti en 2006 ne puisse plus tourner
sur OS X 10.8 ?
Francois LE COAT écrit :Mais pour bénéficier de la mise à jour de iOS 8.1 sur mon iPhone 5.
Ça s'est toujours présenté de cette façon. À une mise à jo ur
majeure de iOS, correspond une mise à jour de iTunes. Je l'ai
déjà dit, pour mettre à jour iOS lundi, il faudra un iTunes à jour
Tu peux mettre à jour ton iPhone en 8.1 directement sur l'iPhone, y a
pas besoin de passer par iTunes ni par un Mac.
Francois LE COAT écrit :
Mais pour bénéficier de la mise à jour de iOS 8.1 sur mon iPhone 5.
Ça s'est toujours présenté de cette façon. À une mise à jo ur
majeure de iOS, correspond une mise à jour de iTunes. Je l'ai
déjà dit, pour mettre à jour iOS lundi, il faudra un iTunes à jour
Tu peux mettre à jour ton iPhone en 8.1 directement sur l'iPhone, y a
pas besoin de passer par iTunes ni par un Mac.
Francois LE COAT écrit :Mais pour bénéficier de la mise à jour de iOS 8.1 sur mon iPhone 5.
Ça s'est toujours présenté de cette façon. À une mise à jo ur
majeure de iOS, correspond une mise à jour de iTunes. Je l'ai
déjà dit, pour mettre à jour iOS lundi, il faudra un iTunes à jour
Tu peux mettre à jour ton iPhone en 8.1 directement sur l'iPhone, y a
pas besoin de passer par iTunes ni par un Mac.
Ce que tu appelles "mise à jour majeure" d'OS X c'est juste l'équivalent
d'un Service Pack sous Windows, hein... Tout n'est pas repeint du sol au
plafond, loin de là. Notamment les API système sont stables d'une version à
l'autre, et heureusement.
Quand une application PowerPC utilise un framework, c'est la version
PowerPC qui est chargée par Rosetta. Comme il y a aussi des applications
natives, il faut bien évidemment aussi une version native de ce
framework. Ca n'est donc pas compliqué de voir qu'il faut maintenir deux
architectures pour chaque framework.
En gros, SL pour supporter Rosetta est un OS qui contient des frameworks
qu'on trouveraient dans la version PowerPC de SL, si cet OS existait. Et
ce en plus des frameworks natifs correspondants.
- qu'est-ce qui empêchait Apple de continuer à fournir ces composants dans
10.6 en package avec Rosetta, quitte à le faire par le MAS ?
Il n'y a aucune impossibilité technique, simplement ça demande soit de
faire un effort conséquent pour adapter et valider les frameworks
PowerPC en plus des frameworks natifs.
Si ça n'avait quasi rien coûté, je vois pas pourquoi Apple aurait
supprimé Rosetta... Ceux qui voulait absolument rester sous 10.6 pour
Rosetta ont fini par repousser l'achat d'une nouvelle machines, donc ce
sont des ventes perdues pour Apple.
Trouverais-tu normal qu'un logiciel x86 sorti en 2006 ne puisse plus tourner
sur OS X 10.8 ?
Pourquoi 2006 et pas 1984 ?
On peut souvent assurer une compatibilité
avec des logiciels très ancien, mais cela a un toujours un coût, et ce
coût peut être très lourd.
Personnellement si je devais prévoir 8 ans
pour amortir un logiciel, je m'interrogerais longuement pour savoir si
l'investissement se justifie.
Ce que tu appelles "mise à jour majeure" d'OS X c'est juste l'équivalent
d'un Service Pack sous Windows, hein... Tout n'est pas repeint du sol au
plafond, loin de là. Notamment les API système sont stables d'une version à
l'autre, et heureusement.
Quand une application PowerPC utilise un framework, c'est la version
PowerPC qui est chargée par Rosetta. Comme il y a aussi des applications
natives, il faut bien évidemment aussi une version native de ce
framework. Ca n'est donc pas compliqué de voir qu'il faut maintenir deux
architectures pour chaque framework.
En gros, SL pour supporter Rosetta est un OS qui contient des frameworks
qu'on trouveraient dans la version PowerPC de SL, si cet OS existait. Et
ce en plus des frameworks natifs correspondants.
- qu'est-ce qui empêchait Apple de continuer à fournir ces composants dans
10.6 en package avec Rosetta, quitte à le faire par le MAS ?
Il n'y a aucune impossibilité technique, simplement ça demande soit de
faire un effort conséquent pour adapter et valider les frameworks
PowerPC en plus des frameworks natifs.
Si ça n'avait quasi rien coûté, je vois pas pourquoi Apple aurait
supprimé Rosetta... Ceux qui voulait absolument rester sous 10.6 pour
Rosetta ont fini par repousser l'achat d'une nouvelle machines, donc ce
sont des ventes perdues pour Apple.
Trouverais-tu normal qu'un logiciel x86 sorti en 2006 ne puisse plus tourner
sur OS X 10.8 ?
Pourquoi 2006 et pas 1984 ?
On peut souvent assurer une compatibilité
avec des logiciels très ancien, mais cela a un toujours un coût, et ce
coût peut être très lourd.
Personnellement si je devais prévoir 8 ans
pour amortir un logiciel, je m'interrogerais longuement pour savoir si
l'investissement se justifie.
Ce que tu appelles "mise à jour majeure" d'OS X c'est juste l'équivalent
d'un Service Pack sous Windows, hein... Tout n'est pas repeint du sol au
plafond, loin de là. Notamment les API système sont stables d'une version à
l'autre, et heureusement.
Quand une application PowerPC utilise un framework, c'est la version
PowerPC qui est chargée par Rosetta. Comme il y a aussi des applications
natives, il faut bien évidemment aussi une version native de ce
framework. Ca n'est donc pas compliqué de voir qu'il faut maintenir deux
architectures pour chaque framework.
En gros, SL pour supporter Rosetta est un OS qui contient des frameworks
qu'on trouveraient dans la version PowerPC de SL, si cet OS existait. Et
ce en plus des frameworks natifs correspondants.
- qu'est-ce qui empêchait Apple de continuer à fournir ces composants dans
10.6 en package avec Rosetta, quitte à le faire par le MAS ?
Il n'y a aucune impossibilité technique, simplement ça demande soit de
faire un effort conséquent pour adapter et valider les frameworks
PowerPC en plus des frameworks natifs.
Si ça n'avait quasi rien coûté, je vois pas pourquoi Apple aurait
supprimé Rosetta... Ceux qui voulait absolument rester sous 10.6 pour
Rosetta ont fini par repousser l'achat d'une nouvelle machines, donc ce
sont des ventes perdues pour Apple.
Trouverais-tu normal qu'un logiciel x86 sorti en 2006 ne puisse plus tourner
sur OS X 10.8 ?
Pourquoi 2006 et pas 1984 ?
On peut souvent assurer une compatibilité
avec des logiciels très ancien, mais cela a un toujours un coût, et ce
coût peut être très lourd.
Personnellement si je devais prévoir 8 ans
pour amortir un logiciel, je m'interrogerais longuement pour savoir si
l'investissement se justifie.
Il n'y a rien à maintenir en double. Les librairies système ne sont à la
base pas différentes entre Mac OS X PPC et Mac OS X x86, c'est le même
code source compilé pour 2 cibles différentes.
Gnu/Linux tourne sur des dizaines d'architectures, et heureusement qu'il
n'y a pas besoin de maintenir des dizaines de versions des librairies.
> En gros, SL pour supporter Rosetta est un OS qui contient des frameworks
> qu'on trouveraient dans la version PowerPC de SL, si cet OS existait. Et
> ce en plus des frameworks natifs correspondants.
Ce sont les mêmes. En plus je doute que les version PPC des librairies
système soient présentes dans Rosetta, ce qui obligerait à les convertir
à la volée en code x86,
alors que ces mêmes librairies sont présentes
nativement en code x86 et peuvent être appelées par Rosetta.
Ce que tu
décris serait le fonctionnement d'un virtualiseur, ce que n'est pas Rosetta.
> Il n'y a aucune impossibilité technique, simplement ça demande soit de
> faire un effort conséquent pour adapter et valider les frameworks
> PowerPC en plus des frameworks natifs.
Non, car il n'y a pas de "frameworks" PPC différents des "frameworks" x86.
> Personnellement si je devais prévoir 8 ans
> pour amortir un logiciel, je m'interrogerais longuement pour savoir si
> l'investissement se justifie.
On ne parle pas d'entreprises, là, mais de particuliers.
Il n'y a rien à maintenir en double. Les librairies système ne sont à la
base pas différentes entre Mac OS X PPC et Mac OS X x86, c'est le même
code source compilé pour 2 cibles différentes.
Gnu/Linux tourne sur des dizaines d'architectures, et heureusement qu'il
n'y a pas besoin de maintenir des dizaines de versions des librairies.
> En gros, SL pour supporter Rosetta est un OS qui contient des frameworks
> qu'on trouveraient dans la version PowerPC de SL, si cet OS existait. Et
> ce en plus des frameworks natifs correspondants.
Ce sont les mêmes. En plus je doute que les version PPC des librairies
système soient présentes dans Rosetta, ce qui obligerait à les convertir
à la volée en code x86,
alors que ces mêmes librairies sont présentes
nativement en code x86 et peuvent être appelées par Rosetta.
Ce que tu
décris serait le fonctionnement d'un virtualiseur, ce que n'est pas Rosetta.
> Il n'y a aucune impossibilité technique, simplement ça demande soit de
> faire un effort conséquent pour adapter et valider les frameworks
> PowerPC en plus des frameworks natifs.
Non, car il n'y a pas de "frameworks" PPC différents des "frameworks" x86.
> Personnellement si je devais prévoir 8 ans
> pour amortir un logiciel, je m'interrogerais longuement pour savoir si
> l'investissement se justifie.
On ne parle pas d'entreprises, là, mais de particuliers.
Il n'y a rien à maintenir en double. Les librairies système ne sont à la
base pas différentes entre Mac OS X PPC et Mac OS X x86, c'est le même
code source compilé pour 2 cibles différentes.
Gnu/Linux tourne sur des dizaines d'architectures, et heureusement qu'il
n'y a pas besoin de maintenir des dizaines de versions des librairies.
> En gros, SL pour supporter Rosetta est un OS qui contient des frameworks
> qu'on trouveraient dans la version PowerPC de SL, si cet OS existait. Et
> ce en plus des frameworks natifs correspondants.
Ce sont les mêmes. En plus je doute que les version PPC des librairies
système soient présentes dans Rosetta, ce qui obligerait à les convertir
à la volée en code x86,
alors que ces mêmes librairies sont présentes
nativement en code x86 et peuvent être appelées par Rosetta.
Ce que tu
décris serait le fonctionnement d'un virtualiseur, ce que n'est pas Rosetta.
> Il n'y a aucune impossibilité technique, simplement ça demande soit de
> faire un effort conséquent pour adapter et valider les frameworks
> PowerPC en plus des frameworks natifs.
Non, car il n'y a pas de "frameworks" PPC différents des "frameworks" x86.
> Personnellement si je devais prévoir 8 ans
> pour amortir un logiciel, je m'interrogerais longuement pour savoir si
> l'investissement se justifie.
On ne parle pas d'entreprises, là, mais de particuliers.
In article ,
pehache wrote:Il n'y a rien à maintenir en double. Les librairies système ne sont à la
base pas différentes entre Mac OS X PPC et Mac OS X x86, c'est le même
code source compilé pour 2 cibles différentes.
Même pour les applications, il ne suffit pas de recompiler, tout
développeur le sait.
Gnu/Linux tourne sur des dizaines d'architectures, et heureusement qu'il
n'y a pas besoin de maintenir des dizaines de versions des librairies.
Mais l'OS ne comporte pas une partie en émulation.
Ce sont les mêmes. En plus je doute que les version PPC des librairies
système soient présentes dans Rosetta, ce qui obligerait à les convertir
à la volée en code x86,
C'est bien ce qui se passe. Evidemment avec des optimisations genre
compilation JIT, mise en cache, ...alors que ces mêmes librairies sont présentes
nativement en code x86 et peuvent être appelées par Rosetta.
Non. J'ai déjà expliqué que ça ne fonctionne pas comme cela !
Il n'y a aucune impossibilité technique, simplement ça demande soit de
faire un effort conséquent pour adapter et valider les frameworks
PowerPC en plus des frameworks natifs.
Non, car il n'y a pas de "frameworks" PPC différents des "frameworks" x86.
Ben voyons. Evidemment qu'ils sont différents vu qu'ils n'utilisent pas
le même jeux d'instructions !
Et à ce titre, comme si on recompile en ne
changeant que des paramètres d'optimisations, le code doit être
revalidé.
Et là en plus, les frameworks PowerPC interfacent un OS qui
n'a pas la même endianness, ce qui nécessite évidemment une couche de
compatibilité qui n'existe pas côté Intel...
Il y a eu des mise à jour de sécurité qui ont rendu certains logiciels
PowerPC inopérants dans Leopard ou SL, on se demande comment cela a pu
arriver si c'est tellement simple de maintenir l'environnement PowerPC
dans Mac OS X Intel.
On ne parle pas d'entreprises, là, mais de particuliers.
Ah... et quand les particuliers achètes des logiciels, ils pensent les
utiliser indéfiniment, y compris sur de nouvelles machines ou des
nouveaux OS, sans jamais acheter de nouvelles versions ou de mises à
jour, et donc sans se poser la question du nombre d'années où ces
logiciels seront exploitables ?
In article <calbvnFrl1oU1@mid.individual.net>,
pehache <pehache.7@gmail.com> wrote:
Il n'y a rien à maintenir en double. Les librairies système ne sont à la
base pas différentes entre Mac OS X PPC et Mac OS X x86, c'est le même
code source compilé pour 2 cibles différentes.
Même pour les applications, il ne suffit pas de recompiler, tout
développeur le sait.
Gnu/Linux tourne sur des dizaines d'architectures, et heureusement qu'il
n'y a pas besoin de maintenir des dizaines de versions des librairies.
Mais l'OS ne comporte pas une partie en émulation.
Ce sont les mêmes. En plus je doute que les version PPC des librairies
système soient présentes dans Rosetta, ce qui obligerait à les convertir
à la volée en code x86,
C'est bien ce qui se passe. Evidemment avec des optimisations genre
compilation JIT, mise en cache, ...
alors que ces mêmes librairies sont présentes
nativement en code x86 et peuvent être appelées par Rosetta.
Non. J'ai déjà expliqué que ça ne fonctionne pas comme cela !
Il n'y a aucune impossibilité technique, simplement ça demande soit de
faire un effort conséquent pour adapter et valider les frameworks
PowerPC en plus des frameworks natifs.
Non, car il n'y a pas de "frameworks" PPC différents des "frameworks" x86.
Ben voyons. Evidemment qu'ils sont différents vu qu'ils n'utilisent pas
le même jeux d'instructions !
Et à ce titre, comme si on recompile en ne
changeant que des paramètres d'optimisations, le code doit être
revalidé.
Et là en plus, les frameworks PowerPC interfacent un OS qui
n'a pas la même endianness, ce qui nécessite évidemment une couche de
compatibilité qui n'existe pas côté Intel...
Il y a eu des mise à jour de sécurité qui ont rendu certains logiciels
PowerPC inopérants dans Leopard ou SL, on se demande comment cela a pu
arriver si c'est tellement simple de maintenir l'environnement PowerPC
dans Mac OS X Intel.
On ne parle pas d'entreprises, là, mais de particuliers.
Ah... et quand les particuliers achètes des logiciels, ils pensent les
utiliser indéfiniment, y compris sur de nouvelles machines ou des
nouveaux OS, sans jamais acheter de nouvelles versions ou de mises à
jour, et donc sans se poser la question du nombre d'années où ces
logiciels seront exploitables ?
In article ,
pehache wrote:Il n'y a rien à maintenir en double. Les librairies système ne sont à la
base pas différentes entre Mac OS X PPC et Mac OS X x86, c'est le même
code source compilé pour 2 cibles différentes.
Même pour les applications, il ne suffit pas de recompiler, tout
développeur le sait.
Gnu/Linux tourne sur des dizaines d'architectures, et heureusement qu'il
n'y a pas besoin de maintenir des dizaines de versions des librairies.
Mais l'OS ne comporte pas une partie en émulation.
Ce sont les mêmes. En plus je doute que les version PPC des librairies
système soient présentes dans Rosetta, ce qui obligerait à les convertir
à la volée en code x86,
C'est bien ce qui se passe. Evidemment avec des optimisations genre
compilation JIT, mise en cache, ...alors que ces mêmes librairies sont présentes
nativement en code x86 et peuvent être appelées par Rosetta.
Non. J'ai déjà expliqué que ça ne fonctionne pas comme cela !
Il n'y a aucune impossibilité technique, simplement ça demande soit de
faire un effort conséquent pour adapter et valider les frameworks
PowerPC en plus des frameworks natifs.
Non, car il n'y a pas de "frameworks" PPC différents des "frameworks" x86.
Ben voyons. Evidemment qu'ils sont différents vu qu'ils n'utilisent pas
le même jeux d'instructions !
Et à ce titre, comme si on recompile en ne
changeant que des paramètres d'optimisations, le code doit être
revalidé.
Et là en plus, les frameworks PowerPC interfacent un OS qui
n'a pas la même endianness, ce qui nécessite évidemment une couche de
compatibilité qui n'existe pas côté Intel...
Il y a eu des mise à jour de sécurité qui ont rendu certains logiciels
PowerPC inopérants dans Leopard ou SL, on se demande comment cela a pu
arriver si c'est tellement simple de maintenir l'environnement PowerPC
dans Mac OS X Intel.
On ne parle pas d'entreprises, là, mais de particuliers.
Ah... et quand les particuliers achètes des logiciels, ils pensent les
utiliser indéfiniment, y compris sur de nouvelles machines ou des
nouveaux OS, sans jamais acheter de nouvelles versions ou de mises à
jour, et donc sans se poser la question du nombre d'années où ces
logiciels seront exploitables ?
Quand on voit que certaines applications Win32 qui ont plus de 15 ans et
tounaient sous Windows 98 peuvent encore tourner sur Windows 8, il faut
arrêter de chercher des excuses à Apple pour Rosetta.
Quand on voit que certaines applications Win32 qui ont plus de 15 ans et
tounaient sous Windows 98 peuvent encore tourner sur Windows 8, il faut
arrêter de chercher des excuses à Apple pour Rosetta.
Quand on voit que certaines applications Win32 qui ont plus de 15 ans et
tounaient sous Windows 98 peuvent encore tourner sur Windows 8, il faut
arrêter de chercher des excuses à Apple pour Rosetta.
