staging.inyokaproject.org

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"? 😀

@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

@2: Kenst du auch die Formel für RHEL?

Ü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.

@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.

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.

Ich meinte es wird mir zu viel Geschraubt an den Display Server.

@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.

@6: Weil es eben nicht so rund läuft, wie es für dich aussieht. X muss einfach ersetzt werden.

@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.

@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...

@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.

@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.)

@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

@13 http://blogs.gnome.org/bolsh/2011/03/07/has-gnome-rejected-canonical-help/

@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.