Date: Wed, 14 Feb 2001 09:00:18 -0800 (PST) From: Brian Behlendorf <brian@collab.net> To: Doug Barton <DougB@gorean.org> Cc: Greg Troxel <gdt@fnord.ir.bbn.com>, <freebsd-stable@FreeBSD.ORG>, Kris Kennaway <kris@obsecurity.org> Subject: Re: Upgrading config files (Was: Re: sshd in 4.2-STABLE) Message-ID: <Pine.BSF.4.31.0102140850350.491-100000@localhost> In-Reply-To: <3A8A1CF3.264A5C70@gorean.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 13 Feb 2001, Doug Barton wrote: > So, the question now is, does upgrading by default without forcing the > user to see the changes unload the gun, or just point it at a different > foot? The way I see it, when I do a make world, there are *lots* of things being upgraded without my awareness. The fact that something is being changed in /sbin/init is not all that different than something being changed in /etc/rc or /dev/MAKEDEV. I don't track changes in the first case (unless I follow cvs commits) and I probably won't care in the latter. I'm hard pressed to think of a file that, if I didn't edit at some point, I would care about being updated. > My feeling is that all we're doing is replacing one set of > problems with another, and losing the opportunity to educate the users > in the process. I have long been an advocate of both making "The Right > Thing" easier to understand and to accomplish, but at some level you > just can't make unix system administration any easier. There are tradeoffs, certainly. I wouldn't argue for making the replace-unless-changed algorithm the default, at least not at this point until people had a chance to work with it and found any hidden gotchas that such an approach has. Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.31.0102140850350.491-100000>