Posted on

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 😉

Posted on

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.

Posted on

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.

Posted on

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.

Posted on

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!

Posted on

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

Posted on

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

Posted on

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

Posted on

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

Posted on

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