[quote="Mungomango"]
Und was den Freak-Faktor angeht - ein System hat IMHO einen Frak-Faktor, wenn es einen sehr geringen Verbreitungsgrad hat. Kommt das OS dann auf irgendeinem Wege auf x86-Hardware, ist fast immer Windows im Spiel. Und wenn Windows schon mal da ist, wird's halt gleich verwendet. Wegen den Treibern, den Programmen und der Zusatzhardware eben... Ist ein OS verbreiteter, ist der Freak-Faktor irgendwo bei Null.
RISC OS ist aus dieser Sicht gesehen in einer wirklich prekären Lage. Die Hardware ist hoffnungslos veraltet und eine richtige Killerapplikation ist auch nicht mehr da. Und am OS müßte auch mal kräftig erneuert werden. Außerdem wandern auch alte RISC OS-User stetig ab. Es gibt ja keine Demo-Szene mehr, kaum noch Entwickler, etc.
[/quote]
Deswegen kann ich mich ja viel mehr für eine PPC-Portierung erwärmen. Performancemäßig immer noch ein großer Sprung, in Assembler nicht so grauenhaft zu programmieren wie x86, größere Verfügbarkeit aktuelle Grafikkarten und anderer Hardware. Und die Auswahl an verfügbaren PPC-Boards ist auch im Steigen.
So würde der Freakfaktor doch erhalten bleiben, man hätt mehr Leistung und aktuelle Peripherie. Die Auswahl von Steckkarten ist natürlich nicht so immens groß wie in der x86 Schiene, aber doch locker ausreichend sag ich mal. Verschiedene Linux-Distributionen laufen auch drauf.
Bleibt halt immer noch das Problem der RISC OS Binärkompatibilität. Um einen ARM-Emulator kommt man so oder so nicht herum, selbst wenn die SWIs nun native laufen würden.
RISC OS 6
Moderator: Patrick
-
Mungomango
- RISCOS Experte
- Beiträge: 364
- Registriert: 02 Mär 2005, 22:21
Eine Portierung auf PPC wäre natürlich ein gewaltiger Schritt. Und der Freak-Faktor würde mitgehen. Allerdings bleibt die Frage, ob es einen Unterschied macht, auf x86 oder PPC zu portieren. Beides dürfte man kaum auf der linken Arschbacke absitzen können.
Und wenn man schon den Schritt der gewaltigen Portierung angeht, sollte man dann nicht auf den Quasi-Standard setzen? Also auf Hardware, die leicht zu bekommen ist und deren Entwicklung systemübergreifend voranschreitet? Auf einer PPC-Plattform ist man wieder auf Deibl komm raus auf wenige Firmen angewiesen, die die Hardware pflegen und entwickeln. Was dabei rauskommt, hat man bei RISC OS leidlich erfahren müssen. Freak-Faktor hin oder her...
Und wenn man schon den Schritt der gewaltigen Portierung angeht, sollte man dann nicht auf den Quasi-Standard setzen? Also auf Hardware, die leicht zu bekommen ist und deren Entwicklung systemübergreifend voranschreitet? Auf einer PPC-Plattform ist man wieder auf Deibl komm raus auf wenige Firmen angewiesen, die die Hardware pflegen und entwickeln. Was dabei rauskommt, hat man bei RISC OS leidlich erfahren müssen. Freak-Faktor hin oder her...
Wer die Wahrheit sagt, braucht ein schnelles Pferd.
Also Mac-User stört es ja auch nicht, das auf einmal ihr OS einen Unix-Mach-Kernel hat. Auch stört es sie nicht, das sie jetzt x86 haben.
Der Schritt von PPC nach x86 war bei denen auch so, das alte PPC-Mac-Software autom. in einem PPC-Emu (Rosetta) lief. Heute gibt es Universal-Binaries, d.h. die Programme werden sowohl in PPC- als auch x86-Variante ausgeliefert (in einer einizigen ausführbaren Datei). Je nach CPU wird in die Binary an das Offset gesprungen (ist ja nur ein Jump). Problem mit alter und neuer Software gelöst. Die Mac-User freuen sich. Freak-Faktor der CPU oder des OS-Kerns ist latte. Trotzdem hat das MacOS X Alleinstellungsmerkmale... komisch.
Der Schritt von PPC nach x86 war bei denen auch so, das alte PPC-Mac-Software autom. in einem PPC-Emu (Rosetta) lief. Heute gibt es Universal-Binaries, d.h. die Programme werden sowohl in PPC- als auch x86-Variante ausgeliefert (in einer einizigen ausführbaren Datei). Je nach CPU wird in die Binary an das Offset gesprungen (ist ja nur ein Jump). Problem mit alter und neuer Software gelöst. Die Mac-User freuen sich. Freak-Faktor der CPU oder des OS-Kerns ist latte. Trotzdem hat das MacOS X Alleinstellungsmerkmale... komisch.
Eines spricht ganz gewaltig gegen eine Emulation unter Windows:
Windows.
Ne ernsthaft... ich habe den Scheiss vor 2 Wochen runtergeschmissen und stelle jetzt komplett auf Linux um.
Das ist zwar auch ein Scheiss - aber ein Scheiss mit System :)
Man muss das System nur lernen. Und man kann soweit zurechtbiegen, bis es das mach was man will und wie man es will.
Und den RPCEm gibt es auch... muss nur noch lernen wie man ihn compiliert.
Mfg
Gryf ap Llandrysgryf
Windows.
Ne ernsthaft... ich habe den Scheiss vor 2 Wochen runtergeschmissen und stelle jetzt komplett auf Linux um.
Das ist zwar auch ein Scheiss - aber ein Scheiss mit System :)
Man muss das System nur lernen. Und man kann soweit zurechtbiegen, bis es das mach was man will und wie man es will.
Und den RPCEm gibt es auch... muss nur noch lernen wie man ihn compiliert.
Mfg
Gryf ap Llandrysgryf
ct.ger proofed Acorn Apologet
Eine interessante Frage wäre, ob denn ein Emulator mit optimierendem JIT-Compiler nicht schnell genug wäre, um das OS überhaupt nicht portieren zu müssen.
Zunächst: meine Erfahrungen mit Java verführen mich zu der Aussage, dass eine virtuelle Maschine ähnlich schnell sein kann wie plattformspezifisch compilierter Code. Nun ist natürlich der ARM-Befehlssatz kein speziell für eine virtuelle Maschine entworfener Code, aber der Java-Bytecode ist da ehrlich gesagt nicht viel besser. Der sehr simple JIT im VirtualRPC, der auf einem 2 GHz x86 schon die Leistungsfähigkeit eines 600 MHz XScale übertrifft, bestärkt mich weiter in meiner Ansicht.
Weiterhin muss man sehen, dass die meisten Dinge, die RISC OS so tut, nicht wirklich zeitkritisch ist. Die Dinge, die uns auf Applikationsseite laufzeittechnisch in die Suppe spucken, sind Laufzeiten die auf Applikationsseite entstehen, nicht im OS. Schon wenn man im OS die Dinge x86-native portieren würde, die für die Visualisierung sorgen (sprich VDUs, SpriteOps, FontManager und Konsorten - alles das, was die ViewFinder-Firmware so außerordentlich erfolreich patcht), und der JIT das weiss, so dass er die SWIs im compilierten Code nicht emuliert, sondern durch direkte Calls ersetzt - ich denke, die Geschwindigkeit auf OS-Seite wäre kaum von einer echten native-Lösung unterscheidbar.
Alles, was also für eine "x86-Portierung" notwendig wäre, ist eine leistungsfähige virtuelle Maschine mit JIT-Compiler. Mit einem geeigneten Emulator drumrum, der gut portierbar ist (wie eben RPCEmu), könnte man RISC OS als "das universelle Betriebssystem" anpreisen. Ob das dann auf Windows läuft oder auf Linux oder einem schmalen Microkernel a la Mach wäre schlicht egal.
Ein anderer Ansatz wäre die maschinelle Konvertierung der ASM-Sourcen von RISC OS von ARM nach. Wenn man nur die Binaries hat, ist das schlichtweg unmöglich. Wenn man aber die Sourcen hat, wäre das denkbar. Da man aber sowieso einen Emulator braucht für die Applikationen und für Module, die nicht in Sourceform vorliegen, hätte die erste skizzierte Lösung vom technischen Standpunkt aus mehr Charme. Die zweite Lösung könnte man dann immer noch hinterherschieben, wenn es sich als notwendig erweist.
Sollte RISC OS in Kürze und in Gänze als Open Source zur Verfügung stehen und damit die Emulator-Lizenzproblematik wegfallen, bin ich mir sicher, dass sich jemand des Themas annimmt.
Steffen
Zunächst: meine Erfahrungen mit Java verführen mich zu der Aussage, dass eine virtuelle Maschine ähnlich schnell sein kann wie plattformspezifisch compilierter Code. Nun ist natürlich der ARM-Befehlssatz kein speziell für eine virtuelle Maschine entworfener Code, aber der Java-Bytecode ist da ehrlich gesagt nicht viel besser. Der sehr simple JIT im VirtualRPC, der auf einem 2 GHz x86 schon die Leistungsfähigkeit eines 600 MHz XScale übertrifft, bestärkt mich weiter in meiner Ansicht.
Weiterhin muss man sehen, dass die meisten Dinge, die RISC OS so tut, nicht wirklich zeitkritisch ist. Die Dinge, die uns auf Applikationsseite laufzeittechnisch in die Suppe spucken, sind Laufzeiten die auf Applikationsseite entstehen, nicht im OS. Schon wenn man im OS die Dinge x86-native portieren würde, die für die Visualisierung sorgen (sprich VDUs, SpriteOps, FontManager und Konsorten - alles das, was die ViewFinder-Firmware so außerordentlich erfolreich patcht), und der JIT das weiss, so dass er die SWIs im compilierten Code nicht emuliert, sondern durch direkte Calls ersetzt - ich denke, die Geschwindigkeit auf OS-Seite wäre kaum von einer echten native-Lösung unterscheidbar.
Alles, was also für eine "x86-Portierung" notwendig wäre, ist eine leistungsfähige virtuelle Maschine mit JIT-Compiler. Mit einem geeigneten Emulator drumrum, der gut portierbar ist (wie eben RPCEmu), könnte man RISC OS als "das universelle Betriebssystem" anpreisen. Ob das dann auf Windows läuft oder auf Linux oder einem schmalen Microkernel a la Mach wäre schlicht egal.
Ein anderer Ansatz wäre die maschinelle Konvertierung der ASM-Sourcen von RISC OS von ARM nach
Sollte RISC OS in Kürze und in Gänze als Open Source zur Verfügung stehen und damit die Emulator-Lizenzproblematik wegfallen, bin ich mir sicher, dass sich jemand des Themas annimmt.
Steffen
[quote="hubersn"]
Alles, was also für eine "x86-Portierung" notwendig wäre, ist eine leistungsfähige virtuelle Maschine mit JIT-Compiler. Mit einem geeigneten Emulator drumrum, der gut portierbar ist (wie eben RPCEmu), könnte man RISC OS als "das universelle Betriebssystem" anpreisen.
[/quote]
Hat es sowas in der Art nicht schon einmal gegeben ? Hieß damals TAOS, war so ca. 1994. Konnte auf jeder beliebigen Prozessorplattform laufen, war multitaskingfähig, multithreadfähig (bzw. basiert) und sollte wohl als "Schicht" unter RiscOS 'eingezogen' werden, damit Acorn seine 3D Oberfläche zum Laufen bekommt - zumindest habe ich das so verstanden.
Später dann gab es das Ganze sogar mal richtig zum Ansehen als AmigaDE SDK, was aber irgendwie auch wieder untergegangen ist. Zumindest hat es nie eine Nutzerversion davon gegeben.
Aber genial wäre das so in der Art:
Bios - Linux (o.ä.) - TAOS - Emulator - RiscOS - (alte) Anwendung
bzw.
Bios - TAOS - RiscOS - neue/umgewandelte Anwendung
Vorteil: Unabhängigkeit von der Prozessorarchitektur, automatische Nutzung der Multikernprozessoren (damals ging es um Hydra).
Aktuell gibt es das Ganze unter dem Namen Elate bzw. intent für Handys, Konsolen und solche Dinge.
Schönen Gruß,
Sebastian
Alles, was also für eine "x86-Portierung" notwendig wäre, ist eine leistungsfähige virtuelle Maschine mit JIT-Compiler. Mit einem geeigneten Emulator drumrum, der gut portierbar ist (wie eben RPCEmu), könnte man RISC OS als "das universelle Betriebssystem" anpreisen.
[/quote]
Hat es sowas in der Art nicht schon einmal gegeben ? Hieß damals TAOS, war so ca. 1994. Konnte auf jeder beliebigen Prozessorplattform laufen, war multitaskingfähig, multithreadfähig (bzw. basiert) und sollte wohl als "Schicht" unter RiscOS 'eingezogen' werden, damit Acorn seine 3D Oberfläche zum Laufen bekommt - zumindest habe ich das so verstanden.
Später dann gab es das Ganze sogar mal richtig zum Ansehen als AmigaDE SDK, was aber irgendwie auch wieder untergegangen ist. Zumindest hat es nie eine Nutzerversion davon gegeben.
Aber genial wäre das so in der Art:
Bios - Linux (o.ä.) - TAOS - Emulator - RiscOS - (alte) Anwendung
bzw.
Bios - TAOS - RiscOS - neue/umgewandelte Anwendung
Vorteil: Unabhängigkeit von der Prozessorarchitektur, automatische Nutzung der Multikernprozessoren (damals ging es um Hydra).
Aktuell gibt es das Ganze unter dem Namen Elate bzw. intent für Handys, Konsolen und solche Dinge.
Schönen Gruß,
Sebastian
[quote="Gryfie"]Eines spricht ganz gewaltig gegen eine Emulation unter Windows:
Windows.
[...][/quote]
Da bin ich derselben Meinung. Nicht weil ich Win verteufle, sondern weil man sich dann automatisch alle Probleme des Host-Systems einhandelt. Ich denke hier vor allem an die Viren, Malware und Spyware-Problematik.
@hubersn:
Stimmt. An RISC OS selber gibts Geschwindigkeitsmäßig sicher nix zu bekrittelnn. Was net oder nur sehr lahmarschig läuft wie CD rippen, xvid-divx schauen, DVD rippen sind ka alles CPU-bound Applikationen.
Ich wär sehr für eine Microkernel oder Linuxkernel-Lösung als Unterbau, da man sich dann die Windows-Probleme nicht einhandelt. Ideal wär, wenn das einfach als ganzes Paket erhältlich ist, wo man nur noch ne Partition erstellen muß, und dann einfach das ganze BS + Kernel draufknallen, so wie von anderen PC-Betriebssystemen gewohnt. Und dann noch eine Option den Kernel updaten zu können, zwecks Treiberaktualisierung - das wärs.
So eine Emulatorlösung würd ich mir sicher zulegen! Obwohl ich dann eher der Typ bin, ders nur als Ergänzung zu einer 'richtigen' Oldschool RISC OS Hardware sieht. ;)
@naitsabes:
Acorn wollte mal ne 3D-Oberfläche Einführen?? Noch nie davon gehört... Gibts irgendwo was zu finden, wie das genauer ausgesehen hätte?
Windows.
[...][/quote]
Da bin ich derselben Meinung. Nicht weil ich Win verteufle, sondern weil man sich dann automatisch alle Probleme des Host-Systems einhandelt. Ich denke hier vor allem an die Viren, Malware und Spyware-Problematik.
@hubersn:
Stimmt. An RISC OS selber gibts Geschwindigkeitsmäßig sicher nix zu bekrittelnn. Was net oder nur sehr lahmarschig läuft wie CD rippen, xvid-divx schauen, DVD rippen sind ka alles CPU-bound Applikationen.
Ich wär sehr für eine Microkernel oder Linuxkernel-Lösung als Unterbau, da man sich dann die Windows-Probleme nicht einhandelt. Ideal wär, wenn das einfach als ganzes Paket erhältlich ist, wo man nur noch ne Partition erstellen muß, und dann einfach das ganze BS + Kernel draufknallen, so wie von anderen PC-Betriebssystemen gewohnt. Und dann noch eine Option den Kernel updaten zu können, zwecks Treiberaktualisierung - das wärs.
So eine Emulatorlösung würd ich mir sicher zulegen! Obwohl ich dann eher der Typ bin, ders nur als Ergänzung zu einer 'richtigen' Oldschool RISC OS Hardware sieht. ;)
@naitsabes:
Acorn wollte mal ne 3D-Oberfläche Einführen?? Noch nie davon gehört... Gibts irgendwo was zu finden, wie das genauer ausgesehen hätte?
-
Mungomango
- RISCOS Experte
- Beiträge: 364
- Registriert: 02 Mär 2005, 22:21
Ja, es gab mal eine 3D-Oberfläche. Die geisterte auch immer mal als Demo durch die Reihen. Ich hatte das Ding mal zu RiscPC-Zeiten. Aber mangels 3D-Hardware war's dann wohl nix mit 3D-Desktop. Das Ding lief elend lahm. Allerdings weiß ich nicht mehr, ob mein RiscPC da schon einen SA drin hatte.
Davon abgesehen hat mich das, was man zu sehen bekam, nicht umgehauen. Wenn ich mich recht entsinne, sah man halt ein Büro. Und demzufolge einen Schreibtisch (Desktop), Aktenschränke (Dateien), etc. Also nix anderes als ein Büro, in 3D, in dem man sich entsprechend umschauen und auf die einzelnen Objekte klicken konnte, die dann die entsprechenden Funktionen bargen. Ich fand's jedenfalls ziemlich unergonomisch.
Davon abgesehen hat mich das, was man zu sehen bekam, nicht umgehauen. Wenn ich mich recht entsinne, sah man halt ein Büro. Und demzufolge einen Schreibtisch (Desktop), Aktenschränke (Dateien), etc. Also nix anderes als ein Büro, in 3D, in dem man sich entsprechend umschauen und auf die einzelnen Objekte klicken konnte, die dann die entsprechenden Funktionen bargen. Ich fand's jedenfalls ziemlich unergonomisch.
Wer die Wahrheit sagt, braucht ein schnelles Pferd.
3D Rooms hiess die Oberflaeche.
Leider war sie wohl wirklich nur ein Versuch. Ich weiss nicht wo ich das mal gesehen habe - aber die Beschreibung von Mungomango ist zutreffend.
Bei [url]http://www.drobe.co.uk/gallery/Rooms3A-Acorn-3D-desktop-demo[/url] gibt es noch ein paar Bilder zum Ansehen.
Sebastian
Leider war sie wohl wirklich nur ein Versuch. Ich weiss nicht wo ich das mal gesehen habe - aber die Beschreibung von Mungomango ist zutreffend.
Bei [url]http://www.drobe.co.uk/gallery/Rooms3A-Acorn-3D-desktop-demo[/url] gibt es noch ein paar Bilder zum Ansehen.
Sebastian
-
Mungomango
- RISCOS Experte
- Beiträge: 364
- Registriert: 02 Mär 2005, 22:21
[quote="naitsabes"]3D Rooms hiess die Oberflaeche.
Leider war sie wohl wirklich nur ein Versuch. Ich weiss nicht wo ich das mal gesehen habe - aber die Beschreibung von Mungomango ist zutreffend.
Bei [url]http://www.drobe.co.uk/gallery/Rooms3A-Acorn-3D-desktop-demo[/url] gibt es noch ein paar Bilder zum Ansehen.
Sebastian
[/quote]
Ja, genau, das war das Ding. Eine ziemliche Ruckelorgie. Und bis mal überhaupt was am Bildschirm erschienen ist, konnte man sich leicht einen Kaffee holen ;)
Von solchen Desktops halte ich nicht viel. Es gab von vielen Herstellern Versuche in dieser Art. Man wollte halt modern sein, was aber ziemlich nach hinten losging. Aber immerhin wurden auch unter RISC OS entsprechende Versuche unternommen.
Die ergonomischste Art, einen Computer zu bedienen, ist meiner Meinung nach ein Grafiktablett mit einem Desktop, wie ihn jeder kennt. Seit ich ein Grafiktablett (Wacom Intuos 3) am PC habe, habe ich die Maus nicht mehr angefaßt.
Leider war sie wohl wirklich nur ein Versuch. Ich weiss nicht wo ich das mal gesehen habe - aber die Beschreibung von Mungomango ist zutreffend.
Bei [url]http://www.drobe.co.uk/gallery/Rooms3A-Acorn-3D-desktop-demo[/url] gibt es noch ein paar Bilder zum Ansehen.
Sebastian
[/quote]
Ja, genau, das war das Ding. Eine ziemliche Ruckelorgie. Und bis mal überhaupt was am Bildschirm erschienen ist, konnte man sich leicht einen Kaffee holen ;)
Von solchen Desktops halte ich nicht viel. Es gab von vielen Herstellern Versuche in dieser Art. Man wollte halt modern sein, was aber ziemlich nach hinten losging. Aber immerhin wurden auch unter RISC OS entsprechende Versuche unternommen.
Die ergonomischste Art, einen Computer zu bedienen, ist meiner Meinung nach ein Grafiktablett mit einem Desktop, wie ihn jeder kennt. Seit ich ein Grafiktablett (Wacom Intuos 3) am PC habe, habe ich die Maus nicht mehr angefaßt.
Wer die Wahrheit sagt, braucht ein schnelles Pferd.