> In *jeder* größeren Unixumgebung Eben nicht! Höchstens in welchen, die seit Jahren nicht mehr angetastet wurden, da man es sich nicht leisten kann, das laufende System umzustellen. Ansonsten sind mir genug Linux Umgebungen bekannt, bei denen auf den Clients der Workgroup X lokal läuft. Würden die X Forward verwenden würde wegen den ganzen Qt und GTK Fenstern das Netzwerk bis zum erbrechen ausgelastet sein. Da laufen dann mal zig Millionen Syncs drüber. Da hilft auch Pufferung kaum noch.
> Und was haben nfs und FUSE bitteschön damit zu tun? Wenn wir von Konzepten bei Client/Server Architekturen reden, sehr viel. Was ist denn das X Forwarding in der Praxis? Nichts weiter als Informationen von einem Rechner zum anderen zu bringen. Im Falle des X Servers wird die Information am Server (grafisch) aufbereitet, so dass sich der Client nicht mehr darum kümmern muss. Letzten Endes ist das aber nichts weiter als Daten von Maschine A zu Maschine B zu bringen. Nehmen wir mal Gnuplot als Beispiel. Ich würde heute nie im Leben auf die Idee kommen, mir vom Hauptrechner die Plotergebnisse per X Forwarding rübergeben zu lassen. Ich mounte das Laufwerk auf dem die Datensätze liegen per NFS oder sonstwas und lasse mir das Ergebniss lokal von gnuplot darstellen. Das hat den Vorteil, dass ich die grafische Ausgabe auch komplett selbst einstellen kann, ohne ggf. durch Restriktionen am Server eingegrenzt zu sein. Wenn ich heute Informationen von einer remote Maschine haben will, dann interessieren mich nur die reinen Daten, die ich vom Server mit der speziell dafür vorhandenen Serversoftware erhalte. Für die Darstellung kümmert sich die lokale Maschine.
Von Sie haben vergessen, Ihren Nam am Do, 26. Juli 2012 um 15:09 #
Willst du mir jetzt erzählen, dass ein paar Zeichen- und Sync-Befehle mehr Netzlast verursachen als das Übertragen kompletter Bitmaps (die sich dank allgegenwärtiger Farbverläufe und unscharf gemachter Schriften auch noch schlecht komprimieren lassen)?
Zu deinem 2. Absatz: Es geht bei Remote-Anwendungen ja vor allem darum, die Resourcen entfernter Rechner zu nutzen (sei es nun per X, VNC, Webanwendung oder ...), und nicht darum, entfernt liegene Daten lokal zu verarbeiten. Das sind zwei Paar Stiefel. Insofern ist dein Verweis auf NFS & co. völlig fehl am Platz.
> dass ein paar Zeichen- und Sync-Befehle mehr Netzlast verursachen als das Übertragen kompletter Bitmaps Nein! Nochmal der Kontext: > Würden die X Forward verwenden würde wegen den ganzen **Qt und GTK Fenstern** Xlib klassich: Zeichne primitive, Zeichne primitive, ..., Synce (geht, da die Queue die primitives kennt) Toolkits die über xlib Bitmaps senden: Zeichne bitmap, synce, zeichne bitmap, synce ... (muss sein, da die queue die primitve der bitmaps nicht kennt)
Die Beispiele sind grob, aber sie sollen nur konzeptionell Zeigen, welche Schwierigkeiten dahinter stecken. Das mag zwar lokal noch einigermaßen gut gehen und lässt sich zu einem gewissen Grad optimieren, jedoch führt das bekanntermaßen in Netzwerken zu enormen Latenzen.
> die Resourcen entfernter Rechner zu nutzen Die Bereitstellung der Daten ist *auch* eine Resource. Und wie ich bereits beschrieben hab, ist die momentane Situation die, dass im Gegensatz zu früheren Terminal/Mainframe Zeiten, die *Bereitstellung* und *Dartstellung* auf Client und Server aufgeteilt werden. Und das wird sich auch so schnell nicht ändern. Selbst rasberry pi besitzt genug Speicher und eine GPU um nicht auf eine remote Grafikresource (Sprich Server der eine GPU zur Darstellung nutzt) angewiesen zu sein.
Man könnte vielleicht noch argumentieren, dass sämtliche Software an einem Platz ist und man sich bei den Clients nicht darum zu kümmern braucht, aber auch das hat heute nicht wirklich mehr Gewicht.
Das Ganze würde ja komplett anders aussehen, wenn das X Protokoll weiter entwickelt worden wäre, sodass die heutigen Toolkits die lokalen Zeichnungen auf ein Minimum reduzieren könnten. Ist aber nicht der Fall. Auch aus oben genannten technischen Gründen. Das heißt wir haben heute eine Form der Resourcennutzung auf die X eigentlich gar nicht ausgelegt ist.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 26. Jul 2012 um 17:00.
Von Sie haben vergessen, Ihren Nam am Do, 26. Juli 2012 um 17:48 #
> Die Bereitstellung der Daten ist *auch* eine Resource. Und wie ich bereits beschrieben hab, ist die momentane Situation die, dass im Gegensatz zu früheren Terminal/Mainframe Zeiten, die *Bereitstellung* und *Dartstellung* auf Client und Server aufgeteilt werden. Und das wird sich auch so schnell nicht ändern. Selbst rasberry pi besitzt genug Speicher und eine GPU um nicht auf eine remote Grafikresource (Sprich Server der eine GPU zur Darstellung nutzt) angewiesen zu sein.
Du übersiehst, dass zwischen Bereitsstellung und Darstellung noch ein Schitt fehlt...
Da fehlen viele Schritte. Nicht nur einer. Aber was tut das zur Sache bei einer reinen Konzeptdebatte zwischen der damaligen Terminal/Mainframe und der heutigen Client/Server Welt? Aufbereitung, Verarbeitung, Darstellung ... das wird heute nicht mehr alles an einer zentralen Maschine gemacht wie es damals in Rechenzentren Gang und Gebe war und vor allem nicht für eine komplette grafische Shell. Es macht aus technischer Sicht einfach kaum noch Sinn. Man siehe zum Beispiel mal nur RDP besonders ab Version 7. Mich schmerzt es zwar das sagen zu müssen, aber was AFAIK die Leistungsfähigkeit angeht sieht es für vergleichbares unter Linux ziemlich Mau aus. Die Diskussion gab es hier schonmal. Und dort kommuniziert die lokal ausgeführte Software auch nicht über ein Protokoll mit einem Server der Zugriff auf die Grafiksubsysteme hat. Da wird die Ausgabe einfach umgeleitet sobald RDP angefordert wird. Sprich, das gesamte Display Management bietet Netzwerktranzparenz (was es bei RDP im gewissen Umfang ist), jedoch nur optional und baut nicht von Grund auf darauf für seine Darstellungen auf.
> In *jeder* größeren Unixumgebung
Eben nicht! Höchstens in welchen, die seit Jahren nicht mehr angetastet wurden, da man es sich nicht leisten kann, das laufende System umzustellen. Ansonsten sind mir genug Linux Umgebungen bekannt, bei denen auf den Clients der Workgroup X lokal läuft. Würden die X Forward verwenden würde wegen den ganzen Qt und GTK Fenstern das Netzwerk bis zum erbrechen ausgelastet sein. Da laufen dann mal zig Millionen Syncs drüber. Da hilft auch Pufferung kaum noch.
> Und was haben nfs und FUSE bitteschön damit zu tun?
Wenn wir von Konzepten bei Client/Server Architekturen reden, sehr viel. Was ist denn das X Forwarding in der Praxis? Nichts weiter als Informationen von einem Rechner zum anderen zu bringen. Im Falle des X Servers wird die Information am Server (grafisch) aufbereitet, so dass sich der Client nicht mehr darum kümmern muss. Letzten Endes ist das aber nichts weiter als Daten von Maschine A zu Maschine B zu bringen. Nehmen wir mal Gnuplot als Beispiel. Ich würde heute nie im Leben auf die Idee kommen, mir vom Hauptrechner die Plotergebnisse per X Forwarding rübergeben zu lassen. Ich mounte das Laufwerk auf dem die Datensätze liegen per NFS oder sonstwas und lasse mir das Ergebniss lokal von gnuplot darstellen. Das hat den Vorteil, dass ich die grafische Ausgabe auch komplett selbst einstellen kann, ohne ggf. durch Restriktionen am Server eingegrenzt zu sein. Wenn ich heute Informationen von einer remote Maschine haben will, dann interessieren mich nur die reinen Daten, die ich vom Server mit der speziell dafür vorhandenen Serversoftware erhalte. Für die Darstellung kümmert sich die lokale Maschine.
Willst du mir jetzt erzählen, dass ein paar Zeichen- und Sync-Befehle mehr Netzlast verursachen als das Übertragen kompletter Bitmaps (die sich dank allgegenwärtiger Farbverläufe und unscharf gemachter Schriften auch noch schlecht komprimieren lassen)?
Zu deinem 2. Absatz: Es geht bei Remote-Anwendungen ja vor allem darum, die Resourcen entfernter Rechner zu nutzen (sei es nun per X, VNC, Webanwendung oder ...), und nicht darum, entfernt liegene Daten lokal zu verarbeiten. Das sind zwei Paar Stiefel. Insofern ist dein Verweis auf NFS & co. völlig fehl am Platz.
> dass ein paar Zeichen- und Sync-Befehle mehr Netzlast verursachen als das Übertragen kompletter Bitmaps
Nein! Nochmal der Kontext:
> Würden die X Forward verwenden würde wegen den ganzen **Qt und GTK Fenstern**
Xlib klassich: Zeichne primitive, Zeichne primitive, ..., Synce (geht, da die Queue die primitives kennt)
Toolkits die über xlib Bitmaps senden: Zeichne bitmap, synce, zeichne bitmap, synce ... (muss sein, da die queue die primitve der bitmaps nicht kennt)
Die Beispiele sind grob, aber sie sollen nur konzeptionell Zeigen, welche Schwierigkeiten dahinter stecken.
Das mag zwar lokal noch einigermaßen gut gehen und lässt sich zu einem gewissen Grad optimieren, jedoch führt das bekanntermaßen in Netzwerken zu enormen Latenzen.
> die Resourcen entfernter Rechner zu nutzen
Die Bereitstellung der Daten ist *auch* eine Resource. Und wie ich bereits beschrieben hab, ist die momentane Situation die, dass im Gegensatz zu früheren Terminal/Mainframe Zeiten, die *Bereitstellung* und *Dartstellung* auf Client und Server aufgeteilt werden. Und das wird sich auch so schnell nicht ändern. Selbst rasberry pi besitzt genug Speicher und eine GPU um nicht auf eine remote Grafikresource (Sprich Server der eine GPU zur Darstellung nutzt) angewiesen zu sein.
Man könnte vielleicht noch argumentieren, dass sämtliche Software an einem Platz ist und man sich bei den Clients nicht darum zu kümmern braucht, aber auch das hat heute nicht wirklich mehr Gewicht.
Das Ganze würde ja komplett anders aussehen, wenn das X Protokoll weiter entwickelt worden wäre, sodass die heutigen Toolkits die lokalen Zeichnungen auf ein Minimum reduzieren könnten. Ist aber nicht der Fall. Auch aus oben genannten technischen Gründen. Das heißt wir haben heute eine Form der Resourcennutzung auf die X eigentlich gar nicht ausgelegt ist.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 26. Jul 2012 um 17:00.> Die Bereitstellung der Daten ist *auch* eine Resource. Und wie ich bereits beschrieben hab, ist die momentane Situation die, dass im Gegensatz zu früheren Terminal/Mainframe Zeiten, die *Bereitstellung* und *Dartstellung* auf Client und Server aufgeteilt werden. Und das wird sich auch so schnell nicht ändern. Selbst rasberry pi besitzt genug Speicher und eine GPU um nicht auf eine remote Grafikresource (Sprich Server der eine GPU zur Darstellung nutzt) angewiesen zu sein.
Du übersiehst, dass zwischen Bereitsstellung und Darstellung noch ein Schitt fehlt...
> Schitt
Ich hoffe das war ein Tippfehler :).
Da fehlen viele Schritte. Nicht nur einer. Aber was tut das zur Sache bei einer reinen Konzeptdebatte zwischen der damaligen Terminal/Mainframe und der heutigen Client/Server Welt? Aufbereitung, Verarbeitung, Darstellung ... das wird heute nicht mehr alles an einer zentralen Maschine gemacht wie es damals in Rechenzentren Gang und Gebe war und vor allem nicht für eine komplette grafische Shell. Es macht aus technischer Sicht einfach kaum noch Sinn. Man siehe zum Beispiel mal nur RDP besonders ab Version 7. Mich schmerzt es zwar das sagen zu müssen, aber was AFAIK die Leistungsfähigkeit angeht sieht es für vergleichbares unter Linux ziemlich Mau aus. Die Diskussion gab es hier schonmal. Und dort kommuniziert die lokal ausgeführte Software auch nicht über ein Protokoll mit einem Server der Zugriff auf die Grafiksubsysteme hat. Da wird die Ausgabe einfach umgeleitet sobald RDP angefordert wird. Sprich, das gesamte Display Management bietet Netzwerktranzparenz (was es bei RDP im gewissen Umfang ist), jedoch nur optional und baut nicht von Grund auf darauf für seine Darstellungen auf.