Linux desktop architects map out plans for 2007

24

Author: Joe 'Zonker' Brockmeier

The Open Source Development Labs hosted the third Desktop Architecture Meeting in Portland, Ore., last week to continue discussions on how to move the Linux desktop forward. More than 40 developers were in attendance, from organizations such as Hewlett-Packard, X.org, Red Hat, Nokia, Intel, OpenWengo, AMD, Xandros, Linuxprinting.org, and many several others.

We would have liked to report on DAM3 directly, but OSDL refused to allow reporters to attend, citing member concerns about disclosing information with reporters present. Instead, we spoke with OSDL’s Desktop Linux (DTL) initiative manager, John Cherry; Jim McQuillan of the Linux Terminal Server Project; and Dave Neary of the OpenWengo project.

Fixing sound suckage

One of the priorities coming out of DAM3 is fixing the sound experience on the Linux desktop. Sound is a mess on the Linux desktop, and developers are finally starting to turn their attention to clearing up the muddle. McQuillan says, “By far, the most important thing coming out of DAM3 was the understanding that we need the audio/multimedia system to finally settle down and adopt a single robust API.”

This doesn’t mean starting from scratch. McQuillan says the idea will be to start with an existing API “and add the missing pieces.

“ISVs and ISDs [independent software developers] shouldn’t be confused by the myriad of choices of APIs that do one thing or a couple of things while missing something else. A single well-designed API is where we need to be.”

What that API will be is still up in the air. The plan now is to organize another meeting exclusively about audio by the spring. According to Neary, “You need the application writers (like Helix, OpenWengo, Audacity, MPlayer, Xine), the framework writers (GStreamer, Phonon, PulseAudio, JACK, PortAudio), and the low-level people working with the sound cards (ALSA, OSS, et al.) to get together and define what the sound APIs need to do.”

Neary also says that they will be putting together a mailing list “in the near future,” and that he expects “to see improvement in the sound situation within a year.”

Codecs and digital rights management were also discussed at the meeting, though Cherry says they “didn’t make much headway because they’re mostly non-technical issues.”

Other priorities

If the recent summit moves the ball forward only on solving the sound problem, many Linux users would probably consider it a success. However, desktop developers have a few additional priorities for 2007.

Neary says that packaging came up at the meeting as well. “Packaging was another issue that was talked about a lot — ISDs writing applications that don’t get into distributions have a hard time of packaging. Do they create a .deb and a .rpm and be done with it, or do they need to create (and maintain) different packages for Debian, Ubuntu, Fedora Core (4, 5, 6), RHEL 4, 5, SLED 10, Mandriva, OpenSolaris….”

Hardware support is also “near the top of the list,” says Neary. “It’s a hard sell to get a hardware manufacturer to write a Linux kernel driver right now; you also have the packaging problem there. Which distribution does he write for? Which version of the kernel? It’s not even a question of the license — even if he releases his module as GPL, and it gets into the mainline kernel, you still have a huge problem of lag between released kernels and the kernels included in the distros that people use.”

Another project that is on the table is a bootable CD that could be used to determine whether a platform is supported. Cherry described a kit that would be used by “decision-makers” to boot a system and evaluate device support under Linux and determine the hardware’s level of compatibility with Linux.

Portland

The Portland Project is also moving forward. Cherry says that there’s a Portland 1.01 release planned for January, and Portland 1.1 in April. These releases should include updates to the Xdg-utils.

Later in 2007, Cherry says that there should be a Portland 1.5 release that will include Xsettings to make it easier to control X.org configuration across different desktops. This should be released by July, according to the group’s DAM3 summary documents.

Desktop developers are also working on a common print dialog for the Portland 2.0 timeframe that would be able to be used by any application. Right now, many applications have their own print dialogs that may or may not expose all of the functionality of a printer. Cherry says that new ISVs developing for the Linux desktop want a consistent service that they can call on KDE or GNOME that will allow applications to take advantage of advanced features in printers.

Fewer meetings in 2007

The face-to-face format of the Desktop Architect meetings is useful, but also a problem for busy FOSS developers who already attend a number of other developer summits each year. Cherry says that they’re planning on cutting down to a single meeting for 2007, and that they’d like to “piggyback” with another event so developers can make the most out of their travel time. The event hasn’t been chosen yet, but Cherry says that they plan to have the fourth DAM in the fourth quarter of 2007 along with “one of the big events.”

Still, despite the travel, McQuillan says it was worth it. “The DAM3 meeting helped rejuvenate some of the spirit of collaboration that is easy to lose track of when I’m sitting alone at my desk. In fact, the night before the meeting started, there was a reception for people to get to know each other. In the hour that I spent there, I was able to make contacts with the people who work on things that are important to us, like gconf and dbus. That alone made the trip worth it.”