From owner-freebsd-hackers Sat Jun 22 15:11:14 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA12939 for hackers-outgoing; Sat, 22 Jun 1996 15:11:14 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA12932 for ; Sat, 22 Jun 1996 15:11:12 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA22895; Sat, 22 Jun 1996 15:06:54 -0700 From: Terry Lambert Message-Id: <199606222206.PAA22895@phaeton.artisoft.com> Subject: Re: cvs commit: src/etc/mtree BSD.usr.dist To: alk@Think.COM (Tony Kimball) Date: Sat, 22 Jun 1996 15:06:53 -0700 (MST) Cc: hackers@freefall.freebsd.org, phk@FreeBSD.org In-Reply-To: <199606222151.QAA02311@compound.Think.COM> from "Tony Kimball" at Jun 22, 96 04:51:54 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Man pages are another component which I do not deem to be part of the > base OS. One can install FreeBSD just dandy without man pages. I gotta agree with this; I'd like to see the label-based CDROM approach to man pages -- just like Microsoft's "Books Online" for their devsys. If you have the ROM in, you get the man pages (as an optional install). > (There is one problem: makewhatis is run by cron whether the man > component is installed or not. That should be fixed, as it is > trivial.) All the makefiles should be fixed, especially the libkvm dependencies. > Games is another. Definitely. Do the CDROM thing there, too. 8-). > DES is another. This is questionable because of DES availability. Certainly, it is not installed by default unless you ask for it. > Perl does not belong in the BIN distribution. Perl is properly part > of an administrative tools and scripting add-on just as optional as > man pages. I'd go further; /bin/sh is evil, as are any other scripting systems where it's possible to have the data embedded in the script instead of operated on by a tool. The only reason I don't call for its removal is that the installation and the system startup (incorrectly) depend on it, and /bin/csh is more evil. As the default system shell, it has to be there, but that makes it no less annoying. Look at the /etc/rc* mess that /bin/sh has gotten us into because it was more convenient than Doing Things The Right Way. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.