Date: Thu, 11 Dec 1997 09:49:44 +1100 (EST) From: Andrew Reilly <reilly@zeta.org.au> To: cfaehl@cs.unm.edu Cc: ksmm@cybercom.net, freebsd-hackers@FreeBSD.ORG Subject: Re: Why so many steps to build new kernel? Message-ID: <199712102249.JAA00920@gurney.reilly.home> In-Reply-To: <m0xfrlj-000386C@enterprise.cs.unm.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712102249.JAA00920>