Login
Newsletter

Thema: Braucht eine grafische Oberfläche Netzwerktransparenz?

7 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von 1ras am Sa, 20. November 2010 um 02:17 #

Es gibt keine künstliche Netzwerktransparenz. Entweder sie ist vorhanden oder nicht.

Du kannst mir aber auch gerne ein alternatives Beispiel für Linux nennen, wie du ein Programm auf einem entfernten Rechner startest und lokal bedienst. Das Programm muss sich natürlich transparent verhalten und in den lokalen Desktop integrieren.

  • 0
    Von LH_ am Sa, 20. November 2010 um 17:47 #

    Diese alternative gibt es nicht, weil vielen das veraltete X Protokoll genug ist. Wäre X11 mit all seinen schwächen aber nicht mehr die Haupt-GUI, würden diese Alternativen entstehen, und auch genutzt werden.

    • 0
      Von 1ras am So, 21. November 2010 um 01:08 #

      Okay, besagte Antwort lautet aber "Netzwerktransparenz kann mit anderen Methoden erreicht werden" und nicht "Netzwerktransparenz könnte mit anderen Methoden erreicht werden."

      Wäre das X-Protokoll wirklich so schlecht wie es oft hingestellt wird, hätte sich schon lange eine Alternative gebildet. Bisherige Alternativen kranken aber an allen Ecken und Enden, so dass sie keine sind. Fehlende Netzwerktransparenz ist dabei nur ein Thema.

      Dieser Beitrag wurde 1 mal editiert. Zuletzt am 21. Nov 2010 um 01:09.
      • 0
        Von glasen am So, 21. November 2010 um 01:43 #

        > Bisherige Alternativen kranken aber an allen Ecken und Enden, so dass sie keine sind.

        Bisherige Alternativen hatten das Problem, dass sie wenig bis gar nicht zu den bisher existierenden Anwendungen kompatibel waren. Auch die Treibersituation war eine ganz andere.

        Wayland hat eine ganz andere Basis als z.B. der damalige Versuch "Fresco" :


        • Der Kernel selbst bietet heute die passenden Treiber an (Stichwort KMS). Die früheren Alternativen mussten selbst Treiber mitliefern.

        • Die beiden wichtigsten Toolkits (Qt und Gtk+) werden auf Wayland portiert. Dadurch wird es ein Kinderspiel bestehende Anwendungen auf Wayland zu portieren.

        • Global-Player wie Intel und Nokia und ihm Linuxbereich RedHat, stehen dahinter. Es ist also kein One-Man-Show.

        • Es wurde schon frühzeitig an einen Kompatibilitätslayer gedacht. X11-Anwendungen werden unverändert unter Wayland funktionieren.

        Zudem gibt es mehr als genügend Beispiele, dass ein Neuanfang nichts Schlechtes oder problematisch sein muss. Ich erinnere nur an die damalige Einführung von MacOS X. Dort wurde nicht nur die Benutzeroberfläche vollständig ausgetauscht, sondern auch das grundlegende Betriebssystem.

        Dieser Beitrag wurde 1 mal editiert. Zuletzt am 21. Nov 2010 um 01:44.
        • 0
          Von 1ras am Mo, 22. November 2010 um 02:22 #

          Wir werden sehen wie sich Wayland entwickelt. Bei einem neuen Protokoll und in der Hochzeit des Internets und der Vernetzung nicht von vorne herein auf Netzwerktransparenz zu achten, halte ich jedoch für einen Kardinalsfehler und massiven Rückschritt.

          Mich erinnert dies an die Zeit als Microsoft noch glaubte, das Internet ignorieren zu können...

          • 0
            Von gustl am Mo, 22. November 2010 um 22:18 #

            Sehe ich genau so

            In einer Transitionsperiode werden wir gar nicht viel von Wayland bemerken, weil ohnehin alle Applikationen X Clients sind, und der XServer den Wayland Compositor anspeist. Ob die Anwendung also remote gestartet wurde oder nicht ist für diesen Fall egal.

            Ganz anders wird es, wenn die Anwendungen zunehmend zu direkten Wayland Clients werden, dann ist es, zumindest so wie ich es verstanden habe, mit der Netzwerktransparenz vorbei, weil die Waylandclient --> Waylandcompositor Verbindung nicht Netzwerktransparent zu sein scheint

            Für mich ist es aber essentiell, dass ich JEDE grafische Anwendung auf einem anderen Rechner starten kann und das Fenster dazu auf meinem Desktop habe, ohne dass der User der vor dem anderen Rechner sitzt das mitbekommt.

            Ich finde man sollte in Wayland ein sehr rudimentäres Netzwerkprotokoll einführen, so dass die Verbindung Client --> Compositor Netzwerktransparent wird. Gut wäre da ein Buffer Rendering auf Clientseite (dann kann es die dortige Hardware benutzen), und das fertige Bild wird dann an den Compositor geschickt. Als vollständig neues Protokoll könnte man das dann so effizient wie NoMachine NX gestalten, was in Kombination mit clientseitigem Rendering 3D Anwendungen über ISDN Leitungen ermöglichen würde.

            • 0
              Von 1ras am Do, 25. November 2010 um 01:17 #

              Ich möchte sogar noch weiter gehen, meines Erachtens ist Wayland der falsche Ansatz. Das Problem ist, dass immer mehr Grafikfunktionen in den Toolkits (GTK, Qt) durchgeführt werden welche an den X-Server nur noch fertige Bitmapgrafiken übertragen und die Grafikfunktionen des X-Servers nicht mehr nutzen. Der Grund dafür ist, dass die Grafikfunktionen des X-Servers nicht mehr ausreichend sind, um heutigen Anforderungen zu genügen.

              Der Ansatz von Wayland ist nun keine Grafikfunktionen mehr zur Verfügung zu stellen sondern nur noch fertige Bitmapgrafiken entgegen zu nehmen und anzuzeigen.

              Ich würde es stattdessen für sinnvoller erachten, das grundlegende Problem zu lösen und dem X-Server wieder brauchbare Grafikfunktionen beibringen, so dass diese von den Toolkits entsprechend genutzt werden können. Die Toolkits müssen natürlich dazu angehalten werden, diese dann auch zu nutzen.

              Damit gäbe es wieder - so wie im ursprünglichen Design von X11 vorgesehen - eine zentrale Instanz welche für das Zeichnen der Grafiken zuständig wäre und das Protokoll wäre entsprechend effizient übers Netzwerk zu übertragen.

              Die Netzwerkfähigkeit vom Toolkit abhängig zu machen, so wie es einige vorgeschlagen haben, halte ich hingegen für keine gute Idee. Damit kann man keine Netzwerktransparenz erreichen, da immer Toolkits dabei sein werden, die diese Funktionalität nicht anbieten. Vom Chaos der unterschiedlichen Implementierungen ganz zu schweigen.

Pro-Linux
Traut euch!
Neue Nachrichten