From owner-freebsd-current Wed Jan 12 5:30:21 2000 Delivered-To: freebsd-current@freebsd.org Received: from mercury.gfit.net (ns.gfit.net [209.41.124.90]) by hub.freebsd.org (Postfix) with ESMTP id 3870314CD0 for ; Wed, 12 Jan 2000 05:30:18 -0800 (PST) (envelope-from tom@embt.com) Received: from PARANOR (timembt.iinc.com [206.67.169.229]) by mercury.gfit.net (8.8.8/8.8.8) with SMTP id HAA12440; Wed, 12 Jan 2000 07:37:43 -0600 (CST) (envelope-from tom@embt.com) Message-Id: <3.0.3.32.20000112082944.01636938@mail.embt.com> X-Sender: tembt@mail.embt.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 12 Jan 2000 08:29:44 -0500 To: Christian Carstensen , Donn Miller From: Tom Embt Subject: Re: why is my current so .... stable? Cc: current@FreeBSD.ORG In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 14:27 01/12/2000 +0100, Christian Carstensen wrote: >On Wed, 12 Jan 2000, Donn Miller wrote: > >> My guess is that once -current gets closer to the release date, it becomes >> more and more stable. I guess the period of greatest instability occurs >> somewhere about 1/4 to 1/2 through the -current life cycle. We could do a >> chart plotting stability vs. time for the life cycle of a given >> -current. That could help people decide whether or not they want to run >> -current. > >This would be great, but I wonder from what source we could take reliable >data about -current's stability. >But what I've meant was: I've had these ugly system freezes not perfactly >reproducable, but very often. From what I've read on current list, the >problems still exist, but not on my system. At least this system runs >stable for 1 day now. I'm wondering, why. > How 'bout some sort of client program that is run via the rc.d and rc.shutdown scripts? When run on bootup it checks dmesg for "WARNING: / was not properly dismounted", and tells a master server whether or not the last reboot was intentional. When run at shutdown it tells the master server the machine's uptime. Of course it would also help to send a 'uname -v' in both situations. This system would have statistical flaws, but it is still an interesting idea. Tom Embt tom@embt.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message