Subject: Re: TK50Z
To: None <port-vax@NetBSD.ORG>
From: Michael Sokolov <sokolov@alpha.CES.CWRU.Edu>
List: port-vax
Date: 02/07/1998 22:44:51
   Dear Allison,
   
   You wrote:
> <   Certainly, but Antonio and Allison were giving these reasons as if
> <refuting my statements about the facts. Reasons can NEVER refute facts.
>
> I was in the meeting as a DEC employee you weren't.  Reasons were facts
> if you were there.
   
   True, but that meeting is now history. Since we are not on the X-Files,
we can't change it. Therefore, we have to accept the decisions of that
meeting as they are, and do our best at working around them.
   
> <   Have you EVER seen anyone make such statements about a Pentium or a
> <SPARC? Until your community starts treating VAXen equally seriously with
>
> Of course not... this is port-vax.  There is a hint in there.
   
   The name "port-vax" doesn't say anything about hobbyist vs. professional
retrocomputing. The kind of retrocomputing I see people on port-vax do is
hobbyist, while professional retrocomputing does require making classical
VAXen equal in power to "modern" Pentiums and SPARCs.
   
> At 18 I was booting PDP-8s and loading tapes on PDP-10.  By 38 was
> running a small cluster (maybe a dozen systems).  I've been working with
> vaxen longer than your alive.  Try not to be insulting, you may actaully
> learn something.
   
   I don't remember being insulting. (I sincerely apologize if I was.) As
for "working with vaxen longer than your [sic] alive", I'm approximately of
the same age as 780 (being born on 8-JUL-1979), so that's doubtful.
   
> <   But he is also using this fact to surmise that the two machines have
> <similar architectures. This like taking the GENERIC.vax kernel and sayin
> <that because it runs on all VAXen they are all very similar.
>
> Hummm, first I have to become a man.
   
   I apologize... The name Allison doesn't immediately sound feminine to
me, but it doesn't sound masculine either, so I was avoiding calling you
"he" or "she" until Kevin P. Neal called you "he" in his message. Then I
have thought that he knows you (or the American naming conventions) better,
and called you "he" too. It turns out that Kevin was wrong.
   
> Now as VMS user of some long time your comments don't apply there.  UNIX
> is a new thing for me as I don't count Venix, Linux and Ultrix as real
> unix though the seem to resemble it.  Though I do have working systems
> using all of these.  Anyhow unix conventions don't apply to VMS and I did
> say VMS behaves across vs2ks and MVIIs and remarkably ultrix does too
> without an intermediate build.  I've done enough RD54 swapping to enjoy
> that property.  It was very handy to image copy a base disk to another
> to make up a new system for a user.  I still do it here as it's faster
> than an install or build.
   
   But you have to agree that the way an OS treats the hardware does tell
you something about the hardware itself, even if you don't use that
particular OS. BTW, I wonder what do you have to say in response to my last
posting on the subject (the ~30 KB one from 31-JAN-1998). If you don't have
it, tell me and I'll send you another copy. Your response would help me
better understand what's going on and eventually contribute to UNIX BabyVAX
support.
   
> <> >Since I haven't laid my hands on our department's copy yet, and no on
> <> >has bothered to send me a copy of the GENERIC kernel config file, the
> <> >only config file that I have is the sample provided in "ULTRIX-32
> <> V3.1 UWS V2.1 Release Notes and Installation Guide" (AA-ME85B-TE).
>
> Lets say that's really old as I'm running 4.3(circa 1993)!
   
   I have recently gained access to TK50 tapes with Ultrix versions 3.0,
3.1, 4.0, and 4.2. I wonder if you or someone else could tell me what are
the main differences between them. Which versions support NFS? (I hope at
least one does.) What about terminal I/O and other kernel interfaces? There
was a change (a contamination with POSIX really) in some kernel interfaces
(most notably terminal I/O) between 4.3BSD-Tahoe and 4.3BSD-Reno. Since
Ultrix dates back to 4.2BSD, it probably used the classical interfaces at
least at some point, and I wonder if it has later switched to the POSIXized
ones and if yes, in what version. Also since the media I have happen to be
TK50 tapes, I need to know their format. How many tape files (sections of
tape separated by physical tape marks) are there? What is the block size
for each? What is in each file (a dd image, a tarball, etc.)? And does one
go about installing it? Just tell the chevron to boot from the tape, or is
it more involved than that? What bootflags should one use?
   
> In the industry where you have not been [...]
                  ^^^^^^^^^^^^^^^^^^^^^^^
   
   Where have you got this idea from? You are accusing me of being
insulting and others are accusing me of being prejudicial, but here you are
being insulting and prejudicial. I have participated in the design of a few
hardware devices, and I have read tons of paper about hardware.
   
> [...] busless is generally accepted
> to me no expansion bus or the processor bus is not available for
> expansion.  That would also be saying the system is bounded as in its a
> generally fixed configuration.   We all know the microvaxII, Cvax
> or 4004 chips have a data, address and control bus.  It means little
> when it is effectively inaccessable for modification or expansion.
>
> I may add that the vs2k by your convention has at least two busses, NI
                          ^^^^^^^^^^^^^^^^^^
> and SCSI, neither of which make the processor bus any more accessable.
   
   I have never proposed any convention, so I don't know what you are
referring to, but if I were to give a definition for "busless", I would use
something like what you are saying. BTW, what's 4004?
   
> It isn't artificially blocked, it's available to any code, all ya gotta
> do is do it.
   
   I'm not saying that the hardware is artificially blocked. What I'm
saying is that Ultrix's GENERIC kernel has the full-blown SCSI code in it,
in the distribution (otherwise it wouldn't be able to run on KA42/41), but
the marketing logic in that same kernel artificially blocks by looking at
the CPU type and refusing to include this code in the run-time
configuration if it's 78032 (UV2). The whatever VMS equivalent of the
GENERIC kernel does the same. For more details see my last posting on the
subject (the ~30 KB one from 31-JAN-1998).
   
   Sincerely,
   Michael Sokolov
   Phone: 440-449-0299
   ARPA Internet SMTP mail: sokolov@alpha.ces.cwru.edu