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 [[ From owner-freebsd-config Mon Jun 16 01:14:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA22018 for config-outgoing; Mon, 16 Jun 1997 01:14:36 -0700 (PDT) Received: from ethanol.gnu.ai.mit.edu (we-refuse-to-spy-on-our-users@ethanol.gnu.ai.mit.edu [128.52.46.64]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA22012 for ; Mon, 16 Jun 1997 01:14:33 -0700 (PDT) Received: by ethanol.gnu.ai.mit.edu (8.8.5/8.6.12GNU) id EAA18533; Mon, 16 Jun 1997 04:14:17 -0400 Date: Mon, 16 Jun 1997 04:14:17 -0400 Message-Id: <199706160814.EAA18533@ethanol.gnu.ai.mit.edu> To: msmith@atrad.adelaide.edu.au CC: config@freebsd.org In-reply-to: <199706160748.RAA10528@genesis.atrad.adelaide.edu.au> (message from Michael Smith on Mon, 16 Jun 1997 17:18:38 +0930 (CST)) Subject: Re: To UNIX or not to UNIX ;-). Was: PPP problems. From: Joel Ray Holveck Reply-to: joelh@gnu.ai.mit.edu Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> 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. Actually, I had in mind something more layered, that could use anything from a teletype to an X display. But the problem I was (and am) trying to address is the accessability of FreeBSD to J. Random Luser, which includes both a GUI and an easy configuration, but as two separate goals. >> 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. Sorry, I was unaware of the Romeo/Juliet project you already started when I initially spouted off. I also expected to have to do most of this myself, and that would require X skill. That is, however, the only skill I can see that I would need but do not have. > 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? I was actually thinking more along the lines of 'what is an easy way for any package to specify how it must be configured'; see my message to Jordan with the Lispish snippit at the top for that info. In the system I had envisioned, the configuration system hasn't any inherent knowledge about POP3, SMTP, or any other package. The packages which provide those services give the necessary information to the system during installation, and their configuration menus are then assimilated into the configuration system. All this was a quick design idea. If you have something more well-thought-out, I'd love to examine it. >> 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). I've never been on -config; I didn't know it existed. I'll check the old discussions out. I was involved in a similar discussion some time ago, but to a very minor degree. > 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. Okay. It won't be tonight; I'm writing a letter to a friend and answering mail as it comes in. After I finish that, I'm going to bed. (It's presently 3:16 AM on this side of the pond, you see.) Happy hacking, joelh -- http://www.wp.com/piquan --- Joel Ray Holveck --- joelh@gnu.ai.mit.edu All my opinions are my own, not the Free Software Foundation's. Second law of programming: Anything that can go wrong wi sendmail: segmentation violation -- core dumped From owner-freebsd-config Mon Jun 16 01:14:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA22036 for config-outgoing; Mon, 16 Jun 1997 01:14:51 -0700 (PDT) Received: from ethanol.gnu.ai.mit.edu (we-refuse-to-spy-on-our-users@ethanol.gnu.ai.mit.edu [128.52.46.64]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA22030 for ; Mon, 16 Jun 1997 01:14:48 -0700 (PDT) Received: by ethanol.gnu.ai.mit.edu (8.8.5/8.6.12GNU) id EAA18533; Mon, 16 Jun 1997 04:14:17 -0400 Date: Mon, 16 Jun 1997 04:14:17 -0400 Message-Id: <199706160814.EAA18533@ethanol.gnu.ai.mit.edu> To: msmith@atrad.adelaide.edu.au CC: config@freebsd.org In-reply-to: <199706160748.RAA10528@genesis.atrad.adelaide.edu.au> (message from Michael Smith on Mon, 16 Jun 1997 17:18:38 +0930 (CST)) Subject: Re: To UNIX or not to UNIX ;-). Was: PPP problems. From: Joel Ray Holveck Reply-to: joelh@gnu.ai.mit.edu Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> 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. Actually, I had in mind something more layered, that could use anything from a teletype to an X display. But the problem I was (and am) trying to address is the accessability of FreeBSD to J. Random Luser, which includes both a GUI and an easy configuration, but as two separate goals. >> 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. Sorry, I was unaware of the Romeo/Juliet project you already started when I initially spouted off. I also expected to have to do most of this myself, and that would require X skill. That is, however, the only skill I can see that I would need but do not have. > 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? I was actually thinking more along the lines of 'what is an easy way for any package to specify how it must be configured'; see my message to Jordan with the Lispish snippit at the top for that info. In the system I had envisioned, the configuration system hasn't any inherent knowledge about POP3, SMTP, or any other package. The packages which provide those services give the necessary information to the system during installation, and their configuration menus are then assimilated into the configuration system. All this was a quick design idea. If you have something more well-thought-out, I'd love to examine it. >> 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). I've never been on -config; I didn't know it existed. I'll check the old discussions out. I was involved in a similar discussion some time ago, but to a very minor degree. > 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. Okay. It won't be tonight; I'm writing a letter to a friend and answering mail as it comes in. After I finish that, I'm going to bed. (It's presently 3:16 AM on this side of the pond, you see.) Happy hacking, joelh -- http://www.wp.com/piquan --- Joel Ray Holveck --- joelh@gnu.ai.mit.edu All my opinions are my own, not the Free Software Foundation's. Second law of programming: Anything that can go wrong wi sendmail: segmentation violation -- core dumped From owner-freebsd-config Tue Jun 17 04:38:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA10436 for config-outgoing; Tue, 17 Jun 1997 04:38:15 -0700 (PDT) Received: from obiwan.psinet.net.au (adrian@for.a.good.time.call.adrian.austnet.org [203.19.28.59]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA10430 for ; Tue, 17 Jun 1997 04:38:11 -0700 (PDT) Received: from localhost (adrian@localhost) by obiwan.psinet.net.au (8.8.5/8.8.5) with SMTP id TAA12360 for ; Tue, 17 Jun 1997 19:17:42 +0800 (WST) Date: Tue, 17 Jun 1997 19:17:42 +0800 (WST) From: Adrian Chadd To: freebsd-config@freebsd.org Subject: DELETE ME Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I warned you. :-) Cya, -- Adrian Chadd | "Unix doesn't stop you from doing | stupid things because that would | stop you from doing clever things"