Re: Two NetBSDs: from Desktop NetBSD needs your help

["Steven M. Bellovin" <smb%cs.columbia.edu@localhost>]

On Sat, 7 Feb 2009 08:18:39 -0500 (EST)
der Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:

> Prompted by smb's response to ad's note about "Desktop NetBSD"....
> 
> I'm actually starting to notice a fundamental divide here.  There seem
> to be two groups of people (I'm painting with a broad brush here; the
> boundaries are not as sharp as I'm making them sound, but I think this
> characterization is useful enough to think about).  One group uses
> "modern" machines (i386, ia64, amd64), sees disk, RAM, and CPU cycles
> as cheap, and wants a "desktop experience", preferably one that looks
> as much like the Windows/Mac/Linux world as possible.  The other group
> uses other ports (sandpoint, vax, shark, pmax, the list is long), sees
> CPU cycles, RAM, sometimes even disk space as scarce resources, and is
> perfectly happy with a command line (or occasionally, as in embedded
> systems, no UI at all).  Most of the conflicts I've seen within the
> project, recently, are between these two camps.  Perhaps we need
> another split?  It would certainly cut down on those conflicts and
> keep each group happier, letting them have what they want without
> constantly struggling with the other.
> 
I'm not sure which camp you put me in...  I do run (reasonably) modern
hardware, but that's as much for lack of time as anything else.  My
Ubuntu and MacOS machines are my niche boxes, used for special
purposes.  I use NetBSD desktops, but I also use NetBSD file servers,
NetBSD dom0s and VMs, and a NetBSD gateway (a Soekris 4801 with only a
CF card at the moment).  They could all use improvement, because while
we have a great kernel, our next layer is deficient.

And that, I think, is what is important here.  The point is not to
split NetBSD, nor even to change the base system very much, and that
last qualifier is only because I suspect we're missing a small number
of primitives.  What we are or have been missing is really good tools to
layer on top.  These may include desktop things like a simplified
installer (care to explain to normal people what the disk geometry
questions are all about, or why they need to care?), but they also
include things like tools to install kernel, module, or user-level
patches to a rack-full of servers, or add-ons to pkgsrc to let me
distribute NetBSD's or locally-built new binary packages to a large
number of machines of varying architectures.  How should an embedded
system handle OS version upgrades?

                --Steve Bellovin, http://www.cs.columbia.edu/~smb