[MUD-Dev] Something in the water

[J C Lawrence]

On Thu, 26 Jul 2001 02:15:02 -0500 
Eli Stevens <listsub at wickedgrey.com> wrote:

> Like if you could pick out groceries from a virtual store and then
> only had to drive to the store, pay and pick up the bags, 

I have shopped at furniture and electronics stores which worked like
that:  

  Wander the store with a bar code reader swiping the bar codes of
  the things you want to buy.  Go to the checkout counter, drop in
  your reader, pay the clerk.  Drive/walk around to the shipping
  dock and there's a palette with your purchases, or juse leave and
  have it delivered to your house next morn.

  Mapping that to a web interface would be trivial (cf ex-WebVan).

> Heck, if I could fire up Quake and hop on over to my school's
> financial aid office server and argue with them about giving me my
> scholarships without having to go down there and do it face to
> face...  :)

http://www.cs.unm.edu/~dlchao/flake/doom/

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

<http://www.cs.unm.edu/~dlchao/flake/doom/start.gif>
Sneaking up on my processes.

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.

<http://www.cs.unm.edu/~dlchao/flake/doom/attack.gif>

Help! I'm being attacked by csh (pid 18729)!

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

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.

Dennis Chao
dlchao at unm.edu
October 17, 1999
--<cut>--

--
J C Lawrence                                    )\._.,--....,'``.	    
---------(*)                                   /,   _.. \   _\  ;`._ ,.
claw at kanga.nu                                 `._.-(,_..'--(,_..'`-.;.'
http://www.kanga.nu/~claw/                     Oh Freddled Gruntbuggly
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev