:
:On Thu, Mar 23, 2000 at 12:45:07PM -0700, Nate Williams wrote:
:> Never mind, I missed the paren.  However, I would have written the fix
:> as follow so I wouldn't have missed the fix. :)
:>  
:> To each his own. :)
:
:so, with this fix, do you think i can consider the box stable enough for
:production?
:
:ie. was the code obviously broken to cause the problem i was seeing, or is
:    it possible that there are other issues (heat, bad memory, etc) that could
:    be causing it?

    Yes, the code was obviously broken.  In fact, the code in question is 
    less then a month old -- it was committed in the rush prior to the 
    release.

    Officially our production quality releases are .1 and higher releases,
    not .0 releases.

    Unofficially I think that 4.0 is very close to production quality -- good
    enough for me to use, definitely!   It's way ahead of the curve
    compared to earlier .0 releases (e.g. 3.0), way ahead of NT and, judging
    from the linux-kernel lists I think we are way ahead of linux in regards
    to reliability and heavy-load handling with this release too (note
    that linux has other strengths, in particular they are about a year 
    ahead of us in regards to SMP performance).  Solaris on Sun hardware
    is the only thing that beats us reliability-wise at the moment, and 
    not by much.

    The problems cropping up seem to be due more to cockpit trouble during
    the pre-release rush then to longer-term issues.   Consequently, problems
    should be fairly easy to find and fix.

    There are still bugs, of course - I haven't tracked down why an NFS
    client can crash if a file is ripped out from under it on the server,
    for example.  But when you take the intersection between known bugs and
    your use of the system there is a good chance of not having any overlap
    at all.

    The number one issue for me has been and always will be reliability first,
    performance second.  I can always throw another machine into a rack, but
    an extra employee to deal with failures costs real money!  I think FreeBSD
    gets a bum-rap sometimes for being behind the SMP curve - it's a favorite
    point of the linux masses and Microsoft likes to bludgeon both Linux and
    FreeBSD with their superior SMP implementation in NT. 

    But when it comes right down to it the real cost savings to a company
    (or individual) these days has little to do with machine performance and
    a whole lot to do with the man hours wasted fixing problems.

    In any ongoing development new bugs will always be introduced.  The key
    is to manage development in such a way that newly introduced bugs
    become immediately obvious and easily fixed.  In my opinion, FreeBSD 
    is far ahead of all the other open source projects in regards to this 
    management goal.

                                        -Matt
                                        Matthew Dillon 
                                        <[EMAIL PROTECTED]>



:i'm really getting pushed to get the server running, and, well i'm nervous to
:put it in if it is going to continue to spontaneously reboot.
:
:and, since the server has a "Powered by FreeBSD" sticker on it, stability
:would be a good thing for these corporate types to see.  8^)
:
:i'm looking for opinion here, i won't hold you to it.
:(in fact, i'm really, really pleased that you guys jumped on this so quickly)
:
:-- 
:[ Jim Mercer                 [EMAIL PROTECTED]              +1 416 506-0654 ]
:[          Reptilian Research -- Longer Life through Colder Blood          ]
:[  Don't be fooled by cheap Finnish imitations; BSD is the One True Code.  ]
:



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Reply via email to