Test de MorphOS 2.7

Le magazine Obligement vous propose aujourd’hui le test de la dernière version en date de MorphOS, la 2.7.

Ce système d’exploitation de la famille Amiga fonctionne sur Pegasos I/II, Efika 5200B, Mac mini G4, eMac 1.25 et plusieurs modèles de Power Mac G4.

Cette mise à jour 2.7 met l’accent sur les corrections de bogues, une meilleure reconnaissance des Power Mac G4 et a quelques nouveautés.

Site internet : http://obligement.free.fr/articles/morphos27.php

25 Commentaires

Passer au formulaire de commentaire

  1. bravo le Daff ! Tes articles sont toujours parmi les plus obectifs et clairs de toute la communauté amiga.

    • JiDeWe sur 10 décembre 2010 à 21h48

    bientôt morphos sur powerbook alors 😉

    • leo sur 10 décembre 2010 à 21h55

    Intéressant !

    N’ayant pas utilisé MorphOS depuis quelques versions, je suis tombé sur cette vidéo il y a quelques jours: http://www.youtube.com/watch?v=NvmWIqqRR-g

    On voit clairement que les performances s’effondrent dès que (à peine), 4 ou 5 fenêtres sont ouvertes: quelqu’un pourrait me dire si les dernières versions ont corrigé ce problème ?

    • henes sur 10 décembre 2010 à 22h21

    C’est clairement un manque de mémoire vidéo qui se fait sentir.
    Comme je peux ouvrir plus de 100 fenêtres sur une config similaire sans aucun ralentissement et que le sujet à déjà été débattu à mort dans un autre thread sans que gibs ne donne aucune indication permettant de savoir ce qu’il a fait pour en arriver là, j’imagine que rien n’a changé et ne changera.

    Edit : pas si débattu à mort que cela, en fait. Voir ici. Je n’arrive plus à retrouver l’autre thread où cela troll autour de cette vidéo.

    • XRAY sur 11 décembre 2010 à 9h10

    Merci Daff, clairement LE site incontournable avec des sujets très fouiillés. On a beaucoup de plaisir à le lire et encore plus à le citer et le recommander, lors des nombreuses réponses questions aux users de tout poils:-)

    Longue vie à Obligement, cordialement
    XRAY
    RELEC

    • sur 12 décembre 2010 à 12h17

    bon bah la il est clair et net qu il y a une mauvaise gestion de la memoire sous Mos

    • Fab1 sur 12 décembre 2010 à 16h57

    Non, pas vraiment. Le mode « enhanced » doit juste être désactivé pour des configs avec peu de vram.

    • leo sur 12 décembre 2010 à 19h10

    Que le système arrive à court de mémoire graphique et doive swapper en fast ram, ok. Mais est-ce que c’est normal que ca fasse grésiller le son ?

    • Fab1 sur 12 décembre 2010 à 21h49

    C’est un process qui tourne à plus haute priorité que le son, j’imagine (et il vaut mieux, c’est plutôt prioritaire comme action).

    • leo sur 13 décembre 2010 à 9h23

    Oui… Mais c’est aussi important pour l’expérience utilisateur que le son ne se mette pas à couper comme ca (surtout sachant le peu de ressources nécessaires pour lire un mp3 sur les machines d’aujourd’hui…).

    Ca me paraittrait aussi important d’avertir l’utilisateur d’un probable ralentissement parce que manque de mémoire graphique.

    • henes sur 13 décembre 2010 à 10h55

    La quantité de mémoire graphique (ou pas) disponible/utilisée/totale peut s’afficher dans la barre d’écran.

    • leo sur 14 décembre 2010 à 12h53

    Oui, on peut aussi taper avail dans un Shell, mais ca ne change rien au problème posé. Surtout que la barre peut être personnalisée pour afficher (ou non) la quantité de mémoire graphique, et peut même être cachée, ou simplement ne pas afficher ces informations sur un écran custom.

    Il faut un moyen de prévenir l’utilisateur quelque soit sa configuration sans qu’*il* ait à *vérifier* sa mémoire dès qu’il exécute une action.

    • henes sur 14 décembre 2010 à 15h49

    Je ne comprend pas bien… Pourquoi avertir (avec des popups ?) de manière intrusive ? En tant qu’utilisateur, cela m’ennuierait profondément… Ce n’est pas comme si le système arrêtait de fonctionner ou que tout explosait.

    Je trouve que la possibilité d’avoir un compteur numérique et/ou des barres colorées pour suivre l’utilisation de la mémoire est acceptable (et demandé depuis des années…). Surtout que, contrairement au vieux Workbench pourri qui gérait cela lui même, tout est géré par Intuition et affiché sur les autres écrans. Sauf les écrans custom sans barre de titre, comme tu le disais (un jeu, TVPaint…)

    De plus, toujours en tant qu’utilisateur, je n’ai jamais réussi à me retrouver dans la situation dont il est question (y compris et surtout sur mon Mac mini sur lequel j’utilise pourtant plusieurs écrans 1920*1080*32)… Donc, euh…

    Imagine si Windows/OSX/Tux avertissaient à chaque fois qu’ils commencent à swapper…

    • leo sur 14 décembre 2010 à 22h56

    Ce n’est pas comme si le système arrêtait de fonctionner ou que tout explosait.

    Sur la vidéo c’est clairement comme si tout exploser.

    Il y a des moyens non intrusifs de prévenir l’utilisateur. Windows prévient quand la mémoire swap est limite par exemple.

    Sur le W1.3, l’écran flashait quand on tentait de cliquer sur un exécutable et qu’il n’y avait pas assez de mémoire pour le charger: ca me parait par exemple pas mal…

    • henes sur 14 décembre 2010 à 23h23

    Ce n’est pas comme si le système arrêtait de fonctionner ou que tout explosait.

    Sur la vidéo c’est clairement comme si tout exploser.

    Sur la vidéo, cela rame à mort (bus bloqué, multitache out) mais tout fonctionne.

    Il y a des moyens non intrusifs de prévenir l’utilisateur. Windows prévient quand la mémoire swap est limite par exemple.

    C’est différent puisque cela doit signifier (?) que Windows va être à court de mémoire et que des allocations vont échouer…
    Dans OSX, l’appli s’arrete de fonctionner jusqu’à libération des resources par l’utilisateur.
    Ce sont des situations catastrophiques où l’OS attend une action de l’utilisateur…
    Sauf pour Linux qui commence carrément à tuer des processus au hasard pour récupérer de la mémoire…

    Sur le W1.3, l’écran flashait quand on tentait de cliquer sur un exécutable et qu’il n’y avait pas assez de mémoire pour le charger: ca me parait par exemple pas mal…

    Oui mais tous ces exemples sont des cas où des actions deviennent impossible.

    Ce n’est pas le cas ici… le système graphique assure qu’un bitmap qui a pu être alloué va continuer à être utilisable quoi qu’il arrive. Quitte à (automatiquement et sans aucune action de l’utilisateur) réorganiser la mémoire video, recopier le bitmap dans son tampon en mémoire fast et temporairement ramer à mort pendant ces opérations.

    • leo sur 15 décembre 2010 à 17h17

    Sur la vidéo, cela rame à mort (bus bloqué, multitache out) mais tout fonctionne.

    Oui, sauf que en tant qu’utilisateur: « bus bloqué, multitaches out » ca ne me parle pas. Quand ca ne reagit pas, c’est « planté » pour la plupart des utilisateurs, même si derrière rien n’est « planté »…

    Le but est de prévenir l’utilisateur que son ordi va ramer d’un coup, à tel point qu’il est planté (d’ailleurs un utilisateur normal va éteindre/redémarrer son ordi).

    Dans le cas de Windows, généralement le swap est augmenté automatiquement (c’est l’option par défaut), et ca va donc lagger. L’indication est là pour indiquer que ca va temporairement ramer…

    Oui mais tous ces exemples sont des cas où des actions deviennent impossible.

    Le système devient innaccessible pendant qu’il lagge à mort… Je ne vois pas la différence. Là un message le préviendrait l’utilisateur: « ca va ramer, il faudrait fermer quelques fenêtres ou un écran ».

    Tout le monde n’est pas censé connaître le fonctionnement interne du système et en prévenir les disfonctionnements et/ou effets extremes… Que ce soit un Unix, un Win, un Mac ou un MorphOS, quand ca se met à ramer d’un coup sans raison particulière, ca fout en l’air l’expérience utilisateur… Comme le problème ne peut être résolu sans une action de la part de l’utilisateur ca me paraît logique de le prévenir…
    Sur Unix (l’OS geek par excellence), on tue un process par défaut… Sur MorphOS, on swappe. Bien, mais l’utilisateur est pas censé le deviner…

    • henes sur 15 décembre 2010 à 21h48

    Le but est de prévenir l’utilisateur que son ordi va ramer d’un coup, à tel point qu’il est planté (d’ailleurs un utilisateur normal va éteindre/redémarrer son ordi).

    Couper le courant parce que le curseur de la souris s’est bloqué pendant 1/10e de seconde ?
    Windows a l’habitude de se bloquer sans mot dire pendant plusieurs dizaines de secondes lorsqu’il swap… ou minutes lorsqu’il dépend d’un timeout réseau… et je vois plutôt les gens attendre que cela passe…

    Je coupe un bout plutot que de tenter d’y repondre parce que je crois maintenant comprendre que tu a l’impression que la moindre ouverture de fenêtre détruit l’expérience utilisateur comme sur la vidéo bizarre de gibs… alors qu’en fait on constate plutôt un micro bloquage lors d’une grosse action…
    Comme lorsque l’on cycle entre deux écrans de 3Mo alors qu’on a que 4Mo de VRAM sur sa CV64… on constate un petit écran noir avant que l’écran suivant s’affiche.

    Je t’invite volontier à rebrancher ton Pegasos et à ressentir toi même le phénomène (que tu as sans doute déjà du vivre puisque CGX et P96 ont toujours fonctionné ainsi) avant d’aller plus loin…

    Sur Unix (l’OS geek par excellence), on tue un process par défaut… Sur MorphOS, on swappe. Bien, mais l’utilisateur est pas censé le deviner…

    Pas Unix mais uniquement Linux. A ma connaissance, les autres Unix ne sont pas cassés ainsi (à part OSX qui bloque l’application)… et font juste échouer l’allocation comme il se doit.

    Et effectivement, je ne vois pas pourquoi l’utilisateur devrait être notifié des relogements mémoire en cours…

    Je pense qu’il aurait par contre pu être intéressant de discuter si Intuition ne permetrait pas d’utiliser la composition trop facilement ou s’il n’y aurait pas moyen d’accélérer certains trucs à l’avenir… mais bon…

    • LorD sur 16 décembre 2010 à 12h41

    @Leo: Non Windows n’averti pas quand il va ramer. Pour preuve, les utilisateur de mon espace informatique lancent 20 navigateurs avant de se rendre compte qu’il fallait juste attendre… et même le sablier n’est pas présent !

    Pareil quand on ouvre un soft lourd, ça rame et pas d’avertissement.

    De toute façon, il vaut mieux avertir dans les cas extrêmes, mais pas dans des lags temporaires. Sinon on aurait des avertisseur sans arrêt.

    • Foul sur 16 décembre 2010 à 13h09

    uhmm question con .. j’ai réussi à booter sur le CD, installer Morphos sur un G3 .. mais après redémarrage .. ca reste sur le texte open firmware machin bidule en haut et ca pas plus loin.

    J’ai lu je sais pas ou qu’il faut appuyer sur pomme + ctrl + O + F je crois pour ouvrir le firmware ..et modifier la séquence de boot.

    Le Prob .. comment je fais avec un clavier PC ?? 😀

  2. uhmm question con .. j’ai réussi à booter sur le CD, installer Morphos sur un G3 .. mais après redémarrage .. ca reste sur le texte open firmware machin bidule en haut et ca pas plus loin.

    c’est un peu confus… et surtout tu devrais plutôt ouvrir un sujet là dessus plutôt qu’en commentaire d’une news.
    bon sinon tu dis G3….. tu parles d’un pegasos ou d’un mac? parce que les macs G3 ne sont pas supportés par morphos, et le truc pomme machin machin c’est réservé aux macs, pas au pegasos.

    • leo sur 16 décembre 2010 à 15h57

    @LorD: je parlais de MorphOS. Et le sablier est là pour indiquer que l’application est en cours de chargement en arrière plan sur Windows… Encore un indicateur, mais méconnu…

    Sur Amiga il n’y a forcément pas ca puisque le chargement d’une application bloque tout le workbench (à moins d’avoir DOpus/AmigaOS NG).

    • Foul sur 16 décembre 2010 à 16h15

    Powermac G3 .. mais pas supporté ca règle le prob 🙁

    • LorD sur 16 décembre 2010 à 18h49

    @Leo : le sablier ne s’affiche qu’au début du chargement des applications, après, il apparait furtivement, voir pas du tout (je parle de XP là, ça s’est peut être amélioré avec seven, mais je l’utilise rarement).

    Mais bon, là n’est pas le débat.

    L’idée d’indicateur est pas mal dans le fond, mais bon, seulement dans les cas critiques (manque de RAM, VRAM, application plantée, erreur disque), pour la lenteur, il suffit de subir pour le savoir non ? Ca rame… et ben ça rame = il faut attendre ou fermer un truc, rien de plus logique.

    Mais une ram un peu trop basse peut être signalée pour ne pas lancer un autre logiciel par ex.

    Enfin, personnellement, je m’en fout, en l’état cela me convient.

  3. Pourquoi pas un message d’avertissement avec la possibilité de ne pas le réafficher, mais qu’un utilisateur débutant puisse savoir la source du ralentissement.
    Ou alors, un icone screenbar /!\ qui s’affiche avec une bulle d’avertissement.

    Un utilisateur averti vaut mieux qu’un utilisateur qui pense que MorphOS ne sait pas gérer 4 fenêtres…

    • leo sur 16 décembre 2010 à 20h28

    et ben ça rame = il faut attendre ou fermer un truc, rien de plus logique.

    Il faut attendre ou ca a planté ? Il faut fermer quelque chose, ou juste attendre ?

    C’est bien ca le problème: tu ne peux pas le deviner…

    La lenteur peut venir de plein de causes:

    – un programme qui hit en boucle
    – un programme qui bouffe trop de cpu
    – le système qui alloue des bitmap en fastram et swap
    – etc…

    A chaque fois tu as une solution (ou non) et différente.

    Avertir l’utilisateur qu’il est à court de VRAM me paraît être une bonne idée. Alerte non intrusive (et que les geeks pourront désactiver biensûr, comme la plupart des alertes d’ailleurs). Voila mon point de vue 🙂

Les commentaires sont désactivés.

Amiga Impact