From owner-freebsd-ports  Wed Sep 20 21:01:58 1995
Return-Path: owner-ports
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id VAA17879
          for ports-outgoing; Wed, 20 Sep 1995 21:01:58 -0700
Received: from phoenix.volant.org (root@phoenix.volant.org [205.179.79.1])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA17868
          ; Wed, 20 Sep 1995 21:01:52 -0700
From: patl@asimov.volant.org
Received: from asimov.volant.org (asimov.volant.org [205.179.79.65]) by phoenix.volant.org (8.6.11/8.6.9) with SMTP id VAA10169; Wed, 20 Sep 1995 21:00:52 -0700
Received: by asimov.volant.org (5.x/SMI-SVR4)
	id AA21520; Wed, 20 Sep 1995 21:06:25 -0700
Date: Wed, 20 Sep 1995 21:06:25 -0700
Message-Id: <9509210406.AA21520@asimov.volant.org>
To: chuckr@eng.umd.edu
Subject: Re: ports startup scripts
Cc: kelly@fsl.noaa.gov, terry@lambert.org, julian@ref.tfs.com,
        asami@cs.berkeley.edu, ports@freebsd.org, hackers@freebsd.org
X-Sun-Charset: US-ASCII
Sender: owner-ports@freebsd.org
Precedence: bulk

|>  OK, let me see if I have this right:
|>  
|>  1) We need an improved startup script system.

Right.

|>  2) There's a very good framework for one existing, it has a lot of bugs
|>     that many people find completely objectionable, but it's a good starting
|>     point.
|>  3) Removing the perceived bugs in that other system makes it different
|>     from the original, displeasing those that happened to have a lot of
|>     experience using it, and don't want to learn another.

Make sure they really are bugs before changing them.  And make sure that
your solution isn't just a different set of bugs...

I suspect that most of the problem with the SVr4/Solaris/HP-UX startup
script system is poor documentation.  And a lot of the people complaining
are really complaining about the change, not the actual result.  Any
change we make will suffer from that, no matter how good it is.

|>  4) We, instead, must use another custom setup.  It, too, will be
|>     non-standard, but at least it won't be traceable to the One True System.

I'm not sure I understand this point.

My position is:

    1.	If we can come up with a system that is significantly better
	than the SVr4 system, do it.

    2.	Minor incompatabilities, like re-numbering the run levels,
	are not likely to be a significant improvement.  Don't do it.

|>  Is this a fair summary?
|>  
|>  I'm not in a fight with anyone, even Microsoft.  I wish our fellow 

If you ever want to see a wide range of commercial quality end-user
software available for FreeBSD, you -are- in a fight with Microsoft.
A fight for market share in installed seats.  If, on the other hand,
you just enjoy hacking around in the kernel and utilities, and don't
care if FreeBSD withers away and you wind up the only one still using
it, then go right ahead and re-invent every wheel you come across.

|>  enthusiasts running Linux well, but I don't want to copy them.
|>  I really enjoy FreeBSD, and I enjoy showing it to friends, like I
|>  enjoy sharing favorite books.  FreeBSD is quite different than other SYSV 
|>  systems, and everyone associated with it wishes that it remain so.  If 
|>  I'm discussing making gratuitous changes to a part of the BSD Unix 
|>  standard, I apologize, I'm completely wrong (and embarrassed), but I 
|>  don't think so.

You make it sound like the folks working on FreeBSD would make changes
just to be different from SYSV.  I sincerely hope that is not the case.
We should strive to produce the best unix-derived system that we can;
but vigorously fight the Not Invented Here syndrome.  If somebody else
has a better solution than the one we are using, we should feel perfectly
free to adopt it.  Or, if we can, improve it further.



-Pat