der Mouse wrote:
> worth dropping the niche people for, and this has resulted in things
> like the package system and /etc/rc.d, things designed to make life

Don't touch the package system, please. There was period in time
when I enjoyed getting all the software I need to use to compilable
state on NetBSD. That period is over and I'm happy I can just
pick up the software I want and install it via simple
make in pkgsrc.

Package system is great thing. It saves my time enormously and I can enjoy 
doing my staff instead of fighting with software to build
and install on some sane place.

> But they're already very well served by Windows, Linux, etc.  Perhaps
> FreeBSD as well; they seem to have gone farther towards catering
> towards that crowd than we have, from what little I know of them.

They have done also quite a lot of cool staff.

> 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.
More users means more resources to solve problems, too. People
tend to not spend time on things, which they consider as "dead",
even when it's good.

> 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, 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.

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.

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. Or if you start a service which
needs other services to run, they are also started.
Very nice.

Jaromir
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>      http://www.ics.muni.cz/~dolecek/
@@@@  Wanna a real operating system ? Go and get NetBSD, damn!  @@@@