Now here’s a great interface with your operating system. Imagine literally killing processes by playing Doom.

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.