Re: Claim to faim

[George Robbins <grr@shandakor.tharsis.com>]

> To: deltoids@mcws.net
> Subject: Re: Claim to faim 
> Organization: Design Software Group, Parametric Technology Corporation
> Date: Thu, 30 Apr 1998 14:02:03 -0600
> From: Rich Thomson <rthomson@ptc.com>
> 
> Ron, I recall a story where you devised a sequence of commands that
> would crash the machine.  You then punched this onto a paper tape,
> fastened one end of the tape to the other -- creating a loop -- which
> you then fed through the teletype so that every time the machine
> rebooted, the tape would feed and crash it again? :)

Well, I remember being on the "other end" end of that one - I think
it was something like the "print sys($1,)" bug, where a null argument
would crash the interpreter.  I guess by that time we had crash dumps
and a program that would print the input buffers from the crash dump,
so that you could tell what was going on and which "school acount" was
to blame, but there were no individual accounts and some of the school
passwords did get passed around...

One of the "amusing" things about Delta was giving the students sysadmin
responsbilites - in earlier days we'd taken some glee in "accidentally"
crashing the UofD B5500, printing out the passwords on the and a look-alike
commercial system in Philly, grubbing thru the trash at Smith Hall for
system program lists and now people were trying to compromise "our" system.

Years, later you find yourself still on the defensive side adimistering
unix systems at this place or another. 8-)

In the earliest days, when RSTS crashed, it crashed.  One of the things
that the DEC guys did when the came down to check things out was add
a dump registers to the console bit of code - the guy, whose name escapes
me right now - did this in sort of a tutorial manner and it as a large
part in getting me/us started with the notion that we *could* do things
with the RSTS code, given source listings.  

Also the crash dump buffer dumper gave us the notion that you could
write a program that could peek at the input buffers and what what
people we typing on the fly.  Some DEC guy claimed that it couldn't
be done, the information was too transient, but we tried it anyway -
I think Clark did the coding but it was kind of a cooperative effort,
and it actually worked quite nicely. 8-)

Another thing they did was work with the FE to install "memory protect"
switches on each of the memory modules that held the system stuff.
Maybe that's the way one their systems in Maynard was equipped, but it
was another lesson that hardware could be adapted to aid in debugging
and that you used all the tools at hand to glean clues.  I've done a
*lot* of software debugging since, some of it kinda un-orthodox and
"magic" to lesser folks...

Someone (Rich?) commented on the details of all the memories - we don't
be decived - memory is very selective and while I remember a lot of high
points and details, there's tons more that is just haze and dropouts.
People are entirely forgotten, names vanish, events are modified or
get muddled together.  Talking about it does tend to retravel the old
associative trails and bring up stuff you'd "forgotten" though.

For certain, not everything about the Delta exerience was positive and
it's marked my life-after in both good and bad ways.  Teresa's model
was that school-age kids could be treated as adults and given "adult"
responsbilties, and in truth some could, but the effect was mixed
blessings - some early development and a chance to blossom, but I think
there was sort of a prodidy effect where other aspects of character
development were retarded for a few extra hard knocks later on.  Not
that one should complain, the stuff I learned while working at Delta
and peripherals activities has been the basis for staying employable
despit my (few 8-) faults over the past nearly 30 years.

						George