Subject: Re: why separate system and pkg hierarchies? (was: /usr/pkg/etc/rc.d/*)
To: None <>
From: leam <>
List: current-users
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 
> overall
>    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 
> under
>    pkgs. But enable them to EVOLVE THEIR WAY WITH THEIR RULES WITHOUT 

  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
  unrelated services.

  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.