An OLS wrapup

A look at the schedule reveals some clear themes for this event. Virtualization is obviously at the top of the list for many OLS attendees; the largest room was dedicated to the topic for a full day. This was perhaps the most kernel-oriented schedule yet from an already kernel-dominated event; there was hardly enough non-kernel content to fill even a single track. Those who are interested in the user space side of free software may find themselves drifting toward other events; but kernel people will find plenty of interest at OLS.

OLS is an increasingly professional event; the proportion of students and part-time hackers attending the event appears to have dropped over the years. Registration fees can be as high as C$750. A surprising number of the attendees are mostly concerned with what their customers want from Linux; these are people who are making their living in a way which at least involves Linux and free software.

As always, there was no trade show floor at OLS; nobody is trying to sell anything to the attendees. OLS is very much about technology and development communities, and little about hype.

Your editor, rather than trying to provide exhaustive coverage of the event, attended some of the more interesting sessions. The resulting articles have been posted over the last week; for convenience, they are:

• A challenge for developers. Jim Gettys thinks that free software developers have to get past the "mantra of one," build the multiuser, cooperative systems of the future, and take the lead for the next generation of computing.

• Linux and trusted computing. IBM engineers Emily Ratliff and Tom Lendacky discuss the current state of Linux support for the "trusted platform module" (TPM) chip and some of the good things that it can do for us. Trusted computing does not have to be an evil thing.

• Xen and UML. Lead developers from the two most prominent Linux paravirtualization projects discuss where those projects are and what's coming next.

There was much more than the above at OLS this year; your editor, in particular, appreciated Keith Packard's discussion of the TWIN window system (designed for very small devices), Michael Austin Halcrow's description of the eCryptfs filesystem (hopefully to be written up in the future), Rusty Russell's discussion of nfsim, and Pat Mochel's sysfs talk. The Wednesday reception featured talks by Doug Fisher of Intel (who nearly got booed off the stage when it became clear that his talk was being run from a Windows system) and Art Cannon from IBM. Art's talk, a buzzword-loaded presentation on how to talk to business people about open source, was well received but hard to follow due to the poor acoustics and high noise level in the room. If you gather several hundred people (many of whom have not seen each other over the past year) into a room and give them all the beer they want, it can be hard to get them to sit down, be quiet, and listen to somebody talk about business stuff.

Dave Jones's ending keynote, instead, got everybody's full attention. Dave, who, among other things, is the current maintainer of Red Hat's kernels, is concerned with the number of regressions and other bugs seen in recent kernels. The quality of our kernels, says Dave, is going down as a result of regressions, and driver regressions in particular.

There's a lot of reasons for the problems. They date back, perhaps, to the adoption of BitKeeper. With BK, Linus could quickly pull in a large set of patches from a subsystem maintainer without really looking at them all. So BitKeeper increased the velocity of patches through the system, with some cost as to the quality. The real problem, however, is one of testing. The only way to really find kernel bugs is to have the kernel tested by a wide variety of users. This is particularly true for driver bugs; nobody, not even the driver maintainer, can possibly have all of the hardware needed to perform even remotely comprehensive testing. It takes a large community of users to do that.

When testing does happen, we need to make it easier for users to report bugs. Requiring a user to create a BugZilla account and fill in vast amounts of information for a (possibly) tiny bug is counterproductive; many bug reporters will simply give up and go away. Bug reporting should be a simple and quick operation.

There are, in any case, quite a few challenges involved in dealing with bug reporters; this was Dave's opportunity to complain a little about the frustrations of his job. Bug reporters tend to always see their bug as the most important one (so, he says, bug reporting systems should not allow reporters to set the severity of the bug); they will continue to mess with the system while others are trying to fix the bug, making confirmation of fixes difficult; some of them file a bug and disappear, not responding to requests for important information; they will lie about the configuration of their systems (and the presence of binary-only modules in particular); and so on. The receiving end of a major distribution's bug tracking system can be a difficult place to be.

The question of the proper place to report bugs came up. Many bugs seen by end users are really bugs in the upstream package, not in a particular distribution's version of it. Those bugs should be reported to the real, upstream maintainer. Some distributions (Debian, for example) see this reporting as their responsibility; others would like bug reporters to go directly upstream. Dave, in particular, notes that quite a few kernel bugs show up only in the Red Hat BugZilla system; they never make it to the (not universally used) kernel BugZilla. How many other distributors, he wonders, have kernel bugs sitting in their bug trackers which should really be reported to the community? In the future, it would be nice if BugZilla installations could talk to each other so that bugs could be forwarded to the right place; however, each BugZilla evidently has its own schema, making that sort of communication difficult.

Dave noted that the kernel has gotten significantly more complicated over the time he has been working on it. Coming up to speed and really understanding what is happening inside the kernel is a challenging task. Kernel developers need to recognize this and take advantage of all the techniques and tools which are available to them to produce better releases.

Next year's keynote speaker will be Greg Kroah-Hartman.

The final event of OLS is the infamous Black Thorn party; it is the ideal way to unwind after an intense week of conferencing. The Black Thorn is getting a little small, however; one of the OLS organizers was asking people to put their backpacks aside so there would be room for everybody to stand. If OLS continues to grow, the final event may have to happen somewhere else.