Not a flame as such - just correcting some points:	

On Sat, 21 Feb 1998, Michael Sokolov wrote:

>						My reasoning was that in the
> world of non-profit software the easiest approach is almost always the one
> actually used.

	Not always true - in particular linux tends to try to choose the
	highest performance route, while NetBSD tries to use the
	architecturally 'cleanest'. In the world of non-profit software
	people are free to choose whichever approach they want.


> > Wow... how can you hate modern BSD and yet know so little about it (or
>                           ^^^^^^^^^^
> > maybe I've just answered my own question).
>    
>    I find certain problems with this term. First be sure to remember that
> BSD stands for Berkeley Software Distribution. An OS that doesn't come from
> UC Berkeley (like the one that most of this group is hung up on) is not

	This maillist _is_ 'port-vax', for (I quote)
	"Discussion of issues specific to NetBSD/vax", which explains
	most of 'this group's interest.

> [adding 4.4 vm system to 4.3 ]
>         The result would be NetBSD/vax with all its problems (lack of
> satisfactory support for anything except MicroVAX II and MicroVAX 3). Each

	Ahem, have you _read_ http://www.netbsd.org/Ports/vax/index.html ?

	The 11/750, 11/780, 11/785, and 8600 (the machines on which Ragge
	produced the initial NetBSD/vax port), are if anything the
	original 'true' vaxes, and are certianly not 'MicroVAX II and
	MicroVAX 3'.

	Please also note the NetBSD is in the process of gaining a new
	VM system, designed by Chuck Craynor on the sparc and i386
	platforms. This is one situation where having the wide platform
	support is a real gain.

>    Also consider the fact that 4.3BSD is very coherent and homogeneous.
> There is very little non-Berkeley code in it, and when its developers were
> testing it, they had a very good feeling for what they were testing. As a
> result, all pieces of 4.3BSD have been tested TOGETHER really well. 4.4BSD
> loses this quality. It incorporates a lot of outside code, and CSRG has
> been disbanded before this code was fully polished up and coordinated with
> the rest of the system. As a result, 4.4BSD is not as stable and well-
> tested as traditional Berkeley UNIX(R) releases. I have a feeling that
> 4.4BSD's follow-ups like FreeBSD and NetBSD haven't eliminated this
> problem. 

	Sorry to debunk that statement, but a lot of commercial
	organisations certainly think FreeBSD is stable enough to handle
	their livelyhood:

		http://www.freebsd.org/cgallery.html

>	Being developed by volunteers without ARPA's support, they simply
> don't have enough resources for proper polishing and testing. Just imagine
> how much did it cost CSRG to keep at least one machine of each supported
> VAX model all the time to test each release on all supported machines.

	There may be specific issues with certain items of hardware
	support, but you should be able to depend on machine independant
	code without having to extensively test it everytime you add a new
	port, or even processor type.

	Further on the 'stability' issues - how many stability problems
	does NetBSD/vax have on the _officially supported_ hardware?
	Note the the MV3100 is not yet offically supported - when ragge
	has had a chance to iron out the problems it will be added to the
	supported list. The fact there are items people would like use
	that are not yet on the supported list is another issue, and one
	that people are working on when they have the time.
		
>    This coherent nature of 4.3BSD is exactly the reason why I have decided
> to take 4.3BSD as it is and do only the absolutely necessary changes,
> rather than launch a large-scale pick-and-choose campaign spawning all
> versions from the original 4.3BSD to the latest NetBSD as I was planning
> originally. The "absolutely necessary changes" are:
>    
>    - Take NFS from HPBSD 1.x. NFS is absolutely essential for UNIX
> "clusters". HPBSD 1.x is 4.3BSD vintage, so this should not introduce any
> impurity problems.
>    
	This would exclude NFS3 which has some real gains.

	Hmm, if you go the SunOS route for NFS support that is going to
	introduce 'vfs' layers to support non ffs filesystems. I think
	there may be quite a bit of 'impurity' there, though it would make
	supporting cd9660 and other filesystems much easier.
	
>    - Take the userland networking and security programs from 4.3BSD-Reno or
> 4.4BSD. Kerberos is almost as essential for UNIX "clusters" as NFS, and it
> also greatly improves security. 4.3BSD's single publicly-readable password
> file is a large security hole. This change also should be relatively
> painless, since the networking and security code really stands out from the
> rest of the system and has nothing to do with POSIXisation or other thorny
> areas. It is also all-Berkeley in all versions, so there are no ideological
> problems.
>    
>    - Add BabyVAX support. I will write all the code myself, but I will take
> IDEAS (as opposed to code) from Ultrix and NetBSD. This is almost why I'm
> undertaking this project in the first place. This change shouldn't cause
> any problems either, since I won't displace any of the classical VAX-11
> support code. In fact, I will draw on it extensively.
>    
>    Another consideration in favor of 4.3BSD is its very compact size
> compared to 4.4BSD and NetBSD/vax. Believe me, this difference (by a factor
> of 3!) often does make the difference between possible and impossible
> (having a single RZ23 in mind here).
>    
	Having run a stripped down NetBSD installation on two 20MBs drives
	I can safely say that deciding which programs you do not want can
	also make the difference. Shared libraries would also help
	significantly with regards to space.

>    Fortunately, the flame war that I have inadvertently started seems to be
> cooling down, and having it heat up again is the least thing I want. I am
> writing this posting only to share my thoughts with you, NOT to waste
> bandwidth on pointless "I'm right, you are wrong" arguments. Please don't
> respond to this posting with yet another flame, there are plenty of them in
> the archives. If you want to be helpful to the BabyVAX user community, help
> me find copies of 4.3BSD-Tahoe and 4.3BSD-Reno tapes, and let the people
> look at my work on BabyVAX support and decide for themselves.

	Facts are right or wrong. Personal opinions are always right for
	the owner, unpredictable elsewhere.

	Some of us choose NetBSD, and prefer the more modern facilities,
	and how the multi-artchitecture design allows improvements in one
	port to benefit all others.

	You choose to go back to 4.3BSD and add only the features you 
	have decided are necessary to make is 'right' for current use.

	Both of the above are valid opinions - I respect yours and wish
	you well, and if your project is successful hope NetBSD and it can
	share code and ideas to aid the development of both.

	I might suggest that you could be a little more careful with
	respect to the comments you make on this list - innacurate
	statements about NetBSD will tend to induce a strong response
	and will taint people's perspective to the other, valid,
	comments you may have.
	
		David/absolute

	You probably wouldn't worry about what people think
	of you if you could know how seldom they do.
		-- Olin Miller.