From owner-freebsd-current Tue Feb 9 21:39:45 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA13895 for freebsd-current-outgoing; Tue, 9 Feb 1999 21:39:45 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from fallout.campusview.indiana.edu (fallout.campusview.indiana.edu [149.159.1.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA13887 for ; Tue, 9 Feb 1999 21:39:42 -0800 (PST) (envelope-from jfieber@fallout.campusview.indiana.edu) Received: from localhost (jfieber@localhost) by fallout.campusview.indiana.edu (8.9.1/8.9.1) with ESMTP id AAA56789; Wed, 10 Feb 1999 00:39:34 -0500 (EST) Date: Wed, 10 Feb 1999 00:39:34 -0500 (EST) From: John Fieber To: jack cc: Matthew Dillon , current@FreeBSD.ORG Subject: Re: Heads up! /etc/rc.conf.site is dead. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 10 Feb 1999, jack wrote: > If /etc/rc.conf only contains changes from the defaults when > man something_or_other tells the user to find and edit > something_or_other_flags in /etc/rc.conf the entry won't be > there to edit. Why must it contain only changes? Is there any reason it couldn't be a copy of the default rc.conf on a new installation? Over time and upgrades it may get a little out of sync with the default file, but by then the user/admin will most likely be familiar enough with configuring the system that it won't exactly be a stumper. And how about this: stick a big comment at the top of /etc/rc.conf suggesting that the user consult /etc/defaults/rc.conf for a complete list of tunable parameters. Even in the worst case, the system behavior is exactly as it was before any of these changes came about. -john To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message