Nun ja, die Ansteuerung von X unterscheidet sich signifikant zu der des Grafik Subsystems von Windows. Wo bei Windows die Zeichenroutinen direkt auf, teilweise sehr systemverwurzelte API Funktionen greifen, hast du bei X nunmal noch ein Transportprotokoll, wie zB TCP/IP dazwischen liegen über das erst auf die eigentlichen Zeichenroutinen zugegriffen wird. Aus _grober theorethischer_ Sicht, ist es dann klar, dass sich die Oberfläche unter Windows idR flüssiger anfühlt. Jedoch liegen die Vorteile eines Transportprotokolls zwischen Anwendung/Client und Grafik-Subsystem auf der Hand. Man hat ein Server-Client Modell. Man kann solche Dinge machen, wie die Verbindung zum XServer schließen, jedoch die grafischen Applikationen weiter laufen lassen. Dann kann man sich irgendow anders einloggen und hat wieder das gleiche Bild vor sich. Das ist nur eine von abertausenden Möglichkeiten die so ein Client-Server Modell bietet. Äquivalentes unter Windows zu implementieren ist eine Qual, wenngar unmöglich. Daher würde ich eher sagen, dass X dem Grafik-Subsystem von Windows meilenweit vorraus ist. Geschwindigkeit ist bei weitem nicht alles.
Was mich diesbezueglich interessieren wuerde: Nun gibt es doch inzwischen Loesungen wie FreeNX, welche das Protokoll um das gefuehlte hundertfache beschleunigen. Wieso implementiert man sowas nicht direkt rein? Abwaertskompatibilitaet? Oder noch besser. Wieso deaktiviert man die Netzwerktransparenz nicht einfach und laesst den User selber entscheiden, ob er sowas wie FreeNX nachinstallieren will? X ist nur (und da auch nur sehr beschraenkt) im lokalen Netz brauchbar.
Die Netzwerktransparenz ist in der Standardeinstellung deaktiviert. Bei OpenGL eh (direct rendering). Aber auch eine abgeschaltete Netzwerktransparenz ändert nichts daran, dass die Abstraktionsschicht erhalten bleibt. Jedes X-Programm wird runtergebrochen auf elementare netzwerktaugliche Befehle.
Naja, in der Praxis sehe ich trotzdem eher Nachteile. Unter Windows kann man sich auch Remote einloggen, was m.E. auch deutlich schmerzfreier funktioniert als unter Linux. Theoretisch gesehen ist es natürlich so, dass so ein Schichtenmodell viel sicherer sein soll. In der Praxis ist es aber so, dass X eher unsicher ist. Auf früheren Linuxinstallationen hatte ich darüber hinaus auch häufig mit Instabilitäten zu kämpfen - klar, eher wegen der Treiber, aber wozu dann diese ganze Komplexität, wenn sie sowieso nichts bringt?
Wie es bei solchen Installationen mit sehr vielen Clients ist, kann ich nicht beurteilen. Aber spätestens seit Windows for Workgroups gibt es doch Netzwerksupport. Einen gewissen Reifegrad sollte die Windowswelt in dieser Hinsicht dann doch auch haben, oder?
Ich meine das Teil erstmal einzurichten - und mit XDMCP, unter den Ubuntuversionen der letzten 2-3 Jahre ist übrigens ein Bug dabei, der es verhindert dies auf einfache Art und Weise zu bewerkstelligen.
Wer weiß, welche benutzt der Client unter Linux? Abgesehen davon gibt es ja für höhere Ansprüche VPN, aber über das Internet will man (ich^^) ja normal eh keinen Remoteclient benutzen, weil das viel zu langsam ist...
Dein Name scheint Programm zu sein. Du brauchst dazu überhaupt nichts einrichten, einfach den Befehl des Vorposters nutzen, ggf. noch mit -C für Kompression und schon kannst du jedes beliebige Programm remote über eine per SSH verschlüsselte Verbindung starten und es fügt sich perfekt in deinen lokalen Desktop ein, so als würde es lokal laufen.
Meiner Meinung nach ist die Netzwerktransparenz von X kein wirkliches Totschalgargument mehr, denn es gibt inzwischen genug andere Möglichkeiten einen Remotedesktop zu ermöglichen. Mit der Behauptung, dass X dem Windows-Grafiksystem überlegen ist wäre ich vorsichtig. Du vergisst das X etwas sehr entscheidentes nicht kann und das sind geräteunabhängige Grafikkontexte (IMHO viel wichtiger als Netzwerktransparenz). Windows kann über verschidene Kontexte auf alle möglichen Ausgabegeräte wie Drucker, Bildschirme, Offscreen-Speicherkontexte zeichnen. Für X sind das alles total unterscheidliche Sachen. Btw: Auch Apple hat etwas ähnliches aber noch viel ausgefeilteres. Nennt sich Display Postscript. Sie haben sich damals ganz bewusst gegen einen X-Server entschieden, wegen den oben genannten Nachteilen bei der Geräteabstraktion.
Es gab ja immer wieder Versuche die alte X-Architektur abzulösen. Zum Beispiel Wayland als schneller und schlanker Grafikserver. Leider sieht es so aus als sei das Projekt schon wieder eingeschlafen. Meiner Meinung sollte man bei einer Neuentwicklung auch mal eine einheitliche Widget-Rendering Engine etablieren auf die GTK, Qt usw. zugreifen können. Nie wieder Sprüche wie: "Meine Qt/GTK-Anwendungen sieht aber hässlich/globig/... unter GNOME/KDE aus. Lasst Toolkit XYZ endlich sterben ..."
Mit X werden wir wohl noch lange leben müssen. Der Dinosaurier hält sich wacker ...
> Meiner Meinung nach ist die Netzwerktransparenz von X kein wirkliches Totschalgargument mehr, > denn es gibt inzwischen genug andere Möglichkeiten einen Remotedesktop zu ermöglichen.
Die Netzwerktransparenz von X ist nicht mit einem Remotedesktop gleichzusetzen, dass ist es, was viele nicht verstehen. XDMCP ist nur einer der Vorteile, X ist auch auf Applikationsebene netzwerktransparent. Nenne uns doch eine einfachere und sicherere Alternative, als per ssh -X eine entfernte Applikation lokal darzustellen, welche sich sauber in den lokalen Desktop einfügt und keinen Fremdkörper darstellt.
Jaja, diese tolle Netzwerktransparenz. Es lohnt sich nicht über Features zu reden die üblicherweise eher selten genutzt werden, gegenüber Problemen und Unzulänglichkeiten die ständig bei X auftreten. Und was bringt mir die ach so tolle Applikationsintegration übers Netzwerk, wenn sich die meisten Toolkits, Desktop Environments immer noch kaum untereinander verstehen. Glücklicherweise gibt es ja Bestrebungen die Grafikkartenverwaltung wieder in die Hände des Betriebessystems zu legen - wo sie ja eigentlich auch hingehört. Das könnte alterativen Grafikservern endlich die Möglichkeit geben X zu beerben. Bisher scheiterte das ja vorallem an den Grafiktreibern.
Schließe mal nicht von dir auf andere, ich benötige die Netzwerktransparenz tagtäglich. Und welche Toolkits oder Desktopumgebungen sollen sich bitte nicht miteinander verstehen??
Ich weiß nicht warum du auf deiner Netzwerktransarenz so rumreitest. X hat zur Zeit ganz andere Probleme als das man immer hervorheben muss wie toll doch ssh -X ist. Mit "nicht verstehen" meine ich: Einstellungen zum Look&Feel, Schriftgrößen usw. Ja ich weiß dafür gibt es hacks aber es sind eben nur hacks.
Also ich habe kein Problem mit unterschiedlichen Toolkits, denn man kann sie gut und recht einfach konfigurieren. Ein Linux-Desktop mit verschiedenen Applikationen die mit unterschiedlichen Toolkits realisiert wurden sieht bereits heute um einiges einheitlicher aus, als dass was man unter Windows vorgesetzt bekommt (siehe meinen Kommentar weiter oben).
Daher würde ich eher sagen, dass X dem Grafik-Subsystem von Windows meilenweit vorraus ist. Geschwindigkeit ist bei weitem nicht alles.
Nun gibt es doch inzwischen Loesungen wie FreeNX, welche das Protokoll um das gefuehlte hundertfache beschleunigen. Wieso implementiert man sowas nicht direkt rein? Abwaertskompatibilitaet? Oder noch besser. Wieso deaktiviert man die Netzwerktransparenz nicht einfach und laesst den User selber entscheiden, ob er sowas wie FreeNX nachinstallieren will?
X ist nur (und da auch nur sehr beschraenkt) im lokalen Netz brauchbar.
Wie es bei solchen Installationen mit sehr vielen Clients ist, kann ich nicht beurteilen. Aber spätestens seit Windows for Workgroups gibt es doch Netzwerksupport. Einen gewissen Reifegrad sollte die Windowswelt in dieser Hinsicht dann doch auch haben, oder?
Ist ja auch so schwer:
$ ssh -X remote-host
Welche Verschlüsselung verwendet der RDP-Client unter Windows?
Wer weiß, welche benutzt der Client unter Linux?
Abgesehen davon gibt es ja für höhere Ansprüche VPN, aber über das Internet will man (ich^^) ja normal eh keinen Remoteclient benutzen, weil das viel zu langsam ist...
Btw: Auch Apple hat etwas ähnliches aber noch viel ausgefeilteres. Nennt sich Display Postscript. Sie haben sich damals ganz bewusst gegen einen X-Server entschieden, wegen den oben genannten Nachteilen bei der Geräteabstraktion.
Es gab ja immer wieder Versuche die alte X-Architektur abzulösen. Zum Beispiel Wayland als schneller und schlanker Grafikserver. Leider sieht es so aus als sei das Projekt schon wieder eingeschlafen. Meiner Meinung sollte man bei einer Neuentwicklung auch mal eine einheitliche Widget-Rendering Engine etablieren auf die GTK, Qt usw. zugreifen können. Nie wieder Sprüche wie: "Meine Qt/GTK-Anwendungen sieht aber hässlich/globig/... unter GNOME/KDE aus. Lasst Toolkit XYZ endlich sterben ..."
Mit X werden wir wohl noch lange leben müssen. Der Dinosaurier hält sich wacker ...
> denn es gibt inzwischen genug andere Möglichkeiten einen Remotedesktop zu ermöglichen.
Die Netzwerktransparenz von X ist nicht mit einem Remotedesktop gleichzusetzen, dass ist es, was viele nicht verstehen. XDMCP ist nur einer der Vorteile, X ist auch auf Applikationsebene netzwerktransparent. Nenne uns doch eine einfachere und sicherere Alternative, als per ssh -X eine entfernte Applikation lokal darzustellen, welche sich sauber in den lokalen Desktop einfügt und keinen Fremdkörper darstellt.
Glücklicherweise gibt es ja Bestrebungen die Grafikkartenverwaltung wieder in die Hände des Betriebessystems zu legen - wo sie ja eigentlich auch hingehört. Das könnte alterativen Grafikservern endlich die Möglichkeit geben X zu beerben. Bisher scheiterte das ja vorallem an den Grafiktreibern.
Mit "nicht verstehen" meine ich: Einstellungen zum Look&Feel, Schriftgrößen usw. Ja ich weiß dafür gibt es hacks aber es sind eben nur hacks.