🚀 go-pugleaf

In article <89347.200350RLE100@PSUVM.BITNET> RLE100@PSUVM.BITNET writes:
>In early 1986, when I was but a wee lad just starting in computers, someone
>got an exec file circulating around PSUVM.  Finding it in my readerfile one
>day, and not knowing any better, I ran it.  From then on, after every couple
>commands, a message would come up demanding a cookie.  After consulting an
>operator, I learned that I had no choice but to respond by typing "cookie".
>If you didn't feed it, it eventually locked up your terminal and you would
>have to get an operator to bump you off the system.  The demands for cookies,
>would get more and more insistent, and after 14 or 15 times it would say:
>"Just one more, please...".  After giving it that last cookie, it would say:
>"Thanks, I'm full now.  Bye!" and be gone.  I agree that this was a fun little
>virus, or whatever you want to call it.  Too bad they aren't all like that...

It's lots older than that.  I heard about it circa 1977 at RPI.

The other interesting story I heard about computing at RPI was
'wabbits.' As I recall, it involved running a program that generated
two copies of itself.  Eventually, the load crashed the system.

When I was there, we had IBM mainframes running the Michigan Terminal
System.  With it, we could write cute little animated scripts for the
25th line on our IBM 3270 terminals, like little rockets across the
bottom of the screen (with --> strings) and intercourse (with --> and
) strings, as I recall, with OOO!  OOO! next to them).

In article <91...@asylum.SF.CA.US> sharon@asylum.UUCP (Sharon Fisher) writes:
>When I was there, we had IBM mainframes running the Michigan Terminal
>System.  With it, we could write cute little animated scripts for the
>25th line on our IBM 3270 terminals, like little rockets across the
>bottom of the screen (with --> strings) and intercourse (with --> and
>) strings, as I recall, with OOO!  OOO! next to them).
Actually, we still have MTS, and these cute little programs are still around...
It's amazing what you can find out playing on a terminal during work-study!

Brad Jones:Unique due to popluar demand.
Intelligent comments to:k...@pawl.rpi.edu, user...@mts.rpi.edu or @RPITSMTS.
Unintelligent comments/flames/etc. to:postmaster@your.system
Disclaimer:I may be here to learn but they can't tell me how to think.

In article <91...@asylum.SF.CA.US> sha...@asylum.SF.CA.US (Sharon Fisher) writes:

   The other interesting story I heard about computing at RPI was
   'wabbits.' As I recall, it involved running a program that generated
   two copies of itself.  Eventually, the load crashed the system.

At Michigan, on the MTS system, we'd submit these recursive batch jobs that just spawned
off copies of themselves.  Submit the job, sit back and watch the job screen fill up.
This would go on until your account ran out of money.  'Twas always an entertaining way
to burn up the excess class account money at the end of the semester.
--
Ed Anselmo   ansel...@cs.yale.edu   {harvard,decvax}!yale!anselmo-ed

> From: Ansel...@cs.yale.edu (Ed Anselmo)
> Newsgroups: alt.folklore.computers
> Subject: Re: My true cookie story

> 
> In article <91...@asylum.SF.CA.US> sha...@asylum.SF.CA.US (Sharon
Fisher) writes:
> 
>    The other interesting story I heard about computing at RPI was
>    'wabbits.' As I recall, it involved running a program that generated
>    two copies of itself.  Eventually, the load crashed the system.

Reminds me of a little ditty I once wrote during the my early days on
the "PDP"-10.  It was called PIG, and being a good mother pig, spawned piglets.
Using various techniques, piglets would eventually be running in all job
slots in the system except that owned by the mother pig (PIG).

At that point the following was typed out:

"All good piggies are taking a nap, the machine is yours"

and PIG exited.

				Bill

(From the land of no signature)

In article <70...@shlump.nac.dec.com> pa...@star.enet.dec.com () writes:
This will be funniest to the UNIX types out there.

In my novice days of shell scripts I played around to see what I could learn.
I wrote the following script

	/usr/games/fortune $1
	echo "------------------------"
	bin/fortune $1

I would then execute this with the line 

	fortune -o | more
or
	fortune -a | more

This would run the fortune cookie program repeatidly.  What I didn't realize 
is that the each script would invoke a new one and wait for it to finish.
Well, months later I had forgotten about this script and typed 

	fortune &

This ran my script instead of the actual program and I started getting the
fortunes on my screen.  I couldn't kill the job because its job number had
gone off the screen and I couldn't figure out the job number because when
I asked for the list of my running jobs the fortunes would scroll that.  So 
I typed 
	zapme

Zapme is a script which does the following:
	get list of user's processes
	kill each one (except itself)
	loop until no jobs are left
	quit

Well, it kill one of the fortunes and then killed my login.  When I logged 
back in I noticed the system was really ssslloooowwwww.  I checked and I had
about a fortune running and the zapme process..... and then my connection
died.  I logged in again and I had about a fortunes running and my login
died.  Thats when it dawned on me.

I had typed '&' as the argument to fortune.  This made it run in the 
the background.  When my original connection had died all output was redirected
to /dev/null (?????) and so each fortune was running faster.  When it was done
it would execture a new fortune.  Meanwhile zapme was getting a list of my jobs
and killing them but before it had a chance to get the list a new fortune with
a new job number would be started.  Zapme would kill the fortune it had seen,
check again, find another and kill it, but by then another one had been
started.  Because the output of the script was going to /dev/null things were
running really fast.  The load had shot up unbeleavably.  At this point the
zapme was killing my login before I ever got the prompt.  All this took place
in about 6 minutes.  I called up the operator on console and told him to delete
 ~dav/bin/fortune to fix the machine.  It took me over a minute to convince him
to do it and about two minutes to delete the file because of the load.  Once
the file was gone the current running ~dav/bin/fortune failed to run another
invocation and things slowly got back to normal.

The regular users noticed a five minute halt of the machine but the users
playing games couldn't play for over half an hour.  Here at dartmouth all 
games (except fortune) can only be run by ~games.  In the games directory 
there is a script play which checks the system load (average 2 minute) and
if it is too high does not let you run the game.  It also nices the games.
When my little script ran the system load (average) went from 0.37 to 10.8
in the first minute! and over 50 before it died.  The average load did not
get below the games level for over half an hour.

dav ;)
of the load.