Für kleine Unternehmen sind 800 EUR im Jahr nicht wenig, damit fängt die günstigste Kauf-Version an. Aber was kann die kostenlose Version eigentlich nicht?
Von Frank Frank am Mo, 30. September 2013 um 15:58 #
Eigentlich würde ich von einem X11-Nachfolger erwarten, dass er einen Großteil der Funktionalität von NoMachine NX ab Werk mitbringt. Zumindest aber die Möglichkeit, Remote mit anpassbarer (auch verlustbehafteter) Kompression auf den Desktop zuzugreifen und eine Session auch ohne offene Verbindung weiterlaufen zu lassen. Das tunneln von beliebigen weiteren Datenkanälen (eben Drucker und so weiter) sollte zumindest im Protokoll vorgesehen sein, damit sich CUPS, PulseAudio etc. dranhängen können.
Was kriegen wir statt dessen? Wayland und Mir. Beide haben noch nicht mal Netzwerktransparenz. Richtig: Statt verrückten Kram aus der Zukunft (NX) auf unsere Systeme zu packen, gehen wir acht Schritte in die Vergangenheit und basteln "Nachfolger", welche den Namen nicht verdienen und nicht mal das können, was sogar Windows kann. Das einzige, was wir durch Wayland und Mir "gewinnen", sind flickerfreie Fenster. Ganz recht. Grafische Spielereien statt echte Features.
Ich würde lachen, wenn es nicht so verdammt traurig wäre. Und mich ärgert, dass ich nicht in der Lage bin, mich einfach hinzusetzen und den notwendigen Code zu schreiben.
Von Unerkannt am Mo, 30. September 2013 um 16:39 #
Zumindest aber die Möglichkeit, Remote mit anpassbarer (auch verlustbehafteter) Kompression auf den Desktop zuzugreifen und eine Session auch ohne offene Verbindung weiterlaufen zu lassen.
Es gibt doch schon VNC.
Das tunneln von beliebigen weiteren Datenkanälen (eben Drucker und so weiter) sollte zumindest im Protokoll vorgesehen sein, damit sich CUPS, PulseAudio etc. dranhängen können.
X11 mag aktuell ein alter und aufgeblasener Moloch sein aber die technischen Ideen sind immer noch sehr gut.
Vollständige Netzwerktransparenz wäre für den Nachfolger absolut wünschenswert. Sowie eine ordentliche Multi-Monitor Unterstützung über mehrere Rechner hinweg.
Also zum Beispiel: 4 Monitore von 3 Rechnern, wobei die Fenster frei verschoben werden können. Da würden mir schon viele Möglichkeiten zur Nutzung einfallen.
Mit Multi Maus und Tastatur würden sich dann ganz neue Welten öffnen. Zum Beispiel richtiges Teamwork auf entsprechend großen Anzeigen (Stichwort "Interaktive Wand") *träum*.
Eigentlich würde ich von einem X11-Nachfolger erwarten, dass er einen Großteil der Funktionalität von NoMachine NX ab Werk mitbringt.
Eigentlich ist ja genau das der Fall. Wie bei NX basiert der Remote Support bei Wayland (wird bei Mir sicher ähnliche gemacht werden) auf dem dem Prinzip, dass Anwendungen mit einem lokalen Displayserver arbeiten und der wiederum mit einem Displayserver am anderen Ende.
Dadurch lässt sich ja auch das Abkoppeln der Sitzung erzielen, weil die Anwendungen davon nichts mit bekommen (ihre Verbindung ist ja zum lokalen Server).
Von Frank Frank am Mo, 30. September 2013 um 22:55 #
Welcher Remote Support? Wayland hat ganz erklärtermaßen keinen, da sich die Entwickler keinen Kopf darum machen wollen. Und ein auf Wayland aufgepropftes RDP/VNC/RFB ist ganz sicher nicht das, was man haben will, da es eben nur aufgepropft und inkonsequent ist.
Ich verstehe bis heute nicht, warum man etwas so zentrales wie die Netzwerktransparenz erst ignoriert, um sie dann hinterher wieder irgendwie durch die Hintertür einzubauen - in schlecht.
Ein Ersatz für X11 sollte meiner Ansicht nach Features haben, welche 20 Jahre in die Zukunft schauen, und nicht irgend ein Kram, der nicht mal auf dem Niveau von Windows 2000 Terminal Server ist.
Von Unwichtig am Mo, 30. September 2013 um 23:40 #
Zumindest war sowas wie eine Remoteverbindung angedacht. Ob es sich nur um einen Hack handelt, der nie produktiv genutzt wird, kann ich leider nicht sagen da ich mich mit der Entwicklung nicht gross auseinandergesetzt habe.
http://www.youtube.com/watch?v=L8zwnqKysfI Ab 1:11:50
Das Video wurde schon bereits bei PL in einem Artikel [1] erwähnt und da steckt wohl Kristian Høgsberg selbst dahinter, also dürfte da ziemlich viel dran sein. Aber warten wir es ab.
Den Commit für den Remote Desktop Support in Weston findet man hier.
Wie eben auch bei NX werden Applikationen über eine dafür spezialiserte Client/Server Verbindung remote verfügbar gemacht.
Wie bei NX läuft dazu am Rechner der Applikation ein lokaler Displayserver, der aus Sicht der Applikation das Ausgabemedium ist und von dem die Benutzereingaben kommen. Auf der anderen Seite ist dann ein spezieller Client, der mit diesem Zwischenserver kommuniziert. im Falle von NX der NX Client, im Falle von RDP ein RDP Client.
Wie diese und ähnliche Technologien gezeigt haben, hat diese Form der Weiterleitung eine Reihe von Vorteilen, u.a. die Möglichkeit, die Verbindung zwischen Client und Zwischenserver zu unterbrechen und wieder neu aufzubauen, oder Protokolle einzusetzen, die z.B. mit den Latenzen des Netzwerks besser umgehen können.
Wie du ja schon selbst im ersten Kommentar festgestellt hast, wird hier "verrückten Kram aus der Zukunft (NX) auf unsere Systeme" gepackt. Und dass dann noch herstellerneutral!
Moooooment: Der Remote-Support wird hier einfach so implementiert, dass RDP ein Backend für Weston ist. Aber Weston ist nur der Referenz-Compositor, und die ganzen größeren Desktop-Environments werden sich ihre eigenen Compositor schreiben bzw. ihre X11-Windowmanager anpassen (siehe kwin).
Also muss entweder jeder andere Compositor ebenfalls ein RDP-Backend implementieren, oder man kann nur Remote auf Wayland zugreifen, wenn man Weston nimmt. Wenn KDE also nicht das RDP-Backend in kwin einbaut, kann ich keine vollständige KDE-Sitzung über Wayland mit RDP fahren, sondern ich muss Weston als Compositor nehmen und dann darunter die KDE-Anwendungen starten. Wenn jemand auf die dumme Idee kommen sollte, Anwendungen an einen bestimmten Compositor zu binden (und das wird garantiert passieren, denn Wayland kann nicht jeden zukünftigen Anwendungsfall berücksichtigen, also wird man irgendwann Erweiterungen haben, welche nicht über Wayland implementiert werden können. Siehe beispielsweise Icons in der Taskleiste, das wurde irgendwann auch an X11 vorbei mit D-Bus implementiert, weil das X11-Interface zu alt und starr war), und dieser Compositor implementiert keinen Remote Support, dann habe ich verloren.
Das ist genau das, was ich meine: Remote-Support ist eben NICHT in Wayland integriert, sondern einfach nur nachträglich und inkonsequent an der falschen Stelle angeflanscht. Remote Support gehört nicht als Backend in den Compositor, vor allem dann nicht, wenn jeder einen anderen Compositor verwendet!
Ob der Fernzugriff jetzt am besten im Compositor ist oder in eine anderen speziellem Komponente, lässt sich sicher so und so argumentieren.
Dagegen ziemlich sicher ist, dass die Kommunikation von Anwendung und Compositor nichts davon wissen muss, wie eben alle anderen Techniken dazu, u.a. NX, sehr schön demonstrieren.
Der Fernzugriff hat einfach andere Anforderungen als der lokale, u.a. auch weil die zur Verfügung stehenden Kommunikationstechnologien so unterschiedlich sind.
Was jetzt die derzeitige Implementierung als Compositor Backend betrifft und die Problematik der Compositorauswahl, denke ich dass es zu einer von zwei Lösungen kommen wird:
1) eine gemeinsame Bibliotek erlaubt allen Compositor Entwicklern ihr jeweiliges Backend mit einem Minimum an Aufwand zu warten
2) ähnlich wie bei NX etabliert sich ein Remote Compositor, zum Beispiel Weston. Die anderen werden bei lokaler Darstellung benutzt, haben vielleicht sogar einen speziellen Clientmodus für den Remotefall.
Ich denke das der zweite Ansatz das bessere Potential hat, weil sich die dort beteiligeten Enwickler dann speziell mit dem Herrausvorderungen des Fernzugriffs beschäftigen können, z.B. Integration und/oder Weiterleitung andere Kanäle.
Die Gefahr, dass spezielle Protokollerweiterungen dann von diesem Compositor nicht unterstützt werden ist natürlich gegeben, aber ja auch schon zu diesem Zeitpunkt existent, wie das von dir anegführte Statusiconbeispiel ja schön zeigt.
Daher sehe ich auch in der zweiten Variante das höhere Potential, denn dann muss die Unterstützung nur an einer Stelle implementiert werden.
Aber das wird die Zeit zeigen. Momentan finde ich es gut, dass aus den Erfahrungen mit NX gelernt wurde und der Remotesupport nach dieser Vorlage umgesetzt wird.
Und das Problem ist gelöst sobald man RDP (oder was auch immer) in den system-compositor einbaut. Dann kann man die ganze session einfach weiterreichen und Logind kümmert sich um die Sicherheit.
Von Unwichtig am Mo, 30. September 2013 um 20:01 #
"Zudem gibt die Lösung dem Anwender die Möglichkeit, sogenannte »seamless connections« zu starten. So lässt sich beispielsweise eine bestehende Verbindung trennen und später wieder von einer anderen Workstation aufnehmen."
Seamless meint, dass "einzelne Anwendungen" dargestellt werden und nicht der ganze Desktop - eigentlich so wie es bei X-Forward auch gemacht wird... oder dem etwas bekannteren Citrix ICA schon lange geht (Published Applications)
Was hier gemeint wurde hat einen anderen Namen... Der mir gerade entfallen ist :) Keep-Alive oder sowas...
Für kleine Unternehmen sind 800 EUR im Jahr nicht wenig, damit fängt die günstigste Kauf-Version an. Aber was kann die kostenlose Version eigentlich nicht?
Kein Support
schränkt auf 2 Verbindungen absolut, jedenfalls war es bei der 3er-Versin so
Nimm halt x2go, basiert auf der noch freien NX Bibliothek.
Eigentlich würde ich von einem X11-Nachfolger erwarten, dass er einen Großteil der Funktionalität von NoMachine NX ab Werk mitbringt. Zumindest aber die Möglichkeit, Remote mit anpassbarer (auch verlustbehafteter) Kompression auf den Desktop zuzugreifen und eine Session auch ohne offene Verbindung weiterlaufen zu lassen. Das tunneln von beliebigen weiteren Datenkanälen (eben Drucker und so weiter) sollte zumindest im Protokoll vorgesehen sein, damit sich CUPS, PulseAudio etc. dranhängen können.
Was kriegen wir statt dessen? Wayland und Mir. Beide haben noch nicht mal Netzwerktransparenz. Richtig: Statt verrückten Kram aus der Zukunft (NX) auf unsere Systeme zu packen, gehen wir acht Schritte in die Vergangenheit und basteln "Nachfolger", welche den Namen nicht verdienen und nicht mal das können, was sogar Windows kann. Das einzige, was wir durch Wayland und Mir "gewinnen", sind flickerfreie Fenster. Ganz recht. Grafische Spielereien statt echte Features.
Ich würde lachen, wenn es nicht so verdammt traurig wäre. Und mich ärgert, dass ich nicht in der Lage bin, mich einfach hinzusetzen und den notwendigen Code zu schreiben.
>Und mich ärgert, dass ich nicht in der Lage bin, mich einfach hinzusetzen und den notwendigen Code zu schreiben.
Das kann ich genauso so unterschreiben. Nicht nur in dem Zusammenhang.
Ich muss dir da vollständig zustimmen.
X11 mag aktuell ein alter und aufgeblasener Moloch sein aber die technischen Ideen sind immer noch sehr gut.
Vollständige Netzwerktransparenz wäre für den Nachfolger absolut wünschenswert. Sowie eine ordentliche Multi-Monitor Unterstützung über mehrere Rechner hinweg.
Also zum Beispiel: 4 Monitore von 3 Rechnern, wobei die Fenster frei verschoben werden können. Da würden mir schon viele Möglichkeiten zur Nutzung einfallen.
Mit Multi Maus und Tastatur würden sich dann ganz neue Welten öffnen. Zum Beispiel richtiges Teamwork auf entsprechend großen Anzeigen (Stichwort "Interaktive Wand") *träum*.
Eigentlich ist ja genau das der Fall. Wie bei NX basiert der Remote Support bei Wayland (wird bei Mir sicher ähnliche gemacht werden) auf dem dem Prinzip, dass Anwendungen mit einem lokalen Displayserver arbeiten und der wiederum mit einem Displayserver am anderen Ende.
Dadurch lässt sich ja auch das Abkoppeln der Sitzung erzielen, weil die Anwendungen davon nichts mit bekommen (ihre Verbindung ist ja zum lokalen Server).
Welcher Remote Support? Wayland hat ganz erklärtermaßen keinen, da sich die Entwickler keinen Kopf darum machen wollen. Und ein auf Wayland aufgepropftes RDP/VNC/RFB ist ganz sicher nicht das, was man haben will, da es eben nur aufgepropft und inkonsequent ist.
Ich verstehe bis heute nicht, warum man etwas so zentrales wie die Netzwerktransparenz erst ignoriert, um sie dann hinterher wieder irgendwie durch die Hintertür einzubauen - in schlecht.
Ein Ersatz für X11 sollte meiner Ansicht nach Features haben, welche 20 Jahre in die Zukunft schauen, und nicht irgend ein Kram, der nicht mal auf dem Niveau von Windows 2000 Terminal Server ist.
Zumindest war sowas wie eine Remoteverbindung angedacht. Ob es sich nur um einen Hack handelt, der nie produktiv genutzt wird, kann ich leider nicht sagen da ich mich mit der Entwicklung nicht gross auseinandergesetzt habe.
http://www.youtube.com/watch?v=L8zwnqKysfI Ab 1:11:50
Das Video wurde schon bereits bei PL in einem Artikel [1] erwähnt und da steckt wohl Kristian Høgsberg selbst dahinter, also dürfte da ziemlich viel dran sein. Aber warten wir es ab.
[1] http://www.pro-linux.de/news/1/18917/wayland-soll-netzwerktransparenz-erhalten.html
Den Commit für den Remote Desktop Support in Weston findet man hier.
Wie eben auch bei NX werden Applikationen über eine dafür spezialiserte Client/Server Verbindung remote verfügbar gemacht.
Wie bei NX läuft dazu am Rechner der Applikation ein lokaler Displayserver, der aus Sicht der Applikation das Ausgabemedium ist und von dem die Benutzereingaben kommen.
Auf der anderen Seite ist dann ein spezieller Client, der mit diesem Zwischenserver kommuniziert. im Falle von NX der NX Client, im Falle von RDP ein RDP Client.
Wie diese und ähnliche Technologien gezeigt haben, hat diese Form der Weiterleitung eine Reihe von Vorteilen, u.a. die Möglichkeit, die Verbindung zwischen Client und Zwischenserver zu unterbrechen und wieder neu aufzubauen, oder Protokolle einzusetzen, die z.B. mit den Latenzen des Netzwerks besser umgehen können.
Wie du ja schon selbst im ersten Kommentar festgestellt hast, wird hier "verrückten Kram aus der Zukunft (NX) auf unsere Systeme" gepackt.
Und dass dann noch herstellerneutral!
Moooooment: Der Remote-Support wird hier einfach so implementiert, dass RDP ein Backend für Weston ist. Aber Weston ist nur der Referenz-Compositor, und die ganzen größeren Desktop-Environments werden sich ihre eigenen Compositor schreiben bzw. ihre X11-Windowmanager anpassen (siehe kwin).
Also muss entweder jeder andere Compositor ebenfalls ein RDP-Backend implementieren, oder man kann nur Remote auf Wayland zugreifen, wenn man Weston nimmt. Wenn KDE also nicht das RDP-Backend in kwin einbaut, kann ich keine vollständige KDE-Sitzung über Wayland mit RDP fahren, sondern ich muss Weston als Compositor nehmen und dann darunter die KDE-Anwendungen starten. Wenn jemand auf die dumme Idee kommen sollte, Anwendungen an einen bestimmten Compositor zu binden (und das wird garantiert passieren, denn Wayland kann nicht jeden zukünftigen Anwendungsfall berücksichtigen, also wird man irgendwann Erweiterungen haben, welche nicht über Wayland implementiert werden können. Siehe beispielsweise Icons in der Taskleiste, das wurde irgendwann auch an X11 vorbei mit D-Bus implementiert, weil das X11-Interface zu alt und starr war), und dieser Compositor implementiert keinen Remote Support, dann habe ich verloren.
Das ist genau das, was ich meine: Remote-Support ist eben NICHT in Wayland integriert, sondern einfach nur nachträglich und inkonsequent an der falschen Stelle angeflanscht. Remote Support gehört nicht als Backend in den Compositor, vor allem dann nicht, wenn jeder einen anderen Compositor verwendet!
Ob der Fernzugriff jetzt am besten im Compositor ist oder in eine anderen speziellem Komponente, lässt sich sicher so und so argumentieren.
Dagegen ziemlich sicher ist, dass die Kommunikation von Anwendung und Compositor nichts davon wissen muss, wie eben alle anderen Techniken dazu, u.a. NX, sehr schön demonstrieren.
Der Fernzugriff hat einfach andere Anforderungen als der lokale, u.a. auch weil die zur Verfügung stehenden Kommunikationstechnologien so unterschiedlich sind.
Was jetzt die derzeitige Implementierung als Compositor Backend betrifft und die Problematik der Compositorauswahl, denke ich dass es zu einer von zwei Lösungen kommen wird:
1) eine gemeinsame Bibliotek erlaubt allen Compositor Entwicklern ihr jeweiliges Backend mit einem Minimum an Aufwand zu warten
2) ähnlich wie bei NX etabliert sich ein Remote Compositor, zum Beispiel Weston. Die anderen werden bei lokaler Darstellung benutzt, haben vielleicht sogar einen speziellen Clientmodus für den Remotefall.
Ich denke das der zweite Ansatz das bessere Potential hat, weil sich die dort beteiligeten Enwickler dann speziell mit dem Herrausvorderungen des Fernzugriffs beschäftigen können, z.B. Integration und/oder Weiterleitung andere Kanäle.
Die Gefahr, dass spezielle Protokollerweiterungen dann von diesem Compositor nicht unterstützt werden ist natürlich gegeben, aber ja auch schon zu diesem Zeitpunkt existent, wie das von dir anegführte Statusiconbeispiel ja schön zeigt.
Daher sehe ich auch in der zweiten Variante das höhere Potential, denn dann muss die Unterstützung nur an einer Stelle implementiert werden.
Aber das wird die Zeit zeigen. Momentan finde ich es gut, dass aus den Erfahrungen mit NX gelernt wurde und der Remotesupport nach dieser Vorlage umgesetzt wird.
Und das Problem ist gelöst sobald man RDP (oder was auch immer) in den system-compositor einbaut. Dann kann man die ganze session einfach weiterreichen und Logind kümmert sich um die Sicherheit.
"Zudem gibt die Lösung dem Anwender die Möglichkeit, sogenannte »seamless connections« zu starten. So lässt sich beispielsweise eine bestehende Verbindung trennen und später wieder von einer anderen Workstation aufnehmen."
Seamless meint, dass "einzelne Anwendungen" dargestellt werden und nicht der ganze Desktop - eigentlich so wie es bei X-Forward auch gemacht wird... oder dem etwas bekannteren Citrix ICA schon lange geht (Published Applications)
Was hier gemeint wurde hat einen anderen Namen... Der mir gerade entfallen ist :)
Keep-Alive oder sowas...