Doom: The Aftermath
The Doom as a tool for system administration web page was Slashdotted
before I had a chance to wrap it up. However, I suppose that's not a
bad thing because now thousands of people are thinking about it, and
probably hundreds are hacking away at the code. The main things I
wish I had time to do before the project was publicized:
- Fix the pid drawing code. The pids are drawn in the middle of the
screen, regardless of where the monster is. This will be confusing
when flying monsters are present. I also think pids should only be
drawn when monsters are near the middle of the screen. Otherwise,
there is too much text.
- Modify the wad file to make large, rectangular rooms. Currently,
the wad is not changed, so all monsters are crammed in one little
section of the first level.
- Spawn off another process to poll for new processes. The program
now blocks for ps, which causes noticeable pauses in play.
An ambush!
Responses to frequently asked questions
- Where did the code go?
- Go to the the Sourceforge page to get it.
- What are they "researching" down there at the University of New Mexico?
- The people I work with are in the
Computer Immunology Group and the
Adaptive Computation Group at the
University of New Mexico.
Many of us here think about computers as living systems
and about living systems performing an implicit computation.
And of course, there's the Santa Fe Institute.
- Are your changes GPL?
- Yes. Feel free to build on it. Or scrap my changes and start on another
Doom port.
- Why can the player be killed?
- The process-player interaction is sometimes adversarial. The process
would like to run and suck up resources while the user would like other
things to have these resources. Think of it as a fight for the memory and
cycles of a computer. The processes need a way to defend themselves.
As far as they're concerned, the guy with the
kill
command
is the most dangerous thing out there.
- Why can processes kill each other?
- On very heavily-loaded machines, it is not uncommon for the OS
to kill random processes. Why not allow the processes to decide among
themselves who should live and who should die?
- When will this be ported to Windows?
- I don't do windows anymore, but someone else might. If I find out about
a windows port, I'll post a link on this page.
- Are you publishing this?
- A paper on this work was presented at the
CHI 2001
Conference on Human Factors in Computing Systems.
See the blurb under the "References in print" section below for
more information.
- Where can I download regular Doom?
- You can find various Linux ports of Doom at
Doomworld.
There are several Windows versions at this site as well, such as
WinDoom.
Under heavy fire.
How to get a copy of PSDoom for Linux
- Go to sourceforge.net to get the latest version.
- You may need to Download the
wad file from id Software.
- If you are using the id-supplied wad file, the processes are in the large courtyard on the first level.
To find it, go over the zig-zagging path over the green acid and "open" the
discolored wall (hidden door) to the right near the door.
- Try not to shoot the monster that represents your primary shell.
- I will not assume any liability for damage caused from running this code.
Especially if you are running it as root. In fact, we both know that this will
cause damage to the system, and that's why you want to try it. You have been warned.
Kill or be killed.
Links
I hope the programming community will eagerly run with this
Doom idea, so I think that many exciting developments will come from
others. For this reason, I will try to post links to interesting
implementations here. I won't have much time to really try them all
out myself, so it's up to you folks to judge them.
Taking out that last shell.
A few of the links:
CHI 2001 presentation.
The references in print:
- My paper on this project,
"Doom as an Interface for Process Management"
was presented at CHI 2001 on
April 4.
(pdf,
postscript,
gzipped postscript, and
html versions available). I have also made a few
CHI LaTeX style/class files available as
alternatives to CHI's Microsoft Word template. The slides from my talk are
available as messy jpegs.
- Hwang, F.
Commando Line Interface.
Wired.
February 2000. p. 52.
- Brockmeier, J.
A SysAdmin's Dream.
Linux Magazine.
January 2000. p. 76.
-
Systemadministration mit dem Colt.
IX: Magazin für professionelle Informationstechnik.
Heft 12, 1999. p. 44.
- Schmidt, J.
Systemverwaltung nach Hackerart.
c't: Magazin für Computer Technik
.
Heft 23, 1999. p. 68.
- Gagné, M.
A Process Smörgåsbord.
Linux Journal.
Issue 104, December 2002.
pp. 26-29.
- Game on.
Application Development Advisor. Jan/Feb 2003, p. 8.
-
Chao, D. L. Computer games as interfaces.
interactions,
11(5): 71-2.
2004.
(PDF)
Thanks
Thanks to Stephanie Forrest's
research group for providing a fertile
environment for new ideas and to all who have mailed me interesting
responses to PSDoom.
Dennis Chao
dlchao@cs.unm.edu
back
a>