Apparently a flame war is taking place on this list regarding VAXen,
retrocomputing, and NetBSD, and I want to make it clear to everyone what my
position on this issue is. The way I view it is that there are two kinds of
retrocomputing: hobbyist retrocomputing and professional retrocomputing.
People who engage in hobbyist retrocomputing view this as a diversion. They
dare to insult their VAXen with the words "old junk" or "old crap". After
they are done playing with their VAXen, they go back to "surfing the Web"
with Netscrap, and/or post the results of their work on a WinNT-based WWW
server. In fact, the headers in many port-vax postings say "X-Mailer:
Windows Eudora"...
   People who engage in professional retrocomputing are much more radical.
I am an excellent example. I sincerely believe that in the past 10 or more
years the computer industry has marched in a completely wrong direction
(IMHO). I conscientiously object to using any computing technology younger
than 10 years, and bar the door of my home to it. For instance, I object to
"hard drives" and use only Winchesters. Of course, a time machine would be
the best solution, but unfortunately they exist so far only on the X-Files.
Therefore, I try to simulate one by PRETENDING that I live in the golden
age. Whenever I'm confronted by a problem, I look at how one would solve it
in the 1980s and follow that way. Of course, I use different terminology
from the one used in hobbyist retrocomputing. I try to stay away from the
word "old" as I find it insulting, and try to use words like "classical",
"mature", or "golden age".
   This concerns not only VAXen. It's true that many people (me included)
simply need a word processor or something else that just requires an IBM PC
or compatible. This can nonetheless fit within the framework of
professional retrocomputing. IBM PC and MS-DOS are almost 20 by now, and
one can easily find a word processor or some other DOS app that's mature
enough. I personally use MS Word (not WinWord) version 6.00. I run it under
MS-DOS, dunno if it works under MS OS/2. This is what I'm typing this text
in. The machine is an Intel 80386-based IBM PC AT-compatible, carefully
configured to be as close as possible to the real 80286-based IBM PC AT. It
has two ~600 MB (formatted) ESDI Winchesters, both of which used to be on a
VAX. Unfortunately, I can't reach my blue sky dream completely. Sometimes I
need to use something a little "newer" than preferable. Sometimes it's OK.
I often think that if something "new" is designed purely as a follow-up to
something classical, it may under certain circumstances be classical too.
This is the case when there are some improvements, but the ideology,
architecture, and topology have undergone the minimum possible change. Thus
I'm quite happy with replacing ST-506/412 with ESDI, since ESDI goes out of
its way to be as close to ST-506/412 as possible. "New" IDE and SCSI "hard
drives", on the other hand, introduce changes first in topology and then in
ideology. Therefore, these are not acceptable. Also unfortunately there are
cases when I have to put up with an ideological or architectural change.
There is a noticeable architectural change between 80386DX-based
motherboards and classical IBM PC AT 80286-based ones. However, I do need
some features that first appear in 80386, and therefore I have to put up
with a 80386-based motherboard. I have also considered 80386SX, but since
it's a compromise solution in the first place, it doesn't give one much in
the way of purity, and I seem to recall that its coprocessor interface is a
kludge. Note that these compromises don't push me out into the hobbyist
retrocomputing category. I always explore all possible options before
making a compromise, and it pains me when I have to use something too
"new", while hobbyist retrocomputing encourages a lighter attitude ("it's
just old junk").
   Things have grown even wilder when in the summer of 1997 I have become
the System Manager of Harhan Project at CWRU. Now I do professional
retrocomputing not only at home, but also at work. One of my goals is to
make classical technology compete with "modern" crap. And so I'm using
VAXen. Of course, the best VAXen (among the small ones) are Q-bus ones with
St-506/412, ESDI, or EMD disks. But as I have said before, this is work,
not play, so I have to take practical considerations into account, which
say that BabyBAXen are much more abundant than Q-bus MicroVAXen. Since
KA410s are too slow, the situation spells out KA42/41, which use SCSI
disks. Unfortunately they are much less fun than ST-506/412, ESDI, or EMD
ones, but they are needed for the practical task. One thing that helps me
out is that on "satellites" I don't need a lot of disk space, so RZ23s do
fine. These are actually more or less classical. They are SCSI-1 only, and
they have a constant angular recording density. They could have easily been
made ESDI by using a different logic board with the same HDA.
   Now for the OS. It looks a bit odd when people are saying that Berkeley
UNIX(R) is ancient and primitive compared to the "modern" NetBSD, meanwhile
using VAXen that are probably older than Berkeley UNIX(R). If you want a
"modern state-of-the-art OS", why are you using VAXen and not "modern"
PeeCees? Many people have said that they like VAXen for their VAXness. I
feel so too. But what they don't realize is that this VAXness is gone the
moment they install NetBSD. Running NetBSD on a VAX is no less odd than
making a PCMCIA adapter for it.
   Actually, even from a purely technical standpoint NetBSD/vax looks
rather pale compared to 4.3BSD-Tahoe or 4.3BSD-Reno. The abovementioned
Berkeley UNIX(R) versions have a much better support for classical
UNIBUS/MASSBUS VAXen than NetBSD/vax. (And VAX 8650 is the pinnacle of
VAXness, right?) First, Berkeley UNIX(R) supports the most classical of all
UNIBUS disk controllers: those for RKs and RLs. It also supports all kinds
of different UNIBUS Ethernet interfaces from all kinds of vendors, and not
only for 10 Mbps Ethernet, but also for 3Mbps Experimental Ethernet, etc.
Berkeley UNIX(R) also supports SMD disks (constant angular density ones,
not EMD) with physical cylinder/head/sector interfaces (not MSCP) connected
through special Emulex controllers. These controllers could be for UNIBUS,
in which case they had a special interface supported only by the sc/up
driver in Berkeley UNIX(R), or for MASSBUS, in which case they looked very
similar to RMs but still requires some OS support, again provided only by
Berkeley UNIX(R). Berkeley UNIX(R) also supports DEC and third-party 9-
track tape drives with physical non-MSCP interfaces connected to both DEC
and Emulex controllers on both UNIBUS and MASSBUS. None of this is
supported by NetBSD/vax. The emphasis of the latter is on MicroVAXen with
MSCP, while the former emphasizes the most classical VAXen with physical
disk and tape interfaces. This doesn't mean that the support for MSCP is
poor. It's certainly not worse than that in NetBSD, since the latter seems
to leave it unchanged from the Berkeley original. Such differences are
apparent not only in the support for peripherals, but also in the support
for CPUs and systems. 4.3BSD (all variations) shipped with a console 8"
floppy disk and a console TU58 tape. All VAX-11 models are supported,
including 730 and 725 with their IDC disks. The documentation clearly
explains how to install the system on any VAX-11 model using the console
media provided. I have yet to see a document describing how to install
NetBSD/vax on a 780 or an 8600. You may say that all this stuff is really
ancient, but isn't ancient stuff all that this group is about? Also
Berkeley UNIX(R)'s tradition of physical interfaces is very helpful for
supporting HDC9224 disks on BabyVAXen (see the next paragraph).
   Before I have joined this list, I considered NetBSD to have one major
merit: BabyVAX support. In theory it's outstanding. Berkeley UNIX(R)
currently doesn't have any, and (again in theory) NetBSD/vax surpasses
Ultrix in BabyVAX support, since it supports KA43 and treats NCR5380 SCSI
controllers the same way for all CPUs. However, upon joining this list I
was quickly disenchanted. It turned out that NetBSD's support for BabyVAXen
is simply unusable because of problems with DMA and bad block replacement,
as well as countless bugs and crashes. Please don't take this as an insult
toward the people who work on it. I have the highest respect for Ragge and
Bertram for implementing the BabyVAX support. It is simply unfortunate that
the fruits of their work go underutilized because they were based on the
wrong codeset.
   I have decided to base my work on implementing REAL BabyVAX support on
the Berkeley UNIX(R) codeset for the following reasons. Since the BabyVAX
support code in current NetBSD/vax is so poor. people who need REAL BabyVAX
support will probably have to rewrite it from scratch. In this light, the
present BabyVAX support in NetBSD doesn't give it any advantage over
Berkeley UNIX(R). On the other hand, NetBSD/vax is not very well fit for
supporting BabyVAXen. Remember that before Bertram's work NetBSD/vax didn't
support anything except MSCP, while Berkeley UNIX(R) has a couple of
decades of support for physical interfaces. For instance, adding absolutely
perfect support for HDC9224 disks to Berkeley UNIX(R) should be a piece of
cake with the superb sc/up driver as an example. Also Berkeley UNIX(R)
would be a better base than NetBSD for developing a VAX OS that runs on the
entire range of VAXen from 780 to perhaps VAX 4000 and MV3100 M30+.
   As for reliability considerations, NetBSD/vax again looks pale compared
to Berkeley UNIX(R) and Ultrix. Ultrix was a commercial product with strict
quality requirements, so it's certainly very stable and bug-free. As it
happens, Berkeley UNIX(R) is not that far behind. A lot of code has been
contributed to CSRG by DEC. All of this code was originally written for
Ultrix, so the reliability of Ultrix was essentially shared with Berkeley
UNIX(R). Even the code written by CSRG guys themselves without DEC's
assistance is still better than what one usually finds in NetBSD/vax.
   
   Brian D Chase <bdc@world.std.com> wrote:
> I don't know that anyone here is
> bent on using NetBSD for serious use like say -- running a company.
   
   NetBSD/vax is certainly unfit for this purpose, but VAXen themselves
are. As long as you use a real OS. Hey, this is essentially what I'm doing:
a 10000-user campus is just as demanding as a company, if not more.
   Many people have asked me questions similar to the following:
   
> Why are you on this mailing list again?
   
   The way I see it is that the purpose of such mailing lists is to allow
people to communicate better and to be able to choose for themselves which
codeset to use, rather than to stipulate a particular codeset. I'm pretty
sure that the guys who have marched off to work on OpenBSD were originally
discussing their plans on NetBSD mailing lists. I have also seen similar
scenarios on other mailing lists, for example, Lynx Developers' list. At
certain times in the history of Lynx there were perhaps five different
codesets being worked on, but all discussions have always been kept at
lynx-dev@sig.net, and everyone was happy with this. Hey, even here not
everyone is all NetBSD. There are quite a few VMSers, there are people
asking for copies of Ultrix, and even Ragge himself prefers adb to gdb!
   
   Sincerely,
   Michael Sokolov
   Phone: 440-449-0299
   ARPA Internet SMTP mail: sokolov@alpha.ces.cwru.edu
   
   P.S. Saying "ARPA Internet" is one of the ways in which I communicate my
inclination for professional retrocomputing to others. And I do miss it a
lot. Free IPs and domains, no Netscrap, no Web sites even... *sigh*