Date : November 1981

Magazine : Computer & Video Games Magazine Issue #1

Advertisement : Towering Inferno



Another advertisement unknown source :



Do not mean to be morbid, but... does this not look like a familiar picture, that was broadcast worldwide on September 11, 2001 ?

Doom as an Interface for Process Management

Dennis Chao
Computer Science Department
University of New Mexico
Albuquerque, NM 87131 USA
+1 505 277 5957
[url]dlchao@cs.unm.edu[/url]
ABSTRACT

This paper explores a novel interface to a system administration task. Instead of creating an interface de novo for the task, the author modified a popular computer game, Doom, to perform useful work. The game was chosen for its appeal to the target audience of system administrators. The implementation described is not a mature application, but it illustrates important points about user interfaces and our relationship with computers. The application relies on a computer game vernacular rather than the simulations of physical reality found in typical navigable virtual environments. Using a computer game vocabulary may broaden an application's audience by providing an intuitive environment for children and non-technical users. In addition, the application highlights the adversarial relationships that exist in a computer and suggests a new resource allocation scheme.

Keywords

Cyberspace, Doom, first-person shooter, games, metaphors, operating systems, Post-Modernism, 3D user interfaces, vernacular, video games, visualization

INTRODUCTION

Those who use computers inevitably encounter some of the metaphors that allow for easier assimilation of abstract concepts. The desktop metaphor is so pervasive that most users hardly notice it [9], but the richness of the science-fiction version of cyberspace is largely confined to research laboratories and Hollywood. The application described in this paper is an initial step towards bringing a richer environment to personal computers.

There is a large gap between how we think about performing actions on our computers and how we actually perform them. For example, people who need to manage processes on a UNIX system think about the ``daemons'' spawning children that may need to be ``killed'' or ``blown away.'' This violent language suggests a metaphor for process management: a first-person shooter game. Each process can be represented as a monster, and interacting with the monsters would affect the corresponding processes. The implementation of this metaphor and the great interest it generated reveal interesting insights about our computers and our society.

IMPLEMENTATION

The Doom process manager (PSDoom) is a modification of the game Doom [8] that displays representations of the processes running on a machine. Rather than using standard text-mode UNIX tools to view and manipulate processes, one surveys and shoots at a room full of bloodthirsty mutants, as shown in Figure 1. When a user starts PSDoom, currently running processes are instantiated as ``process monsters'' in a single room in a ``dungeon.'' These monsters have their associated process' name and id printed on them. The program periodically polls the operating system to add newly-created processes to the game. The user may choose to view the processes from a balcony above the room, as shown in Figure 2, or to enter the room to interact with them. If the user inflicts a wound upon a process monster, the corresponding process' priority is lowered to give it fewer CPU cycles. When the monster accumulates enough damage and is killed, the associated process is also killed.



PSDoom inherits the rest of its behavior from the original Doom, and play is not noticeably affected. Monsters attempt to attack the player and each other. The hostility of the monsters and the user's limited ammunition are disincentives to attack them. Conflict among process monsters could help regulate heavily-utilized systems by making crowded rooms have higher mortality rates. Killing random processes on an extremely loaded system is not an uncommon operating system strategy. When the user is ``killed,'' he or she will be healed and placed at the entrance of the dungeon with a pistol and a modest amount of ammunition.

Doom was chosen for this project for two reasons. The first is that it is a classic game, familiar to most system administrators. The second is that its source code was recently released under the GNU General Public License (GPL) [13]. This license not only allows the author to modify the source code, but it guarantees that future derivatives of the author's work will be available to the public.

RESULTS

PSDoom received a surprisingly large reaction even though it was not publicized [24,26,4,16]. Less than a week after the initial version of the code was written, the project's website was attracting tens of thousands of visitors per day. Approximately 800 responses were e-mailed to the author or http://www.slashdot.org within the first two months. Of these responses 27% praised the project, 23% offered suggestions for improving PSDoom, 10% found the project funny, 10% reported technical problems, 8% related PSDoom to science fiction or to the future of interfaces, 1% disliked the project, and 0.6% were frightened by its implications.

Users found the interface intuitive. One can quickly assess machine load by seeing how crowded a room is. The command line methods to slow down and kill processes are different, while PSDoom unifies them - shooting a monster with a small weapon slows down or ``wounds'' the corresponding process, and repeated firings or the use of a large weapon kills the process, as shown in Figure 3. The violence inflicted upon the monsters reflects the violent terminology of UNIX commands.

Figure 3: Killing a process in PSDoom.

A significant problem with the current implementation of PSDoom is that monsters are much more likely to attack each other than expected. This causes many windows to mysteriously disappear as the program runs. For the same reason, the computer is prone to crashing because certain processes are vital to the computer's operation and should not be killed.

Many users want a larger variety of monsters in PSDoom. If larger or more important processes were represented as larger monsters, it would be easier to assess the machine load at a glance. If these monsters were also more powerful, they would be less likely to be killed by accident and be more able to defend themselves against the player. Several users made similar suggestions for altering the appearance of monsters based on certain attributes. Processes that take more memory could appear wider, while those that take more CPU time can appear taller. Sleeping processes could be represented by napping monsters.

To address some of these requests, I added code to make some of the more important processes ``Barons of Hell,'' the largest monsters in the game. Unfortunately, they had a tendency to quickly kill all of the other processes, and the user could not interact with processes for more than a few seconds before his or her avatar is killed. Making the monsters less aggressive would allow the user to navigate among processes more easily as well as make the computer more stable.

DISCUSSION

The enormous interest that PSDoom generated naturally raises the question of why people find it so compelling. Perhaps even more interesting than the application itself is the set of issues that it raises.

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

Hey guys, It's Autumn time, getting dark early, we need something to fiddle with,So we had this plan to pick up a old IBM AT/XT, remove it's innards and rivet in a ATX chassis etc for a new retro cool looking pc.

Managed to find a IBM 5170, little bit rough and dirty but complete.


So before we start butchering the poor thing I thought we would give it a clean up and see what we have here.
And what we have is 26 years of filth








Nice leaky battery



Mother of all power supplys



(Note to self, cleaning around rather large capacitors with an artists brush isnt very bright.....owwww!)

Much less painful



All apart and clean



Back together again



Other than being dirty and the legs discoloured (removed for retrobrite) & half a dozen paperclips inside the keyboard, it's spot on



After a really good scrub up it looks really good, Hard drives are out for the son to find the spec sheet for, as the battery is dead the system wont find the hardisks until the drive type, mem size etc are typed back in with a new battery fitted.....



Now it's alive....I cant bare to gut the poor thing

A new paper to be published in the upcoming issue of Marketing Science shows that removing DRM from music leads to a decrease in piracy. Or phrased differently, DRM appears to be an incentive for people to pirate music instead of buying it. The researchers from Rice and Duke University used analytical modelling to come to this seemingly common sense conclusion.

DRM only hurts legitimate customers.

The phrase above has been written a few dozen times here on TorrentFreak, and it’s now supported by an academic report.

Researchers from Rice and Duke University looked into the effect of digital restrictions on music piracy. In their paper “Music Downloads and the Flip Side of Digital Rights Management Protection” they conclude that DRM doesn’t prevent piracy at all. Quite the opposite.

“Only the legal users pay the price and suffer from the restrictions. Illegal users are not affected because the pirated product does not have DRM restrictions,” the researchers write in their report.

Ditching DRM and other restrictions would actually reduce piracy according to the analytical model developed by the researchers.

“In many cases, DRM restrictions prevent legal users from doing something as normal as making backup copies of their music. Because of these inconveniences, some consumers choose to pirate,” DinahVernik, assistant professor of marketing at Rice’s Jones Graduate School of Business says.

So without DRM, more people would be buying music. And aside from this direct effect, the researchers predict that DRM-free music will increase competition between retailers, which then results in lower prices.

“Removal of these restrictions makes the product more convenient to use and intensifies competition with the traditional format (CDs), which has no DRM restrictions,” says Vernik. “This increased competition results in decreased prices for both downloadable and CD music and makes it more likely that consumers will move from stealing music to buying legal downloads.”

Since the paper has yet to be published we can’t review all aspects of the analytical model. But unlike the researchers suggest, their findings are hardly surprising as the effect they describe has already unfolded in real life..

Even the most dedicated copyright protectionists concluded a long time ago that music DRM is a thing of the past. Most notably, IFPI said two years ago that stripping DRM would “significantly boost download sales.”

And indeed, those who look around will find that there’s hardly any music being sold with classic DRM in place. Even the RIAA admitted that DRM is an endangered species, probably because what the researchers report today is rather accurate.

The late Steve Jobs already knew this a long time ago. “DRMs haven’t worked, and may never work, to halt music piracy,” he said back in 2007.

Source: http://torrentfreak.com/eureka-ditching-drm-decreases-piracy-111008/

TV in a PC

Old Gateway PC transformed into a Linux server with embedded display, which is a hacked portable B&W TV driven directly by the VGA card.



I never liked having a server without some kind of console display built in. Up to now, when the machine went down, I had to lug out a VGA monitor, which was at least 14", often larger. Most PC cases have an abundance of unused bays (too many really), and are so deep that there is mostly empty space in the front (and the gateway PC I had was no exception). I was able to mount a 5in CRT and TV board inside while still leaving room for the floppy, cdrom and other things.



The old TV didn't have any composite input, so the video and sync lines had to be tapped out (Korean made, it had a manufacture date of 1989, the tuner was not working and the case was cracked, but the picture was still good). The video BIOS was customized for driving at the correct NTSC sync and scan rate.

Best thing about this project was almost everything came from the trash. The only things that were purchased were the zip ties, can of black krylon (for painting the tv bezel), and the game zapper for the optional second tv/display (see below).

After adding a second VGA card, it also makes a good media center PC. Getting the NTSC mode on the second card required the appropriate modeline for X as well as a VGA->Composite modulator (not scan converter), which is an old ADS Game Zapper I purchased in the early 90s. These are rare, and based on the older (and also hard to find) cxa1145 RGB encoder. However a similar, better circuit can be made with minimal parts using an AD724/AD725.

Source : http://www.ccs.neu.edu

Originally Posted by Eurogamer
A collectable gold-coloured Commodore 64 sold on eBay yesterday for an incredible GBP 2650 (around EUR 3340).

Apparently it's one of only a few hundred ever made. They were produced back in 1986 to celebrate the production of the one millionth C64 home computer to be manufactured at the German production plant. Back then, that was a big number.

The lucky seller's parents 'won' the super-rare item at CeBit in Hanover 1987, and promptly locked it in a cabinet and never used it.

But while the item was acknowledged by C64 aficionados to be rare, the amount it fetched has surprised many in the retro community - eclipsing recent auctions for the unreleased and supremely rare C65 machine.



In the U.S. in 1984, and later in Germany in 1986, Commodore celebrated the one millionth Commodore 64 sold in those countries by presenting the C64 with its traditional breadbox case "dipped" in a sparkling golden color.






Aside from the cosmetic beauty, the computer is otherwise a completely ordinary later model breadbox C64. The Commodore 64 sports 64K of memory, a leading edge video chip capable of producing images at 320 X 200 from a pallette of 16 colors, a text mode that displays 40 characters and 25 rows in upper/lowercase as well as Commodore's PETSCII graphics set, a fully programmable parallel IO port, and a high quality 3-voice, 8-octive additive synthesizer sound chip also capable of 8-bit PCM audio samples.





One of the only true curiosities in the design is the lack of the normal black protective plate on the side of the machine, as shown here. Reports are that none of the Golden C64s have the missing plate. The reason is a mystery.



Source: http://www.zimmers.net

The case of the 500-mile email


The following is the 500-mile email story in the form it originally appeared, in a post to sage-members on Sun, 24 Nov 2002.:

From trey@ Fri Nov 29 18:00:49 2002
Date: Sun, 24 Nov 2002 21:03:02 -0500 (EST)
From: Trey Harris
To:
Subject: The case of the 500-mile email (was RE: [SAGE] Favorite impossible
task?)

Here's a problem that *sounded* impossible... I almost regret posting the story to a wide audience, because it makes a great tale over drinks at a conference. The story is slightly altered in order to protect the
guilty, elide over irrelevant and boring details, and generally make the whole thing more entertaining.

I was working in a job running the campus email system some years ago when I got a call from the chairman of the statistics department.

"We're having a problem sending email out of the department."

"What's the problem?" I asked.

"We can't send mail more than 500 miles," the chairman explained.

I choked on my latte. "Come again?"

"We can't send mail farther than 500 miles from here," he repeated. "A little bit more, actually. Call it 520 miles. But no farther."

"Um... Email really doesn't work that way, generally," I said, trying to keep panic out of my voice. One doesn't display panic when speaking to a department chairman, even of a relatively impoverished department like statistics. "What makes you think you can't send mail more than 500 miles?"

"It's not what I *think*," the chairman replied testily. "You see, when we first noticed this happening, a few days ago--"

"You waited a few DAYS?" I interrupted, a tremor tinging my voice. "And you couldn't send email this whole time?"

"We could send email. Just not more than--"

"--500 miles, yes," I finished for him, "I got that. But why didn't you call earlier?"

"Well, we hadn't collected enough data to be sure of what was going on until just now." Right. This is the chairman of *statistics*. "Anyway, I asked one of the geostatisticians to look into it--"

"Geostatisticians..."

"--yes, and she's produced a map showing the radius within which we can send email to be slightly more than 500 miles. There are a number of destinations within that radius that we can't reach, either, or reach
sporadically, but we can never email farther than this radius."

"I see," I said, and put my head in my hands. "When did this start? A few days ago, you said, but did anything change in your systems at that time?"

"Well, the consultant came in and patched our server and rebooted it. But I called him, and he said he didn't touch the mail system."

"Okay, let me take a look, and I'll call you back," I said, scarcely believing that I was playing along. It wasn't April Fool's Day. I tried to remember if someone owed me a practical joke.

I logged into their department's server, and sent a few test mails. This was in the Research Triangle of North Carolina, and a test mail to my own account was delivered without a hitch. Ditto for one sent to Richmond,
and Atlanta, and Washington. Another to Princeton (400 miles) worked.

But then I tried to send an email to Memphis (600 miles). It failed. Boston, failed. Detroit, failed. I got out my address book and started trying to narrow this down. New York (420 miles) worked, but Providence
(580 miles) failed.

I was beginning to wonder if I had lost my sanity. I tried emailing a friend who lived in North Carolina, but whose ISP was in Seattle. Thankfully, it failed. If the problem had had to do with the geography of the human recipient and not his mail server, I think I would have broken down in tears.

Having established that--unbelievably--the problem as reported was true, and repeatable, I took a look at the sendmail.cf file. It looked fairly normal. In fact, it looked familiar.

I diffed it against the sendmail.cf in my home directory. It hadn't been altered--it was a sendmail.cf I had written. And I was fairly certain I hadn't enabled the "FAIL_MAIL_OVER_500_MILES" option. At a loss, I
telnetted into the SMTP port. The server happily responded with a SunOS sendmail banner.

Wait a minute... a SunOS sendmail banner? At the time, Sun was still shipping Sendmail 5 with its operating system, even though Sendmail 8 was fairly mature. Being a good system administrator, I had standardized on
Sendmail 8. And also being a good system administrator, I had written a sendmail.cf that used the nice long self-documenting option and variable names available in Sendmail 8 rather than the cryptic punctuation-mark
codes that had been used in Sendmail 5.

The pieces fell into place, all at once, and I again choked on the dregs of my now-cold latte. When the consultant had "patched the server," he had apparently upgraded the version of SunOS, and in so doing
*downgraded* Sendmail. The upgrade helpfully left the sendmail.cf alone, even though it was now the wrong version.

It so happens that Sendmail 5--at least, the version that Sun shipped, which had some tweaks--could deal with the Sendmail 8 sendmail.cf, as most of the rules had at that point remained unaltered. But the new long configuration options--those it saw as junk, and skipped. And the sendmail binary had no defaults compiled in for most of these, so, finding no suitable settings in the sendmail.cf file, they were set to zero.

One of the settings that was set to zero was the timeout to connect to the remote SMTP server. Some experimentation established that on this particular machine with its typical load, a zero timeout would abort a connect call in slightly over three milliseconds.

An odd feature of our campus network at the time was that it was 100% switched. An outgoing packet wouldn't incur a router delay until hitting the POP and reaching a router on the far side. So time to connect to a lightly-loaded remote host on a nearby network would actually largely be governed by the speed of light distance to the destination rather than by
incidental router delays.

Feeling slightly giddy, I typed into my shell:

$ units
1311 units, 63 prefixes

You have: 3 millilightseconds
You want: miles
* 558.84719
/ 0.0017893979

"500 miles, or a little bit more."

By: Trey Harris

MIT researchers uncover mountains of private data on discarded computers

January 15, 2003 *** NOTE DATE***

CAMBRIDGE, Mass.--Discarded computers, even those with "erased" disk drives, may harbor confidential information such as credit card numbers and medical records, two MIT graduate students found.

Scavenging through the data inadvertently left on 158 used disk drives, the students at MIT's Laboratory for Computer Science found more than 5,000 credit card numbers, detailed personal and corporate financial records, numerous medical records, gigabytes of personal email and pornography.

The disk drives were purchased for less than $1,000 from eBay and other sources of used computer hardware. Only 12 were properly sanitized.

"There are many stories in which somebody has bought a used computer and found confidential information on it, but nobody has ever quantified the scale of the problem," said Simson Garfinkel, one of the students. "So we decided to find out."

Results from the study, which Garfinkel performed with Abhi Shelat, are being published in the January/February 2003 issue of IEEE Security and Privacy. The research suggests that the secondary market is awash with confidential information, although work needs to be done to get more accurate statistics. More than 150 million disk drives were retired from primary service in 2002.

Of the disk drives acquired, 129 were functional. Of these, Garfinkel and Shelat found 28 disk drives in which little or no attempt had been made to erase any information. One of these drives, Shelat says, had apparently come from an automatic teller machine in Illinois and contained a year's worth of financial transactions.

Attempts to erase information from the drives were usually ineffectual. On many disks, files that would typically be found in the "My Documents" folder had been deleted, but they could be recovered using a simple "undelete" utility. Undelete programs work because deleting a file does not actually overwrite the blocks on the computer's disk that are used to hold the file's information.

Roughly 60 percent of the disks were formatted before they were sold, but even formatting did not properly sanitize a disk because the Windows "format" command doesn't actually overwrite every block--"the format command just reads every block to make sure that they still work," Garfinkel said. "To properly sanitize the hard drive, you need to overwrite every block."

On one of the "formatted" disks, Shelat found more than 5,000 credit card numbers.

Roughly 45 percent of the disks contained no files at all and the disks could not be mounted on the computer. Yet the data could still be retrieved by reading each block of the disk using special tools.

********************************

This article made me think of the relevancy of this article in respect to those wiping programs that seem so prevalent today assuring you that any personal data will be destroyed if you use their program. Well it seems that all these assurances by respective software makers is some what lacking in credibility.

From what I have been able to gather , it seems that recovery methods of wiped data is still ahead in the game.But never fear, for those paranoid and extremely cautious. I was able to dig up a program that will completely destroy your data so it will never fall into the hands of those criminal minded thugs or those government agencies that want to pry into your every orifice.

This program was created because of the above article in 2003, and ladies and gentlemen, I assure you it is as effective today as back then.

Because of monthly bandwidth restrictions, I am unable to bring screenshots, so I will point you in the direction of this wonderful and reliable program.

Without further ado, I present>>>>>>> DriveSlag>>>>>>>

http://eecue.com/c/driveslag

In December of 2008, a group of hackers was sitting on the floor with faces aglow with laptop light cruising the internet and skyping friends in and listening to death metal.

It was 12 days before 25c3. Astera and I had a conversation that went something like this:

B: There should be a book.
A: Yes, there should.
B: We have 12 days.
A: We can do it.

The twelve days we had was until CCC started. We figured we would have it done by then. We contacted all the hackers we knew around the world and put the word out. We expected to get about a half a page of writing from each space. We reckoned that it would be a 25 page pamphlet. We also reckoned that it be easy for folks to write up a little summary within a few days of what it was like to get their hackerspace started and get back to us.

Within a week we had been scorched by a flame war, gotten a lot of both written and photographic material submitted and it seemed likely that the book would happen. Then the submissions kept coming… and coming. The hackerspaces around the world told each other about the project and many groups sent some writing in describing the beginning of their hackerspace. Word had even gotten round to groups that didn’t have a space yet and they were sending us descriptions of their pre-beginnings too!

The 12 days came and went and still the submissions kept coming. After a few months submissions had trailed off and Astera came to NYC and began designing the book. She’s a pro and it shows. This book looks beautiful because she took the material and somehow made it fit together aesthetically, not a trivial task. Jens Ohlig jumped into the process last year to help push the editing process forward. Remember, in our minds it was going to be a project that would take less than two weeks and it turned into something epic. It’s been a long wait and I hope you’ll think that it’s worth it.

Download HackerSpaces: The Beginning!

This book documents where the hackerspace movement was in December of 2008. In that way it’s a bit of a time capsule. It’s not an exhaustive book, but we hope there are enough stories in here to show that all your excuses for not starting up a hackerspace are invalid. Each group faced down their own dragons to bring their hackerspace into existence including floods, rats, and drama. If they can do it, so can you.

We did this because we wanted it to exist and so it is a reward in itself. If you feel moved and want to support hackerspaces, we suggest contributing to the Wau Holland fund which helps make awesome things happen for hackerspaces. We would also like to thank everyone who submitted photographs and writing, this is your book.

After these years, the book is finally free in the world as a pdf. Download it, read it, and share it. We’re open to the idea of making it into a real physical book and if you’re interested in making that happen, let us know.

Build, Unite, Multiply!

Source:

Code: Select all

http://blog.hackerspaces.org/

About LNG

LNG is an operationg system primarly for the good old Commodore64 home-computer. There also is a native version for the successor Commodore128. Ports to other 6502/6510 driven 8Bit Computers are possible but not yet started. LUnix started in 1993 and reached the internet in 1994. In 1997 LUnix0.1 was rewritten from scratch, the result is LNG.

LNG on a C=64



LNG on a C=128 with REU



Information on LNG can be found here: http://lunix.c64.org/

and here: http://sourceforge.net/project/showfile ... p_id=10888

Anybody feel adventurous?