The seventh annual Ottawa Linux Symposium has come to an end. Your editor,
who has attended six of the seven OLS events, finds the conference in good
health. OLS was larger this year - some 700 people - but it has handled
its growth well. OLS remains one of the premier Linux development
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
- 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
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
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
to post comments)