Wieso kein X-Server?

Die GUI ist heutzutage oft eine Webgui.

X ist nicht wirklich als "veraltet" zu bezeichnen, bis es halt eine 
tragbare Alternative gibt. Und die gibt es zur Zeit noch nicht.

Das X-Remote Zeug wird haufenweise benutzt und ist auch nicht wirklich 
langsam. Gerade über ssh ist das schon sehr praktisch.

Das X-Protokoll war ursprünglich primär für die Übertragung mäßig
komplexer Vektorgrafiken in lokalen Netzwerken gemacht. Dafür ist es
auch heute noch gut geeignet und meist schneller als VNC, weil die
übertragenen Grafikinformationen stärker abstrahiert sind und damit mit
weniger Bytes auskommen.

Allerdings schwächelt X in den folgenden Punkten:

- Das Protokoll erfordert eine häufige Synchronisation zwischen Client
  und Server. Bei Internet-Verbindungen über viele Zwischenknoten bremst
  diese Synchronisation den Gesamtdurchsatz extrem aus, so dass die
  theoretisch verfügbare Datenbandbreite nur zu Bruchteilen genutzt
  werden kann.

- Die heutigen GUIs mit ihren vielen (teilweise animierten) Icons,
  Dekorationen (dreidimensional anmutende Buttons u.ä.) erfordern die
  Übertragung von sehr viel mehr Grafikprimitiven als die klassisch
  nüchterne Darstellung mit einfachen Linien und Texten. Damit steigt
  die Anzahl der zu übertragenden Bytes gewaltig an, so dass es oft
  günstiger ist, wie bei VNC statt der Vektoren größere rechteckige
  Bereiche (Fensterinhalte oder Ausschnitte davon) als Bitmap zu
  übertragen.

- Dazu kommen noch ein paar Sicherheitsprobleme, die aber nicht ganz so
  stark ins Gewicht fallen, da man das Protokoll meist sowieso durch SSH
  oder VPN tunnelt.

Yalu X. schrieb:
> - Die heutigen GUIs mit ihren vielen (teilweise animierten) Icons,
>   Dekorationen (dreidimensional anmutende Buttons u.ä.) erfordern die
>   Übertragung von sehr viel mehr Grafikprimitiven als die klassisch
>   nüchterne Darstellung mit einfachen Linien und Texten. Damit steigt
>   die Anzahl der zu übertragenden Bytes gewaltig an, so dass es oft
>   günstiger ist, wie bei VNC statt der Vektoren größere rechteckige
>   Bereiche (Fensterinhalte oder Ausschnitte davon) als Bitmap zu
>   übertragen.

Plus Toolkits wie Qt (5+ oder 4.x ohne -graphicssystem native Flag) 
rendern sowieso alles selbst und sagen X nur, es soll die Bilder 
anzeigen. Und das ist über das Netzwerk immens langsam, weil 
unkomprimiert. Das ist dann quasi VNC in extrem schlecht.

Boston schrieb:

> ich verbinde mich üblicherweise mittels SSH zu meinem Raspberry.
> Jetzt hab ich mal bischen gesucht, was es für Möglichkeiten gibt auch
> die GUI "fernzusteuern".

Warum sollte man das tun?

> Die Lösungen sind wohl hauptsächlich VNC oder RDP
...

> So, jetzt frage ich mich, wieso eigentlich nicht direkt X?

Das frage ich dich auch. Warum nutzt du nicht einfach X?

> Wieso wird also dieses grundlegende Feature von X nirgends benutzt?

Selektive Wahnehmung?

> Wieso setzt man dann auf den X Server ein weiteres Client-Server
> Protokoll drauf?

Das braucht man, wenn man (mit deinen Worten) "die GUI fernsteuern" 
will. Aber X wird genau nicht so verwendet.

Bei X läuft der Server auf dem Client-Rechner. Das ist da, wo du deine 
"ssh ..." Kommandozeile eintippst. Das erscheint auf den ersten Blick 
etwas widersinnig, wird aber klarer wenn man bedenkt, daß das Ding mit 
vollem Namen X Display Server heißt. Das ist also ein Server der den 
Dienst Display bereitstellt. Und der muß logischerweise da laufen, wo 
sich der User befindet (der ja das Display sehen können soll).

Auf dem Rechner zu dem du dich per SSH verbindest, da kannst du dann 
eine X-Applikation laufen lassen die ihre Zeichenbefehle zu deinem 
X-Server schickt bzw. von selbigem Events für Tastendrücke, Mausklicks 
etc. entgegennimmt. Und das beste daran: mit SSH läuft das normalerweise 
out-of-the-box [1].

Verbinde dich einfach per SSH zu deinem RasPi und rufe dann auf dem 
RasPi irgendein X-Programm auf. Z.B. xclock. Wenn das nicht irgendwo 
zerkonfiguriert ist, dann wird jetzt ein xclock-Fenster auf deinem 
Desktop aufgehen. Das genauso aussieht wie ein lokales xclock, nur daß 
es in Wirklichkeit auf dem RasPi läuft. Das ist die Magie von X.


XL

[1] Das Stichwort dazu ist "X-Forwarding", SSH-Option -X (ssh -X 
raspi.domainname). man ssh; man ssh_config

Boston schrieb:
> Die Lösungen sind wohl hauptsächlich VNC oder RDP.

Das ist das, was Du irgendwo in Foren, Wikis, Anleitungen etc. gefunden 
hast - richtig?

Für viele Leute ist der Raspi das erste richtige Linux-System in ihrem 
Haus daß sie selbst unter Kontrolle haben (also nicht der Router, 
Fernseher oder Android). Das Notebook etc. laufen bei den meisten Leuten 
unter Windows. Und wenn Du einen Windows-Client hast, ist das mit dem X 
doch gleich deutlich mühsamer als VNC oder RDP. Und da Du diese beiden 
Protokolle auch problemlos unter Linux nutzen kannst, ist die Anleitung 
mit VNC oder RDP gleich für viel mehr Leute nutzbar.

Axel Schwenke schrieb:
> Das ist die Magie von X.
Genau. Eigentlich sehr cool, nur dass es mit modernen Anwendungen 
("nicht xclock") sehr oft ziemlich kaputt ist, weil die nicht mehr so 
rendern, wie die X-Leute sich das 1970 vorgestellt haben. Leider, möchte 
man sagen, in dem Sinne, dass das Feature halt nicht mehr so gut geht.

Sven B. schrieb:
> Axel Schwenke schrieb:
>> Das ist die Magie von X.
> Genau. Eigentlich sehr cool, nur dass es mit modernen Anwendungen
> ("nicht xclock") sehr oft ziemlich kaputt ist, weil die nicht mehr so
> rendern, wie die X-Leute sich das 1970 vorgestellt haben. Leider, möchte
> man sagen, in dem Sinne, dass das Feature halt nicht mehr so gut geht.

IMHO wird in der Diskussion über die Unzulänglichkeiten von X oft und 
gern übertrieben, vornehmlich von Leuten, die ihre eigene Alternative 
"verkaufen" wollen.

Es ist richtig, daß X für sehr "dünne" Leitungen wie Modem- und ISDN- 
Einwahlverbindungen nicht die erste Wahl ist. Einerseits wegen der 
geringen Bandbreite und noch mehr wegen der recht hohen Latenzzeiten. 
Allerdings ist das X-Protokoll aber auch nicht dafür entwickelt worden, 
sondern setzte eigentlich immer ein LAN zwischen Client und Server 
voraus. Andererseits gibt es aber auch bei/für X Abhilfe. Ich habe 
beispielsweise mal für ca. 1 Jahr remote mit X-Applikationen über ISDN 
gearbeitet (arbeiten müssen) und da mit LBX (low bandwidth X, ein 
transparent komprimierender Proxy) gute Erfahrungen gemacht.

Sehr erstaunt war ich auch, als es mir das erste Mal passiert ist daß 
ich unbeabsichtigt ein Video mit mplayer auf meinem Server abgespielt 
habe. Zur Erklärung: das ist hauptsächlich ein Fileserver, aber auch 
sonst "Mädchen für alles". Steht im Keller (natürlich headless). Ab und 
zu logge ich mich per SSH ein, nutze dann auch den mc und habe mal auf 
einem .mpg ENTER gedrückt. Und zu meiner Verwunderung öffnete sich ein 
Videofenster neben dem xterm und das Video lief los. Nur der Ton fehlte. 
Zugegeben, das ist Gigabit Ethernet zwischen den Büchsen. Aber wenn ich 
daran denke, daß noch wenige Jahr vorher alleine die Übertragung der 
decodierten Frames auf den lokalen(!) Bildschirm genausoviel CPU-Zeit 
gefressen hat wie die Dekomprimierung, dann ist das trotzdem beachtlich.


XL

Axel Schwenke schrieb:
> LBX (low bandwidth X, ein transparent komprimierender Proxy)

Ist eben nur leider nie ein richtiger Standard geworden.

Wenn man bedenkt, dass X Mitte der 80er Jahre entstanden ist und der 
"gemeine PC-Dummuser" zu dem Zeitpunkt nichts (und auch 5-6 Jahre später 
immer noch nicht) von GUI oder gar Netzwerk wusste, ist das eigentlich 
schon ein grosser Wurf... Bei X ging die GUI schon übers Netzwerk, wo 
andere noch von Hand Pixel im segmentierten VGA-Speicher gesetzt haben 
;)

Auch sonst war X recht weit. Mit der Shape-Extension (~1990) gab es 
Fenster mit beliebiger Form, die xeyes nutzen das ja auch...

Axel Schwenke schrieb:
> IMHO wird in der Diskussion über die Unzulänglichkeiten von X oft und
> gern übertrieben, vornehmlich von Leuten, die ihre eigene Alternative
> "verkaufen" wollen.
Stimmt schon. Nur: X-Netzwerktransparenz ist halt jetzt vorbei, das wird 
in den nächsten wenigen Jahren mehr und mehr kaputt gehen. Leute malen 
heutzutage ihre animierten UIs direkt mit OpenGL, und das über das 
X-Protokoll zu einem anderen Client weiterzureichen wird so gut wie 
unmöglich sein.

Da ist jetzt schon haufenweise kaputt -- wie gesagt, es ist unglaublich 
langsam mit Toolkits, die ihren eigenen Renderer haben, und ganz oder 
nahezu kaputt mit so Dingen wie Videos oder sogar OpenGL.

> Auch sonst war X recht weit. Mit der Shape-Extension (~1990) gab es
> Fenster mit beliebiger Form, die xeyes nutzen das ja auch...
Na gut, "wer braucht das" frage ich jetzt mal lieber nicht :-)

http://www.raspians.com/Knowledgebase/setting-up-a-remote-desktop-view-the-pi-on-your-windows-pc/

Jörg Wunsch schrieb:
> Axel Schwenke schrieb:
>> LBX (low bandwidth X, ein transparent komprimierender Proxy)
>
> Ist eben nur leider nie ein richtiger Standard geworden.

Ich hatte nicht den Eindruck daß das ein Problem gewesen wäre.
Funktioniert hat es jedenfalls. Leider ist es zwischenzeitlich
aus dem X Server (zumindest: X.org) wieder entfernt worden:

https://en.wikipedia.org/wiki/Low_Bandwidth_X

Ich hatte mir damals auch vorgenommen mir mal NX anzuschauen.
Mangels Leidendsdruck ist das dann hinten runtergefallen ;)


XL

ssh kann übrigens auch Kompression, ssh -C

Ist auch meine Erfahrung, die Kompression bringt schon was bei X 
forwarding.

Axel Schwenke schrieb:
> Sehr erstaunt war ich auch, als es mir das erste Mal passiert ist daß
> ich unbeabsichtigt ein Video mit mplayer auf meinem Server abgespielt
> habe. […] Und zu meiner Verwunderung öffnete sich ein Videofenster
> neben dem xterm und das Video lief los.

Die Erfahrung habe ich einmal mit zwei über ein 100-Mbit/s-Netzwerk
verbundenen Uraltgurken gemacht: Jeder PC für sich gesehen war nur mit
Ächzen in der Lage, das Video abzuspielen. Nutzte man aber einen für die
Dekodierung (mplayer) und den anderen für die Anzeige (X-Server), lief
alles perfekt rund, und jeder PC hatte noch etwa 40% ungenutzte CPU
übrig. Die Übertragung zwischen den PCs scheint dabei keinen merklichen
Flaschenhals dargestellt zu haben.

Boston schrieb:
> Die Lösungen sind wohl hauptsächlich VNC oder RDP.

Einen ganz wichtigen hast Du vergessen: NX (oder Free-NX), das ist von 
der Performance in etwa vergleichbar mit RDP (also 1000 mal schneller 
und reaktionsfreudiger als VNC oder gar X11) und es ist relativ 
schmerzfrei (in wenigen Minuten und ohne Konfigurationsorgien) 
aufzusetzen.

Benötigt (und verwendet) wird der ganz normale SSH Server der ohnehin 
schon auf dem Server installiert und eingerichtet ist, NX setzt darauf 
auf und tunnelt seine Session dann durch eine ganz normale SSH session.

Jedem ders noch nicht ausprobiert hat empfehle ich mal damit 
rumzuspielen, vor allem auch mal über ne schwachbrüstige DSL-Leitung 
testen und staunen.

Axel Schwenke schrieb:
> XL
>
> [1] Das Stichwort dazu ist "X-Forwarding", SSH-Option -X (ssh -X
> raspi.domainname). man ssh; man ssh_config

Allerdings wird die in diesem Fall unnötige zusätzliche Schicht mit 
Verschlüsselung, die durch SSH dazukommt, nicht unbedingt der 
Performance förderlich sein. Man kann X auch direkt ohne den Umweg über 
SSH nutzen. Das ist nicht ganz so bequem, weil bei X-Servern heutzutage 
die Remote-Funktionalität leider per Default abgeschaltet ist, aber geht 
durchaus.

Sven B. schrieb:
> Stimmt schon. Nur: X-Netzwerktransparenz ist halt jetzt vorbei, das wird
> in den nächsten wenigen Jahren mehr und mehr kaputt gehen. Leute malen
> heutzutage ihre animierten UIs direkt mit OpenGL, und das über das
> X-Protokoll zu einem anderen Client weiterzureichen wird so gut wie
> unmöglich sein.

Das ist in OpenGL genau wie in X von Grund auf vorgesehen und 
funktioniert bei X.org quasi schon immer. Hab ich übrigens erst gestern 
genutzt.

> Da ist jetzt schon haufenweise kaputt -- wie gesagt, es ist unglaublich
> langsam mit Toolkits, die ihren eigenen Renderer haben, und ganz oder
> nahezu kaputt mit so Dingen wie Videos oder sogar OpenGL.

Keine Ahnung, was du mit "nahezu kaputt" meinst. Natürlich darf man 
nicht erwarten, daß der modernste Egoshooter damit flüssig über's Netz 
spielbar wird, aber für OpenGL-basierte Visualisierungen, die nicht ganz 
so anspruchsvoll sind, eignet es sich durchaus.

>> Auch sonst war X recht weit. Mit der Shape-Extension (~1990) gab es
>> Fenster mit beliebiger Form, die xeyes nutzen das ja auch...
> Na gut, "wer braucht das" frage ich jetzt mal lieber nicht :-)

Es gab lustigerweise eine Zeit, als X für sehr rückständig angesehen 
wurde, weil es so Spielchen wie z.B. bunte und animierte Mauszeiger 
nicht unterstüzt hat.

Also bei mir ging das noch nie, mit diversen Fehlern.

1

Xlib:  extension "GLX" missing on display "localhost:10.0".

Bernd K. schrieb:
> Einen ganz wichtigen hast Du vergessen: NX (oder Free-NX)

Meinst du die Variante in der NX als X-Server-Proxy dient, oder die (mit 
der 4er-Version zum Standard erkorene) Übertragung des kompletten 
Bildschirms? Letztere funktioniert leider meiner Erfahrung nach eher 
unzuverlässig, und die Bildqualität lässt auch zu wünschen übrig 
(Komprimierungsartefakte).

RDP unter Windows ist m.E. immer noch mit Abstand das beste um remote zu 
arbeiten.

Andreas Schwarz schrieb:
> Bernd K. schrieb:
>> Einen ganz wichtigen hast Du vergessen: NX (oder Free-NX)
>
> Meinst du die Variante in der NX als X-Server-Proxy dient, oder die (mit
> der 4er-Version zum Standard erkorene) Übertragung des kompletten
> Bildschirms?

Das wird wohl die erste Variante sein, nx als X proxy. So kenn ich das 
und so hat es mir schon gute Dienste geleistet.

Gesamtes Bild übertragen stell ich mir da eher als Rückschritt vor, das 
wär ja dann keinen Deut besser als VNC von der Performance (also 
unterirdisch).

Die Variante mit X-Proxy war Pfelschnell, sogar über ne lahme 128kBit/s 
DSL-Leitung (mein damaliger Upstream an ner 1000er Leitung, hab es 
benutzt um von der Firma aus meinen Desktop zuhause zu bedienen).

Gefühlt war es in etwa so schnell wie RDP. VNC über die selbe Verbindung 
war vollkommen unbrauchbar. X über ssh sogar noch schlechter als VNC.