Notes from the DAM

Here’s some random notes from the Desktop Architects Meeting-3. Follow the link for summary and presentations.

The format was somewhat different from what I was expecting; I think we spent too much time (too many and too long) on the presentations, at the expense of breakout sessions. Breakouts themselves were great, but in some cases the problems can not be solved with technology (codecs, DRM) or we did not have the right people present to get a concrete action plan (upstream/downstream co-operation.) All in all, it was good, could’ve been better.

The DAM is a good place to meet the people working on different aspects of the Linux desktop and have a glance to the big picture on what’s happening in different areas. Following are some things we discussed during the two days.

ISVs want one stable platform. Never ever remove or change anything, adding is OK. ISVs do not want to keep on porting the software. Once an applications is released it should run (everywhere.) You can rebuild the distribution to migrate from libstdc++.so.5 to libstdc++.so.6 and drop the former without affecting the distribution, but that easily breaks independent applications. Having compatibility libraries is nice in theory, but in practice there is no distribution independent way for getting them installed.

If ISVs agree on some common set of libraries and APIs they’d all be happy about, there might be enough incentive for distributions to keep making that set of libraries available. Have them all installed by default, or get distributions provide a single well known way to get them installed on end user systems.

At least in theory we currently have two totally incompatible Nokia 770’s out there. Some (really few I’d expect) with the 2005 and the rest with the 2006 OS release. This presents a problem to ISVs, what does “runs on Nokia 770” really mean? And when/if we release new hardware/software combinations, how can we get the message clear to both ISVs and end users about platform compatibility?

Audio on Linux is in a sorry state. On Windows there’s one audio API, on Mac there’s one API, on Linux there’s 6-7 incompatible APIs. It’s relatively futile to talk about video if even audio doesn’t work. And with codecs/DRM the problems are not really technical anyway. Focusing on the needs of application developers is the way to go here.

In Maemo we’re using GStreamer and ESD basically for the same reason, there is no one API that would work for all, or even the most common, cases.

Improving upstream/downstream co-operation.
Currently the technology (read: bugzilla) does not help as much here as it could, there’s much manual work involved; forwarding bugs to upstream, searching through all (other) distribution bugzillas for bugfixes, etc. It would be nice to have an overview of the state of a bug across all distributions. Does any distribution have a proposed fix? Is the bug officially fixed upstream? Where can one find a patch to backport to maintenance release? And so on.

Unfortunately we could only collect use cases as we didn’t have the right people present to concretely plan for getting things done.

Qt applications should look native. Qt4 adds lots of support to make this possible (cleanlooks theme, integrating with glib mainloop, button order.) In Maemo integrating with the input methods is the only thing I can think of that might be tricky to do. Theming and other overall look and feel is simply straightforward work that just needs to be done methinks.

D-Bus 1.0 guarantees API/ABI stability. No more need for “I know this is unstable” defines. No more worries about changing APIs.