I am Matthias Klumpp and I will work on making AppStream work for openSUSE as part of the Google Summer of Code this year. I study Molecular Biomedicine in my second semester in Germany and I use Linux for years now.

I contribute to KDE (mainly to Apper, the PackageKit-based KDE package manager) and I am PackageKit upstream developer, as well as the maintainer of Listaller, a cross-distro application installer, which has the goal to make installations on multiple distributions using just one package as easy, secure and integrated as possible. (Yes, repos and native packages have some issues, just before you ask the obvious question ^^)

I’m not really a typical KDE user, as I also use GNOME from time to time and contribute to GNOME (but just very unimportant things for now). Knowing both desktops and both communities is usually an advantage, and therefore I very much enjoyed the last Desktop Summit in Berlin.  If you’ve been there, you might have met me there already

I am Debian Maintainer and maintain all PackageKit and most PackageKit-related packages there. This means I also use Debian, so doing a project for openSUSE might look strange on the first look. But’s it’s not strange at all: I’m working on a cross-distro project so the distribution doesn’t matter that much. And I already know openSUSE. In fact, it was SuSE 9.3 I guess, which was the first Linux distribution I ever tried. And I used (open)SUSE 10.x for a long time, until switching to Fedora, Debian, Ubuntu and then back to Debian. (The (K)Ubuntu->Debian switch was political, but now Canonical is giving me technical reasons too… – But better not talk about that issue, otherwise this blogpost will become way longer than I want it to be ) Anyway, openSUSE is already running here again (in a VM for now) and I already did some modifications on the Software-Center, after reactivating my Python skills. (which are small, but good enough – I like Vala/C/C++ more) Next few weeks will be about getting to know the openSUSE community and reading Python-code.

In general kudos to openSUSE for doing the cross-distro tasks which no other distribution does. OpenSUSE has always been the distribution with the highest activity in this area, although they could’ve said “we don’t care about collaboration and interoperability”, which would’ve been perfectly sane. My greatest respect for that open-minded attitude and I’m really happy to work with you all!

This will be an exciting time!

A great present ^^ The Tux is now sitting next to my desk and I hope he will have some helpful programming tips, if I ask him Speaking of this, there are some other awesome news: I will participate in the Google Summer of Code this year!

Originally, I applied for developing a collaborative text editor using Telepathy for KDE, but I haven’t been accepted. (given the facts that the KDE-Telepathy team got only two free slots, not surprising that other tasks have priority, which are even more awesome) I also though of applying for some GNOME projects, but because the application period was right in my exam-phase, I haven’t had the time to write many applications. So I wrote two proposals concerning the AppStream project: One to fix the GUI package manager infrastructure on Debian, which is badly needed to implement some more new and exciting features as well as implementing DEP-11, our proposal for AppStream data on Debian, in DAK, the Debian Archive Kit. The second one was a similar proposal for openSUSE, which is making the Ubuntu Software Center usable on openSUSE and other distributions using PackageKit. And – what should I say – I got accepted for the last one!

Because I live in the Debian-world, working on a cross-distro project on openSUSE will be a completely new experience for me. But because I already do stuff regarding cross-distro software and develop PackageKit upstream, this project is just perfect! Depending on the timeline, I’ll also be able to work on other components upstream to implement AppStream and PackageKit features, so that we will have a great experience for installing new software on all distributions.

Thank you openSUSE for accepting me and kudos for the cross-distro slot of your GSoC! It would be easy and absolutely fine to say “let the students just work on our stuff, we don’t care about other distributions”, but openSUSE explicity has GSoC proposals to work on cross-distribution collaboration. No other distro does that (AFAIK). I’m looking forward to the next weeks!

[1]: The rewrite is young. The project itself started in 2008/2009.

What is Listaller?

So, what the hell is Listaller? Listaller is a solution which will make it possible to install 3rd-party applications on Linux-distributions easily. You might say now, that we have a package-manager for this. But what do you do if your favourite package is not available in the repos? Ubuntu users will just add a PPA, and by doing this practically give someone else full root-access to their machines and potentially break system upgrades. That should never ever happen, and PPAs are therefore dangerous stuff, which is useful but should better be used by people who are aware of what they’re doing. PPAs are an overkill if you just want to have the newest version of GIMP. Right now, software relations on Linux look like this:

Lots of packages depending on each other. You can’t replace one of them without breaking the others. Listaller now does this:

Users will get a package, which provides an application. This application-package (extension *.ipk) declares dependencies on components in a distro-agnostic way. Listaller will then try to satisfy these dependencies at install-time, by downloading the right dependencies and installing them side-by-side with the native packages. By doing this, the system itself is left unaffected by the changes and application installations will only affect a very small part of the system. Therefore, Listaller packages are much more secure than native packages. Of course there are limitations: Listaller packages were designed to install 3rd-party applications. Applications for example are games, a web browser, image-editing tools etc., but not system components like PolKit or full desktop-environments. So you won’t be able to install these using an IPK Listaller package. You still have to rely on your native package manager there. But for most users, features Listaller provides are enough and might also give some additional freedom to the users as some people think. (incuding me)

So, now the cool stuff: Listaller is integrated into the system. This means that users won’t notice Listaller is there and working, because they continue using the tools they already know. There is no duplication of tools when using Listaller. Listaller is plugged into PackageKit, the cross-distro package-management abstraction layer, and frontends can communicate with Listaller using the PackageKit API. This means you can install applications using GNOME-PackageKit or Apper and they will show up just like native packages in their software managers. Even updates will be done through the system’s updater.

Of course, you can compile in additional Listaller support, for example compiling Apper with -DLISTALLER=ON will give you a nicer Listaller package installation UI, which exposes some more of Listaller’s features:

Of course, this is optional. The KDE frontends are in a really good shape right now, the GNOME side needs some love and an UI designer, but it also works.

What’s new?

So, what is new in Listaller 0.5.4? We now require that you use the DOAP RDF Format to describe the project you want to package.Most projects already provide DOAP data, and creating it is really trivial. The new release also makes it possible to embed more architectures in one package, which is especially nice for some games with small binaries and a large amout of data. They now just need to ship one package.

Listaller also allows setups to declare a “replaces” dependency on existing software. For example a IPK packaged version of Firefox could declare a replacement on “/usr/bin/firefox”, so users get a message that they might want to remove the native distribution package after they installed the new 3rd-party app. I’m not super-happy with this feature, so please use it carefully! Please note that Listaller still won’t remove any native package automatically.

It is also now easier for packages to ship license texts, they just have to link a file called “license.txt” in the IPK package source directory.

Also, options to GPGsign a package have been improved. GPGMe API is not really nice to work with, so with the improvements, the ability to check signature trust levels has gone missing, but I’ll add this again in the next release. (This check was broken anyway) That’s the reason why even signed packages now will only get a maximum trust level of “low”.

This release also contains many other improvements and bugfixes, for example we no use /var/tmp instead of /tmp for temporary data, just to make Lennart happy.

What’s missing?

Listaller needs help! After rewriting the tool, many features went missing and need to be implemented again, as well as there are some things which are planned and just not implemented because nobody did that

For example, dependency resolving sucks at time, there are many parts which have to be improved. I will finish policy for dependencies soon and then this can be done properly. (by using or not using ZI feeds) First steps are already completed.

Also, there is no Listaller Updater at time, a feature which is probably one of the most important things.

There’s also a sandboxing feature planned, so 3rd-party applications can be executed in a sanbox by default, so the system and user data remains safe even if users install stuff not checked by the distributor. The difficult thing about this will be picking a sandbox-solution. The Listaller implementation will be easy, everything is already there. And of course, the project needs bug-fixing work! ^^

We also require people to create IPK packages. The process of doing that is extremely easy. Yes, we inherited parts of Autopackage, but creating a Listaller package is definitely easier than creating an Autopackage.

All of these features will be implemented with the next releases of Listaller, if we follow the roadmap.

We need help!

If you are a developer and like developing in Vala and C, we need you! If you don’t know Vala, no problem, it’s really easy to learn and I can help. You could also create packages or translate the project.

Also, for distribution packagers: Some people wanted to include Listaller packages in their distribution’s repos, but I said “please, not now”, because Listaller was in an experimental state at that time and I didn’t want to disappoint users with alpha-software. Now, we need Listaller packaged in distributions, so if you still want to do that, do it now!

Try Listaller?

You can download Listaller from the Download Page. You will at leas need PackageKit>=0.7.2, but I recommend using PackageKit 0.7.4, which might be released today. You also need GLib>=2.26, SQLite and Redland to build the software. After installing it, Listaller will start working as part of PackageKit and you will be able to install Listaller packages.

…next steps

I plan to release new Listaller versions every month now, probably in sync with the PackageKit release cycle. Also, testing should be increased and missing features will be implemented, while maintaining the package format backward-compatible, if possible. (Please note that I still will break it if there are good reasons for it!)

In the (very) long term, I could even imagine making the Open Build Service create LI packages, but that’s far future

So, expect some more news on this project later

…what you get if your friends know you’re doing Linux

Falsch gedacht! Eigentlich wollte ich – da ich Skype echt Leid war – selbst Hand anlegen und ein solches Backend schreiben. Der Haken: Das SkypeKit sowie die nötige Dokumentation dafür sowie die Header werden erst nach einer Registrierung bei Skype exklusiv freigegeben. Es ist nicht erlaubt, die SkypeKit-Schnittstellen öffentlich zu zeigen, weshalb ein Telepathy-SkypeKit-Backend nicht im Quellcode (z.B. unter der LGPL) veröffentlicht werden dürfte.

Das bedeutet, dass man selber das Modul als Closed-Source schreiben müsste und dann kompilierte Binaries anbieten müsste – das ist es mir dann auch nicht wert.

SkypeKit behindert mit dem Verbot, es weiter zu verteilen und die SkypeKit Schnittstellen öffentlich zu zeigen, effektiv seine Verbreitung bzw. die Verbreitung in freier Software. SkypeKit ist ausschließlich für Firmen oder ClosedSource Softwareprojekte interessant, solange bis Microsoft die Schnittstellen öffentlich macht und nicht mit Vertrag und Sonderbedingungen verteilt. Die Gründe dafür sind für mich nicht ersichtlich, da das Offenlegen von Schnittstellen mit keinem einzigen Nachteil für das Unternehmen verbunden wäre. Man könnte annehmen, dass Linux bzw. freie Software absichtlich ausgeschlossen werden soll, aber das wäre vermutlich zu simpel gedacht. (Obwohl ich es Microsoft ohne Probleme zutraue)

Was also tun? Auf das Reverse-Engineering des Skype-Protokolls warten? Meiner Meinung nach sollte man nicht zusehr darauf hoffen. Das Projekt macht zumindest auf mich keinen so guten Eindruck. (Ich wünsche mir aber, dass es funktioniert!) Stattdessen wäre es sinnvoller, alle Anderen zu überzeugen, Skype nicht zu nutzen und sie auf Alternativen hinzuweisen, in diesem Fall z.B. ein XMPP-Server mit Jingle-Erweiterung.

Ist die Gegenseite auf Windows zu Hause, ist es wohl am stressfreiesten, einen Google-Account zu empfehlen. Google bietet darüber einen XMPP/Jingle Chat an, der einfach zu bedienen ist. Bestehende XMPP/Jabber Nutzer können sich problemlos mit Google-Nutzern verbinden und Voice&Videochat nutzen. (In GNOME/Empathy wurde dieser gerade überarbeitet, in KDE-Telepathy ist das Modul noch experimentell) Wer kein Google benutzen will, kann auch auf andere Anbieter, z.B. Jabber-Server.de zurückgreifen, wichtig ist nur, dass der Server die Jingle-Erweiterung und damit Videochats unterstützt, um Feature-Gleichheit mit Skype zu erreichen. Der Haken für Windows-Nutzer besteht darin, dass es (zumindest so weit ich weiß) noch keine guten Clients für XMPP-Videochats unter Windows gibt. (Google bietet dafür ein Plugin, welches aber nur mit Google funktioniert) Linux-Nutzer müssen sich darüber keine Gedanken machen.

Das größte Problem, ist das Überzeugen der Mitmenschen, sofern das überhaupt möglich ist. (Eventuell benötigen einige Skype beruflich) – Dann steht der skypefreien Zone aber nichts mehr im Weg. Ich sehe keine gute Zukunft für Skype unter Linux, alleine der ungewartete Zustand des offiziellen Skype-Clients lässt das nichts gutes hoffen. – Vielleicht überrascht uns Microsoft aber auch noch, wer weiß?

Color management is present in all modern operating systems, including Microsoft Windows and Apple OS-X, as well as GNOME has support for it since 3.0 (AFAIK).

Having color management on machines used for creative tasks (like painting/photography, etc.), is very important, because the human eye can only capture a certain range of colours as well as digital devices can only produce/display a specific range of colours. So you have different colour-spaces between devices, your printer, your screen, your camera:

When the graphics are processed by devices using different colour-spaces, you get results like this:

To keep the “genuine” colours of graphics while processing it, ICC profiles are used to translate between different colour-spaces. ICC is an ISO standard and used in many (all?) operating systems. It is supported by most image-processing devices.

colord now is (as you might guess from the name) a D-Bus activated system daemon to manage, install and generate color profiles to accurately colour manage input and output devices. colord is a Freedesktop.org project and therefore not tied to GNOME or any other desktop. But at the moment, only GNOME provides support for colord in it’s settings panel, so integration in KDE is wanted . Richard Hughes, the author of colord, offers is help when someone wants to write a KCM for colord, which would be great to get full colour-management support on KDE too. Working with Richard is great, I am working with him on the PackageKit project, which really is a pleasure. You just need to make very clear, why a certain bigger change is required and what the benefits are. (but that’s a good aspect for project maintainers, IMHO)

Unfortunately I am very busy with Listaller, PackageKit/Apper/Debian-DEP-11 and university stuff at the moment, so I can’t do much for this task. But of course I’d be willing to help a little, if I can, if someone would like to take this task.

P.S: If you find it weird that I first write about making System Settings easy to use and then ask for another KCM: The System Settings project hasn’t finished with the last blogpost, I’m already planning some stuff based on the comments on the last post. I’ll write about it soon. (But as always, the critical factor is time…)

EDIT240212/12:24: Do be fair, I want to mention that there already is a “color-management” module, called Oryanos. At time, it looks like nobody makes use of it, although it has already been around for years. colord, in contrast, is already used by a wide variety of other tools and libraries, for example CUPS and GTK+. To be honest, I cannot really judge which technology is better, but I can see that the adoption of colord is far greater, while colord is the younger project. This means that colord seems to provide the necessary components, is functional & stable.

There is a FAQ-Document available, describing why colord was created instead of fixing Oryanos, it’s very interesting to read and describes nicely why colord is preferred.

This post was planned to be just a hint for interested people to see that the colord project is looking for KDE developers (there are already a few who are interested), but it looks like I ran directly into the colord vs. Oryanos crossfire.

Was ist Freiheit?

Die BSD-Fraktion bezeichnet sich immer selbst als die mit der freieren Lizenz und bezichtigen den “Gegner”, Copyleft-Lizenzen wie die GPL, Freiheiten einzuschränken. Umgekehrt, nur mit etwas anderer Argumentation, werfen die GPLer das auch den BSDlern vor. Wer hat also recht? Welche Lizenz ist die “freiere”? Die Antwort ist so einfach wie verwirrend: Beide haben recht. Es kommt nämlich ganz darauf an, wie man Freiheit definiert bzw. welche Freiheit man betrachtet.

Die GPL-Lizenz zwingt den Programmierer bzw. die Firma, die den GPL-Code nutzt, alle Änderungen ebenfalls mit den binären Dateien zu veröffentlichen und denjenigen, die die Binärdateien erhalten, zugänglich zu machen. In der Regel ist das die Allgemeinheit, da jeder die Binärdateien erhalten kann, in einigen Fällen müsste aber der Code auch nur dem jeweiligen Auftraggeber zugänglich gemacht werden, der das Programm bestellt hat, und alleine die Binärdatei erhält. (Somit müssten also Änderungen, die intern in der Firma verwendet werden, gar nicht veröffentlicht werden. Bei Webanwendungen ist das mitunter ein Problem, wofür die AGPL geschaffen wurde) Die GPL-Lizenz forciert also insgesamt die Freiheit des Codes.

Die BSD-artigen Lizenzen ermöglichen es der Firma, jegliche Änderung am BSD-Code als Closed-Source zu behalten, ein Veröffentlichungszwang existiert nicht. Einzig die Autoren der BSD-Software müssen irgendwo genannt werden. Da BSD-Code quasi beliebig verwendet werden kann, ohne zusätzliche Pflichten aufzuerlegen, steht hier die Freiheit des Entwicklers im Vordergrund.

Spricht man über freie Software, muss man also immer überlegen, wie weit die Freiheit geht, bzw. was genau die jeweilige Freiheit ist.

Beide großen Lizenzen, GPL wie BSD, sind nach der FSF zulässig für “freie Software”, also im Grunde gleich frei.

Das System GPL

Die GPL-Lizenz stellt sicher, dass Code, welcher unter der GPL veröffentlicht wurde, auch für immer offen bleibt und alle Änderungen ebenfalls veröffentlicht werde.

Der Hintergedanke dabei ist, dass wenn jemand das Projekt eines Entwicklers X benutzt und verbessert, dieser dann seinen Code veröffentlichen muss, der dann wieder in das ursprüngliche Projekt einfließt. Somit wird das Projekt immer besser, je mehr Leute es nutzen.

Die GPL etabliert also ein System von “geben-und-nehmen”. Dabei ist es relativ problemlos möglich, GPL-Lizenzierten Code in Closes-Source Softwareprojekten zu verwenden, anders als oft behauptet. Einzige Bedingung bei der GPL: Der Code muss separat kompiliert werden und die Closed-Sozrce Teile dürfen keinen GPL-Code enthalten. (Sonst müssten sie ja im Sourcecode freigegeben werden) Das führt zu Problemen, wenn Bibliotheken unter der GPL stehen, denn durch das linken gegen diese würde der Closed-Source-Code ebenfalls “GPLifiziert”. Dafür gibt es dann die LGPL, die das Problem umgeht, indem sie einige Ausnahmen zur GPL hinzufügt. Wenn eine Firma also LGPL-Code benutzen will, muss sie diesen nur in eine extra-Library auslagern und ihren Closed-Source Code dann gegen diese linken. Einzig die Änderungen am ursprünglichen LGPL-Code müssten dann publiziert werden.

Das System BSD

Bei der BSD-Lizenz kann der offene BSD-Code beliebig mit dem Closed-Source Code vermischt werden. Man kann also geziehlt einzelne Module aus dem Code in seinem Projekt verwenden, ohne sie in irgendeiner Form auszulagern. Das ist für viele Firmen natürlich angenehmer, da man nicht darauf achten muss, ob man die GPL-Lizenz verletzt.

Änderungen an BSD-Code können, müssen aber nicht an das ursprüngliche Projekt zurückgegeben werden. So konnte z.B. Apple aus einem BSD-System sein MacOS formen, ohne es im Code freizugeben, war aber gleichzeitig bei seinem KHTML-Fork WebKit dazu gezwungen, dieses im Code freizugeben, da KHTML unter der LGPL-Lizenz stand.

Fazit & Meinung

Im Prinzip müsste es für Unternehmen problemlos möglich sein, GPL-Code zu verwenden und auf dessen Lizenz zu achten. Kleinere Unternehmen schaffen das, und größere mit einer so riesigen Rechtsabteilung wie der von Sony müssten erst recht dazu in der Lage sein.

Klar ist die GPL ein Mehraufwand und schränkt die Flexibilität eines Entwicklers ein wenig ein, aber man muss ihr zugutehalten, dass mit der Freiheit des Codes, den die GPL propagiert, in der Regel auch die Freiheit des Nutzers einhergeht. Klar, nicht jeder kann den Code selber anpassen oder kontrollieren, aber von den Veröffentlichungen von denjenigen, die sowas können, profitiert am Ende auch der ganz normale Endnutzer.

Das alles sind keine Argumente gegen die Verwendung der BSD-Lizenz – und ganz ehrlich, für den durchschnittlichen, freien Entwickler fallen mir auch keine ein. Das ist eine Sache persönlicher Vorlieben. Anders herum kann es in manchen Fällen durchaus sinnvoll sein, die GPL bzw. eine andere Copyleft-Lizenz nicht zu nutzen. So steht z.B. Googles WebM-Projekt under der BSD-Lizenz. Das macht es einfacher, das Format zu verbreiten, da man BSD-Code, solange man den Namen der Autoren erwähnt, beliebig nutzen kann. Das ist für Unternehmen wir bereits gesagt weit weniger aufwändig als die Verwendung von GPL-Code, womit sich WebM im Unternehmensbereich schneller verbreiten kann.

Meine Projekte stehen alle unter der GPLv3 oder LGPLv3, da ich nicht erwarte, das eine Firma – sollte sie auf die Idee kommen, den Code zu verwenden – ohne irgendeinen Anreiz wieder Code an das Projekt zurückfließen lässt. Warum auch? Firmen arbeiten kapitalistisch, wenn sie also die Werte, die sie selber schaffen freigeben, ohne Gewinn zu machen, ist das höchst unlogisch, sofern das Geschäftsmodell der Firma aus dem Varkauf von Closed-Source-Softwarelizenzen besteht. (dass es anders geht, zeigt das Beispiel RedHat)

Die GPL-Lizenz zwingt nun quasi ein Unternehmen, ebenfalls etwas beizutragen. Durch den viralen Effekt der GPL, wird das Projekt nach und nach immer besser. Ein Beispiel ist Linux. Man kann zwar nicht wissen, wie es ausgesehen hätte, wenn Linux unter einen Non-Copyleft-Lizenz wie der BSD-Lizenz gestanden hätte, aber ich würde jede Wette eingehen, dass der Kosmos and Firmen und freien Entwicklern, die gemeinsam an Linux arbeiten ohne GPL nie zustande gekommen wäre.

Im Gegensatz zur Meinung einiger fordert die GPL auch nicht, den gesamten Code eines Projektes herauszugeben. Lediglich die GPL-Teile müssen veröffentlicht werden, was ich akzeptabel für alle Seiten finde.

Im ganzen Streit um die GPL scheint ziemlich viel Unwissen vorhanden zu sein: So kenne ich z.B. ein Unternehmen, in dem noch immer der GCC (GNU C Compiler) in Version 3 eingesetzt wird, obwohl es bereits Version 4.6 gibt. Warum? Die neueren versionen des Compilers sind GPLv3 lizenziert, die älteren GPLv2. Die GPLv3 erhebt ein paar weitere Ansprüche, z.B. enthält sie eine Art eine “anti-DRM-Klausel” und erzwingt die Lizenzierung von Patenten an den Nutzer des GPL-Codes. Weiterhin wurde die Kompatibilität mit anderen Lizenzen verbessert. Im Grunde gäbe es keinen Grund, die GPLv3 bei einem Compiler (!) zu umgehen, aber anscheinend sind die Unterschiede zwischen den GPL-versionen nicht gut genug bekannt.

Zur aktuellen Debatte: Sony hat jedes Recht, einen Busybox-Ersatz unter einer X-Beliebigen Lizenz nachzuprogrammieren. Die Ausführungen wirken aber so, als ob Sony die Community dazu brigen will, ihnen einen Busybox-Ersatz zu bauen, was ich wiederum ziemlich dreist finde. Mal sehen, wie sich das Ganze entwickelt, ich hoffe aber, dass sich die Antipathie gegen die (L)GPL mit der Zeit legt und Lizenzen sinnvoll gewählt werden.

Beide, die GPL- und die BSD-Lizenz, haben ebsolut eine Daseinsberechtigung und keine ist “besser”. Lediglich der Fokus beider Lizenzen und die Definition von “Freiheit” sind bei den Lizenzen anders gewählt.

Für die, die Interesse haben empfehle ich den Blogbeitrag von Bradley M. Kuhn (englisch) zum Thema Copyleft-Lizenzen und Firmen.

Bei allem, was oben steht möchte ich noch anmerken, dass ich kein Jurist bin und auch nicht selbst in einer Firma arbeite. 8Dennoch ist es natürlich möglich, Informationen zu bekommen )

Recently, I installed KDE on a friend’s computer. As always when I install Linux for someone who never used it before (just saw it on my computer) I let him play with the desktop environment, without giving any advice and without showing what you can do with KDE. (and to be honest, I always enjoy this moment!) He was impressed by the overall speed and the possibility to customize everything (although it took some time to understand how the widget system works). But in this case he also made one experience which bothered me too for a very long time and which lead to this post: The System Settings of KDE are a horror to use for new, non-technical users. Please let me explain why.

The problems

Let’s start with this first thing people see when running “systemsettings”:

You see a bunch of icons, categorized into “Common Appearance and Behavior”, “Workspace Appearance and Behavior”, “Network”, “Hardware” and “System Administration”. And the problems to new, non-technical users start right here: What is the difference between “Common” and “Workspace” behavior? For all users, the workspace and all applications are the “common” thing, so they can’t see the difference. (For developers, of course, this is obvious)

Second thing: Why are “Account Details” and “Personal Information” in the “Common Appearance & Behavior” section, when they have nothing to do with behavior or appearance? And what is the difference between “Personal Information” and “Account Details” anyway? Well, let’s open the “Personal Information” setting, because I want to change my e-mail address, which is a personal information, right?

Oh… Technically, it is sane to put the personal resources under “Personal Information”, but this is not what users expect. Also, did you recognize that “Personal Information” and “Account Details” have the same icon? How should users see the difference? This “same icon problem” is also present in the two modules which control appearance:

This might look as a very, very small issue, but it is a very bad thing for what people call “user experience”. Why do we have “Workspace Behavior” and “Application Behavior” anyway? Users open the system settings with something like a mission, e.g. “I want to change the look of my desktop” – while it’s technically correct to separate between applications and the workspace itself, users don’t care about these details.

Let’s go down the System Settings page and take a look at the hardware section: You’ll find an entry “Information Sources” there. What the hell are “information sources”? To provide some more information, the System Settings provide tooltips to help users find what they need or to explain something:

Oh cool! “Hardware Integration Configuration with Solid” – While all people developing stuff for KDE of course know what Solid is, users really don’t know and don’t want to know it, which makes this tooltip a pretty useless information. If you open the “Information Sources” module, you also get stuff to see which is not useful for the average, non-technical user. So in the end, this entry for example should be hidden by default. Also, no user know what “Phonon” is and what backends are for. All these settings, including options to change user’s $HOME path for example, are not relevant for end users. They just want a working system and might do small modifications, and they don’t want to be confused by many strange-looking settings if they just want to change their desktop design. It is extremely hard to find the particular setting you are looking for, if it is hidden by thousand other settings you can apply.

As you can see, there are four main-areas where KDE’s System Settings are a problem to new, non-technical users:

• The settings are crowded and it’s difficult to find stuff you change often between settings you probably never (want to) touch.
• Some sections have confusing names
• The separation of settings is confusing: Stuff which belongs together is separated, and some stuff is together which should be separated.
• Technical terms are still used in the settings
• (Icons are the same for some stuff)

Let’s do something weird…

…and look at what the GNOME folks did:

The first thing you can see is that they copied the layout KDE already used . You can also see that they show only very few modules by default, separated into only three categories: “Personal”, “Hardware” and “System” This makes it very easy for new users to find the stuff they want. Also, you don’t see technical details here, e.g. if you click on the “Sound” button, you won’t find a single word about PulseAudio. Also, they don’t show many settings, they pick good defaults which fit for most users and show a settings UI for the stuff which most users want to change (e.g. the Background, Passwords or Sounds) There is no chance that users get lost in too many settings.

The solution…

…is of course not to copy what GNOME did! As much as I like their approach of making settings simple for new users, it also brings many disadvantages. The biggest problem is that users who want to customized their GNOME desktop a little bit more than the GNOME devs think it is necessary, have to dig into config files and the DConf system – and this definitely can’t be the solution since we want to create a great desktop for beginners as well as for professional users and for people who want to customize everything. So we should not remove useful settings. Certainly there are thinks some people want to to change where others think this setting is useless because they never changed it.

So, what should we do instead? First of all, pick good defaults. The best settings are the ones you never want to change because they are already set to a good default value. Finding these defaults is hard (meaning some user-surveys), but in the end the overall experience is better.

I would also like to propose two modes for the System Settings: One “Basic Mode”, doing something similar than the GNOME Control Center by just showing essential elements and stuff which is changed often, and one “Advanced Mode”, showing all settings. We already have “Settings for the Settings” (which is also a strange thing ), so adding this to the UI shouldn’t be a problem. (It might break the control module API, because each module would have to check if it is running in advanced mode or not, so this might be something for KDE5) – Of course this is just a suggestion which I find useful, but there might be reasons against doing it

For all the other stuff, there really needs to be a discussion about how to group the settings and maintainers of control modules need to look how they can improve the user experience. A very good example is the Power Management module, which got a much better UI recently.

Der Nutzer darf vor allem wesentlich bessere Musikvisualisierungen in Anwendungen wie Rhythmbox und anderen Musikplayern, die die LibVisual und GStreamer nutzen (Totem) betrachten. Außerdem wird nun der LibVisual-Actor von projectM unterstützt, womit man projectM-Visualisierungen nun fast überall verwenden kann.

Der Patch wird vermutlich in der nächsten GStreamer-Version zu finden sein.

Warum das Ganze 6 Jahre gedauert hat, ist nicht so wirklich einfach zu sagen… Der Fehler wurde – trotz Patch – wohl einfach vergessen und ist in anderer Arbeit untergegangen. Die Ganze Diskussion um dieses Feature kann man in GNOME#310775 betrachten.

Apropos viel Arbeit: Leider hatte ich in der letzten Zeit extrem viel zu tun, weshalb es lange keine weiteren Blogposts gab. Natürlich ist trotzdem so einiges passiert, der Stoff für neue Artikel geht mir also nicht aus. Ich werde auch weiterhin in 2012 Artikel schreiben, vermutlich allerdings nicht mehr sehr zahlreich, da mein Studium doch ziemlich viel Zeit in Anspruch nimmt. Wer will, kann auch auf PlanetKDE vorbeischauen, wo ich auch hin und wieder schreibe.

Ein frohes Fest euch allen und einen guten Rutsch ins neue Jahr 2012!

At time, if you develop a new application “Foo”, you as an upstream developer let other experienced people distribute your application in Linux-Distribution X through a package. Packaging an application is not as easy as some people think, a package of high quality requires some work. And the package wants to be maintained. The upstream -> downstream way we have at time works very nice, although there are some problems:

• It takes time for downstream people (packagers) to package a new bugfix release / a new major upstream release
• If a distribution is frozen (=stable), new upstream major releases aren’t sent to the archives anymore, so users will use an outdated version of an application
• Some stuff is just not packaged, think of proprietary software as an example. But also free software needs someone to step in an package the stuff.
• There are thousands of Linux-distributions. An application needs to be packaged for every single distribution (in the worst case)

To make new software available for users of stable distributions and to offer a possibility for everyone to package stuff, Ubuntu invented [Update] The OpenSUSE Build Service offers a similar, but cross-distro alternative and has been published earlier than Ubuntu’s PPAs. [/Update] the so-called PPAs.

PPAs have great advantages:

• You can install PPAs easily
• You always get fresh updates using the generic Update-Manager
• It is nicely integrated with other parts of the system

People who know me might now want to skip the next section – I am a very well-known critic of PPAs Despite all the great advantages, PPAs also have their issues:

• Security: If a package contains malware, it will have root-access to your full system. You’re practically giving someone else root-access to your system by installing a PPA.
• Quality: Packaging is not only taking the upstream tarball and putting it into a DEB package. There are a lot of quality standards to comply with, if you want a high-quality package. The quality guidelines are defined to keep the Distribution working & stable. Some people might not know how to create a sane package and there is a serious risk to damage the system sooner or later with a “bad” package.
• Upgrades: If you install new versions of a package, old packages provided by your distributor get replaced. And even if you only add new packages, you might break your distribution’s upgrade-path, so an upgrade to a newer distribution-release might fail. (nobody tests with every PPA installed)
• Ubuntu-Centric: PPAs are Ubuntu-only. There’s no Fedora support and no Debian support too. A cross-distro solution would be better.

Because of these issues, I started Listaller, a new approach of a cross-distro software installer. Listaller is based on two great projects: PackageKit and AppStream. The development started years ago, but all old code has been thrown away with the availability of a stable PackageKit and the AppStream project, which covers some Listaller’s former project goals and will reach them in a much better and more generic way than Listaller could’ve done. Listaller is now rewritten in the Vala programming language.

The project was started to offer upstreams the ability to provide cross-distro packages of their applications. This means Listaller was designed to install applications and not libraries or system-components. So, Listaller was not designed to replace package formats like RPM or DEB or to replace package managers like APT/Yum/Zypper/etc. It’s main goal is to extend these systems to offer cross-distro application installations.

The “package”-format of Listaller is a tarball with the extension “.ipk” (Installation-Package) containing a GPG-signature, a XZ-compressed archive with XML control data and a (also compressed) archive with the payload data. This is very similar to the structure of a Debian archive.

Because Listaller works as a PackageKit plugin, all tools using PackageKit will magically get support for Listaller too. So you can remove Listaller-installed software through Apper on KDE and with GNOME-PackageKit on GNOME. Users won’t notice the difference. Same also applies to updates: Users will only see one updater application. This will avoid having many different UIs which do all the same.

How are dependencies handled? By default, Listaller always tries to use native distribution packages as dependency providers. (It searches them through PackageKit) If this does not work, it can make use of ZeroInstall feeds too. (this feature is under construction at time) Listaller distinguishes between applications, dependencies or resources and frameworks. Applications are packaged in an IPK package, while dependencies are fetched from somewhere else and can be used by many applications. Frameworks are something like D-Bus, PolicyKit, PackageKit, Nepomuk or Akonadi, which relies on being integrated with the system. Listaller will never try to install a framework. Frameworks always have to be provided by the distributor. (This has security reasons too, also Listaller just can’t do this cause of it’s design.)

And what about relocatable applications? Well, that’s a big issue. Binaries on Linux usually have paths to their data hardcoded, so they will always search in e.g. “$prefix/share/foo”. But Listaller puts applications and their data into /opt by default, so binaries need to find data independent where they are. To achieve this, we have code called “BinReloc”. Listaller inherited this from the Autopackage project, which has been merged into Listaller some time ago. BinReloc allows software developers to create relocatable applications by integrating it into their applications. For some people this is not necessary anymore: Qt4 already provides some nice methods to create relocatable apps.

To make installed apps find their libraries, every Listaller application is executed using a tool called “runapp”. This tool will set the LD_LIBRARY_PATH variable and run the applications. So you can easily use Listaller-installed tools in scripts. This also avoids collisions with applications in /usr/bin.

Is it secure? Yes, Listaller is secure. Every package should be signed, if it is not, the installer will reject it by default. (Unless you change the settings ) Updating software is easily possible, and Listaller applications will never conflict with native distribution applications, so upgrading a distro is safe. Also, the “runapp” tool is able to execute every newly installed application in a sandbox first, so you can test the application. IPK packages don’t have much possibilities to damage the system, because they don’t contain custom scripts. So, yes, Listaller is secure. Only the user could do the wrong thing

Okay, this was a quick, but still far too long information about what keeps me busy. Listaller has very few developers and to be honest, there was a time where I thought this project would fail. But now I’m sure that working on it is a good activity At time, there are only GNOME-frontends available for Listaller. This is because the Qt bindings aren’t updated and because of me, who is eager to try Smoke-GObject on this project

So, thanks for reading! And I promise, the next post will be more KDE-centric again