The 2007 [Ottawa] Linux Symposium has run its course. All of the
casualties from the closing party (perhaps made more numerous by the new
practice of sending around waiters with trays full of shots of tequila)
should have found their way home by now. Your editor has returned from
this year's event; here's his summary of what took place.
Greg Kroah-Hartman has been digging through the kernel source repositories
for statistics much like your editor has. The resulting numbers are
similar, though Greg has cranked through the full 2+ years of history in
the mainline git repository and,
thus, has a longer-term sort of view. Among other things, he concluded
that, in that time, the kernel developers have averaged almost three
changes per hour - every hour - during that time. About 2000 lines of code
are added every day. That is a pace of development which is matched by few
- if any - projects anywhere in the world. Greg also notes that the number
involved is growing with each release. This, he says, is a good sign; the
kernel community is bringing in new developers, important to keep the
Those interested in the detailed numbers can find them in Greg's paper (all
of the OLS papers are available
online). What many people found as interesting as the numbers,
however, was Greg's chain-of-trust poster. He took the signed-off-by path
from every patch in 2.6.22 and plotted all of them as a big graph. The
result, showing the approximately 900 developers who got patches into
2.6.22, was a plot some 40 feet long which crashed almost every
printer he tried to print it on. The plot for the entire git repository
history would have been nice, but, Greg says, it would have printed out at
One might have expected the plot to look like a nice, neat tree showing how
patches move up through the subsystem maintainers toward the mainline. In
fact, says Greg, it's "a mess." The interactions between kernel developers
are broad and do not fit into any sort of simple hierarchy; it is a loose
and flexible system.
Greg encouraged all developers represented on the plot to sign their little
bubbles; after the poster has run up some frequent-flier miles and acquired
enough signatures, it will be auctioned off for some good cause. Over the
course of the conference, just over 100 developers added their signatures.
Jon "maddog" Hall is not quite the ubiquitous figure at Linux conferences
that he was a few years ago. So it was nice to see him show up at OLS this
year. Maddog remains an engaging and amusing speaker. His topic this time
was how we are really going to get Linux systems to the masses - especially
in the urban environments which house much of the population in the
developing world. His answer is thin clients. He would like to see most
users working with small, low-power, fanless boxes with a nice screen and
the ability to talk with a central server which hosts software, user files,
and more. All running Linux, of course.
His vision for where this could go is ambitious: he would like to see
150 million of these thin clients deployed in Brazil, for example,
supported by as many as 2 million servers. This would bring
affordable computing to almost all of Brazil's city dwellers in an
ecologically sensible way while providing about 2 million technical
jobs. And it could all be done through private initiatives. If this sort
of development can be made to happen, says Maddog, we may truly achieve the
potential offered by computers and by free software.
Martin Bligh has an interesting job: he gets to find out what causes the
occasional machine to go wrong in the middle of the massive Google
network. It can be a real pain when, on occasion, one machine out of
thousands will crash or slow way down in a non-reproducible way. And only
in production, of course. Martin described a few such problems and how
they were tracked down through the use of a set of tracing tools used at
Google. Finding this kind of problem requires the ability to collect data
in a flexible manner without disrupting ongoing operations. Google has
developed the tools to do this sort of tracing; much of the resulting work
will be merged into LTTng project and
made available to the community.
The keynote speaker this year was James Bottomley, who spoke on the topics
of diversity and evolution. Diversity is the stream of new ideas which are
always being directed toward any active free software project; evolution is
the (sometimes harsh) process which selects the ideas which actually work.
Evolution in this context is selecting mostly on the patience and
innovation of the development community - not necessarily on the usefulness
of a given patch. KAIO (kernel asynchronous I/O support) was given as an
Maintainers play a vital part in the evolutionary process. The key to
being a good maintainer - one who helps move the community forward - is to
not reject changes out of hand but to work with developers to bring things
up to kernel standards. Being a maintainer, says James, is not about
saying "no"; it is about saying "no, but..."
Fragmentation is often raised by proprietary vendors as a way of scaring
people away from Linux. Bringing up fragmentation is a way of calling up
memories of the Unix wars, where fragmentation truly was a damaging
phenomenon for just about everybody involved. In the free software world,
though, we don't have fragmentation; instead, we have forking. James
claims that forking is an essential source of diversity; it's necessary for
continued innovation. No project, he says, is truly open unless it can
fork. In the end, openness and evolution drive forks to merge back
together, propagating the good ideas that resulted.
One final topic was nearly inevitable: closed-source drivers. Unlike some
other speakers, James was unwilling to characterize such drivers as being
either illegal or immoral. Instead, he looked at the costs involved in
keeping drivers closed source - costs for both the vendor and the users -
and concluded that closed-source drivers are simply "bloody stupid."
Happily, he says, some vendors are figuring this out. He announced that
Adaptec has become the first vendor to make use of the Linux Foundation's
NDA program to
provide information for the creation of free drivers for its products.
This year marks the first time in some years that the Kernel Summit was not
held just before the Linux Symposium started; many people expressed
concerns that kernel developers would stay away this year and OLS would not
be as interesting an event. There was a reduction in the number of
high-profile kernel developers this year, though quite a few were still in
evidence. The 100 signatures on the 2.6.22 poster make an effective
demonstration that OLS is able to attract kernel developers even without
the summit. One result of the change may be that a few more relatively new
and inexperienced developers were able to present this year; that should be
seen as a good thing.
Something that fewer people worried about, but which may have hurt the
conference more was the
absence of the desktop developers summit. Desktop developers were
generally absent, making the 2007 Linux Symposium, if anything, even more
kernel-centered than in previous years. Bringing together developers from
all over our wider community is an important function of a conference; one
hopes that the desktop folks will be back next year.
On the other hand, it was a pleasure to see the large "Linux on Cell"
contingent sent by Sony. The embracing of Linux by a company which has not
always been known for its openness can only be a good thing, and nobody was
complaining about the frequent giveaways of Playstation 3 systems -
though your editor, with his usual luck, failed to win one. The Cell
architecture seems destined to do interesting things, especially if the
companies which are working with it continue to promote and support the use
Back to the topic of next year:
2008 will be the tenth Linux Symposium; the organizers are clearly already
thinking about how they can make it the best one yet. There is thought of
moving it out of Ottawa to another Canadian city, and some
possible changes to the organization of the event, including a
track-oriented schedule and tutorial days, have been mentioned. This is
all good; OLS is probably due for a makeover after all of these years.
The 2007 event has shown that OLS can be successful on its own, without
leaning on the kernel summit; perhaps 2008 will show us where this
important community event can go in the future.
to post comments)