From owner-freebsd-current Wed Feb 22 13:27:25 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id NAA04454 for current-outgoing; Wed, 22 Feb 1995 13:27:25 -0800 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id NAA04444; Wed, 22 Feb 1995 13:27:06 -0800 Received: from localhost (localhost [127.0.0.1]) by grunt.grondar.za (8.6.9/8.6.9) with SMTP id XAA24936; Wed, 22 Feb 1995 23:26:08 +0200 Message-Id: <199502222126.XAA24936@grunt.grondar.za> X-Authentication-Warning: grunt.grondar.za: Host localhost didn't use HELO protocol To: "Rodney W. Grimes" cc: bugs@FreeBSD.org, current@FreeBSD.org Subject: Re: Lots of crud... Date: Wed, 22 Feb 1995 23:26:08 +0200 From: Mark Murray Sender: current-owner@FreeBSD.org Precedence: bulk > Please read again what I said ``MAKEDEV is machine dependent, MAKEDEV.local > is machine INdependent''. No, they should not be togeather. OOps.. > Fixit functionality, running a system from cdrom and floppy, etc... there > are things that can be done with these tools that can not be done with the > new ones. :-( Ok - makes sense. I can see that they will become Really Difficult (tm) to maintain as FBSD evolves. Already, look at the makefiles. They are TERRIBLE to try to understand, let alone modify. > And with the new or old install tools we create entries for the disk that > is installed to, no need to really create a huge /etc/disktab file. Perhaps > the parts of the scripts that create /etc/disktab entries could be pulled > out and made a seperate script and installed as /usr/sbin/mkdisktab for > those that want an easier way to create one. Cool... > The things that really need to stay in this file are the floppy disks, as > far as I can see we could nuke the rest of the file. AHA! Now you're talking. > Having been installing and upgrading unix systems for 15 years I have never > seen a clean way to handle /etc, atleast now all the files in /etc are > text files, and diff can be used to see what was customized (if you keep > the original files around). Yeah. Nasty manual method, though. I was using my 4 years, not all of it that involved in that many systems, and thinking (in dream mode) "but..." > I don't think your classing of ``should, may, and may not'' would work, > I can label every file in /etc as ``should''. Can you point to one that > a user under some circumstances would not modify. If you can I will make > the argument that the file no longer belongs in /etc. :-) There are some that many users can get away with _not_ modifying for quite a while. The way rc is headed, most of the mucking about is done in netstart. I'm not saying now that rc is somehow holy and not to be messed with, but what the average joe does (start named/routed, name his machine, configure internet interfaces etc) is _not_ done in rc, so I tend to class it as a "should not", not a "must not". Obviously if you know WTF you are doing, its yours for the having, at the expense of having more work at the next SUP. Others, like hosts and netstart are "musts". Not many users will have cause to modify services, but more (particularly the security aware) will want to touch inetd.conf and syslog.conf. These are "may"s. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200