Date: Tue, 5 May 1998 20:20:47 +0100 (BST) From: Ben Cohen <bjc23@hermes.cam.ac.uk> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: Stuart Henderson <stuart@internationalschool.co.uk>, advocacy@FreeBSD.ORG Subject: Re: A GUI greyscale interface by default / sysinstall II Message-ID: <Pine.BSF.3.96.980505194058.224B-100000@bjc23.trin.cam.ac.uk> In-Reply-To: <18987.894390105@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi! > > Incidentally, would it be useful for the config program to do something > > like rcs or CVS on the major config files automatically to allow easy > > undos and (perhaps) multiple configurations? (Either by default or as an > > option.) > > Probably not - most folks wouldn't know what to do with the information > anyway. I'm assuming that this is entirely integrated into the config program, so that rcs would be completely transparent. The config program could have an option (e.g. either a single option from the main menu, or more likely an option from each config screen, like kernel, devices, printers, etc.) to look at and possibly retrieve previous setups. This might be useful for retrieving previous configurations if a mistake has been made. (For example, if the config program supports kernel config then the user can go back to the previous kernel(s) if something is broken.) Multiple configurations (like different hardware profiles in MS Windows) could be selected. Thus, for instance, when at university I have an ethernet connection, but I don't at home; I can't be bothered to change all the network settings each time I go home and come back, so when I'm at home I have to wait for attempted network connections to time out. If multiple configs were available then I could just switch each time. I don't know if rcs has any facility to remove data older than a certain age, but this could be added to stop the *,v files growing too large. It would also be handy as the *,v would be a sort of backup for each config file in case of corruption etc. Of course, the great disadvantage then would be that any manual changes wouldn't be recorded in the *,v file unless the user used rcs to make the change---but in this case the config program could (=must) save the change as a new revision. Comments in rcs need not be entered by the user (except for describing different configs), but the config program could put in something intelligent like "Changes made by setup program" or "Changes made by user" if the config file had changed since the last time the config program changed the file (i.e. the user had changed it manually). The config program could have an option _to_ use the rcs system or not to---this might be useful for backwards-compatability, for example. There could also be an option so that the rcs comments could be added automatically as above or by hand if the user wanted. If the config program has (as I suggested before) perhaps three different user-selectable levels, "Newbie", "Intermediate" and "Advanced", the rcs bit might only be available for the "Advanced" setting. By the way, what do people think of having about three different levels like this? (Sort of like the three different levels of installation in /stand/sysinstall.) I think it would be nice as it would allow an easy-to-use basic setup for newbies, a more comprehensive setup for people who need an extra bit of control, and an advanced setting which has lots of unusual and powerful features? I don't know how much programming this would take (it depends on the way the config program is written) but it might be worth it. In any case, once the rcs thing is written once it presumably doesn't take much more effort to use it for each config file (given that rcs itself can be used and that the config files have to be loaded and saved anyway). And the three settings might be OK to write depending on the toolkit used. This does mean, however, that the sysinstall program [which hopefully will be renamed something like setup!] might have to have it's _own_ config file! Please let me know whether you think the ideas above are helpful or complete rubbish! Thanks... Ben. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980505194058.224B-100000>