new sysinstall

[Garance A Drosihn]

At 9:13 AM -0700 9/1/03, Matthew Dillon wrote:
    I think we can settle on using a web server model,
    so lets target:
    * Apache
    * Links
Sounds good.

    Tcl/Tk should probably be discarded.
Sounds good to me.  I have used TCL (for TickleServices under
NeXTSTEP), and either I hate the language, or I "just don't
get it".
    /bin/sh is in simply because we *ARE* going to leverage
    RCNG to actually perform subsystem starts, stops, and...
It would be mighty surprising if /bin/sh was removed! :-)

    Perl is out because only a Perl programer can easily
    write in Perl
I have written thousands of lines of perl scripts.  Some of
them very impressive in what they can do.  But most of my
larger perl scripts end up in such a state that even I have
trouble figuring out how they work...  This might well be a
weakness on my part, but that is what often happens to me.
I usually do an OK job with my initial cut at a perl script.
But my scripts get uglier and uglier as the project expands
(beyond what I originally intended to do), especially if
there are changes to the constraints and requirements of the
script.  And of course, such changes almost always happen!
    Ruby and Python are still candidates.
I (for one) like ruby.  I have written a fair amount in ruby,
and my larger ruby scripts do *not* fall into the mess that
my larger perl scripts fall into, even for scripts where I
start out with a completely-wrong idea of the constraints and
requirements.
I have not worked much with python.  I can not say that there
is anything I can do in ruby which I "can not" do in python,
it is just that I enjoy writing in ruby but writing in
python doesn't do much for me.  I do *not* particularly mind
the intending rules in python, but somehow I just like the
ruby language more than python.
There have been long threads on the ruby lists which try to
"prove" that ruby is better than python, or visa-versa.  All
those threads ever prove is that the people who like ruby,
like ruby, and that the people who like python, like python.
I doubt we'll do any better in this mailing list.
So, I vote enthusiastically for ruby, but I am convinced
that it is absolutely impossible to "prove" that is the
right choice.
Several other messages mention the issue of:
    * There are issues with having multiple versions
      installed...  [of any of these scripting languages]
So far I have said nothing useful in this message.  Let me now
submit the one thing that I really want to push for.  If dfly
is going use ruby or python, then install it as "sysruby"
or "syspython".
By doing that, we can trim down (*) the language to be whatever
we want for "the system" (or add just the library packages that
we want).  We can leave it at whatever version we want.  We
can upgrade it at major *system* releases, instead of tracking
major *language* releases.  People who want the "real" ruby or
python can just install the appropriate package, and not care
what we want to use for "the system".
I think this is better than burying any language-version info
in all our system scripts.  I don't want to *have* to change
scripts when we decide to switch the system version.  Perhaps
we should include "sys-version" information, but not the
language version.  Ie, "sysruby1" for whatever ruby exists
in release 1.0 of dragonfly bsd.  If we switch to some major
new version, we call that "sysruby2" (even though that switch
might not happen until release 3.0 of dragonfly).
(* - we might want to trim down the language just to make it
easier for porting to new architectures, or because some
standard library module requires some other component which
we don't want to require on the "liveCD" version of the system).
--
Garance Alistair Drosehn            =   gad at xxxxxxxxxxxxxxxxxxxx
Senior Systems Programmer           or  gad at xxxxxxxxxxx
Rensselaer Polytechnic Institute    or  drosih at xxxxxxx