Yesterday I woke up to the news that Canonical are no longer going to fund Riddell to work on Kubuntu. I've trying to figure out what that means for KDE and for community Linux generally.

Disclaimer: I work in the same role as Jonathan at SUSE, a competing Linux company that sponsors the openSUSE project. This is my personal opinion, not that of the openSUSE Board or SUSE Linux GmbH.

I'm sad for Jonathan personally. He has put a lot of his lifeblood into Kubuntu over the years, at no little cost to himself, and to be pulled off one's favourite project hurts. The same thing could happen to me if the powers that be decide, so I can easily empathise with him.

In the bigger picture, I have to say that this doesn't surprise me at all. For Canonical, Kubuntu fulfilled its purpose a few years ago already. Kubuntu, and the other official Ubuntu derivatives, have always been a spoiler move to tie up community contributors who believed in the early community-centric image of Ubuntu, but who didn't agree with the main Ubuntu's direction. Otherwise, there was the risk that Ubuntu design decisions would polarize the Linux community and send people towards Ubuntu's competitors. With the derivatives, they are safely occupied under the big tent of the Ubuntu brand.

If we look back at the Ubuntu game plan as history neatly lays it out for us, we have

1) Establish the Ubuntu brand amongst early adopters (check, by about 2005)
2) Expand it to the wider Linux user base (check, by about 2007)
3) Make Ubuntu the default Linux for non-technical users (2009)
4) Tie up a paying market. Initial targets have been enterprise desktop Linux (maybe next year ;)) or consumers in the massmarket netbook segment (but that was squashed by tablets and Microsoft rounding up the manufacturer back to the XP prison), and now they are aiming at embedding into consumer electronics (TVs) and will probably snare a tablet OEM as a cloud OS (hell, if KDE can do it...) or a bookseller or someone who wants a platform to digitally sell something else off of.
5) Profit
6) Buy more spaceflight (Probably. For some, 5) is enough)

Somewhere after 1), the massive demand for KDE on Ubuntu in KDE's main territories (Germany, via the ubuntu.de forums, which IIRC threatened an unofficial fork) caused Canonical to realise that it was better to control a large dissenting minority with some token gestures than to have them really doing their own thing. So Jonathan, at that point a KDE packager at Debian, was hired, and Mark Shuttleworth did his salesman job at a couple of KDE events making some insubstantial promises (If I had a dollar for every KDE eV board member at the time who told me "But Mark has promised to install and use Kubuntu on his workstation" multiplied by every Ubuntu developer overheard chuckling that "But they don't know that Mark *never* uses his workstation, he's always on a notebook"...), a few community people got flights to events, and Kubuntu was born, and legitimised by the then-leaders of the KDE community.

Once 2) was consolidated, Kubuntu was redundant to Canonical, but on the average professional Linux hacker's salary, Jonathan was an affordable luxury. Now, I suspect that with the trend at Canonical to develop more and more in-house to chase 4) rather than just distribute what the FLOSS community provides, putting paid man-hours on a mature product is no longer a good way to spend engineering budget.

By cheaply tying up competitors' resources, Kubuntu has hindered KDE's overall growth via other distributions and balkanized the KDE community. It can be argued that Kubuntu has brought users and contributors to KDE as part of the rapid initial growth of Ubuntu, and Kubuntu has been a success in focussing their developers on improving KDE, but this came at the price of cementing KDE in the role of a second class environment in the eyes of everyone who came to Linux via Ubuntu. I suspect that the GNOME community, which previously surfed the wave of Ubuntu's growth, will feel the pinch of necessity as Canonical moves towards its endgame, and having already been displaced as the default desktop for an inhouse development, will move further towards just being an anonymous organ donor to Unity and subsequent productisable UIs.

Why am I writing this? I don't want to be so crass as to just say 'come to my project instead'. I'd like to take this opportunity to suggest that you should have no illusions about what your community Linux distribution means to the businesses that sponsor it.

For openSUSE, it's some engineering contribution to and testing of SUSE enterprise products' codebase, and supporting the enterprise brand via a halo effect from the community brand. In setting up the openSUSE project, SUSE has been militant in giving the community complete control of the project and the distribution that comes out of it. Call it an insurance policy or a lifeboat, but by opening and freeing all the tools that create openSUSE (as well as the source code), we assure that the results of 20 years of work are indefinitely available. SUSE is secure enough in its business and believes strongly enough in free software to do this with the rootstock of its enterprise products, because the modular, federated Open Build Service allows SUSE to derive enterprise products from openSUSE without having to steer it.

Linux fragmentation requires extra effort from packagers, and extra communication efforts between software vendors and packagers. To lower this unnecessary pain I shall remind, how to package Kexi?

Kexi depends on many packages that are highly optional, only suggested for "full installation", which in turn is rarely needed in real world. So each database driver ideally should be packaged separately for the best user experience. For example there is no need for user of file databases to install PostgreSQL or Sybase package(s). Did I mention Oracle?

(by-nc-nd) darwinjus

Yes, this is basically a job ad. The openSUSE Boosters team is expanding again (when will it ever stop?) and we're looking for another member. If you want to work full time on Linux, enjoy the idea of building a community around the distribution and think you have the right skills why not apply and have the chance to work with me, Lubos Lunak, Stephan Kulow, Klaas Freitag and many other people you know from the KDE and wider Free Software scene?

Today openSUSE 11.3 is released, concluding 8 months of intense and enjoyable work. This release has been especially enjoyable for me, as it was the first openSUSE release where the community KDE team really took the driving seat and made decisions about what to include, updated packages and intensively tested. Instead of just being a slave to a feature list this release, I was more occupied in enabling, advising and reviewing others' contributions. I'd like to say "Excellent work!" to the whole openSUSE team here in Nuremberg, Prague, the rest of Novell and to every openSUSE contributor who has tested milestones, reported bugs, learned how to use osc and build.opensuse.org and made a difference.

By our recent standards, openSUSE 11.3 is a conservative release; it doesn't have bleeding edge features shoehorned in at the last minute by product management or novelty for its own sake. Instead it's what a Linux distribution should be: a careful composition of the all the newest stable elements from upstream. The KDE SC 4.4.4 that we ship is now stable and feature complete, by most accounts, and contains many tweaks and upstream patches to be an elegant, good-looking but also stable and usable desktop. I hope that it will provide its users a lot of pleasure and utility, inspire many of them to jump on board at the openSUSE project, and others to explore all the possibilities and smoking hot new stuff available in the openSUSE Build Service.

Oh and in case you wondered why I wasn't at Akademy in Tampere, here's why:

After 9 months of enjoyable and intense work, our daughter Anna was released a couple of weeks ago. At the moment she's quite unimpressed by computers, desktops and operating systems, but I hope that Free Software will be of benefit to her life as it already is to millions around the world.

As already mentioned, I have this certain tool in works that can do various magic when it comes to creating packages, especially for people who have no idea how to do them themselves. And since

too, and on Wednesday I have scheduled a slot for demoing the tool and helping people who'd like to create packages of their software, I've worked on implementing and improving various features that make it more interesting:

• Besides the obvious CMake support, there is now also support for autotools-based software. Autotools stuff is harder to process then CMake (funny, I remember not being very impressed by the move to CMake, but going back now made me wince here and there), but it's already pretty usable.
• Which means that even though the tools is called kde-obs-generator it can handle non-KDE stuff too. For example I have GEdit, Gnumeric or GOffice (why aim low, right?) in my testing project, and while none of that finish the build completely yet, it just needs handling more of the autofoo trickery. I guess the tool is about to need a better name.
• There's QMake support too, kind of. However, if you use QMake, you probably want to switch to CMake anyway.
• The recommended way of use is setting the build service project in a way that presents a more unified build environment, with macros and package name substitutions automatically taking care of distribution differences. This results in the .spec files being quite clean and easy to read. But there is also a mode that doesn't require this setup and builds directly in normal openSUSE, Mandriva and Fedora repositories (and Ubuntu, but that's already different enough from the rest). It means of course that the .spec may have a bunch of %ifdef's and manually written macros at the top, but it works.
• A consequence of this is that it is also usable for creating normal openSUSE packages. If the project build only for openSUSE, the resulting .spec is more or less a normal openSUSE .spec file. I've already watched few times Pavol and Michal explaining packaging to people who would like to learn it, and I couldn't help wondering how scary it has to be for some of them, getting a full .spec file explained line by line on how they need to write it manually. Well, for the next time the introduction part can be greatly reduced to just "run this tool, if it works and you're happy with the result, that's all then".
• There is also the bonus even for somebody who knows how to create packages. It's still nice to have the .spec generated automatically, including all the build requirements (if they are already in the database), the file list and so on. Everything I have posted at kde-apps.org for the last several months has up-to-date binary packages too, and it's almost boring to create them.

So, whoever would be interested, just talk to me at Akademy or come to the Wednesday session and I'll try to help you getting your stuff built and answer any questions (except for the two questions about blue hair - really, people, I've heard both of them already enough times, can't you get at least a bit innovative :) ?).

Some things are really really tiny details, yet they can be annoying in way. Something that's been occassionally bugging me is that fact that KDE uses the same wallpaper as KDM background, the splashscreen background and desktop background, yet depending on the screen resolution it may not be exactly the same background - during login the picture may stretch or shrink at certain points. The times when decent monitor screens had a 4:3 ratio are a thing of the past, starting with LCD makers making 5:4 "narrow-screens", then changing their minds and making 16:10 or 16:9 wide-screens. The choice of screen resolutions is not that limited either and that means that the wallpaper has to be scaled ... and that was the problem. Plasma has code to select how to do the scaling, KSplashX has code for that and KDM has code for that, and yes, you guessed it, it's always a different code. So unlucky resolutions get different wallpapers from different code. Since I actually spent some time in the past trying to make the login as seamless as possible, this indeed made me twitch whenever I saw it.

Seeing this again while testing openSUSE 11.3 made me finally spend the time to patch the openSUSE package to use the same selection code in all the three components. We really lack polish in so many places :(. But now it looks like the change is almost not there - there's just a progressbar and logo shown during startup and that changes to the desktop. With compositing enabled there would be also the fade-in animation.

Seeing that 4.4's KDM had no support for differently sized wallpapers, I was about to submit a copy of Plasma's code there when I noticed that trunk has some code for it. Of course, different from the rest again. Also, the login sequence is basically just lucky to be so smooth. The splashscreen is supposed to stay visible until Plasma is ready with its wallpapers and panel layout. And there is code in KSMServer to ensure this. And Plasma uses it. Yet it's apparently not used properly - during the first login, when there is more setup to be done during login, it's perfectly possible to see how the panels are set up. Well ... maybe in time for openSUSE 11.3 + 1.

You most probably have already run into this at least once. You use the computer, try to do something and you get an error message saying "sorry, application foo is not installed", "the required plugin bar is not installed" or similar. And that's it, there it stops. You have to find out what package the required functionality is in, install it manually and try again. Like if the computer couldn't ask "but maybe I can install that, do you want me to try?" and handle it itself.

And that's what my goodie for this openSUSE release is about. I've been examining a bit about what various parts of the desktop could do this and there indeed are some cases. For example, clicking in Dolphin on a file that has no associated application installed usually results in the "Open with?" dialog. And that dialog has nowhere in it the option "the application that can open it, silly". Especially given that if the installation medium is accessible (i.e. usually if the network connection is up), it's rather easy to find out the right application for the file and install it:

This specific case is actually a bit tricky. The file, example.kvtml, is a file with pairs of words or expressions that e.g. KWordQuiz can use for teaching (words for language lesson, for example). The problem is that technically the data is stored as XML and the mimetype (file types) specification has a concept of subclasses that is and in not useful depending on how you look at it. A C++ source file is a subclass of a plain text file, so you can edit it just like a plain text. Good. An XML file is also a subclass of a plain text file, so you can view XML as plain text. Good? I'm not quite sure on this one, since while XML is human-readable, any decent up-to-date XML is certainly not human-understandable anyway, so I fail to see the point. But, since .kvtml files are XML files, they are a subclass of them, and that means you can view them just like a plain text.

Good??? Probably not. They are supposed to be opened in an application that can show the lesson nicely, who'd be crazy enough to decipher it from the XML? Well, but that's the reason for the dialog looking this way, the above is what the dialog is trying to tell you. Sorry :). This should get eventually sorted out somehow in the mimetype specification, but for now I had to go with this.

The short version is: Just say you want an application that can handle exactly the file type, that's usually the right choice here. And if there are more applications that can handle it, you'll get a choice:

There is another, rather obvious case, where this can be useful. Amarok on its first start usually likes to complain about lack of support for certain well-known and widely used multimedia format and 11.3 will be no different. However, Amarok has also some support for solving this problem and has this dialog:

And that is where the new feature comes into play.

This time, however, there is the usual problem: The openSUSE distribution is not allowed to include the necessary support, because <a lot of ugly legal babble that causes headache>. Some distributions may try to include it and hope that residing in a country without such laws solves the problem. Or, even better, not having a load of money in bank avoids a lot of trouble too (what's the point of sueing somebody who can't pay afterwards, these merry patent folks don't do it just for the sports). That doesn't quite work for openSUSE, being supported by Novell, and I bet every big company has been already sued for much more stupid things than this, just in case it'd work out. So openSUSE simply can't include the support and can't even really tell you where to get it. As long as the world is the way it is, there can't even be any "install all I need" button in openSUSE. Sorry. That's the way it is :(.

So what happens in this case it that the required packages will not be found. However, there are many repositories for openSUSE not provided by openSUSE, and you can add the right one and try again (BTW, the URL in the link doesn't work yet, that will be fixed in time for 11.3).

Choosing to enable additional repositories will simply launch the YaST module for configuring repositories. And, as I said, it cannot point you "here" and tell you which repository to add (because, if nothing else, it doesn't know anyway). But adding a repository is not really that hard.

After adding the right repository it will proceed with installation. Again, the usual allmighty YaST. Nothing hard about it, and this part should be mostly automatic anyway.

There it is. As simple as possible (sigh) and now it's ready (but the dialog is actually right, restart is required for technical reasons).

There of course can be more places where this could be useful. The crash handler has already support too, so generating proper bugreports with full backtraces should be now much simpler as well. This is so far just experimenting with the feature and seeing how it works out, if it works well, even more can be added after 11.3.