MorphOS, la suite du dév ?
-
Parce que faire booter MorphOS sur G5 a pris quelques jours à une personne seule alors qu’arriver au même résultat sur x86 prendrait surement plusieurs années.
Et pour avoir au final un OS incompatible avec l’ensemble des logiciels existant. Ne pas oublier ce détail
Le faire booter dessus a peut être pris quelques jours… mais avoir quelque chose d’assez fini pour le commun des mortels semble en prendre bien plus…
Ensuite, ça ne sert à rien de répéter que ça prendrait des années (ça fait 5 ans qu’on en parle… on aurait déjà quelque chose d’utulisable…), qu’on n’aurait pas d’applis (qu’est-ce qui empêche d’avoir un MUI x86 et de porter l’ensemble des applis MorphOS dessus ? Sachant que toutes les libs/codecs sont *déjà* disponibles pour x86: webkit, mplayer,… que ça ne soit pas compatible, ok, qu’on n’ait 0 applis, hmm…)
La question c’est plutôt: quel est le but de MorphOS ? Quelle utilisation ? Quel « marché » ? Tant qu’on ne répondra pas, on peut débattre pendant 10 ans, ça ne servira à rien. Si le but c’est de satisfaire le milliers de fans de l’Amiga, alors c’est sur: aucun intérêt d’aller sur x86… Si le but est d’avoir un système moderne dans la tradition de l’Amiga, mais avec un minimum d’ambition, alors je ne vois pas pourquoi on reste 1 mois de plus sur PPC… C’est aussi simple. Le x86 c’est pourri, l’ARM c’est mieux, le Sparc ça cartonne, on s’en fou…
Tout dépend de ça. Et que ce soit MorphOS, AROS, ou OS4, on est dans le flou: j’ai jamais vu aucun des trois se positionner quelque part. Haiku vise le desktop. Les *BSD le réseau, etc… A chaque fois il y a un but clair et précis. Pour les Amiga-like, on ne sait pas, alors ça part dans tous les sens (AROS par exemple) sans jamais avancer/se stabiliser, ou alors ça ne bouge pas, et patauge: OS4/MorphOS…
Ah, et autre chose: on le sait qu’il n’y a pas de moyens, mais les *BSD, Haiku, etc…. n’ont pas plus d’argent. Ca les empêche pas d’avoir un but. Et un but un minimum ambitieux…
Feroce a écrit :
Il y a quand même quelque chose qui m’étonne dans tout ça : tout le monde crie à l’impossibilité de faire tourner les softs PPC sur x86.
Ce genre de remarque revient souvent…
Il faut comprendre qu’on parle en fait de l’impossibilité de faire tourner les softs PPC sur x86 de façon complètement transparente pour l’utilisateur. De la même manière que les softs 68k, PowerUP, WarpUP et HyperOS tournent sur MorphOS sans même que l’utilisateur se rende compte qu’il fait tourner un soft prévu pour un CPU différent, une API différente ou une ABI différente.
Par contre, il existe bien des façons de faire tourner les softs PPC sur x86 :
– via un UAE qui émulerait une carte PPC
– via l’émulateur de machine de QEMU (bigfoot l’a déjà fait)
– via un logiciel de type l’environnement classic » d’OSX (la « yellow box »)
– etc…
C’est autant intégré et transparent qu’un logiciel Amstrad CPC qui tourne sur Amiga…
Et, si un quelconque AmigaOS x86 est un jour compatible avec les softs actuels, j’imagine qu’il utilisera une de ces méthodes. Eventuellement en tentant de faire cela de façon plus ou moins acceptable, comme Apple l’a tenté avec son émulateur de Mac « classic » sur ses machines OSX.
Pourtant Apple a résolu sans trop de difficultés le problème au passage sur x86 en 2005.
Ca avait par ailleurs été sous-traité, il n’est pas impossible que cette société puisse bosser avec la MOS Team (enfin, faut voir le prix
).Ce qu’a fait Apple avec Rosetta n’est pas une première et a déjà été fait par :
– FX!32 qui faisait tourner les softs Windows x86 sur Windows Alpha il y a 15 ans
– QEMU qui fait tourner les softs Linux x86 sur Linux PPC, Linux PPC sur Linux ARM et peut-être même Linux x86 sur Linux 68k… allez savoir
– les divers OS BSD qui font tourner les softs Linux
– etc
Ce genre de chose n’est pas excessivement compliqué à faire à partir du moment où l’on parle d’un OS faisant une séparation claire et nette entre l’OS et ses applications…
L’OS x86 charge le binaire PPC et l’exécute via une émulation PPC. Le soft PPC fait un appel système… qui se retrouve être un stub (un wrapper)… qui converti les arguments pour l’OS x86 et effectue l’appel système correspondant dans l’OS x86. Les valeurs de retour sont éventuellement converties et on retourne à l’émulation PPC. Point. C’est terminé. Grosso modo.
Rien de tout cela ne peut fonctionner dans le cas d’AmigaOS qui ne fait pas de différence entre ce qui est OS et ce qui est application. Et, pire, où les application peuvent et *doivent* manipuler les structures internes de l’OS sans en avertir qui que ce soit.
Un simple wrapper devient alors impossible et, à ma connaissance, personne au monde n’a jamais programmé un tel truc et réussi à le faire *vraiment* marcher.
Et, d’ailleurs, Apple non plus n’a pas réussi à faire tourner les softs MacOS7/8/9 sur OSX de façon 100% transparent… Comme quoi…
Actuellement, un programmeur AROS travaille pourtant sur un tel truc (est-ce « Janus UAE » ? je ne me souviens plus…). Un UAE modifié pour donner l’impression que les applis tournent dans l’OS hote. Et il arrive déjà à lancer quelques applis simples come clock et même d’autres beaucoup plus compliquées… mais ça ne fonctione alors pas très longtemps
Son projet est excessivement compliqué puisqu’il tente de suivre en permanence l’évolution des structures internes de l’AmigaOS natif (AROS) et de l’AmigaOS émulé (dans UAE) et de mettre à jour l’une pour ressembler à l’état de l’autre et vis versa…
Je crois qu’il est conscient qu’il est impossible qu’il arrive à programmer quelque chose qui marche dans (presque) tous les cas.
Mais peut-être qu’il arrivera un jour à faire tourner de façon stable un gros programme comme TVPaint ou Magellan. Ce qui serait déjà un exploit. Stay tuned.
Je pense que pour évoluer, il faudra un jour arrêter de vouloir à tout pris être compatible… Sinon dans 10 ans on se retrouvera à avoir un wrapper PPC, un wrapper 68k, pour le nouveau CPU choisi… Et si on doit rechanger, avec les mêmes contraintes (donc pas de limite entre ce qui est OS ou application comme le dit Henes), ça sera les mêmes problèmes…
Pour ça la 1ère chose serait de développer de nouvelles API qui soient « sures » de ce côté là. C’est toujours pas fait, ni à l’ordre du jour…
Regarder un Amiga booter c’est cool, ça va vite, mais au bout de 3 jours on en a marre… Il faudrait quand même une vraie utilisation
J’ai mon peg/morphos allumé toute la journée, auquel je peux accèder via VNC quand je suis au boulot, et sur lequel je peux naviguer et faire toutes mes tâches quotidiennes, etc…
C’est une utilisation, non ?
Le problème c’est que cette utilisation est commune à Linux, MacOS, BSD, Windows (je continue ?) qui, tout en offrant une meilleure/plus complète utilisation, offrent plein d’autres choses…
C’est juste « normal ». J’espère que ce n’est pas le but
@Soundsquare : d’accord avec toi, sauf pour la rétrocompatibilité : ce n’est pas un frein, puisque WinUAE existe déjà. Il manque toujours l’équivalent distribué sous Linux et Mac. Et pas de binaires de PUAE à l’horizon (a part pour Mac http://www.ultimateamiga.co.uk/index.php/page,13.html).
Pour moi qui suis « pur » Amiga Classique, je m’amuse autant maintenant sur Amiga qu’il y a 10ans, donc l’avenir de l’Amiga Moderne reste… le passé !
Une vie entière ne suffirait pas à tester tous les jeux et applis sympa sur Amiga.
Ma config : Amiga CD32 nue, c'est un super joujou pour rester dans le monde de l'Amiga 🙂
Au lieu de passer trop de temps à développer des drivers ( et réinventer la roue) sur un OS qui n’a pour cible qu’une seule architecture (PPC), pourquoi ne pas reprendre une base puissante comme Ubuntu pour y intégrer :
(1) – La brique logicielle AROS (fonctionnant comme Wine)
(2) – Une version Linux de WinUAE, intégrée au système, avec toutes les options qui vont bien.
Urg!
J’imagine que tu parles d’une version « hosted », donc (pourquoi privilégier un OS particulier alors, et pourquoi ubuntu ????). Franchement, une base ubuntu, c’est le pompon. Qui veut de l’OS le plus lent et mal fichu de l’histoire pour servir de base à un amigaos « NG » ?
Ensuite, pourquoi choisir AROS dans ce cas? Les technologies et programmes actuellement présents dans MorphOS sont plus intéressants. Aucun besoin de revenir en arrière d’une décennie ou deux en choisissant AROS.
WinUAE ? Pourquoi cette fixation sur WinUAE ? Les fioritures de WinUAE c’est bien mignon, mais la seule partie qui importe, c’est le noyau même d’UAE, et dans ce cadre, E-UAE et cie font tout aussi bien le boulot (j’ai l’impression que certains confondent un peu vite le noyau de l’émulation est les fonctions terminales comme l’affichage et cie). Alors oui, WinUAE a aussi un peu forké UAE et apporte certaines corrections au UAE original, mais cette partie là est très facilement réutilisable de toutes façons.
Pour etayer ce que viens de dire: j’ai eu un MacMini G4 entre les mains avec MorphOS dessus. Et j’ai été déçu. Car la moitié des composants du MacMini (Wifi + Bluetooth + Clavier sans fil + Télécommande) ne fonctionnait pas. De plus l’AGA est très mal supporté sur UAE.
La moitié, ben voyons, comme tu y vas…
En plus, le bluetooth pour les claviers et souris peut en réalité marcher sous MorphOS, grâce au bridge usb->bluetooth du macmini (dans un mode de base).Quant à l’AGA de UAE, tu peux préciser un peu? J’ai vu les mêmes soucis sur WinUAE…
- Vous devez être connecté pour répondre à ce sujet.
