On recent Anti-KDE blogs.

Being an avid reader of blogs in the Free Software world, and especially in the Free Desktop
world, lately, I see there is an increased amount of blogs that try to put KDE in a bad light.
Today’s example on
Iain Holmes blog made me realise that it’s time to
publicly ask people to stop exhibiting this pattern in the public.

This kind of sidekicking other Free Software projects puts you and the
community (GNOME in this case, but it universally also applies to KDE, the Freedesktop and the
Free Software community) as a whole in bad light. While it’s probably fine to
make an ass out of yourself, please don’t apply the same logic to others. Therefore, if you
consider bitching about The Other Desktop (be it KDE, GNOME or whoever else’s offering) in
public forums, please keep the following in mind (and don’t expect me to list new things here):

  • Trying to ridicule other Free Software people’s work is counter-productive to
    the cause of getting more people to use Free Software.
  • Stating bad things and forgetting about the background for convenience reasons shows
    only one thing well: You’re too narrow-minded to see the big picture, and you don’t do any
    effort to try to really understand the thing you’re bitching about. In 99.9% of the cases,
    the world is not as black-and-white as you are so conveniently trying to put it.
  • It also puts your community into bad light, and it makes collaborating for those who
    are less narrow-minded much harder. Don’t throw sticks between your own people’s legs.
  • It doesn’t help the adoption of Free Software and the Free Desktop at all,
    in fact, it shows that you’re immature.
  • It might provoke the same kind of reaction from the other side, leading to a vicious circle
    of mud-slingering with the consequences I’m outlining in this post.
  • Diversity is one of the principles of Free Software, your pattern of behaviour shows a deep
    lack of understanding of this concept.
  • Remember what today might be a funny and smart post, it can be tomorrow’s reason for an employer
    to not consider your application because of a lack of vision, understanding and diplomacy in dealing with
    diversity. (Replace “employer” with “potential girl-friend” at will.) Don’t shoot yourself in the
  • The Free Software cause is best served by being open-minded, collaborating with each other and
    being honest and positive about your own and other’s achievements.

Those who look behind this kind of posts wonder about the real reasons for this
immature and harmful behaviour. My personal guess is that there’s a fear of others outrunning your
pace of innovation (which is absolutely normal in competitive innovation, sometimes A leads,
sometimes B does, in total both win in terms of speeds compared to being the only player).
Then, there’s an uncertainty how to cope with this in a collaborative fashion (there’s a lot of
potentially shared technology in KDE4, you know?). The net result is doubt for those who
consider trying a Free Desktop — they’ll just wait until the community shows it’s mature and
working as one on a good user experience.
That’s the people you’re scaring away, yet it’s by far largest part of the desktop market. Remember,
there’s one vendor monopolising the market, by concentrating your effort on
the other Free Desktop, you’re trying to fight for a 3% – 6% slice of the market (which probably
aligns much better with your offering, and thereby it has much less of a competitive advantage.
That is “interesting”, “unique” and “challenged”, but probably not very “smart” from a marketing
point of view.).

So here’s my call to weapons:

People of the Free Software community, discourage this kind of counter-productive behaviour
and fight for a wide community of freedom-lovers that grows beyond trying to downplay other’s

On a positive note, I do know that this kind of behaviour is not the common
case in either community. In fact, I’ve worked together really well with people from other Free
Software projects (including GNOME) in the recent past. Unfortunately, only bad news is news, so
this is what gets picked up by the media. And unfortunately, it needs a lot of people not peeing
in the pool to see a pattern of a nice bunch to make up for one rotten apple.

Beta 3 delayed one week

Again, I’m acting as messenger of the Release Team. It has just been decided that the Beta 3
will be out one week latet than originally planned. This is mainly due to some changes in how
plasma work that we’d like to see in the new Beta. Highlights of that will be a working panel
implementation. In other news, Robert Knight is working on kickoff, which will probably also
be part of the next Beta.

This does give you, the developer of a component the possiblity to make sure your bits work
well before Wednesday next week, when Dirk will be tagging Beta 3. Please make sure that you
don’t break anything and have your code reasonably stable. Do delay unsafe code
changes (which probably shouldn’t be happening at all in the first place) to after tagging
and work on stability. Last time, Dirk (as part of the Release Team) had to spend a
considerable amount of time to make things compile, that should not be necessary this time.

In the meantime, the
list of showstoppers for KDE 4.0
is taking shape. While it’s not
complete yet, it provides some good pointers to where the Release Team would like effort
directed. Fixing those bits makes it possible to release KDE 4.0.

Now listening: Manu Chao – La Radiolina

Development Priorities

The KDE Release Team has a list with things that need to happen before we can get KDE 4.0
out of the door. I feel it’s a good idea to share this with the wider community as much as
possible. We need to get our noses aligned and head for 4.0. This will be a huge effort, but
on the way to the finish line for 4.0, we’ll need to focus on the following things:

  • Workspace Plasma
  • Color configuration (I understand this is already in)
  • Oxygen style (More help is need in polishing)
  • Konqueror
  • Dolphin
  • KMail
  • Kate
  • Printing (i.e. kprinter)
  • Sound

The Beta Cycle will continue until these critical components are determined
to be functional (i.e. the “Minimum Requirements”). Our hero David Faure put it very nicely:

Let’s fix the damn code before we think about betas and parties :-)

The Release Team is contacting people in charge of those components to give more detailed
information about the status and what to expect.

We shoud encourage people to work on those priority items instead of other things which can
be deferred into the 4.0 cycle. Getting 4.0 out of the door will be heavy lifting, now is
time to show that we can function as one community with one
shared goal. So if you want to see KDE 4.0 released (and I boldly assume we all do), help with
fixing the bits above.

AMD’s new promises

If AMD will open specs in a way sufficient for developing a new driver (and start of the
development by providing a reference driver, this is indeed very good news. Some sources
even say that a first version of the new, free driver they’re promising will be released
next week. I’ll happily download the source code once I’m back from vacation. :-)

Rumours that I’ve read all over the place include interesting bits which do make
it looks like it’s all a grand masterplan, and one that works well with the Free Software
development model as well. Rumours are that the people (among which Dave Airlie who has
shown in the past that he is dedicated to getting this high priority item in the Free
world fixed.) who have earlier been working on reverse engineering existing drivers.
Phoronix (an ATI friendly website) is of course all raged about all this news.

At the same time, the closed fglrx driver seems to be recovering from a long period of
minimal feature additions. For now, ATI promises large performance improvements for the
imminent 8.41 release and AIGLX support for October. This hopefully means short term that
a lot more machines that will run KDE 4 will be able to use a composited environment. Longer
term it means that the out of the box experience will be much better (imagine the driver
being merged in main line Linux and BSD!). Also it means that *you* decide when to throw
away that old video card (not a vendor deciding when to stop supporting it for newer kernels)
and maybe even the long-awaited stable support for suspend/resume.

ATI now following Intel’s way of working with the community rather than around it means
that NVidia will have to think how to rearrange its “Open Source strategy” so it fits better
with a community-driven development model — although the immediate pressure on them is
a bit lower due to better driver quality and shorter ‘time-to-user’. “Following” in this
context means that that ATI requires — just like Intel — some sort of NDA for those who
want to look into the specifications.

An interesting bit is that the often-cited ‘AMD representative’ at the Kernel Summit in
Cambridge is Chris Schlaeger, a long-time KDE developer. Congrats, Chris!

Update: It seems that AMD has released large parts of their specification without
strings attached. Kudos to those who made it happen!

New Release Schedule

The KDE Release Team has worked on a revised release schedule during the last week, and now it’s
a fact. While a first version of the renewed schedule had already made it on the development lists
there were still some problems open with it. If you’d pick the worst week of the whole year, it
would be around 20 December, which was the release date in the previous version of the revised
schedule. We’ve now shifted the release date of KDE 4.0 to December 11th. Tagging of this release
will take place on 5 December.

The new thing in the release schedule is not the slightly earlier date, but it’s the overall
strategy has changed. Just like KDE is becoming more and more a meta-project, there is also an
ongoing discussion what KDE is anyway. It’s a community of Free Culture people, a Desktop
Environment (a term that noone outside the geek world understands) and a development platform. And
that’s what we’re releasing. So here’s how it looks like in the new world order. First, the Desktop:

  • October, 2nd: KDE 4.0 Beta 3
  • October, 19th: Total Release Freeze
  • October, 30th: KDE 4.0 Release Candidate 1
  • November, 14th: KDE 4.0 Release Candidate 2
  • December, 11th: KDE 4.0

Since a releasable desktop builds on libraries and tools that are sufficiently stable, and since we
feel very good about the current state of kdelibs and everything that is a bit further down the
stack, we’ll be releasing a KDE Developer Platform already at the end of October,
together with the first release candidate. This developer platform (sort of an SDK) contains
libraries and tools to build and run KDE applications (but no applications themselves). By doing
this, we want to make it easier for third party developers and ‘casual developers’ (those who don’t
have time compiling kdelibs and the other needed bits) to work on KDE 4.0 applications and port
existing applications to KDE 4.0. This is all part of a grand master plan which is all about making
KDE development easier and more fun. This effort is of course spearheaded by Techbase, our portal to all the knowledge about KDE software and
development. Techbase has in very short time become an invaluable tool for the whole community and
lower the barrier to enter KDE development.

Enough rambling, here’s the deal: KDE 4.0 is now planned to be released on December
. The KDE Development Platform will be given birth (yeah, it really is our
baby!) on October 30th. The Development Platform contains kdesupport, kdelibs, kdepimlibs and

LCE, power consumption and version control systems?

I’m travelling back from LinuxConf.EU right now. The
conference was very well organised, taking place in the beautiful Cambridge. My talk went pretty
well. For me it was the first time I relied on KDE 4 not letting me down, I did the presentation
from a KDE 4 desktop, using okular. Glad to tell you it didn’t let me down. :-)

Most of the talks were very technical and largely related to kernel-like stuff. No wonder that,
there were quite some kernel developers around, some of which I got to give me some insight what we
as desktop and their upstream can do better.

Most notably, I’ve talked with Arjen van der Ven about power consumption. Arjen advised to do
regular checks with powertop and see who’s the worst offender in waking up the CPU. He mentioned
that 2 wakeups per second is a good value and that we should be aiming for that. (Not having a
recent enough kernel on my notebook right now, I can’t check how KDE 4 does with respect to that
right now.) He also mentioned that the worst offenders are not-aligned timers, so if we use timers
at all, they should all be aligned with each other so that multiple timer events don’t wake up the
CPU more often than necessary. I understand that there’s work in plasma going on to accomplish that,
and that there’s also a patch for Qt lying on a desk somewhere in Oslo which does this for the whole
of Qt. Would be nice if that could make it in quickly. Arjen noted that there’s also related work in
glibc going on.

On monday night at Duxford Imperial War Museum, I did an interview
with Linux User & Developer Magazine. Make sure you don’t
miss the next edition if you want to read it.

Yesterday, I chatted with Linus about version control systems, especially the difference between git
and subversion. Important aspects are that git does not do well with binary data (especially not if
it changes frequently), it’s just not designed for that (no surprise here). There also seem to be a
couple of performance issues when importing very large repositories (such as KDE).

My major gripes on the whole VCS issue are the following (take git as an example for any distributed
VCS here):

  • Switching from a centralised VCS to a distributed model makes some changes in our social
    structure necessary. In a way, a centralised VCS repository is also some sort of social glue that
    keeps us focused on one authoritative codebase. We should prevent forking (the bad version) — this
    will do harm to our community. Also, I do understand that a centralised way of using git is
    possible, but that’s not quite the point here. Also remember that we do not even have maintainers for
    all the module in KDE.
  • Contributors will inevitably have to adjust their personal workflow. We should make
    absolutely sure that this does not increase the barrier to start contributing to KDE.
  • Using two VCS in parallel can harm the community. If you really want to use git, make sure
    your code is available for others, sync with our SVN repo on a regular basis. I’ve already seen
    people using git and not caring about updating the copy in SVN. This hurts our development process,
    especially while we want to get KDE 4.0 ready for consumption.
  • Consider that switching important tools such as our VCS is a huge step that doesn’t come
    without costs. It might even be a disruptive change to how we work as a community. We should not
    tinker with our tools more than necessary.
  • Switching VCS before we are well underway in the 4.0 release cycle is a stupid
    to do. One major challenge at a time is already enough for us.

That said, I do see potential benefits from using git. Most of them have been pointed out
by others already. My concerns and thoughts go out more into the social aspects. Git (or any other
distributed VCS for that matter) might perfectly fit how we (should) collaborate as a project. It
might make new ways of creating kick-ass software possible for us, just like it did for other
projects, such as Linus’ baby.