Da das Thema Netzwerktransparenz immer wieder heiss diskutiert wird,
wenn es um Wayland geht, hier mal einige Fakten:
1. Die X-Forwarding ist mit aktuellen Applikationen zu langsam
X ist nicht mehr die Rendering-Schicht. Fuer X war vorgesehen, dass
Zeichenbefehle ueber das Netzwerk uebertragen werden. Das ist nicht
mehr der Fall, da die Applikationen heute Bitmaps an den Server
uebertragen, was X-Forwarding nur in Netzwerken mit hoher Bandbreite
benutzbar macht. Manche Anwendungen versagen sogar bei hoher
Bandbreite und selten ist das Arbeiten mit remote-Applikationen unter
X angenehm. Einzelne Faelle, in denen Netzwerktransparenz erfolgreich
und gerne eingesetzt wird, bleiben, nunja, einzelne Faelle. Und ja,
ich habe es selbst ausprobiert. Ueber DSL und in einem
100MBit-Netzwerk Zusaetzlich fuehlen sich die Anwendungen oft wie
Fremdkoerper an, da sie keine Informationen ueber lokale Themes
erhalten. Das sieht X-Forwarding naemlich nicht vor.
2. Ein netzwerktransparentes GUI reicht nicht aus
Die Netzwerktransparenz von X funktioniert nicht mit allen
Anwendungen, da sie sich lediglich um die GUI und Input kuemmert.
Sound und Dbus z.B. sind i.d.R. nicht Netzwerktransparent bzw. werden
nicht automatisch mit umgeleitet, was viele Anwendungen unbenutzbar
macht. Eine vollstaendigere Loesung wird also ohnehin benoetigt.
3. Wayland verbietet Netzwerktransparenz nicht
Obwohl Netzwerktransparenz noch nicht in Wayland implementiert ist,
bedeutet das nicht, dass es nicht implementierbar ist. Mit
entsprechenden Erweiterungen koennen Wayland-Anwendungen auf dieselbe
Weise wie X11-Anwendungen ueber das Netzwerk uebertragen werden.
Wobei das Unsinn waere, da es die heutigen Probleme der
X11-Netzwerktransparenz nur zum Teil loest.
Viel besser waere es, die Netzwerktranparenz in die Rendering-Schicht
- das waeren die Toolkits - einzubauen. Jetzt werden natuerlich die
Ersten wieder "Bloat!" und "Redundanz!" bruellen, was sicherlich
nicht ganz ungerechtfertigt ist. Jedoch bringt diese Methode
wesentliche Vorteile mit sich. Alles, was auf Toolkit-Ebene erledigt
wird, kann uebertragen werden. Nicht nur das Interface sondern auch
der Sound, dbus etc.. Denkbar waere auch ein einfacher Zugriff auf
die lokalen Dateien, was in X nur ueber Umwege moeglich ist.
Zusaetzlich brauchen statt Bitmaps nur informationen ueber
Interfaceelemente uebertragen werden, wodurch die benoetigte
Bandbreite drastisch reduziert wird und der Anwendung die
Moeglichkeit gegeben wird, das Interface dem Zielrechner anzupassen
(Icons, Theme, Fonts).
Denkbar waere ein Scenario, in dem Wayland oder ein anderer Server
die Netzwerktransparenz verwaltet, nach Bibliotheken sucht, ueber
fehlende Bibliotheken informiert und im Zweifelsfall die
Fallback-Loesung der Bitmapuebertragung verwendet.
Fakt ist, dass die Netzwerktransparenz von X nur begrenzt
funktioniert und problembehaftet ist. Das als Totschlagargument
vorzubringen, ist jaemmerlich.
Hinzu kommt, dass die meisten remote-Apps heutzutage HTML-Apps sind.
Das macht sie Plattformunabhaengig, reaktionsfreudig und
bandbreitenfreundlich. Vielleicht ist dies ohnehin die Zukunft von
remote-Applikationen.
4. X verschwindet nicht
Die nachsten Jahre werden X und Wayland parallel existieren, denn
Wayland wird zweifelsohne noch etwas reifen muessen, vor allem im
Bezug auf Anwendungs- und Treiberunterstuetzung. Genug Zeit, sich
nach Alternativen umzuschauen. Solange sich die Netzwerktransparenz
von X als unverzichtbar erweist, wird X denjenigen, die es brauchen,
als Option zur Verfuegung stehen. Kein Grund zur Panik.
wenn es um Wayland geht, hier mal einige Fakten:
1. Die X-Forwarding ist mit aktuellen Applikationen zu langsam
X ist nicht mehr die Rendering-Schicht. Fuer X war vorgesehen, dass
Zeichenbefehle ueber das Netzwerk uebertragen werden. Das ist nicht
mehr der Fall, da die Applikationen heute Bitmaps an den Server
uebertragen, was X-Forwarding nur in Netzwerken mit hoher Bandbreite
benutzbar macht. Manche Anwendungen versagen sogar bei hoher
Bandbreite und selten ist das Arbeiten mit remote-Applikationen unter
X angenehm. Einzelne Faelle, in denen Netzwerktransparenz erfolgreich
und gerne eingesetzt wird, bleiben, nunja, einzelne Faelle. Und ja,
ich habe es selbst ausprobiert. Ueber DSL und in einem
100MBit-Netzwerk Zusaetzlich fuehlen sich die Anwendungen oft wie
Fremdkoerper an, da sie keine Informationen ueber lokale Themes
erhalten. Das sieht X-Forwarding naemlich nicht vor.
2. Ein netzwerktransparentes GUI reicht nicht aus
Die Netzwerktransparenz von X funktioniert nicht mit allen
Anwendungen, da sie sich lediglich um die GUI und Input kuemmert.
Sound und Dbus z.B. sind i.d.R. nicht Netzwerktransparent bzw. werden
nicht automatisch mit umgeleitet, was viele Anwendungen unbenutzbar
macht. Eine vollstaendigere Loesung wird also ohnehin benoetigt.
3. Wayland verbietet Netzwerktransparenz nicht
Obwohl Netzwerktransparenz noch nicht in Wayland implementiert ist,
bedeutet das nicht, dass es nicht implementierbar ist. Mit
entsprechenden Erweiterungen koennen Wayland-Anwendungen auf dieselbe
Weise wie X11-Anwendungen ueber das Netzwerk uebertragen werden.
Wobei das Unsinn waere, da es die heutigen Probleme der
X11-Netzwerktransparenz nur zum Teil loest.
Viel besser waere es, die Netzwerktranparenz in die Rendering-Schicht
- das waeren die Toolkits - einzubauen. Jetzt werden natuerlich die
Ersten wieder "Bloat!" und "Redundanz!" bruellen, was sicherlich
nicht ganz ungerechtfertigt ist. Jedoch bringt diese Methode
wesentliche Vorteile mit sich. Alles, was auf Toolkit-Ebene erledigt
wird, kann uebertragen werden. Nicht nur das Interface sondern auch
der Sound, dbus etc.. Denkbar waere auch ein einfacher Zugriff auf
die lokalen Dateien, was in X nur ueber Umwege moeglich ist.
Zusaetzlich brauchen statt Bitmaps nur informationen ueber
Interfaceelemente uebertragen werden, wodurch die benoetigte
Bandbreite drastisch reduziert wird und der Anwendung die
Moeglichkeit gegeben wird, das Interface dem Zielrechner anzupassen
(Icons, Theme, Fonts).
Denkbar waere ein Scenario, in dem Wayland oder ein anderer Server
die Netzwerktransparenz verwaltet, nach Bibliotheken sucht, ueber
fehlende Bibliotheken informiert und im Zweifelsfall die
Fallback-Loesung der Bitmapuebertragung verwendet.
Fakt ist, dass die Netzwerktransparenz von X nur begrenzt
funktioniert und problembehaftet ist. Das als Totschlagargument
vorzubringen, ist jaemmerlich.
Hinzu kommt, dass die meisten remote-Apps heutzutage HTML-Apps sind.
Das macht sie Plattformunabhaengig, reaktionsfreudig und
bandbreitenfreundlich. Vielleicht ist dies ohnehin die Zukunft von
remote-Applikationen.
4. X verschwindet nicht
Die nachsten Jahre werden X und Wayland parallel existieren, denn
Wayland wird zweifelsohne noch etwas reifen muessen, vor allem im
Bezug auf Anwendungs- und Treiberunterstuetzung. Genug Zeit, sich
nach Alternativen umzuschauen. Solange sich die Netzwerktransparenz
von X als unverzichtbar erweist, wird X denjenigen, die es brauchen,
als Option zur Verfuegung stehen. Kein Grund zur Panik.