Date: Wed, 09 Jul 1997 21:58:15 -0500 From: Wm Brian McCane <root@bmccane.uit.net> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: config@FreeBSD.ORG Subject: Re: kc 1.1 Message-ID: <199707100258.VAA22029@bmccane.uit.net> In-Reply-To: Your message of "Sun, 29 Jun 1997 19:14:44 %2B0930." <199706290944.TAA18982@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> Wm Brian McCane stands accused of saying: > > > I am pleased to announce that a newer version of my kernel > > configuration tool 'kc' is available for testing. To get a copy of > > it: > > Hmm, not bad. If I may raise a few gripes though : > > - Just running it, there's no indication of what to do. You could get > around this with a "status bar" with a few quick details on it. I had already planned TODO this, but have been fairly busy paying the bills lately. I will add a status bar in the next version. > - There's no separation between the various base-level config > directives. It'd be good to have the options separate from the > controllers, separated from the pseudo-devices, etc. This and the fourth comment are doable, but you lose the ability to easily define dependancies in the configuration file. I had thought of `sorting' the different items within a dependancy block, but that is just a matter of setting up the configuration file correctly to handle it. > - You could use more vertical space to avoid cutting off the names of > long options. (eg. keep option descriptions indented on the next line) Actually, with the new help option we can get away with a small description, or none at all. To be honest, the comment is not going to do anybody any good. If a person knows enough to configure a kernel the comments are probably not necessary, and if they don't know enough to do the configuration, it's going to take a much larger description to actually baby sit them through their difficulties. > - Rather than having everything based on your options.list file, read > LINT and just keep a private database of descriptions and criteria > for the things you know about. (This is a WIBNI, not something that > I think is easily achieved.) My software will use LINT if you name it option.list, unfortunately you then have no dependancies or other assistance in your configuration. > I think ultimately though, the biggest difficulty I have with 'kc' is > that it doesn't actually remove itself much from the configuration > file; for all the added convenience, essentially you are still > manipulating the same information in the same format. It is difficult to isolate configuration from configuration files. I guess I don't quite understand what you want here. My goal was to allow a person to easily select the items they wanted, perform a little "dumb" cross checking (resource conflicts), and make the task a little less painful. There are many things which can be done to improve this program, I will be the first to admit that (I would love to start over and do it as an O-O program, if I had a couple of days to spare), but at least it's something. I have seen many high-minded conversations go on in this group, but they didn't have the right tools, or no one had the time. I wrote this program 2 or 3 years ago and it was suffering a little bit-rot, so everytime the conversation came up, I thought, "nyah, this time they will actually do it (but I will still probably use mine 8-)." When nothing ever came from all the talk, I finally sent mine out as at least a stop gap, and maybe even as a platform we can build on. brian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707100258.VAA22029>