Using Doom as a sys admin tool is not new, heck, been around for a few years.  But as I was surfing around the net I came across this post and thought.. eh why not, I’ll repost it.

So here is the basic point for you non sys admins out there.  Somewhere, in the deep cess pool of the company office building sites a few guys (and gals) who basically stare at a computer screen all day with tons of windows and text. Looking at bit like the matrix. No pretty icons, hardly ever use the mouse.  Just a man and his keyboard.

They basically watch the network, the traffic loads, the loads on the hardware, various tasks that start and stop.  They make sure the system does not get overloaded and tasks that should be running and running, and those that should not, are not.

However, this is not the most exciting thing in the world.  How much more fun would it be to perform pretty much the same tasks but use a video game and your controller!  Well a few years back in 1999 someone did it using Doom.

Pretty cool idea huh?  Here is more information the words of the Dennis Chao who created it.

Some of the potential benefits of using Doom as a tool for system administration:

• 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.
• 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.
• 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.
• 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.
• Drastic action takes work. In a command line interface, all actions take approximately the same amount of effort. One can ls just 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.
• Important processes can be instantiated as more powerful monsters. They can then defend themselves against inexperienced sysadmins.
• 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.

A few of the problems of using Doom as a tool for system administration:

• 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 csh, csh was shot by friendly fire from behind, possibly by tcsh or xv, and my session was abruptly terminated.
• 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?
• It is difficult to tell if your employees are doing real work or just goofing off when tools and games have the same GUI.

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).