Re: Why is Desktop NetBSD a threat to NetBSD?

[Andrew Reilly <andrew-netbsd%areilly.bpc-users.org@localhost>]

On Sun, Feb 08, 2009 at 06:13:36PM +0000, David Holland wrote:
> Which is fine, but almost none of that touches on the points that
> concern me. In order to make the desktop stuff work properly, it needs
> to integrate with the base system at a number of points. (Obvious
> examples that come to mind include the handling of online
> documentation, generating/processing device change notifications, and
> dealing with system configuration.)
> 
> If this integration is not done at all, the desktop will not run very
> well, which will reflect badly on the project even if (maybe
> particularly if) lots of people don't use the desktop.
> 
> If the integration is done poorly, it can and will affect the quality
> of the existing and future NetBSD experience for those who don't use
> the desktop.
> 
> As I said in my previous posting, doing the integration well requires
> thought and attention, and I'm somewhat concerned about whether it's
> going to get it. It doesn't help that other projects have set a poor
> precedent, either.

There is a bit of a third angle to consider, I think, although
perhaps it really is as simple as the raw-server/full-desktop
dichotomy...  I base my observations on the two other desktop
BSD systems that I use all the time: Mac OS and FreeBSD.  (My
NetBSD use is so-far confined to a net-booting server
application.)  This third angle is that it seems that the
available desktop environments, when applied, replace fairly
large lumps of base-system functionality.  Not augment; replace.
I speak in particular of GNOME and hal, although it seems that
hal is becoming a dependency of modular xorg, so you might need
it whether or not you go for GNOME.

Anyway, hal wants to control the mounting of fixed and removable
drives, and it wants to do that independently of /etc/fstab.  It
wants to use another set of XML config files called
PolicyKit.conf and something else related to sessions and GDM.
The upshot of which is that once hal is working properly (and on
my FreeBSD box it still isn't), I lose the ability to mount things
directly, I have to gnome-hal-mount --some-enormous-command-line
(or get nautilus to do it, which is probably fine, when it
works.)

Even if you accept that that's a reasonable price to pay for a
slick, integrated desktop that doesn't require terminal window
incantations for anything, if nothing else you're signing
someone up for a lot of work to make sure that hal tracks
on-going changes in both the kernel and NetBSD infrastructure,
and however the up-stream reference (Linux, probably) wriggles.

How long will a dynamic, dbus+hal configuration be able to
coexist with rc-NG/rcorder?  I know that the Mac OS control GUI
functionality has subsumed most of that under launchd and a
forrest of plists.  Not that that's necessarily a wrong design
decision, but there's no escaping the fact that it's a lot
different from /etc as it is now.  And that changes the base
system, or has to track changes to the base system as a fork.

Cheers,

Andrew.