From owner-freebsd-config Mon Jun 16 00:48:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA21193 for config-outgoing; Mon, 16 Jun 1997 00:48:56 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA21187 for ; Mon, 16 Jun 1997 00:48:52 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id RAA10528; Mon, 16 Jun 1997 17:18:38 +0930 (CST) From: Michael Smith Message-Id: <199706160748.RAA10528@genesis.atrad.adelaide.edu.au> Subject: Re: To UNIX or not to UNIX ;-). Was: PPP problems. In-Reply-To: <199706160521.BAA16712@ethanol.gnu.ai.mit.edu> from Joel Ray Holveck at "Jun 16, 97 01:21:11 am" To: joelh@gnu.ai.mit.edu Date: Mon, 16 Jun 1997 17:18:38 +0930 (CST) Cc: config@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Joel Ray Holveck stands accused of saying: > get Linux. A GUI like this, to work, must be internally consistant, > and provide a consistant interface. I want to make sure that the > ideas we get will work before I start coding. After that, we can talk > about the rest. Just a point worth thinking over before you get too involved in the details. For a configuration interface to be taken seriously across the range of applications that FreeBSD finds itself used for, a very open and modular design is called for. Calling it a "GUI" implies the sacrificing of cross-system management, as well as the large number of systems that don't have pixel-addressable displays. > I don't have the skill... yet. I can design and code fine, but don't > know much about X. Still, this can be remedied. By the time the > framework is designed and planned, I think I can build up a reasonable > level of X skill to get started on that part. The framework was designed and planned and reached no-criticism point in about February or so 8) X skill is an almost irrelevant attribute to posess; what you want to be thinking about is the association of basic configurable elements ("parameters") into related groups, and the logical operations that make sense on a group of parameters. Take as an example a user-level activity such as "enable POP-3 services". What fundamental actions do you have to perform to take the system from its current (perhaps inconsistent) state to a state consistent with "POP-3 services are enabled"? Which parameters are involved in the transaction? What prerequisites are there? Can you leverage the "package installation" facility to install the POP-3 server software, or should you just return an error indicating that the user should DIT? > Terrific. I would like to do this. People, look over the goals that > I wrote down. Let's modify them, refine them. Then, let me know if > you want to help, and how. If you have the opportunity, I strongly encourage you to dig up the discussions that took place late last year and early this year. You will probably have to rummage a bit; I would start with the discussions on the -config list, and backtrack through -hackers and -chat (I believe you were involved last time as well). If you haven't already, look at the configuration server-side prototype at ftp://gsoft.com.au/pub/misc/juliet.tar.gz. It embodies a number of basic principles that need to be well-refined before things grow much further. > joelh -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[