From owner-freebsd-questions Tue May 13 16:36:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA24574 for questions-outgoing; Tue, 13 May 1997 16:36:19 -0700 (PDT) Received: from mailhost.PII.COM (pii.com [192.77.209.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id QAA24565 for ; Tue, 13 May 1997 16:36:17 -0700 (PDT) Received: from PII.COM by PII.COM (4.1/SMI-4.4) id AA17286; Tue, 13 May 97 16:38:57 PDT Received: from PII-Message_Server by pii.com with Novell_GroupWise; Tue, 13 May 1997 16:39:32 -0700 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 13 May 1997 16:33:49 -0700 From: Robert Clark To: root@cola68.scsn.net, questions@FreeBSD.ORG, dmaddox@scsn.net Subject: Re: FreeBSD 2.1.7 and COMPAT_43 -Reply Sender: owner-questions@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Gas is optional in a car, but it won't run without it. [RC] >>> "Donald J. Maddox" 05/13/97 03:01pm >>> On Wed, May 14, 1997 at 09:07:13AM +1200, jonc@pinnacle.co.nz wrote: > On Tue, 13 May 1997, Nadav Eiron wrote: > > > jonc@pinnacle.co.nz wrote: > > > > > > Hmm, > > > > > > Just tried recompiling a kernel for 2.1.7, and removed the COMPAT_43 > > > option from the list. Upon rebooting, login behaves slightly strangely: > > > > Why did you remove COMPAT_43? It's one of the things that's not meant to > > be removed from the kernel config file (as the comment states). Most > > noteably it breaks xterm. > > The kernel config files do *NOT* say that its a required option (in either > GENERIC or LINT); they need updating if that's the case. > > And as to why, just fooling around with how small a kernel I can get > that still boots and works.. This raises a question that I have often wondered about: Why are *required* parts of the system listed in the config file as _options_? I mean, if it's _required_, then it's *not* an _option_; and if it's an option, it's not required, right? It seems to me that this just serves to confuse new users. Why not remove these "required options" and include required functionality unconditionally? -- Donald J. Maddox (dmaddox@scsn.net)