Neues von Wayland

Nicht nur die Entwicklung von Canonicals eigenem Display-Server Mir ist in vollem Gange. Auch das „Konkurrenzprodukt“ Wayland erschien diese Woche in einer neuen Version und bringt zahlreiche neue Funktionen mit.

Wayland 1.2 freigegeben¶

Wayland-Logo

Der Display-Server Wayland 🇬🇧, der diese Woche in Version 1.2 erschienen ist, bringt erstmals eine stabile Programmierschnittstelle (API) mit. Das heißt, wer die Funktionen von Wayland nutzt (wie z.B. den Referenz-Compositor Weston), kann sein Programm auch mit späteren Wayland-Versionen noch verwenden.

Zu den weiteren Neuerungen 🇬🇧 gehört eine Farbverwaltung, Unterstützung von HiDPI 🇬🇧, Rasperry-Pi-Unterstützung 🇬🇧, Multi-Seat-Implementierung und vieles mehr.

Sailfish OS mit Wayland¶

Neben FirefoxOS und Ubuntu Touch gibt es mit Sailfish OS einen weiteren Fisch im Smartphone-Meer. Sailfish OS wird von Jolla auf Basis von MeeGo bzw. Mer 🇬🇧 entwickelt.

Bereits seit Mai 2013 arbeitet Jollas Chef-Entwickler Carsten Munk an einer Bibliothek namens Libhybris, die es erlaubt Wayland auf Android zu nutzen. Nun bestätigte er 🇬🇧, dass Sailfish OS Wayland als Display-Server einsetzen wird. Die ersten Smartphones mit Sailfish OS soll es zum Ende des Jahres geben.

Live-System mit Wayland¶

Wer mit der neuen Wayland-Version herumspielen will, kann sich die neueste Version von Rebecca Black OS 🇬🇧 herunterladen und auf eine CD, eine DVD oder einen USB-Stick spielen. Das 32-Bit-System enthält neben Wayland 1.2 auch die Wayland-Anpassungen für GTK3, Qt5 und SDL, um so die neuen Funktionen des Display-Servers testen zu können.

Hintergrundwissen¶

Wayland ist ein Display-Server, der prinzipiell für die Grafikausgabe zuständig ist. Er wird von vielen Entwicklern als Nachfolger des X-Servers, der nach zwei Jahrzehnten in die Jahre gekommen ist, angesehen. Dementsprechend arbeiten viele bekannte Kernel- und X.org-Entwickler an dem Projekt.

Mit Mir (siehe Ikhaya-Artikel) hat Canonical nach dem Start der Wayland-Entwicklung einen eigenen Display-Server angekündigt, der sich ebenfalls noch in der Entwicklung befindet. Viele Entwickler haben sich aber bisher für Wayland bzw. gegen Mir 🇬🇧 ausgesprochen.

Links¶

Veröffentlicht von Dee | 17. Juli 2013 06:50 | Kategorie: Linux und Open Source | # Fehler im Artikel melden

Kerlbürste_Suessholz	1 17. Juli 2013 11:50 Ich frage mich gerade, wie lange ich als Debian-stable-Benutzer warten muss, bis ich den Austausch des Displayservers erlebe 😲 Oder sollte ich eher fragen "ob"? 😀
Das_Auge	2 17. Juli 2013 18:01 @1: Die Formel zum errechnen, wie lange das dauert, lautet: Zeit-bis-alle-X-Features-in-Wayland-vorhanden-sind + 3 Jahre = Debian Stable mit Wayland
ingo2	3 17. Juli 2013 19:50 @2: Kenst du auch die Formel für RHEL?
Tids	4 18. Juli 2013 07:00 Übrigens setzt canonicals mir auch auf die libhybris auf. Weshalb sich das nicht viel nehmen dürfte, ob Wayland oder Mir. Ein Punkt mehr der mir den Sinn von Mir verschleiert.
basti171	5 18. Juli 2013 08:05 @4 ich schau öfter mal die wöchentlichen developer q&a. zusammengefasst würde ich das so sehen (warum mir und nicht wayland): - unabhängiger von red hat und intel zu sein (die hauptsächlich hinter wayland stehen) - basiert viel stärker auf EGL als wayland - schnellerer entwicklungsprozess - bessere und automatische tests generell ist mir jetzt kein wirklich wichtiges projekt. man sollte aber bedenken, dass intel (reine open source treiber) und red hat (null interesse am endkunden) andere interessen haben könnten als canonical und nvidia/amd. außerdem ist wayland noch weit weg vom release. was ist mit weston? wird das weggeworfen? auch sollte die api mit version 1.0 schon fest sein. jetzt ist sie es angeblich mit 1.2. außerdem ist nicht ausgeschlossen, dass wayland auch in ubuntu einzug erhält.
DPITTI	6 18. Juli 2013 09:22 Alles wird irgendwie Geschraubt an den Display Servern. Irgendwann haut Überhaupt nix mehr hin warum.Warum bleibt man nicht bei Gewohnten was auch laufen tut das Verstehe ich nicht.
DPITTI	7 18. Juli 2013 09:23 Ich meinte es wird mir zu viel Geschraubt an den Display Server.
diwolf	8 18. Juli 2013 12:34 @7 Ich denke wayland war aus diesem Grund immer schon eine technische Tüftelei, ohne dass man konkret dachte es sofort einsetzen zu müssen/wollen. Man könnte ja irgendwann umstellen. Aber solange eben X gut lief/läuft war wayland eben nicht mehr als tüfteln auf hohem Niveau. Typisch Linux halt. Geändert hat das ganze eigentlich die Generation Handy/iphone/Tablet. Wenn man hier die Konvergenz mit dem PC haben will, geht das mit X eben nicht mehr. Und auch nur deswegen baut Ubuntu mit MIR etwas eigenes. Um hier die Kontrolle und den Fokus auf dem Konsumenten zu behalten. Und das ist auch logisch und richtig. Denn der Fokus bei wayland liegt auf Desktopebene und beim professionellen Linuxuser Umfeld, das auch mal im Terminal etwas schreiben mag. Der Fokus bei ubuntu liegt auf Handy/Tablet/PC, bei den Konsumenten, die einfach nur etwas anschalten wollen.
ChemicalBrother Ehemaliger	9 18. Juli 2013 12:35 @6: Weil es eben nicht so rund läuft, wie es für dich aussieht. X muss einfach ersetzt werden.
Ximion	10 18. Juli 2013 12:47 @5: Das Märchen, dass RedHat die Entwicklung kontrolliert (wo kommt das eigentlich her?) ist eher Unsinn. Das Projekt ist offen für alle, und jeder kann Änderungen Beitragen und die Richtung des Projektes definieren. Christian hat Wayland ja auch nie im Auftrag der Firma (damal RedHat) entwickelt, sondern als eigenes Freizeitprojekt (jetzt hat Intel natürlich interesse daran, es voran zu treiben). Das Client-API (das, womit die Toolkits zeichnen) war mit 1.0 stabil, das Compositor-API (= wichtig für Weston, KWin, Mutter, ...) ist jetzt ebenfalls stabil. Das mit EGL ist Unsinn, beide Projekte setzen auf EGL aus technischen Gründen, "echtes" GL wird aber in beiden Projekten kommen (ich glaube, für Wayland ist das schon fertig...). Und Open-Source treiber werden von Mir und Wayland benötigt, da nur diese momentan moderne Kernel-Features unterstützen, was zwingende Voraussetzung ist. Sobald die proprietären Treiber das auch tun, sollten diese sogar mit Waylsnd und Mir laufen.
basti171	11 18. Juli 2013 19:03 @10 toll die werden dann nur nicht angenommen wenn die red hat mitarbeiter dagegen stimmen. glaubst du Christian hat wayland in seiner freizeit entwickelt? dann guck dir nur mal allein die commits an...
TraumFlug	12 18. Juli 2013 19:34 @6 informier' dich mal zum thema x-server, x.org, xfree86...wenn da mal nicht jahrzehntelang permanent geschraubt und gedreht wurde, und immer mal wieder kleine Flicken eingebaut wurden, um moderneren Anforderungen halbwegs zu genügen... Der Sinn (von mir und wayland) ist dieses unübersichtliche Ding, mit Ballast von vor Jahrzehnten, von Grund auf sauber neu zu schaffen, mit dem heutigen Stand der Technik (Hardware wie Programmiertechnik) im Blick (und eben auch Smartphones/Tablets mit kleinfaktorprozessoren...). Als Endanwender merkt man das nicht so zwingend (X läuft halt...), aber wer sich mit der Technik beschäftigt wird eventuell die Vorzüge erkennen. Und X.org stirbt ja nicht sofort komplett.
Ximion	13 19. Juli 2013 03:06 @11: Solange patches mit den Zielen des Projektes übereinstimmen, und offen entwickelt werden (= ich zeige auch mal zwischenstufen und frage nach Feedback von anderen Entwicklern) werden diese eigentlich immer aufgenommen. Beispiel sind z.B. einige patches des komplett unabhängigen Entwicklers Jason Ekstrand gegen das Wayland-Protokoll. Christian hat Wayland in seiner Freizeit entwickelt, als er noch bei Red Hat war. Wayland war dabei erst nur ein Hobbyprojekt und Tech-Demo, dass es mal so viel Unterstützung finden würde (und inzwischen nahezu alle X-Entwickler Wayland zuarbeiten) hat er damals wohl nicht geahnt. Inzwischen arbeitet er für Intel, und vor allem für Intel an Wayland, was aber nichts an den Ursprüngen des Projektes ändert. Ich habe echt keine Ahnung, woher dieser Mythos, RedHat würde Patches zurückweisen, kommt (ich vermute mal FUD von MS, habe aber sowas schon vor seinem Blogpost gelesen). Ich selber kann bei diversen Projekten, die von RedHat-Entwicklern gestartet wurden, quasi beliebig Patches von externen Entwicklern einpflegen und eigene Ideen einbauen - obwohl andere diese Projekte gestartet haben (das ändert natürlich nichts daran, dass trotzdem noch alles abgestimmt und reviewed wird). Auch GNOME3 mit der Standard-Shell war ein Ergebnis der Arbeit von GNOME-Entwicklern, und für RH eher suboptimal (was vermutlich auch mit ein Grund für die Entwicklung des optionalen Classig-Mode ist). Dass RH viele Entwickler, die vorher schon in der FLOSS-Community aktiv waren einstellt, ist natürlich wahr, aber genau diese Strategie ist IMHO sehr sinnvoll und nicht verwerflich (mit dem Projektmaintainer holt man sich schließlich das know-how direkt in die Firma, und kann seinen Kunden optimalen Support anbieten - und an den Projekten ändert sich nichts). Projekte, denen wirklich von RedHat die Richtung vorgegeben wird, werden gekennzeichnet, das wären z.B. JBoss/WildFly, SPICE, OpenShift, ... Sag' mir, welcher offen entwickelte Patch von einem RH-Entwickler in einem nicht-RH-Projekt zurückgewiesen wurde 😉 (Btw, der RH-Entwickler, der (ebenfalls als Freizeitaktivität) den Farbmanagement-Code in Wayland/Weston 1.2 eingebaut hat, wusste selber lange nicht, ob seine Patches gut genug für den Hauptzweig sind und angenommen werden würden. Wurden sie dann aber doch, mit Modifikationen. - Es wird eigentlich niemals irgendein Code in Projekten "einfach so" durchgewunken, nur weil der Autor für eine Firma oder sogar die selbe Firma arbeitet.)
basti171	14 19. Juli 2013 07:14 @13 das mit gnome ist doch ein witz. die sind ne geschlossene community und ziehen ihren stiefel durch. sei es globale menüleisten oder indicators, was denen nicht in den kram passt wird einfach ignoriert und abgeleht. gearde gnome ist ein beispiel wo eben nichts "gemeinschaftlich" gelöst wird. bei mint mit Cinnamon genauso. komisch oder? http://www.golem.de/news/gnome-selbstkritik-und-plaene-fuer-gnome-4-1207-93525.html "Es gebe allerdings auch weitere Kritikpunkte und womöglich Anlass zur Sorge. Denn Gnome soll unter einem Benutzer- und Entwicklerschwund leiden. Außerdem werden Themen wie eine zu große Fragmentierung, Entwicklermangel und zu wenig Engagement durch Firmen diskutiert. Kritisiert wird vor allem, dass ein Großteil der Gnome-Entwickler bei Red Hat arbeitet. Dadurch soll das Projekt zu sehr von einem Unternehmen abhängig sein." kann man natürlich wieder leugnen. canonical hat unity nur gestartet, eben weil red hat so viel einfluß auf gnome hat. das ist alles auch gar nicht schlimm. man sollte nur nicht die realität ignorieren. ist bei vielen "offenen" projekten so. ibm bei eclipse, sun bei java, sun bei netbeans, und und. Ist auch gar nichts schlimmes dabei. nur sollte man nicht einem alles in die schuhe schieben, während man red hat einen freifahrtsschein gibt
basti171	15 19. Juli 2013 07:19 @13 http://blogs.gnome.org/bolsh/2011/03/07/has-gnome-rejected-canonical-help/
Ximion	16 19. Juli 2013 14:25 @15: Dass CLA-Zeug ohne abtimmung nicht aufgenommen wird, ist eigentlich klar ^^ - Die Indicator-Sache ist wirklich etwas unglücklich gewesen, wäre Canonical damit sofort gekommen, hätte es keine Probleme gegeben. "I would love to point to other instances of work which has been proposed upstream from Canonical and which has been rejected, but my (admittedly, brief) search has not turned up much useful stuff. I can’t find any online reference to displeasure with the GNOME Shell vision, or proposals of alternatives, nor can I find situations of “Paper Cut” patches being rejected because they were from Canonical or Ubuntu." @14: Es gibt einen Design-Plan, an den sich logischerweise jeder halten sollte, sowie jeweils eigene Pläne der Modulmaintainer. Diskutieren und ändern kann man aber alles. Ich bin kein GNOME-Foundation Mitglied (eigentlich KDE und Freedesktop-Entwickler), aber für mich war es absolut kein Aufwand, patches in GNOME einzubringen und Commit-Zugang zu Modulen zu bekommen. Alles geht. Unity wurde IMO eher entwickelt, weil Canonical darüber die volle Kontrolle hat. Bei GNOME müssen sich immer alle Abstimmen (klar gibt's auch welche, die mehr zu sagen haben, also äquivalente Positionen haben wie Aaron Seigo bei KDE), also RH-Entwickler, SUSE-Entwickler, Collabora, Igalia, Freie Entwickler etc. Bei Unity hingegen ist das gesamte Projekt vollständig unter Canonicals Kontrolle, eine Abstimmung mit anderen externen Entwicklern ist nicht zwingend nötig, ebensowenig wie mit anderen Distributoren. Was natürlich cür Canonical Vorteile hat. Und Nebenbei, der Einfluss von Firmen wird in den meisten OSS-Projekten, also auch in GNOME, sehr kritisch beleuchtet. Gibt immer wieder mal Diskussionen dazu.