Abseits von Gehype einerseits und Gebashe auf der anderen Seite finde ich die ganze Wayland-Geschichte reichleich undurchsichtig. Ich würde mich sehr über einen Artikel freuen, der einmal aufzeigt welche Probleme Wayland lösen soll und wo er Vorteile und Nachteile bietet.
X wurde in einer Zeit konzipiert, als es andere Anforderungen gab und hat viele Altlasten, was die Wartung und Erweiterung schwierig macht. Wayland ist sozusagen ein Projekt, um mit dem Problemen die X verursacht, aufzuräumen.
Von theBohemian am Fr, 10. Februar 2012 um 11:03 #
> Aufräumen, neee, > ich würde nichts sagen wenn es alte vorteile weiterhin hätte, und durch > neues desin neue vorteile hinzufügt. Lies http://wayland.freedesktop.org/architecture.html und dann argumentiere technisch, wo Wayland keine Vereinfachung der derzeitigen Architektur und kein Aufräumen ist.
> argumentiere technisch, wo Wayland keine Vereinfachung der derzeitigen Architektur und kein Aufräumen ist.
Das hat der Kollegen auch nicht behauptet. Ich finde er hat recht. Viele der Vorteile von X gehen mit Wayland zunächst mal bis auf unbestimmte Zeit verloren.
Gibts denn auch noch einen anderen Vorteil von X11, den Wayland nicht bieten kann? Wie weiter unten in den Kommentaren zu lesen ist, wird sich jetzt nur an der nicht enthalten Netzwerktransparenz von Wayland hochgezogen. Dann gibts noch den Hinweis von Workoft auf das mögliche X fuer Wayland, was die ganze hitzige Diskussion für mich relativiert.
Letzten Endes läuft das nur auf die begründete Befürchtung hinaus, dass man "native" Wayland-Anwendungen die keine X-Clients mehr sind, dann nicht mehr ohne weiteres wird auf den remote laufenden X-Server holen können. Für mich persönlich wäre das aber gar nicht von Bedeutung.
X11 als Wayland Client war von Anfang an geplannt. Also war die Netzwerktransparenz nie in Gefahr. Sie wird nur optional. Native Wayland Clients wirst Du mit der Lupe suchen müssen. Jede normale Anwendung wird mit Hilfe eines Toolkits erstellt und die werden mit beiden Welten umgehen können.
Ach klausi, lies doch bitte meinen Kommentar bevor du darauf antwortest^^ Ich will nicht für andere sprechen, kann aber selber auf die Netzwerktransparenz ganz gut verzichten.
Mir geht es darum, dass oben von den vielen Vorteilen von X11 die Rede ist, die mit Wayland dann angeblich verloren gingen. Wenn da jetzt nicht noch mehr Argumente kommen, dann halte ich das für FUD.
Ich habe mich Blöd ausgedrückt, okay. Ich wollte nur klarstellen, das X für Wayland nichts optionales oder neues ist, wie "das mögliche X fuer Wayland" vermuten lässt.
X11 als Wayland Client war von Anfang an geplannt. Also war die Netzwerktransparenz nie in Gefahr. Sie wird nur optional.
Ja, dieses Beruhigungsmantra kann man in jeder Diskussion zum Thema vernehmen. Unterschlagen wird dabei immer, daß das natürlich nur mit X-Clients funktioniert. Native Wayland-Applikationen können nicht mehr über's Netzwerk verwendet werden.
Copy & Paste aus dem Beitrag, auf den Du geantwortet hast:
Native Wayland Clients wirst Du mit der Lupe suchen müssen. Jede normale Anwendung wird mit Hilfe eines Toolkits erstellt und die werden mit beiden Welten umgehen können.
Wie kommst Du darauf? Alle Toolkits haben bereits ein X11-Backend, jetzt kommt das Wayland-Backend dazu. Die Anwendung bzw. das Toolkit entscheidet beim Start welches Backend benutzt wird (je nachdem welche Umgebung vorgefunden wird). Es fällt nichts weg, jedenfalls nicht in absehbarer Zeit. Die Idee, die Netzwerkfunktionen in die Toolkits zu verlegen, habe ich bisher nur in Forem gesehen (Ich lasse mich aber gerne mit Referenzen widerlegen). Auf der Wayland-Seite kann ich diese Idee nicht finden - ganz im Gegenteil wird dort von einer möglichen Netzwerk-Funktion im Wayland-Compositor gesprochen, was ja dann wieder X11 ähnlich wäre.
Damit man jetzt zusätzlich zu X auch noch Wayland laufen lassen kann. Wenn eines beim X-Forwarding noch gefehlt hat, dann definitiv noch ne Schicht.
Außerdem laufen Nvidia-Treiber viel zu gut unter Linux. Eine Linux-Only-Lösung, die von Nvidia nicht unterstützt wird, ist hier auch dringend nötig.
Zudem bekommen die ganzen GUI-Toolkit-Schreiber endlich mal wieder was zu tun. Die langweilen sich schon.
Jedenfalls freue ich mich auf die Zukunft, wenn Wayland den Status des heutigen X hat. Dann gibt es einen neuen Window-Server unter dem Wayland als Client läuft, damit X dort als Client laufen kann. Hach, das wird herrlich. Und ich machte mit schon Sorgen, wofür ich die bis dahin gestiegene Rechenleistung benutzen kann.
Von theBohemian am Fr, 10. Februar 2012 um 10:58 #
Nein, der einzige Zweck von Wayland ist postings wie deines zu provozieren ... :huh:
Ich meine, was kümmert es dich, wenn einige Leute was entwickeln, was nicht X11 ist? Hat das irgendwelche Auswirkungen auf dich oder die Systeme, die du betreust? Gehen die etwa alle kaputt an dem Tag wo Wayland 1.0 released wird?
Btw: Es gibt auf DirectFB. Das ist auch nicht kompatibel zu X11 und wird sehr gerne im Embeddedbereich eingesetzt. Derselbe Bereich hofft auch auf Wayland ...
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 10. Feb 2012 um 10:59.
Da haben die KDE3/Gnome2 Anwender sich tierisch darüber gefreut, dass ihr funktionierender Desktop durch KDE4/Gnome3 ersetzt wurde. Gleiches wird auch den X Nutzern ereilen. Es muss nicht besser sein, es muss nur neu sein.
„Ich meine, was kümmert es dich, wenn einige Leute was entwickeln, was nicht X11 ist? Hat das irgendwelche Auswirkungen auf dich oder die Systeme, die du betreust? Gehen die etwa alle kaputt an dem Tag wo Wayland 1.0 released wird?”
Was willst du mir damit sagen? Dass ich zu etwas keine Meinung haben sollte, weil ich es auch prinzipiell ignorieren könnte?
„Btw: Es gibt auf DirectFB. Das ist auch nicht kompatibel zu X11 und wird sehr gerne im Embeddedbereich eingesetzt. Derselbe Bereich hofft auch auf Wayland ...”
Ja und?
Wayland soll X11 ersetzten. Wird es aber faktisch für lange, lange Zeit nicht. D.h. es wird, selbst wenn es sich durchsetzt, erstmal eine Doppel-Lösung sein, die kaum einen Mehrwehrt bringt, stattdessen eine zusätzliche Komplexität.
Da Wayland einige Features von X11 gar nicht supported, wird es wohl auch nie ein vollständiger Ersatz für X11, d.h. in einigen Bereichen wird eine Doppel-Lösung bestehen bleiben.
Dazu kommt eben das Problem, mit der Grafikkarten-Treiber. Was soll ein System, dass von Nvidia nicht unterstützt wird? Auf Desktop-Systemen wird es daher für lange Zeit nicht laufen. Aber wo denn sonst?
Und was ist mit der Zukunft? Der X-Server ist alt, aber auch Wayland wird altern. Wird Waylands Alterung tatsächlich besser skalieren, als das bei X der Fall ist? Wenn sich Wayland nach Jahren, vielleicht sogar Jahrzehnten durchsetzt, wird sich dann durch Wayland die Situation nicht genauso darstellen, wie jetzt durch X?
Also ich persönlich würde mir in diesem elementaren Bereich, einen deutlich ingeneursmäßigeren Ansatz wünschen, statt eben mal was zusammen zu hacken, was im Moment vielleicht gut funktionieren würde.
"Wird es aber faktisch für lange, lange Zeit nicht. D.h. es wird, selbst wenn es sich durchsetzt, erstmal eine Doppel-Lösung sein, die kaum einen Mehrwehrt bringt, stattdessen eine zusätzliche Komplexität."
Das kannst du nicht wissen. Zudem wäre der Wechsel für die meisten wohl nicht mal zu bemerken, 90% der Linuxuser (meine Vermutung aus div. Gesprächen) wissen wohl nicht mal wirklich was der X-Server tut.
"wird sich dann durch Wayland die Situation nicht genauso darstellen, wie jetzt durch X?"
Und? Wo ist der Punkt. Glaubst du den, X ist in 20 Jahren nicht noch schlimmer als heute? Wayland wird altern, aber vorher Vorteile bringen. Wechselt man nicht, werden die Folgeprobleme nur noch größer.
Bitte? Das ist doch absolut absehbar. Auf der Doku zu Wayland wird auch immer klar gestellt, wie wunderbar man X als Client dort laufen lassen kann.
„Zudem wäre der Wechsel für die meisten wohl nicht mal zu bemerken, 90% der Linuxuser (meine Vermutung aus div. Gesprächen) wissen wohl nicht mal wirklich was der X-Server tut.”
So, wie niemand was merkte, als Ubuntu auf Pulseaudio umgestiegen ist, weil niemand wusste, was ein Alsa ist, ja?
„Und? Wo ist der Punkt. Glaubst du den, X ist in 20 Jahren nicht noch schlimmer als heute? Wayland wird altern, aber vorher Vorteile bringen. Wechselt man nicht, werden die Folgeprobleme nur noch größer.”
Das ist der Punkt. Nichts genaues weiß man nicht, weil man nicht voraus plant. Es gibt keine Evaluierung bezüglich der Zukunftssicherheit. Bei anderen Lösungen, wie upstart, hal, devfs, d-bus, mag es ja kein Beinbruch sein, wenn man die vor-sich-hin entwickelt und nach 5 Jahren wieder wegwirft. Weil es eben leicht austauschbare Technologien sind und abgesehen von den Distributoren wenig Menschen von diesem Experimentieren betroffen sind. Für das Grafik-System gilt das aber nicht. Alle Treiber, ob Opensource oder Close-Source, alle GUI-Toolkits, alle Grafik-Settings alle paar Jahre neu anzupassen ist definitiv nicht drin.
Von X kann man vieles sagen, aber es ist gut 10 Jahre älter als Linux. Es läuft seit 30 Jahren auf völlig verschiedenen Systemen und auch auf, aus Sicht von X, völlig neuartigen Systemen. Und ich kann mir nicht vorstellen, dass man das in 30 Jahren auch von Wayland sagen wird.
Es gibt noch andere Möglichkeiten, als ein vollständiger Bruch, um die Probleme mit X anzugehen. Man könnte sich mal hinsetzten und erstmal evaluieren, wie die Anforderungen genau sind und wo man das Protokoll sinnvoll erweitern könnte. Man könnte die Code-Basis aufbessern und entrümpeln. Aber das ist halt deutlich unsexier und anstrengender als so eine Ein-Mann-Show und Linux-Only-Lösung.
Von Schöne Grüße am Fr, 10. Februar 2012 um 15:35 #
Bitte? Das ist doch absolut absehbar. Auf der Doku zu Wayland wird auch immer klar gestellt, wie wunderbar man X als Client dort laufen lassen kann.
Nur nötig, wenn Du alte Xclients oder die Netzwerkfunktionen von X11 benötigst. Steht auch in der Doku.
So, wie niemand was merkte, als Ubuntu auf Pulseaudio umgestiegen ist, weil niemand wusste, was ein Alsa ist, ja?
Neue Techniken brauchen immer eine Anlaufphase. Ubuntu war mit Pulse etwas vorschnell, gut. Aber Du musstest den Umstieg nicht mitmachen. Und inzwischen ist Pulse aber ein echter Mehrwert - also hat es sich gelohnt.
Bei anderen Lösungen, wie upstart, hal, devfs, d-bus, mag es ja kein Beinbruch sein, wenn man die vor-sich-hin entwickelt und nach 5 Jahren wieder wegwirft.
Alle diese Projekte (ausser devfs vielleicht) haben Linux vorran gebraucht. Auch wenn einige (bzw eins, HAL) inzwischen ersetzt wurden, haben sie den Weg geebnet und Problem aufgezeigt, die in den nachfolgenden Projekten gelöst wurden. Übrigen ist dieses Vorgehen ein Grundpfeiler von Open Source - "Release Early, Release Often".
... alle ... alle paar Jahre neu anzupassen ist definitiv nicht drin.
An wievielen Projekten arbeitest Du mit, das Du Dir darüben einen Kopf machst? GTK, QT, SDL, KDE, GNOME ua. arbeiten breits am der Unterstützung für Wayland. Also kanns ja so schlimm nicht sein (oder der Leidensdruck ist inzwischen hoch genug).
Von X kann man vieles sagen, aber es ist gut 10 Jahre älter als Linux. Es läuft seit 30 Jahren auf völlig verschiedenen Systemen und auch auf, aus Sicht von X, völlig neuartigen Systemen.
Es läuft, mehr aber auch nicht. DOS "läuft" auch auf meiner 64bit CPU mit 6Kernen.
Und ich kann mir nicht vorstellen, dass man das in 30 Jahren auch von Wayland sagen wird.
Und woher nimmst Du diese Weißheit? Wayland ist ganz Grob gesagt eine Schnittstelle zu den neuen Kernel-APIs für die Grafikausgabe. Damit wandert die Verwaltung der Grafikhardware endlich dahin, wo sie hingehört - in den Kernel. Auch wenn Wayland einmal ersetzt wird, künfige Projekte werden den "Wayland-Weg" gehen und von Wayland lernen.
Es gibt noch andere Möglichkeiten, als ein vollständiger Bruch, um die Probleme mit X anzugehen.
Lies die FAQ. Natürlich kannst Du einige Probleme von X11 umgehen, das Problem "X11" bekommst Du damit aber nicht gelöst.
Man könnte sich mal hinsetzten und erstmal evaluieren, wie die Anforderungen genau sind und wo man das Protokoll sinnvoll erweitern könnte. Man könnte die Code-Basis aufbessern und entrümpeln.
Das hat man gemacht. Man kann X11 aber nicht "entrümpeln", weil dann ist es nicht mehr X11. Steht übrigens auch in der FAQ.
Das ist der Punkt. Nichts genaues weiß man nicht, weil man nicht voraus plant.
Wayland _ist_ genau das, was Du hier verlangst: die Planung für eine sinnvolle Zukunft des Linux-Grafiksystems. Ich zitiere mal die Wayland-FAQ: "Getting to a point where the X server is a compatibility option instead of the core rendering system will take a while, but we'll never get there if don't plan for it."
Bei anderen Lösungen, wie upstart, hal, devfs, d-bus, mag es ja kein Beinbruch sein, wenn man die vor-sich-hin entwickelt und nach 5 Jahren wieder wegwirft. Weil es eben leicht austauschbare Technologien sind und abgesehen von den Distributoren wenig Menschen von diesem Experimentieren betroffen sind. Für das Grafik-System gilt das aber nicht. Alle Treiber, ob Opensource oder Close-Source, alle GUI-Toolkits, alle Grafik-Settings alle paar Jahre neu anzupassen ist definitiv nicht drin.
Von X kann man vieles sagen, aber es ist gut 10 Jahre älter als Linux. Es läuft seit 30 Jahren auf völlig verschiedenen Systemen und auch auf, aus Sicht von X, völlig neuartigen Systemen. Und ich kann mir nicht vorstellen, dass man das in 30 Jahren auch von Wayland sagen wird.
Wieder einmal beweist Du, dass Du keine Ahnung hast, wovon Du sprichst. D-Bus ist ein IPC-System, der Inbegriff einer nicht leicht austauschbaren Komponente, weil es eben mit sehr vielen anderen Programmen interagiert. Und wie wäre es, wenn Du auch nur mal ein einziges Argument dafür nennen würdest, wieso Du das Wayland-Protokoll nicht für zukunftsfähig hältst? Fakt ist jedenfalls, dass es äußerst erweiterbar ist. Genauer gesagt: Bei Wayland ist *alles* eine Protokollerweiterung, bis auf die Funktionalität, die man benötigt, um die bekannten Protokollerweiterungen abzufragen (Quelle). Es ist äußerst unwahrscheinlich, dass so ein Protokoll überhaupt veralten kann.
Es gibt noch andere Möglichkeiten, als ein vollständiger Bruch, um die Probleme mit X anzugehen. Man könnte sich mal hinsetzten und erstmal evaluieren, wie die Anforderungen genau sind und wo man das Protokoll sinnvoll erweitern könnte. Man könnte die Code-Basis aufbessern und entrümpeln. Aber das ist halt deutlich unsexier und anstrengender als so eine Ein-Mann-Show und Linux-Only-Lösung.
Wayland ist keine Linux-Only-Lösung sondern ein Protokoll, das prinzipiell auf allen Plattformen implementiert werden kann. Auf Linux beschränkt ist lediglich Weston, die Demo-Implementierung dieses Protokolls, die Linux-Technologien wie KMS voraussetzt. Es spricht aber nichts gegen Implementierungen auf Basis anderer Betriebssysteme, wenn diese die nötige Funktionalität bereitstellen. Und wenn sie das nicht tun -- nun ja, dann haben sie eben Pech gehabt. Es wäre dumm, die Möglichkeiten, die der moderne Linux-Grafikstack bietet, zu ignorieren, nur weil die Anbieter anderer Systeme ihren Grafikstack nicht auf die Reihe bekommen. Insbesondere, wenn man berücksichtigt, dass Solaris, FreeBSD & Co. auf dem Desktop praktisch gar nicht verwendet werden.
Wayland ist keine Linux-Only-Lösung sondern ein Protokoll, das prinzipiell auf allen Plattformen implementiert werden kann. Auf Linux beschränkt ist lediglich Weston, die Demo-Implementierung dieses Protokolls, die Linux-Technologien wie KMS voraussetzt. Es spricht aber nichts gegen Implementierungen auf Basis anderer Betriebssysteme, wenn diese die nötige Funktionalität bereitstellen. Und wenn sie das nicht tun -- nun ja, dann haben sie eben Pech gehabt. Es wäre dumm, die Möglichkeiten, die der moderne Linux-Grafikstack bietet, zu ignorieren, nur weil die Anbieter anderer Systeme ihren Grafikstack nicht auf die Reihe bekommen. Insbesondere, wenn man berücksichtigt, dass Solaris, FreeBSD & Co. auf dem Desktop praktisch gar nicht verwendet werden.
Lies doch mal die FAQ und die Aussagen des Entwickler. Wayland setzt auf einen Linux DRM Stack auf, benutzt Linux Technik für Energie und Geräteerkennung und setzt sonst nur Annahmen, die ausschließend auf Linuxsystemen zu finden sind. Selbst wenn man portieren würde, ständig nachziehen will das keiner. Der Linuxstack ändert sich ständig da mitzuhalten mit den entsprechenden Resourcen (Wissen, Zeit) halten nur Söldner aus.
Lies doch mal die FAQ und die Aussagen des Entwickler. Wayland setzt auf einen Linux DRM Stack auf, benutzt Linux Technik für Energie und Geräteerkennung und setzt sonst nur Annahmen, die ausschließend auf Linuxsystemen zu finden sind.
Selbst wenn man portieren würde, ständig nachziehen will das keiner. Der Linuxstack ändert sich ständig da mitzuhalten mit den entsprechenden Resourcen (Wissen, Zeit) halten nur Söldner aus.
Wenn die Entwickler anderer Systeme den Linux-Grafikstack mit KMS, DRM etc. nicht wollen, können sie ihren eigenen implementieren, und dann Wayland auf dieser Grundlage umsetzen. Und wenn sie das auch nicht können, dann ist das eben schlicht und einfach ihr Problem. Es ist nicht die Aufgabe der Entwickler des Linux-Grafikstacks, sich auch noch um den Grafikstack anderer Systeme zu kümmern, die auf dem Desktop ohnehin keine Rolle spielen.
Wayland soll X11 ersetzten. Wird es aber faktisch für lange, lange Zeit nicht.
Wayland soll nur einen Teil von X11 ersetzen, genauer gesagt IPC, Compositing und Input. Das heißt aber nicht, dass X nicht trotzdem sterben wird. Über die Jahre hat man systematisch Teile von X11 ersetzt. 3D-Grafik wird heute am X-Server vorbei per DRI erledigt, Mode setting findet im Kernel statt, Videowiedergabe läuft per VA-API oder VDPAU, Eingabegeräte werden im Kernel per evdev bedient. Gerendert wird auch nicht mehr im X-Server, sondern mit Bibliotheken (Cairo, AGG, Qt, Freetype, Pango und weitere).
D.h. es wird, selbst wenn es sich durchsetzt, erstmal eine Doppel-Lösung sein, die kaum einen Mehrwehrt bringt, stattdessen eine zusätzliche Komplexität.
Es bringt sehr wohl einen Mehrwert, z. B. ermöglicht Wayland endlich Input Redirection, was unter X11 bis heute nicht geht. Wozu man das braucht? Probier mal, mit einem X-Compositor ein Fenster auf die doppelte Größe zu skalieren und dann Input-Events noch korrekt zu verarbeiten -- das geht heute schlicht nicht. Und wenn native Wayland-Clients verwendet werden, funktioniert der ganze Stack einfacher und effizienter. Nicht einmal Deine Behauptung von erhöhter Komplexität im Falle von Legacy-X-Applikationen stimmt. Es läuft im Prinzip genauso wie heute: der X-Client kommuniziert mit dem X-Server, der X-Server mit dem Compositor. Der einzige Unterschied ist, dass der Compositor kein X-Client ist, sondern per Wayland mit dem X-Server kommuniziert.
Da Wayland einige Features von X11 gar nicht supported, wird es wohl auch nie ein vollständiger Ersatz für X11, d.h. in einigen Bereichen wird eine Doppel-Lösung bestehen bleiben.
Mal Butter bei die Fische: Welche Features von X11 sind mit Wayland nicht machbar? Netzwerktransparenz? Klar, das X-Protokoll ist prima für solche Desktops: Keine Farbverläufe, keine Grafiken, Fonts ohne Antialiasing. Für einen modernen Desktop ist es gnadenlos ineffizient, und das weiß auch jeder, der es mal übers Internet genutzt hat. Außerdem ist es problemlos möglich, ein Remote-Rendering-Protokoll über Wayland zu legen. Und das könnte man dann so auslegen, dass es die Features unterstützt, die heutzutage sinnvoll sind, und nicht die, die vor 20 Jahren sinnvoll waren. Und selbst wenn es dazu nicht kommt, ist eine "Pixel-scraping"-Lösung a la VNC X immer noch überlegen, da VNC wenigstens Kompression unterstützt - nicht einmal das tut X11.
Dazu kommt eben das Problem, mit der Grafikkarten-Treiber. Was soll ein System, dass von Nvidia nicht unterstützt wird? Auf Desktop-Systemen wird es daher für lange Zeit nicht laufen. Aber wo denn sonst?
Früher oder später wird Nvidia seine Politik ändern müssen, wenn sie unter Linux nicht den Anschluss verlieren wollen. Ich bin optimistisch, dass es in den nächsten Jahren eine Entwicklung in dieser Richtung geben wird.
Und was ist mit der Zukunft? Der X-Server ist alt, aber auch Wayland wird altern. Wird Waylands Alterung tatsächlich besser skalieren, als das bei X der Fall ist? Wenn sich Wayland nach Jahren, vielleicht sogar Jahrzehnten durchsetzt, wird sich dann durch Wayland die Situation nicht genauso darstellen, wie jetzt durch X?
Die Argumentation ist behämmert. Es ist kaum möglich, die Zukunft vorherzusagen, aber das kann doch kein Argument dafür sein, eine Technologie beizubehalten, die heute schon veraltet ist. Obwohl, wieso heute? Man lese diesen Kommentar von Mike Paquette, einem der Entwickler von Apples Quartz-Technologie. X11 war 2003 schon völlig veraltet.
Also ich persönlich würde mir in diesem elementaren Bereich, einen deutlich ingeneursmäßigeren Ansatz wünschen, statt eben mal was zusammen zu hacken, was im Moment vielleicht gut funktionieren würde.
Kannst Du dieses Gewäsch auch nur _irgendwie_ begründen? Was ist an Wayland nicht "ingeneursmäßig" (sic)? Mir scheint, Du hast einfach keine Ahnung, worüber Du hier redest.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 12. Feb 2012 um 22:29.
Wenn du weiterhin X brauchst, nutz es. Keiner hält dich ab. Wenn du auch noch in 50 Jahren X nutzen willst, nutz es. Auch dann wird dich keiner abhalten, genauso wenig wie wir dich von Pferdekutschen und Kornkühlen abhalten.
Aber wegen dir bleibt die Welt trotzdem nicht stehen. Nur du bleibst stehen.
"Eine Linux-Only-Lösung, die von Nvidia nicht unterstützt wird, ist hier auch dringend nötig."
Nouveau wird niemals so gut werden können wie der unfreie NVidiatreiber. Vergiss es. Nouveau funktioniert mit etwa 50% aller existierenden Nvidiagrafikkarten leider nur auf 2D-Niveau ohne jede Hardwarebeschleunigung. Deshalb kommt nun auch das Allheilmittel der Gnome3-Shell-Red Hat-Fraktion: Quadcore-CPU und "Shadowfb", Pseudo-3D für Outcasts.
Stimmt. Das mit dem shadowfb war der Gegenvorschlag auf die Frage, wie man denn in Zukunft einen alten oder "kaputten" Treiber ohne jede 2D-Hardwarebeschleunigung nutzen soll.
Von theBohemian am Fr, 10. Februar 2012 um 17:01 #
> Nouveau wird niemals so gut werden können wie der unfreie > NVidiatreiber. > Vergiss es. Ist auch egal, ob er 100% so schnell ist, wie der proprietäre Treiber. Wichtig ist, dass er mit der HW läuft die existiert und die Dinge für die er benötigt wird (Wayland, Desktop Environment) vernünftigt beherrscht.
Außerdem besitzt du keine Glaskugel und kannst in die Zukunft sehen. Ich kann dir aber sagen, dass es einen gewissen freien Kernel gibt, der sämtliche existierenden proprietären Betriebssysteme in punkto Leistung, Flexibilität, Kosten usw. in den Schatten stellt. Welcher war das nur ... ?
Als Nicht-Entwickler kann man das leider sehr schlecht beurteilen. Die zahlreichen Informationen, die man im Netz findet, geben die Sachverhalte zwar korrekt wieder. Aber nur wer wirklich Erfahrung in der Software-Entwicklung mit X hat, kann gut beurteilen, was jetzt der Mehrwert von Wayland sein soll.
Stelle dir vor, du schreibst ein Java-Programm, das ein Pixel auf den Bildschirm zeichnet. Du kannst dir sicherlich vorstellen, dass dieses Pixel einen weiten Weg hat, bis es auf dem Bildschirm erscheint. Das Pixel muss durch das Betriebssystem, durch die Desktop- und Fenster-Routinen, durch den Grafikkartentreiber und schließlich irgendwann landet es im RAM der Grafikkarte und auf dem Bildschirm. Das ist ein ziemlich weiter weg. Dass dieser Weg weit ist, sieht man z.B. beim Scrollen. Es ist nie so flüssig wie z.B. die Bewegung in einem Computerspiel. Wayland ist jetzt eine Architektur, die diesen Weg deutlich verkürzt. Beispielsweise die Umrechnung von Pixeln in einem Fenster auf Bildschirmpixel macht der X-Server oft selber. Aber eigentlich ist das nichts anderes als eine 3D-Routine, die moderne Grafikkarten auch alleine machen können. Das heißt, hier gibt es eine Abkürzung.
Die Schwierigkeit für den Laien ist jetzt, dass er eigentlich kaum beurteilen kann, welche Schritte auf diesem Weg von einem Pixel wirklich notwendig sind. Es ist ja nicht so, dass X sinnlose Berechnungen durchführt. Was X macht, ist schon alles sehr sinnvoll und bewährt. Daher auch die Skepsis gegenüber Wayland. Aber welches Detail in welchem Kontext wie am besten gelöst werden, ist eine außerst komplizierte Frage.
"Was X macht, ist schon alles sehr sinnvoll und bewährt."
Das X-Protokoll ist ziemlich bescheuert für heutige Anforderungen. Das ist nicht sinnvoll, und bewährt nur wen man bewährt = "man leidet darunter, aber kennt es" bedeutet.
Da stimme ich dir voll zu. Ich meinte es eher so: Es gibt viele Situationen, in denen das X-Protokoll "sinnvoll und bewährt" ist. Daher will ich mal nicht so sehr meckern. Aber mein Rechner fällt nicht darunter. Bei meiner täglichen Arbeit X zu benutzen, ist, wie du sagst "bescheuert" und "man leidet darunter". Daher freue ich mich schon darauf, wenn ich diese Altlasten endlich los bin.
Viele Leute fragen dann halt ganz natürlich, ob ihre unfreien Nvidia- und ATI-Treiber noch funktionieren werden. Es ist doch ganz normal, dass niemand von denen eine Distro mit Wayland benutzen würde, wenn das nicht sofort funktionieren sollte. Das interessiert die Nutzer, nicht wie das X- oder Nicht-X-"Ding" heißt oder was es auf technischer Ebene macht.
Ich sage einfach mal ja das werden sie. Nur was sollen Nvidia und AMD jetzt tun? Ein System unterstützen das noch nicht fertig ist? Sobald es die erste "fertige" Version gibt werden die sich sich das mal anschauen und entsprechenden Support implementieren.
Viele Leute fragen dann halt ganz natürlich, ob ihre unfreien Nvidia- und ATI-Treiber noch funktionieren werden. Es ist doch ganz normal, dass niemand von denen eine Distro mit Wayland benutzen würde, wenn das nicht sofort funktionieren sollte.
Das ist vollkommen irrelevant. Die Toolkits haben Backends für die verschiedenen Ausgaben. Auf den Rechner, auf denen Wayland läuft, wird Wayland gestartet und das Wayland-Backend benutzt. Wo es noch nicht funktioniert, da kommt halt X11 und das X11-Backend zum Einsatz. Aber irgendwann werden sich die Leute fragen, warum Ihr 300€ PC mit Intel-OnBoard Grafik besser läuft, als die High-End-Workstation mit 300€ Grafikkarte von NVidia. Spätestens dann werden auch NVidia und ATI von Ihrem hohen Ross steigen müssen und Treiber oder Specs liefern.
Von Anon Y. Mouse am So, 12. Februar 2012 um 12:44 #
vielleicht interessiert sich nvidia ja garnicht für linux? vielleich sind die linux treiber ja nur ein abfallprodukt der AIX (und konsorten) treiber, weil man diese für cathia zb braucht?
vielleicht interessiert sich nvidia ja garnicht für linux? vielleich sind die linux treiber ja nur ein abfallprodukt der AIX (und konsorten) treiber, weil man diese für cathia zb braucht?
Nvidia stellt keine Treiber für AIX bereit, und der CATIA V6-Client läuft nur noch unter Windows. Wahrscheinlich wollte man sich nicht mehr mit dem X-Mist herumärgern.
Bisher war der Treiber so generisch, dass Solaris, FreeBSD und Linux zugleich unterstützt werden konnten, immerhin. Intel, AMD ist sich dafür ja zu schade.
Bisher war der Treiber so generisch, dass Solaris, FreeBSD und Linux zugleich unterstützt werden konnten, immerhin. Intel, AMD ist sich dafür ja zu schade.
Ganz ehrlich: wen interessiert's? Schon Linux ist auf dem Desktop eine Randerscheinung, warum also Zeit mit noch exotischeren Systemen verschwenden? Die Zeit ist besser investiert, indem man etwas baut, das zumindest unter Linux vernünftig funktioniert.
Deren Verfügbarkeit über Systemgrenzen hinweg samt ihre Cuda Technologie ist ein Grund warum man in der Forschung ausschließlich auf deren Karten setzt. Für 3D Tetris und die x-te Quake Engine brauchst du solche Highend Karten sicher nicht.
Deren Verfügbarkeit über Systemgrenzen hinweg samt ihre Cuda Technologie ist ein Grund warum man in der Forschung ausschließlich auf deren Karten setzt.
Wo hast Du denn das her? OpenCL ist praktisch das gleiche wie CUDA und läuft auf allen Karten. Ich bin übrigens zufällig an einer Universität, wo sowohl AMD- als auch Nvidia-Grafikprozessoren eingesetzt werden, eben mit OpenCL.
Die Gefahr sehe ich auch nicht so sehr. Wenn man sich die OpenSource-Welt mal anschaut, so war es oft so, dass funktionierende Software auch weiter funktioniert. KDE 3 (Trinity) funktioniert noch wunderbar, obwohl schon lange KDE4 verfügbar ist. Gnome 2 kann noch verwendet werden. Der Kernel 2.2 wurde ewig gepflegt. OpenGL funktioniert auch ohne DRI noch wunderbar. OpenGL funktioniert sogar remote halbwegs gut, obwohl das wirklich kaum jemand benötigt. Sogar solche verrückten Dinge wie Videos über die Ascii-Art-Schnittstelle ausgeben im mplayer funktionieren seit Jahren unverändert. DLL-Probleme oder Compiler-Inkompatibilitäten gibt es auch kaum.
Insgesamt kann man sich eigentlich nicht beklagen, dass Dinge von heute auf morgen nicht mehr funktionieren. Ich denke, da können wir zuversichtlich sein, dass jede x-beliebige Linux-Distribution bei Bedarf auch zukünftig noch X mitliefern wird und sämtliche Anwendungen ordentlich damit laufen werden. Man hat die freie Wahl, ob man Wayland möchte oder X. Ich finde das wirklich schön.
Von theBohemian am Fr, 10. Februar 2012 um 11:11 #
Zwei Beispiele: Die X11-Architektur sieht vor, dass die X11-Programme Zeichenanweisungen an den X11-Server senden und jener diese ausführt. Moderne Toolkits zeichnen aber zum großen Teil selbst und senden bloß noch Bitmaps zum Server. Das ist ein Bruch mit der Architektur und zeigt, dass sie nicht mehr zeitgemäß ist.
DRI/DRM erlaubt einen gemeinsamen Speicherbereich zwischen Server und Client zu haben, damit der Client 3D-Operationen machen kann. Das ist nicht mit X11-Forwarding kompatibel und wiederum ein Bruch mit der ursprünglichen Architektur.
Und zur Thematik: "Aber mein geliebtes X11-Forwarding!!einsölf1" Das wird einfach anders implementiert, als es beim X11 war und könnte, wenn man will, genauso funktionieren. Einziger Unterschied ist, dass es nicht im Kern des Display-Servers steckt.
Aber was hat das jetzt mit dem Thema zu tun? Du kannst glxgear flüssig über ein Gigabit-Netzwerk laufen lassen ... TOLLLLL!!! Oder ein 15 Jahre altes Spiel, SUUUUUPER!!! Wie oft hast Du das in den letzen 15 Jahren benötigt?
Glxgears ist kein Benchmark, also was soll der Quatsch? Und bei Quake III stellt sich die Frage, ob es per VNC o. ä. nicht genauso gut bzw. schlecht laufen würde.
Abseits von Gehype einerseits und Gebashe auf der anderen Seite finde ich die ganze Wayland-Geschichte reichleich undurchsichtig. Ich würde mich sehr über einen Artikel freuen, der einmal aufzeigt welche Probleme Wayland lösen soll und wo er Vorteile und Nachteile bietet.
Kurz und knapp: alter, kompromissbehafteter, Multiplattform Architektur -> Linux Only Architektur
Vielleicht liest du mal den Link aus dem Artikel:
http://wayland.freedesktop.org/architecture.html
X wurde in einer Zeit konzipiert, als es andere Anforderungen gab und hat viele Altlasten, was die Wartung und Erweiterung schwierig macht. Wayland ist sozusagen ein Projekt, um mit dem Problemen die X verursacht, aufzuräumen.
Aufräumen, neee,
ich würde nichts sagen wenn es alte vorteile weiterhin hätte, und durch neues desin neue vorteile hinzufügt.
> Aufräumen, neee,
> ich würde nichts sagen wenn es alte vorteile weiterhin hätte, und durch > neues desin neue vorteile hinzufügt.
Lies http://wayland.freedesktop.org/architecture.html und dann argumentiere technisch, wo Wayland keine Vereinfachung der derzeitigen Architektur und kein Aufräumen ist.
> argumentiere technisch, wo Wayland keine Vereinfachung der derzeitigen Architektur und kein Aufräumen ist.
Das hat der Kollegen auch nicht behauptet. Ich finde er hat recht. Viele der Vorteile von X gehen mit Wayland zunächst mal bis auf unbestimmte Zeit verloren.
Nenne doch mal einen.
Netzwerktransparenz
*scnr*
PS: Ich bin mir bewusst das die Netzwerktransparenz vom X Server heutzutage nicht wirklich brauchbar ist.
Also ich benutze ssh -X noch immer ganz gerne, lieber als VNC: Geht einfach, unkompliziert und ist absolut brauchbar.
Gibts denn auch noch einen anderen Vorteil von X11, den Wayland nicht bieten kann? Wie weiter unten in den Kommentaren zu lesen ist, wird sich jetzt nur an der nicht enthalten Netzwerktransparenz von Wayland hochgezogen. Dann gibts noch den Hinweis von Workoft auf das mögliche X fuer Wayland, was die ganze hitzige Diskussion für mich relativiert.
Letzten Endes läuft das nur auf die begründete Befürchtung hinaus, dass man "native" Wayland-Anwendungen die keine X-Clients mehr sind, dann nicht mehr ohne weiteres wird auf den remote laufenden X-Server holen können. Für mich persönlich wäre das aber gar nicht von Bedeutung.
X11 als Wayland Client war von Anfang an geplannt. Also war die Netzwerktransparenz nie in Gefahr. Sie wird nur optional.
Native Wayland Clients wirst Du mit der Lupe suchen müssen. Jede normale Anwendung wird mit Hilfe eines Toolkits erstellt und die werden mit beiden Welten umgehen können.
Ach klausi, lies doch bitte meinen Kommentar bevor du darauf antwortest^^ Ich will nicht für andere sprechen, kann aber selber auf die Netzwerktransparenz ganz gut verzichten.
Mir geht es darum, dass oben von den vielen Vorteilen von X11 die Rede ist, die mit Wayland dann angeblich verloren gingen. Wenn da jetzt nicht noch mehr Argumente kommen, dann halte ich das für FUD.
Ich habe mich Blöd ausgedrückt, okay. Ich wollte nur klarstellen, das X für Wayland nichts optionales oder neues ist, wie "das mögliche X fuer Wayland" vermuten lässt.
Copy & Paste aus dem Beitrag, auf den Du geantwortet hast:
Das hatten wir doch schonmal. Konkret bedeutet das:
1. jedes Toolkit koch in Zukunft sein eigenes Süppchen.
2. Für jedes Toolkit muß auf der Kiste, auf welcher letztlich die Ausgabe stattfindet, ein eigener kleiner Server laufen.
3. Jedes Toolkit muß in Zukunft zwei Backends pflegen.
Wie kommst Du darauf? Alle Toolkits haben bereits ein X11-Backend, jetzt kommt das Wayland-Backend dazu. Die Anwendung bzw. das Toolkit entscheidet beim Start welches Backend benutzt wird (je nachdem welche Umgebung vorgefunden wird). Es fällt nichts weg, jedenfalls nicht in absehbarer Zeit.
Die Idee, die Netzwerkfunktionen in die Toolkits zu verlegen, habe ich bisher nur in Forem gesehen (Ich lasse mich aber gerne mit Referenzen widerlegen). Auf der Wayland-Seite kann ich diese Idee nicht finden - ganz im Gegenteil wird dort von einer möglichen Netzwerk-Funktion im Wayland-Compositor gesprochen, was ja dann wieder X11 ähnlich wäre.
Damit man jetzt zusätzlich zu X auch noch Wayland laufen lassen kann. Wenn eines beim X-Forwarding noch gefehlt hat, dann definitiv noch ne Schicht.
Außerdem laufen Nvidia-Treiber viel zu gut unter Linux. Eine Linux-Only-Lösung, die von Nvidia nicht unterstützt wird, ist hier auch dringend nötig.
Zudem bekommen die ganzen GUI-Toolkit-Schreiber endlich mal wieder was zu tun. Die langweilen sich schon.
Jedenfalls freue ich mich auf die Zukunft, wenn Wayland den Status des heutigen X hat. Dann gibt es einen neuen Window-Server unter dem Wayland als Client läuft, damit X dort als Client laufen kann. Hach, das wird herrlich. Und ich machte mit schon Sorgen, wofür ich die bis dahin gestiegene Rechenleistung benutzen kann.
Nein, der einzige Zweck von Wayland ist postings wie deines zu provozieren ...
:huh: 
Ich meine, was kümmert es dich, wenn einige Leute was entwickeln, was nicht X11 ist? Hat das irgendwelche Auswirkungen auf dich oder die Systeme, die du betreust? Gehen die etwa alle kaputt an dem Tag wo Wayland 1.0 released wird?
Btw: Es gibt auf DirectFB. Das ist auch nicht kompatibel zu X11 und wird sehr gerne im Embeddedbereich eingesetzt. Derselbe Bereich hofft auch auf Wayland ...
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 10. Feb 2012 um 10:59.Da haben die KDE3/Gnome2 Anwender sich tierisch darüber gefreut, dass ihr funktionierender Desktop durch KDE4/Gnome3 ersetzt wurde.
Gleiches wird auch den X Nutzern ereilen.
Es muss nicht besser sein, es muss nur neu sein.
Genau, ganz schlimm. Die Entwickler stellen irgendwo Sourcecode auf eine Website und schon ändert sich was bei mir auf Platte installiert ist....
Weiß nicht in welchem Paralleluniversum obiges geht, aber bei meinem System ist immer noch die gleichen DE-Version drauf, wie beim Release der Distro.
„Ich meine, was kümmert es dich, wenn einige Leute was entwickeln, was nicht X11 ist? Hat das irgendwelche Auswirkungen auf dich oder die Systeme, die du betreust? Gehen die etwa alle kaputt an dem Tag wo Wayland 1.0 released wird?”
Was willst du mir damit sagen? Dass ich zu etwas keine Meinung haben sollte, weil ich es auch prinzipiell ignorieren könnte?
„Btw: Es gibt auf DirectFB. Das ist auch nicht kompatibel zu X11 und wird sehr gerne im Embeddedbereich eingesetzt. Derselbe Bereich hofft auch auf Wayland ...”
Ja und?
Wayland soll X11 ersetzten. Wird es aber faktisch für lange, lange Zeit nicht. D.h. es wird, selbst wenn es sich durchsetzt, erstmal eine Doppel-Lösung sein, die kaum einen Mehrwehrt bringt, stattdessen eine zusätzliche Komplexität.
Da Wayland einige Features von X11 gar nicht supported, wird es wohl auch nie ein vollständiger Ersatz für X11, d.h. in einigen Bereichen wird eine Doppel-Lösung bestehen bleiben.
Dazu kommt eben das Problem, mit der Grafikkarten-Treiber. Was soll ein System, dass von Nvidia nicht unterstützt wird? Auf Desktop-Systemen wird es daher für lange Zeit nicht laufen. Aber wo denn sonst?
Und was ist mit der Zukunft? Der X-Server ist alt, aber auch Wayland wird altern. Wird Waylands Alterung tatsächlich besser skalieren, als das bei X der Fall ist? Wenn sich Wayland nach Jahren, vielleicht sogar Jahrzehnten durchsetzt, wird sich dann durch Wayland die Situation nicht genauso darstellen, wie jetzt durch X?
Also ich persönlich würde mir in diesem elementaren Bereich, einen deutlich ingeneursmäßigeren Ansatz wünschen, statt eben mal was zusammen zu hacken, was im Moment vielleicht gut funktionieren würde.
"Wird es aber faktisch für lange, lange Zeit nicht. D.h. es wird, selbst wenn es sich durchsetzt, erstmal eine Doppel-Lösung sein, die kaum einen Mehrwehrt bringt, stattdessen eine zusätzliche Komplexität."
Das kannst du nicht wissen.
Zudem wäre der Wechsel für die meisten wohl nicht mal zu bemerken, 90% der Linuxuser (meine Vermutung aus div. Gesprächen) wissen wohl nicht mal wirklich was der X-Server tut.
"wird sich dann durch Wayland die Situation nicht genauso darstellen, wie jetzt durch X?"
Und? Wo ist der Punkt. Glaubst du den, X ist in 20 Jahren nicht noch schlimmer als heute? Wayland wird altern, aber vorher Vorteile bringen. Wechselt man nicht, werden die Folgeprobleme nur noch größer.
„Das kannst du nicht wissen.”
Bitte? Das ist doch absolut absehbar. Auf der Doku zu Wayland wird auch immer klar gestellt, wie wunderbar man X als Client dort laufen lassen kann.
„Zudem wäre der Wechsel für die meisten wohl nicht mal zu bemerken, 90% der Linuxuser (meine Vermutung aus div. Gesprächen) wissen wohl nicht mal wirklich was der X-Server tut.”
So, wie niemand was merkte, als Ubuntu auf Pulseaudio umgestiegen ist, weil niemand wusste, was ein Alsa ist, ja?
„Und? Wo ist der Punkt. Glaubst du den, X ist in 20 Jahren nicht noch schlimmer als heute? Wayland wird altern, aber vorher Vorteile bringen. Wechselt man nicht, werden die Folgeprobleme nur noch größer.”
Das ist der Punkt. Nichts genaues weiß man nicht, weil man nicht voraus plant. Es gibt keine Evaluierung bezüglich der Zukunftssicherheit. Bei anderen Lösungen, wie upstart, hal, devfs, d-bus, mag es ja kein Beinbruch sein, wenn man die vor-sich-hin entwickelt und nach 5 Jahren wieder wegwirft. Weil es eben leicht austauschbare Technologien sind und abgesehen von den Distributoren wenig Menschen von diesem Experimentieren betroffen sind. Für das Grafik-System gilt das aber nicht. Alle Treiber, ob Opensource oder Close-Source, alle GUI-Toolkits, alle Grafik-Settings alle paar Jahre neu anzupassen ist definitiv nicht drin.
Von X kann man vieles sagen, aber es ist gut 10 Jahre älter als Linux. Es läuft seit 30 Jahren auf völlig verschiedenen Systemen und auch auf, aus Sicht von X, völlig neuartigen Systemen. Und ich kann mir nicht vorstellen, dass man das in 30 Jahren auch von Wayland sagen wird.
Es gibt noch andere Möglichkeiten, als ein vollständiger Bruch, um die Probleme mit X anzugehen. Man könnte sich mal hinsetzten und erstmal evaluieren, wie die Anforderungen genau sind und wo man das Protokoll sinnvoll erweitern könnte. Man könnte die Code-Basis aufbessern und entrümpeln. Aber das ist halt deutlich unsexier und anstrengender als so eine Ein-Mann-Show und Linux-Only-Lösung.
Nur nötig, wenn Du alte Xclients oder die Netzwerkfunktionen von X11 benötigst. Steht auch in der Doku.
Neue Techniken brauchen immer eine Anlaufphase. Ubuntu war mit Pulse etwas vorschnell, gut. Aber Du musstest den Umstieg nicht mitmachen. Und inzwischen ist Pulse aber ein echter Mehrwert - also hat es sich gelohnt.
Alle diese Projekte (ausser devfs vielleicht) haben Linux vorran gebraucht. Auch wenn einige (bzw eins, HAL) inzwischen ersetzt wurden, haben sie den Weg geebnet und Problem aufgezeigt, die in den nachfolgenden Projekten gelöst wurden. Übrigen ist dieses Vorgehen ein Grundpfeiler von Open Source - "Release Early, Release Often".
An wievielen Projekten arbeitest Du mit, das Du Dir darüben einen Kopf machst? GTK, QT, SDL, KDE, GNOME ua. arbeiten breits am der Unterstützung für Wayland. Also kanns ja so schlimm nicht sein (oder der Leidensdruck ist inzwischen hoch genug).
Es läuft, mehr aber auch nicht. DOS "läuft" auch auf meiner 64bit CPU mit 6Kernen.
Und woher nimmst Du diese Weißheit? Wayland ist ganz Grob gesagt eine Schnittstelle zu den neuen Kernel-APIs für die Grafikausgabe. Damit wandert die Verwaltung der Grafikhardware endlich dahin, wo sie hingehört - in den Kernel. Auch wenn Wayland einmal ersetzt wird, künfige Projekte werden den "Wayland-Weg" gehen und von Wayland lernen.
Lies die FAQ. Natürlich kannst Du einige Probleme von X11 umgehen, das Problem "X11" bekommst Du damit aber nicht gelöst.
Das hat man gemacht. Man kann X11 aber nicht "entrümpeln", weil dann ist es nicht mehr X11. Steht übrigens auch in der FAQ.
Schöne Grüße
Und wie wäre es, wenn Du auch nur mal ein einziges Argument dafür nennen würdest, wieso Du das Wayland-Protokoll nicht für zukunftsfähig hältst? Fakt ist jedenfalls, dass es äußerst erweiterbar ist. Genauer gesagt: Bei Wayland ist *alles* eine Protokollerweiterung, bis auf die Funktionalität, die man benötigt, um die bekannten Protokollerweiterungen abzufragen (Quelle). Es ist äußerst unwahrscheinlich, dass so ein Protokoll überhaupt veralten kann.Wayland ist keine Linux-Only-Lösung sondern ein Protokoll, das prinzipiell auf allen Plattformen implementiert werden kann. Auf Linux beschränkt ist lediglich Weston, die Demo-Implementierung dieses Protokolls, die Linux-Technologien wie KMS voraussetzt. Es spricht aber nichts gegen Implementierungen auf Basis anderer Betriebssysteme, wenn diese die nötige Funktionalität bereitstellen. Und wenn sie das nicht tun -- nun ja, dann haben sie eben Pech gehabt. Es wäre dumm, die Möglichkeiten, die der moderne Linux-Grafikstack bietet, zu ignorieren, nur weil die Anbieter anderer Systeme ihren Grafikstack nicht auf die Reihe bekommen. Insbesondere, wenn man berücksichtigt, dass Solaris, FreeBSD & Co. auf dem Desktop praktisch gar nicht verwendet werden.
Lies doch mal die FAQ und die Aussagen des Entwickler. Wayland setzt auf einen Linux DRM Stack auf, benutzt Linux Technik für Energie und Geräteerkennung und setzt sonst nur Annahmen, die ausschließend auf Linuxsystemen zu finden sind. Selbst wenn man portieren würde, ständig nachziehen will das keiner. Der Linuxstack ändert sich ständig da mitzuhalten mit den entsprechenden Resourcen (Wissen, Zeit) halten nur Söldner aus.
Nicht einmal Deine Behauptung von erhöhter Komplexität im Falle von Legacy-X-Applikationen stimmt. Es läuft im Prinzip genauso wie heute: der X-Client kommuniziert mit dem X-Server, der X-Server mit dem Compositor. Der einzige Unterschied ist, dass der Compositor kein X-Client ist, sondern per Wayland mit dem X-Server kommuniziert.Mal Butter bei die Fische: Welche Features von X11 sind mit Wayland nicht machbar? Netzwerktransparenz? Klar, das X-Protokoll ist prima für solche Desktops: Keine Farbverläufe, keine Grafiken, Fonts ohne Antialiasing. Für einen modernen Desktop ist es gnadenlos ineffizient, und das weiß auch jeder, der es mal übers Internet genutzt hat.
Außerdem ist es problemlos möglich, ein Remote-Rendering-Protokoll über Wayland zu legen. Und das könnte man dann so auslegen, dass es die Features unterstützt, die heutzutage sinnvoll sind, und nicht die, die vor 20 Jahren sinnvoll waren. Und selbst wenn es dazu nicht kommt, ist eine "Pixel-scraping"-Lösung a la VNC X immer noch überlegen, da VNC wenigstens Kompression unterstützt - nicht einmal das tut X11.Früher oder später wird Nvidia seine Politik ändern müssen, wenn sie unter Linux nicht den Anschluss verlieren wollen. Ich bin optimistisch, dass es in den nächsten Jahren eine Entwicklung in dieser Richtung geben wird.Die Argumentation ist behämmert. Es ist kaum möglich, die Zukunft vorherzusagen, aber das kann doch kein Argument dafür sein, eine Technologie beizubehalten, die heute schon veraltet ist. Obwohl, wieso heute? Man lese diesen Kommentar von Mike Paquette, einem der Entwickler von Apples Quartz-Technologie. X11 war 2003 schon völlig veraltet.Kannst Du dieses Gewäsch auch nur _irgendwie_ begründen? Was ist an Wayland nicht "ingeneursmäßig" (sic)? Mir scheint, Du hast einfach keine Ahnung, worüber Du hier redest. Dieser Beitrag wurde 1 mal editiert. Zuletzt am 12. Feb 2012 um 22:29.
Wenn du weiterhin X brauchst, nutz es. Keiner hält dich ab. Wenn du auch noch in 50 Jahren X nutzen willst, nutz es. Auch dann wird dich keiner abhalten, genauso wenig wie wir dich von Pferdekutschen und Kornkühlen abhalten.
Aber wegen dir bleibt die Welt trotzdem nicht stehen. Nur du bleibst stehen.
"Eine Linux-Only-Lösung, die von Nvidia nicht unterstützt wird, ist hier auch dringend nötig."
Nouveau wird niemals so gut werden können wie der unfreie NVidiatreiber.
Vergiss es.
Nouveau funktioniert mit etwa 50% aller existierenden Nvidiagrafikkarten leider nur auf 2D-Niveau ohne jede Hardwarebeschleunigung.
Deshalb kommt nun auch das Allheilmittel der Gnome3-Shell-Red Hat-Fraktion:
Quadcore-CPU und "Shadowfb", Pseudo-3D für Outcasts.
Die Llvmpipe hast Du vergessen bzw. an diese gedacht.
Stimmt.
Das mit dem shadowfb war der Gegenvorschlag auf die Frage, wie man denn in Zukunft einen alten oder "kaputten" Treiber ohne jede 2D-Hardwarebeschleunigung nutzen soll.
> Nouveau wird niemals so gut werden können wie der unfreie
> NVidiatreiber.
> Vergiss es.
Ist auch egal, ob er 100% so schnell ist, wie der proprietäre Treiber. Wichtig ist, dass er mit der HW läuft die existiert und die Dinge für die er benötigt wird (Wayland, Desktop Environment) vernünftigt beherrscht.
Außerdem besitzt du keine Glaskugel und kannst in die Zukunft sehen. Ich kann dir aber sagen, dass es einen gewissen freien Kernel gibt, der sämtliche existierenden proprietären Betriebssysteme in punkto Leistung, Flexibilität, Kosten usw. in den Schatten stellt. Welcher war das nur ... ?
NetBSD?
Als Nicht-Entwickler kann man das leider sehr schlecht beurteilen. Die zahlreichen Informationen, die man im Netz findet, geben die Sachverhalte zwar korrekt wieder. Aber nur wer wirklich Erfahrung in der Software-Entwicklung mit X hat, kann gut beurteilen, was jetzt der Mehrwert von Wayland sein soll.
Stelle dir vor, du schreibst ein Java-Programm, das ein Pixel auf den Bildschirm zeichnet. Du kannst dir sicherlich vorstellen, dass dieses Pixel einen weiten Weg hat, bis es auf dem Bildschirm erscheint. Das Pixel muss durch das Betriebssystem, durch die Desktop- und Fenster-Routinen, durch den Grafikkartentreiber und schließlich irgendwann landet es im RAM der Grafikkarte und auf dem Bildschirm. Das ist ein ziemlich weiter weg. Dass dieser Weg weit ist, sieht man z.B. beim Scrollen. Es ist nie so flüssig wie z.B. die Bewegung in einem Computerspiel.
Wayland ist jetzt eine Architektur, die diesen Weg deutlich verkürzt. Beispielsweise die Umrechnung von Pixeln in einem Fenster auf Bildschirmpixel macht der X-Server oft selber. Aber eigentlich ist das nichts anderes als eine 3D-Routine, die moderne Grafikkarten auch alleine machen können. Das heißt, hier gibt es eine Abkürzung.
Die Schwierigkeit für den Laien ist jetzt, dass er eigentlich kaum beurteilen kann, welche Schritte auf diesem Weg von einem Pixel wirklich notwendig sind. Es ist ja nicht so, dass X sinnlose Berechnungen durchführt. Was X macht, ist schon alles sehr sinnvoll und bewährt. Daher auch die Skepsis gegenüber Wayland. Aber welches Detail in welchem Kontext wie am besten gelöst werden, ist eine außerst komplizierte Frage.
"Was X macht, ist schon alles sehr sinnvoll und bewährt."
Das X-Protokoll ist ziemlich bescheuert für heutige Anforderungen. Das ist nicht sinnvoll, und bewährt nur wen man bewährt = "man leidet darunter, aber kennt es" bedeutet.
Da stimme ich dir voll zu. Ich meinte es eher so: Es gibt viele Situationen, in denen das X-Protokoll "sinnvoll und bewährt" ist. Daher will ich mal nicht so sehr meckern. Aber mein Rechner fällt nicht darunter. Bei meiner täglichen Arbeit X zu benutzen, ist, wie du sagst "bescheuert" und "man leidet darunter". Daher freue ich mich schon darauf, wenn ich diese Altlasten endlich los bin.
Viele Leute fragen dann halt ganz natürlich, ob ihre unfreien Nvidia- und ATI-Treiber noch funktionieren werden.
Es ist doch ganz normal, dass niemand von denen eine Distro mit Wayland benutzen würde, wenn das nicht sofort funktionieren sollte. Das interessiert die Nutzer, nicht wie das X- oder Nicht-X-"Ding" heißt oder was es auf technischer Ebene macht.
Ich sage einfach mal ja das werden sie. Nur was sollen Nvidia und AMD jetzt tun? Ein System unterstützen das noch nicht fertig ist? Sobald es die erste "fertige" Version gibt werden die sich sich das mal anschauen und entsprechenden Support implementieren.
Das ist vollkommen irrelevant. Die Toolkits haben Backends für die verschiedenen Ausgaben. Auf den Rechner, auf denen Wayland läuft, wird Wayland gestartet und das Wayland-Backend benutzt. Wo es noch nicht funktioniert, da kommt halt X11 und das X11-Backend zum Einsatz. Aber irgendwann werden sich die Leute fragen, warum Ihr 300€ PC mit Intel-OnBoard Grafik besser läuft, als die High-End-Workstation mit 300€ Grafikkarte von NVidia. Spätestens dann werden auch NVidia und ATI von Ihrem hohen Ross steigen müssen und Treiber oder Specs liefern.
>Spätestens dann werden auch NVidia und ATI von Ihrem hohen Ross steigen müssen und Treiber oder Specs liefern.
Tut das ATI nicht bereits seit Jahren?
Ich habe die Ankündigungen von ATI gelesen. Aber sind daraufhin jemals erwähnenswerte Taten erfolgt?
Ja, die aktuellen Chips von AMD sind dokumentiert.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 12. Feb 2012 um 22:32.http://developer.amd.com/documentation/guides/Pages/default.aspx
vielleicht interessiert sich nvidia ja garnicht für linux? vielleich sind die linux treiber ja nur ein abfallprodukt der AIX (und konsorten) treiber, weil man diese für cathia zb braucht?
was dann?
Dann Bye Bye NVidia. Ein unfreier Binary-Blobs weniger!
Dann Bye Bye NVidia. Ein unfreier Binary-Blobs weniger!
Bisher war der Treiber so generisch, dass Solaris, FreeBSD und Linux zugleich unterstützt werden konnten, immerhin. Intel, AMD ist sich dafür ja zu schade.
Deren Verfügbarkeit über Systemgrenzen hinweg samt ihre Cuda Technologie ist ein Grund warum man in der Forschung ausschließlich auf deren Karten setzt. Für 3D Tetris und die x-te Quake Engine brauchst du solche Highend Karten sicher nicht.
Die Gefahr sehe ich auch nicht so sehr. Wenn man sich die OpenSource-Welt mal anschaut, so war es oft so, dass funktionierende Software auch weiter funktioniert. KDE 3 (Trinity) funktioniert noch wunderbar, obwohl schon lange KDE4 verfügbar ist. Gnome 2 kann noch verwendet werden. Der Kernel 2.2 wurde ewig gepflegt. OpenGL funktioniert auch ohne DRI noch wunderbar. OpenGL funktioniert sogar remote halbwegs gut, obwohl das wirklich kaum jemand benötigt. Sogar solche verrückten Dinge wie Videos über die Ascii-Art-Schnittstelle ausgeben im mplayer funktionieren seit Jahren unverändert. DLL-Probleme oder Compiler-Inkompatibilitäten gibt es auch kaum.
Insgesamt kann man sich eigentlich nicht beklagen, dass Dinge von heute auf morgen nicht mehr funktionieren. Ich denke, da können wir zuversichtlich sein, dass jede x-beliebige Linux-Distribution bei Bedarf auch zukünftig noch X mitliefern wird und sämtliche Anwendungen ordentlich damit laufen werden. Man hat die freie Wahl, ob man Wayland möchte oder X. Ich finde das wirklich schön.
Zwei Beispiele:
Die X11-Architektur sieht vor, dass die X11-Programme Zeichenanweisungen an den X11-Server senden und jener diese ausführt. Moderne Toolkits zeichnen aber zum großen Teil selbst und senden bloß noch Bitmaps zum Server. Das ist ein Bruch mit der Architektur und zeigt, dass sie nicht mehr zeitgemäß ist.
DRI/DRM erlaubt einen gemeinsamen Speicherbereich zwischen Server und Client zu haben, damit der Client 3D-Operationen machen kann. Das ist nicht mit X11-Forwarding kompatibel und wiederum ein Bruch mit der ursprünglichen Architektur.
Und zur Thematik: "Aber mein geliebtes X11-Forwarding!!einsölf1"
Das wird einfach anders implementiert, als es beim X11 war und könnte, wenn man will, genauso funktionieren. Einziger Unterschied ist, dass es nicht im Kern des Display-Servers steckt.
hab gerade ein ssh -X in meinem lokalen netz (1000Mb) gemacht, und remote glxgears gestartet.
fast die selben FPS wie lokal gestartet.
auch quake3 ist remote so (gerade noch) spielbar.
(nvidia GK, und GBit netz)
Das ist auch ursprünglich für (schnelle(re)) lokale Netzwerke gedacht gewesen.
Die meisten Mitleser hier registrieren das einfach nicht.
Das nennt sich GLX.
http://de.wikipedia.org/wiki/GLX
Aber was hat das jetzt mit dem Thema zu tun?
Du kannst glxgear flüssig über ein Gigabit-Netzwerk laufen lassen ... TOLLLLL!!! Oder ein 15 Jahre altes Spiel, SUUUUUPER!!! Wie oft hast Du das in den letzen 15 Jahren benötigt?
Glxgears ist kein Benchmark, also was soll der Quatsch? Und bei Quake III stellt sich die Frage, ob es per VNC o. ä. nicht genauso gut bzw. schlecht laufen würde.
vnc und opengl? sei ehrlich, du redest nur und hast es nie probiert!
quake3 laeuft bei mir mit 20-30 fps und und urbanterror mit knapp unter 20 fps wenn ich es remote starte ( ssh -X -C ) im gigabit netzwerk.
Bist Du nicht fähig oder zu faul Dich selbst zu informieren?