Themen fuer Einfuehrung in Kubuntu auf der Ubucon gesucht

Ich bin gerade dabei mein Demo-System fuer meine Einfuehrung in die KDE Plasma Workspaces auf der Ubucon am Samstag vorzubereiten und wollte dabei noch einmal kurz daran erinnern, dass ich immer noch gerne Themenvorschlaege annehme zu was ich denn im Vortrag alles beruecksichtigen soll.

Also falls jemand einen Wunsch hat, einfach in den Kommentaren hinterlassen, dann kann ich was vorbereiten. Ansonsten einfach zu meinem Vortrag kommen und die Frage/Antwort Session nutzen ­čśë

Einf├╝hrung in Kubuntu auf der Ubucon 2012

Auf der diesj├Ąhrigen Ubucon, welche vom 19. bis 21. Oktober in Berlin stattfindet, werde ich eine Einf├╝hrung in Kubuntu und insbesondere in die KDE Plasma Workspaces geben.

Dies ist eine hervorragende Gelgenheit mal in Kubuntu reinzuschnuppern und das nicht nur wenn man mit den Entwicklungen bei anderen Umgebungen nicht so ganz zufrieden ist ­čśë Als Entwickler an den Workspaces kann ich bestimmt auch alten KDE Plasma Nutzern noch einige Tricks beibringen um Plasma besser zu bedienen.

Da ich plane die Einf├╝hrung haupts├Ąchlich als Live-Vorf├╝hrung durchzuf├╝hren, kann ich anbieten, dass ich eure W├╝nsche in der Einf├╝hrung ber├╝cksichtige. Wenn es etwas gibt, was ihr angesprochen haben wollt, dann hinterlasst doch einfach einen Kommentar hier im Blog und ich werde schauen, dass ich das einbauen kann. Nat├╝rlich keine Garantie :-)

Freue mich schon viele interessierte Gesichter in Berlin zu treffen.

Da das Programm der Ubucon anscheinend noch nicht online ist, hier mal der Abstract zu meinem Vortrag wie ich ihn im Call-For-Papers eingereicht hatte:

Kubuntu – eine Einf├╝hrung in die KDE Plasma Workspaces

Kubuntu ist die von der Community herausgegebene Ubuntu Variante mit Fokus auf Software der KDE Community. Anstatt dem unter Ubuntu verwendeten Unity kommt hier eine der KDE Plasma Workspaces zum Einsatz – je nach Gr├Â├če des Bildschirmes entweder eine speziell angepasste Netbook Oberfl├Ąche oder ein klassischer Desktop.

In diesem Vortrag wird die grundlegende Verwendung von Kubuntu und der KDE Plasma Workspaces vorgestellt. KDE Plasma ist ein sehr m├Ąchtiger Desktop, der dem Nutzer unglaublich viele M├Âglichkeiten gibt, schnell, effizient und mit Freude seine Arbeit am Rechner zu vollbringen. KDE Plasma ist eine Oberfl├Ąche, die nicht Aufmerksamkeit verlangt, sondern dem Nutzer hilft seine Arbeit durchzuf├╝hren.

Hierzu bietet Plasma interessante neue Konzepte wie Aktivit├Ąten an. Diese erlauben dem Nutzer seine Arbeit thematisch zu sortieren. Dabei wird aber diese Funktion dem Nutzer nicht aufgezwungen, sondern es ist eine n├╝tzliche Funktion, welche man benutzen kann, wenn man denn m├Âchte.

Neben der Einf├╝hrung in die KDE Plasma Workspaces, werden auch einige der f├╝r den t├Ąglichen Gebrauch wichtigsten Anwendungen von KDE erkl├Ąrt, wie z.B. den KDE Dateimanager Dolphin oder den Bildbetrachter Gwenview, welcher auch Bilder direkt nach Facebook, Flicker und Co senden kann.

Hilf KDE den Randa Sprint auszurichten

Dieses Jahr m├Âchte die KDE Community erneut einen Entwicklersprint im schweizerischen Randa durchf├╝hren. Diese Sprints sind besonders wichtig f├╝r die Entwickler. Der Sprint ist f├╝r den Zeitraum vom 21. bis 27. September geplant und es sind die folgenden Ziele f├╝r den Sprint gesetzt:

  • Das KDE Accessibility Team m├Âchte sich mit den GNOME Accessibility Experten treffen um die Anwendungen f├╝r im Sehen eingeschr├Ąnkte Nutzern besser verf├╝gbar zu machen. Daf├╝r wurden blinde Nutzer eingeladen um bei der Entwicklung zu helfen
  • Die KDE Education Entwickler arbeiten an neuen oder existierenden Bildungs-Anwendungen f├╝r mobile Endger├Ąte
  • Das KDE Multimedia und Amarok Team m├Âchte die Zukunft von Amarok insbesondere auf mobilen Endger├Ąten besprechen. Zus├Ątzlich wird an Phonon im Zuge von Qt 5 gearbeitet.
  • Die Plasma Entwickler m├Âchten an der Zukunft der Workspaces arbeiten, insbesondere an den Anpassungen f├╝r Frameworks 5, welches auf Qt 5 basiert. Dies ist unglaublich wichtig um eine gemeinsame Richtung zu definieren und die Anforderungen auszuarbeiten um eine aktualisierte Entwicklungsumgebung bereitzustellen ohne die Benutzbarkeit einzuschr├Ąnken.

In der Vergangenheit gab es bereits einige wegweisende Sprints in Randa. So wurde letztes Jahr die Grundlage f├╝r Frameworks 5 gelegt. Genaue Details kann man auf dem Dot nachlesen.

Die KDE Community muss f├╝r diesen Sprint 35 Entwickler aus der ganzen Welt nach Randa bringen und daf├╝r brauchen wir etwas Geld. Um den Sprint zu erm├Âglichen, wurde eine Spendenkampagne gestartet. Es w├Ąre toll wenn m├Âglichst viele an der Spendenkampagne teilnehmen w├╝rden.

Click here to lend your support to: KDE Randa Meetings and make a donation at www.pledgie.com !

Wenn du dauerhaft die KDE Community unterst├╝tzen m├Âchtest, dann ist Join the Game genau das richtige f├╝r dich. F├╝r nur 100 ÔéČ im Jahr kannst du ein unterst├╝tzendes KDE-Mitglied werden (KDE e.V. ist ein gemeinn├╝tziger Verein). Ich bin seit letztem Jahr nicht nur ein entwickelndes sondern auch unterst├╝tzendes KDE-Mitglied.

Motor Tuning

Mittlerweile hat das KDE Release Team begonnen die Quellcode-Pakete f├╝r die KDE Applications, KDE Workspaces and KDE Platform in Version 4.9 vorzubereiten, was f├╝r mich mal wieder ein guter Zeitpunkt ist zur├╝ckzuschauen auf das letzte halbe Entwicklungsjahr im KDE Plasma Fenstermanager und Compositor KWin.

F├╝r den Nutzer wird es in KWin 4.9 nicht viel Neues zu sehen geben. An einigen Stellen haben wir die Benutzbarkeit etwas erh├Âht, so zum Beispield das Konfigurationsmodul f├╝r Fensterwechseln komplett ├╝berarbeitet und das Konfigurationsmodul f├╝r Fensterdekorationen ist nun interaktiver geworden.

Dies war aber auch nur m├Âglich durch einige Arbeiten unter der Haube. Die Fensterdekorationsengine Aurorae wurde mittels QtQuick neugeschrieben, ist dadurch bedeutend wartbarer und performanter geworden und ist nun zumindest auf meinen Systemen performanter als unsere Standarddekoration Oxygen. Als Nebeneffekt kann der Quellcode auch in dem Konfigurationsmodul verwendet werden, was die nun existierende Interaktion erst erm├Âglicht.

Aber nicht nur der Motor der Aurorae Themes wurde getuned, nein der ganze Fenstermanager musste an sich Anpassungen ergehen lassen. Der Startvorgang ist deutlich beschleunigt, vieles wird nun parallel abgearbeitet und generell wird nicht mehr so viel gewartet um zum Beispiel eine Konfigurationsdatei einzulesen. Das d├╝rfte je nach Hardware den Startvorgang des KDE Plasma Desktops um ein paar hundert Millisekunden beschleunigen.

Durch die generellen Umbaumassnahmen am Motor waren wir auch in der Lage einige richtig alten Bugs zu beheben. So ist der zweite Bug Report, den ich f├╝r KWin als Entwickler aufgemacht habe, nun endlich behoben: Fenster werden nach dem Schlie├čen nicht mehr ├╝ber andere Fenster gesetzt sondern behalten ihre Position. Was eigentlich nur nach einem Sch├Ânheitsfehler klingt, ist durchaus auch relevant f├╝r die Sicherheit. Durch diesen Bug wurden Benachrichtigungen f├╝r ein paar Millisekunden ├╝ber der Bildschirmsperre angezeigt. Leider ist die ├änderung doch sehr tiefgreifend und bringt den Motor noch etwas zum “stottern”, daher k├Ânnen wir die ├änderung nicht in 4.8 einarbeiten. Bis zur Ver├Âffentlichung von 4.9 bekommen wir das Stottern aber noch in den Griff. Gerade eben hatte ich einen Crash dadurch, f├╝nf Minuten sp├Ąter war der Review Request mit dem Fix bereits erstellt.

Auch in anderen Bereichen haben wir daran gearbeitet, dass der Motor einfach runder l├Ąuft. So wurden die “Fenstertabs”, also die Funktionalit├Ąt mehrere Fenster in einer Fensterdekoration zu haben, komplett neu geschrieben um die Stabilit├Ąt zu erh├Âhen. Dies war urspr├╝nglich einmal ein Google Summer of Code Projekt gewesen und wurde leider nach Abschluss des Projekts vom Studenten nicht weitergepflegt.

Auch ein anderes Google Summer of Code Projekt wurde in diesem Release Zyklus neu geschrieben und ausgebaut: Scripting. In 4.9 k├Ânnen nun Skripte entweder als JavaScript oder als QtQuick geschrieben werden und wir machen davon durchaus Gebrauch. Die Anzeige, wenn der Desktop gewechselt wird, wurde durch ein QtQuick Skript ersetzt und einige Anpassungen zum Deaktivieren der Multi-Monitor-Unterst├╝tzung haben wir in Skripte ausgelagert.

Skripte k├Ânnen nun auch bedeutend einfacher erstellt werden, n├Ąmlich ├╝ber die Window Skripting Console, zu starten ├╝ber KRunner (Alt+F2) und dann “wm console”. Der JavaScript Code wird direkt im Fenstermanager ausgef├╝hrt und erm├Âglicht somit ein sehr einfaches Ausprobieren der Skripte.

Ein zus├Ątzliches Highlight ist, dass man nun Desktop Effekte in JavaScript implementieren kann. Ein paar Effekte haben wir damit auch bereits ersetzt und einige hundert Zeilen C++ Code durch ein paar JavaScript Zeilen ausgetauscht. Interessant ist, dass dies keinerlei Auswirkung auf die Performance hat, denn zum eigentlichen Zeichnen und Animieren wird weiterhin ein ausgereiftes C++ Backend verwendet. Ausschlie├člich Code zum Starten der Animation ist in JavaScript geschrieben.

Zusammengefasst denke ich, dass unsere Nutzer sehr zufrieden mit diesem Release sein werden und uns nachsehen werden, dass es keine neuen Spielereien gibt. Daf├╝r haben wir aber die Grundlagen gelegt, dass unsere Nutzer selbst mittels JavaScript und QtQuick neue Spielereien nachreichen k├Ânnen. Mein Vortrag auf der diesj├Ąhrigen Akademy wird sich um genau dieses Thema drehen.

Wer die Entwicklungen der KDE Community finanziell unterst├╝tzen will, kann zum Beispiel bei Join the Game teilnehmen. F├╝r die KDE Community ist solch eine Unterst├╝tzung unglaublich wichtig, da wir Server zu bezahlen haben und wir das Geld einsetzen k├Ânnen um Entwickler zu den Sprints zu fliegen. Gerade die Entwicklersprints sind unglaublich hilfreich f├╝r die Entwicklung der Software, da hier die Entwickler die M├Âglichkeit haben mal direkt miteinander zu sprechen als immer nur ├╝ber E-Mail oder IRC.

Was passierte im Fenstermanager f├╝r KDE Plasma Workspaces 4.8?

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?

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

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?

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

├ť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

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:

  1. 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.
  2. Zumindest KWin hat durch das 4.0 Release keine Nutzer verloren. Andernfalls h├Ątte die Kurve nicht anziehen k├Ânnen
  3. Die Anzahl der Bugs ist gestiegen obwohl die neue Funktionalit├Ąt nicht standardm├Ą├čig aktiviert war. Dies deutet auf ein Wachstum der Benutzerzahlen hin.
  4. Das sp├Ątere standardm├Ą├čige Aktivieren der neuen Funktionen hat keine Auswirkungen auf offene und behobene Bugs sondern nur auf Duplikate und Treiber Bugs
  5. 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.
  6. 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