Hm, RISC OS neu zu schreiben wird wohl nur funktionieren, wenn alle zusammenarbeiten und sich über die zukünftige Implementierung einig sind. War nicht sogar ein großes Developertreffen geplant, zu dem viele aktuelle Entwickler eingeladen wurden?
Ansonsten bleibt wohl wirklich nur die Emulation. Am besten auf einem minimalen Linux-System, das nur alle für die Emulation benötigten Treiber/Komponenten läd und direkt nach RISC OS durchstartet. Damit könnte man schon einen Rechner bauen, der sich wie ein nativer RISC OS Rechner anfühlt. Problem bleibt, dass man es weiterhin mit RISC OS in seiner jetzigen Form zu tun hat, die an vielen Stellen unzureichend ist.
Netbook mit ARM-CPU
Moderator: Patrick
Die Frage ist: "Was bringts?"
Was würde uns ein hypothetisches Nachprogrammieren von RISC OS bringen? Reichlich wenig (verglichen mit einer Emulator-Lösung) für verhältnismäßig viel Aufwand, denn am Ende hätte man etwas sehr ähnliches, was man jetzt eh schon hat, vielleicht etwas wartungsfreundlicher und/oder performanter (wobei ersteres nicht mal sicher ist, wenn man wirklich die 100%-Kompatibilität anstrebt). Zudem würde es doch recht lange dauern, bis man die ersten Früchte sehen würde - ohne nahezu vollständig fertig zu sein, würde praktisch nichts laufen.
Natürlich ist RISC OS nicht besonders komplex. Und das Nachprogrammieren z.B. der WIMP-SWIs und der Sprite-SWIs und des FontManagers wäre sicherlich in relativ kurzer Zeit möglich. Aber was würde es letztlich bringen? Ganze Applikationen bringt man dadurch nicht zum Laufen, die verlassen sich nämlich z.B. auf Interrupts, Callbacks, Upcalls, Messages etc. - eben das ganze RISC OS-Environment.
Neuschreiben ist also IMHO ein Irrweg. Beginnen wir nochmal am Anfang mit dem Nachdenken.
Was ist denn das Tolle an RISC OS? Doch nicht das OS selbst. Oder die Tatsache, dass es auf einem ARM-Prozessor läuft. Oder die restliche Hardware, auf der es läuft. Es sind die vielen Applikationen, die über die Jahre gewachsen sind. Es ist die Art und Weise, wie das OS das Zusammenspiel dieser Applikationen managed.
Unglücklicherweise ist es nun aber so, dass viele dieser Applikationen nicht mehr sonderlich aktiv gepflegt werden. Eine Portierung auf ein "neues RISC OS" ist also völlig unmöglich, ohne 99% der Applikationen und damit die Essenz von dem, was wir RISC OS nennen, zu verlieren. Schon das 32bitten hat zu umfangreichen Verlusten geführt, und das war eine vergleichsweise triviale Anpassung. Wenn man RISC OS dahingehend erweitert, dass es nun plötzlich asynchrone IO, Speicherschutz und präemptives Multitasking unterstützt, dann läuft halt fast keine alte Anwendung mehr.
Was ist das Schlechte an RISC OS? Wir wissen es alle: läuft nur auf langsamer Hardware, viel zu schmale Treiberunterstützung für die tolle Peripherie, kein vernünftiger Browser, fehlende Plugins im Browser wie Flash etc. - welches dieser Probleme würde denn ein neu geschriebenes RISC OS lösen?
Ich denke wir müssen uns von dem Gedanken eines RISC OS nach altem Zuschnitt schlicht befreien. Wir brauchen für die Zukunft eine Hybridlösung und wir brauchen einen gleitenden Übergang, der mit überschaubarem Aufwand echte Vorteile mit sich bringt.
Und da sind wir wieder bei der klassischen Emulation angelangt. VirtualRPC und RPCemu sind schon heute relativ brauchbar. Wenn ROOL wirklich in absehbarer Zeit ein kostenloses RISC OS im Bundle mit RPCemu schnüren kann, dann ist die Grundvoraussetzung erfüllt: die 0-EUR-Lösung für alle relevanten Betriebssysteme als Plattform.
Dann geht es an die Optimierung des Systems. Ein neuer FPEmulator, der die x86-FPU verwendet. Die Verlagerung des IP-Stacks auf die Host-Plattform. Die Verwendung der 2D-Beschleunigerfeatures der Host-Plattform (RO5 bietet dafür die notwendigen "Hooks", um das sauber einbinden zu können). UniPrint/UniScan fürs universelle Drucken und Scannen über Geräte der Host-Plattform. Ein intelligentes HostFS, welches z.B. eingesteckte Massenspeicher automatisch unter RISC OS mountet und zur Verfügung stellt. Verbesserung des ARM-JITs. Ersetzung performancekritischer Teile durch Host-Code (z.B. FontManager). Und last but not least eine Möglichkeit, innerhalb eines RISC OS-Fensters das Host-System reinrendern zu lassen (Thema Browser und Plugins, Video).
Jeder einzelne dieser Verbesserungsschritte ist unabhängig vom anderen. Das heisst: weniger Koordination notwendig, unabhängige Teams können für die Implementierung sorgen, Fortschritte werden sofort sichtbar. Meines erachtens würde selbst ein Teil der oben genannten Maßnahmen ausreichen, um die Userbasis zunächst mal zu sichern und ggf. ein paar Altentwickler zurückzuholen.
Wenn man die alten Anwendungen retten will, ist das IMHO der einzige realistische Weg. Sofern man nicht gleich aufgeben will natürlich.
Steffen
Was würde uns ein hypothetisches Nachprogrammieren von RISC OS bringen? Reichlich wenig (verglichen mit einer Emulator-Lösung) für verhältnismäßig viel Aufwand, denn am Ende hätte man etwas sehr ähnliches, was man jetzt eh schon hat, vielleicht etwas wartungsfreundlicher und/oder performanter (wobei ersteres nicht mal sicher ist, wenn man wirklich die 100%-Kompatibilität anstrebt). Zudem würde es doch recht lange dauern, bis man die ersten Früchte sehen würde - ohne nahezu vollständig fertig zu sein, würde praktisch nichts laufen.
Natürlich ist RISC OS nicht besonders komplex. Und das Nachprogrammieren z.B. der WIMP-SWIs und der Sprite-SWIs und des FontManagers wäre sicherlich in relativ kurzer Zeit möglich. Aber was würde es letztlich bringen? Ganze Applikationen bringt man dadurch nicht zum Laufen, die verlassen sich nämlich z.B. auf Interrupts, Callbacks, Upcalls, Messages etc. - eben das ganze RISC OS-Environment.
Neuschreiben ist also IMHO ein Irrweg. Beginnen wir nochmal am Anfang mit dem Nachdenken.
Was ist denn das Tolle an RISC OS? Doch nicht das OS selbst. Oder die Tatsache, dass es auf einem ARM-Prozessor läuft. Oder die restliche Hardware, auf der es läuft. Es sind die vielen Applikationen, die über die Jahre gewachsen sind. Es ist die Art und Weise, wie das OS das Zusammenspiel dieser Applikationen managed.
Unglücklicherweise ist es nun aber so, dass viele dieser Applikationen nicht mehr sonderlich aktiv gepflegt werden. Eine Portierung auf ein "neues RISC OS" ist also völlig unmöglich, ohne 99% der Applikationen und damit die Essenz von dem, was wir RISC OS nennen, zu verlieren. Schon das 32bitten hat zu umfangreichen Verlusten geführt, und das war eine vergleichsweise triviale Anpassung. Wenn man RISC OS dahingehend erweitert, dass es nun plötzlich asynchrone IO, Speicherschutz und präemptives Multitasking unterstützt, dann läuft halt fast keine alte Anwendung mehr.
Was ist das Schlechte an RISC OS? Wir wissen es alle: läuft nur auf langsamer Hardware, viel zu schmale Treiberunterstützung für die tolle Peripherie, kein vernünftiger Browser, fehlende Plugins im Browser wie Flash etc. - welches dieser Probleme würde denn ein neu geschriebenes RISC OS lösen?
Ich denke wir müssen uns von dem Gedanken eines RISC OS nach altem Zuschnitt schlicht befreien. Wir brauchen für die Zukunft eine Hybridlösung und wir brauchen einen gleitenden Übergang, der mit überschaubarem Aufwand echte Vorteile mit sich bringt.
Und da sind wir wieder bei der klassischen Emulation angelangt. VirtualRPC und RPCemu sind schon heute relativ brauchbar. Wenn ROOL wirklich in absehbarer Zeit ein kostenloses RISC OS im Bundle mit RPCemu schnüren kann, dann ist die Grundvoraussetzung erfüllt: die 0-EUR-Lösung für alle relevanten Betriebssysteme als Plattform.
Dann geht es an die Optimierung des Systems. Ein neuer FPEmulator, der die x86-FPU verwendet. Die Verlagerung des IP-Stacks auf die Host-Plattform. Die Verwendung der 2D-Beschleunigerfeatures der Host-Plattform (RO5 bietet dafür die notwendigen "Hooks", um das sauber einbinden zu können). UniPrint/UniScan fürs universelle Drucken und Scannen über Geräte der Host-Plattform. Ein intelligentes HostFS, welches z.B. eingesteckte Massenspeicher automatisch unter RISC OS mountet und zur Verfügung stellt. Verbesserung des ARM-JITs. Ersetzung performancekritischer Teile durch Host-Code (z.B. FontManager). Und last but not least eine Möglichkeit, innerhalb eines RISC OS-Fensters das Host-System reinrendern zu lassen (Thema Browser und Plugins, Video).
Jeder einzelne dieser Verbesserungsschritte ist unabhängig vom anderen. Das heisst: weniger Koordination notwendig, unabhängige Teams können für die Implementierung sorgen, Fortschritte werden sofort sichtbar. Meines erachtens würde selbst ein Teil der oben genannten Maßnahmen ausreichen, um die Userbasis zunächst mal zu sichern und ggf. ein paar Altentwickler zurückzuholen.
Wenn man die alten Anwendungen retten will, ist das IMHO der einzige realistische Weg. Sofern man nicht gleich aufgeben will natürlich.
Steffen
[quote="hubersn"]Was ist denn das Tolle an RISC OS?[/quote]
Ganz klar der Desktop der einfach und wunderbar zu bedienen ist und man dabei auch noch die Kontrolle bei der Bedienung behält. Auch wenn das im Wessentlichen schon nahezu 20 Jahre alt ist, ist es immer noch in der Gesamtheit von keinen anderen erreicht worden.
Denkbar wäre auch den Desktop auf Linux oder ein BSD zu "retten" und dann all die Anwendungen wie Firefox, OpenOffice usw. usw. den RISC OS Stil beizubringen. Native RISC OS Programme kann man dann via Emultation in Rennen schicken. Denkbar, aber die Verwirklichung ist nicht wirklich realistisch.
Ansonsten sind Steffens Ausführungen nicht viel hinzuzufügen. Auch wenn ich weiterhin lieber echte RISC OS Hardware sehen würde, aber da man muß man leider Realist sein.
Ganz klar der Desktop der einfach und wunderbar zu bedienen ist und man dabei auch noch die Kontrolle bei der Bedienung behält. Auch wenn das im Wessentlichen schon nahezu 20 Jahre alt ist, ist es immer noch in der Gesamtheit von keinen anderen erreicht worden.
Denkbar wäre auch den Desktop auf Linux oder ein BSD zu "retten" und dann all die Anwendungen wie Firefox, OpenOffice usw. usw. den RISC OS Stil beizubringen. Native RISC OS Programme kann man dann via Emultation in Rennen schicken. Denkbar, aber die Verwirklichung ist nicht wirklich realistisch.
Ansonsten sind Steffens Ausführungen nicht viel hinzuzufügen. Auch wenn ich weiterhin lieber echte RISC OS Hardware sehen würde, aber da man muß man leider Realist sein.
[quote="hubersn"]
Natürlich ist RISC OS nicht besonders komplex. Und das Nachprogrammieren z.B. der WIMP-SWIs und der Sprite-SWIs und des FontManagers wäre sicherlich in relativ kurzer Zeit möglich.[/quote]
Eben, RISC OS ist im Vergleich zu anderen Systemen doch recht überschaubar. Kommt sicherlich auch daher, das es nicht so massiv weiter entwickelt wird.
[quote="hubersn"]
Aber was würde es letztlich bringen? Ganze Applikationen bringt man dadurch nicht zum Laufen, die verlassen sich nämlich z.B. auf Interrupts, Callbacks, Upcalls, Messages etc. - eben das ganze RISC OS-Environment.
[/quote]
Ich kann mir hier einen Emulator/JIT vorstellen.
[quote="hubersn"]
Was ist denn das Tolle an RISC OS?[/quote]
Wenn ich RISC OS gegen Windows NT oder ein *BSD antreten lasse, verliert RISC OS in Sachen Laufzeitsicherheit haus hoch. Z.B. weil Speicherschutz fehlt (falls dieses schon in aktuellen RISC OS Versionen drin sein sollte, würde ich mich gerne aufklären lassen).
Aber trotzdem vermisse ich heute unter meinem Windows XP und meinem FreeBSD sehr viele nette Sachen aus meinen alten RISC OS Zeiten.
- Das ich z.B. ein Zip-Archiv wie ein jedes anderes Dateiverzeichnis behandeln kann. Das Filesystem-Konzept von RISC OS finde ich einfach nur genial. Auf NT und *BSD muß ich erstmal alles entpacken.
- Der Microkernel ist super, ich kann zur Laufzeit beliebig Module rein- und rausschmeissen. Die anderen Mainstreamsysteme mit ihren Monolithkerneln erlauben mir das nicht oder nur eingeschränkt.
- Das ausgiebige Drag & Drop gibt es unter Windows, GNOME & Co. heute immer noch nicht.
- Das Popup-Menü ohne Menüleisten ist konsequent und sehr gut. Bei den anderen Systemen ist alles wischi-waschi.
- Das System mit den Appl.-Verzeichnissen (!-Zeichen) ist super genial. Gab es glaube ich nur in ähnlicher Form auf dem NeXT und jetzt OSX.
Und viele andere kleine Dinge. Leider ist RISC OS im Kern stehen geblieben.
[quote="hubersn"]
Es sind die vielen Applikationen, die über die Jahre gewachsen sind. Es ist die Art und Weise, wie das OS das Zusammenspiel dieser Applikationen managed.
[/quote]
Richtig, vieles ist außerhalb des Kernels aber immernoch im RISC OS sehr gut gelöst worden. Was die Appl. positiv beeinflusst hat.
[quote="hubersn"]
Unglücklicherweise ist es nun aber so, dass viele dieser Applikationen nicht mehr sonderlich aktiv gepflegt werden. Eine Portierung auf ein "neues RISC OS" ist also völlig unmöglich, ohne 99% der Applikationen und damit die Essenz von dem, was wir RISC OS nennen, zu verlieren. Schon das 32bitten hat zu umfangreichen Verlusten geführt, und das war eine vergleichsweise triviale Anpassung. Wenn man RISC OS dahingehend erweitert, dass es nun plötzlich asynchrone IO, Speicherschutz und präemptives Multitasking unterstützt, dann läuft halt fast keine alte Anwendung mehr.
[/quote]
Ja, 100% der Anwendungen würden wahrscheintlich nicht mehr laufen, weil man es auf x86 probiert. Aber hier kann man ja einen Emulator transparent einbauen. D.h. ich klicke z.B. eine Classic-Anwendung wie !Paint an, und das OS entscheidet anhand eines bestimmten Parameters (oder ebend anhand eines fehlenden Paramters), es im Emulator transparent auszuführen. D.h. es geht kein Emulator auf, sondern ein normales Anwendungsfenster, der User merkt nicht direkt den Emulator. Sondern erst daran, das es vielleicht etwas langsamer läuft, oder andere unvermeidbare Einschränkungen hat.
Das hat ja Apple auch so gemacht, mit Rosetta glaube ich.
Unter Linux gibt es mittlerweile VMs, die lassen Windows-Anwendung normal in einem X11-Fenster laufen, ohne das ich direkt einen geschlossenen Windows-Desktop sehe. Ich erkenne das Windows-Programm nur noch an den anders aussehenden Widgets.
Es gibt doch heute schon Emulatoren und VMs, die Acorn-Hardware darstellen.
[quote="hubersn"]
Ich denke wir müssen uns von dem Gedanken eines RISC OS nach altem Zuschnitt schlicht befreien. Wir brauchen für die Zukunft eine Hybridlösung und wir brauchen einen gleitenden Übergang, der mit überschaubarem Aufwand echte Vorteile mit sich bringt.
[/quote]
Exakt!
[quote="hubersn"]
Jeder einzelne dieser Verbesserungsschritte ist unabhängig vom anderen. Das heisst: weniger Koordination notwendig, unabhängige Teams können für die Implementierung sorgen, Fortschritte werden sofort sichtbar.
[/quote]
Gerade die Modularisierung erlaubt diese Arbeitsweise.
[quote="hubersn"]
Wenn man die alten Anwendungen retten will, ist das IMHO der einzige realistische Weg. Sofern man nicht gleich aufgeben will natürlich.
[/quote]
Aufgeben wäre ganz schlecht, da meiner Meinung nach ein OS auch die Anwendungen ausmachen. Mich bewegt z.B. ein RISC OS nicht, wenn ich dort einen Firefox 1:1 vorgesetzt bekomme. Den kann ich auch super unter WinXP benutzen. Mein FreeBSD benutze ich als Abwechslung, aber dort gibts leider auch das meiste 1:1 von Windows.
Oder einen Zip-Archivierer... macht unter FreeBSD und Windows keinen Unterschied für mich. Aber unter RISC OS habe ich mit SparkFS ganz andere Möglichkeiten. (hach, war das schön damals)
Ein neues RISC OS könnte sowohl die alten Anwendungen weiter leben lassen, und vielleicht auch neue bringen, die sich am RISC OS Style halten.
Natürlich ist RISC OS nicht besonders komplex. Und das Nachprogrammieren z.B. der WIMP-SWIs und der Sprite-SWIs und des FontManagers wäre sicherlich in relativ kurzer Zeit möglich.[/quote]
Eben, RISC OS ist im Vergleich zu anderen Systemen doch recht überschaubar. Kommt sicherlich auch daher, das es nicht so massiv weiter entwickelt wird.
[quote="hubersn"]
Aber was würde es letztlich bringen? Ganze Applikationen bringt man dadurch nicht zum Laufen, die verlassen sich nämlich z.B. auf Interrupts, Callbacks, Upcalls, Messages etc. - eben das ganze RISC OS-Environment.
[/quote]
Ich kann mir hier einen Emulator/JIT vorstellen.
[quote="hubersn"]
Was ist denn das Tolle an RISC OS?[/quote]
Wenn ich RISC OS gegen Windows NT oder ein *BSD antreten lasse, verliert RISC OS in Sachen Laufzeitsicherheit haus hoch. Z.B. weil Speicherschutz fehlt (falls dieses schon in aktuellen RISC OS Versionen drin sein sollte, würde ich mich gerne aufklären lassen).
Aber trotzdem vermisse ich heute unter meinem Windows XP und meinem FreeBSD sehr viele nette Sachen aus meinen alten RISC OS Zeiten.
- Das ich z.B. ein Zip-Archiv wie ein jedes anderes Dateiverzeichnis behandeln kann. Das Filesystem-Konzept von RISC OS finde ich einfach nur genial. Auf NT und *BSD muß ich erstmal alles entpacken.
- Der Microkernel ist super, ich kann zur Laufzeit beliebig Module rein- und rausschmeissen. Die anderen Mainstreamsysteme mit ihren Monolithkerneln erlauben mir das nicht oder nur eingeschränkt.
- Das ausgiebige Drag & Drop gibt es unter Windows, GNOME & Co. heute immer noch nicht.
- Das Popup-Menü ohne Menüleisten ist konsequent und sehr gut. Bei den anderen Systemen ist alles wischi-waschi.
- Das System mit den Appl.-Verzeichnissen (!-Zeichen) ist super genial. Gab es glaube ich nur in ähnlicher Form auf dem NeXT und jetzt OSX.
Und viele andere kleine Dinge. Leider ist RISC OS im Kern stehen geblieben.
[quote="hubersn"]
Es sind die vielen Applikationen, die über die Jahre gewachsen sind. Es ist die Art und Weise, wie das OS das Zusammenspiel dieser Applikationen managed.
[/quote]
Richtig, vieles ist außerhalb des Kernels aber immernoch im RISC OS sehr gut gelöst worden. Was die Appl. positiv beeinflusst hat.
[quote="hubersn"]
Unglücklicherweise ist es nun aber so, dass viele dieser Applikationen nicht mehr sonderlich aktiv gepflegt werden. Eine Portierung auf ein "neues RISC OS" ist also völlig unmöglich, ohne 99% der Applikationen und damit die Essenz von dem, was wir RISC OS nennen, zu verlieren. Schon das 32bitten hat zu umfangreichen Verlusten geführt, und das war eine vergleichsweise triviale Anpassung. Wenn man RISC OS dahingehend erweitert, dass es nun plötzlich asynchrone IO, Speicherschutz und präemptives Multitasking unterstützt, dann läuft halt fast keine alte Anwendung mehr.
[/quote]
Ja, 100% der Anwendungen würden wahrscheintlich nicht mehr laufen, weil man es auf x86 probiert. Aber hier kann man ja einen Emulator transparent einbauen. D.h. ich klicke z.B. eine Classic-Anwendung wie !Paint an, und das OS entscheidet anhand eines bestimmten Parameters (oder ebend anhand eines fehlenden Paramters), es im Emulator transparent auszuführen. D.h. es geht kein Emulator auf, sondern ein normales Anwendungsfenster, der User merkt nicht direkt den Emulator. Sondern erst daran, das es vielleicht etwas langsamer läuft, oder andere unvermeidbare Einschränkungen hat.
Das hat ja Apple auch so gemacht, mit Rosetta glaube ich.
Unter Linux gibt es mittlerweile VMs, die lassen Windows-Anwendung normal in einem X11-Fenster laufen, ohne das ich direkt einen geschlossenen Windows-Desktop sehe. Ich erkenne das Windows-Programm nur noch an den anders aussehenden Widgets.
Es gibt doch heute schon Emulatoren und VMs, die Acorn-Hardware darstellen.
[quote="hubersn"]
Ich denke wir müssen uns von dem Gedanken eines RISC OS nach altem Zuschnitt schlicht befreien. Wir brauchen für die Zukunft eine Hybridlösung und wir brauchen einen gleitenden Übergang, der mit überschaubarem Aufwand echte Vorteile mit sich bringt.
[/quote]
Exakt!
[quote="hubersn"]
Jeder einzelne dieser Verbesserungsschritte ist unabhängig vom anderen. Das heisst: weniger Koordination notwendig, unabhängige Teams können für die Implementierung sorgen, Fortschritte werden sofort sichtbar.
[/quote]
Gerade die Modularisierung erlaubt diese Arbeitsweise.
[quote="hubersn"]
Wenn man die alten Anwendungen retten will, ist das IMHO der einzige realistische Weg. Sofern man nicht gleich aufgeben will natürlich.
[/quote]
Aufgeben wäre ganz schlecht, da meiner Meinung nach ein OS auch die Anwendungen ausmachen. Mich bewegt z.B. ein RISC OS nicht, wenn ich dort einen Firefox 1:1 vorgesetzt bekomme. Den kann ich auch super unter WinXP benutzen. Mein FreeBSD benutze ich als Abwechslung, aber dort gibts leider auch das meiste 1:1 von Windows.
Oder einen Zip-Archivierer... macht unter FreeBSD und Windows keinen Unterschied für mich. Aber unter RISC OS habe ich mit SparkFS ganz andere Möglichkeiten. (hach, war das schön damals)
Ein neues RISC OS könnte sowohl die alten Anwendungen weiter leben lassen, und vielleicht auch neue bringen, die sich am RISC OS Style halten.
Wow, fantastische Ideen, die ich hier lese. Da kann man nur hoffen, dass das ROOL-Projekt so richtig ans fliegen kommt und sich mit derartigen Ideen befruchten lässt.
Jedes Jahr muss mein Iyonix nämlich "ein paar Federn lassen", weil ich mehr und mehr merke, dass ich mit meinem PC schneller/fehlerfreier zum Ziel komme. Dieses Jahr hat es mich an zwei Stellen ordentlich geärgert, so dass ich bei meinen DTP-Aktionen zur Halbzeit meiner Weihnachtsarbeiten zum PC geschwenkt bin (Photodesk hat durch zahlreiche Fehlermeldungen und zähes abarbeiten der Aufgaben das Arbeiten erschwert und OvationPro hat mit Fehlermeldungen herum gezickt).
Aber wie Steffen schon ausgeführt hat, sind es die Anwendungen und deren (normalerweise) fantastisches Ineinandergreifen, die RISC OS (für mich) ausmachen. Anhand von OvationPro kann ich das supergut nachvollziehen. Auf dem PC läuft OvationPro superschnell und bisher absolut fehlerfrei, nur das Handling mit anderen Anwendungen (z.B. drag and drop) und die Zweimaustastensteuerung sind scheußlich. Auf dem Iyonix dagegen zickt es manchmal herum (bei umfangreichen Grafikeinpassungen steigt es nicht selten mit einem Fehler aus; wobei das nicht zwingend an OvationPro liegen muss!) und ist relativ langsam bei bildlastigen Arbeiten.
Ich bin gespannt, wie es weiter geht und hoffe, dass mein Iyonix noch solange durch hält, bis man auf die Ergebnisse des ROOL-Projektes zurückgreifen kann.
Gruß
HöMi
Jedes Jahr muss mein Iyonix nämlich "ein paar Federn lassen", weil ich mehr und mehr merke, dass ich mit meinem PC schneller/fehlerfreier zum Ziel komme. Dieses Jahr hat es mich an zwei Stellen ordentlich geärgert, so dass ich bei meinen DTP-Aktionen zur Halbzeit meiner Weihnachtsarbeiten zum PC geschwenkt bin (Photodesk hat durch zahlreiche Fehlermeldungen und zähes abarbeiten der Aufgaben das Arbeiten erschwert und OvationPro hat mit Fehlermeldungen herum gezickt).
Aber wie Steffen schon ausgeführt hat, sind es die Anwendungen und deren (normalerweise) fantastisches Ineinandergreifen, die RISC OS (für mich) ausmachen. Anhand von OvationPro kann ich das supergut nachvollziehen. Auf dem PC läuft OvationPro superschnell und bisher absolut fehlerfrei, nur das Handling mit anderen Anwendungen (z.B. drag and drop) und die Zweimaustastensteuerung sind scheußlich. Auf dem Iyonix dagegen zickt es manchmal herum (bei umfangreichen Grafikeinpassungen steigt es nicht selten mit einem Fehler aus; wobei das nicht zwingend an OvationPro liegen muss!) und ist relativ langsam bei bildlastigen Arbeiten.
Ich bin gespannt, wie es weiter geht und hoffe, dass mein Iyonix noch solange durch hält, bis man auf die Ergebnisse des ROOL-Projektes zurückgreifen kann.
Gruß
HöMi
MfG HöMi