Martin's Blog » ubuntuusers

Was passierte im Fenstermanager für KDE Plasma Workspaces 4.8?

Martin Gräßlin — Mon, 26 Dec 2011 19:00:51 +0000

Es ist schon ziemlich lange her, dass ich hier mal auf Deutsch gebloggt habe. Nun nehme ich unser bevorstehende Release der KDE Plasma Workspaces 4.8 als Anlass um mal darüber zu berichten, was sich so im Bereich des Fenstermanagers und Compositors seit 4.7, welches in Kubuntu 11.10 zum Einsatz kommt, so getan hat.

Unser nächstes Release wird Bestandteil der LTS Version, d.h. sehr viele Kubuntu und hoffentlich auch Ubuntu Nutzer werden lange daran Freude haben.

In 4.8 sehen wir im Fenstermanager nicht besonders viele neue Funktionen. Wir haben hauptsächlich “unter der Haube” gearbeitet. An mehreren Stellen haben wir die Performance verbessert. Das Vergrößern/Verkleinern von Fenstern läuft nun dank einer verbesserten Synchronisierung mit dem Zeichnen der Fenster flüssiger. Wer es ganz flüssig haben will, sollte weiterhin den Effekt dafür verwenden.

Unser Verwischen (Blur) Effekt hat besonders viel Liebe erhalten. Alle Zwischenergebnisse werden nun im Speicher vorgehalten und nicht in jedem Frame neu berechnet. Das hat enorme Auswirkungen auf die Performance. Dank dieser Verbesserung (und einigen anderen kleinen Verbesserungen im Compositor dafür) konnte ich problemlos auf einer etwas älteren Ati X300 einen Fensterstil einsetzen, bei dem alle Fenster mit verwischtem Hintergrund gezeichnet werden. Auch können wir nun den Hintergrund von herausfahrenden Popups selbst während der Animation verwischen. Bisher hatten wir darauf verzichtet um die Performance zu schonen.

Weitere Performanceverbesserungen wurden unserem Effektsystem spendiert. Die Effekte können nun sagen ob sie gerade aktiv oder inaktiv sind. Dadurch werden sie beim Rendern eines Frames nicht berücksichtigt. Dies führt zu einer besseren Skalierung: die Anzahl geladener Effekte und offener Fenster hat keine Auswirkung mehr auf die Performance, denn in der Regel sind nur ein oder zwei Effekte gleichzeitig aktiv.

Eine sehr interessante Entwicklung ist der Einsatz von QtQuick. Diese Technologie haben wir im Fensterwechsler (Alt+Tab) eingebaut und können dadurch sehr einfach verschiedenste Layouts unterstützen. Hier ermöglichen wir unseren Nutzer eigene Layouts zu erstellen und zu verwenden. In der nächsten Version wollen wir das weiter ausbauen um auch Get Hot New Stuff zu integrieren um weitere Layouts aus dem Internet herunterladen zu können.

Generell sehen wir in QtQuick sehr viel Potential und wollen dies in 4.9 verstärkt einsetzen um den Nutzern somit ein Werkzeug in die Hand zu geben um einfacher seinen Fenstermanager zu gestalten und die eigenen Ideen in die Entwicklung einzubringen ohne C++ beherrschen zu müssen oder KDE Plasma überhaupt bauen zu müssen.

Rückblickend bin ich mit der Entwicklung in 2011 sehr zufrieden und freue mich auf das nächste Jahr um die Früchte zu ernten von der Arbeit, die wir dieses Jahr begonnen haben. Ich kann nur jedem Nutzer empfehlen den KDE Plasma Fenstermanager in Version 4.8 auszuprobieren und mal neben Unity oder GNOME Shell zu versuchen. Dank der Flexibilität unserer Desktop Shell Plasma können Nutzer auch ohne großen Aufwand ihre bevorzugte Desktop Shell – sei es Unity oder GNOME Shell – nachbauen.

Aber damit 4.8 ein richtig tolles Release wird, sind wir auf eure Mithilfe angewiesen. Aktuell ist der Release Candidate 1 veröffentlicht und wir brauchen noch mehr Tester. Von Kubuntu gibt es PPAs um die aktuelle Entwicklerversion zu bekommen. Wenn ihr ganz sicher gehen wollt, könnt ihr auch Neon verwenden, das die Pakete getrennt installiert. Testet, findet die Fehler, meldet sie, damit wir Entwickler sie noch vor dem Release beheben können.

Und wenn ihr nicht wisst, was ihr mit dem ganzen Geld machen sollt, dass ihr zu Weihnachten geschenkt bekommen habt, so empfehle ich euch eine unterstützende Mitgliedschaft im KDE e.V. (Ich bin auch zahlendes Mitglied.) Dies ist ganz wichtig, denn mit euren Spenden werden die Entwicklersprints finanziert, welche wir Entwickler benötigen um die zukünftige Entwicklung zu koordinieren. Vielen Dank!

Wie sicher ist WebGL wirklich?

Martin Gräßlin — Sat, 18 Jun 2011 10:19:15 +0000

WebGL erlaubt es OpenGL in Webseiten einzubetten, also 3D Grafiken auf der lokalen Hardware direkt zu rendern. WebGL baut auf der API von OpenGL ES 2.0 auf, welches selbst eine Untermenge (und Teilweise Übermenge) von OpenGL 2 ist. Eine Webseite, die WebGL einbindet, funktioniert somit prinzipiell auf aller Hardware die entweder OpenGL 2 oder OpenGL ES 2.0 unterstützt. Das ist so ziemlich jedes moderne Smartphone und auch jede Grafikkarte der letzten Jahre.

Persönlich betrachte ich WebGL als den größten Durchbruch im Web Bereich der letzten Jahre und als viel wichtiger als HTML 5. WebGL hat das Potential eine neue Ära einzuleiten. Vor allem im Bereich der Web basierten Spiele sehe ich ein unglaubliches Potential für diese Technologie. Aktuell wird für vieles immer noch Flash verwendet, was größtenteils über die CPU ineffizient rendert. Aber auch viele Webdienste wie z.B. Kartendienste können von 3D Beschleunigung profitieren.

OpenGL ist der offene Industriestandard für 3D Grafik und steht in direkter Konkurrenz zu einer proprietären API, welche nur von einem Softwarehersteller kontrolliert wird. Mit OpenGL laufen Anwendungen auf allen verfügbaren PC Plattformen, mit OpenGL ES 2.0 ist der boomende Markt der Smartphones und Tablets abgedeckt, auf dem es noch keinen konkurrierenden Standard gibt und mit WebGL betritt OpenGL erneut einen Bereich in dem es noch keinen vergleichbaren Standard gibt. Es ist erfreulich zu sehen, dass der offene Standard hier vor der Konkurrenz ist und die Technologie vorantreibt.

Sollte WebGL sich als bevorzugter Vermarktungsweg für moderne Spiele durchsetzen, wäre dies ein schwerer Schlag für die konkurrierende API und den Webbrowser des selben Herstellers, der WebGLnicht unterstützt. OpenGL Anwendungen würden ohne jegliche Anpassung auf allen verfügbaren Plattformen über den Webbrowser laufen, sämtlicher Portierungsaufwand entfällt komplett. Zusätzlich gibt es dem Hersteller der Anwendung ein bewehrtes Distributionsmedium (das Web) in die Hand.

Zuletzt hörte man einiges an Kritik bezüglich der Sicherheit von WebGL (z.B. bei fefe), vor allem möchte der Konkurrent von OpenGL, WebGL nicht in seinen Webbrowser einbauen aus Sicherheitsgründen. Die Sicherheitsproblematik läuft zusammen auf die Tatsache, dass Anwendungen aus dem Web Zugriff auf die lokale Hardware bekommen und nativen Code ausführen können. Zusätzlich gibt es auch (noch) keine Sandbox um den Code abzuschotten und da auf die Hardware zugegriffen werden kann, wird auch einiges des Codes im Kernelmode ausgeführt.

Das ist soweit natürlich alles korrekt, nur macht es die Technologie WebGL grundsätzlich nicht zu einem Sicherheitsproblem. OpenGL für sich ist eigentlich eine riesige Sandbox. OpenGL ist ein Zustandsautomat bei dem die eigentliche API nur dazu da ist den Zustand zu setzen. Also zum Beispiel eine Textur zu laden und anzugeben, dass die nächsten Zeichenbefehle diese Textur verwenden sollen. Das eigentliche Zeichnen der Geometrie erfolgt mit sogenannten Shadern. Es gibt dabei einen Vertexshader zum Umwandeln von Vertices im Anwendungskoordinatensystem nach Clipcoordinaten und den Fragmentshader um jedes vom Vertexshader bestimmte Fragment zu zeichnen. OpenGL verwendet zur Programmierung dieser zwei Shader Zustände eine eigene Programmiersprache namens OpenGL Shading Language (GLSL).

GLSL ist eine sehr domain spezifische Sprache speziell für die Anforderungen der 3D Grafikprogrammierung. Der Vertexshader bekommt als Eingabewerte Attribute pro Vertex und als Ausgabewerte liefert er variierende Werte, die an den Fragmentshader weitergegeben werden und als Eingabeparameter verwendet werden. Der Fragmentshader produziert nun einen Farbwert. Zusätzlich können beide Shader auf gemeinsamen Speicher zugreifen: auf den OpenGL Zustand über sogenannte “uniform” Werte und auf Texturen.

Die Shader in GLSL werden vom OpenGL Treiber in hardwarespezifischen Assemblercode kompiliert. Der Compiler sollte dabei sicherstellen, dass der Code nichts machen kann, was OpenGL nicht erlaubt, also z.B. auf Speicher außerhalb des Kontexts zuzugreifen. Jede Textur und auch jeder Shader wird nämlich in einem Kontext erstellt und ein Objekt darf nur auf Objekte des selben Kontexts zugreifen. Wenn der Shader vom Treiber nicht kompiliert werden kann, so wird ein Fehler zurückgeliefert auf den der Anwendungscode reagieren muss.

Die Technologie WebGL ist also selbst die Sandbox, die angeblich nicht existiert. Ein Shader kann nur graphikspezifischen Code ausführen und es wäre mir auch noch kein Fall bekannt, bei dem GPU Code auf die CPU “ausbrechen” könnte. Die einzige verbleibende Gefahr wäre somit das setzen der Zustände um den Shader auszuführen. Dabei besteht eigentlich auch kein Problem, denn OpenGL ist sehr fehlertolerant und bei einem fehlerhaften Ansprechen der API wird ein GL_ERROR zurückgeliefert was im schlimmsten Fall zu Darstellungsfehlern führt. Die OpenGL API ist somit auch Bestandteil der Sandbox.

Wie wir sehen bietet die Technologie WebGL außreichend Sicherheit. Mittels der Technologie ist es nicht möglich Schadprogramme auf den Client zu bekommen. Die Vorwürfe gegenüber der Technologie sind daher einfach falsch.

Anders sieht es mit den Implementierungen aus. In der Theorie sollte OpenGL sicher sein, jedoch kann ich aus eigener Erfahrung sagen, dass dies nicht der Fall ist. Alle Treiber (egal ob offen oder proprietär) haben Fehler und können die Anwendung zum Absturz bringen, bei legalen und illegalen OpenGL Befehlssequenzen. Somit ist ein Angriffspotential denkbar: ist man in der Lage über die richtigen Befehle in WebGL den Treiber zum Absturz zu bekommen, kann man im schlimmsten Fall Code auf der CPU ausführen. Dies ist ein reales Angriffsszenario, dessen sich die Browserhersteller bewusst sind. So hatte ein Mozilla Entwickler vor der Veröffentlichung von Firefox 4 z.B. auf der KWin Mailingliste nach den Erfahrungen zur Stabilität insbesondere der freien Treiber nachgefragt.

Von dem theorethischen Angriffsszcnario zu einem Exploit ist es dennoch ein weiter und meiner Meinung nach sehr unwahrscheinlicher Weg. Zum einen ist es schwer den OpenGL Treiber gezielt zum Absturz zu bringen, zum anderen diesen Absturz zum Angriff auszunutzen. Abstürze lassen sich nach der Erfahrung mit KWin meistens nur in einer bestimmten Kombination von OpenGL Befehlen, Treiberversion und Hardware erreichen. Ein Angreifer müsste also den Angriff speziell auf Hardware und Treiber zurechtschneiden. Natürlich wäre solch ein Fall dann eine Möglichkeit den Browser remote abstürzen zu lassen, dies ist natürlich schon einmal sehr schlecht, lässt sich aber von Browserherstellerseite sehr leicht beheben indem WebGL Kontexte in einen eigenen Prozess ausgelagert werden.

Die viel größere Schwierigkeit dürfte sein den Crash zum Angriff auszunutzen. Außer GLSL (was ja nicht auf der CPU sondern GPU ausgeführt wird) gibt es keine Codebestandteile, die direkt ausgeführt werden. Die WebGL API zum Setzen des OpenGL Zustands verwendet JavaScript und sollte somit vom restlichen System abgeschottet sein. Die API selbst erlaubt auch ausschließlich nur das Setzen der Zustände. Die einizige Möglichkeit größere Speichermengen über Buffer anzusprechen (um zum Beispiel Angriffscode abzulegen) ist das Laden von Texturen was jedoch in der WebGL API im Vergleich zur OpenGL C-API abgesichert wurde.

Falls es mittels Texturen und OpenGL API möglich ist einen Treiber so zum Absturz zu bekommen, dass Code ausgeführt werden kann, so ist das ein grundsätzliches Problem was nichts mit der Technologie WebGL zu tun hat. Moderne Webbrowser verwenden OpenGL auch zum Rendern der Canvas womit es denkbar ist, dass durch das einfache Einbinden desselben gefährlichen Bildes der Browser zum Absturz gebracht werden kann und der Schadcode ausgeführt werden kann.

Wie wir sehen ist der Vorwurf gegenüber der Technologie WebGL nicht sicher zu sein, schlicht falsch. Genaugenommen betrifft es nur sich fehlverhaltende Implementierungen deren Schwachstellen generell ausgenutzt werden können, egal ob es sich um WebGL, hardwarebeschleunigtes Rendern der HTML Canvas oder harwarebeschleunigtes Flash oder Silverlight handelt. WebGL ist hier im Vergleich zu anderen Lösungen wie hardwarebeschleunigtes Flash sogar besser, da es sich abschotten lassen kann.

Ich möchte hier nicht sagen, dass der Einsatz von WebGL ungefährlich ist. Sicherlich besteht durch die Instabilität der OpenGL Implementierungen und der recht neue Einsatz in Webbrowsern ein Gefährdung. Jedoch betrifft diese alle Technologien, die auf OpenGL (oder auch Direct3D) zugreifen. Das Argument des Konkurrenzherstellers klingt daher für mich als vorgeschoben und nach FUD um der Konkurrenz zu schaden und die konkurrierende API nicht im eigenen Webbrowser einsetzen zu müssen.

=-=-=-=-=
Powered by Blogilo

Neues Spielzeug

Martin Gräßlin — Mon, 13 Jun 2011 09:32:33 +0000

Es sollte ja kein Geheimnis mehr sein, dass der X Server mitlerweile angezählt ist und mit Wayland der potentielle Nachfolger bereits in den Startlöchern steht. Auch wenn es noch lange dauern wird bis wir X endlich in den Ruhestand schicken können, ist für mich bereits der Zeitpunkt gekommen, mich etwas intensiver mit der neuen Technologie zu beschäftigen. Für KWin ist es wichtig früh Wayland Anwendungen zu integrieren, da man unter KDE Plasma Wayland nicht benutzen kann, wenn KWin Wayland nicht unterstützt.

Letzte Woche habe ich angefangen KWin um ein Wayland Backend zu erweitern. Glücklicherweise ist das Wayland Server Protokol extrem einfach gehalten wodurch man sehr schnell erste Ergebnisse erreichen kann:

Dieser Screenshot ist sehr interessant. Das Terminal Fenster ist ein Wayland Client, die Fensterdekoration ist jedoch ein klassisches X11 Fenster. Wir kombinieren hier also beide Technologien. Dies zeigt sehr schön die Strategie, die wir bei KDE Plasma einschlagen: schrittweise Unterstützung für Wayland Fenster implementieren ohne unseren bestehenden Desktop zu zerstören. Erst wenn wir volle Unterstützung implementiert haben, werden wir X11 verlassen und auf Wayland wechseln. Bis dorthin werden wir eine Strategie fahren bei der Wayland Clients unter X11 verwaltet und gerendert werden.

Auch wenn der Screenshot schon nach sehr viel aussieht, darf man sich nicht täuschen lassen. Bis wir auf Wayland sind, ist noch ein weiter Weg. Viel muss erst noch implementiert werden. Für mich ist das gerade extrem spannend und ich fühle mich wie ein kleines Kind mit einem neuen Spielzeug. Schritt für Schritt kann ich nun die Fenster benutzbar machen. Dabei lerne ich auch richtig viel noch über KWin Interna. Mit dem X11 Fenstermanagement musste ich mich eigentlich nie beschäftigen, da es vollständig und korrekt implementiert ist. Nun bin ich dabei Fenstermanagement für Wayland nachzuimplementieren.

Richtig toll ist wie viel einfach so ohne jegliche Anpassung funktioniert. Vor allem unser Effekt Framework interessiert sich überhaupt nicht dafür ob ein Fenster nun X11 oder Wayland ist. Es wird einfach integriert und angezeigt. Auch wie man im Screenshot sehen kann, ist es den Fensterdekorationen egal ob sie ein X oder Wayland Fenster dekorieren.

Experimentierfreudige Nutzer können das ganze auch schon testen (auch wenn es extrem langweilig ist) wenn sie selbst aus den Quellen bauen. Bis das ganze in Distributionen verfügbar wird, wird noch einiges an Zeit vergehen. Da wir ja in Feature Freeze für 4.7 gerade sind, werden all Änderungen erst in 4.8 erscheinen und auch dann ist es fraglich ob Distributionen mit den entsprechenden Build Flags bauen werden (wer hat denn schon Wayland in den Repos?). Bei OpenSUSE wird es wahrscheinlich in den Factory Builds verfügbar sein, sobald die Änderungen in den master branch einfließen. Bei Kubuntus Project Neon ist das auch denkbar, jedoch könnte die Wayland und Mesa 7.11 Abhängigkeit das ganze erschweren.

=-=-=-=-=
Powered by Blogilo

Bye, bye KDE 4?

Martin Gräßlin — Tue, 10 May 2011 13:47:21 +0000

Wer die OpenSource Medien gestern oder heute verfolgt hat, dürfte ja schon mitbekommen haben, dass Nokia Qt 5 für nächstes Jahr angekündigt hat. Das hat natürlich auch Auswirkungen auf KDE. Um die Neuerungen von Qt 5 verwenden zu können, müssen wir gegen die neue Version linken, wodurch unsere KDE Platform eine binär inkompatible Änderung erhält. Die Folge davon ist recht logisch: KDE Plattform 5.

Für mich ist die Ankündigung von Qt 5 und dem daraus zwangsläufig folgendem KDE Plattform 5 keine Neuigkeit, besonders mit einem KDE 5 rechne ich eigentlich seit der Planung des “Plattform 11″ Sprint für die zukünftige Entwicklung der KDE Plattform. Dass nun Qt 5 kommt, ist da sehr passend. Sehr erfreulich ist auch das nun offenere Entwicklungsmodell von Qt sowie einem Qt Contributors Summit direkt nach Plattform 11. Auch bei Plasma haben wir bereits mit den Planungen begonnen mit libplasma2 und im Compositor und Window Manager planen und überarbeiten wir auch unsere APIs. Hier ist natürlich ein sich ankündigender ABI Bruch eine schöne Sache, da man besser planen kann und nicht den Bruch in der Laufzeit der KDE Plattform 4 bringen wird.

Ich persönlich freue mich auf diese neue Entwicklung, da ich bei der Entwicklung zu KDE 4 noch nicht dabei war und das eine sehr interessante Aufgabe ist. Das Designen einer guten API betrachte ich als große Kunst und eine der schönsten Disziplinen der Informatik. Daher freue ich mich darauf die Dekorations-API den modernen Anforderungen anzupassen.

Nun habe ich die ganze Zeit sehr bewusst von der “KDE Plattform” gesprochen. Die KDE-libs werden ihre Versionsnummer erhöhen, für Anwendungen und die Plasma Workspaces steht das aber noch nicht fest. Nach aktuellem (noch nicht wirklich existierendem) Planungsstand soll Qt 5 hauptsächlich neu kompilieren sein und natürlich wäre das auch für die KDE-Libs eine sehr schöne Lösung. Anwendungen und Plasma werden also einfach weiter funktionieren. Wir sind sehr zufrieden mit unserem aktuellen Stand und sehen keinen Bedarf erneut den Desktop zu brechen. Sehr schön hat auch Aaron diese Gedanken zusammengefasst. Ob das ganze dann KDE 5 heißt, weiterhin KDE 4 heißt oder einen ganz anderen Namen bekommt, ist aktuell noch völlig offen und noch nicht entschieden oder diskutiert.

Für mich ist es bei der Entwicklung – gerade auch in Hinblick auf Wayland – oberste Priorität den Desktop nicht zu brechen. Auch wenn es sich zeitlich anbieten würde mit KDE 5 auf Wayland zu setzen, werde ich solche Pläne nicht verfolgen. X11 wird für uns zumindest in nächster Zeit weiterhin eine wichtige Plattform sein.

P.S.: alle Kommentare wie fürchterlich KDE 4.0 war und dass sich sowas nie wieder wiederholen darf, werden konsequent moderiert. Das wissen wir selbst gut genug.

=-=-=-=-=
Powered by Blogilo

Die Bugtracker Lüge

Martin Gräßlin — Sun, 01 May 2011 08:43:42 +0000

Über Jahre hinweg hat die freie Software Gemeinschaft gepredigt, dass freie Software proprietärer Software überlegen ist, da die Bugtracker offen sind. Jeder Nutzer kann sich an der Weiterentwicklung freier Software beteiligen und mithelfen sie zu verbessern indem er Fehlerberichte einsendet. Ja die Entwickler freier Software nehmen sogar Wünsche an und warten nur darauf alles zu implementieren, was ein Nutzer als Wunsch äußert.

Wie sieht aber die Realität heute aus? Ist ein freier Bugtracker eine Hilfe für freie Software? Holen sich Entwickler Inspiration aus den Wünschen der Anwender? Gibt es bei der Entwicklung überhaupt Überschneidungen zwischen den Vorstellungen der Nutzer und der Entwickler?

Ich kann natürlich nicht für die gesamte freie Software Gemeinschaft schreiben und beziehe mich jetzt im weiteren auf meine Community also den KDE Plasma Workspaces. Persönlich bin ich Maintainer des Plasma Compositors und Window Managers mit aktuell > 400 offenen Fehlermeldungen und > 300 offenen Wünschen. Wöchentlich erhaltet unsere Komponente etwa 20 neue Bugs. Bei den Plasma Desktop Shells sieht es noch schlimmer aus mit > 1200 offenen Fehlermeldungen und > 1000 offenen Wünschen. Alle KDE Software zusammen hat mehr als 24.000 offene Fehlermeldungen und mehr als 17.000 offene Wünsche bei einer Änderungsrate von etwa 500 neuen Fehlermeldungen pro Woche und 50 neuen Wünschen pro Woche.

Als ich vor ein paar Jahren mit KDE Entwicklung angefangen hatte, lag KDE noch deutlich unter 20.000 offenen Bugs. Man müsste also annehmen dass die Qualität unglaublich sinkt wenn man den Zahlen glauben schenken würde. Jeder, der die Entwicklung von KDE Software über die letzten Jahre verfolgt hat, wird mir zustimmen dass die Qualität unglaublich gestiegen ist und nicht gesunken ist.

Was ist also die Erklärung für die steigende Anzahl Meldungen? Ganz einfach: der Bugtracker vermüllt! Kaum einer der neu gemeldeten Fehler sind zu gebrauchen. Nutzer sind nicht in der Lage korrekt zu suchen und melden wieder und wieder die gleichen Fehlermeldungen. Selbst wenn unser Dialog anzeigt, dass es schon mehr als 20 identische Crashreports gibt, wird ein neuer aufgemacht. Anderen Crashreports fehlt dann eine Anleitung sie zu reproduzieren womit eine Behebung unmöglich ist. Andere sind für komplett veraltete Software, wie sie von den Distributionen ausgeliefert werden. Wieder andere melden den Fehler und reagieren nicht auf Rückfragen. Oftmals reicht es nicht einfach nur einen Fehler zu melden, man muss mit den Entwicklern zusammenarbeiten um den Fehler zu erkennen. Wirklich gute und nützliche Meldungen sind leider die Ausnahme.

Für die Entwickler ergibt sich daraus natürlich ein Problem: wie findet man den nützlichen Report in all dem Müll? Und wie kann man den Bugtracker zur Koordination einsetzen? Ein Tool zum Verwalten der Aufgaben ist extrem wichtig und kann wirklich hilfreich sein und ich wünschte mir, ich hätte eins. Nur unser KDE Bugtracker ist es nicht. Was hilft mir ein Tool bei dem ich mit den Nutzern diskutieren muss, dass ich ihren Fehler nicht als wichtig ansehe? Oder ein Tool in dem ich stundenlang erst mal suchen muss bis ich einen Report finde, der genügend Informationen enthält um ihn zu beheben? Natürlich überhaupt nicht. Ich gehe nicht in den Bugtracker um einen Fehler zu suchen an dem ich jetzt arbeite. Über die letzte Woche habe ich viele Fehler behoben – kaum einer davon war im Bugtracker vermerkt. Die Existenz der Fehler war mir jedoch bekannt. Mein Bugtracker ist mein Kopf. Und das menschliche Gedächtnis skaliert nur sehr eingeschränkt.

Und wie sieht es mit den Wünschen aus? Gehen Entwickler in die Liste und picken sich eins davon aus und implementieren es? Auch hier ist die Realität, dass ich die Wünsche als komplette Müllhalde betrachte. Ändere ich einen Report von Fehler auf Wunsch ist es gleichbedeutend wie “> /dev/null”. Es gibt keine Wünsche der Nutzer, die sich mit meinen Entwicklungszielen überschneiden. Wenn ein neues Feature einen Wunsch erfüllt, so ist das reiner Zufall und nicht darauf zurückzuführen, dass Nutzer es als Wunsch geäußert haben. Dies führt natürlich zu einer weiteren Vermüllung des Bugtrackers: Wünsche, die implementiert werden, werden nicht auf geschlossen gesetzt. Und dass ein Nutzer kommt und es nachträglich macht, ist leider auch die Ausnahme.

Kein einziger Wunsch der Nutzer deckt sich mit den Entwicklungszielen, die ich habe. Nirgends gibt es einen Wunsch “KWin mit OpenGL ES/EGL” oder “Aufspaltung in mehrere Bibliotheken” oder “Unterstützung von Wayland”. Ein Nutzer kann nicht wissen wohin ein Projekt der Größe sich entwickelt und was die Ziele sind. Da Nutzer jeden Bugreport lesen und schreiben können (muss ja offen sein!) ist für mich der Bugtracker zur Planung völlig nutzlos. Ich kann mir nicht meine eigenen Bugs aufmachen, die nur von meinem Entwicklerteam gelesen und bearbeiten werden.

Dass Nutzer der freien Software durch das Melden von Fehlern und Wünschen helfen, ist für mich die größte Lüge der freien Software. Kein Fehler gemeldet von einem Nutzer hilft ihr, wenn es ihn mal gibt, geht er in der Menge von Müll einfach unter. Meldungen von Nutzern binden nur sinnlos Ressourcen der Entwickler, so verschwende ich wöchentlich etwa eine Stunde darauf immer und immer wider den gleichen Treiber Crash als Duplikat zu markieren. Neben all den anderen Meldungen die ich sinnlos beantworte. Ich mache dies (noch) um zumindest die Möglichkeit zu waren irgendwann einmal den Bugtracker noch sinnvoll zu benutzen und die Vermüllung einzudämmen.

Freie Software braucht Qualitätssicherung und auch Bugtracker – so wie jedes andere Projekt auch. Ein Bugtracker, der für jeden offen ist, kann aber keine Lösung mehr sein, dafür ist freie Software zu populär und Nutzer sind Nutzer und keine potentiellen Entwickler und Informatikstudenten mehr.

=-=-=-=-=
Powered by Blogilo

KWin über den Verlauf der Zeit

Martin Gräßlin — Sat, 19 Mar 2011 11:26:44 +0000

Eine der kontroversesten Entwicklungen in KDE in den letzten Jahren war sicherlich das KDE 4.0 Release. Obwohl es klar als Entwickler Release bezeichnet wurde: "KDE 4.0.0 is our "will eat your children" release of KDE4, not the next release of KDE 3.5." (Aaron Seigo, Plasma Maintainer, am 04.01.2008 in talking bluntly), wurde es auch von Anwendern verwendet und nach dem Feedback was man damals gehört hat, waren sie damit nicht wirklich zufrieden. Vor allem Plasma in KDE 4.0 wurde (zu Recht) als unausgereift und nicht stabil bezeichnet. Selbst heute kann man auf heise oder pro-linux kaum einen Artikel zu KDE sehen ohne Hinweis auf das nicht ausgereifte Release von vor drei Jahren.

Immer wieder hieß es, dass KDE sich durch das Release selbst Schaden zugefügt hat und massiv Nutzer verloren hat. Solche Zahlen sind schwer zu erfassen, da es generell keine Statistiken zu den Anzahl Nutzern gibt. Von Entwickler Seite selbst wird das 4.0.0 Release als äußerst wichtig angesehen, alleine schon weil man in der Open Source Welt "Release Early, Release Often" folgt. Persönlich gehöre ich zu den Entwicklern (Hinweis: mein erster Patch für KWin war kurz vor 4.0.0 und wurde am 08.01.2008 eingespielt), die 4.0 unter dem Aspekt was KDE selbst erreichen wollte, als vollen Erfolg ansehen. Als sehr einfache Metrik um das zu bestätigen: in 2008 wurde fast jeden Tag ein neuer SVN Account erstellt.

Nun bleibt die Frage offen, ob KDE wirklich Nutzer verloren hat durch das Release und sich selbst geschadet hat. Wie gesagt ist es schwierig Daten dafür zu bekommen. Als Versuch möchte ich mal die Bug Statistik von KWin über die Geschichte von 1999 bis heute heranziehen. KWin ist hierbei interessant, da es in 3.5 bereits eine sehr ausgereifte und extrem stabile Anwendung war. in KDE 4 kamen die Desktop Effekte dazu, jedoch bis 4.2 standardmäßig deaktiviert und als experimentelles Feature markiert.

Die Statistik beinhaltet leider auch die "Wishlist" (aka Feature Requests), welche die Statistik leicht verfälschen, da sie meistens nicht bestätigt werden oder implementiert werden. Aktuell haben wir ungefähr 320 Feature Requests wovon 270 zu der roten Linie der Unconfirmed Bugs gehört. Eine Entwicklung über die Zeit steht mir hier leider nicht zur Verfügung.

Erklärung der Begriffe:

UNCONFIRMED: ein Bug, der noch nicht reproduziert werden konnte oder ein Feature Request
NEW: reproduzierbarer Bug
ASSIGNED: ein Entwickler hat sich den Bug zugewiesen – wird in KWin eigentlich nicht verwendet
REOPENED: ein Bug der als behoben markiert wurde und noch immer vorhanden ist.

Der Graph zeigt sehr deutlich einen massiven Einschnitt in der Entwicklung. Dieser Einschnitt liegt um die Jahreswende 2007/2008. Zwischen 2005 und 2008 haben sich die Zahlen der bestätigten Bugs kaum verändert. Der Abstand zwischen den UNCONFIRMED und NEW bleibt in diesem Zeitraum in etwa gleich. Was hat sich also in 2008 ereignet, dass sich die Zahlen so verändern? In diesen Zeitraum fällt das 4.0 Release. Seit diesem Zeitpunkt hat sich die Gesamtzahl der offenen Bugs mehr als verdoppelt und nehmen etwa einen linearen Verlauf an.

Zuerst einmal stellt sich hier die Frage: wie kann es sein, dass Bugs gemeldet werden, wenn das Release doch in einem Zustand ist, dass es nicht benutzbar ist und der neue Code in der Anwendung standardmäßig nicht aktiviert ist (und damals) auch auf der meisten Hardware nicht funktionierte?

Eine naheliegende Erklärung zu den wachsenden Kurven wäre, dass vor 4.0 die Entwickler neu aufgemachte Bugs behoben haben und ab 4.0 der Bugtracker vermüllt. Diese These kann man mit einer weiteren Statistik widerlegen:

Zuerst die Erklärung der neuen Linien:

FIXED: ein behobener Bug
DUPLICATE: ein Bug der bereits gemeldet wurde und durch Triaging manuell als Duplikat markiert wurde
NEEDSINFO: ein Bug bei dem Rückfragen an den Nutzer gestellt wurden und keine Antwort kam
UPSTREAM: Bug in einer Komponente auf die KWin aufbaut – meistens Treiber

Bei den neuen Kurven ist wichtig zu bedenken, dass es zu erwarten ist, dass die Werte immer weiter anwachsen – im Gegensatz zu den offenen Bugs wo man erwartet, dass sie konstant sind oder zurückgehen. Am interessantesten ist die Kurve der FIXED Bugs. In dem Bereich zwischen 2005 und 2008 ist die Kurve fast konstant – genauso wie die Kurven der UNCONFIRMED und NEW Bugs. In 2008 verändert sich die Kurve ebenfalls und nimmt auch ein lineares Wachstum an. In den drei Jahren seit 4.0 haben die KWin Entwickler fast so viele Bugs behoben wie in den acht Jahren zuvor.

Die Kurve zeigt deutlich, dass zum Auslauf von KDE 3.5 keine neuen Bugs mehr gemeldet wurden und seit 4.0 die Anzahl sowohl gemeldeter als auch behobener Bugs deutlich ansteigt. Dies kann man auch an der DUPLICATE Kurve sehen. Diese wächst auch während KDE 3 linear an. D.h. es wurden immer wieder die gleichen Bugs gemeldet. Jedoch verändert auch diese Kurve Ende 2008 ihre Form (Kubuntu mit 4.1 und Effekten standardmäßig aktiviert). Die Kurve hat klar die stärkste Steigung von allen hier gezeigten und scheint gänzlich unbeeinflusst von den anderen Kurven zu sein. Dass wir viele Duplikate bekommen habe ich ja schon vorher gewusst.

Nun will ich noch eine weitere Statistik zeigen: die Entwicklung von KWin. Mit Hilfe von git log und einem kleinen Programm hab ich mir die Anzahl Commits und Anzahl Committer pro Jahr generieren lassen (Achtung: Y-Achse ist logarithmisch):

Der Graph bricht zum Schluss so stark ab, da wir in 2011 noch nicht viele Monate hatten Was dieser Graph nun zeigt, ist dass in der Zeit in der keine neuen Bugs gemeldet wurden die Enticklungsgeschwindigkeit stark angezogen hatte (KDE 4 Portierung/Entwicklung der Effekte) und auf dem hohen Level sich hat halten können. Das 4.0 Release hat die KWin Entwicklung weder in die eine noch in die andere Richtung beeinflusst. Insbesondere konnte KWin das reduzierte Engagement des Maintainers (immernoch etwa 27 % aller Commits) durch neue Entwickler kompensieren.

Fazit:

Die Aussage, dass es das 4.0 Release brauchte um den Code getestet zu bekommen, ist im Falle von KWin klar bestätigt. Seit 4.0 steigt die Anzahl der gemeldeten und behobenen Bugs stark an.
Zumindest KWin hat durch das 4.0 Release keine Nutzer verloren. Andernfalls hätte die Kurve nicht anziehen können
Die Anzahl der Bugs ist gestiegen obwohl die neue Funktionalität nicht standardmäßig aktiviert war. Dies deutet auf ein Wachstum der Benutzerzahlen hin.
Das spätere standardmäßige Aktivieren der neuen Funktionen hat keine Auswirkungen auf offene und behobene Bugs sondern nur auf Duplikate und Treiber Bugs
Die massive Stabilisierung in KWin hat keine Auswirkung auf die Anzahl der gemeldeten Bugs. Die Rate ist nahezu konstant. Auch dies lässt sich nur mit Anwachsen der Benutzerzahlen erklären.
KWin ist als Projekt sehr gesund.

Ich bitte davon Abstand zu nehmen mich in den Kommentaren daruaf hinzuweisen, dass 4.0 doch ganz fürchterlich war. Das 4.0 Release war vor meiner Zeit als Entwickler und ich bin daher in keinster Weise für das Release verantwortlich.

=-=-=-=-=
Powered by Blogilo

Upstream und Downstream

Martin Gräßlin — Tue, 01 Mar 2011 18:26:51 +0000

Das Verhältnis zwischen den Open Source Projekten und ihren Distributionen ist ein sehr besonderes. Die Distributionen brauchen die Open Source Projekte, denn ohne sie haben sie nichts zu paketieren und die Open Source Projekte brauchen die Distributionen um den Quellcode zu verteilen – wie der Name schon sagt. Dieses Verfahren ist so eingespielt, dass richtig große Open Source Gemeinschaften wie z.B. KDE überhaupt keine Pakete bereitstellen, sondern nur den Quellcode zum Download anbieten. Im Falle KDE sind die Distributionen so eingebunden, dass sie Zugriff zu den Quellcode Paketen eines neuen Releases bekommen bedeutend vor dem Rest der Welt (mich eingeschlossen) um Pakete rechtzeitig zum Release bereitstellen zu können.

Die Beziehung zwischen den Open Source Projekten und ihren Distributionen ist so speziell, dass sie sogar eigene Namen haben. Die Open Source Projekte bezeichnen sich als "Upstream" und die Distributionen als "Downstream". Das Projekt ist also flußaufwärts und der Quellcode strömt zur Distribution den Fluß hinunter. Patches, die von den Distributionen zurück an die Projekte fließen, wir mit "to upstream" bezeichnet.

Mir persönlich ist das Verhältnis zu den "Downstreams" sehr wichtig. Ich kenne die Paketbetreuer unserer wichtigsten Distributionen und helfe regelmäßig falls es darum geht KWin besser in die Distribution zu integrieren und Bugreports von "Downstream" werden von mir priorisiert behandelt. Genauso wie einem als Upstream die Downstreams wichtig sind, erwartet Upstream auch, dass Downstream sich um Upstream kümmert. Einer der Punkte, die einem da sehr wichtig sind, ist die Anzahl der Patches, die Upstream integriert. Von einer guten Downstream erwartet man, dass Patches geupstreamed werden. Wenn nicht stellt sich immer die Frage: warum? Hier erfolgt dann sehr oft der Vorwurf, dass Distributionen ihre Upstreams kaputt patchen.

Natürlich ist es einer Downstream erlaubt den Quellcode zu verändern und zu verbreiten. Dies ist durch die dritte Freiheit der Free Software Definition klargestellt:

The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

Wer die Open Source Welt in den letzten Tagen verfolgt hat, dem dürfte klar sein auf was ich mit meiner Einleitung hinaus wollte: dem Fall Banshee und Canonical oder verallgemeinert Upstream und Downstream. Zu dem Fall an sich will ich gar nichts mehr sagen. Das haben andere schon viel besser erledigt.

Für mich als Maintainer einer Upstream Software ist das Verhalten der Downstream aber ein sehr interessanter Fall zum Studieren und ich bin mir sicher, dass sehr viele Upstream Entwickler den Fall sehr genau betrachten und auch andere Downstreams schauen sehr genau darauf. Faktisch ist alles klar: Canonical hat durch die dritte Freiheit das Recht den Code zu ändern in welcher Art sie wollen. Ob sie es sollen ist eine andere Sache. Ich möchte hierzu den relevanten Quellcode in Banshee zitieren:

// We ask that no one change these affiliate codes. ALL (100%) revenue
// generated by these affiliate IDs is sent directly to the GNOME
// Foundation. The GNOME Foundation controls/owns these affiliate IDs.
// Please help support Free Software through the GNOME Foundation!

Ob es nun moralisch vertretbar ist, dass ein Unternehmen diesen Code ändert um selbst Profit daraus zu ziehen, muss im Endeffekt jeder selbst entscheiden. Für mich persönlich ist es befremdlich zu sehen, dass eine Downstream gegen den Wunsch des Upstream Projekts den Code ändert – auch wenn es ihr gutes Recht ist. Für mich als einer der vielen altruistisch arbeitenden Open Source Entwickler ist es noch befremdlicher zu sehen, dass das Geld eigentlich an eine gemeinnützige Organisation gehen soll. Der finanzielle Beitrag ist dabei übrigens eher marginal. Banshee bringt aktuell etwa 10.000 $ pro Jahr ein. Wir können nicht wissen wie viel Ubuntu beisteuern würde, aber meine Vermutung ist, dass es nicht viel mehr wäre. Der aktuelle Beitrag reicht vllt. um einen Entwickler einen Monat zu finanzieren oder aber um einen Sprint auszurichten. Ich überlasse die Bewertung dessen dem Leser.

Der "Skandal" ist für mich aber nicht, dass Canonical den Code geändert hat, sondern das Vorgehen. Zuerst eine Diskussion mit den Entwicklern zu starten und zwei Optionen zur Wahl zu stellen und danach einstimmig zur abgelehnten Option umzuschwanken, ist meiner Meinung nach mehr als nur schlechter Stil. Persönlich denke ich auch, dass hier das Hauptproblem ein Kommunikationsproblem von Seiten Canonicals war. Und ich meine nicht, dass überhaupt Optionen angeboten werden, wie Mark Shuttleworth es nun verteidigt hat, sondern dass man das Upstream Projekt falsch angesprochen hat.

Als Distribution muss man seine Upstreams kennen. Bei den zwei Optionen hätte es Canonical bereits im Vorfeld klar sein müssen, wie sich die Entwickler entscheiden. Canonical hätte also wissen müssen dass die gewünschte Option nicht gewählt wird und das anschließende Erzwingen stößt jeden Entwickler nur vor den Kopf. Natürlich wäre nicht zu kommunizieren genauso falsch gewesen, genauso wie zu kommunizieren, dass man das jetzt einfach so macht. Ich halte es aber für durchaus denkbar, dass man die Community so führen kann, dass sie selbst den Vorschlag zum Aufteilen der Einnahmen erbringt – wenn es unbedingt sein muss. Eine klare Aufgabe für einen Communitymanager – den Ubuntu ja hat.

Canonical hat sich mit der gesamten Geschichte einen riesigen Bärendienst erwiesen. Canonical und auch Ubuntu stehen schon länger unter genauer Beobachtung von Upstream Projekten. Immer wieder mehren sich die Vorwürfe, dass Canonical nur nimmt und nicht gibt (vgl. Diskussion zu Quellcode Beiträge zu Kernel und GNOME). Immer wieder wird auch die Art und Weise wie Canonical mit der Community umgeht kritisiert (vgl. Copyright Assignment, Ayatana, Unity). Persönlich habe ich auch schon sehr lange und intensiv mir Gedanken zu Canonical gemacht und auch immer wieder gefragt, ob Canonical überhaupt Open Source versteht. Für mich passt (leider) das aktuelle Geschehen in mein Bild von Canonical – denken viele Entwickler so, dann ist dies eine sehr gefährliche Entwicklung für Canonical. Verscherzt es sich Canonical zu stark mit allen Upstream Projekten, dann stehen sie sehr alleine dar und ob sie dafür Manpower und Kompetenz auf allen Feldern haben, ist mehr als fraglich.

Hinweis: in diesem Text fehlen viele Fußnoten. Ich habe mich aus aktuellem Anlass dazu entschlossen meine Quellen nicht anzugeben und überlasse dem Leser das Suchen der Quellen selbst. Bei der großen Anzahl von Quellen zu diesem Blogpost habe ich leider den Überblick verloren, dennoch ist es kein Plagiat, auch wenn Gedanken aus anderen Quellen übernommen worden. Dies sieht man schon daran dass alle nicht angegebenen Quellen auf Englisch sind und dieser Post auf Deutsch.

=-=-=-=-=
Powered by Blogilo

Fortschritt im Land der Wabernden Fenster

Martin Gräßlin — Sun, 27 Feb 2011 12:20:37 +0000

Ich hab schon länger nicht mehr auf Deutsch gebloggt, was natürlich nicht bedeutet, dass die Entwicklung an KWin eingeschlafen wäre, nein ganz im Gegenteil. Aktuell passiert im Land der wabernden Fenster recht viel und viele Verbesserungen für die Anwender sind in der Implementierungsphase für die nächste Version der KDE Plasma Workspaces.

Über die letzten Monate habe ich hauptsächlich an der Portierung von KWin nach OpenGL ES gearbeitet, womit KWin nun auch auf mobilen Endgeräten verwendet werden kann. Vor kurzem hatten wir dazu eine Meldung auf der KDE Nachrichtenseite (der Artikel enthält auch zwei Videos!). Was aber noch viel wichtiger ist als die Verfügbarkeit von KWin auf mobilen Endgeräten, ist dass mit OpenGL ES der Grundstein für KWin mit Wayland gelegt ist. Wayland erzwingt für Compositing OpenGL ES und somit muss jeder Compositor OpenGL ES verwenden.

Durch die Unterstützung von OpenGL ES wurde der gesamte Compositing Code überarbeitet und KWin unterstützt nun OpenGL 1.x und 2.x als rendering backends. Voreingestellt ist dabei (sofern es der Treiber unterstützt) OpenGL 2. Damit haben wir nicht nur einen bedeutend moderneren Code, sondern auch bessere Performance im gesamten Rendering Stack. Natürlich ist das noch nicht alles, denn wir arbeiten nun daran den Code zu optimieren und selbst ohne Optimierung spürt man schon deutliche Performance Verbesserungen im Vergleich zu 4.6.

Abseits der Programmierung passiert auch richtig viel. Ich habe angefangen im Community Wiki eine KWin Sektion einzurichten um neuen Entwicklern das Leben einfacher zu machen und unsere Bugzilla Komponenten wurden erweitert und die Bugs werden nun besser kategorisiert. Hier ist natürlich die Hilfe der Community mehr als erwünscht Bei über 400 Bugs ist das kaum etwas was sich leicht und schnell stemmen lässt.

In unserer Code Struktur arbeite ich auch daran die Effekt API etwas zu erneuern um in Zukunft vielleicht doch irgendwann mal eine stabile API zu haben. Das ist eine Voraussetzung um einige Effekte aus KWin auszulagern. Mittlerweile haben wir mehr als 40 Effekte was sowohl uns als auch den Nutzern die Verwendung erschwert. Ziel ist es in KWin nur noch die wichtigsten Effekte zu haben und den Rest auszulagern. Dies erlaubt uns die Effekte besser zu warten und uns gezielt auf einige Effekte zu konzentrieren.

Demnächst beginnt auch wieder der Google Summer of Code und KWin möchte sich auch daran beteiligen. Wir haben einige interessante Projekte ausgeschrieben. Z.B. eine Modularisierung von KWin Core zur besseren Wartung von KWin Core, dem Aufbau eines Unit Test Frameworks mit Xephyr und KWin’s Scripting Komponente sowie ein Projekt zur Initialen Unterstützung von Wayland Clients. Natürlich kann jeder potentielle GSoC Student auch eigene Ideen bringen.

Wie man sieht sind wir fleißig am Arbeiten und wollen mit KWin in 4.7 das nächste Level des composited Window Managments einläuten. Die Änderungen sind jetzt schon unglaublich performant und meine Erwartung ist, dass wir mit 4.7 den Vergleich mit Compiz endlich nicht mehr scheuen müssen

=-=-=-=-=
Powered by Blogilo

Debugging Rendering Code visuell

Martin Gräßlin — Fri, 19 Nov 2010 20:02:28 +0000

Ich bin aktuell dabei den Rendering Code von KWin neuzuschreiben für OpenGL ES und auch OpenGL 3. Das stellt einen natürlich vor Probleme: wie überprüft man, dass der neue Code ausgeführt wird und, dass der alte noch funktioniert?

Der neue Zeichen Code verwendet nun einen Shader – hier ist es einfach einen Test einzubauen. Aktuell färbe ich einfach alle Pixel grün ein, wenn der Shader verwendet wird. Somit sieht man sehr leicht, welche Bereiche den neuen Pfad verwenden. Neben dem eigentlichen Zeichnen, ist es auch noch interessant zu sehen wie die Geometrie aussieht, die da eigentlich gerendert wird. Vor einiger Zeit hatte mir ein Compiz Entwickler einen Screenshot gezeigt, wo das zu sehen war und ich dachte mir, irgendwie nützlich. Heute abend hab ich es mal schnell eingebaut.

Ich lese zur Zeit die fünfte Auflage der OpenGL SuperBible (dazu mehr mal in einem anderen Post) und zwar von vorne ohne größere Grundlagenbereiche auszulassen. Somit bin ich heute auf eine Stelle gestossen, die beschreibt wie das geht. Natürlich kannte ich die Technik schon, nur ich hatte nicht daran gedacht. Beim Lesen dachte ich mir: ach das war doch das was Compiz auch hat, wäre ganz nützlich einzubauen. Das sieht dann insgesamt eigentlich schon sehr häßlich aus

Debug OpenGL rendering

Was man sehr schön sieht, ist wie groß der Schatten der Fensterdekoration doch ist.. Den debug Modus kann man in Zukunft über die Umgebungsvariable KWIN_GL_DEBUG aktivieren. Da wir ja schon im Feature Freeze sind, sprechen wir hier von 4.7 im Juli 2011. Wer trotzdem den Bildschirm bunt sehen will, kann ja den Show Paint Effekt verwenden.

=-=-=-=-=
Powered by Blogilo

Interessante Zeiten liegen vor uns

Martin Gräßlin — Fri, 12 Nov 2010 15:41:48 +0000

In der Nacht auf den heutigen Freitag war der große Freeze für die KDE Plattform, Workspaces und Application Releases in Version 4.6. D.h. es dürfen keine neuen Features eingespielt werden und keine Änderung an Texten vorgenommen werden. Die KDE Entwickler Community wird sich nun ganz auf das Stabilisieren und Bugfixing konzentrieren bis zum Release Ende Januar. Die erste Beta Version wird bereits am 24.November erscheinen.

Wie man sich vorstellen kann, war der gestrige Abend noch etwas stressig. Code wollte noch geschrieben werden (sonst müssten die User noch ein halbes Jahr auf ein Feature warten), Review Requests angeschaut, getestet und kommentiert werden und so weiter. Zum Glück ist das Release Team nicht ganz so streng was das Einhalten der Frist angeht und so hat ein KWin Entwickler heute morgen um halb sieben noch einen Commit eingespielt

Für mich war der 4.6 Entwicklungszyklus auch sehr interessant. Es war der erste Zyklus in dem ich nicht mehr Student bin und musste diese Doppelbelastung auch erst einmal organisiert bekommen. Gerade wenn man als Softwareentwickler arbeitet, hat man ja abends nicht immer die Lust noch einmal zu programmieren. So muss ich leider auch erkennen, dass ich weit weniger für KWin implementieren konnte, als ich mir eigentlich vorgenommen hatte.

Das 4.6 Release ist aus KWin Sicht nun für mich besonders interessant, da es das erste Release ist, bei dem mein Name in den aboutData als Maintainer aufgeführt ist. Natürlich fühle ich mich geehrt Maintainer einer der wichtigsten, ältesten und ausgereiftesten Komponenten des KDE Workspaces sein zu dürfen. Wenn mir jemand vor drei Jahren gesagt hätte, dass ich Maintainer von KWin werde, hätte ich ihn wohl nur verwirrt angeschaut. Aber das ist ja das schöne, dass man nicht in die Zukunft schauen kann.

Trotzdem werde ich das nun machen. Mit dem Freeze hinter sich, hat man mehrere Monate Zeit um sich Gedanken zum nächsten Zyklus zu machen. Was wollen wir in 4.7 neues bieten, worauf sollen wir achten? In den letzten Wochen hat sich für mich angedeutet worauf wir uns konzentrieren müssen. Wayland wird vermutlich kommen, genauso wie ARM. KWin ist hier sicherlich die Anwendung aus dem KDE Lager, welche am stärksten angepasst werden muss. 4.7 wird also der erste Releasezyklus auf dem langen Weg zu Wayland. Insgesamt ist es nicht so viel Arbeit wie ich anfänglich dachte, jedoch wird es sicherlich mindestens zwei Jahre dauern, bis diese Anpassung abgeschlossen sind. Ich hoffe hier vor allem mit den Compiz Entwicklern zusammenarbeiten zu können.

Insgesamt bedeutet das nun eine Verschiebung meiner Implementierungsideen. Wollte ich eigentlich KWin zuerst auf OpenGL ES 1.1 portieren, werde ich die Arbeit daran nun einstellen und direkt auf OpenGL ES 2 gehen. Dies ist nicht nur für mobile Geräte interessant, sondern wird auch benötigt um Wayland zu unterstützen. Alle Änderungen, die ich dabei mache, werden auch direkt für die aktuelle Desktop Version vorteilhaft sein. So plane ich das einfache Rendern von Fenstern (keine Effekte aktiv) auf einen moderneren Code zu heben. Der Shader dafür liegt schon auf Papier niedergeschrieben auf meinem Schreibtisch Leider ist das auch immer eine Gratwanderung: Optimierung bei einem Treiber kann zu riesigen Performanceproblemen bei einem anderen führen. Da aber der alte Code nicht entfernt wird, sollte es problemlos zurückschaltbar sein.

Interessante Zeiten liegen vor den Entwicklern von s/Fenstermanagern/Compositor/.