ubuntuusers.de

🛈 Aktuell gibt es im Wiki ca. 300 Artikel, die nur für Xenial getestet sind. Dies entspricht ca. 3,8 % aller Wikiartikel. Damit diese im Frühjahr nicht alle archiviert werden müssen, ist eure Mithilfe gefragt!

[Kwami] Wayland vs. Mir

kwami.png

Diese Woche hat Canonical einen eigenen Displayserver namens „Mir“ angekündigt und damit für viel Aufregung und Verwirrung in der Freien-Software-Welt gesorgt. In diesem Kommentar von Martin Gräßlin werden die Hintergründe dieser Entscheidung kritisch beleuchtet.

Hinweis:

Dieser Artikel gehört der Kategorie Kwami an. Er spiegelt damit allein die Meinung des Autors und nicht zwingend die des ubuntuusers.de-Teams wider.

Worum geht es überhaupt? Was ist ein Display Manager?

Ein Display Manager ist vereinfacht gesagt die Schnittstelle zwischen einem „Fenster“ und den Betriebssystemschichten. Der Display Manager nimmt Eingabeereignisse (z.B. Tastatur, Maus, Touch) vom Linux-Kernel entgegen und leitet sie an das „Fenster“ weiter, welches aktuell die Ereignisse erhalten soll. Auf der anderen Seite ist das Fenster, welches in einen „Buffer“ zeichnet und Änderungen an diesem an den Display Manager kommuniziert, damit dieser den Inhalt des Buffers auf den Bildschirm bringt.

In der Unix-Welt ist seit Mitte der 80er Jahre des letzten Jahrhunderts das X Window System das Mittel der Wahl für Display Management. Mittlerweile zeigt die aktuelle Version 11 des X-Protokolls aus dem Jahre 1987 ihr Alter. Fast die komplette Funktionalität wurde entweder durch Erweiterungen ersetzt oder in die Clients („Fenster“) verschoben. Die Anzeige der Fensterinhalte übernimmt heutzutage ein „Compositor“ (unter Unity ist dies Compiz, bei der GNOME Shell ist es Mutter und bei KDE Plasma ist es KWin). Der X-Server wird eigentlich nicht mehr benötigt und ist vor allem auf mobilen Endgeräten eher ein Hindernis. Googles Android setzt daher auf eine Eigenentwicklung namens „SurfaceFlinger“.

Der X-Nachfolger: Wayland

Seit einigen Jahren arbeitet die Freie-Software-Welt an einem Ersatz für X. Solche Versuche gab es schon oft und sie sind alle gescheitert. Doch diesmal sieht es besser aus. Es gibt Zustimmung von allen Seiten, insbesondere von den X-Entwicklern, welche aktiv das Projekt vorantreiben und aus deren Reihen auch der Hauptentwickler und Initiator Kristian Høgsberg stammt.

Ende letzten Jahres konnten nach mehreren Jahren Entwicklung die Version 1.0 der Waylandspezifikation 🇬🇧 freigegeben werden. Hiermit hat die Entwicklung einen Stand erreicht, dass man nun anfangen kann auf Wayland aufzubauen. Dass das alles sehr lange dauert und es teilweise für Nichtinformierte so aussieht, als ob alles stagnieren würde, ist nicht wirklich überraschend, sondern durchaus gewollt. Eine Spezifikation für einen Display Manager zu schreiben ist nichts, was man mal eben so macht. Die Spezifikation muss richtig sein und zwar beim ersten Versuch. X hat wie bereits erwähnt 11 Versuche gebraucht, so etwas richtig hinzubekommen. Dass die X-Entwickler, die auch an Wayland arbeiten, nun darauf achten, solche Fehler nicht zu wiederholen, ist nachvollziehbar.

Für Desktopumgebungen wie KDE Plasma oder GNOME Shell ist es nicht gerade einfach auf Wayland zu wechseln – sie wurden geschrieben für X11 unter der Annahme, es würde niemals etwas anderes geben. Trotzdem stehen sie voll hinter der Entwicklung und arbeiten an den Portierungen, gehen aber ebenfalls sehr vorsichtig vor, da sie die Systeme der Nutzer nicht gefährden wollen.

Es sieht eigentlich alles ganz toll aus. Alle sind sich einig, dass Wayland die Zukunft ist. Auch Canonical. Bereits 2010 🇬🇧 träumte Mark Shuttleworth davon, innerhalb des nächsten halben Jahres bis einem Jahr Unity auf Wayland aufbauen zu können. Alles sah toll aus...

Mir

... bis Montag und die überraschende Ankündigung, dass Canonical einen eigenen Display Manager Mir 🇬🇧 entwickelt. Kritik hagelte es schnell von allen Seiten, vor allem da die Spezifikation keinerlei Unterschiede zu Wayland aufzeigt. Kristian Høgsberg konstatierte dann auch nur, dass „dies alles so vertraut klingt...“ 🇬🇧. Dave Airlie, einer der führenden Köpfe des Grafikstacks unter Linux, stellte süffisant fest, dass „Canonical mit dem Rad unzufrieden ist und es demnächst eine Spezifikation geben wird es zu ersetzen“ 🇬🇧. Ausführlicher hat er seine Sicht auch in seinem Blog kommentiert 🇬🇧.

Natürlich hat Canonical gute Gründe, warum sie Mir brauchen und Wayland nicht gut genug ist. So erbt laut Canonical Wayland die Sicherheitsprobleme von X für Eingabeereignisse... oder auch nicht, denn wie mittlerweile in der Spezifikation steht:

Please note though that Wayland's input event handling does not suffer from the security issues introduced by X's input event handling semantics (thanks to Daniel Stone and Kristian Høgsberg for pointing this out)

Übersetzt: „Bitte beachten Sie, dass jedoch Waylands Eingabeereignisverarbeitung nicht unter den Sicherheitsproblemen leidet, welche in Xs Eingabeereignis-Verarbeitungssemantik verursacht wurden (vielen Dank an Daniel Stone und Kristian Høgsberg für die Korrektur)“

Moment – das Hauptargument, warum man eine eigene Technologie ausarbeitet, ist erlogen oder einfach nur falsch? Was dahinter steckt, darf der Leser sich aussuchen - keine der möglichen Optionen klingt, als ob hier Experten am Werk wären.

Sicherlich muss es noch mehr Gründe auf technischer Seite geben und ja es gibt eine interessante Diskussion zwischen einem Canonicalmitarbeiter und verschiedenen Waylandentwicklern auf IRC. Nachzulesen hier. Es erscheinen dann als weitere Argumente Unwissenheit (serverseitige Buffer nicht möglich mit Wayland – widerlegt von daniels um 00:35) und Missverständnis (shell interface muss gebunden werden) – diese wurden von Tiago Vignatti in einen Blogpost 🇬🇧 auch ausführlicher auseinander genommen. All diese angeblichen Probleme konnten sehr schnell geklärt werden, wenn man denn nur mal miteinander redet.

Warum!?

Die große Frage bleibt somit im Raum stehen: Warum? Warum entwickelt Canonical einen eigenen Display Manager, wenn Wayland die gleichen Anforderungen erfüllt. Technische Argumente können es nicht gewesen sein, zumindest wird dies von Wayland Entwicklern bezweifelt 🇬🇧. Dass diese Argumente dann im Nachhinein davor geschoben wurden, ist einfach nur peinlich und das, was die Entwickler wirklich aufregt. Kristian bringt es im Chat recht deutlich zum Ausdruck was er davon hält: „that's what pisses me off - you can do whatever you want and you don't need my permission - but don't piss on wayland in the process“ (00:02).

Natürlich darf Canonical entwickeln was sie wollen. Sie dürften auch einen eigenen Kernel entwickeln. Niemand stört sich daran. Nur die eigene Entwicklung durch angebliche Fehler in anderen Projekten zu begründen, ist einfach nicht akzeptabel.

Man kann sich nun fragen wie das passieren konnte. Ist es schlicht Unwissenheit? Hoffentlich nicht! Man stelle sich mal vor, man entwickelt seit 9 Monaten an einem eigenen System ohne das existierende zu verstehen. Was natürlich die nächste Frage aufwirft: Warum entwickelt man 9 Monate an dem System basierend auf technischen Limitierungen, ohne diese auszuräumen? Wayland war ja noch nicht finalisiert. Man hätte sich ja daran beteiligen können.

Die wohl wahrscheinlichste Variante ist, dass Canonical die Kontrolle über das Projekt will, was auch OK ist, nur sollte Canonical es dann auch zugeben. Es passt ja ins Bild: Unity, Upstart und nun Mir.

Was bedeutet es für Ubuntu?

Als die ersten Gerüchte aufkamen, dass Canonical einen eigenen Display Manager entwickelt, wurde das als schlechter Witz angesehen. Niemand traut Canonical das zu und auch die allgemeine Meinung ist, dass sie sich mit der Aufgabe übernehmen. Wayland hat lange gedauert - nicht weil die Entwickler nichts geschaffen bekommen, sondern weil sie die Problematik perfekt kennen. Sie sind die Experten in dem Bereich. Wie Canonical dies nun ohne diese Experten schneller und besser schaffen will, ist mehr als fraglich. Aktuell sieht die Quellcodebasis noch nicht sehr vielversprechend aus. Aber hier gilt es natürlich abzuwarten, was daraus wird.

Für Ubuntunutzer ist das Ganze natürlich schade. Es sieht sehr danach aus, dass sie nun zum Versuchskaninchen für eine Eigenentwicklung werden, die klar nicht für Desktops ausgelegt ist. Wie aus dem IRC-Chat deutlich wurde, ist einer der Beweggründe die Android-Grafiktreiberarchitektur. Ob der Desktop dann nicht auf der Strecke bleibt, wenn die Zeitlinie für das nächste Tablet eingehalten werden muss, ist nicht auszuschließen. Die angestrebte Rolling-Release-Distribution wird dies für die Nutzer nur noch gefährlicher machen. Wobei auch die Frage berechtigt ist, ob Canonical überhaupt noch Interesse am Desktop hat.

Für die sogenannten Ubuntu „Flavors“ wie Kubuntu oder Xubuntu ist die Umstellung auf Mir unangenehm. Die Desktopumgebungen werden wohl kaum Unterstützung für Mir einbauen, da nach aktuellem Wissensstand Wayland technisch überlegen wirkt und Mir aktuell nur in einer Distribution eingesetzt wird. Je nachdem wie das System am Ende eingesetzt wird, kann es sehr leicht zu einem System zweiter Klasse werden, wo die Desktop-Umgebung in einem emulierten X-Welt lebt, wogegen auf anderen Distributionen auf Wayland gesetzt werden kann. Diese Sorgen wurden auch sehr schnell von einem Kubuntu-Entwickler angesprochen 🇬🇧.

Was bedeutet es für die Freie-Software-Welt?

Ein Aspekt wurde bisher noch nicht angesprochen: Anwendungen müssen an ein Windowing-System wie X, Wayland oder Mir angepasst werden. Ohne speziellen Code funktioniert dies nicht. Anwendungen verwenden dazu Toolkits. Am verbreitetsten sind hierbei GTK+3 (GNOME und bis Montag Ubuntu) und Qt (KDE und seit Montag Ubuntu), welche es erlauben das Fenstersystem zur Laufzeit auszuwählen. Dies ermöglicht es erst, Anwendungen unter Linux entweder für X oder Wayland bereitzustellen. Bei beiden Toolkits (und bei weiteren) ist Wayland in Entwicklung und bereits einsatzfähig. Mir möchte Canonical nun selbst beisteuern. Damit nehmen sie eine große Aufgabe auf sich. In der Theorie sollten Anwendungen auf diesen Toolkits dann einfach funktionieren – die Praxis sieht aber immer ein bisschen anders aus, was bedeutet, dass je nach welcher Linux Distribution bei den Entwicklern verwendet wird, die Anwendung besser oder schlechter funktioniert – auch dann unter den Flavors. Als ob es nicht schon genügend Unterschiede zwischen den Desktops gibt, wird nun noch ein weiteres Problem eingebaut. Vielen Dank!

Richtig problematisch wird es für Anwendungen, welche nicht auf einem der zwei großen Toolkits aufbauen. Was sollen sie machen? Auf X bleiben und in der Wayland- und Mir-Welt als „legacy“ angesehen zu werden. Auf Mir portieren? Auf Wayland portieren? Beides unterstützen? Bis Montag war dies keine Frage. Jedem wäre klar gewesen, dass langfristig eine Waylandportierung notwendig ist, nun ist das ein ernsthaftes Problem bei dem man zwischen Ubuntu und dem Rest der Welt oder doppelter Arbeit wählen darf. Viele werden dann wohl leider auf X bleiben und abwarten, wer sich durchsetzt.

Hier wird auch ersichtlich, dass das oft angeführte Argument der „Vielfalt ist gut“ oder „Konkurrenz belebt das Geschäft“, nicht greift. Mir verursacht Probleme - für alle. Es ist diesem nichts positives abzugewinnen, nicht einmal als Alternative. Alternativen zu X/Wayland gibt es mit SurfaceFlinger und anderen Systemen schon mehr als genug.

Zusammenfassend bleibt hier nur noch festzustellen, dass Canonical nun den kompletten Split der Freien-Software-Welt erreicht haben. Ubuntu entfernt sich immer weiter von allen anderen Distributionen - angefangen mit Unity über Upstart zu nun auch noch Mir. Eine Entwicklung, die zu erwarten war und sich seit langem immer wieder in kleinen Schritten abzeichnet. Ob die Strategie langfristig erfolgreich ist, ist fraglich.

Über den Autor

Martin Gräßlin ist KDE-Entwickler und arbeitet hauptsächlich am Fenstermanager und Compositor KWin. Fenstermanager und Fenstersysteme gehören somit zu seinem Spezialgebiet und auch die Portierung von KWin nach Wayland wird von ihm vorbereitet.


Vielen Dank an Martin Gräßlin für den eingereichten Kommentar!