From owner-freebsd-hackers Thu Apr 10 12:51:47 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA26192 for hackers-outgoing; Thu, 10 Apr 1997 12:51:47 -0700 (PDT) Received: from becker2.u.washington.edu (spaz@becker2.u.washington.edu [140.142.12.68]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA26187 for ; Thu, 10 Apr 1997 12:51:45 -0700 (PDT) Received: from localhost (spaz@localhost) by becker2.u.washington.edu (8.8.4+UW96.12/8.8.4+UW97.03) with SMTP id MAA01485; Thu, 10 Apr 1997 12:50:09 -0700 (PDT) Date: Thu, 10 Apr 1997 12:50:08 -0700 (PDT) From: John Utz To: "Jordan K. Hubbard" cc: proff@suburbia.net, Nate Williams , msmith@atrad.adelaide.edu.au, terry@lambert.org, sef@kithrup.com, hackers@freebsd.org Subject: Re: on the subject of changes to -RELEASEs... In-Reply-To: <20842.860656023@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 10 Apr 1997, Jordan K. Hubbard wrote: > > The design principals behind /etc are heading in the right direction > > but seem to lack vision. Jordon, call me an engineering psychopath, > > It's "Jordan" and ok, you're an engineering psychopath. ;-) yippee for engineering psychopaths! > > but it is my belief that FreeBSD should attempt to adopt a file-system > > organisation whereby after the system is installed, write access > > can be removed completely from the root and /usr because any > > configuration changes do not require modification of any of these > > partitions. Upgrades, re-installation and protection against trojans > > then become trivial. > > The problem is that the minute you start removing things from /etc and > putting them in their more "logical" places, the learning curve for > existing UNIX admins goes up and this too is "cost." > > However, if you were to say that everything in /etc should depend on a > single writable configuration file, I wouldn't argue with the > principle (and it's what I had in mind for /etc/sysconfig) but simply > point to the fact that "everyone" knows about files like > /etc/resolv.conf too, and if you put "domain=blah.com" and > "resolver1=foo .. resolvern=bar" lines into /etc/sysconfig and > made resolv.conf redundant (or removed it) there would be a lot of > confusion. yah, but one could leave these files in /etc and then write into the comments part of the file that this file is ( or more reasonably, going to be ) deprecated. One could then leave the files in /etc/ in perpetuity as simple readmes that point to /etc/sysconfig i think the idea has merit, but gets into the "we are BSD, dammit" argument. i dont have an opinion one way or the other, other than to point out that some day there will be more linux and *BSD administrators than "cost money unix" administrators, so this argument about existing implementation similarity will become moot. > Jordan > ******************************************************************************* John Utz spaz@u.washington.edu idiocy is the impulse function in the convolution of life