[I'm quoting two different messages together here.]

> In particular, NetBSD has ... a couple of serious, annoying problems
> which may cause problems for you depending on your environment.  In
> that class, I include:

> 	(1) [the VM shadow object pseudo-leak]

> 	(2) [allocate and touch RAM+swap memory -> hang]

I would add to those at least

	(5) VM and filesystem buffer caches are still not integrated,
	    last I saw, which means that using read()/write() and
	    mmap() on the same file is quite badly broken.

(5 because a (3) and (4) are mentioned in stuff I partially quote
below.)

This is the main reason I haven't pushed harder to get NetBSD on our
netnews server; INN likes to mmap() some of its files, and while I have
been told this can be disabled, one presumably takes a performance hit
for doing so, which is a problem for a netnews server.

I've heard from someone who intends to do a lot to the VM stuff once
1.2 is out the door; I'm hoping that will include fixing this.

> 	(3) When your system decides to page for whatever reason, it
> 	    seems to want to page out Lots O' Pages at once;

> I haven't seen this, and I do some interesting data reduction
> ugliness that eats acres of memory for breakfast, lunch and dinner,
> cranking out network statistics.

But Sean, which port(s) do you run?  My memory of this problem being
discussed on the list, fuzzy though it is, says that it's a problem on
only the i386 port.

> WRT running NetBSD in a "real environment", there are some
> deficiencies, but my opinion is that these seem to be less of a
> problem than the idiosyncracies of the OSes shipped by SUN.

Depending on your workload, of course.  And if you have a decent kernel
hacker in-house (which I realize most sites won't), just having the
source available may be benefit enough to cause a switch.

> Finally, all the fixes I've seen put together have been pretty solid,
> which is a pleasant change compared to what I remember from
> commercial vendors...

Yeah; this is one of NetBSD's major strengths, IMO.  When a fix goes
in, you can usually count on it.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu
		    01 EE 31 F6 BB 0C 34 36  00 F3 7C 5A C1 A0 67 1D