All of these are good points, but point to more of a meta issue with NetBSD,
FreeBSD, OpenBSD and Linux in general.

The fact of the matter is that they're not provisioned or funded for full
engineering. Testing is not done in any real sense. The only thing that saves
them is dedicated user and developer communities that respond to problems
pretty quickly.

Now, as to the problems you report- I'd say that I'd expect to see PRs, but I
haven't been very responsive to PRs. To be frank, I've spent most of the last
two years concentrating on FreeBSD, a chapter in my life that is now coming to
a close- hence a bit more activity in NetBSD more recently.

But, lacking PRs, you know who  I am, and I really didn't hear about these
issues from you. I don't *entirely* doubt your assessment, but w/o collateral
in terms of PRs, or communication from the people who've dropped BSD of *some*
kind, I tend to think that your comments are more 'potential' as opposed to
'actual' issues.

My own personal opinion, which I certainly pass on to to *my* customers WRT to
*BSD and Linux is that if they plan on using same, they have to fund
development and fixing and a completion engineering effort. Since they have to
do the same with Windoze and HP-UX and Solaris, etc., they're usually not all
that averse to doing so for *BSD if they also realize that they get a lot
better response time and control over the final result than they do with
commercial offerings.

My experiences with people rejecting *BSD is that they're looking for quick
and cheap solutions that they don't have to think about for whatever their
problem/product is. My experience with these same people is that they do the
same for the commercial products as well. The answer here is "Cheap is
cheap"- and these people would not be necessarily good reference sales for
*any* OS since all they're interested in is making a quick buck. If we can
suit such people with what we're trying to do our best with- great. If not,
then I doubt that anything will please a lot of them anyway.

This may be a bunch of blather- I'm tired.

-matt


On Sun, 24 Mar 2002, Charles Shannon Hendrix wrote:

> On Sun, Mar 24, 2002 at 11:42:19AM -0800, Matthew Jacob wrote:
> 
> > I mean, yes there are a few PRs open, but I'd be interested in a list of what
> > the companies that have dumped NetBSD found lacking other than lack of tape
> > position info.
> > 
> > Maybe these companies were naive. Tape position info is 'nice' but no serious
> > backup utility depends or should depend on it.
> 
> Yes, they were naive, but that hardly matters when you are trying to use
> NetBSD and they see a problem, or something they perceive as a problem.
> 
> The problem was when mt status returned nothing, they assumed something
> was wrong, like maybe the driver was broken.  
> 
> The last time I had one, NetBSD-sparc failed to read, but could write
> to a DEC branded DLT drive.  I cannot remember the model.  Then someone
> played with mt and noticed status was broken.  The machine was going to
> be used as a backup server, and Linux was put in its place because it
> worked from the start.
> 
> Naive?  Yeah... but then it isn't completely unreasonable to worry when
> something very common looks broken.  I worried a lot when I first noticed
> mt didn't do status information, and I got a spare DAT running and did
> a lot of backup/restore cycles, complete with md5 checks.
> 
> Heck, I *still* worry even though it passed the tests, but because I'm
> using DAT drives, not NetBSD.
> 
> Want to make some bets on how many people actually test a restore to
> see if it will work?   :)
> 
> Anyway, maybe it is a bit silly, but the change to mt will have a positive
> effect, because there is one serious backup utility that does depend on
> tape position: a system administrator.
> 
> -- 
> UNIX/Perl/C/Pizza__________________________________shannon@widomaker.com
>