Software::Distributionen::Canonical
Canonical-Entwickler geben Details zum Mir-Projekt
Nachdem Canonical anlässlich seiner Ankündigung, mit Mir einen eigenen Displayserver zu entwickeln, reichlich Kritik geerntet hatte, haben Canonical-Mitarbeiter jetzt noch einmal detailliert ihre Gründe für die Entscheidung dargelegt.
Ubuntu
Architektur von Mir
Der Haupttenor der Kritik an Canonicals Entscheidung, mit Mir
einen eigenen Displayserver zu starten, ist, dass Entwickler befürchten, Canonical spalte die Gemeinschaft. Unter dem Titel »Warum wir Mir entwickeln« haben daher Canonical-Mitarbeiter wie Christopher Halse Rogers auf
Google+ die Gründe für das Entwickeln von Mir noch einmal im Detail dargelegt. In diesem Zuge hat sich Rogers beim Wayland-Projekt für einige irreführende Informationen entschuldigt, etwa die Aussage, die Protokolle von Wayland seien unsicher. Das sei falsch, denn Wayland löse durchaus in X vorhandene Sicherheitsprobleme.
Laut Christopher Halse Rogers solle Mir eigentlich »genauso wie Wayland werden«, aber »doch ganz anders«. Der für Mir vorgesehene Ansatz hätte allerdings fundamentale Änderungen am Wayland-Code nach sich gezogen, weshalb sich sein Arbeitgeber entschlossen habe, die Mitarbeit an Wayland einzustellen. Dennoch solle sich für die Anwender nichts ändern und alle relevanten Desktops, darunter KDE, Gnome, Xfce und Mint, weiterhin mit Mir funktionieren, so Rogers, weil auch Mir nicht auf die Unterstützung des X-Servers verzichten könnte. Trotzdem sollen auch die Wayland-Entwickler von Canonicals Bemühungen profitieren.
Ubuntu
Architektur von Mir
Laut Rogers wollte Canonical nicht Waylands Referenz-Compositor Weston benutzen, weil dieser keine Desktop-Shell sei, sondern nur zum Entwickeln der Wayland-Protokolle diene. Zum Zeitpunkt, als Canonical mit der Entwicklung von Mir begann, habe es keinen Input-Stack für Wayland gegeben. Die Canonical-Entwickler wollten zur Unterstützung der ARM-Plattform eine Server-seitige Speicherverwaltung. Diese soll langfristig auch in den anderen Ubuntu-Versionen umgesetzt werden. Die Wayland-EGL-Plattform in Mesa und Weston arbeite dagegen mit einer Client-seitigen Puffer-Allozierung. Zwar sei eine Server-seitige Speicherverwaltung auch mit den Wayland-Protokollen möglich, die Umsetzung sei aber äußerst schwierig und wohl auch kaum im Interesse der Wayland-Entwickler. Ferner strebten die Mir-Entwickler eine andere Semantik für die Fensterverwaltung an, als sie in Wayland umgesetzt ist.
Schließlich hätte die Weiterentwicklung von Wayland und Weston für Canonical bedeutet, einen Input-Stack und Patches für die EGL-Plattform in Mesa zu schreiben. Außerdem hätte die Umsetzung der Fensterverwaltung in allen Toolkits umgeschrieben werden müssen. Rogers betont aber, Canonical werde auch weiterhin den X-Server unterstützen. Auf X11 basierende Anwendungen sollen quasi nichts von der Umstellung auf Mir bemerken. Einzig das Verwenden alternativer Display-Manager wie KDM oder GDM müsse bereits beim Systemstart erfolgen und nicht erst im Anmeldefenster. Rogers schreibt weiter, der Treiber-Stack von XMir werde sich bei Desktop-Systemen nur geringfügig vom XWayland-Treiber-Stack unterscheiden, womit Rogers etwaigen Befürchtungen von Entwicklern entgegen steuern will, Mir werde die Treiber-Entwicklung unter Linux fragmentieren. Dieser Kritikpunkt wurde vor allem von KDE-Entwicklern geäußert. Da sich Mirs EGL-Plattform ebenfalls kaum von der für Wayland oder X11 unterscheiden werde, könnten die von Canonical zusammen mit Nvidia und AMD für deren proprietären Treiber anstrebten Entwicklungen auch für andere Projekte von Nutzen sein.
){kind=small}
){kind=small}
