From owner-freebsd-config Fri Jan 10 01:44:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id BAA03075 for config-outgoing; Fri, 10 Jan 1997 01:44:15 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id BAA03070 for ; Fri, 10 Jan 1997 01:44:12 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id BAA06156; Fri, 10 Jan 1997 01:44:04 -0800 (PST) To: Michael Smith cc: config@freebsd.org Subject: Re: Config Manifesto comments? In-reply-to: Your message of "Fri, 10 Jan 1997 13:53:39 +1030." <199701100323.NAA01710@genesis.atrad.adelaide.edu.au> Date: Fri, 10 Jan 1997 01:44:04 -0800 Message-ID: <6152.852889444@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Well, it's been more than a week since I posted the first-draft FCF > proposal, and the silence has been deafening. > > Should I take it then that 'vi' is the configuration tool-of-choice and > pack the whole thing in? No, please don't. Assume instead that those of us who care were either preparing for or are now directly at USENIX. :-) I've spent a lot of time talking with BSDI about their installation and system management interface which will debut in 3.0, BTW. Guess what - it's HTML based. When I raised the objections that others have raised about the limitations of crafting good looking interfaces in HTML, the response was "yeah, we know, but face it - there's a GUI standard now, the HTML browser is it, end of story. Learn to live with it, warts and all, OK?" They also don't feel that it's worthwhile to attempt to use lynx or make the product lynx friendly. In BSD/OS 3.0, you're asked enough questions to configure the network and then optionally start the X server + a browser (in this case Netscape since they're licensed for it) or simply go to another station if you're not able to run a browser (say because you're on a serial console). You know what? I think they're right. Technology is simply moving so fast that these assumptions are no longer unreasonable, nor would they be by the time we actually deployed our own system. How that effects the romeo/juliette abstraction I'm not sure, exactly, but I still like the idea of keeping all the "system properties" in property lists (which can be arbitrarily nested) and making them the responsiblity of a single daemon. That allows you to write multiple agents for frobbing the data, not just our nifty installation and setup tool. I guess that means that Juliette is safe. :-) Romeo might need an HTML hair transplant, but I need to go back and read the spec in more detail before I respond. This is on my post-conference TODO list so please don't despair, Mike! :-) Jordan