Wer es noch nicht gelesen hat:
http://www.golem.de/0909/69879.html
Mal sehen ob RISC OS davon profitieren kann.
ARMs Cortex A9 läuft mit mehr als 2 GHz
Moderator: Patrick
Hier auch: http://www.heise.de/newsticker/ARM-Cortex-A9-Entweder-schnell-oder-sparsam--/meldung/145408
Aber erstmal muss sich ein Lizenznehmer für diesen Cortex-A9 finden und dann muss dieser den noch bauen und dann muss diesee Prozessor seinen Weg in ein für RISC OS geeignetes Gerät finden und dann muss RISC OS noch diese Hardware unterstützen. Alles, was nicht in den nächsten Monaten zu erwarten ist, leider. Aber Jeffrey Lee leistet ja schon [url=http://www.riscosopen.org/forum/forums/5/topics/166]Vorarbeit[/url] für die RISC OS Unterstüzung.
Zusätzlich erwarte ich das dieser Prozessor eher für 1,5 bis 1,8 GHz als für 2 GHz gebaut wird. Fehlt noch die Unterstüzung von zwei Kernen in RISC OS. Da habe ich aber keine Hoffnung. Aber eventuell kann man den zweiten Kern für andere Dinge "missbrauchen".
Aber erstmal muss sich ein Lizenznehmer für diesen Cortex-A9 finden und dann muss dieser den noch bauen und dann muss diesee Prozessor seinen Weg in ein für RISC OS geeignetes Gerät finden und dann muss RISC OS noch diese Hardware unterstützen. Alles, was nicht in den nächsten Monaten zu erwarten ist, leider. Aber Jeffrey Lee leistet ja schon [url=http://www.riscosopen.org/forum/forums/5/topics/166]Vorarbeit[/url] für die RISC OS Unterstüzung.
Zusätzlich erwarte ich das dieser Prozessor eher für 1,5 bis 1,8 GHz als für 2 GHz gebaut wird. Fehlt noch die Unterstüzung von zwei Kernen in RISC OS. Da habe ich aber keine Hoffnung. Aber eventuell kann man den zweiten Kern für andere Dinge "missbrauchen".
Diese ganzen neuen CPU-Designs sind ja ganz nett. Aber sie helfen dem RISC OS Markt nicht wirklich weiter.
Wenn ich so lese, wie fehlerhaft der A9home Computer (heute noch) sein soll, sieht das mit einer CortexA9 CPU nicht besser aus (ich meine nicht das die CPU fehlerhaft ist!). Eine Frage ist auch, ob RISC OS überhaupt mit Multicore-CPUs auskommt?
Aber selbst das finde ich noch nicht mal wichtig für die RISC OS Zukunft. Was mich traurig stimmt, ist das RISC OS anscheinend (bitte korrigiert mich!) immer noch keinen Speicherschutz hat?! Obwohl mittlerweile eine MMU serienmäßig ist (seit ARM610-Zeiten). Speicherschutz ist DAS Feature das ich mir wünsche. Was nützt mir die schnellste CPU, wenn ein Programmfehler das ganze System zum Absturz bringt?
Ich weiß leider nicht, ob solche Features bei RISC OS überhaupt wirtschaftlich implementierbar sind? Da müssten mal die Insider von RISC OS ein Statement abgeben. Denn so können Außenstehende (wie ich) nur spekulieren.
Zurück auf die Hardware: es muß dann auch jemand einen Desktop-Computer bzw. -Mainboard bauen. Denn die ARM-CPUs werden ja hauptsächlich in mobilen und embedded Geräten verbaut. Hilft dem RISC OS Markt nicht wirklich... zumindest mir nicht.
Wenn ich so lese, wie fehlerhaft der A9home Computer (heute noch) sein soll, sieht das mit einer CortexA9 CPU nicht besser aus (ich meine nicht das die CPU fehlerhaft ist!). Eine Frage ist auch, ob RISC OS überhaupt mit Multicore-CPUs auskommt?
Aber selbst das finde ich noch nicht mal wichtig für die RISC OS Zukunft. Was mich traurig stimmt, ist das RISC OS anscheinend (bitte korrigiert mich!) immer noch keinen Speicherschutz hat?! Obwohl mittlerweile eine MMU serienmäßig ist (seit ARM610-Zeiten). Speicherschutz ist DAS Feature das ich mir wünsche. Was nützt mir die schnellste CPU, wenn ein Programmfehler das ganze System zum Absturz bringt?
Ich weiß leider nicht, ob solche Features bei RISC OS überhaupt wirtschaftlich implementierbar sind? Da müssten mal die Insider von RISC OS ein Statement abgeben. Denn so können Außenstehende (wie ich) nur spekulieren.
Zurück auf die Hardware: es muß dann auch jemand einen Desktop-Computer bzw. -Mainboard bauen. Denn die ARM-CPUs werden ja hauptsächlich in mobilen und embedded Geräten verbaut. Hilft dem RISC OS Markt nicht wirklich... zumindest mir nicht.
Ja, der unveränderte Zustand des A9home nach fast 3½ Jahren ist eine Schande, wenn man die vielen dringenden Baustellen denkt. Aber vor dem Cortex-A9 steht die Portierung auf dem Cortex-A8 an. Die ist zwar noch weit entfernt von fertig, aber das sieht gut aus. Wenn das abgeschlossen ist, gibts vielleicht auch den Cortex-A9. Aber einen Rechner wie zum Beispiel den IYONIX pc mit "richtiger" Graphikkarte und so weiter wird es nicht geben. Da kann nur Emulation die Lösung sein. Aber wenn die Cortex-A8 Portierung benutzbar wird und gut läuft, dann ist zum Beispiel das BeagleBoard oder DevKit8000 eine sehr interessante Alternative zum Risc PC.
Sicher sind mehrere Prozessoren für RISC OS kein Ding der Unmöglichkeit, aber ich sehe nicht das dies absehbar umgesetzt wird. Das sind einige tiefgreifende Eingriffe in RISC OS notwendig. Eher kann ich mir vorstellen, dass man den zweiten Prozessor einige Arbeiten zuweist. Ich denke da an Flieskommajobs, wie seinerzeit mit der x86er Karte im Risc PC.
Wirtschaftlich implementierbar ist bei RISC OS so gut wie nichts mehr. RISCOS Ltd. hält sich wohl so gerade mit Feierabendprogrammierer über Wasser und Castle hat das Handtuch geworfen und sich zum Glück für Open Source entschieden. Aber mit Speicherschutzverletzungen habe ich eigentlich kein Probleme. Ich programmiere wohl offenbar zu wenig. Was mich im Alltag stört ist der Speicherhunger von NetSurf. Aber das liegt an NetSurf und nicht an RISC OS und da wäre virtueller Speicher auch keine Lösung.
Sicher sind mehrere Prozessoren für RISC OS kein Ding der Unmöglichkeit, aber ich sehe nicht das dies absehbar umgesetzt wird. Das sind einige tiefgreifende Eingriffe in RISC OS notwendig. Eher kann ich mir vorstellen, dass man den zweiten Prozessor einige Arbeiten zuweist. Ich denke da an Flieskommajobs, wie seinerzeit mit der x86er Karte im Risc PC.
Wirtschaftlich implementierbar ist bei RISC OS so gut wie nichts mehr. RISCOS Ltd. hält sich wohl so gerade mit Feierabendprogrammierer über Wasser und Castle hat das Handtuch geworfen und sich zum Glück für Open Source entschieden. Aber mit Speicherschutzverletzungen habe ich eigentlich kein Probleme. Ich programmiere wohl offenbar zu wenig. Was mich im Alltag stört ist der Speicherhunger von NetSurf. Aber das liegt an NetSurf und nicht an RISC OS und da wäre virtueller Speicher auch keine Lösung.
[quote="Artchi"]Diese ganzen neuen CPU-Designs sind ja ganz nett. Aber sie helfen dem RISC OS Markt nicht wirklich weiter.
[/quote]
Wenn sie leistungsfähig sind, und wenn sie ihren Weg in käuflich zu erwerbende, anständige Geräte finden, dann helfen sie auf lange Sicht dem Markt.
Signifikante Gründe für den Niedergang von RISC OS waren immer die teure Hardware und die wenig leistungsfähige CPU. Die neuen Entwicklungen bei ARM für den Netbook-Markt könnten beide Probleme mit einem Schlag lösen. Die Netbooks haben gezeigt, dass Linux durchaus massenmarkttauglich ist. Und warum dann auf x86 setzen, mit all den Nachteilen von hohen Preisen bis zu hohem Stromverbrauch?
Es bleibt natürlich abzuwarten, welche geeigneten SoCs am Ende tatsächlich verfügbar sind, und wann - Ankündigungen gab es schon viele (Samsung Halla und Sorak z.B., zwei ARM10-Implementierungen mit angeblich 1,2 GHz und 3 GHz, die spätestens 2005 verfügbar sein sollten).
[quote]
Wenn ich so lese, wie fehlerhaft der A9home Computer (heute noch) sein soll, sieht das mit einer CortexA9 CPU nicht besser aus (ich meine nicht das die CPU fehlerhaft ist!).
[/quote]
Der A9 ist letztlich ein gescheitertes Experiment. Ein Beweis, dass die 32bit-Version von RO Ltd. nicht markttauglich ist. Ein Beweis, dass Hardware in kleinen Stückzahlen viel zu teuer ist. Ein Beweis, dass Treiberentwicklung als Closed Source im stillen Kämmerlein ohne anständige Bezahlung gescheitert ist. Ein Beweis, dass kommerzielle RISC OS-Hardwareentwicklung sich nicht mehr rechnet.
[quote]
Eine Frage ist auch, ob RISC OS überhaupt mit Multicore-CPUs auskommt?
[/quote]
Klar geht das, die Frage ist nur wie gut die zweite CPU nutzbar ist. Pace/Tematic hatte da einige interessante Ansätze, was die Auslagerung des TCP/IP-Stacks und Video-/Audiocodecs angeht.
[quote]
Aber selbst das finde ich noch nicht mal wichtig für die RISC OS Zukunft. Was mich traurig stimmt, ist das RISC OS anscheinend (bitte korrigiert mich!) immer noch keinen Speicherschutz hat?! Obwohl mittlerweile eine MMU serienmäßig ist (seit ARM610-Zeiten). Speicherschutz ist DAS Feature das ich mir wünsche. Was nützt mir die schnellste CPU, wenn ein Programmfehler das ganze System zum Absturz bringt?
[/quote]
RISC OS hat nur begrenzten Speicherschutz - das Design der RMA macht das quasi zur Notwendigkeit, dass gewisse Speicherbereiche für alle zugänglich sind. Trotzdem hat RISC OS mehr als "kein Speicherschutz", denn die Tasks sind gegeneinander abgeschirmt, was das Problem doch stark entschärft.
Am Ende des Tages kann ich aus meiner 20jährigen Nutzung von RISC OS wohl mit gutem Gewissen sagen, dass der fehlende perfekte Speicherschutz das geringste Problem von RISC OS ist und einer Nutzung nicht wirklich im Wege steht.
[quote]
Ich weiß leider nicht, ob solche Features bei RISC OS überhaupt wirtschaftlich implementierbar sind? Da müssten mal die Insider von RISC OS ein Statement abgeben. Denn so können Außenstehende (wie ich) nur spekulieren.
[/quote]
Ohne eine wirklich aufwändige Lösung (jeder Task bekommt sein eigenes RISC OS) ist echter Speicherschutz nicht nachträglich in RISC OS einbaubar, ohne quasi alle Anwendungen inkompatibel zu machen.
Selbiges gilt für präemptives Multitasking.
[quote]
Zurück auf die Hardware: es muß dann auch jemand einen Desktop-Computer bzw. -Mainboard bauen. Denn die ARM-CPUs werden ja hauptsächlich in mobilen und embedded Geräten verbaut. Hilft dem RISC OS Markt nicht wirklich... zumindest mir nicht.[/quote]
Hardware in diese Richtung ist ja verfügbar. BeagleBoard, SheevaPlug, rd-base und rd-client...dazu z.B. das TouchBook von Always Innovating oder das T800 Netbook von TCS.
Das BeagleBoard kostet gerade mal 130 EUR inkl. Versand und bietet im Prinzip mehr als IYONIX-Leistung. Der rd-client liegt unter 250 EUR inklusive Gehäuse und ist deutlich leistungsfähiger als ein IYONIX.
Durch den Erfolg von Linux hat sich das alte RISC OS-Hardwareproblem wirklich stark entschärft. Es gibt viele Hersteller, die auf das offene Entwicklungsmodell setzen und ihre Development Kits zu attraktiven Preisen anbieten. Wenn man da an früher denkt - die XScale-DevBoards von Intel lagen allesamt im mittleren vierstelligen Preisbereich.
Fehlen nur noch die vielen Programmierer, die die Portierungen tatsächlich machen...
Steffen
[/quote]
Wenn sie leistungsfähig sind, und wenn sie ihren Weg in käuflich zu erwerbende, anständige Geräte finden, dann helfen sie auf lange Sicht dem Markt.
Signifikante Gründe für den Niedergang von RISC OS waren immer die teure Hardware und die wenig leistungsfähige CPU. Die neuen Entwicklungen bei ARM für den Netbook-Markt könnten beide Probleme mit einem Schlag lösen. Die Netbooks haben gezeigt, dass Linux durchaus massenmarkttauglich ist. Und warum dann auf x86 setzen, mit all den Nachteilen von hohen Preisen bis zu hohem Stromverbrauch?
Es bleibt natürlich abzuwarten, welche geeigneten SoCs am Ende tatsächlich verfügbar sind, und wann - Ankündigungen gab es schon viele (Samsung Halla und Sorak z.B., zwei ARM10-Implementierungen mit angeblich 1,2 GHz und 3 GHz, die spätestens 2005 verfügbar sein sollten).
[quote]
Wenn ich so lese, wie fehlerhaft der A9home Computer (heute noch) sein soll, sieht das mit einer CortexA9 CPU nicht besser aus (ich meine nicht das die CPU fehlerhaft ist!).
[/quote]
Der A9 ist letztlich ein gescheitertes Experiment. Ein Beweis, dass die 32bit-Version von RO Ltd. nicht markttauglich ist. Ein Beweis, dass Hardware in kleinen Stückzahlen viel zu teuer ist. Ein Beweis, dass Treiberentwicklung als Closed Source im stillen Kämmerlein ohne anständige Bezahlung gescheitert ist. Ein Beweis, dass kommerzielle RISC OS-Hardwareentwicklung sich nicht mehr rechnet.
[quote]
Eine Frage ist auch, ob RISC OS überhaupt mit Multicore-CPUs auskommt?
[/quote]
Klar geht das, die Frage ist nur wie gut die zweite CPU nutzbar ist. Pace/Tematic hatte da einige interessante Ansätze, was die Auslagerung des TCP/IP-Stacks und Video-/Audiocodecs angeht.
[quote]
Aber selbst das finde ich noch nicht mal wichtig für die RISC OS Zukunft. Was mich traurig stimmt, ist das RISC OS anscheinend (bitte korrigiert mich!) immer noch keinen Speicherschutz hat?! Obwohl mittlerweile eine MMU serienmäßig ist (seit ARM610-Zeiten). Speicherschutz ist DAS Feature das ich mir wünsche. Was nützt mir die schnellste CPU, wenn ein Programmfehler das ganze System zum Absturz bringt?
[/quote]
RISC OS hat nur begrenzten Speicherschutz - das Design der RMA macht das quasi zur Notwendigkeit, dass gewisse Speicherbereiche für alle zugänglich sind. Trotzdem hat RISC OS mehr als "kein Speicherschutz", denn die Tasks sind gegeneinander abgeschirmt, was das Problem doch stark entschärft.
Am Ende des Tages kann ich aus meiner 20jährigen Nutzung von RISC OS wohl mit gutem Gewissen sagen, dass der fehlende perfekte Speicherschutz das geringste Problem von RISC OS ist und einer Nutzung nicht wirklich im Wege steht.
[quote]
Ich weiß leider nicht, ob solche Features bei RISC OS überhaupt wirtschaftlich implementierbar sind? Da müssten mal die Insider von RISC OS ein Statement abgeben. Denn so können Außenstehende (wie ich) nur spekulieren.
[/quote]
Ohne eine wirklich aufwändige Lösung (jeder Task bekommt sein eigenes RISC OS) ist echter Speicherschutz nicht nachträglich in RISC OS einbaubar, ohne quasi alle Anwendungen inkompatibel zu machen.
Selbiges gilt für präemptives Multitasking.
[quote]
Zurück auf die Hardware: es muß dann auch jemand einen Desktop-Computer bzw. -Mainboard bauen. Denn die ARM-CPUs werden ja hauptsächlich in mobilen und embedded Geräten verbaut. Hilft dem RISC OS Markt nicht wirklich... zumindest mir nicht.[/quote]
Hardware in diese Richtung ist ja verfügbar. BeagleBoard, SheevaPlug, rd-base und rd-client...dazu z.B. das TouchBook von Always Innovating oder das T800 Netbook von TCS.
Das BeagleBoard kostet gerade mal 130 EUR inkl. Versand und bietet im Prinzip mehr als IYONIX-Leistung. Der rd-client liegt unter 250 EUR inklusive Gehäuse und ist deutlich leistungsfähiger als ein IYONIX.
Durch den Erfolg von Linux hat sich das alte RISC OS-Hardwareproblem wirklich stark entschärft. Es gibt viele Hersteller, die auf das offene Entwicklungsmodell setzen und ihre Development Kits zu attraktiven Preisen anbieten. Wenn man da an früher denkt - die XScale-DevBoards von Intel lagen allesamt im mittleren vierstelligen Preisbereich.
Fehlen nur noch die vielen Programmierer, die die Portierungen tatsächlich machen...
Steffen
[quote="hubersn"][...]
Die Netbooks haben gezeigt, dass Linux durchaus massenmarkttauglich ist.
[...]
Der A9 ist letztlich ein gescheitertes Experiment.
[...]
[/quote]
Ich denke viele die sich ein Linux Netbook gekauft haben, haben inzwischen XP aufgespielt. Die meisten haben halt die M$ Schere im Kopf und kommen nur mit Windows, MS Office und so weiter zurecht. Gutes Beispiel ist Vista, das von fast allen gehaßt wird und das hat nicht nur technische Gründe. Sonder liegt einfach daran, das es so anders als XP ist. Wenn ich durch die grossen Elektromärkte gehe, werde ich auch kein Linux Netbook finden. Dafür haben fast alle mobile Geräte schwachsinnigerweise gespiegelte Bildschirme. Aber es stimmt, dank Linux gibt es neue RISC OS Hardware und es kommt mehr. Der Erfolg der ARM Netbooks sehe ich sehr skeptisch, da läuft ja kein Word, Excel, Skype, ...
Ja, der A9home ist gescheitert. Ich denke aber RISC OS 6 würde ganz gut laufen, wenn es dann laufen würde. Auf alle Fälle wäre dann das fehlerhafte Dateisystem besser als von Select32. So ist aber RISC OS 6 nur noch für den Risc PC und Emulatoren geeignet. Die Zukunft der nativen Hardware liegt in RISC OS 5 und Jeffrey.
Die Netbooks haben gezeigt, dass Linux durchaus massenmarkttauglich ist.
[...]
Der A9 ist letztlich ein gescheitertes Experiment.
[...]
[/quote]
Ich denke viele die sich ein Linux Netbook gekauft haben, haben inzwischen XP aufgespielt. Die meisten haben halt die M$ Schere im Kopf und kommen nur mit Windows, MS Office und so weiter zurecht. Gutes Beispiel ist Vista, das von fast allen gehaßt wird und das hat nicht nur technische Gründe. Sonder liegt einfach daran, das es so anders als XP ist. Wenn ich durch die grossen Elektromärkte gehe, werde ich auch kein Linux Netbook finden. Dafür haben fast alle mobile Geräte schwachsinnigerweise gespiegelte Bildschirme. Aber es stimmt, dank Linux gibt es neue RISC OS Hardware und es kommt mehr. Der Erfolg der ARM Netbooks sehe ich sehr skeptisch, da läuft ja kein Word, Excel, Skype, ...
Ja, der A9home ist gescheitert. Ich denke aber RISC OS 6 würde ganz gut laufen, wenn es dann laufen würde. Auf alle Fälle wäre dann das fehlerhafte Dateisystem besser als von Select32. So ist aber RISC OS 6 nur noch für den Risc PC und Emulatoren geeignet. Die Zukunft der nativen Hardware liegt in RISC OS 5 und Jeffrey.
Noch mal wegen dem Thema Multi-Core/-CPU und RISC OS mit seinen fehlenden Fähigkeiten. Ein Mitarbeiter von MS-Forschung hat da einen Denkansatz, der vielleicht RISC OS entgegen kommen könnte:
http://www.golem.de/showhigh2.php?file=/1003/73996.html
Er meint sicherlich nicht Kooperatives Multitasking, aber so in etwa die Richtung geht das doch schon?
Hier im Topic wurde ja auch gesagt, jede RISC OS-Anwendung müsste seine eigene OS-Instanz bekommen, um mehrere CPUs/Cores ausnutzen zu können. Das klingt ja auch bei dem MS-Forscher durch, das jede Anwendung seine eigenen Resourcen verwalten soll. Wie man das Kind nennt, ist ja egal.
Das nur mal zur Info, falls jemand den Artikel nicht kennt.
http://www.golem.de/showhigh2.php?file=/1003/73996.html
Er meint sicherlich nicht Kooperatives Multitasking, aber so in etwa die Richtung geht das doch schon?
Hier im Topic wurde ja auch gesagt, jede RISC OS-Anwendung müsste seine eigene OS-Instanz bekommen, um mehrere CPUs/Cores ausnutzen zu können. Das klingt ja auch bei dem MS-Forscher durch, das jede Anwendung seine eigenen Resourcen verwalten soll. Wie man das Kind nennt, ist ja egal.
Das nur mal zur Info, falls jemand den Artikel nicht kennt.
Ich sehe nicht den Zusammenhang mit RISC OS.
Die Äusserung von Probert wurde sicher in Fachkreisen kritisch diskutiert. Für mich hört sich das an als wenn er den Anwendungen Aufgaben zuweisen will die heute das Betriebsystem macht. Das läuft daraus hinaus, dass das Betriebssytem klein und schlank wird und die Verantwortung an die Anwendungen abgegeben werden. Als Folge wird dann der Kram in Bibliotheken verlagert und nicht mehr Betriebssystem genannt. Bibliothekten sich auswechslebarer. Also ein Basis-Betriebssystem und via Bibliotheken wird für verschiedene Zwecke (Desktop, Fileserver, Datenbank, ...) wird dann etwas optimales daraus. In diesen Sinne ist es ein interessanter Ansatz.
Mal vorrausgesetzt das Bild des Taskmanager ist real, dann hat Windows massive Probleme 12 Kerne vernüftig, sprich halbwegs gleichmässig, zu benutzen.
Aber irgendwie haben ich den Faden verloren, was hat das mit RISC OS zu tuen? Selbst wenn man das so umsetzen würde wie angedacht, dann würde das das Ende von jeglicher Kompabiltät mit allen bestehenden Programmen bedeuten. Egal ob das jetzt Windows, Linux oder RISC OS heißt.
Die Äusserung von Probert wurde sicher in Fachkreisen kritisch diskutiert. Für mich hört sich das an als wenn er den Anwendungen Aufgaben zuweisen will die heute das Betriebsystem macht. Das läuft daraus hinaus, dass das Betriebssytem klein und schlank wird und die Verantwortung an die Anwendungen abgegeben werden. Als Folge wird dann der Kram in Bibliotheken verlagert und nicht mehr Betriebssystem genannt. Bibliothekten sich auswechslebarer. Also ein Basis-Betriebssystem und via Bibliotheken wird für verschiedene Zwecke (Desktop, Fileserver, Datenbank, ...) wird dann etwas optimales daraus. In diesen Sinne ist es ein interessanter Ansatz.
Mal vorrausgesetzt das Bild des Taskmanager ist real, dann hat Windows massive Probleme 12 Kerne vernüftig, sprich halbwegs gleichmässig, zu benutzen.
Aber irgendwie haben ich den Faden verloren, was hat das mit RISC OS zu tuen? Selbst wenn man das so umsetzen würde wie angedacht, dann würde das das Ende von jeglicher Kompabiltät mit allen bestehenden Programmen bedeuten. Egal ob das jetzt Windows, Linux oder RISC OS heißt.
[quote="cms"]
Aber irgendwie haben ich den Faden verloren, was hat das mit RISC OS zu tuen?[/quote]Direkt hat das natürlich nichts mit RISC OS zu tun. Selbst mit Windows hat es direkt nichts zu tun. Denn bei Dave Proberts Äußerung geht es ja erstmal nur um allgemeine Grundlagenforschung (was wäre wenn?). Und die kann für jedes OS interessant sein. Und somit vielleicht doch für RISC OS interesant.
[quote="cms"]Selbst wenn man das so umsetzen würde wie angedacht, dann würde das das Ende von jeglicher Kompabiltät mit allen bestehenden Programmen bedeuten. Egal ob das jetzt Windows, Linux oder RISC OS heißt.[/quote]Laut Steffen wäre das aber nur so möglich, die Kompatibilität zu erhalten um Multi-Core/-CPU zu unterstützen. Deshalb fand ich den Gedanken von Probert für RISC OS interessant. Steffen sagte zwar, das man das ganze OS pro Anwendung instanzieren müsste, aber abstrakt betrachtet, ist das OS auch nur eine Resource. Steffens Gedanke liegt also gar nicht so fern, von einer möglichen Umsetzung. Dave Probert von MS hat ja auch nur erstmal einen Gedanken geäußert, da er bei MS Forschung betreibt. Und die MS-Forscher sicherlich keine Idioten sind, kann man sich zumindest ihre Erkenntnisse anhören und evtl. in RISC OS einfließen lassen. Oder sogar die Gedanken von Steffen dadurch bestärken.
Aber irgendwie haben ich den Faden verloren, was hat das mit RISC OS zu tuen?[/quote]Direkt hat das natürlich nichts mit RISC OS zu tun. Selbst mit Windows hat es direkt nichts zu tun. Denn bei Dave Proberts Äußerung geht es ja erstmal nur um allgemeine Grundlagenforschung (was wäre wenn?). Und die kann für jedes OS interessant sein. Und somit vielleicht doch für RISC OS interesant.
[quote="cms"]Selbst wenn man das so umsetzen würde wie angedacht, dann würde das das Ende von jeglicher Kompabiltät mit allen bestehenden Programmen bedeuten. Egal ob das jetzt Windows, Linux oder RISC OS heißt.[/quote]Laut Steffen wäre das aber nur so möglich, die Kompatibilität zu erhalten um Multi-Core/-CPU zu unterstützen. Deshalb fand ich den Gedanken von Probert für RISC OS interessant. Steffen sagte zwar, das man das ganze OS pro Anwendung instanzieren müsste, aber abstrakt betrachtet, ist das OS auch nur eine Resource. Steffens Gedanke liegt also gar nicht so fern, von einer möglichen Umsetzung. Dave Probert von MS hat ja auch nur erstmal einen Gedanken geäußert, da er bei MS Forschung betreibt. Und die MS-Forscher sicherlich keine Idioten sind, kann man sich zumindest ihre Erkenntnisse anhören und evtl. in RISC OS einfließen lassen. Oder sogar die Gedanken von Steffen dadurch bestärken.