On Thu, 16 Jan 2003 20:03:00 -0800, "Conrad T. Pino" writes:
>> "Statistically stable" and "works well on my systems" still produces
>> high quality code for the simple reason that code quality is rated on
>> exactly those two criteria: How often does a failure occur and how high
>> is the performance on observed systems.
>
>This observation isn't immediately obvious but once stated it becomes so.

FWIW, while I don't have any MP i386 systems, I can say that
NetBSD/i386 has been extremely stable for me over the years.
Eg. the machine that was until recently my main server (still 
running 1.4.2), has achieved uptimes of 180+ days (though 140 odd is
more common), and aside from two panics in 4 years that my teenage
kids managed to induce, the only reason for reboots have been hardware
changes and power outages that exceeded the UPS capacity.

Obviously machines that track -current are not going to achive
impressive uptimes - if only because the kernel is changed more
regularly.  While -current may on any particular day be "broken",
NetBSD has been (for me at least) very reliable.  I've also used
various commercial *nix for 15 years (mostly SunOS/Solaris) and I
think NetBSD compares very well.

Also don't be surprised at the lack of regression testing etc that
free s/w projects get - I work for a company that does do serious
regression testing and it is a very expensive exercise - worth it if
you can afford it of course.

>This is very useful to me.  The lack of stability in -current rules it
>out for my goals.  Do you have opinions on when SMP support might show
>up in a stable or release branch?

Since it is in -current now it will be in the next release.
Whether it is flagged as experimental or anything remains to be seen I
guess.

>An implied corollary is that attempting to use -current for production
>use will create a turbulent life for those that so dare.

It all depends on how closely you track -current and your goals.  
Many people run -current just to pick up new features, they update as
necessary until the bugs are sorted out and then stop - switching to
the next release when available.  I did this for some years on one
machine. 

>hacked eventually because I didn't update the code.  It's become clear
>that I need to become a source code user instead of relying only upon
>binary distributions if I plan to stay with an open source OS.

This is true of any OS - the need to keep up to date with patches for
security issues.  Whether that is via binary or source patches, the
need for keeping up to date is the same (though the effort involved
may not be).

>After reviewing Linux, FreeBSD, OpenBSD & NetBSD once more, I've concluded
>NetBSD's project goals best fit my needs and I want to see a stable SMP
>release.  Given that my focus is on the application side, what can I do to
>assist progress on the OS side?

If you can spare a machine - run -current on it, and when you hit
problems, file PR's that clearly detail the problem.  Even if you
don't want to track -current closely, its handy if you can
occasionally let us know that your machine has been up for 3 months
with serious load ;-)

Thanks
--sjg