From
[email protected] Fri Aug 14 17:44:11 1998
Date: Tue, 28 Jul 1998 14:05:15 -0500
From: Daniel Seagraves <
[email protected]>
Newsgroups: alt.sysadmin.recovery
Subject: Re: See Figure 1
Here you are, hot off the Chaosnet. (I wish! ITS rocked!
JSYK, I'll be getting [most] of a KS-10 sometime in the next few weeks!)
For the historically declined, MIT-OZ was one of the MIT Tweenexes.
(Tweenex = TOPS-20. See xkleten.paulallen.com) It was so named when
someone stared at the newly delivered KL-10 and the PDP-11 console
frontend and stated:
"I am the great and powerful OZ! Nevermind the PDP-11 behind the console..."
-------------------- AI:HUMOR;BUGOZ REPLY -------------------
It has come to my attention that there is quite a large amount
of mail being sent to Bug-OZ, creating a situation where replying to
all of the queries received can be quite tedious. To remedy this problem,
I suggest a form letter which could be sent to all of the people who
complain about various topics; a letter which would cover them all. My
proposed form letter follows:
----------------------------------------------------------------------------
REPLY TO YOUR RECENT MESSAGE TO BUG-OZ
----------------------------------------------------------------------------
Please stop sending mail to Bug-OZ. This is our system. We
installed it, we worked hard on it, and we screwed it up. Besides, we
use it more than you do. You don't seem to understand that OZ exists
so that new systems hackers can get some practice -- if OZ actually
supported users in a useful way, there would be something wrong. Refer
to Figure 1 below.
Forget about your stupid problem, and take a look at some of the
features of the MIT-OZ system.
1) System programs. We have enough to go around. In other words,
there should be enough programs that each lab member can do the same
thing with a different program. You can also argue about which is the
best program to use for a given task. Also, we have enough
documentation for the programs that you can fill all 3 of those empty
8-foot tall book cases in your office. With lots of help, you might
actually use half of the manuals, too!
2) We put a lot of thought into our defaults. We like them. it
doesn't matter what you think anyway. In other words, keep your
cotton-picking hands off our defaults! If you change them, we'll hack
your account with DDT when the system isn't even up! If you lose your
directory, TOUGH!!! See Figure 1 below.
3) Language Processors. They work just fine. They take in source
and often produce object files as a reward for your efforts. You don't
like the code? Too bad! Buy a Gorin book for $40 and use the assembler
like we do. We spoke with the language development team. They seem to
agree with us. They said "See Figure 1 below".
4) Debuggers. We support 37 different DDTs on Twenex, and use the
one on ITS ourselves. You shouldn't make mistakes anyway. It's a waste
of time. We don't want to hear any more about DDT, we're not
interested, see Figure 1 below.
5) Error logging. Who needs it? Why give yourself an ulcer? You
don't want to let us take the machine down to fix it, and we couldn't
fix it if you did. Don't waste your time talking to us about problems
that you had to have the machine tell you were there; see Figure 1
below.
6) Command Language. Many of you don't know it, but it's actually
100% compatible. You just don't notice it because you're used to the
Incompatible Timesharing System. What, you WANT it to be
'incompatible'? See Figure 1 below.
7) Arpanet. They're in the middle of a protocol change now
anyway. See Figure 1 below.
+-------------------------------------+
! _ !
! { } !
! | | |
! | | |
! .-.! !.-. !
! .-! ! ! !.-. !
! ! ! ! ; !
! \ ; !
! \ ; !
! ! : !
! ! | !
! | | !
! !
! !
+-------------------------------------+
Figure 1.
