From owner-freebsd-hackers  Fri Jul 21 22:06:06 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.11/8.6.6) id WAA10056
          for hackers-outgoing; Fri, 21 Jul 1995 22:06:06 -0700
Received: from gndrsh.aac.dev.com (gndrsh.aac.dev.com [198.145.92.241])
          by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id WAA10048
          ; Fri, 21 Jul 1995 22:06:02 -0700
Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.6.11/8.6.9) id WAA14561; Fri, 21 Jul 1995 22:05:55 -0700
From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
Message-Id: <199507220505.WAA14561@gndrsh.aac.dev.com>
Subject: Re: What people are doing with FBSD
To: iidpwr@lightlink.satcom.net (Imperial Irrigation District)
Date: Fri, 21 Jul 1995 22:05:54 -0700 (PDT)
Cc: iidpwr@lightlink.satcom.net, jkh@time.cdrom.com,
        freebsd-hackers@freefall.cdrom.com, hsu@cs.hut.fi,
        jmacd@freefall.cdrom.com, karl@mcs.com, terry@cs.weber.edu
In-Reply-To: <199507220454.VAA11103@lightlink.satcom.net> from "Imperial Irrigation District" at Jul 21, 95 09:54:27 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2183      
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

> 
> What suggestion?  Provide an upgrade path?  Trust me, we're working
> on it! :-)
> 
> Sorry, I didn't make myself clear.
> The suggestions refer to (1) seperate the configuration data
> from the executable scripts such as rc, rc.local, netstart, ...etc.
> The advantage of seperating the configuration data from the executable scripts
> is easier to debug for both the user and the developer.

This is work in process.  If you look at the 2.0.5R versions of rc, and
netstart at the top they have clear markers saying that if for some
reason you need to modify this file we would like to know about it.

>From those markers I have 40 some odd submissions of things to correct
and enhance in /etc/rc and netstart to rectify the things folks had to
tweak.

Once I get this all intergrated (and most of it is done) and fully tested
(some changes are in the field being used day to day, so I know them to
be safe, others are, well, rather untested and have known problems) it
will go into the 2.2 -current developement branch for a more extensive
testing.

Some or all of this may end up in 2.1, but I will not make promises at
this date on that, it is a _very_ complex problem, that you just can't
say seperate the data from the executable and be done with it as some
of it involves very intertwined sequences that must be different depending
on site configuration.  (ie, diskless operation puts a royal twist into
the order of events in /etc/rc, this is one problem I know I can not
get solved by 2.1, gated puts another twist in with respect to when
you clean /var/lock, etc, etc, etc :-().

> (2) provide an upgrade path. That would speed up the development too because
> the current developer can upgrade to the latest and greatest. Moreover, that
> would close the gap between commercial grade OS and non-commercial OS.
> Most importantly provide an upgrade path is user friendly. Make the user
> happy.

I am not involved in that effort, but my understanding is that something
is being worked on for this as well.

> 
> 


-- 
Rod Grimes                                      rgrimes@gndrsh.aac.dev.com
Accurate Automation Company                 Reliable computers for FreeBSD