>> [...] has resulted in things like the package system and /etc/rc.d,
> Don't touch the package system, please.

I don't argue for touching it.  Unlike the rc changes, the package
system is a case where people who don't like it can just ignore it and
it won't cause them any grief.  The only price for me is a half-dozen
executables I never use...and if that bothered me, I'd be yammering
about a bunch of other stuff too, like bind, uucp, sendmail, MIDI and
USB goop, etc.

The only danger I saw in the package system was that it would lead to
exchanges like

	User: I'm trying to build Foo V3.8 and I'm having such-and-such
		a problem....
	NetBSD person: Why aren't you using the Foo package?

(as opposed to actually addressing the problem, which simply happens to
be tickled by Foo V3.8).  Fortunately this doesn't seem to have
materialized.

>> I don't want to see NetBSD trying to compete with Linux and Windows
>> on their own ground, both because I believe it will lose and because
>> it will mean that NetBSD will then no longer suit the niche I am
>> part of.  Yet that seems to be where it's headed.
> Well, I don't thing thing that popularity is necesarily bad thing.

Me neither.  Additional user base *per se* is not something I mind.

But when that additional user base is seen as a good enough thing in
its own right that it's worth breaking things for the niche people,
well, as one of that niche, I feel..abandoned.

>> Just as "BSD way" != "CSRG products", "SysV way" != "SVR4 spec".
>> The rc.d scheme, as I understand it, has the same basic problems
>> that real SysV startup scripts do: they make human understanding and
>> manipulation of the startup sequence significantly harder, for the
>> sake of making mechanical ditto easier.

> I always though the problem with SysV-type startup script was the
> runlevel shit and no clear dependencies,

That's another problem with SysV startup.

> no clear way when exactly is what called (i.e. what kill/start
> scripts to call when changing runlevels).  Figuring out what services
> need to run before given service can be started is non-trivial in
> SysV.

> Those problems are just not present in what we have now.

True.  But just because one of two big problems with SysV startup was
not introduced, that's no reason to overlook the one that was.

> Nice things about the scripts in /etc/rc.d is that dealing with
> individual daemons/services is much more easier.  They do all the
> work you would have to do (e.g. ps ax | grep myproc; kill it; start
> with appropriate flags), plus they manage dependencies.

They..may try.  They will get it wrong too often.

ps ax | grep myproc is *not* suitable for automated use.  When human
intelligence is applied to the output before it's fed into kill, it's
fine.  Without that, it's an invitation to disaster.  (Which of those
pppd processes is the one I want to kill?  Or both?  And what about my
watch-pppd script, why did it kill that?)

> It provides you with much more flexible way to define what depends on
> what, way to define subsytems so that when you kill a service, all
> services depending on it are killed, too.

...assuming that's what I want, rather than to kill it, move the new
config into place, and bring it back up, letting the dependent services
retry a time or two rather than restrting them too.

And if shutting down Foo shuts down everything currently running which
depends on Foo, where does it record what those are so that when I
restart Foo a moment later they're brought back up?

> Or if you start a service which needs other services to run, they are
> also started.  Very nice.

...for turnkey production systems.

A disaster when, say, I'm trying to run an experimental replacement for
one of those services and the start script notices the stock one isn't
running and tries to start it, not able to tell that my replacement is
running instead.

Remember what I said about the OS-hacker niche?  Guess what perspective
this message is being written from. :-)

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B