Kevin P. Neal <kpneal@pobox.com> wrote to me instead of port-vax:
> >   You are giving reasons, but the facts remain facts regardless of the
> >reasons. My intention in starting this particular thread was to discuss
> >the facts about certain aspects of the BabyVAX architecture, rather than
> >DEC's reasoning for choosing the approach that has been chosen.
>
> But understanding the reasoning behind the approaches chosen helps us to
> understand the current state of the hardware.
   and
> >   Again, you are giving reasons, but the facts remain facts regardless
> >of the reasons. My intention in starting this particular thread was to
> >discuss the facts about certain aspects of the BabyVAX architecture,
> >rather than DEC's reasoning for choosing the approach that has been
> >chosen.
>
> Again, understanding why something was done helps in understanding how it
> was done. It's perfectly reasonable to discuss DEC's reasoning.
   
   Certainly, but Antonio and Allison were giving these reasons as if
refuting my statements about the facts. Reasons can NEVER refute facts.
   
> >   Oh, I'm not defending NetBSD at all. NetBSD is a hobbyist toy
> >absolutely unfit for serious use. All people who work on NetBSD/vax
> >consider VAXen a retrocomputing diversion. How many people here
> >professionally manage clusters of brand new VAXen operating in full
> >production and competing with Pentiums and SPARCs while giving shell
> >access to thousands of users?
[...]
> We do have VAXen running NetBSD and serving as web servers, etc. on the
> 'net. We do have NetBSD/vax machines running servers for all sorts of
> other uses. I'm referring to "we" as "the NetBSD community".
   
   OK, so you do have VAXen in production, but how about competing with
Pentiums and SPARCs and giving shell access to thousands of users? It's
still true that most people on port-vax consider VAXen a retrocomputing
diversion. I have seen lots of statements on port-vax like the following:
   - "Can I make my VAXstation boot from its SCSI disk instead of the net,
or am I nuts even thinking about this?"
   - "Is there anyone at all on this list who doesn't always netboot to get
the kernel running?"
   - "I wonder how long will it take to, say, compile Lynx on NetBSD/vax?
Two weeks?"
   Have you EVER seen anyone make such statements about a Pentium or a
SPARC? Until your community starts treating VAXen equally seriously with
Pentiums and SPARCs, and makes NetBSD fit for this, I will continue to say
that NetBSD is a hobbyist toy absolutely unfit for serious use. As for your
servers running NetBSD/vax, I bet that they have been set up very carefully
so that none of the programs that makes NetBSD/vax crash ever gets
executed, and no one except the administrator can log into them, since
anyone else logging into the box will make it crash immediately. Now
imagine about ten boxes on which thousands of users can run and compile
arbitrary programs. A couple hundred of these users are hackers trying to
crack root on the system just for the art's sake. Is NetBSD/vax fit for
such boxes? I _STRONGLY_ doubt that, even though I have heard that some of
the problems have been fixed in the 1.3 release.
   
> If NetBSD is so bad and you are so skilled then why are you not trying to
> make NetBSD/vax more stable? Why are you not helping out instead of
> *reinventing the wheel* by trying to piece together pieces of old BSD
> distributions and old pieces of AT&T code?
   
   I like Berkeley UNIX(R) better than NetBSD. Period. This is just my
personal opinion and I'm not trying to force it upon anyone else. Please
don't follow this thread further, since I have no time for this pointless
debate. Everyone likes what he or she likes. On the other hand, unlike
f*ckers who make commercial software, I publicize all my work, and anyone
is welcome to reuse my work in any way he/she pleases, including porting it
to NetBSD. This may be difficult because of the way you have f*cked up the
config mechanism, but this is your problem: no one was forcing you to
switch to your so-called "new" config.
   
> Do you actually think that you can do a better job than the entire NetBSD
> team?
   
   As far as VAXen go yes. Why? Because I have the right attitude. Because
I consider VAXen brand new fast machines no worse than Pentiums or SPARCs.
I would never use a kludge like PIO-only SCSI, since I value the
performance on a 3.8 VUP VAX just as much as on a 300 MHz SPARC. I also
seem to do a better job than some former DEC employees at separating the
truth from the lie that DEC wants you to believe. (Having the KA410/TK50Z
saga in mind here.)
   
> What's so wrong with commercial OSs? I find them quite useful. Besides,
> on a production machine you aren't going to be dinking with the kernel or
> whatever are you?
   and
> "Commercial product-oriented". What are you referring to here?
   
   There are two types of Unices: freedom-oriented and commercial product-
oriented. All "free" Unices like NetBSD are obviously freedom-oriented, but
so is Berkeley UNIX(R), even though it contains encumbered code. Freedom-
oriented Unices place the user in charge of everything. The relationship
between different pieces are clearly documented. Sometimes it is even
stated that the way these pieces are put together in the distribution is
only an example, and the user is encouraged to set things up to his liking.
Commercial product-oriented Unices present themselves as black boxes, and
officially don't bless any activities other than following step-by-step
instructions. As for making local changes to the code, why do you think
that this is not useful on production systems?
   
> >   For me the solution is Berkeley UNIX(R). In particular, 4.3BSD-Tahoe
> >and 4.3BSD-Reno. Both are very good, and there is no simple answer as to
> >which is better. Each has some very good qualities that the other
> >doesn't have. I hope to create an intermediate system, combining the
> >good qualities from each.
>
> And you can't help add some/all of these good qualities to NetBSD? Why
> not?
   
   What I like about 4.3BSD-Tahoe is that it's the last release adhering to
the tradition of True UNIX(R) that dates all the way back to V6 and V7.
It's the last release that has all True UNIX(R) code in place. "Adding"
this quality to NetBSD requires reversing all changes between 4.4BSD and
NetBSD, as well as many changes between 4.3BSD-Tahoe and 4.4BSD. Of course
it would no longer be NetBSD.
   4.3BSD-Reno starts in the direction of dehancement (IMHO), introducing
the evil spirit of POSIX and replacing divine V6/V7 utilities with mortal
"equivalents". This direction leads to Net/2, 4.4BSD, and eventually things
like FreeBSD and NetBSD. This direction is in sharp contrast with my
ideology and I will never follow it. However, there are two key features
that are not present in releases before 4.3BSD-Reno. They are Kerberos and
NFS. These features are essential for UNIX "clusters", and I definitely
need them, but I won't put up with POSIXisation dehancements because of
them. That's why I plan to play pick-and-choose between different versions.
   
> >The result probably won't match the real Berkeley UNIX(R) release line
> >for line, so it's still better to get the real one, but a half of the
> >pie is better than none.
>
> And NetBSD is a "whole pie". Where's the problem?
   
   NetBSD is 0% of the pie. The whole pie would be a byte-for-byte copy of
the UC Berkeley tape.
   
> >   I have seen a VAX for the first time in my life in June 1997, but I'm
> >making amazing progress. Also ten years ago (at the age of 8) I worked
> >on PDP-11s (actually poorly-compatible Soviet clones, but still).
>
> You are 18?
   
   Yes.
   
> >   Aha! Now YOU are looking at a pumpkin and seeing a pie. You are
> >seeing that two DEC OSes, which are well-known to do a great job at
> >obfuscation, seem to use the same code for the two systems and surmising
> >that they have similar architectures.
>
> No, he's saying that a kernel that runs on one machine can run on the
> other machine also. It's not an uncommon thing.
   
   But he is also using this fact to surmise that the two machines have
similar architectures. This like taking the GENERIC.vax kernel and saying
that because it runs on all VAXen they are all very similar.
   
> >Since I haven't laid my hands on our department's copy yet, and no one
> >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).
>
> Lots of assumptions even though you haven't seen a GENERIC kernel config
> file.
   and
> > However, I can bet that these same lines are used for KA410,
> >simply because these subsystems are identical on the two boards.
>
> There you go making assumptions again.
   and
> >generic MSCP driver (uq), and the MSCP disk driver (ra). This
> >configuration clearly doesn't support KA410, so I don't know how would
> >it fit in this scheme until I have the GENERIC config file.
>
> You should reserve your statements until you see a GENERIC config file.
   
   Since no one wants to send me a copy of that file, it may take a while
before I get to it. One guy has told me that there should be some Ultrix
tapes or CD-ROMs in his department's junkyard, but I have to wait before he
finds the time to search for them. Plus, if they are TK50 tapes, I'll have
to wait until my system is set up well enough to read them. Finally, since
I'm also a student, I have very little time for E-mail. This means that if
I were to wait until I get to that damn file, by the time I got it Antonio
and Allison would have forgotten about their postings, and my reply to them
would be totally out of context.
   As for my assumptions, in this case I'm about 90% sure about them, and I
have reasoned that the risk of posting incorrect assumptions is smaller
than the risk of waiting long enough for this thread to be completely
forgotten. In any case I have clearly indicates that these are only
assumptions, and when I do get to the GENERIC config file I'll certainly
post what I find there.
   
> 1) Nitpick: No machine is busless. Some lack expansion busses, but all
> have at least one bus.
   
   Strictly speaking this is correct, but the term "busless" is de facto
defined by the VAXist community to describe the architecture of BabyVAXen.
   
> 2) You are cribbing from a system based on 4.2BSD to make assumptions
> about a "modern" (well, that's what I call it) system? Bad idea.
   
   I don't quite see what you are referring to by "a \"modern\" system",
but I'm using an _Ultrix_ kernel config file to make assumptions about
_Ultrix_, so where is the problem?
   
> Those lines up there could be referring to where in the *processor's
> address space* those devices appeared. In this particular case I don't
> actually know.
   
   This is correct, and this is what I have meant by "raw VAX addresses".
   
> >   These lines are for QVSS, QDSS, and DEQNA/DELQA, respectively. This
> >should already tell you that you can make a kernel that will run on one
> >system but not on the other simply by removing one set of lines.
>
> Uh, yup. That doesn't make it impossible to have a kernel that boots and
> runs on either machine.
   
   But this does indicate that the two systems are supported by different
blocks of code.
   
> A system derived from 4.2BSD is closer to a system derived from (roughly)
> 4.4BSD-Lite than it is to "Berkeley UNIX(R)"? *sigh*
   
   Only in the way in which MSCP devices are configured. In general, Ultrix
is MUCH closer to Berkeley UNIX(R) (specifically all versions from 4.2BSD
to 4.4BSD) than to NetBSD. For instance, it uses the classical config(8),
rather than the "new" one. Berkeley UNIX(R) and Ultrix share a lot of code,
since the latter is obviously based on the former and a lot of DEC's new
code was contributed back to CSRG (you can see DEC's copyright (although a
copyleft one) on many files in 4.4BSD-Lite). As far as the configuration of
MSCP devices goes, here are the differences. Ultrix and NetBSD have low-
level drivers for variations like U/Q MSCP and BI MSCP (uda and kdb), one
driver for all MSCP controllers (bus-independent), and one driver for MSCP
disks. In this case MSCP disks are always called ra<n> regardless of
whether they are on U/Q or BI. In Berkeley UNIX(R), on the other hand, the
disk drivers attach directly to low-level drivers (uda and kdb) without
going through a bus-independent MSCP controller driver, so there are only
two layers instead of three. As a result, BI MSCP disks are called kra<n>
instead of ra<n>. This is certainly less portable, but since I don't plan
to do any work on the MSCP support anyway (and I certainly won't treat
disks and tapes on KA410 as MSCP), I can live with this.
   
> >But most probably there is a driver that sits under uq and talks to the
> >HDC9224. This would clearly be an example of obfuscation. Although I
> >don't know much about MSCP, I think that it's a packet-based protocol.
>
> You think? Shouldn't you find out first before talking at such great
> length about it?
   
   I have just checked, and TMSCP is indeed a packet-based protocol.
   
> Adding more layers to a system may make the system larger and seemingly
> more complex but the reality is that a properly layered system is *less*
> complex vertically (that is, moving between layers). In other words, more
> layers (done properly and not overdone) can make a system *easier to
> understand and maintain*.
   
   In general yes, but not in this case. Other disk controllers with
cylinder/head/sector software interfaces that have nothing to do with MSCP
(e.g., MASSBUS disks on 780, 750, and 8600) are already supported by all
three systems (Berkeley UNIX(R), Ultrix, and NetBSD) by separate ostensibly
non-MSCP drivers. Why should HDC9224 disks on KA410 be different? Only
because DEC wants people to think that they are MSCP? Only because
MicroVAX/VAXstation 2000 is targeted for the same marketing space as
MicroVAX/VAXstation II, and the latter uses MSCP disks? Having a generic
MSCP driver as an umbrella on top of uda and kdb drivers is a good idea
because the MSCP packet generation code can be shared between U/Q MSCP and
BI MSCP, but putting KA410's HDC9224 under this umbrella is plain stupid,
since HDC9224 HAS NO IDEA about MSCP packets.
   
> >   But here we see an example to the contrary. Making Ultrix support
> >SCSI disks on KA410 would be a matter of 5 minutes: simply remove the
> >artificial blocking! The same is probably true for VMS and VMB. But DEC
> >didn't do it,
>
> I doubt that you know more than the guy who pointed out that the concept
> didn't exist at that time. I'm pretty sure that it's not as easy as you
> think to add the full-blown SCSI support.
           ^^^
   
   You don't need to ADD it, it's ALREADY THERE. You simply need to stop
ARTIFICIALLY BLOCKING it!
   
> There are established standards for email and usenet messages. You need
> to be paying attention to them as they were established for the purpose
> of making it easier to communicate (which is the whole point).
>
> Don't indent paragraphs. Do put blank lines between paragraphs. Your
> indentation doesn't show up very well and your lack of blank lines causes
> your writing to become a wash of text -- very difficult to read. In fact,
> there have been posts of yours that I just didn't bother to read large
> sections of because it was too difficult to read a screenful of text with
> no real breaks in it.
   
   This is where I tend to disagree. My postings are essays. An essay is an
essay, regardless of whether it's transported by E-mail, fax, or a piece of
paper. (You like portability, don't you?) All writing classes teach the
style that I'm using, and all professional essays, articles, and books that
I have ever seen use it. Why should an essay's style be different just
because it happens to be sent over E-mail? And what if the same essay is
being sent to three different people by E-mail, fax, and paper mail? What
if I later want to publish it as an article in a scientific magazine, or
include it in a book that I'm writing?
   
   Sincerely,
   Michael Sokolov
   Phone: 440-449-0299
   ARPA Internet SMTP mail: sokolov@alpha.ces.cwru.edu