Posted on

Upstream und Downstream

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

Posted on

Fortschritt im Land der Wabernden Fenster

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

Posted on

Debugging Rendering Code visuell

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

Posted on

Interessante Zeiten liegen vor uns

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

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

Posted on

Wayland in Ubuntu – oder viel Lärm um Nichts?

Mark Shuttleworth hat in einem Blog Post geschrieben, dass Ubuntu eine der ersten Distributionen sein wird, die Wayland verwendet, was einiges an medialem Echo hervorgerufen hat. Persönlich hat mich der Blogpost überrascht, da auf dem Ubuntu Developer Summit für mich nicht ersichtlich wurde, dass Wayland schon zur Diskussion steht. Nur in einer Sitzung zu OpenGL ES in Composited Window Managers hatte ich Mark eine Frage zu Wayland stellen hören und war etwas verwundert. Für mich auch Anlass mal wieder in die Commit Historie zu schauen und ich habe erfreut festgestellt, dass die Entwicklung an Wayland aktiver geworden ist.

Nun was ist Wayland überhaupt? Wayland ist im Prinzip der Nachfolger des X-Servers, jedoch bedeutend schlanker. Wayland ist nur noch ein sehr dünner Display Manager mit eingebautem Compositor, der die Fenster zeichnet. Damit das ganze funktioniert braucht es viele der Technologien, die in den letzten Jahren Einzug erhalten haben, wie KMS und GEM. Genau hab ich mich auch noch nicht mit Wayland auseinandergesetzt, da es meiner Meinung nach, noch viel zu weit in der Zukunft ist. Jedoch sollte ich mich langsam aber sicher, damit beschäftigen, denn sonst steht KDE am Ende ohne Compositor dar (KWin als X WindowManager ist natürlich in einem X freien System nicht wirklich sinnvoll) 😉

Warum sollte man X überhaupt ersetzen? X11 ist älter als ich, xlib ist nicht gerade die schönste API um mit zu arbeiten – nicht überraschend bei einem Alter von fast 30 Jahren. X11 ist entwickelt für die Ansprüche der Rechner aus den 80er Jahren. Xlib enthält also einiges was man heute nicht mehr braucht: Farbverwaltung, Zeichnung, etc. und so ziemlich alles was man heute mit OpenGL machen sollte. Heutige Anwendungen nutzen die primitiven Funktionen von X zum Zeichnen nicht mehr, so ziemlich jedes Toolkit hat dafür bessere Methoden. So bietet Qt an komplett auf der CPU zu zeichnen, statt native Aufrufe zu verwenden und ist dabei bedeutend performanter. Das ganze führte so weit, dass Bereiche von X über Jahre kaputt waren ohne dass es irgendjemand aufgefallen ist.

Die X Entwickler um Keith Packard kennen auch die Probleme und haben immer wieder neue Lösungen angebracht. So zum Beispiel XCB – ein etwas schönerer Ersatz um nicht auf Xlib aufsetzen zu müssen. Nur hat das erst mal niemanden interessiert – KWin zum Beispiel verwendet immer noch XLib und nicht XCB. Genauso die Toolkits: mittlerweile hat man die Erfahrung an den Problemen von X herumzuprogrammieren und warum sollte man etwas neu programmieren, wenn es funktioniert? Ein anderer Bereich ist die Erweiterung des Protokolls durch Erweiterungen wie XFixes – welche wie der Name sagt Fehler im X Protokoll behebt.

Warum sollte aber ein Display Manager eine bessere Lösung sein? Dazu kann man sich anschauen wie aktuell Fenster auf den Bildschirm kommen. Das Fenster wird zuerst gemappt – erhält also einen Bereich auf dem Bildschirm. Der X Server sorgt dafür, dass nur die nicht überlappten Bereiche gezeichnet werden. Die Anwendung zeichnet in der Regel in Pixmaps als Buffers und diese werden von X dann auf den Screen geblittet. Der X Server ist also zuständig dafür zu sorgen, dass die Inhalte aktualisiert werden. Wenn man also ein Fenster über einem anderen verschiebt, werden ständig beide neu gezeichnet. Nun schalten wir die XComposite Erweiterung dazu und betrachten uns das neue Verhalten. X leitet die Ausgabe der Fenster in eine off-screen Pixmap um (Moment? Die Anwendung zeichnet selbst doch auch schon in eine Pixmap…) und benachrichtigt einen externen Client (in der Regel den Fenstermanager) über die XDamage Erweiterung wann sich die off-screen Pixmap verändert. Das geschieht schön asynchron und in klitze kleinen Häppchen (man kann sich vorstellen, was passiert, wenn der Compositor nicht alle Änderungen mibekommt). Der Fenstermanager (oder auch Compositor) nutzt nun die GLX Erweiterung Texture from Pixmap um aus der Pixmap eine Textur zu erstellen und mittels OpenGL diese auf den Bildschirm zu zeichnen. Der ganze "legacy" Bereich des X Servers wird nun nicht mehr benötigt. Man muss keine Zeichenoperationen unterstützen, keine Fenster verschieben können und so weiter und so fort.

Ein kleiner Display Manager ist genau das was man will. Jede Anwendung wird automatisch und immer umgeleitet. Sie braucht also auch keine Informationen wo sie sich befindet. Interessant ist nur die Größe, ob sie aktiv ist oder nicht und vllt. ob sie sichtbar ist oder nicht (z.B. für Videoplayer um automatisch zu pausieren). Wenn man sich nun auch festlegt, dass Compositing generell über OpenGL erfolgt, kann man auch statt einer Pixmap direkt einen Buffer verwenden, der in OpenGL direkt benutzt werden kann. Der X Fenstermanager entfällt und kann nun durch einen viel schlankeren Compositor ersetzt werden.

Viele der heutigen Probleme im Compositing Stack von X sind vermutlich unlösbar. Ich denke da zum Beispiel an das Problem der "Löcher in Fenstern" oder die Tatsache, dass man keine Live Bilder von minimierten Anwendungen hat (was auch der Grund ist für das Stottern der de-minimier Animationen ist). Auch Lösungen um Live Bilder von Anwendungen auf anderen Desktops zu erhalten ist eigentlich nur ein riesiger Hack. Warum wird mein Bildschirm neu gezeichnet, wenn sich etwas auf einem anderen Desktop ändert? Bei einer Architektur, die sich primär auf Compositing ausrichtet, ist das natürlich viel einfacher.

Der Wechsel auf Wayland ist natürlich nichts, was schnell vollzogen werden kann und ich denke mal, dass es locker noch fünf Jahre dauern wird. Alle Toolkits müssen dazu die X Abhängigkeit verlieren, Desktop Shells müssen portiert werden – hier ist es vor allem wichtig gute Compositor zu erstellen, da sonst Funktionalität verloren geht und die wichtige Adaptierung von Wayland verhindern wird. Dies ist zum Beispiel bei KWin ein etwas schwieriges Unterfangen, da die Anwendung komplett X voraussetzt – nur die Effekte könnten fast komplett wiederverwendet werden (nach einer Portierung auf OpenGL ES 2). Es gibt sicherlich auch Anwendungen und Toolkits die niemals portiert werden – für diese wird es dann in Wayland auch einen eingebetteten X Server geben. Die Angst, dass geliebte Anwendungen durch die Transition verloren geht, besteht also nicht. Auch die Netzwerktransparenz von X bleibt somit erhalten.

Und was ist nun von der Canonical Ankündigung zu halten? Für mich klingt es danach, dass sie Unity so schreiben, dass es keine X Abhängigkeit erzwingt (wie zum Beispiel Plasma auch nicht) und dass sie wohl daran arbeiten werden Compiz als Compositor für Wayland fit zu machen. Dies wäre natürlich sehr interessant, da ich mich dort dann auch bedienen kann 😉 Bzw. dass man in den Bereichen zusammenarbeiten kann. Wir sind glücklicherweise so weit, dass wir grundlagen Technologie nicht mehr getrennt entwickeln. Vorerst bedeutet das wohl, dass Compiz auf OpenGL ES portiert werden muss – genauso wie KWin. Abgesehen davon wird wohl nicht viel passieren. Die Anwendungen werden weiter X verwenden.

Natürlich ist das jetzt auch nichts unglaublich herausragendes von Canonical in dem Bereich früh dabei zu sein. Sie werden es wohl auch nicht schaffen als erste Wayland einzusetzen, da MeeGo auch daran arbeitet (Kristian Høgsberg arbeitet für Intel) und gerade für Mobile Devices X nicht die beste Technologie ist. Außer Maemo setzt aktuell kein Linux Handy OS auf X. Um es ganz klar zu sagen: alle Distributionen werden so schnell wie möglich ein etwas funktionierendes Wayland ausliefern, um den Entwicklern eine Basis zum Portieren geben zu können.

Ich persönlich begrüße die Entwicklung, auch wenn es gerade für meine Anwendung viel Arbeit bedeuten wird, auf Wayland zu portieren und ohne eine Vollzeit Stelle wird so etwas kaum machbar sein. Dass Ubuntu nun diese Ankündigung macht, ist wirklich nicht überraschend, aber man muss Mark gratulieren zum guten Marketing 😉

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

Posted on

Wechsel auf KDE SC 4.6

Diese Woche war es mal wieder soweit und ich bin auf den Entwicklungszweig der kommenden Version 4.6 der KDE Plattform, KDE Plasma und KDE Anwendungen umgestiegen. Normalerweise wechsel ich erst zum ersten Beta Release, jedoch wurde der Wechsel bereits nun erforderlich. Auf Grund der schlechten Erfahrungen des letzten Entwicklungszyklus, hatte ich mein Entwicklungsmodell angepasst und hatte unter Plasma 4.5 immer den Fenstermanager KWin in der Entwicklungsversion (plus persönliche Anpassungen) eingesetzt. Ich hoffe dass dies hilft Probleme früher zu bemerken, als wenn die Nutzer mit dem Beta Release die ersten Tester sind.

Um KWin "trunk" fahren zu können, darf KWin natürlich keine Abhängigkeiten auf andere Komponenten aus trunk haben. Das einzige Problem war dabei bisher die Fensterdekoration Oxygen, welche mit dem Widget Style zusammen eine gemeinsame Bibliothek in kdebase/workspace hat. Da diese sich verändert, zerstört das eine Übersetzung (ich sage als immer, dass ich ein reicher Mann wäre, wenn ich für jedes Mal wenn mein KWin trunk nicht kompiliert wegen Oxygen, einen Cent bekäme). Meine Lösung war Oxygen einfach in der Build Datei zu deaktivieren. KWin lädt dann einfach Oxygen von 4.5 (dank binärkompatibilität der Fensterdekorationen möglich) und das Problem ist umschifft. Und ich bin stolz, dass ich mehrere Monate entwickelt habe ohne jemals Oxygen durch ein git commit -a && git svn dcommit deaktiviert zu haben 😉

Letztes Wochenende wurden nun Änderungen für die "Activities" eingespielt, welche auch eine weitere trunk-Abhängigkeit haben. Da diese Änderungen nicht mit einem Kommentar in CMakeLists rückgängig gemacht werden können, stand ich vor einem kleinen Problem: zurück auf 4.5 und test Account zur Entwicklung oder kompletter Wechsel. Das ganze verbunden mit dem Zeitdruck des aufkommenden Feature Freeze. Also einmal trunk neu durchkompiliert und auf 4.6 als primärer System gewechselt. Hat mich leider einen Abend gekostet, an dem ich eigentlich noch wichtige Features für 4.6 einbauen wollte 🙁

Für mich war es das erste mal seit Wochen, dass ich 4.6 neugebaut habe und es war für mich auch spannend, zu sehen woran die anderen Entwickler gearbeitet hatten und noch erfreulicher war, festzustellen, dass man nach Änderungen regelrecht suchen muss. Ein klares Zeichen dafür, dass KDE Plasma mittlerweile sehr ausgereift ist und die größten Änderungen weiter unten im Stack sind – so wie die Optimierungen in KWin.

Sehr erfreulich ist auch bereits die Stabilität von 4.6. Bisher ist mir noch keine Anwendung abgestürzt, obwohl wir gerade in der Phase sind, die wohl die instabilste überhaupt ist: zwischen soft feature freeze und hard feature freeze. Der klassische Zeitraum für "it compiles, ship it". Ich freue mich, dass wir in 4.6 den Nutzern wohl ein noch besseres Produkt liefern werden können als wir bereits in 4.5 konnten.

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

Posted on

KDE erfolgreich bei den Readers’ Choice Awards 2010

Auch dieses Jahr hat das Linux Journal seine Leser abstimmen lassen über die besten Anwendungen/Softwareprodukte und hat die Readers’ Choice Awards 2010 vergeben. Dabei hat KDE Software sehr erfolgreich abgeschnitten. Amarok und digiKam konnten jeweils in ihrer Kategorie gewinnen. Besonders für die Amarok Entwickler freut mich das sehr, da sie doch in den letzten Jahren viel Kritik einstecken mussten. Da ist es schön zu sehen, dass die Anwender die Arbeit schätzen.

Ein sehr schöner Erfolg ist auch das Abschneiden der KDE Plasma Workspaces (im Artikel als KDE bezeichnet): es konnte mit GNOME gleichgezogen werden und beide Desktopumgebungen belegen den ersten Platz. Im Vergleich zum Letzten Jahr konnte Plasma GNOME 10 % abknapsen. Als Plasma Entwickler freut es mich, dass die Anwender unserer Arbeit schätzen. Hier bin ich auch schon auf die Ergebnisse nächstes Jahr gespannt. Ich hoffe dass die Kategorie in Desktop Shell umbenannt wird, um auch unsere neuen Kollegen GNOME Shell und Unity neben KDE Plasma, GNOME Panel, XFCE, etc. antreten zu lassen.

KDE hat auch ein paar richtig tolle zweite Plätze belegt: Platz zwei hinter Android als "Product of the Year", OwnCload hinter MeeGo als "Best New Open-Source Project", KDevelop hinter Eclipse als "Best IDE", Choqok hinter Gwibber als "Best Microblogging Client". Hier sind auch ein paar neue und vielversprechende Projekte dabei. Gratulation und weiter so. Gerade KDevelop freut mich als Nutzer ungemein – ich muss leider auf Arbeit mit Konkurrenzprodukten arbeiten.

Man kann allen Lesern des Linux Journals nur danken für diese tollen Ergebnisse. Aber natürlich auch Gratulation allen anderen ausgezeichneten Produkten. Ein ganz besonderer Dank jedoch und Gratulation an all unsere Nutzer. Wir können zwar Software für uns selbst schreiben, aber ohne Nutzer ist es halt doch nichts. Und nur Nutzer können uns so tolles Feedback, wie diese Auszeichnungen geben. Daher: Danke

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

Posted on

Unity – Herausforderung und Chance für den freien Desktop

Letzte Woche wurde auf dem Ubuntu Developer Summit von Mark Shuttleworth angekündigt, dass 11.04 mit Unity statt GNOME Shell ausgeliefert wird. Dank Canonical hatte ich die Chance nicht nur die Ankündigung live zu erleben, sondern mich auch intensiv mit den Unity Entwicklern auszutauschen und mir einen Eindruck von der Entwicklung zu bilden. Als KDE Entwickler habe ich hoffentlich einen groß genugen Abstand um die Thematik objektiv zu bewerten.

Der Wechsel zu Unity wird sehr kontrovers diskutiert, persönlich überrascht er mich nicht und ich begrüße insbesondere den Wechsel zu Compiz von Mutter. Die Entwickler hatten sehr starke Performanceprobleme und waren auch mit der Technologie nicht wirklich zufrieden. Compiz stellt dazu im Vergleich einen sehr ausgereiften Compositing Manger da, von dem sich KWin auch schon öfter dankend bedient hat (in umgekehrter Richtung übrigens auch). Mutter hingegen hat ein Design, dass Austausch weder in die eine, noch in die andere Richtung möglich macht.

Viele Anwender hätten sich in 11.04 GNOME Shell gewünscht und das Canonical daran mitarbeitet. Nur wäre das überhaupt denkbar gewesen? Ubuntu wird in 12.04 wieder eine LTS ausliefern. Auf diese wird Canonical drei Jahre Support gewähren. Die Frage ist, ob GNOME Shell bis dahin ausgereift genug ist. Was aber wenn nicht? Weiter auf GNOME Panel setzen, auch wenn es im Prinzip von Upstream aufgegeben wurde? Für Canonical war das sicher keine einfache Entscheidung und es ist eine Herausforderung – darauf hat auch Mark in der Keynote hingewiesen.

Die Frage ist ob Mutter und GNOME Shell bis 12.04 ausgereift genug wären. Meiner Meinung nach ist das ziemlich undenkbar. Dies basiert nun hauptsächlich auf meiner Erfahrung als Entwickler an KWin. Mit 4.0 haben wir Compositing als zusätzliches Feature eingeführt, ein Jahr später mit 4.2 standardmäßig aktiviert. Wir haben uns also ein Jahr Zeit gelassen es out-in-the-wild zu testen. Dies ist bei Mutter so noch nicht wirklich geschehen. Ich weiß wie viele Änderungen wir vorgenommen haben, um den Compositing Stack performant zu bekommen – und dabei hatten wir den Vorteil uns an Compiz bedienen zu können. Wir haben den Vorteil, dass wir sowohl einen Fallback auf XRender als auch auf klassisches 2D rendering haben. Bei GNOME Shell ist dies nicht möglich. Ein anderes Thema ist die Frage ob die Shell funktional ausgreift ist. Schaut man sich an, wie lange es dauert bis so etwas ausgereift ist, denke ich nicht dass dies der Fall sein wird. Natürlich gilt für Unity in diesem Punkt das Gleiche.

Nun zum Punkt der Zusammenarbeit mit GNOME Shell. Canonical hat sehr klare Ideen wie der freie Desktop aussehen soll – ob man das nun gut findet oder nicht ist ein anderes Thema. Die Möglichkeit von Canonical Einfluss auf die GNOME Shell zu nehmen scheint nicht zu existieren. Keine der von Canonical vorgeschlagenen Neuerungen wurden aufgenommen – gerade was den Status Notifier/Indicator angeht ist das sehr schade, denn damit wird auch eine freedesktop.org Spezifikation verhindert. Persönlich habe ich auf der UDS die Erfahrung gemacht, dass Canonical ein sehr großes Interesse an guter Zusammenarbeit hat und KDE für die existierende Zusammenarbeit dankbar ist und auch sehr begrüßt dass KWin und Compiz in vielen Bereichen zusammenarbeiten. Nun da Kernentwickler von Compiz bei Canonical angestellt sind, bin ich persönlich zuversichtlich, dass sich die Zusammenarbeit verbessert. Angesichts der ablehnenden Haltung Seitens der GNOME Entwickler gegenüber Canonical Neuerungen und der Tatsache, dass GNOME Shell bisher fast nur vom Konkurrenten Red Hat entwickelt wird, ist es nicht überraschend, dass Canonical lieber etwas eigenes programmiert, als auf eine Shell zu setzen, die weder ihre Ziele verfolgt, noch darauf Einfluss nehmen kann.

Persönlich denke ich auch, dass Unity für GNOME insgesamt ein Gewinn ist. Wie Mark in seiner Keynote sagte, ist Unity zwar nicht die GNOME Shell, trotzdem eine Shell für GNOME. Mich persönlich hat die GNOME Shell von den Design Dokumenten her, nie überzeugt und ich halte vieles für unglaublich falsch (ich behaupte mal frech, dass ich ein bißchen was von der Entwicklung einer Desktop Shell verstehe). Hier sehe ich eine große Chance für die freie Software und für GNOME. Die Zeit der einen Shell für alle und die Frage zwischen GNOME oder KDE ist wohl endgültig vorbei. Es gibt je Aufgabengebiet eine andere Shell und je Zielgruppe. Viel wichtiger als GNOME Shell oder KDE ist doch ob die Shell den Anforderungen der Zielgruppe gerecht wird. Und ich denke, dass Ubuntu nun eine Shell baut, die auf ihre Zielgruppe gerichtet ist. Das dürfte eins der Probleme sein mit Unity: viele der heutigen Nutzer gehören nicht zur Zielgruppe. Ubuntu strebt mehr an, als den ca. 1 % Marktanteil, den Linux aktuell wohl so hat. Aus diesem Aspekt heraus, ist die größere Vielfalt durch Unity nur zu begrüßen.

Abschließend möchte ich noch einen Hinweis geben an all die, die nun meckern und mit Wechsel der Distro drohen: Auch GNOME Panel wird auf der Live CD enthalten sein, denn Unity benötigt OpenGL und FBOs. So wird ein NVIDIA Nutzer auf der Live CD kein Unity haben können – wir haben das auf dem Summit durchaus diskutiert (hab da auch ein Interesse dran aus KWin Sicht). GNOME Panel ist also weiterhin vorhanden. Und dann möchte ich darauf hinweisen, dass die Ankündigung auch hätte sein können, dass Ubuntu auf Plasma wechselt – angesichts der Architektur zum Erstellen eigener Shells wäre dies auch nicht überraschend gewesen. Sogesehen ist GNOME noch ganz gut weggekommen 😉

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

Posted on

KWin Bug Day am Sonntag 10.10.10

Wie gerade auf dem Dot angekündigt, wird morgen der erste KWin Bug Day sein. Es geht darum die immer größer werdende Zahl an offenen Bugs zu ordnen. Dazu gehört Bugs zu reproduzieren oder auch zu überprüfen ob Bugs überhaupt noch gültig sind, oder ob wir sie schon längst behoben haben. Hierzu braucht es überhaupt keine Programmierkenntnisse, eine aktuelle KWin Version ist völlig ausreichend. Daher meine Empfehlung: Morgen Update auf Kubuntu 10.10 und danach ab 13 Uhr im #kde-bugs IRC Channel auf FreeNode vorbeischauen und mithelfen.

Schon mal im Voraus vielen Dank an alle, die mithelfen 🙂

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

Posted on

Entscheidung des Presserats zum Chip Artikel Betriebssysteme im Härtetest

Man erinnert sich vielleicht noch an den Betriebssystem Test zwischen Windows 7, MacOS Snow Leopard und Kubuntu in nicht definierter Version letztes Jahr in der CHIP und auf Focus Online. Ich hatte den Artikel damals auch etwas auseinandergenommen. Zusätzlich hatte ich auch eine Beschwerde beim Presserat gegen den Artikel bei Focus Online eingelegt. Motiviert hat mich vor allem, dass über Tage hinweg jedes mal die selbe Werbeanzeige zu sehen war und immer noch zu sehen ist:

Ich sah in der Werbeanzeige für Windows 7 einen klaren Verstoß gegen den Trennungsgrundsatz von redaktionellem und inhaltlichem Bereich wie er nach Ziffer 7 des Pressekodex nicht gestattet ist. Zusätzlich habe ich mir einen der vielen redaktionellen Fehler herausgepickt und eine Beschwerde wegen Verstosses der Sorgfaltpflich (Ziffer 2) eingelegt. Dazu hab ich den Bereich ausgewählt, bei dem ich mich am Besten auskenne und auch persönlich involviert bin (mittlerweile bin ich Miturheber der angeblich fehlenden Funktion und würde daher nun zum Mittel der Gegendarstellung greifen statt den Presserat anzurufen):

Nach nun etwa einem Jahr kam die endgültige Enscheidung: "Beschwerde begründet, keine Maßname, Ziffer 2"

Eine Verletzung des Trennungsgrundsatzes liegt nicht vor, da die Platzierung der Werbung angeblich nicht beeinflusst werden kann. Als Informatiker halte ich diese Aussage für nun ja nennen wir es schwachsinnig. Ein einfaches Tag-System würde bereits ausreichen um zu garantieren, dass bei einem Artikel zu Windows 7 keine Werbung dafür erscheint. Wäre für die Redaktion sehr hilfreich, da man dann nicht annehmen würde, dass der Artikel gekauft ist.

In Bezug auf die KWin Funktionalität hat die Redaktion dem Presserat auch eine Geschichte aufgedeckt, die – ich kommentiere das hier nicht weiter sonst wird es unfreundlich. Der Presserat hatte diese Geschichte der Redaktion abgekauft und die Beschwerde ursprünglich als unbegründet zurückgewiesen. Nun ja ich mag es nicht wenn man über meine Arbeit lügt und habe daher noch einmal geantwortet und Widerspruch eingelegt. Habe die Stellungsnahme der Redaktion auseinandergenommen und darauf hingewiesen, dass ich ehrenamtlicher Entwickler der Anwendung bin, die besagter Funktion, welche nicht existiert, bereitstellt. Der Presserat hat daruafhin die Beschwerde wieder aufgenommen. Im weiteren Verlauf hat die Redaktion ihre Meinung geändert und bestätigt, dass Kubuntu die Vorschaufunktion besitzt, aber sich auch ein neues Märchen ausgedacht, von wegen auf Ati funktioniert das nicht (hmm welche Karte verwende ich? Ach richtig Ati). Für mich ist das eine weitere Bestätigung, dass die Redaktion eine Entwicklerversion getestet hat, bei der manchmal halt der Catalyst Treiber nicht verfügbar ist. Schwachsinn ist das ganze dennoch, da ich bereits in meiner Stellungsnahme auf die XRender Funktionalität hingewiesen hatte. Ich spiele mit dem Gedanken nun noch einmal an den Presserat zu schreiben ohne erneut Widerspruch einzulegen. Im Gesamten sieht der Presserat nun aber doch die Sorgfaltpflicht verletz und hält die Beschwerde für begründet. Jedoch wird keine Maßnahme ergriffen, da online die Bildbetitelung abgeändert wurde:

Kubuntu-Linux: Eine Übersichtsfunktion für offene Fenster ist serienmäßig auf Systemen ohne OpenGL-Grafikbeschleunigung nicht verfügbar.

Nun ist das eigentlich immer noch genauso falsch, denn serienmäßig ist XRender verfügbar, jedoch standardmäßig nicht aktiviert. Die gesamte Entscheidung des Presserats hab ich als PDF hinterlegt.

Fazit: der Presserat ist ein Papiertiger. Bei einer Beschwerde schenkt er der Redaktion mehr Glauben als dem Beschwerdeführer und führt keinerlei unabhängige Überprüfung durch. Selbst nach einem Widerspruch wird die Aussage der Redaktion nicht noch einmal gegengeprüft (ich hätte das mit der Ati Karte gerne noch einmal auseinandergenommen bevor der Pressearat berät). Für mich war das meine erste Beschwerde beim Presserat und ich vermute, dass es auch meine letzte bleibt.

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