Netzwerktransparenz kann mit anderen Methoden erreicht werden?
Welche anderen Methoden sollen dass sein?
Die Netzwerktransparenz der grafischen Oberfläche bedeutet, dass es für den Nutzer keinen Unterschied macht, ob er ein Programm lokal oder Remote startet. Das Programm verhält sich jeweils gleich und fügt sich auf gleiche Weise in den Desktop ein.
Das Exportieren eines vollständigen Desktops, wie bei VNC oder NX, hat damit wenig zu tun.
Welche anderen Methoden sind also gemeint?
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 19. Nov 2010 um 15:04.
Es gibt für Windows einige Lösungen, welche auch einzelne Fenster Netzwerktransparent machen. Das ist technisch auf einem anderen Layer der GUI angelegt, aber nicht von Nachteil.
Soetwas setzt dann z.B. in der GUI Lib an, anstatt im Displayserver.
RDP und dessen Möglichkeiten (das Übertragen einzelner Fenster wurde dort auch erst nachträglich implementiert) und Unzulänglichkeiten sind mir bekannt. Von Netzwerktransparenz würde ich bei RDP genau so wenig sprechen, wie bei VNC oder NX. Es wird immer ein lokaler Server benötigt dessen Anzeige erst nachträglich übers Netzwerk übertragen wird. Netzwerktransparenz sieht anders aus.
Die Umfrage auf pro-linux.de ziehlt wohl auch primär auf Linux ab. Ich möchte deshalb meine Frage wiederholen und präzisieren, Netzwerktransparenz kann mit welchen anderen Methoden unter Linux erreicht werden?
Immerhin haben aktuell 36% diese Option gewählt, da sollte mir doch jemand ein Beispiel nennen können, was er damit meint. Oder wissen die alle nicht, was Netzwerktransparenz ist?
> Oder wissen die alle nicht, was Netzwerktransparenz ist?
In diesem Fall bedeutet es, dass man ein Programm auf einem entfernten Rechner starten kann und von einem lokalen Rechner aus bedient.
Ob die Transparenz jetzt "echt" oder "künstlich" erreicht wird, spielt für den Anwender doch keinerlei Rolle. Hauptsache er kann einen entfernten Rechner problemlos bedienen.
Es gibt keine künstliche Netzwerktransparenz. Entweder sie ist vorhanden oder nicht.
Du kannst mir aber auch gerne ein alternatives Beispiel für Linux nennen, wie du ein Programm auf einem entfernten Rechner startest und lokal bedienst. Das Programm muss sich natürlich transparent verhalten und in den lokalen Desktop integrieren.
Diese alternative gibt es nicht, weil vielen das veraltete X Protokoll genug ist. Wäre X11 mit all seinen schwächen aber nicht mehr die Haupt-GUI, würden diese Alternativen entstehen, und auch genutzt werden.
Okay, besagte Antwort lautet aber "Netzwerktransparenz kann mit anderen Methoden erreicht werden" und nicht "Netzwerktransparenz könnte mit anderen Methoden erreicht werden."
Wäre das X-Protokoll wirklich so schlecht wie es oft hingestellt wird, hätte sich schon lange eine Alternative gebildet. Bisherige Alternativen kranken aber an allen Ecken und Enden, so dass sie keine sind. Fehlende Netzwerktransparenz ist dabei nur ein Thema.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 21. Nov 2010 um 01:09.
> 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.
Netzwerktransparenz kann mit anderen Methoden erreicht werden?
Welche anderen Methoden sollen dass sein?
Die Netzwerktransparenz der grafischen Oberfläche bedeutet, dass es für den Nutzer keinen Unterschied macht, ob er ein Programm lokal oder Remote startet. Das Programm verhält sich jeweils gleich und fügt sich auf gleiche Weise in den Desktop ein.
Das Exportieren eines vollständigen Desktops, wie bei VNC oder NX, hat damit wenig zu tun.
Welche anderen Methoden sind also gemeint?
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 19. Nov 2010 um 15:04.Es gibt für Windows einige Lösungen, welche auch einzelne Fenster Netzwerktransparent machen. Das ist technisch auf einem anderen Layer der GUI angelegt, aber nicht von Nachteil.
Soetwas setzt dann z.B. in der GUI Lib an, anstatt im Displayserver.
Eben. Es gibt zig Möglichkeiten Netzwerktransparenz zu realisieren. X11 ist und eine Möglichkeit von vielen.
RDP und dessen Möglichkeiten (das Übertragen einzelner Fenster wurde dort auch erst nachträglich implementiert) und Unzulänglichkeiten sind mir bekannt. Von Netzwerktransparenz würde ich bei RDP genau so wenig sprechen, wie bei VNC oder NX. Es wird immer ein lokaler Server benötigt dessen Anzeige erst nachträglich übers Netzwerk übertragen wird. Netzwerktransparenz sieht anders aus.
Die Umfrage auf pro-linux.de ziehlt wohl auch primär auf Linux ab. Ich möchte deshalb meine Frage wiederholen und präzisieren, Netzwerktransparenz kann mit welchen anderen Methoden unter Linux erreicht werden?
Immerhin haben aktuell 36% diese Option gewählt, da sollte mir doch jemand ein Beispiel nennen können, was er damit meint. Oder wissen die alle nicht, was Netzwerktransparenz ist?
> Oder wissen die alle nicht, was Netzwerktransparenz ist?
In diesem Fall bedeutet es, dass man ein Programm auf einem entfernten Rechner starten kann und von einem lokalen Rechner aus bedient.
Ob die Transparenz jetzt "echt" oder "künstlich" erreicht wird, spielt für den Anwender doch keinerlei Rolle. Hauptsache er kann einen entfernten Rechner problemlos bedienen.
Es gibt keine künstliche Netzwerktransparenz. Entweder sie ist vorhanden oder nicht.
Du kannst mir aber auch gerne ein alternatives Beispiel für Linux nennen, wie du ein Programm auf einem entfernten Rechner startest und lokal bedienst. Das Programm muss sich natürlich transparent verhalten und in den lokalen Desktop integrieren.
Diese alternative gibt es nicht, weil vielen das veraltete X Protokoll genug ist. Wäre X11 mit all seinen schwächen aber nicht mehr die Haupt-GUI, würden diese Alternativen entstehen, und auch genutzt werden.
Okay, besagte Antwort lautet aber "Netzwerktransparenz kann mit anderen Methoden erreicht werden" und nicht "Netzwerktransparenz könnte mit anderen Methoden erreicht werden."
Wäre das X-Protokoll wirklich so schlecht wie es oft hingestellt wird, hätte sich schon lange eine Alternative gebildet. Bisherige Alternativen kranken aber an allen Ecken und Enden, so dass sie keine sind. Fehlende Netzwerktransparenz ist dabei nur ein Thema.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 21. Nov 2010 um 01:09.> 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.
> Netzwerktransparenz kann mit anderen Methoden erreicht werden?
> Welche anderen Methoden sollen dass sein?
> Welche anderen Methoden sind also gemeint?
http://pvbrowser.org
ist unser Eigengewächs
Danke, aber bei der Umfrage ging es ja um Netzwerktransparenz für die grafische Oberfläche.