Date: Mon, 16 Jun 1997 04:14:17 -0400 From: Joel Ray Holveck <joelh@gnu.ai.mit.edu> To: msmith@atrad.adelaide.edu.au Cc: config@freebsd.org Subject: Re: To UNIX or not to UNIX ;-). Was: PPP problems. Message-ID: <199706160814.EAA18533@ethanol.gnu.ai.mit.edu> In-Reply-To: <199706160748.RAA10528@genesis.atrad.adelaide.edu.au> (message from Michael Smith on Mon, 16 Jun 1997 17:18:38 %2B0930 (CST))
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706160814.EAA18533>