--pgp-sign-Multipart_Tue_Mar_20_16:27:43_2007-1
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

At Mon, 19 Mar 2007 20:10:12 -0700,
Scott Ellis wrote:
>=20
>   The root of what is being proposed is the ability to use rc.d/ stype
> scripts rather than the rc.local file.  The proposal to extend rc.local
> into "modern" NetBSD times by allowing rc.local.d/ seems reasonable, and
> preserves the differentiation between 'OS' and 'local' scripts.
>=20
> I for one welcome the thought of an rc.local.d/ .

I can assure you that such artificial separation of things that are best
kept together is a very BAD idea.  It leads to frustration and
unnecessary complexity, and those things _always_ lead to very serious
mistakes even by the most careful of system managers.

The current system is very simple and very easy to manage (when used
correctly), regardless of whether add-on packages are installed manually
or via pkg_*.

It is _extremely_ simple to differentiate 'OS' and 'local' (and 'pkg')
scripts without moving them into separate directories.  You do not need
to put things into separate directories just to differentiate their
origin.  As I said the trivial identification of OS/pkg and local
scripts is already possible with a trivial "grep" (or visual inspection).

Furthermore, and by far most importantly, such differentiation is only
necessary during quite rare moments of the average system's lifetime.

On the other hand unification and consistency of location for system and
service controls and configuration is highly desirable on every day of
the average system's lifetime, including on those days when upgrades and
changes are made to installed software (base or add-on).

Meanwhile the need to mechanically identify and manage all locally added
files everywhere on the system is still very high and it is already most
easily solved by creating pkgsrc modules and exclusive use of the pkg_*
tools.  In conjunction with use of syspkgs such policies even make it
possible to merge /usr/pkg and /usr (or even /, with minor adaptations).

I.e. if you want to differentiate things then use tools that do it for
you and you can eliminate confusion, mistakes, and unnecessary drudgery.

Creating unnecessary complexity for what turns out to be zero benefit,
and for an extremely rare need, is actually a serious detriment overall.

One of the reasons I refuse to manage most GNU/Linux systems is for the
very reason that with most such distributions these important system and
service controls and configuration are spread over hell's half acre and
it's nearly impossible to remember what's where on all the many variants.

If you could show any other reason for this kind of separation, other
than the already easily satisfied need to differentiate their origin,
then that reason could be weighed, but at the moment the scales are
entirely weighted on the side of the status quo and this proposal is,
IMNSHO, counter-productive.  In my experience though, having created and
managed both systems that have extreme degrees of artificial separation
of locally added software, and those with zero degrees of separation, I
seriously doubt there are any other advantages to such separation.

--=20
						Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>       Secrets of the Weird <woods@weird.com>

--pgp-sign-Multipart_Tue_Mar_20_16:27:43_2007-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: h9XbtHYjGYThNVtWZ+bGf2oFw17W+mP8

iQA/AwUBRgBDwWZ9cbd4v/R/EQKvygCg6/X4JD6gvJ4PECxUDSh3CJ+9xLkAoKAO
e3amGGL/zEMynYgd0/r3LfA1
=d2Hg
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Tue_Mar_20_16:27:43_2007-1--