On Mon, 18 Nov 2002, Gregory Bond wrote: > > You have chosen to maintain systems which stretch FreeBSD to its limits > > and uncover bugs lurking in the code. This is great. But you cannot do > > so on the one hand and refuse to face the administrative work on the > > other hand. > > And this is not a FreeBSD problem either - if you are doing stressful or > mission-critical things, then you have to put more effort into admin and > making sure you get the right OS environment, whether you are running > FreeBSD or Solaris or whatever. For example, if you had Solaris boxes > in the same job, you wouldn't just willy-nilly add Solaris patches > without trying them on a test box....
Actually ... when I patch up a Solaris box, I apply all the patches provided by Sun, as I expect it to be them that does the testing ... when I upgrade to FreeBSD-STABLE, I do so *expecting* that I may have some problems and will need to debug as a result ... but, I don't know kernel internals, but I do know how to provide at least the *base* debugging information to give a start ... If I can keep my server rock-solid on -STABLE, with the load that I'm putting onto it, there is a good chance that few others are going to be able to crash it ... if I *can* cause it to crash, and can provide information on that crash, I would *hope* that someone would want to act on that to keep it from happening to someone else ... I'm stress-testing FreeBSD in ways that, I would guess, few of the developers have the time to do ... I'm stess-testing it in ways that few end-users ever see ... not only am I hitting the server(s) with a very heavy load, but its a very heavy load that is pretty steady, and by several hundred different applications, and, in some cases, several different versions of those applications ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
