As I was listening to
Anil talk about
daemons spawning processes and sysadmins killing them, I thought,
"What a great user interface!" Imagine running around with a shotgun
blowing away your daemons and processes, never needing to type
kill -9 again.
In 1981, Vernor Vinge introduced the concept of cyberspace to the reading public in his novella True Names, in which characters could plug into a virtual universe where their actions in a fantasy world mapped to performing sophisticated actions on the network. For example, walking along a tricky path through a swamp would be the same as going through a firewall.
The mapping of abstract operations to an intuitive environment is a difficult problem. There are two distinct obstacles: the environment must be intuitive and the mapping must be accurate. If the environment is not intuitive, it can alienate users. In a good environment, the user would instinctively do the right thing. The quality of the environment is for naught if the mapping is not accurate. For instance, if certain natural actions lead to detrimental results or if desired results can only achieved by performing contrived acts, the mapping to the underlying processes must be learned.
The difficulty of the mapping is evidenced by the paucity of good user interfaces that use physical metaphors. The only widespread example is the "desktop" interface, where files are held in "folders" which may be "opened" or "thrown away". This is a fairly good mapping, but there are certainly problems. For example, the user must understand what "links" are to figure out why some folders are not always accessible. The user must also realize that one can close a folder and still see the contents of its sub-folders.
I am proposing a new mapping for managing system loads. As mentioned above, people frequently talk about "blowing processes away", and the Unix command to destroy a process is "kill". This suggests a metaphor for process management. Each process can be a monster, and the machines can be represented by a series of rooms.
Id Software has generously released the source for Doom, which has been ported to Linux. I downloaded one of the many versions and added a few lines of code that would spawn a new soldier for each process, renice the process when it is wounded, and kill the process when it dies.
Some of the potential benefits of using Doom as a tool for system administration:
lsjust as easily as
rm -rf *, which is kind of unfortunate. In a cyberspace environment, the players are not omnipotent, so performing large actions takes time and effort.
A few of the problems of using Doom as a tool for system administration:
cshwas shot by friendly fire from behind, possibly by
xv, and my session was abruptly terminated.
I'd like to thank the Adaptive Computation Group at UNM for providing a supportive environment in which one can claim one is doing research while playing Doom for two days. This work was funded by the National Science Foundation through a BIO Research Training Group in Ecological Complexity (NSF 9553623).
Mail me your insightful comments. I would especially be interested in hearing about implementation changes that you have tried and responses to my CHI 2001 paper or talk on PSDoom.
October 17, 1999
Click here to get the code, read the paper presented at the CHI 2001 Conference, follow links...