> 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.
> 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.