new sysinstall

[Chris Pressey]

On Sat, 30 Aug 2003 01:41:49 +0200
"Ivan Voras" <ivoras!@!geri.cc.fer.hr> wrote:

> [...]
> The idea of a scripting language has very interesting and useful
> properties - if a dynamic enough language is chosen, the entire
> sysinstall and maintenance could be highly modularised, to the point
> where adding new behaviour or option is accomplished by just dropping
> a script file (acting as a module/library) in the appropriate
> directory (of course, a simple 'API' would then need to be formed).
> 
> Of course, shell scripts could do almost all that work, but I think a
> dedicated scripting language is better:
> -    *it is meant to be used as a general-purpose langugage, allowing
> for more natural programming*
> -    it is (more) modular
> -    it has more support for e.g. using sockets or parsing text (xml?)
> data-    it is *very* convenient to have such a language guaranteed to
> exist on every installation 'out there', and a standardised one too
> -    script code is much easier to modify and maintain
>
> Current scripting languages are usually portable to wherever there is
> gcc, so that is not a concern. A much bigger concern is that most of
> them are bundled with a massive collection of 'standard' libraries. I
> am much in favour of the idea to basically fork a version, include
> only the needed libraries that can compile with only the stuff that is
> in 'base' distribution (like file access, low-level OS support &
> information, ncurses, regular expressions...). Such fork should be
> installed so that it does not clash with a full installation of the
> language (including naming the interpreter executable differently),
> and the full version *must* be installed to run user applications. The
> fork version and libraries should be documented and kept as 'frozen',
> and updated only when a security update becomes available (or a
> seriously needed feature appears).
> 
> On the subject of the choice of the language, the foremost concern for
> me is*readability* (both for novice users and for looking at the code
> years later:) ). I know that perl in the current FreeBSD 4 &
> DragonflyBSD satisfies most of the requirements above, but the scripts
> are most of the time as readable as the shell ones. My pet-language is
> python, but everyone has theirs :). Alternatively, an intentionally
> small language could be used, such as lua (the misadvantage of which
> is the need to write the 'missing' libraries).

I couldn't disagree more - essentially on the same grounds as laid out
in my message of July 24th of this year.  In short, it's overkill.

However, a concrete example might help me understand why this sort of
added complexity is justified, if you care to give one.

My only suggestion for the install process is that there be plenty of
help screens and that they're written by someone who can *write*.  I
don't think there's anything that repels the less technically-inclined
from FreeBSD quite as soundly as the opacity of the documentation - and
the install process is often their first encounter with it.

-Chris