Linux Symposium 2007 - a summary

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 of developers 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 process healthy.

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 250 feet.

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 example here.

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 of Linux.

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.

---

(Log in to post comments)