Our community has a number of volunteer-organized events; some of them are
rather more organized than others. Anybody who thinks that volunteers
cannot produce a professional-quality (or better) event, though, has never
been to linux.conf.au. LCA is not just run by volunteers; it is organized
by a completely different group of volunteers every year, but it still
comes off reliably, every time, as a top-quality conference. Each year's
organizers clearly deserve a lot of credit, but there is also a lot of
value in the LCA "ghosts" institution, whereby organizers from previous
years give advice and keep a watch for red flags as the planning and
preparations go forward. Without the ghosts, LCA would not be what it is.
Now imagine that you have been planning an event for over a year. Two
weeks before the conference, venues, equipment, accommodations,
transportation, social events, and more are all in place. Then the host
city is hit by catastrophic floods, the venues for both the conference and
the social events are taken out of commission, and the routers for the
wireless network are soaking at the wrong end of a flooded warehouse. Even
if a new venue can be found, it will no longer be within walking distance
of the accommodations, so transportation must be arranged on short notice.
That is the point where the ghosts run out of useful experience to share.
It is also the point where an insufficiently determined group would simply
The organizers of LCA 2011, held in Brisbane, would appear to be a
determined bunch indeed. They found a new venue, reprinted the conference
maps, found new locations for the social events, swam through the warehouse
to recover the routers, arranged new transportation for the attendees, and,
beyond any doubt, did a thousand things that nobody else saw. The end
result was a conference which, barring knowledge to the contrary, would
have seemed like they had planned it that way all along. LCA 2011 didn't
just work - it worked just as well as its predecessors. One easily runs
out of superlatives when describing the job this group did; your editor
only hopes that, after they have slept for a solid week or so, they have
arranged a major party to celebrate what they accomplished.
There were a number of interesting sessions at this conference, many of
which have been covered in these pages. Here, your editor will summarize
some of the talks which, for various reasons (including simple time) were
not discussed in a separate article.
Andrew 'Tridge' Tridgell has developed a reputation for energetic
LCA talks focused on the simple joy of hacking; his LCA 2011 talk did not
disappoint. Tridge, it seems, has become somewhat of a coffee snob, so he
has taken to roasting his own beans. That turns out to be an
attention-intensive process which takes too much time away from the hacking
that coffee is meant to support, so he built a Linux-powered coffee roaster
out of an old bread maker, a temperature sensor, a heat gun, and a
hand-made circuit for power regulation.
While demonstrating the device and hoping the fire alarms did not sound, he
went into the specifics of coffee roasting and the details of how one uses
LD_PRELOAD to reverse engineer a Windows temperature driver
running under Virtualbox on Linux. A good time was clearly had by all.
Bdale Garbee's session on the creation of a large, Linux-powered
milling machine had a similar feel. Both talks will be well worth watching
once the videos become available.
Daniel Bentley and Daniel Nadasi talked about the challenges that go
with opening up code at Google. Internal programs tend to be heavily used
and have a lot of internal contributors; these people often have a lot of
worries when they are approached about releasing their code to the world.
They have to be sold on the business case for opening the code, and they
have to be talked past worries that their code is too ugly to see the light
of day. There are also some real concerns that opening code might reveal
internal information and that working with the community might slow the
project down. Changing source control and build systems can also be a
challenge; apparently few people at Google still remember how to write a
An important question is: where is the home for the code's further
development? If it's developed internally, the internal folks are happy
because things are working as they were before. Outsiders, who see a
series of code dumps, may be less impressed. If development happens
publicly then outside developers will be happier, but it can be harder for
internal developers. An added factor is that any project, no matter how
successfully it is opened, will be dominated by internal developers during
part of its open existence; that tends to drive the internal development
model, but that, in turn, can slow (or prevent) the development of a
community around the code.
Daniel and Daniel's response to this problem is a tool called "make open
easy," or "moe." With moe, internal developers can mark sections of code
which should not be visible to the outside world; markings can take the
form of function annotations or preprocessor-like directives. The tool can
then extract the code from the internal repository, edit it according to
the directives, and load it into a public repository. Importantly, it can
also move code in the other direction, merging external changes while
retaining the scrubbing directives. Moe makes lives easier on both sides
of the wall, and is in active use with a number of projects; it can be
obtained from code.google.com.
Carl Worth gave a well-attended session on the notmuch mail system. Notmuch has been reviewed here in the past; your editor was
mostly interested in the current and future state of this search-oriented
mail tool. Recent changes include the ability to search on mail folder
names - useful for migrating from a folder-based mail client. There is
also synchronization with maildir flags, which is helpful for people using
both notmuch and a more traditional client. There are now a few supported
output styles for search operations, which should make it easier to create
a web-based notmuch front-end, among other things.
In the near future, notmuch users should expect the ability to search on
arbitrary mail headers and some relief from the rather inflexible date
format which must be used now. Further ahead, there will be more work
toward synchronization with remote mail spools; the hard part here is
moving tags back and forth. Options for a solution include the addition of
a special header to the messages themselves (but that could be problematic
if the header leaks in a forwarded message, revealing to all the tags one
uses for mail from the special people in one's life), the use of custom
maildir flags, or the addition of some sort of journal replay mechanism.
There is also talk of storing mail in git packs and using the git protocol
to move messages (and tags) around. Even further ahead might be a notmuch
backend for mutt.
Meanwhile, the project has a number of interested users but, by Carl's
admission, it could benefit from a more present maintainer.
Kirk McKusick is one of the creators of BSD Unix. His fast-paced
session in an overflowing room covered much of the history of the Berkeley
Software Distribution, the ups and downs of hacking with Bill Joy, the ATT
lawsuit, his refusal to work for just-starting Sun Microsystems (because
Apollo had the workstation market completely sewed up), and much more. The
talk should eventually appear with the rest of the conference videos; there
is also apparently a DVD available on Kirk's web page for those who want
There were far more interesting talks than your editor could possibly
attend, much less write up. The good news is that the conference
organizers are making the videos available quickly; they can be found (in
several formats) on this blip.tv page, but this wiki page has them in
a much better-organized fashion.
In summary: LCA 2011 was another great success; it would have been judged
favorably against its predecessors even in the absence of natural
disasters. LCA 2012 will,
perhaps surprisingly, be held in Ballarat, a
small city outside Melbourne. The Ballarat organizers have a hard act to
follow, but history suggests they will be up to the task.
to post comments)