Lu ce matin, un article passionnant nous raconte l'histoire de RiscOS (le système d'Acorn Computers) depuis les années 80 en s'intéressant aux possibilités de l'adapter au potentiel du matériel actuel.
Ces systèmes des années 80 (ceux d'Acorn, Commodore, Atari, Apple, Microsoft — et d'autres) ont leurs avantages et défauts en partage : ils sont rapides mais plantogènes. Pour faciliter leur conception et privilégier la vitesse, ces OS utilisaient le multi-tâche coopératif avec ses défaut de gestion de mémoire et étaient très proche du matériel, avec beaucoup d'assembleur. Je résume et simplifie bien entendu.
Quand les microprocesseurs ont évolué, apportant la protection mémoire, le multi-threading, le multi-processeur, et la possibilité du multi-tâche préemptif (et sa lenteur), aucun de ces systèmes n'a pu en tirer parti. Ils traitaient le proco comme un CPU de la génération d'avant qui va un peu plus vite. Sans parler du binaire ! quand des puces 16 bits, 32 bits, 64 bits sont apparus, ils continuaient de les utiliser en 8, 16 ou 32 bits (26 bits pour RiscOS), sans possibilité d'évolution.
Aucun de ces concepteur à part Microsoft n'a fait les changements nécessaires : tout reprendre à zéro en ajoutant des couches de compatibilité pour continuer de lancer les programmes d'avant. De fait, on peut toujours lancer des vieux programmes DOS ou Windows sur Windows 10, bien que le système n'ait plus rien à voir (de là, le côté « bouffi » du système de Microsoft). À la fin des années 90, Apple n'avait donc guère le choix en adoptant NextStep pour base de MacOSX : macOS ne pouvait pas évoluer. Je le répète, c'est un résumé grossier.
Cette compatibilé binaire est un fameux dilemme d'ailleurs. Plutôt que trop grossir, MacOSX l'évacue régulièrement. Linux choisit la compatibilité du code source recompilable sur plein d'architectures, mais va donc lancer un programme propriétaire pour Linux 2.6 sur un noyau actuel ! les distros ne sont pas adaptées. Déjà pour le 32 bits elles ont fait un effort, mais c'est parce que les processeurs sont compatibles — jusqu'à quand ? c'est toujours du résumé, pas taper merci.
Conclusion, je n'ai pas résumé l'histoire d'Acorn ni celles des puces ARM (d'Acorn aussi) pour vous laisser le plaisir de la lire dans cet article écrit en anglais simple, lisible, accessible. Comme RiscOS.
# Amiga
Posté par bunam . Évalué à 10. Dernière modification le 10 octobre 2020 à 22:30.
AmigaOS était en multitâche préemptif dès le début.
https://fr.wikipedia.org/wiki/Multitâche_préemptif
Aussi on avait un patch qui priorisait mieux l'application en 1er plan pour avoir un peu plus de souplesse d'utilisation, mais les taches d'arrière-plan étaient fortement ralenties du coup.
Le matos était excellent, en virtualisation de macOS ça tournait mieux que sur de l’Apple à CPU équivalent ;)
[^] # Re: Amiga
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 5.
Un système très en avance pour l'époque <3
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# ABI Linux <> userspace
Posté par Alexandre Belloni (site web personnel) . Évalué à 10. Dernière modification le 10 octobre 2020 à 23:23.
C'est tout simplement faux, ça n'est pas un problème de noyau. Le noyau Linux a pour politique de ne pas casser l'ABI avec les binaires. Le problème du vieux programme propriétaire, ça va être le reste de l'espace utilisateur et notamment la libc, les libs graphiques, etc… Mais un binaire propriétaire compilé en statique qui fonctionnait sur un noyau 2.6 doit continuer à fonctionner sur un noyau récent. Sinon, c'est un bug du noyau et il doit être corrigé.
D'ailleurs, l'article d'origine ne parle de pas de problème avec le noyau.
[^] # Re: ABI Linux <> userspace
Posté par claudex . Évalué à 7.
La libc aussi garde une compatibilité ABI, c'est plutôt du côté des autres bibliothèques que la compatibilité est cassée.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ABI Linux <> userspace
Posté par orfenor . Évalué à 5.
Tiens une bonne idée : résumer en ajoutant des trucs faux pour faire lire l'article :-)
J'avais mal compris, merci de la précision.
# résumé
Posté par stopspam . Évalué à 3.
Joli teasing et donc je m'en vais de ce pas lire l'article que tu conseilles
# dis lemme !
Posté par BAud (site web personnel) . Évalué à 3.
Même si c'est une erreur fréquente, c'est bien dilemme, oui le terme lemme comme en maths ;-)
Bon, il y a un RicOS qui traîne aussi au passage avec un S perdu et une compatibilité ayant perdu son lien avec l'IT.
Si tu as d'autres articles revenant sur les années 90 (Archimedes, NextSTEP… RISC vs CISC…), n'hésite pas _o/ (moui, j'étais un lecteur assidu de Jerry Pournelle dans Byte, et avec son pote Larry Niven aussi d'ailleurs :D OS/2 avec toutes ses qualités ne s'est que peu retrouvé dans NT4.1 qui était à la limite de l'utilisable, W2K en reprenant quelques bons éléments que ME et XP ont fait oublier à beaucoup de monde dans le grand public… même 8.1 n'a pas atteint le niveau catastrophique envisageable, autant attendre win11 s'il existe un jour).
[^] # Re: dis lemme !
Posté par gUI (Mastodon) . Évalué à 3.
corrigé
corrigé
ainsi qu'un Atari qui a pris un T de trop.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
# Presque en synchro
Posté par Tarnyko (site web personnel) . Évalué à 10. Dernière modification le 11 octobre 2020 à 13:43.
À deux semaines près ; je vais bientôt être l'heureux possesseur d'un Acorn Archimedes A3010.
C'est une machine qui m'a toujours fasciné, par son exotisme mais aussi sa parenté architecturale avec nos smartphones modernes.
On peut installer un Linux 2.0.31 dessus ; dans ce cas, l'ABI est la même que sur un Linux 2.x ARM "classique". Les binaires sont donc transférables. Par exemple, ce code une fois "assemblé" marchera à la fois sur Archimedes et une autre carte ARM :
Sur un Linux plus récent, non seulement l'alignement change (on passe de l'architecture "arm" à "armel" par défaut sur Debian), ce qui fait que le binaire ne se transfère plus; mais en plus on passe de l'OABI historique à l'EABI, ce qui implique de changer le syscall à la fin:
(ce qui, par ailleurs, marchera aussi sur Android).
RiscOS, lui, intègre carrément un éditeur pour exécuter de l'assembleur directement. Le format est bien sûr différent, et depuis le vieil Archimedes jusqu'à la récente Raspberry Pi, reste constant grâce à des genres de macros :
C'est vraiment un excellent OS pour s'initier au bas niveau sur ARM ; un truc d'étudiant. Niveau écosystème soft, on est bien sûr bien loin derrière Tutux…
# MacOS
Posté par superna (site web personnel) . Évalué à 1.
Mouais je veux dire MacOS est passé de PowerPC, à Intel, à ARM avec les iPhone/iPads et maintenant sur ARM sur les Macs.
Pour un OS qui n'est pas évolutif, je trouve qu'il évolue vachement !
Il est au contraire vachement évolutif car il est basé sur un micro-noyau et la couche kernel est très fine, tu dois confondre avec la couche "Framework" et la encore, ils ont su faire évoluer leur couche applicative de manière spectaculaire en 20ans.
[^] # Re: MacOS
Posté par arnaud.c . Évalué à 3.
Il faut bien distinguer l'ancien Mac OS et son remplaçant : Mac OS X.
MacOS est l'OS des années 80/90 qui se nommait au départ System[1,7] et qui a tourné sur 68k et PowerPC.
MacOS*X* est une évolution de l'OS OpenStep de NeXT avec le look'n feel d'Apple. Le marketing l'a nommé successivement Rapsody (1998), MacOSX (2001) puis OSX et aujourd'hui MacOS. Il a débuté sur les machines PowerPC puis Intel et bientôt ARM.
Les premiers MacOSX proposaient Classic qui exécutait un environnement capable d'exécuter les anciennes applications compilés pour MacOS9.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.