Re: Removing ARCNET stuffs

[Gerard Lally <lists+netbsd.tech.net%netmail.ie@localhost>]

At date and time Fri, 29 May 2015 11:09:08 -0500, J. Lewis Muir wrote:

> On 5/29/15 5:22 AM, David Holland wrote:
> > Because of these trends, I've been thinking for a while now that maybe
> > it's getting to be time to fork.
> 
> Hello, David!
> 
> I started using NetBSD because of its small base system disk and memory
> footprint, focus on security, support for many machine architectures,
> ability to scale well to large SMP machines, support for a wide range
> of deployments from embedded to server to desktop (it's a big time
> savings to only have to learn and remember how to do something on one
> OS instead of many), and genteel user and developer community.  I value
> all of these things.  (Some benefits I came to appreciate later were its
> relatively long support for a release and its package management system,
> pkgsrc (writing a package once and having it work on all platforms I use
> is a big win).)

[...]

I sometimes think developers get so close they can't see the wood for
the trees. They see all the flaws but fail to see the overall picture.

As someone who struggles to understand code I am happily oblivious of
NetBSD's flaws. What I can say, however, is that using NetBSD is so much
more pleasant than using any of the modern Linux distributions, with the
honourable exception of Crux and Slackware. I tried the latest Debian
and CentOS recently and I wanted to throw up. Talk about over-engineering,
deliberate obfuscation and condescension!

It would be a tragedy of immense proportions to see NetBSD's small
developer pool split up to pursue their own interests in yet another
BSD fork. They have put together a first-rate, unequalled operating
system that really is a pleasure to use. I for one didn't need marketing
in order to find NetBSD; the sheer stupidity of other open-source
operating systems was enough to drive me here. Why the need for
marketing? We are intelligent enough to discover NetBSD for ourselves
without marketing. If it does what we want then we stay with it. Simple.

Is it really worth it putting the future of the project at risk over
these small quarrels that pop up every now and again? Perhaps Ryota
Ozaki could quantify the cost of maintaining this code? If it appears
too costly then should we really go all out to maintain it, given what
Ryota is offering in its stead - a multiprocessor-friendly network stack?
Surely the pros have to be weighed up here, as well as the cons?

Just my tuppence worth. NetBSD is to my mind nearly perfect. Adding a
modern network stack, a modern filesystem and perhaps some MAC
implementation (or do we already have that?) would make it unequalled.
If we need to sacrifice some code along the way shouldn't we be prepared
to do so? People will naturally gravitate towards excellence if it is
provided, no marketing required. Let's keep the developer pool together,
and let's not get all worked up over code if Ryota feels a multiprocessor
network stack can't be easily achieved while it's in place. The pursuit
of excellence is not always immediately rewarding, and some people stand
to lose out for the greater good. That's life. No need for drama; let's
make a mature decision about this and be grateful we still have NetBSD
to work and play with, because, for me at least, 95% of the alternatives
are rapidly heading for the gutter.

-- 
Gerard Lally