I read an interesting blog this morning Freedom vs. The Cloud Log where Glyn Moody interviewed Eben Moglen. Eben Moglen was General Council of the FSF for 13 years and helped draft various versions of the GPL. He talks about the implications for software freedom caused by the rise of services in the 'cloud' where your data is owned by the service provider, and the fact that they don't usually release the code of their applications that run on the servers.

Apparently, with my original posting here, I stepped on several people's toes. I'm sorry for that, and for this reason, I've simply removed this content (and also because - as some of you pointed out - some of the things I mentioned were not Plasma's fault, but workarounds or bugs in other areas, although to me as a user they appeared on Plasma).

It is raining massively, outside, again. It does that every day here, in Manaus, what with it being the rainy season and this being the Amazon jungle. The negativity ends there, though, since it takes about 15 minutes, is very refreshing, and everything else here is Awesome (TM). I have really enjoyed the past few days, Bossa Conference has been a great experience. The presentations were generally of high quality, I had many very good conversations over many excellent meals, and by a luxurious pool, met several impressively talented individuals and the equally impressive INdT teams. There is a lot of very nice work being done here in Brazil in Free Software in general and around Qt and KDE in particular. I'm proud to have been invited to come.

Aaron, Sandro, moofang, Shantanu and Diego have been hacking up a Plasma storm lately on the Javascript bindings for Plasma and the Plasmate builder tool. Since good code is running code, and running code is a lot easier when somebody else builds it and packages it, I've updated the Plasmate packages in KDE:KDE4:Playground to 0.1alpha2 and have updated the javascript bindings in our KDE SC 4.4.1 packages to include Aaron's latest errata - no need to update yourselves.

So it's even easier to take part in the Plasma Javascript Jam Session competition now.

And while you're at it, how about completing the loop by using our kde-obs-generator to package your plasmoids and make them available on kde-look.org, so others can start to download and improve them directly in Plasmate? Free Software virtuous circle FTW!

KDE will be moving to git, Qt has moved to git, recently also CMake moved to git.

So, it's time to start using git.

...until now it really looks so complicated, compared to cvs/svn.
In cvs/svn it was easy: local working copy, remote central repository, just one step away.
With git this is about three steps away: local working copy, stash, local repository, remote repository. You always have to be aware of where things are.

Ok, one has to get used to that "git add" is something different from "svn add", and "git commit" is different from "svn commit".

Do you know this one?

Phoronix tested md5sums of ISO images of distributions. The winner was openSUSE, scoring e29311f6f1bf1af907f9ef9f44b8328b, which gave it a noticeable lead before second Slackware (b026324c6904b2a9cb4b88d6d61c81d1), which is quite closely followed by Fedora (9ffbf43126e33be52cd2bf7e01d627f9) and Debian (9ae0ea9e3c9c6e1b9b6252c8395efdc1). The difference between these two distributions, as you can see, is only very small. Ubuntu completely flopped in this test, achieving only 1dcca23355272056f04fe8bf20edfce0, which is surprising, especially considering that its previous release scored a very nice c30f7472766d25af1dc80b3ffc9a58c7. (source).

Ok, that's just a joke, but the sad part is, as somebody pointed out, that it wouldn't be really that surprising if Phoronix actually did something like that. And, probably even more sad, there would be people who'd really take it as if it meant something and started adding comments about how last openSUSE is pretty good, last Ubuntu is so disappointing, and Fedora and Debian are not really that different.

So take this from somebody who has already done a lot of performance work: Benchmarks, on their own, mean almost nothing if you don't understand them. Especially if they are seriously flawed (I mean, testing filesystem performance by doing CPU-intensive tasks? Hallo? Probably even FAT16 could provide the same results in those tests on an SSD.), but even if the results are useful numbers, it is still necessary to understand what the numbers actually say. I think I wouldn't even have a big problem forging a "benchmark" where KDE would get better (and correct) numbers than LXDE by finding a scenario that'd be twisted enough.

And even then, it is still necessary to keep in mind what is compared. Comparing the default setup of Fedora and openSUSE means also comparing GNOME and KDE, which you may or may not want, but if you compare the distributions this way, it is affected by differences between the desktops, and if you compare the desktops, it is affected by the differences between the distributions. And in either case, it may or may not apply to another distribution or another desktop.

Yet one more thing to understand is what is measured and how it affects performance as a whole. Ages ago there was a Dot article that also mentioned performance improvements to be brought by Qt4 in some specific areas, yet even now there are numbers of people seriously disappointed by KDE4's performance only because they thought that since Qt4 improves in some areas, KDE4 will get exactly the same improvement, regardless of how much these improvements matter for the whole of KDE4 or how much of KDE4 was rewritten when porting from KDE3. When I fixed Exmap to work again and did a little benchmark as a part of it, there wasn't really much more to it than to show that Exmap works again and that it is very easy to lose a lot of advantage by a simple mistake, yet people had no problems drawing all kinds of strange conclusions from that. Since making right conclusions is unexpectedly difficult for most people when it gets to benchmarks, I really need to remember not to just post numbers again without also saying what it means.

And, finally, there is still the question of other costs and whether it is worth it. Various KDE components often have resource demands, but then they are also often worth it. I mean, we all could still use TWM, or, heck, Windows 95, but seriously, how many of us really would? This, ultimately, is always about what works the best for you.

1) Create a folder somewhere eg ~/Desktop/My Favourite Apps
2) Drag and drop the folder onto a panel
3) Choose "Folder View" from the popup that appears
4) Drag apps from the menu, documents from Dolphin and other stuff onto the new panel icon
5) Click it and enjoy your new menu!

I recently realised that much of the code I find interesting is about interoperability. That is, I'm interested in making sure we can get at data in a range of formats. Work on libtiff, poppler, okular generators and openchange are all examples of that. I also like Qt as a very nice cross-platform API. The convergence of those interests is having Qt-style libraries and tools that can get access to data, especially data in widely used proprietary formats (e.g. those produced by Microsoft products).

I've set up a gitorious repository (http://gitorious.org/microsoft-qt-interop/microsoft-qt-interop) for some of that stuff.

Those that were at either CampKDE or FOSDEM might already know, so for those this is a status update, for the rest: I've been working on a tool that makes it quite easy to create packages in the openSUSE build service, which despite the name can create binary packages also for other distributions than openSUSE. If you've ever gotten a mail asking for a binary package of your application or help with a compile problem, this could make your life easier.

For example, imagine Joe Developer, who has written his KFoo application, uploaded it to http://kde-apps.org and is now watching what happens. But, alas, instead of thanks and praise, what often happens is that the first comment is something like "I get this compile error, can you help?" or "Are there packages for Kubuntu?".

It may be quite easy for Joe to see that the compile error is caused by libbar-devel not being installed, but how is he to know what the package is called in other distributions? The same way, how is he to provide binary packages for distributions he does not use? And that's far from all things that can go wrong in such case - Joe may be running KDE workspace 4.4, but somebody may be still on 4.3, where the application would nicely compile and run, if only one #ifdef would be added to the right place. But will Joe really downgrade his installation just in order to fix that, and again each time he does a release of KFoo? And then maybe somebody else will try to compile it on openSUSE Factory, which already uses GCC 4.5, and will get compile errors because the latest compiler is more strict than previous versions and rejects invalid code that however compiles just fine on Joe's computer. And so on and on.

Joe, of course, is a smart guy (after all, he's written this great KFoo app that everybody wants to run if only they could compile it ). He can get the idea to use VirtualBox and install other distros he could care about, and test in all of them. The question is how long he'd be really willing to do that, since it certainly sounds like a lot of fun (and lot of disk space, and work). And that still means that all those potentional users would have to compile KFoo from source.

Maybe distributions would eventually include KFoo, but there's this tricky loop 'nobody uses it' -> 'why should a distro include it' -> 'no distro ships it' -> 'nobody uses it'. Maybe Joe gets lucky, maybe he does not.

Sometimes other people may provide binary packages for the distribution they use, so if somebody likes KFoo enough (and knows how to do it), Joe may find a comment on kde-apps.org pointing to this package and can add it to the list of packages to download. Except this may and also may not work, depending on how well those packagers keep up. Having a binary package of KFoo-0.3 when the latest source tarball is KFoo-1.5 is probably worse than no binary package at all.

So Joe can go back to the VirtualBox installations and try to package KFoo for all those distributions. But Joe is a developer, not a packager, so first of all he'd have to learn how to actually do that (e.g. creating a .deb is quite different from .rpm, and even .rpm packages for different distros are not created exactly the same way). Worse, he is a developer, and, honestly, developers just love packaging, especially for multiple distributions, riiiiiight?

Now here comes the openSUSE build service (OBS), which as already said is not only used for creating the openSUSE distribution, but also provides the ability to create repositories providing additional software, also for non-openSUSE distributions. That almost looks like the solution for all the above problems, doesn't it? No need to install the distributions and do the builds locally, the OBS itself will do the building. New packages would be available very soon after updating the sources in the OBS. And kde-apps.org has even direct OBS support, so packages can have direct download links there.

There's still the problem of actually having to know how to do the packaging, but that is exactly what kde-obs-generator should help with. KDE applications in general happen to be simple to build, and thus quite simple to package (in fact, compared to some other pieces of software, KDE apps happen to be remarkably simple to package ). So a lot of that could be automated. In the best case, creating a KDE package in the OBS can be now a couple of clicks in the web interface, few osc commands (osc is the CLI tool for OBS) and running kde-obs-generator in the directory with the source tarball. I've already tested the tool with some packagers and they even started using it for real, because even for experienced people it saves work.

I still consider the tool to be experimental and work in progress, but it's already pretty usable. Currently it can handle Plasma themes, KDM themes, KPlash themes, wallpapers and generic KDE/Qt CMake-based builds. It tries to automatically figure out all the needed build dependencies (which however means the list of mappings from cmake to package names for all supported distributions needs to be extended as necessary). Also kde-obs-generator itself is packaged using kde-obs-generator. The biggest thing I've built so far is the whole of kdeutils, that's of course not how something like kdeutils should be packaged, but that shows it can handle quite a lot.

So, in case you'd like your application to reach more of its posible users, you'd like to ease your testing, or you're just curious, the documentation is in the openSUSE wiki. I'd especially like to point out the tutorial, which is really step by step and includes also things like how to create an account for the OBS, so maybe even a monkey could now create a package (well, assuming it can read and write and is pretty bright for a monkey - this still cannot be as simple as just hitting Enter repeatedly). If there are any questions or a problem, see the feedback section (mail the opensuse-kde mailing list, or just ping me (llunak) in #opensuse-kde on Freenode).

PS: I'd appreciate if people using other distributions could edit the wiki page on how to actually install the binary packages in some easier way than going to http://download.opensuse.org, navigating to the right .rpm/.deb file and clicking on it. It's pretty easy with openSUSE so I assume there must be something simpler on other distributions too, but I can't find it.

New KDE Four Live CDs with KDE 4.4.1, and much more are up.

They were built with openSUSE Build Service's KDE:Medias project and SUSE Studio and consist of openSUSE 11.2 plus all updates, KDE 4.4.1, upstream branding, Nepomuk enabled and Strigi disabled (because it's a Live CD).

They can be used as Live USB sticks too, see these instructions if you don't know how to dd a file to a device.

You can also install to disk and use it as a normal distribution using the installer on the desktop. Once installed, the first update will pull in all the packages that are normally on an openSUSE KDE install that do not fit on a single CD.