On Thu, 2002-02-28 at 09:23, David O'Brien wrote:
> On Thu, Feb 28, 2002 at 08:39:33AM -0800, Mike Makonnen wrote:
> > I chose to go a slightly different route than Gordon, in that I have not
> > tried to make the scripts compatible with NetBSD (His scripts include
> > conditionals for NetBSD, mine don't). These are my reasons.
> The point you are missing is that we can work with the NetBSD guys to
> maybe change the NetBSD framework such that it works better for *both*
> systems.  It is totally stupid to not share as much of the existing body
> of work with NetBSD.  If you have ever had to administrate or use more
> than one Unix OS, you know how gratuitously different things are in
> them.  Typically for no good reason.

I don't think I articulated myself very well in my email. I am not
against sharing code with NetBSD and I don't like gratuitous diffs any
more than the next guy, but the differences in our scripts are because
of gratuitous diffs elsewhere in the system. I think it's better to
eliminate the differences elsewhere in the system. Then the scripts will
naturally converge, with less need for conditionals. The 'sysctl -w'
issue is a trivial example, but let me use it again. My argument is that
it is better to have NetBSD support writing to sysctls without a '-w'
switch, so that the same invocation works for both OS, than to maintain
a mechanism, in the startup scripts, by which to work around the issue.

Let's take another example. The REQUIREMENT line in a script cannot be
made conditional. It requires a modification of rcorder(8) to do so.
So, if one of NetBSD's services has a requirement that we don't have, it
automatically means we need two separate scripts with different
REQUIREMENT lines regardless of whether the rest of the script is
identical. BTW, from a quick glance at the rcorder(8) source, modifying
it to eliminate this problem is not going to be a trivial task.

> >     - Each project is going to have scripts that the other project
> >       won't use. This means someone has to invest the time and 
> >       effort to maintain scripts the project won't be using
> I know we will not have 100% identical implementations.  But people seem
> to want to use the NetBSD bits as reference but change things to how the
> "should have been done".

Now, that I've had a bit more time to think about it, I appreciate
better the point you're making. I still think it's better to make the
rest of the OS more compatible, but I can understand your point. What
bothered me about it initially is that it seemed you wanted 100%
compatibility and _all_ of it directed at making our startup process
conform to NetBSD's. The reason I eschewed making the scripts NetBSD
compatible is because once I saw how Gordon did it and I actually
started converting the scripts I gained a better appreciation for the
amount of work it entailed. It's going to be a tedious and long process
probably, but I can see the merits now if the NetBSD people are willing
to work with us. For example, I prefer our method of mounting local and
then remote file systems, rather than having the sysadmin specify
critical_filesystems in  rc.conf ( I can already imagine the flood of
emails to freebsd-questions: "Help! My system won't boot..." :-).

Can I make a few suggestions:
        - Aim for at least a six month "shake-down", with rc_ng="YES"
          by default, in -Current before 5.0-Release.

        -  A. Leave the current scripts as they are, for the moment. As
              new scripts get converted make them NetBSD compatible.
              Then work on making the initial scripts converge.
              This option will probably take some time.
           B. Leave the current scripts as they are, for the moment.
              Get the scripts converted as quickly as possible. If
              possible make them NetBSD compatible from the start, but
              the overriding factor is getting the new system up and
              running in -Current so that people can start using it
              while the larger and slower task of converging the scripts
              goes on in parallel. Getting the rest of the rc system
              converted should only take a couple of weeks.

        -  It may be useful to fix _some_ compatibility problems in the 
           base system, even if just to reduce the complexity of a
           script. However, I have a suspicion we would just get bogged
           down in flame-fests between the two projects over who's 
           implementation is better :(

        - I think on some things, the two projects may "agree to
          disagree" on, which means the majority of the code base
          will probably be 'identical', but there will be differences
          in things like, boot order, requirements, etc.

I am of the opinion that it would be better to just get the system up
and running to start with, and then work toward making them as identical
as possible as we move forward. Never the less, I am willing to put
effort into converging the two systems (/me thinks I might live to
regret this sentence :-).

mike makonnen

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to