Bertram Barth <bertram@ifib.uni-karlsruhe.de> wrote:
> Just to get some facts straight (which reminds me on some related
> statement concerning NFS and IDE [Hi Andy!]) the drivers for NCR5380 and
> HDC9224 are rather broken (while I have to say that they are/were
> relatively stable on my 2 machines), but the LANCE driver is quite stable
> which makes NetBSD/vax on netbooted 2000/3100 machines with swap and fs
> via NFS as stable as on uVAX-II (these are the machines I could compare.
> YMMV).
>
> Also due to bugs and other ugly things in the HDC/NCR drivers the
> performance of 2000/3100 via NFS on a lightly loaded network is much
> better than the performance with support for local disks...
   
   Getting an OS to perform better in one configuration than in another is
not the point, the point is (for me at least) putting VAXen on a par with
Pentiums and SPARCs. Diskless machines are no good for this goal. Take
CWRUnet as an example. Everything is on 10 Mbps Ethernet. You can argue
that this is slow in and of itself. However, this doesn't preclude you from
running a good and fast system, you just have to use the network properly.
The enemy's Pentiums and SPARCs are on the exact same 10 Mbps Ethernet. A
system can run just fine if the "satellites" have local root, swap, /usr,
and /var, if only home directories and mailboxes are NFS-mounted, and if
the disk server is fast enough. But imagine just for one second what would
happen if 99% of the bandwidth is wasted on swapping and fetching things
like /bin/ls. Of course the disk server would also be bogged down to death.
To quote Jeff Gumpf from INS, "don't use the network as a disk bus".
   
   You may say that you are only a hobbyist and have no need to compete
with Pentiums or SPARCs. But then you have to accept that your OS is a
hobbyist toy absolutely unfit for serious use, and that a professional
System Manager needs a better OS.
   
> I myself don't care about a RD32 being "old" or "classical" or
> something else.
   
   Not everyone is limited to RD32s! I would never use anything smaller
than two RD53s on an MFM machine or an RZ23 on a SCSI machine. (Even one
RZ23 may be too small, I may have to put two in each box.)
   
> If my machine is running stable with NFS then I'll use NFS.
   
   "My machine" is a hobbyist attitude. What if your boss at your paid job
told you to build a fully competitive production system using only VAXen?
You would probably be fired if you used your NetBSD toys.
   
   In general all arguments I have heard in favor of NetBSD/vax emphasize
hobbyist uses. Wouldn't it be better to end this pointless flame war and
accept the following points:
   
   1. NetBSD/vax is for hobbyist uses only.
   
   2. Not everyone is a hobbyist, and some people manage VAX systems as
part of their jobs.
   
   3. Some of these systems need to be fully competitive, no worse than
Pentiums or SPARCs.
   
   4. People who manage such systems need a real OS. If they need UNIX and
not VMS, the best choice is Berkeley UNIX(R).
   
> IMHO you could do a great job in fixing/rewriting the drivers for HDC9224
> and NCR5380 (plus DMA etc.) in NetBSD/vax. With these pieces existing and
> working support for "BabyVAXen" would become real.
>
> AFAIK all the rest of NetBSD/vax is as stable on "BabyVAXen" as on other
> types of VAX. These two drivers are the source for all (or at least most
> of) the grief. If it's really "a piece of cake with the superb sc/up
> driver as an example" then please do it! [No harm intended.]
   
   Apparently you don't understand the situation. If I take the sc/up
driver from Berkeley UNIX(R) and change it to work with SMC HDC9224 instead
of Emulex SC-21/31, it would still be for Berkeley UNIX(R) and not for
NetBSD. It can be ported to NetBSD, but this job is for you, not for me,
since I will never use NetBSD myself no matter what.
   
   I will base my work on the 4.3BSD-Tahoe codeset, but I will make it
public (at least the patches if SCO doesn't allow me to put the whole
source tree up on an FTP site), and you will be welcome to try porting it
to NetBSD. I have to warn you, however, that this porting may be difficult.
After all, there is a reason why I'm basing my work on Berkeley UNIX(R). My
work will draw extensively on the existing solid foundation of VAX-11
support in the latter. This foundation is missing in NetBSD. Before your
work on KA410 and KA43 NetBSD/vax was a small subset of Berkeley UNIX(R).
Basically what I have seen when I looked at it was a collection of several
pieces from Berkeley UNIX(R), glued together by the severely misguided
(IMHO) "new" config. Those Berkeley UNIX(R) pieces that have been ported
are usually more buggy and limited than their original versions. I have
already described this in my original posting (archived at
http://sclwww.scl.cwru.edu/~mxs46/retro1.txt for your convenience), and I
don't have time to repeat that argument all over. You can also see for
yourself how much useful stuff is there in Berkeley UNIX(R) that's missing
in NetBSD by comparing the GENERIC kernel config files for the two. You can
get the Berkeley UNIX(R) one from 4.4BSD-Lite available on many FTP sites
(to name just one, anonymous-FTP to ftp.cdrom.com and cd to /pub/bsd-
sources).
   
   What I hope will happen is the following. I'll add perfect BabyVAX
support to Berkeley UNIX(R) and release my work. You'll look at my patches
with the intention of porting them to NetBSD. You'll quickly realize that
they rely extensively on the solid Berkeley UNIX(R) foundation, very little
of which is present in NetBSD. Hopefully you'll realize that this
foundation is really necessary for proper BabyVAX support. Once everyone
understands this, it will be a matter of finding an OS that has this
foundation in it. One can either use Berkeley UNIX(R) or Ultrix which
already have it, or one can add this foundation to NetBSD. As I'm
fortunately not limited to the so-called "free" software, I have chosen the
former approach because it will take less time and give me a system that
has undergone more testing to achieve production quality. You are certainly
welcome to take the latter approach, and I'm actually helping you by
releasing my work.
   
   Bertram Barth <bertram@ifib.uni-karlsruhe.de> wrote:
> Don't underestimate the problems with copyrights and encumbered "free"
> (whatever that means) versions. I can't see the advantage of modifying
> "Berkeley UNIX(R) and Ultrix" which I don't have access to over working
> on NetBSD/vax which is available and running on my machines...
   
   Allison J Parent <allisonp@world.std.com> wrote:
> That said there is a demand for a free
> unencumbered OS for vax systems as there out there and being junked.
   
   Allison J Parent <allisonp@world.std.com> wrote:
> Vaporware: software that is nonexistant, unavailable or far to expensive
>           to obtain.
>
> 4.3BSD is pretty close to that if you not a business that can afford the
> license or a university.
   
   Now we are getting to the crux of the matter. Basically, you are
reinventing the wheel because the one that has been around for about 10000
years happens to be patented, right? Isn't this ridiculous? I see that this
club that a great desire and potential to bring a good OS to a large number
of VAX users. However, it pains me to see all this effort go into making a
cadaver walk (i.e., making NetBSD/vax do something useful). If at least 20%
of the energy that goes into this exercise in futility were directed toward
lobbying SCO to remove the encumbered status from 4.3BSD, then there would
be some light on the horizon. This is NOT like asking Microsoft to release
Win95 sources. The encumbered code in 4.3BSD originates from V7 (1975
IIRC). We are talking about software that's 23 YEARS OLD! Plus, we are
talking not about V7 itself, but about Berkeley UNIX. The vast majority of
its code is Berkeley-original and free. V7 ran on PDP-11s. Given their
modest RAM and disks (at least at that time), I would be surprised if the
V7 code amounted to more than a megabyte or two. For comparison, 4.3BSD is
50 MB.
   
   As for Ultrix, I see a lot of people referring to it as a commercial
product. Keep in mind, however, that 99% of this "commercial product" was
designed at UC Berkeley on your money (ARPA's grant from the defense
budget).
   
   Sincerely,
   Michael Sokolov
   Phone: 440-449-0299
   ARPA Internet SMTP mail: sokolov@alpha.ces.cwru.edu