From owner-freebsd-arch Fri Jul 14 18: 7:51 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 8744A37BA91; Fri, 14 Jul 2000 18:07:43 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id SAA17267; Fri, 14 Jul 2000 18:07:40 -0700 Date: Fri, 14 Jul 2000 18:05:26 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Alfred Perlstein Cc: arch@FreeBSD.ORG, marcel@FreeBSD.ORG Subject: Re: I'm fixing the build/install kernel target In-Reply-To: <20000714175620.R25571@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Being better than Windows isn't really aiming that high now is it? That's not the point. The point here is about what sophistication we expect from users. The slightly more sophisticated then average windows user will dork with their registry and leave their system in an unusable state. This also include users who, on installing new versions of not so bright software that does this for them, have to do a forklift upgrade afterwards. Most Windoze users have come to expect this "every system knob ties directly to 3 pound of plastique!" way of doing business. *BSD, like Unix has always been, is still a shipped toolkit, but unlike 10 years ago we expect these systems to be usable after install for nearly all user environments. That is, a kernel reconfiguration should rarely be required. If it is required, the steps are fairly straightforward to do so, but the assumption still is that the users are smart enough to know which end of a sabre saw to grab- there are very, very, few violations of the Principle of Least Surprise here. I don't see much utility in spending a lot of cycles come up with child safety locks in this area. If you feel that kernel reconfiguration is a must for the novice user (the one who might get bit by not paying attention to overwriting a bootable kernel, i.e., not using the current 'make install', which will most certainly leave you with a bootable kernel/modules set if the new one is wrong), then instead of making this process super safe, I suggest that the install tools are a better place to do this. We should then take the approach that, say, Tru64 takes, and reconfig and rebuild a kernel specific for a user's configuration as part of the install process. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message