Von Mir ist ein compositor für Way am Mo, 24. September 2018 um 17:49 #
Mir ist, wie auch im Artikel beschrieben mittlerweile ein compositor für Wayland. Man benötigt bei Wayland einen compositor und fast jede DE braut da ihr eigenes Süppchen. Gnome und KDE haben ihren eigenen sogar sway (ein tiling WM für wayland) benötigt seinen eigenen. Da wundert es nicht wenn unity auch so was haben will.
" Nach der Trennung des Projekts von Canonical stand nicht nur Mir, sondern auch das dahinter stehende Konzept zur Disposition. Reichlich spät sind die Entwickler deshalb zu der Einsicht gelangt, dass neben Wayland kein zweites neues Protokoll benötigt wird. Ende des vergangenen Jahres verkündeten sie schlussendlich, dass Mir in Zukunft nur noch mit Wayland-Clients kommunizieren soll. Damit sollte sich der Server auf die Aufgabe eines Treibers, Kompositors und Window-Managers beschränken und nur ein Minimum weiterer Komponenten mitbringen. "
.... Canonical stellte die Entwicklung von Unity und Mir allerdings im Frühjahr 2017 ein und Mir wandelte sich zu einem Gemeinschaftsprojekt, das von einigen Freiwilligen unabhängig weitergeführt wird. Die Leitung von Mir übernahm dabei Alan Griffiths, der schon bei Canonical das Projekt führte....
Unity7 und Unity8 sind nicht eingestellt, Canonical hat nur aufgehört die Entwickler für die Arbeit an diesen Projekten weiter zu bezahlen. Bei mir wurde das Team verkleinert - die Arbeit geht aber weiter. Alan Griffiths ist wohl der aktivste beteiligte Entwickler und noch immer bei Canonical beschäftigt.
..... Den Anstoß, auf eine Eigenlösung zu setzen, gab bei Canonical seinerzeit die Ansicht, wonach weder X11 noch Wayland den Anforderungen von Ubuntu entsprechen würden. Die Reaktionen aus der Gemeinschaft fielen auf diese Ankündigung allerdings recht unterschiedlich aus. Der Start eines neuen Display-Servers missfiel manchem Entwickler.
Randbemerkung: wayland ist in erster Linie ein Code Generator für UI-Protokoll. Technisch könnte man auch sagen dass wayland die weiterentwicklung der x11 Protokollerlweiterungsmechanismen ist. MirServer /MirAL ist aus Stacksicht ein paar Ebenen höher aufgehängt, vielleicht eher mit Compiz+X11Server vergleichbar). MirServer ist eine Display Server Implementierung mit flexibler Treiberschicht. Mit Hilfe von MirServer können WindowManager/Compositor gebaut werden. Selbst mit dem Support von Wayland clients hat sich daran nichts geändert.
So bekräftigte beispielsweise der damalige Betreuer von Kwin seine Ablehnung gegenüber Mir und bemängelte, dass viele Konzepte unausgereift waren.
Martin hat sich mit Mark einen ins persönliche abgerutschten Streit geliefert, inhaltlich war da nichts..
Nach der Trennung des Projekts von Canonical stand nicht nur Mir, sondern auch das dahinter stehende Konzept zur Disposition.
Fake news.
Reichlich spät sind die Entwickler deshalb zu der Einsicht gelangt, dass neben Wayland kein zweites neues Protokoll benötigt wird.
Fake news und hier liegt ein fundamentales Problem von wayland begraben. Wayland ist X11 auf Extensions-LSD. Es gibt die wayland core Protokolle die irgendwie jeder Client und Server können muss. Damit lässt sich aber noch keine ordentliche Desktop Anwendung bauen. Darüberhinaus hat sich jedes Compositor Projekt seinen eigenen Satz von Erweiterungen gebacken. Zusammengeführt wurden diese teilweise in den xdg-shell Protokollen. Diese werden regelmäßig erweitert und sind jetzt bei v6 angelangt. Die UI Toolkits und Server müssen also mit diesem Versionswust umgehen. Ob ein Client oder Server sauber funktioniert ist dann am eine Laufzeitentscheidung, also ob die Version der ui toolkit library mit den am Server verfügbaren Protokollversionen zusammenpasst.
In der mirclient library wurde damals versucht dieses Problem nicht dem Toolkit zu überlassen sondern in der Implementierung der client library abzufangen.
Obwohl es diesen Wildwuchs an Protokollen gibt sind gerade die Core Protokolle auch ein Problem. Das dort verankerte redraw Protokoll geht davon aus dass der client und server mit Puffern hantieren. Wenn man davon abweichen will fängt man sich nur Ärger ein. Nvidia wollte EGLStreams einführen. Dort nutzen Client und Server handles auf einen Stream über den dann das redraw geregelt wird. Also wir nie ein einzelner Puffer per IPC von Client zu Server transportiert - das passiert auf Treiber Ebene. Das hat jede Menge Vorteile bei der Latenz beim Resourcenverbrauch - es spart IPC .. usw.
Im Mir Design sind EGLStreams nur MirRenderSurfaces die an Fenstern attached werden koennen, die technischen Details werden durch die client und server Treiber Implementierungen geregelt. Dadurch muss kein WindowManager/Compositor angepasst werden und clients nutzen einfach die EGL. Das ist Software Design 1x1 - Verstecke deine Implementierungsdetails! Lass nicht zu dass das Protokoll das du verwendest in deiner API sichtbar wird.
- Mit Wayland kann jeder sein eigenes Protokoll bauen -
Jede Anwendung kommuniziert ausschließlich über eine eigene Verbindung, die sowohl sicher als auch robust gegen Angriffe ist.
Das war auch schon bei X11 so und bringt sicherheitstechnisch nichts neues. Sicherheitskonzepte sind in den Waylandprotkollen immer noch nicht umgesetzt. Copy & Paste ist so schrecklich wie schon bei X11. (Eine Lösung des C&P Problems gibt es bei Ubuntu Touch -> Content Hub)
Von Gnome-Nutzer am Di, 25. September 2018 um 11:36 #
• Unity 7 wird weiterentwickelt • Unity 8 wird weiterentwickelt • Mir und das dahinterstehende Konzept standen nie zur Disposition • neben Wayland w i r d ein zweites Protokoll benötigt • Wayland ist ein unsicherer, unausgereifter Versionswulst
Von Klaus Müller am Di, 25. September 2018 um 15:48 #
Hach schön, wie die Canonicals auf ihrem Schrott eingeschworen sind und sich nicht einmal davon trennen können, wenn das Projekt bereits auf dem Abstellgleis steht! Erinnert mich irgendwie an Apple Jünger ...
Aber wir werden ja sehen, wie sehr die Welt auf Mir gewartet hat und welche Distributionen ohne Mir nicht zurecht kommen werden?
Meine Prognose: Keine außer Canonical und deren Ableger.
Also ändert sich im Prinzip nicht viel zum Ist-Zustand, alle anderen Distributionen machen einen großen Bogen um Canonical Technologie.
Whoa! Was hat das so lange gedauert bis die typischen "Alles-von-Canonical-is-schlecht"-Fraktion ihren Senf abgibt. :-O Was ist los? Zu irrationaler Lebensstil, um konsequent den eigenen irrationalen Hass zu pflegen?
Kann mir jemand erklären wozu ich Mir brauchen sollte ?
Alle Gui toolkits werden doch entwickelt um direkt mit Wayland zu kommunizieren/davon Gebrauch zu machen.
Warum also sollte man eine Zwischenschicht einführen (wollen)?
Aber es darf ja jeder seine Freizeit einteilen wie er will, auch wenn das dann keinen Sinn oder Zweck erfüllt.
Mir ist, wie auch im Artikel beschrieben mittlerweile ein compositor für Wayland. Man benötigt bei Wayland einen compositor und fast jede DE braut da ihr eigenes Süppchen. Gnome und KDE haben ihren eigenen sogar sway (ein tiling WM für wayland) benötigt seinen eigenen. Da wundert es nicht wenn unity auch so was haben will.
"
Nach der Trennung des Projekts von Canonical stand nicht nur Mir, sondern auch das dahinter stehende Konzept zur Disposition. Reichlich spät sind die Entwickler deshalb zu der Einsicht gelangt, dass neben Wayland kein zweites neues Protokoll benötigt wird. Ende des vergangenen Jahres verkündeten sie schlussendlich, dass Mir in Zukunft nur noch mit Wayland-Clients kommunizieren soll. Damit sollte sich der Server auf die Aufgabe eines Treibers, Kompositors und Window-Managers beschränken und nur ein Minimum weiterer Komponenten mitbringen.
"
Aber haters gonna hate
also ala Mutter/kwin, ...
vielen Dank für die klärenden Worte!
.... Canonical stellte die Entwicklung von Unity und Mir allerdings im Frühjahr 2017 ein und Mir wandelte sich zu einem Gemeinschaftsprojekt, das von einigen Freiwilligen unabhängig weitergeführt wird. Die Leitung von Mir übernahm dabei Alan Griffiths, der schon bei Canonical das Projekt führte....
Unity7 und Unity8 sind nicht eingestellt, Canonical hat nur aufgehört die Entwickler für die Arbeit an diesen Projekten weiter zu bezahlen. Bei mir wurde das Team verkleinert - die Arbeit geht aber weiter. Alan Griffiths ist wohl der aktivste beteiligte Entwickler und noch immer bei Canonical beschäftigt.
..... Den Anstoß, auf eine Eigenlösung zu setzen, gab bei Canonical seinerzeit die Ansicht, wonach weder X11 noch Wayland den Anforderungen von Ubuntu entsprechen würden. Die Reaktionen aus der Gemeinschaft fielen auf diese Ankündigung allerdings recht unterschiedlich aus. Der Start eines neuen Display-Servers missfiel manchem Entwickler.
Randbemerkung: wayland ist in erster Linie ein Code Generator für UI-Protokoll. Technisch könnte man auch sagen dass wayland die weiterentwicklung der x11 Protokollerlweiterungsmechanismen ist. MirServer /MirAL ist aus Stacksicht ein paar Ebenen höher aufgehängt, vielleicht eher mit Compiz+X11Server vergleichbar). MirServer ist eine Display Server Implementierung mit flexibler Treiberschicht. Mit Hilfe von MirServer können WindowManager/Compositor gebaut werden. Selbst mit dem Support von Wayland clients hat sich daran nichts geändert.
So bekräftigte beispielsweise der damalige Betreuer von Kwin seine Ablehnung gegenüber Mir und bemängelte, dass viele Konzepte unausgereift waren.
Martin hat sich mit Mark einen ins persönliche abgerutschten Streit geliefert, inhaltlich war da nichts..
Nach der Trennung des Projekts von Canonical stand nicht nur Mir, sondern auch das dahinter stehende Konzept zur Disposition.
Fake news.
Reichlich spät sind die Entwickler deshalb zu der Einsicht gelangt, dass neben Wayland kein zweites neues Protokoll benötigt wird.
Fake news und hier liegt ein fundamentales Problem von wayland begraben. Wayland ist X11 auf Extensions-LSD. Es gibt die wayland core Protokolle die irgendwie jeder Client und Server können muss. Damit lässt sich aber noch keine ordentliche Desktop Anwendung bauen. Darüberhinaus hat sich jedes Compositor Projekt seinen eigenen Satz von Erweiterungen gebacken. Zusammengeführt wurden diese teilweise in den xdg-shell Protokollen. Diese werden regelmäßig erweitert und sind jetzt bei v6 angelangt. Die UI Toolkits und Server müssen also mit diesem Versionswust umgehen. Ob ein Client oder Server sauber funktioniert ist dann am eine Laufzeitentscheidung, also ob die Version der ui toolkit library mit den am Server verfügbaren Protokollversionen zusammenpasst.
In der mirclient library wurde damals versucht dieses Problem nicht dem Toolkit zu überlassen sondern in der Implementierung der client library abzufangen.
Obwohl es diesen Wildwuchs an Protokollen gibt sind gerade die Core Protokolle auch ein Problem. Das dort verankerte redraw Protokoll geht davon aus dass der client und server mit Puffern hantieren. Wenn man davon abweichen will fängt man sich nur Ärger ein. Nvidia wollte EGLStreams einführen. Dort nutzen Client und Server handles auf einen Stream über den dann das redraw geregelt wird. Also wir nie ein einzelner Puffer per IPC von Client zu Server transportiert - das passiert auf Treiber Ebene. Das hat jede Menge Vorteile bei der Latenz beim Resourcenverbrauch - es spart IPC .. usw.
Im Mir Design sind EGLStreams nur MirRenderSurfaces die an Fenstern attached werden koennen, die technischen Details werden durch die client und server Treiber Implementierungen geregelt. Dadurch muss kein WindowManager/Compositor angepasst werden und clients nutzen einfach die EGL. Das ist Software Design 1x1 - Verstecke deine Implementierungsdetails! Lass nicht zu dass das Protokoll das du verwendest in deiner API sichtbar wird.
- Mit Wayland kann jeder sein eigenes Protokoll bauen -
Jede Anwendung kommuniziert ausschließlich über eine eigene Verbindung, die sowohl sicher als auch robust gegen Angriffe ist.
Das war auch schon bei X11 so und bringt sicherheitstechnisch nichts neues. Sicherheitskonzepte sind in den Waylandprotkollen immer noch nicht umgesetzt. Copy & Paste ist so schrecklich wie schon bei X11. (Eine Lösung des C&P Problems gibt es bei Ubuntu Touch -> Content Hub)
• Unity 7 wird weiterentwickelt
• Unity 8 wird weiterentwickelt
• Mir und das dahinterstehende Konzept standen nie zur Disposition
• neben Wayland w i r d ein zweites Protokoll benötigt
• Wayland ist ein unsicherer, unausgereifter Versionswulst
Aha!
Hach schön, wie die Canonicals auf ihrem Schrott eingeschworen sind und sich nicht einmal davon trennen können, wenn das Projekt bereits auf dem Abstellgleis steht!
Erinnert mich irgendwie an Apple Jünger ...
Aber wir werden ja sehen, wie sehr die Welt auf Mir gewartet hat und welche Distributionen ohne Mir nicht zurecht kommen werden?
Meine Prognose: Keine außer Canonical und deren Ableger.
Also ändert sich im Prinzip nicht viel zum Ist-Zustand, alle anderen Distributionen machen einen großen Bogen um Canonical Technologie.
Whoa! Was hat das so lange gedauert bis die typischen "Alles-von-Canonical-is-schlecht"-Fraktion ihren Senf abgibt. :-O Was ist los? Zu irrationaler Lebensstil, um konsequent den eigenen irrationalen Hass zu pflegen?
"Alles-von-Canonical-is-schlecht"
Hmm, warum um alles in der Welt wird dann Ubuntu 18.10 ebenfalls wieder mit Gnome (Version 3.30) gebaut?
Angeblich werden ja Unitiy 7 und Unity 8 noch immer weiterenwickelt.