Doom as a tool for system administration (1999) | Hacker News Reader

Doom as a tool for system administration (1999)

cs.unm.edu

200 pointsTazeTSchnitzel62 comments

The paper got accepted at CHI 2001, but never would make it today. It's a nice summary of what made CHI so great in the past, and how tedious it has become.

(For the paper to make it into CHI 2015, it'd probably need a part where the author surveys 50 people and asks them inane questions such as "on a scale from 1 to 5, how likely are you to use the software for your sysadmin needs", and then measures+plots mean time for each operation on the command line vs Doom, and ends with a 3 year timeline of proposed enhancements for the software that will require additional NSF funding)

A modern version would make it to alt.chi. People present alt.chi papers (usually very though provoking) at the conference.

Yeah, alt.chi was a great idea. I often find alt.chi papers more interesting than CHI papers.

What

But this is valueless. It's a stupid idea, for obvious reasons. Okay it's sort of fun, but if a researcher wants to have fun, they should do it on their own time, or apply for funding from an arts council or something. Why should a taxpayer pay for this? Why should we want a conference to publish it?

1) please read the paper that was published (http://www.cs.unm.edu/~dlchao/flake/doom/chi/chi.html - the Discussion section is the meat of it) and don't base yourself solely on the webpage

And then

2) please enlighten me as to the "obvious reasons" that make it a stupid idea, as I don't find them obvious at all.

It should also be considered in the context of its time. CPU clocks finally ran at hundreds of megahertz. Primitive GPUs made their way down to consumer hardware. There was literally a new dimension of computer interaction to explore. We were VR crazy in the mid-to late 90s.

Aside from games, researchers were exploring all sorts of uses for this new tech. Consider this a "low brow" version of the 3D IRIX file browser that appeared in Jurassic Park, and you didn't need a professional workstation to run it.

First of all, this assumes that it was someone's job to sit there watching top all day, manually intervening and killing processes. That's ridiculous. Sometimes a sysadmin needs to kill a process --- fine, they look at the load, often know something about who's running what and why, and make a decision. This takes less than a minute. When would they ever load this stupid GUI?

What's more, any information that you can encode into the GUI representation could easily be operationalised into fixed policies, instead. The reason you need a human to do these things is because there are aspects to the decision that can't be represented in this way --- whose job it is, what their deadline is, whether that job is running within its expected parameters or outside of them, etc.

So, all this sort of interface can do is get in the way --- it makes it harder for the sysadmin to dig more deeply, and find out what they need to know.

I don't care about the side effects of this. This is going to replace every part of my workflow that it possibly can ;)

edit Okay, guys. I'm not serious. It looks fun, but not practical. It's a joke. You can stop downvoting now. Sigh...

Downvoted for not taking doom-top seriously.

Idea: pipe stdout and stderr through a text-to-speech program. Programs with noisy logs would be running around screaming like lunatics.

Somewhat related:

"The best ping story I've ever heard was told to me at a USENIX conference, where a network administrator with an intermittent Ethernet had linked the ping program to his vocoder program, in essence writing:

ping goodhost | sed -e 's/.*/ping/' | vocoder

He wired the vocoder's output into his office stereo and turned up the volume as loud as he could stand. The computer sat there shouting "Ping, ping, ping..." once a second, and he wandered through the building wiggling Ethernet connectors until the sound stopped. And that's how he found the intermittent failure."

[0] http://www.askapache.com/hacking/ping-unix-darpa-muuss.html

The FreeBSD game collection had some tunes you could play on the PC speaker around 2004-2005. So I once found myself playing the simpsons tune on the PC speaker of a server (yes it had a pc speaker) on repeat, and going into the server room to find the damn thing.

I've been thinking of a similar idea, but instead of text-to-speech, doing something like choir.io and playing positive, negative, or neutral sounds. The resultant noise would give you enough information to get a feel for what's happening.

Read an article a while back about a guy setting up his phone so that any wifi APs detected while wandering around town would play certain sounds to his headphones. This based on signal, encryption etc.

Since then i found myself pondering how we limited our computing interaction to our visual sense, where as interacting with mechanical devices also involve auditory and tactile feedback. A fridge moment was when i was waiting for my coffee machine to do its thing, and how i instinctively responded to changes in the noises made.

Never mind the analog modem days where i got into the habit of leaving the sound on for the handshake, as i could then tell if i got a good or bad connection based on the sounds heard.

Reading the paper [1], you will find the following comment -

"It is unfortunate, especially in the light of recent schoolyard tragedies, that first-person shooters are so popular. Even though studies on the effects of violent media on youth are not conclusive [..], interface designers must proceed with caution when adding potentially aggressive aspects to interfaces. One must take into consideration the age of the expected user base and the possible use of non-aggressive alternatives."

It's interesting to see personal antidotes which have been shown to be incorrect to be permitted in papers.

Today if the paper was written the text could have been replaced with -

"..researchers found that the playing of such games actually had a very slight calming effect on youths with attention deficit symptoms and helped to reduce their aggressive and bullying behavior." [2]

(replace 'youths' with 'sysadmins')

[1] http://www.cs.unm.edu/~dlchao/flake/doom/chi/chi.html

[2] http://www.springer.com/about+springer/media/springer+select...

> It is difficult to tell if your employees are doing real work or just goofing off when tools and games have the same GUI.

this is listed under the "problems" section. maybe it should be in the "benefits" section :)

It's not 3D, but I wrote a little curses program to find and delete large files - https://github.com/dlubarov/cleanup

My favourite part of this is that actually deleting the file is a TODO item.

Processes should be differentiated by importance and resource consumption. For instance, PID 1 should be rendered as the Cyber Demon, since killing PID 1 would end your game. Any parent processes of the current process should be friendly, and processes consuming large resources should be special enemies like pinky.

PID 1 should be rendered as Player 1 (as a http://doom.wikia.com/wiki/Voodoo_doll ).

It would be fun to set off a forkbomb with a small sleep call in a system and watch it cause pandemonium. Shoot a couple of the rabbits so that they start infighting, and then watch the system slowly eat itself as legitimate processes enter the fray :)

Brilliant idea.

With the Unix file systems, that show about everything of a computer, it should be possible to create a game, where the whole world is generated by that informations :D

Nobody mentioned TRON yet?

TRON had too much anthropomorphisation for me.

This is a neat game that portrays that exact concept. It isn't really your system, but the idea is that the in game objects are supposed to visually represent data in a fictional system, and your job is to fix the corrupted bits to progress.

http://www.brokendimension.com/

For one that's actually your system, there's Lose/Lose. Each alien is a file on your system, and the file gets deleted when you kill it. When your ship dies, the game erases itself. But it doesn't reflect the system structure beyond using your files as enemies, so it's more on par with the Doom thing in that regard.

http://www.wired.co.uk/news/archive/2009-09/22/the-computer-...

IIRC there was a graphical file manager on some systems like this, famously featured in Jurassic Park ("This is a UNIX system! I know this!")

Also, not quite the same, but: https://en.wikipedia.org/wiki/Virus:_The_Game

http://jpos.jurassicpark.sk/

http://www.jurassicsystems.com/

Aha, I found it. The file manager in question was fsn: https://en.wikipedia.org/wiki/Fsn

So pretty much a 3D tree map.

I recall trying a demo of that game. Was very "odd".

It was pretty much the original Decent, but using the directory tree of my HDD as the basis for the map. If it ran into files i could understand, like say images, it would use those as textures etc.

Reminds me of a program I played with way back when, which was effectively a desktop replacement - instead of a flat desktop, it presented a 3d-rendered office building of sorts, with web bookmarks and applications rendered as pictures on the wall and things like that. I forgot what it's called though. Still, I wonder if something like that was re-imagined today what it would look like.

BumpTop? http://en.m.wikipedia.org/wiki/BumpTop It was acquired by Google and promptly buried. It was a fun toy, but I could never see myself using it seriously. Really didn't understand what goog's interest was.

fsn[1] seen in Jurassic Park brings that kind of metaphor to the file system. I don't think it's that practical, but it sure looked wonderful in the movie. I guess we better stick to 2D interfaces as long as we don't have 3D controls that equal mouse in their practicality. Maybe one day there'll be a nice Oculus Rift enabled desktop :)

[1]: https://en.wikipedia.org/wiki/Fsn

https://www.youtube.com/watch?v=Dgtba_GpG-U

Wayland is very flexible.

Sounds like Microsoft Bob and some VRML demos I used back in the day. Unsure of the practicality, but could be interesting if done right I suppose.

"In a cyberspace environment, the players are not omnipotent, so performing large actions takes time and effort."

Well... try to glue these operations on a OOT rom and wait for people to reverse bottle adventure your system.

http://www.zeldaspeedruns.com/oot/ba/reverse-bottle-adventur...

Linux systems should boot with "-norba -noww" as kernel arguments ;-)

One of the issues with this user interface was that you were going to kill the Doom process itself, eventually :-)

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

The solution to that problem is simple. Map the Doom process to doomguy. If you die, the process ends! :) You could even add a bit of code that sends a message to the head sysadmin so if a newbie keeps attacking a big nasty and dying as a result, the sysadmin would know to step over and tell the newbie to chill out.

This also raises an existential conundrum. If the sysadmin has god mode, what happens if they shoot init with a BFG? Kidding of course, but it is fun to imagine an invincible process stepping heroically through the ensuing wreckage of a kernel panic :D

I installed this at work once. Processes were spawned via a popen() calling ps with some flags. It was easy enough to modify it to grep out the more important processes.

I remember when this first came out. I was just about to start college. There was a sense at the time that anything related to Linux system administration was black magic, doubly so for anything involving game programming. So this was certainly only talked about in hushed whispers and euphemism.

I was actually a grad student at unm with Dennis Chao. Guy was bright, creative and knew how to tell a good joke. Interesting to see this still on the inter-tubes.

I think any real world environment in which this would be feasible would be served better by other tools. This is because in order to render a process that needs to be killed a system needs to know that it is a bad process. But if you know how to simply identify bad processes you would just write a script to kill it, which is widely done now.

What you are doing at best is converting textual information into visual one, I can't really see a way to do that without drastically increasing complexity of representation.

Maybe this concrete implementation of the idea is the problem here, processes aren't your enemies.

If the whole thing was more neutral, it would help.

Are you seriously considering this as a potential system administration tool, or am I just bad at detecting sarcasm?

well the article is obviously facetious, but what makes it interesting is the notion of more physical upfront analogies for controlling our computers. It get's explored all the time in Hollywood, and we all collectively roll our eyes, but maybe it's not the stupidest thing ever.

I've thought about this before in context to Mechanical Turk. The theory is that you could put a game UI on top with a Mechanical Turk project in the background. Its much more fun to play the game interface then to do a monotonous job.

If anyone is interested in this idea let me know. I'm not a game developer but would enjoy working on this MT idea.

Well there's the folding protein game which along those lines - http://fold.it/portal/

This is what I call gamification.

doomification ?

Hah, imagine a system where processes were placed in an arena and they battle it out for cpu time. Programmers will not only have to build their applications but also write an AI to protect itself, an IDE could be a fortress where processes could be relatively safe.

Darwinian computing?

Or maybe Core War? https://en.wikipedia.org/wiki/Core_War

Nice!

Proposal: I'd like to have an ssh multiplayer so I can kill the other players' systemd's. :)

Would likely either spawn as a cyberdemon or that massive spiderbrain...

I remember when this first hit slashdot back in 1999. It's still a damn funny analogy. 8)

I was going to say the same thing. Cue the jokes about bringing down a system with a BFG. :)

UNIX groups could be handled by KeyCards, with the nice weird additional feature of User1 being able to let User2 into an area usually outside their permissions.

But really... idqd ... now bring on pid 1!

i use to be part of a research group (back in 2005/2006) and one the guys in the lab had the exact same thing as his thesis/research. And he actually built a working program which leveraged off the quake engine (i think it was quake). If I recall, he was invited by Cisco to demo his research.

Lets see if I can find his research.

Update: found it! http://caia.swin.edu.au/urp/l3dge/

I remember that when I was working at Icon Medialab back in the days.

So I guess, whatever you do, don't use the BFG 9000.

Reply on news.ycombinator.com