Joey and I decided to create an umbrella project—a meta-project. The plan was to spur development of HAL-aware applications that can provide hardware policy on the desktop. Never should a user need to configure hardware. It should happen automatically in response to the user plugging the hardware in. Never should the user (or even the programmer) have to mess with device nodes and esoteric settings. HAL should provide all of that, on the fly, to the applications. Never should the user have to guess how to use new hardware. If I plug in a camera, my photo application should run. If I insert a DVD, it should start playing. All of this should happen magically, automatically and cleanly.
I coined the name Project Utopia. It was, after all, a bit utopian.
We did not have a central Web site or source repository or cute logo. Project Utopia was a cause and a way of thinking. We had a goal and a set of use cases and a growing disgust toward things not working. We blogged and spoke at conferences and wrote code. One by one, piece by piece, we started to build a set of policy pieces on top of HAL, guided by the following rules:
Make hardware just work.
Use HAL, udev, sysfs and 2.6 Linux kernel as our base.
Tie it all together with D-BUS.
No polling, no hacks—everything should be event-driven and automatic.
Carefully divide infrastructure into system and user level.
System level should be platform-agnostic; user level, GNOME-based.
I began writing GNOME Volume Manager in late December 2003. It was originally a proof of concept—a test bed for my ideas. I wanted to see how feasible hardware management on top of HAL could be. The plan was to respond to events such as “new hardware” or “audio CD inserted” with specific actions. GNOME Volume Manager is nothing but a simple finite state machine, receiving hardware-related events on one end and replying with hardware-induced actions on the other. The tricky part was to do it all with HAL: no polling, no hacks.
GNOME Volume Manager implemented the Project Utopia policy related to block devices. When the user inserted an audio CD, GNOME Volume Manager would play it. When the user inserted a USB keychain device, GNOME Volume Manager would mount it and open a Nautilus window. When the user plugged in a camera, GNOME Volume Manager would ask if it should automatically import the photos into the user's photo management application (Figures 2 and 3). A recently added feature even found GNOME Volume Manager managing iPods!
The next step was bringing HAL support to more applications, a process Joey and I call halification. The following months witnessed additional policy pieces, such as automatic printer configuration and seamless network management (Figure 4).
For printers, Joey wrote a HAL back end for CUPS, the Common UNIX Printing System, allowing CUPS to query HAL on the availability of printers. The result: plug in a printer and configure it automatically, on the spot.
The ambitious NetworkManager Project, started by hackers at Red Hat, aimed to solve networking woes. Seth Nickell, an early designer on the project, described the intended use case as an electrical outlet: “you plug it in and [it's] on.” For example, plug a laptop in to a docking station, and it instantly switches to the station's Ethernet. Walk into your favorite coffee shop and instantly begin using the wireless networking. NetworkManager made networking simple, automatically choosing the optimal solution for networking connectivity.
NetworkManager's architecture is two-part. First, a root-level dæmon sits alongside HAL, responding to HAL events and communicating with the system's networking hardware. Second, one or more user-level components implement policy and provide a user interface. Together, the components provide a complete solution for networking. Figure 5 is a diagram of the architecture.