Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 16 Jun 1997 01:52:34 -0400
From:      Joel Ray Holveck <joelh@gnu.ai.mit.edu>
To:        msmith@atrad.adelaide.edu.au
Cc:        devnull@gnu.ai.mit.edu, molter@logic.it, adrian@obiwan.psinet.net.au, vas@vas.tomsk.su, chat@FreeBSD.ORG
Subject:   Re: To UNIX or not to UNIX ;-). Was: PPP problems.
Message-ID:  <199706160552.BAA16911@ethanol.gnu.ai.mit.edu>
In-Reply-To: <199706160105.KAA08436@genesis.atrad.adelaide.edu.au> (message from Michael Smith on Mon, 16 Jun 1997 10:35:12 %2B0930 (CST))

next in thread | previous in thread | raw e-mail | index | archive | help

>> we want to use.  (I may well rewrite parts of the user interface
>> in Guile and use Tk; I don't know yet.)
>Tk already comes with a perfectly good scripting language; Tcl.  Don't
>let another of RMS' irrational bigotisms put you off.

I personally am going to speak up for Guile, because Lisp is a great
language.

>[this is someone else rambling]
           \-- Me.  -joelh
>>>** System configuration
>>>I'm sorry, guys, but this *must* be done well.  How difficult would it
>>>be to write an X interface to get the /etc files handled right?  Or
>Bloody hard, bucko boy.  There isn't enough meta-information
>associated with them to derive everything you need to know
>automagically, so you have to embed this information somewhere higher
>up the chain.  This becomes unfun very fast, as as soon as the file
>format/usage changes your tools suffer from version skew.

Most of the stuff is fairly static.  When was the last time that the
resolv.conf format changed?

As for the stuff started in /etc/rc, I'm going to go out on a limb
here and assume that if we can get keep things coordinated enough to
have a sane configuration file, then we can keep a fairly simple
structure graph for it together.  That's why I was thinking of using
Lisp for this; it's very easy to organize dynamic graphs and whatnot.

>>> maybe systems to take a new user by the hand and set up some of the
>>> systems (like ppp) from scratch?  I can see using Guile (an extension
>>> Lisp) or a similar language to make a basic framework and library,
>>> which then can take care of configuration for other subsystems as they
>>> are added.  For instance, the ppp package could add its little bit of
>>> configuration code to a standard directory, which the configuration
>>> tool could then take in and have seamless integration into the rest of
>>> the configuration.
>Been there, done that.  For the server side of a network-transparent
>implementation of this concept, see
>ftp://gsoft.com.au/pub/misc/juliet.tar.gz
>Note that the version there only supports modules written in Tcl.
>Current working code supports modules written as shared libraries, and
>other extension languages can be supported just as soon as someone
>comes forward with some language-specific knowhow.
>The client side is still in conceptual development, as it's likely
>that there are going to be requirements for several different client
>styles (GUI, text mode, batch mode, etc.)
>The current model would, in fact, be quite acceptable as an extension
>to an SNMP MIB if SNMP's security were a little better.

Okay, I'll check this out.

>>> - Some basic word processor.  I'm not talking about Emacs here, since
>>>JRL balks at the idea of not having different fonts and sizes
>>>(although that is in the works for Emacs).  Does anybody know of a
>>>WYSIWYG (or even -ish) TeX editor or something of the sort?
>> There's a program called Lyx that I've heard of, but it requires that
>> you use its special template instead of Plain Tex or LaTeX, and it
>> looks like it is even less stable than [insert name of favorite
>> proprietary word processor that crashes a lot].
>*ahem*.  Have any of you looked at StarOffice yet?

What *was* I thinking?  Of course, StarOffice would be perfect, as we
have discussed on this list multiple times in the past.

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?199706160552.BAA16911>