What the desktop architects are talking about [LWN.net]

The third Desktop Architects' Meeting (DAM3) is being held on December 7 and 8 at OSDL's offices in Portland. Despite some rumors to the contrary, there will still be a few people in those offices, and the meeting is going ahead as planned. LWN, unfortunately, will not be represented there. Happily, most of the attendees have posted their slides ahead of the event, so it is possible to get a sense for what some of the common themes will be.

Outsiders like to criticize Linux for its proliferation of distributions, desktops, and more. Within the community, we recognize this diversity as a form of wealth. The variety of Linux distributions encourages experimentation with different approaches, with the resulting lessons being learned by the community as a whole. They also ensure that we will never be locked into a single source for our software; switching distributions is an easy thing to do. Similarly, the competition between free desktop projects has inspired them all to identify their users and give them the best experience they can. There are few people who would wish for a world with a single distribution and a single desktop.

Some of those who might wish for that world, however, may well be at DAM3. Diversity is good for the community, but it does make life harder for those who would support binary applications on Linux. Having to deal with a range of desktops, packaging systems, library versions, encoding choices, etc. creates a lot of work for application vendors. Someday, maybe, the free software community will be so rich that nobody will ever wish for a proprietary application for their Linux systems. Until that time, we will either have to make life easier for those vendors or simply write off a large subset of potential desktop Linux users.

Some other old complaints have been raised: lack of support for proprietary codecs and DVD playback, for example. Most of the people involved seem to understand why Linux has these limitations. But they can still wish for a world where more things just worked. Hardware support also shows up in a few sets of slides. This is an area where things are getting better quickly - most wireless network adapters should be supported before too long, for example. But video adapters are still a problem.

A certain amount of slide space was reserved for complaints about sound support under Linux. At the driver level, things seem to work, but not everybody likes the ALSA API. Above that, there seems to be no consensus on which sound server should be used. Without a consistent and reliable way to make noise, many desktop applications will remain hard to support.

Printing also, apparently, remains a sore point, despite the great progress that has been made in recent years. One initiative which may go forward soon is the certification of printers which are well supported under Linux. Beyond that, it appears that the Portland Project is going to try to create a unified structure for print dialogs. This mechanism would try to present a consistent interface to printing which would make it easier to export - and use - printer-specific features. Desktop-specific dialogs would still do the actual user interaction, but they would be using the Portland mechanism underneath.

Perhaps the most interesting thing to be seen from the slides, however, is the expanded view of the "desktop" being taken by the group. Mobile and embedded systems - from the OLPC to the Nokia 770 and telephones - are clearly seen as a sort of desktop system. Many of the issues are the same, but the incorporation of mobile applications brings new pressures. One can, with little effort, find plenty of evidence that the desktop projects have not, so far, been overly concerned with memory use and overall bloat. Small systems are forcing people to reconsider their priorities, however, and there is likely to be an increase in the amount of development time which goes into making things smaller. A few of the participants note that better tools for memory profiling would be most helpful in this task.

Overall, there appears to be nobody who is willing to predict total World Desktop Domination anytime in the near future. There is, however, a clear level of interest in the Linux desktop, especially when one considers desktops which fit in a shirt pocket. Interesting things are going to happen in this area.

(Log in to post comments)

out-of-tree drivers

Posted Dec 7, 2006 4:57 UTC (Thu) by xoddam (subscriber, #2322) [Link]

> Hardware should work when bought. No vendor can fix this

You're wrong here. Vendors are perfectly capable of supplying their own
drivers.

However much the key kernel developers discourage it on the surface, it
is not impossible to maintain a driver out of the official kernel.org
source tree. In fact it is much easier to build an out-of-tree module
for a 2.6 kernel than it was for 2.4 kernels. Such tactics as the GPL
only symbols discourage non-GPL drivers, but many GPL drivers are
maintained out-of-tree.

If vendors wish their cutting-edge hardware to be supported on an
already-released distribution, they will provide some way to install a
module on that distribution without upgrading the vendor kernel. The
simplest way is to provide a package which contains the driver source and
builds it against the headers of the installed kernel. Most
distributions these days package the appropriate headers, installed to a
canonical location.

There is a certain difficulty in maintaining a single driver which can be
built and run on several different versions of the kernel, because of the
fluid API. This is not a crippling disability: stick to interfaces which
appear in all versions of interest and have not yet been "deprecated" and
you'll be fine. Get it into the tree and you can stop caring about
future kernel versions and watch your support problem disappear as users
upgrade.

The burden of cross-version compatibility is rightly placed on those
vendors who wish to continue to maintain out-of-tree drivers. The
alternative is to start building a house of cards, which will end up as
stable and lovable as the Windows 98 kernel. New devices are commonly
sold compatible with "Windows XP or later"; if hardware vendors can so
cavalierly drop support for an OS with the installed base of Windows NT
4.0 (service pack n), they should not hesitate to abandon Red Hat 9.

Debian's module-assistant

Posted Dec 15, 2006 0:39 UTC (Fri) by blujay (guest, #39961) [Link]

Debian has this down pat.

$ sudo m-a a-i whatever

m-a = module-assistant
a-i = auto-install

This automatically installs the kernel headers, installs the module source, builds the module, puts it into a deb package, and installs the package.

What the desktop architects are talking about

Posted Dec 7, 2006 9:40 UTC (Thu) by bignose (subscriber, #40) [Link]

> Someday, maybe, the free software community will be so rich that nobody will ever wish for a proprietary application for their Linux systems.

I doubt that; there will always be those who ask users to forfeit their freedoms and betray their community in return for some bauble.

> Until that time, we will either have to make life easier for those vendors or simply write off a large subset of potential desktop Linux users.

This dichotomy is commonly presented, but it's false.

We can do more than just "write off" potential users; we can *enlist* them in the process by showing them an atractive free software environment that they *want* to use, and encourage them to use their power as customers of the non-free vendors to free their wares.

The non-free vendors only care about free software to the extent that their customers care about it. So long as we see users of non-free software as lost causes, we'll never have them as allies in growing the free software community.

What the desktop architects are talking about

Posted Dec 7, 2006 10:03 UTC (Thu) by dion (subscriber, #2764) [Link]

Well, I happen to think that supporting non-free software on a Free OS is not a bad thing.

(Non free drivers is another thing entirely, though)

More users will always mean better support for all users, so our first goal ought to be to grow the number of users.

If the new users are using 100% Free software then that's great and we all win big, but even if the new users are using certain non-free pieces of software then we still win, just not as much.

The worst case is a user who stays on a non-Free OS, just because their non-free application cannot work on the Free OS.

What the desktop architects are talking about

Posted Dec 7, 2006 12:07 UTC (Thu) by hansl (subscriber, #5086) [Link]

Yes, and that's were Wine can help out too. A user that
runs a proprietary app on Linux + Wine instead of Windows
is a net gain for free software, just like running Firefox
or OpenOffice on Windows is a net gain for free software.

We have to make the transition easier and less of an all or
nothing issue when it comes to running proprietary apps (and
OSes), even if that means the user can also switch back easier.
We can't resort to lock-in or lock-out strategies, free software
should win entirely on it's own merit, that is, by being free.

What the desktop architects are talking about

Posted Dec 7, 2006 18:29 UTC (Thu) by iabervon (subscriber, #722) [Link]

What people should be looking for is not a single distribution or a single desktop environment. What they should be looking for is the desktop equivalent of POSIX or SUS.

Most desktop applications want something like "audio_send_alert(audio_read_file(filename))". I think that, if every distribution had a -laudio with these functions (and the appropriate cleanup functions) that worked with whatever sound server, sound drivers, system libraries, etc. were in use (or, at least, were provided by the distribution), there would suddenly be a whole lot less interest in standardizing on a piece of software. Of course, the sound servers and such would still have to fight over the library, but application developers wouldn't have to care; they link against a standard stub library, and if the software doesn't work on some distro, it's clearly the distro's fault.

The reason *NIX in general works is that it is founded on a set of implementation-neutral standards, which everybody can agree on (at least as far as the non-obscure stuff). If I want to receive data by TCP and write it to a file, the code I write doesn't depend on which *NIX I'm using. And even the compiled code only depends on the C ABI I'm using, not the filesystem I'm writing to, the TCP implementation the kernel uses, or any of that stuff. Surely it's easier to standardize on an interface for "read opaque sound data from a file" and "play it".

What the desktop architects are talking about

Posted Dec 7, 2006 19:48 UTC (Thu) by vmole (guest, #111) [Link]

And it took years for POSIX to be specified, more years for each vendor to meet the spec, and even then there was a bunch of useful stuff (mmap(MEM_SHARED), anyone?) that was either not specified or under-specified to the point of being useless (that is, I still had to write vendor-specific code).

Don't get me wrong, POSIX (and the various SUS specs) were great steps forward, but not a complete panacea. When you've got multiple competing implementations, each of which works, getting some team to basically say "okay, we'll let ours go" is tough. Yeah, you can invent new interfaces to sit above the real implementations, but either it's baby simple (which may be enough for an alert sound, but not much more), or is broken (new interfaces of any complexity are *always* broken until enough people have used them to get it right).

What the desktop architects are talking about

Posted Dec 7, 2006 21:46 UTC (Thu) by iabervon (subscriber, #722) [Link]

This sort of thing only really works when everybody knows how to do it, and it's just a matter of choosing a bikeshed color and giving it a neutral name.

But my feeling is that 90% of applications want to do the baby-simple thing, so it would be worth doing that much. Then 9% are games, and want to use SDL. And the other 1% are media players, and can justify the hassle of interfacing with all the weird libraries (and want stuff like cross-fade, streaming decoding, and synchronization with video). When a lot of applications want trivial stuff for trivial effort, it's worth providing just that. There's a bad tendancy to not provide a solution at all until it solves absolutely everything. If there's a manageable, self-contained chunk that is easy and people want it, do just that much and get it out there. People who want to do more complicated things can ignore you.

For that matter, it's reasonably likely that users would want different behavior for alert sounds than other audio. If you're listening to some music, and do something that also has music, you tend to want to hear only one of these at a time, but you generally want to hear all of the alerts that programs send. And people often want separate volume controls, so if their music is quiet and they've turned up the volume so they can hear it, program beeps aren't louder. And if I'm playing music for a roomful of people on nice speakers, and I get an alert sound, I'd like it to come out of my laptop speakers, if at all.