Ottawa Linux Symposium, 2005: first day
Already, two speakers have made wisecracks about OpenOffice.org, 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 LWN.net news site, and lead author on the two latest editions of Linux Device Drivers. A few months ago, he ruminated at his LWN.net 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.
Comments on this weblog
1 to 1 of 1
1 to 1 of 1
Return to weblogs.oreilly.com.