From owner-freebsd-stable Fri Apr 19 19:56:33 2002 Delivered-To: freebsd-stable@freebsd.org Received: from bodb.mc.mpls.visi.com (bodb.mc.mpls.visi.com [208.42.156.104]) by hub.freebsd.org (Postfix) with ESMTP id 8FE7237B41C; Fri, 19 Apr 2002 19:56:26 -0700 (PDT) Received: from sheol.localdomain (hawkeyd-fw.dsl.visi.com [208.42.101.193]) by bodb.mc.mpls.visi.com (Postfix) with ESMTP id 7F47B4BCB; Fri, 19 Apr 2002 21:56:25 -0500 (CDT) Received: (from hawkeyd@localhost) by sheol.localdomain (8.11.6/8.11.6) id g3K2uOu10038; Fri, 19 Apr 2002 21:56:24 -0500 (CDT) (envelope-from hawkeyd) Date: Fri, 19 Apr 2002 21:56:24 -0500 (CDT) Message-Id: <200204200256.g3K2uOu10038@sheol.localdomain> Mime-Version: 1.0 X-Newsreader: knews 1.0b.1 Reply-To: hawkeyd@visi.com Organization: if (!FIFO) if (!LIFO) break; References: <20020419225855.E7E575D05_ptavv.es.net@ns.sol.net> <20020419181021.X18267-100000_zoot.corp.yahoo.com@ns.sol.net> In-Reply-To: <20020419181021.X18267-100000_zoot.corp.yahoo.com@ns.sol.net> From: hawkeyd@visi.com (D J Hawkey Jr) Subject: Re: /etc/defaults/rc.conf theory X-Original-Newsgroups: sol.lists.freebsd.stable To: DougB@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Being "just an user/admin", and not part of The Project, my opinions probably won't carry much weight, but weigh in I will anyway... In article <20020419181021.X18267-100000_zoot.corp.yahoo.com@ns.sol.net>, DougB@FreeBSD.ORG writes: > On Fri, 19 Apr 2002, Kevin Oberman wrote: > >> I really hate to see the suggestion that people copy files from >> /etc/defaults to /etc. This really breaks the paradigm of having only >> changes in defaults in /etc so that defaults can be changed with a >> normal system update. > > But that was never the paradigm. There are a few different ideas > about why the defaults file should exist (none of which I'm particularly > fond of, btw) but silently changing defaults out from under the users > isn't really all that good of an idea, no matter how well intentioned it > might be. I'm afraid I must side with Kevin. I'm not going to throw the word "paradigm" around, but, from /etc/defaults/rc.conf: # This is rc.conf - a file full of useful variables that you can set # to change the default startup behavior of your system. You should # not edit this file! Put any overrides into one of the ${rc_conf_files} # instead and you will be able to update these defaults later without # spamming your local configuration information. # # The ${rc_conf_files} files should only contain values which override # values set in this file. This eases the upgrade path when defaults # are changed and new features are added. IMHO, you muddy, if not nullify, the abstract altogether. You are advocating copying this file down to /etc, and editing it. There goes the concept of "overriding the values contained in this file". I don't know what you're definition of "paradigm" is, but yes, I believe this is indeed a "paradigm shift". Oops. I used that word, didn't I? > The one rational reason for having the defaults file is to create > a reasonable environment at startup for fresh installs. Given that > everything in inetd.conf is commented out, it's reasonable not to start > that daemon. The sendmail issue is a little more enigmatic, given that in > order for local processes to send outgoing mail it's now necessary to have > a sendmail daemon running... it could be argued that changing the defaults > in both branches is reasonable at this point. (Technically, there is > another good reason for the defaults file, namely that new options should > always be defaulted to off when they are introduced. However, that is both > abused, and not used consistently, so I'd much rather see > /usr/share/examples/rc/*, or something to that effect. But I digress.) This rather sounds more like "rationale" than "rational". It seems to me your using one fuzzy/broken/flawed thing to justify changing another. >> While the new mergemaster option helps with this, I would really rather >> not see rc.conf (and other files) become large and not trivial to scan >> over. > > The problem is, if an option exists, it has to be documented > somewhere. While fraught with danger, the existing situation isn't > HORRIBLE... but it does need help. Rather like highy-paid (and already rich) senators and representatives declaring that the Welfare State overhaul won't be horrible for those most destitute that are in it. Did any of them ask those most needy how horrible it would be? OK, ok, lotso rhetoric there. Sorry. But you know what? Your "horrible" ain't mine, and mine ain't Harry's. /etc/rc.conf in 4.5-RELEASE is almost 400 lines long. My own /etc/rc.conf is not even 40 lines long. When a normally live server is down to single-user mode, and in the home stretch of the "installworld process", and your boss is breathing down your neck, what do you want to look at, a diff of a 400-line file, or a diff of a 40-line file? >> Of course, people SHOULD pay attention to whet mergemaster has to say, >> but even I have messed up when updating an important server and not >> watching all of the things mergemaster showed in an effort to get the >> system back on-line quickly. > > I agree that we should provide safety nets whenever possible... > that's been one of my main areas of work in the project. But, at some > point, it's still on you when you push 'i' for install. This ain't > windows. :) Easy to say from your Airion (sp?), as you throw the MFC switch, with little real-time pressure on your shoulders. Eh? Oh. Sorry. More need- less rhetoric. I apologize again. All except one of the files in /etc/defaults make use of language similar to that which I quote above, and you're advocating changing one. Are you taking on the responsibility of changing them all, then, in the name of consistancy? Will you do so _before_ the next formal release? And will you somehow make all these changes known to all admins, well before they begin their "makeworld process" or new installation, _including_ those that don't follow this mailing list (for whatever reason of _their_ circumstance or choosing), in a concerted effort to minimize unforeseen confusion and/or damage? Now, to be fair to you, I am not subscribed to this list (which may further negate my unsolicited input), but do try to monitor it via an Usenet "mirror" on a daily basis, and I missed your reasoning for this change, and it may indeed have more substance than this "Head's Up". Having said that, I wonder how many others may have, too? By this one, on it's own, the change seems rather gratuitous (p'raps a bad choice of word; no offense meant in my using it). I don't know how long things have been as they are now (i.e., 4.5-REL), as I've really only been immersed if FreeBSD since 4.2-REL, but I'm already _very_ used to the current relationship between the files in /etc/defaults and those in /etc. It is direct, concise, and, best of all, brief. Brief, in this context, is good. I'm sorry if this reads strongly. I've tried to stay on the polite side during this message, but I feel strongly that you're making a mistake here that will be felt - badly - by many, many people, perhaps at the time when they need it least. I don't mean to be a Luddite, but neither do I see any real need for this change. Not at this time, anyway. I know that the rc and periodic structures are changing to something more SysV-ish for 5.0-REL (I have that right, don't I?). If you must go this direction, can't you wait until then, when a "paradigm shift" occurs for a [more] rational reason [than stated with this "Head's Up"], and we'll have to digest and adapt to a major change anyway? OK, I'm off my soapbox now. I feel better for voicing my two-cents' worth. Have I made a fool of myself yet? Dave -- Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message