From owner-freebsd-hackers Wed Dec 10 15:00:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA28897 for hackers-outgoing; Wed, 10 Dec 1997 15:00:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA28783 for ; Wed, 10 Dec 1997 14:59:52 -0800 (PST) (envelope-from andrew@zeta.org.au) Received: from gurney.reilly.home (d14.syd2.zeta.org.au [203.26.11.14]) by godzilla.zeta.org.au (8.8.7/8.6.9) with ESMTP id JAA10342; Thu, 11 Dec 1997 09:54:59 +1100 Received: (from andrew@localhost) by gurney.reilly.home (8.8.7/8.8.5) id JAA00920; Thu, 11 Dec 1997 09:49:45 +1100 (EST) From: Andrew Reilly Message-Id: <199712102249.JAA00920@gurney.reilly.home> Date: Thu, 11 Dec 1997 09:49:44 +1100 (EST) Subject: Re: Why so many steps to build new kernel? To: cfaehl@cs.unm.edu cc: ksmm@cybercom.net, freebsd-hackers@FreeBSD.ORG In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 10 Dec, Chris Faehl wrote: > Anyway, the biggest reason I can come up with AGAINST GUIs for kernel > configuration is the obscuration of the original, has-to-exist kernel > config file. That is, the config file still has to exist, so why not > just muck about with it directly? This thread has prompted me to think about UIs a bit, and I'd like to see if anyone else has come to a similar conclusion. Kernal configuration is an excellent example. The kernel config file is quite simple in concept, easy to edit, easy to run config and then make and install a kernel. Never the less it is extremely daunting to newcommers because this simplicity rides on the requirement for deep knowledge of what the options ARE, what they MEAN, and what the DEPENDANCIES between them are. At the moment, this information resides in the brains of gurus, and is otherwise scattered through the man pages, the LINT config file, and the source code itself. A user interface that just wraps this up in forms and dialogs is obviously pointless. But a user interface that /contains/ all of the (large amounts of) information described above would be a significant boon. It would probably also be a significant development and maintenance burdon, which is why those who know how complicated it would really need to be have not done it. Imaging scrolling through the options window, able to switch options on or off, or include them or not (as in sysinstall), and having immediate access to descriptions of the option in question, required or incompatible options. These dependancies could be enforced, to avoid building broken configurations. Keeping track of interrupt numbers, collision requirements, busses, etc is just more of the same, and hairier. > Regarding GUIs as an affront to computer science - there seems to be a > sizable portion of folks who think that possession of a GUI makes a > program great. I especially see this attitude wrt to NT - administration > of these boxes is touted to be 'easier' because of the boatload of > (poor) GUI chrome they've dumped on to it. Oh, please... all this does > is encourage the 'reinstall the OS when something breaks' mode of > operation, since the real guts of the damn thing are completely obscured. I agree that most of the GUIs I've seen on Windows are broken, but that's because they do (as you say) obscure the underlying mechanism. What I would like to see is an interface that /illuminates/ the mechanism. -- Andrew "The steady state of disks is full." -- Ken Thompson