> Bisherige Alternativen kranken aber an allen Ecken und Enden, so dass sie keine sind.
Bisherige Alternativen hatten das Problem, dass sie wenig bis gar nicht zu den bisher existierenden Anwendungen kompatibel waren. Auch die Treibersituation war eine ganz andere.
Wayland hat eine ganz andere Basis als z.B. der damalige Versuch "Fresco" :
Der Kernel selbst bietet heute die passenden Treiber an (Stichwort KMS). Die früheren Alternativen mussten selbst Treiber mitliefern.
Die beiden wichtigsten Toolkits (Qt und Gtk+) werden auf Wayland portiert. Dadurch wird es ein Kinderspiel bestehende Anwendungen auf Wayland zu portieren.
Global-Player wie Intel und Nokia und ihm Linuxbereich RedHat, stehen dahinter. Es ist also kein One-Man-Show.
Es wurde schon frühzeitig an einen Kompatibilitätslayer gedacht. X11-Anwendungen werden unverändert unter Wayland funktionieren.
Zudem gibt es mehr als genügend Beispiele, dass ein Neuanfang nichts Schlechtes oder problematisch sein muss. Ich erinnere nur an die damalige Einführung von MacOS X. Dort wurde nicht nur die Benutzeroberfläche vollständig ausgetauscht, sondern auch das grundlegende Betriebssystem.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 21. Nov 2010 um 01:44.
Wir werden sehen wie sich Wayland entwickelt. Bei einem neuen Protokoll und in der Hochzeit des Internets und der Vernetzung nicht von vorne herein auf Netzwerktransparenz zu achten, halte ich jedoch für einen Kardinalsfehler und massiven Rückschritt.
Mich erinnert dies an die Zeit als Microsoft noch glaubte, das Internet ignorieren zu können...
In einer Transitionsperiode werden wir gar nicht viel von Wayland bemerken, weil ohnehin alle Applikationen X Clients sind, und der XServer den Wayland Compositor anspeist. Ob die Anwendung also remote gestartet wurde oder nicht ist für diesen Fall egal.
Ganz anders wird es, wenn die Anwendungen zunehmend zu direkten Wayland Clients werden, dann ist es, zumindest so wie ich es verstanden habe, mit der Netzwerktransparenz vorbei, weil die Waylandclient --> Waylandcompositor Verbindung nicht Netzwerktransparent zu sein scheint
Für mich ist es aber essentiell, dass ich JEDE grafische Anwendung auf einem anderen Rechner starten kann und das Fenster dazu auf meinem Desktop habe, ohne dass der User der vor dem anderen Rechner sitzt das mitbekommt.
Ich finde man sollte in Wayland ein sehr rudimentäres Netzwerkprotokoll einführen, so dass die Verbindung Client --> Compositor Netzwerktransparent wird. Gut wäre da ein Buffer Rendering auf Clientseite (dann kann es die dortige Hardware benutzen), und das fertige Bild wird dann an den Compositor geschickt. Als vollständig neues Protokoll könnte man das dann so effizient wie NoMachine NX gestalten, was in Kombination mit clientseitigem Rendering 3D Anwendungen über ISDN Leitungen ermöglichen würde.
Ich möchte sogar noch weiter gehen, meines Erachtens ist Wayland der falsche Ansatz. Das Problem ist, dass immer mehr Grafikfunktionen in den Toolkits (GTK, Qt) durchgeführt werden welche an den X-Server nur noch fertige Bitmapgrafiken übertragen und die Grafikfunktionen des X-Servers nicht mehr nutzen. Der Grund dafür ist, dass die Grafikfunktionen des X-Servers nicht mehr ausreichend sind, um heutigen Anforderungen zu genügen.
Der Ansatz von Wayland ist nun keine Grafikfunktionen mehr zur Verfügung zu stellen sondern nur noch fertige Bitmapgrafiken entgegen zu nehmen und anzuzeigen.
Ich würde es stattdessen für sinnvoller erachten, das grundlegende Problem zu lösen und dem X-Server wieder brauchbare Grafikfunktionen beibringen, so dass diese von den Toolkits entsprechend genutzt werden können. Die Toolkits müssen natürlich dazu angehalten werden, diese dann auch zu nutzen.
Damit gäbe es wieder - so wie im ursprünglichen Design von X11 vorgesehen - eine zentrale Instanz welche für das Zeichnen der Grafiken zuständig wäre und das Protokoll wäre entsprechend effizient übers Netzwerk zu übertragen.
Die Netzwerkfähigkeit vom Toolkit abhängig zu machen, so wie es einige vorgeschlagen haben, halte ich hingegen für keine gute Idee. Damit kann man keine Netzwerktransparenz erreichen, da immer Toolkits dabei sein werden, die diese Funktionalität nicht anbieten. Vom Chaos der unterschiedlichen Implementierungen ganz zu schweigen.
> Bisherige Alternativen kranken aber an allen Ecken und Enden, so dass sie keine sind.
Bisherige Alternativen hatten das Problem, dass sie wenig bis gar nicht zu den bisher existierenden Anwendungen kompatibel waren. Auch die Treibersituation war eine ganz andere.
Wayland hat eine ganz andere Basis als z.B. der damalige Versuch "Fresco" :
Zudem gibt es mehr als genügend Beispiele, dass ein Neuanfang nichts Schlechtes oder problematisch sein muss. Ich erinnere nur an die damalige Einführung von MacOS X. Dort wurde nicht nur die Benutzeroberfläche vollständig ausgetauscht, sondern auch das grundlegende Betriebssystem.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 21. Nov 2010 um 01:44.Wir werden sehen wie sich Wayland entwickelt. Bei einem neuen Protokoll und in der Hochzeit des Internets und der Vernetzung nicht von vorne herein auf Netzwerktransparenz zu achten, halte ich jedoch für einen Kardinalsfehler und massiven Rückschritt.
Mich erinnert dies an die Zeit als Microsoft noch glaubte, das Internet ignorieren zu können...
Sehe ich genau so
In einer Transitionsperiode werden wir gar nicht viel von Wayland bemerken, weil ohnehin alle Applikationen X Clients sind, und der XServer den Wayland Compositor anspeist. Ob die Anwendung also remote gestartet wurde oder nicht ist für diesen Fall egal.
Ganz anders wird es, wenn die Anwendungen zunehmend zu direkten Wayland Clients werden, dann ist es, zumindest so wie ich es verstanden habe, mit der Netzwerktransparenz vorbei, weil die Waylandclient --> Waylandcompositor Verbindung nicht Netzwerktransparent zu sein scheint
Für mich ist es aber essentiell, dass ich JEDE grafische Anwendung auf einem anderen Rechner starten kann und das Fenster dazu auf meinem Desktop habe, ohne dass der User der vor dem anderen Rechner sitzt das mitbekommt.
Ich finde man sollte in Wayland ein sehr rudimentäres Netzwerkprotokoll einführen, so dass die Verbindung Client --> Compositor Netzwerktransparent wird. Gut wäre da ein Buffer Rendering auf Clientseite (dann kann es die dortige Hardware benutzen), und das fertige Bild wird dann an den Compositor geschickt. Als vollständig neues Protokoll könnte man das dann so effizient wie NoMachine NX gestalten, was in Kombination mit clientseitigem Rendering 3D Anwendungen über ISDN Leitungen ermöglichen würde.
Ich möchte sogar noch weiter gehen, meines Erachtens ist Wayland der falsche Ansatz. Das Problem ist, dass immer mehr Grafikfunktionen in den Toolkits (GTK, Qt) durchgeführt werden welche an den X-Server nur noch fertige Bitmapgrafiken übertragen und die Grafikfunktionen des X-Servers nicht mehr nutzen. Der Grund dafür ist, dass die Grafikfunktionen des X-Servers nicht mehr ausreichend sind, um heutigen Anforderungen zu genügen.
Der Ansatz von Wayland ist nun keine Grafikfunktionen mehr zur Verfügung zu stellen sondern nur noch fertige Bitmapgrafiken entgegen zu nehmen und anzuzeigen.
Ich würde es stattdessen für sinnvoller erachten, das grundlegende Problem zu lösen und dem X-Server wieder brauchbare Grafikfunktionen beibringen, so dass diese von den Toolkits entsprechend genutzt werden können. Die Toolkits müssen natürlich dazu angehalten werden, diese dann auch zu nutzen.
Damit gäbe es wieder - so wie im ursprünglichen Design von X11 vorgesehen - eine zentrale Instanz welche für das Zeichnen der Grafiken zuständig wäre und das Protokoll wäre entsprechend effizient übers Netzwerk zu übertragen.
Die Netzwerkfähigkeit vom Toolkit abhängig zu machen, so wie es einige vorgeschlagen haben, halte ich hingegen für keine gute Idee. Damit kann man keine Netzwerktransparenz erreichen, da immer Toolkits dabei sein werden, die diese Funktionalität nicht anbieten. Vom Chaos der unterschiedlichen Implementierungen ganz zu schweigen.