Re: Desktop NetBSD needs your help

[David Holland <dholland-current%netbsd.org@localhost>]

On Sat, Feb 07, 2009 at 12:00:03AM +0000, Andrew Doran wrote:
 > [desktop stuff]

While all that is a fine idea in principle, I'm worried that in
practice it's going to end up being another large-scale effort to
reinvent the mistakes of the Linux world.

As a few people may be aware, I argue about this regularly on chat
with jmcneill, and the substance of those discussions usually breaks
down into two major points:

   1. We really do need various desktop things to work more cleanly.
   2. It is essential not to violate the integrity of the system by
      making half-assed changes, or uncritically adopting half-assed
      third-party solutions.

For the most part NetBSD as a project manages to avoid making half-
assed changes; however, detecting system-level design flaws in
3rd-party solutions is not always so easy, and resisting the pressure
to adopt them regardless is harder still. The most obvious such
problem in the current desktop bundle is sysutils/hal; as things stand
it's needed to make various things work, but it doesn't do most of
these things the right way, and it is not the right mechanism going
forward.

Ultimately, the Linux desktop folks (and, in fact, the Linux community
in general) have never bothered much with proper system-level
integration. We know better than that; we can and should do better
too; but it takes thought, and design work, and feedback cycles. It
requires a balanced approach that's cognizant of system-level issues
as well as desktop issues.

This in particular means paying adequate attention to the people who
are afraid their ksh-and-vi world is going to stop working; the reason
for those concerns is precisely that in other projects, the push
towards the desktop has compromised system-level integration, which in
extreme cases *does* break things in the ksh-and-vi world. For
example, in most Linux distributions today it is no longer safe to
configure the system solely by editing files in /etc; this (sometimes
and unpredictably) leads to inconsistencies between /etc and other
hidden or semi-hidden state on the system that's silently maintained
by the "easy to use" configuration tools. This results from poor or
nonexistent system-level design. It's ultimately not acceptable.

We can avoid making this particular mistake and others like it, but we
will need to make a conscious effort. Meanwhile, several people have
already posted in this thread to air this quite legitimate concern,
although perhaps without explaining the background.

The attitude that's been displayed in response is troubling, as is the
phrase "we are not interested in debating the essential merits of the
project." Starting out with a conviction that one already knows the
right thing to do and that one is doing that thing... is not sound
engineering.

-- 
David A. Holland
dholland%netbsd.org@localhost