<HTML>
<HEAD>
<STYLE>
<!--
A{text-decoration:none}
-->
</STYLE>
<TITLE>Doom</TITLE>
</HEAD>
<BODY BGCOLOR="#000000" LINK="#f02020" VLINK="#c0c040" TEXT="#ffffff">
<h2>Doom as a tool for system administration</h2>
<p>As I was listening to
<a href="http://www.cs.unm.edu/~soma">Anil</a> 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
<code>kill -9</code> again.</p>
<p>
<center>
<img src="start.gif"><br>
Sneaking up on my processes.
</center>
</p>
<p>In 1981,
<a href="http://www-rohan.sdsu.edu/faculty/vinge/">Vernor Vinge</a>
introduced the concept of cyberspace to the reading public in his
short story
<a href="http://car54.cc.gatech.edu:1880/truenames/"><i>True Names</i></a>,
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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p><a href="http://www.idsoftware.com">Id Software</a> has generously released
the source for
<a href="http://www.idsoftware.com/killer/doomult.html">Doom</a>,
which has been ported to <a href="http://www.linux.org">Linux</a>.
I downloaded <a href="http://tux.telefragged.com/file.pl?filename=xdoom-990926.tar.gz&dir=doomworld/ports/">one</a> of the
<a href="http://www.doomworld.com/ports/linux_unix.shtml">many versions</a>
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.</p>
<p>
<center>
<img src="attack.gif"><br>
Help! I'm being attacked by csh (pid 18729)!
</center>
</p>
<p>Some of the potential benefits of using Doom as a tool for system administration:
<ul>
<li>The machine load is immediately apparent to the player,
who can see how crowded a room is. The player can eyeball many
machines from a high vantage point and go down to a room that
needs maintenance.
<li>There is a nice continuum for resource allocation.
A user may choose to simply wound processes rather than killing
them, which could naturally be translated to renicing them.
<li>A new sysadmin can be given less power by providing her with a
smaller weapon. A rank beginner may not be given a weapon at all
and be forced to attack processes with her bare hands. It would
take a foolhardy player to attack a room full of monsters, just
as a newbie should not kill a bunch of important processes.
A more experienced sysadmin would have time to stop a newbie who
is trying to kill the wrong process.
The real work could be left to those with the big guns. The truly
great sysadmins could have BFGs.
<li>Really crowded systems would regulate their own load because
monsters occasionally kill each other. Once the population in a
room goes down, the monsters will stop attacking each other.
<li>Drastic action takes work. In a command line interface, all
actions take approximately the same amount of effort. One
can <code>ls</code> just as easily as <code>rm -rf *</code>,
which is kind of unfortunate.
In a cyberspace environment, the players are not omnipotent,
so performing large actions takes time and effort.
<li>Important processes can be instantiated as more powerful
monsters. They can then defend themselves against inexperienced
sysadmins.
<li>Sysadmins could cooperate or compete. Doom is a natural
environment for player-to-player interactions. A team of players
can cooperate to take care of a heavily-loaded system, or they
can even take out rogue sysadmins who are killing the wrong
processes.
<!--
<li>Players would be more likely to monitor their systems very
carefully so their characters don't get killed. They may even
work for longer hours without pay.
-->
</ul>
</p>
<p>A few of the problems of using Doom as a tool for system administration:
<ul>
<li>Certain processes are vital to the computer's operation and
should not be killed. For example, after I took the screenshot
of myself being attacked by <code>csh</code>, <code>csh</code>
was shot by friendly fire from behind, possibly by <code>tcsh</code>
or <code>xv</code>, and my session was abruptly terminated.
<li>Mapping processes to appropriate monsters is difficult.
Should large processes be mapped to large monsters?
Should the monster type reflect the CPU as well as memory usage?
Should processes and their children look alike?
<li>It is difficult to tell if your employees are doing real work
or just goofing off when tools and games have the same GUI.
</ul>
</p>
<p>
I'd like to thank the
<a href="http://www.cs.unm.edu/~immsec/adaptive-web/ac_main.htm">Adaptive Computation Group</a>
at <a href="http://www.unm.edu">UNM</a> 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
<a href="http://www.nsf.gov">National Science Foundation</a>
(without their knowledge) through a BIO Research Training Group
in
<a href="http://sevilleta.unm.edu/~ehdecker/complexity/99fall/">Ecological Complexity</a>
(NSF <a href="http://www.nsf.gov/cgi-bin/showaward?award=9553623">9553623</a>).
</p>
<p>
If you really want to try this yourself on a Linux box, you can.
The application is very touchy and development is hindered by guys
with shotguns killing my shell windows.
I have only tested it on an Intel.
A great deal more work is needed to turn it into a useable product.
I don't expect to work on it much more, so I am releasing the
source so hackers can play around with it. I made very few changes
to the original Doom source, so if you already have a favorite Doom
port, it would not be hard to adapt my changes to it.
Here's how to turn your Linux box into a battleground:
<ol>
<li><a href="http://tux.telefragged.com/file.pl?filename=xdoom-990926.tar.gz&dir=doomworld/ports/">Download</a> the original doom port that I used.
<li><a href="xdoom-process.patch.gz">Download</a> my patch.
<li><a href="http://www.idsoftware.com/archives/doomarc.html">Download</a> the
iwad file from Id.
<li>gunzip the port and the patch file. untar the port.
<li>Enter the directory that contains the Doom port and type:<br>
<code>patch -p1 < <i>path of my patch file</i></code>
<li>Follow the instructions provided in the READMEs to build the app.
<li>Move the doom1.wad file and the executable into the data directory.
<li>Try not to shoot the monster that represents your primary shell.
</ol>
</p>
<p>
<a href="mailto:dlchao@unm.edu">Mail</a> me your insightful comments.
I would especially be interested in hearing about implementation
changes that you have tried.
</p>
<p>
<i>Dennis Chao<br>
<a href="mailto:dlchao@unm.edu">dlchao@unm.edu</a><br>
October 17, 1999</i>
</p>
<!-- Start of TheCounter.com Code -->
<SCRIPT><!--
s="na";c="na";j="na";f=""+escape(document.referrer)
//--></SCRIPT>
<SCRIPT language="javascript1.2"><!--
s=screen.width;v=navigator.appName
if (v != "Netscape") {c=screen.colorDepth}
else {c=screen.pixelDepth}
j=navigator.javaEnabled()
//--></SCRIPT>
<SCRIPT><!--
function pr(n) {document.write(n,"\n");}
NS2Ch=0
if (navigator.appName == "Netscape" &&
navigator.appVersion.charAt(0) == "2") {NS2Ch=1}
if (NS2Ch == 0) {
r="&size="+s+"&colors="+c+"&referer="+f+"&java="+j+""
pr("<A HREF=\"http://www.TheCounter.com\" TARGET=\"_top\"><IMG")
pr("BORDER=0 SRC=\"http://c1.thecounter.com/id=169771"+r+"\"></A>")}
//--></SCRIPT>
<NOSCRIPT><A HREF="http://www.TheCounter.com" TARGET="_top"><IMG
SRC="http://c1.thecounter.com/id=169771" BORDER=0></A>
</NOSCRIPT>
<!-- End of TheCounter.com Code -->
<br>
<i><a href="..">back</a></i>
</body>
</html>