new sysinstall

[Ivan Voras]

Billy wrote:
> On Sat, Aug 23, 2003 at 12:45:31PM -0500, Robert Garrett wrote:
>> I'm seeing this as a four stage system.
>>
>> 1. Disk Editor (creates slices, and partitions)
>> 2. Distribution Selection
>> 3. Glorified FTP client
>> 4. Configuration Management System

> It would be nice if the various components of sysinstall do NOT have
> different behavior than then regular system tools.  I'm talking

> Ideally the fdisk and the fdisk portion of sysinstall would/will come
> from the same piece of code, so that we have equivalent behavior


I this is an excellent time to rehash the idea of an 'embedded' scripting
language for system maintenance. Since after the initial booting there is a
complete unix environment present, and the actual install process of the
first stage is basically a 'cp -r' and writing a boot sector, the new
sysinstall could just be a script that calls the appropriate
'mini-utilities'. If needed, the script can call the mentioned 'cp',
'pkg_add', 'fdisk' and similar utilities.

The old sysinstall could be broken into useful pieces (I personally very
much like the 'semi-gui' fdisk of the sysinstall over the die-hard terminal
version) that can work as separate utilities. (On the subject of fdisk, I
think both versions should coexist, with the sysinstall version being the
default)

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).

--
--
Logic is a systematic method of coming to the wrong conclusion with
confidence.