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.