Subject: Re: why separate system and pkg hierarchies? (was: /usr/pkg/etc/rc.d/*)
To: None <email@example.com>
From: leam <firstname.lastname@example.org>
Date: 03/19/2003 06:25:34
> There are two approaches.
> 1. the BSD style: basic os + add-ons
> 2. gentoo linux style: everything is a package.
> that way suits linux best, because it strives to be bleeding edge and
> don't care that much that basic os is not 100% cleaned and stable
> and consistent. it just changes too quickly and noone is having
> control. i like BSD style, where basic os is controled by the NetBSD
> foundation. We cannot control every single application, so we just
> apply some constraints and keep them controlled as much as possible
> pkgs. But enable them to EVOLVE THEIR WAY WITH THEIR RULES WITHOUT
> INTERFERING WITH OUR WAY AND OUR RULES IN THE BASIC OS.
I'm not sure I agree with this, though the point of NetBSD being lighter
seems true. If I have to put up a unix server for a variety of reasons,
so far Linux seems easier to do. I still have to whack away the extra
userland stuff, but the base OS seems to have more features like
filesystem choices, pre-built packages, and documentation.
If I build a system I'd rather have the packages, system and add-on, in
the same place. That way if I need to follow some path to find
something, I only have one. If I have startup files, I'd rather have a
central place for all of them, and then link them to various run-levels.
That way I can search in one place for what owns some effect, and I can
remove the activated startup script without worrying about removing the
original. I dis-like the grab-bag rc.everything scripts that start
That said, I've done Linux and Solaris admin for a bit, but am still
learning BSD. So there may well be advantages to this I've not discovered.