Morgen, 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". Die Lösungen sind wohl hauptsächlich VNC oder RDP. Beide übertragen im Prinzip Events von Maus und Tastatur zum Server, dieser bearbeitet die Eingabe und zurückgeschickt wird dann ein "Bild" (wobei RDP da bisl trickreicher ist). Die Serversoftware setzt dabei unter unixoiden Systemen auf X auf. So, jetzt frage ich mich, wieso eigentlich nicht direkt X? Soweit ich weis wurde X vor Jahrzenten aus genau dem Grund eingeführt. Um Server (Verarbeitung) und Client (Darstellung) sauber zu trennen. Wieso wird also dieses grundlegende Feature von X nirgends benutzt? In 99,9% der Fälle laufen ja Server und Client auf der selben Maschine. Wieso setzt man dann auf den X Server ein weiteres Client-Server Protokoll drauf? Ist X veraltet? Wieso benutzt man dann überhaupt noch diese Zwischenschicht, wenn dessen Features eh keiner mehr nutzt? Freue mich auf Rückmeldungen, würde mich sehr interessieren!
X ist einfach viel zu langsam über langsame Leitungen, es werden viel zu viel API aufrufe übertragen. Es werden auch viele Dinge übertragen, die am ende nicht mal Sichtbar sind. Denn das entscheidet der X-Server. > Ist X veraltet? ja, etwas > Wieso benutzt man dann überhaupt noch diese Zwischenschicht, wenn dessen > Features eh keiner mehr nutzt? sie wird nicht mehr wirklich genutzt, Video machen damit Probleme. Nachfolger ist doch schon in arbeit http://de.wikipedia.org/wiki/Wayland_(Protokoll)
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.
:
Bearbeitet durch Moderator
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 :-)
:
Bearbeitet durch User
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
Sven B. schrieb: > ssh kann übrigens auch Kompression, ssh -C die Latenz ist aber das Problem und nicht die Bandbreite. Und die wird durch Kompression noch schlechter.
Arc Net schrieb: > http://www.raspians.com/Knowledgebase/setting-up-a... Was hattn das mit der Frage zu tun?
Hi, 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". > > Die Lösungen sind wohl hauptsächlich VNC oder RDP. Naja, es gibt halt nicht mehr viele klassische Terminals -- und schon gar keine X-Terminals. Die können jetzt Protokolle mit Vorteilen gegenüber X, zum Beispiel Windows-Unterstützung und Verschlüselung. Aus diesem Grund gibt es immer weniger klassische X-Terminals und immer mehr Terminals mit VNC, RDP, NX oder Citrix. > So, jetzt frage ich mich, wieso eigentlich nicht direkt X? Selbstverständlich kannst Du immer noch X benutzen, wenn Du möchtest, und mit dxpc(1) sogar komprimiert und halbwegs komfortabel über schmalbandige DialUp-Verbindungen. Wenn Du nur ein einzelnes grafisches Programm aufrufen statt eines ganzen Display umleiten möchtest, funktioniert unter Systemen mit X-Server ein "ssh -X" oder unter einem Windows ohne X-Server das Programm "Moba Xterm". Dabei wird das X-Protokoll über einen verschlüsselten und optional auch komprimierten SSH-Tunnel geleitet. HTH, Karl
Hallo, Peter II schrieb: > Sven B. schrieb: >> ssh kann übrigens auch Kompression, ssh -C > > die Latenz ist aber das Problem und nicht die Bandbreite. Und die wird > durch Kompression noch schlechter. Unfug. Auf einem lahmen Link zwischen zwei schnellen Büchsen bringt die Komprimierung richtig viel und verbessert die Latenz erheblich. Weil die schnellen Maschinen dann nämlich schneller komprimieren und dekomprimieren können, als die Zeitdifferenz zwischen den Übertragungen von komprimierten und unkomprimierten Datenmengen beträgt. Beste Grüße, Karl
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.
... ich habe mal Xming getestet (hab eine Lizenz) um von Windows auf den Rasperry Pi zuzugreifen und es funktioniert im lokalen Netz sehr gut! http://de.wikipedia.org/wiki/Xming
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.
:
Bearbeitet durch Admin
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.