Ottawa Linux Symposium, 2005: first day

by Andy Oram

Related link:

I've finished the first day of the Ottawa Linux Symposium, and already
feel I've had enough conference to last a long while. The last time I
got to an OLS was four years ago. In the intervening time they've
grown a great deal, learned a lot, and become even more
professional. Some 800 attendees from 37 countries are here.

Already, two speakers have made wisecracks about,
tagging it as a bloated memory hog. I have the suspicion that some
attendees see Linux as something to run for its own intrinsic value,
rather than as a platform for useful applications that can actually
help people accomplish something.

The keynote speaker was Jonathan Corbet of the highly respected news site,
and lead author on the two latest editions of
Linux Device Drivers.
A few months ago, he ruminated at his site on the critique
that Linux doesn't have a road map. His retort was that
there is plenty of information in full view about where Linux is
heading, for those with the time and knowledge to put it together.

Jonathan's keynote built on this assertion by providing some
predictions (with suitable caveats) about the upcoming course of
Linux. These predictions include the entrenched use of git for Linux
source control, more support for clustering filesystems, consensus on
the use of SELinux for security, and various enhancements to improve
real-time response (including more preemption and I-pipe interrupt
handling). What was interesting about Jonathan's talk, of course, was
not the laundry list of features, but his explanations of what
motivated them and why they seemed good solutions.

Another talk I enjoyed was the report by X Window System/Project
Athena leader Jim Gettys (just laid off by Hewlett Packard when they
closed his lab) on his gedankenexperiment about creating a
more responsive computer environment. His vision fits with the
pervasive computing movement that gave rise to Project Oxygen and
other experiments. In this world, we would all be able to look
virtually over a coworker's or spouse's shoulder at a remote location
and scribble on their screens. We could switch a remote control from a
TV screen to an audio speaker when a phone call comes in, and then
pick up a keyboard if the phone call demanded text input--all these
devices capable of operating independently and connecting with other
devices on the drop of a dime.

What was most interesting about Jim's talk was not the grand vision
(they come a dime a dozen) but the set of stepping stones he drew
between the technologies we have now and the capabilities of the
future. He endorsed Zigbee, for instance, as a wireless protocol more
appropriate for the kind of flexible environment he put forward than
either Bluetooth or 802.11. He praised Zeroconf and distributed
caching filesystems such as Coda. On the other hand, he lamented the
lack of convenient systems for retrieving geographic information and
employing it to shape interactions.

Authentication is key to opening up information sharing, so that
people can share just what they want and protect the rest. Thus, Jim
wants X to have a concept of a user, just as the underlying operating
system does. Like Corbet, he sees an important role for
SELinux. Unlike Corbet (who is not enamored of SELinux) Gettys wants
it used by X for its security. He also thinks there's potential in
SASL, which I find a rather heavyweight spec.

Another interesting aspect of Jim's ambitions is that they are
imminent, not something that we'll have to live a long time before we
see. He thinks the way open-source software allows everyone to
approach and play with the internals of all the components can bring
us a brave new world within a couple years--if the will is there.

One advantage of the close examination that a conference like this one
gives to its subject matter is that you see the unsavory
underside. Marcel Holtmann zipped expertly through a comprehensive
assessment of the state of Bluetooth on Linux (the BlueZ project) and
how far each protocol had come. Martin J. Bligh reported the
frustrations of making memory management robust on Linux. Even though
millions of sites are comfortably and reliably running Linux, the
basic operating system task of memory management has a way to go.

There are still ways that users (not even maliciously) can occupy
memory until there's not enough left to keep the system going. Two
major memory crimes that contribute to this situation are pinning
memory (that is, leaving around references that make it impossible for
the kernel to free some routine house-keeping data) and creating large
numbers of dirty pages (memory that has been changed but that the
kernel hasn't had a chance to write back safely to disk yet).

The former problem is deeply embedded in the kernel's design. The
latter occurs in situations the kernel developers know how to check
for, but checking for it would add a substantial burden to routine
memory allocation. In fact, even instrumenting the kernel to help
developers track memory usage would add a substantial burden to
routine memory allocation. And since a program can often cause a
memory allocation simply by calling a different function or reading in
a new line of data, allocation cannot be burdened that way. The most
desperate act that the kernel engages in for self-rescue in low-memory
situations--killing a user process--often chooses a process that's not
important or not particularly wasteful of memory.

A sign of this conference's appeal is that a talk such as Bligh's on
memory management could attrack hundreds of people, and that audience
members came up with several suggestions and specific requests. As I
pointed out, millions of users rely on Linux 24/7 and never have a
problem with memory management. But there are dozens of developers who
want Linux to be even better.