Subject: Re: Why people know what FreeBSD and OpenBSD are, but not NetBSD
To: Michael Graff , Frank Warren <clovis@home.com>
From: Miles Nordin <carton@Ivy.NET>
List: netbsd-advocacy
Date: 12/07/1999 00:29:09
On 6 Dec 1999, Michael Graff wrote:

> the masses simply do not know about us to even ask that question in
> most cases.

This may sound a little depressing, but I don't think it matters what the
masses know.  The masses have never chosen their operating system--it has
always been chosen for them.  In the future, this will be even more
pronounced--the masses won't even know what operating system they're
using, much less be able to choose it.

Let's look at how things stack up now:

 o Couch-users:              use Wintel junk, WebTV, N64

 o Power users, sysadmins:   _some_ use Linux.  Linux, FreeBSD, u.s.w., 
                             compete for these people.

 o Contributing developers:  There are so few of these, they usually
                             aren't even counted.

I suggest that, since there are so many more couch users than power users,
we forget about the middle category entirely.  If we're not going to
bother getting $20-a-pop for CD's they buy straight from TNF, we may as
well forget about them and wait for them to find us.  Their only real
purpose is to pay money that funds development.  They're people like
me--who don't contribute code, and who don't exist in large enough numbers
to pose any real competition to desktop OS's.

Let's instead look at the four free operating systems as competing for
_developers_, rather than users.  In that sense, I want to write code for
whatever OS provides the most pleasant development environment.  
Particularly if I work on a *BSD, I'm relatively certain that if I write
something truly earthshattering, either the others will pick it up, or
they'll get laughed at--vanity points for me either way.  I suspect NetBSD
provides an unusually happy development environment.  We do a lot of work
with the toolchain and have much more complete online documentation than
Linux.  The ability to run on Hardware That Doesn't Suck is a big plus for
a low-level developer, too.

Or, maybe I want to contribute to a BSD not to inflate my ego or augment
my resume, but because I want to become a better programmer--because I
actually _like_ to write code for some strange reason.  In this case, I
will want to work with, and produce, the best code possible.  It's clear
who wins here, too--the best teaching system--NetBSD.

If we're going to boast-for-users, I think we should pursue it from this
angle. In a general sense, we could talk about the clean-code philosophy.  
If the argument gets down to specifics, we can talk about the toolchain,
the kernel debugging features that recently came up on the other list, the
clever way we write drivers to work on multiple platforms, the superior
.mk files in the build system and the package system, the high quality of
documentation and standards-compliance of the libraries, the guaranteed
availability of IPv6 and SSL in all releases, a sane and educational build
procedure that can get you to working Mesa libraries and a custom-tweaked
X server if you so desire.  To a large extent, I think we already do this.

We also ought to make a plea for app developers, since many of the same
development features that make NetBSD attractive to contributors make it
attractive to people developing 3rd party software, too.  These people are
generally well-respected and well-known among other Open Source Fanatic
Power Users, and I suspect they often turn into OS contributors, too.  As
an app developer, you're completely free to choose whatever Unix you like.  
You could care less how many others are using it. If you develop a GNOME
app, there's nothing NetBSD-specific about it.  You can even sell it
running on Solaris if you want.

Likewise, NetBSD needs to be the foremost pedagogical operating system.  
A lot of universities seem to be using Linux now, which is downright
silly. Source code hard to extract, build procedures needlessly complex,
documentation is lacking, the development environment is flakey and
inconsistent, the toolchain is often out-of-date, version-skewed, and
unpatched from what Cygnus provides.  The <include> files are a typical
glibc mess, the kernel is a notoriously poor example, and there is a
paucity of textbooks available which discuss the internals of the OS.
Linux is a _horrible_ teaching operating system.

CU Boulder is even further behind the times--the educational labs here use
a mix of Solaris, NT, and an old Debian release.  I do not have a single
OS available to me on campus where I can, for example, go to a certain
directory and look at the source code for yacc There are pictures of the
Daemon everywhere and a big ``4.4 > 5.4'' poster down in our little
dungeon, which suggests that they used to use BSD and then ditched it!
Rediculous bastards!


> I think NetBSD is at a crossroads, and indeed has been for some time
> now.  

I also think NetBSD is at a crossroads, but not because it's losing
developers or getting left out of the Linux (and now Linux/FreeBSD)
limelight.  Rather, for one simple reason:  The PC is on its last legs.


Consider, what would happen if at exactly 2am US Mountain Time tonight,
the PC platform completely died out.  Linux, in spite of its many
so-called ports, will never run well off the PC because it lacks the the
management, the code base, the sane build process, the architecture and
philosophy, and the contributing developers to write-and-maintain any
useful notPC code.  Trust me on this one, guys--it was an awful mess on
the Alpha, especially compared to our port. FreeBSD can't ``compete'' off
the PC, because there's no reason not to just start with NetBSD instead.

Is this an unlikely situation?  Well, see for yourself.  The PC's biggest
and only consistent advocate is in very serious legal trouble.  Vendor
relationships are in jeapoardy, and it has just become clear to what
extent these relationships were artificially prolonging the platform's
lifespan.  Some very large vendors (like Compaq and Sony, for example) are
in a better position than ever to abandon the platform and replace it with
something faster and cheaper.  Compaq has the Alpha, while Sony has a MIPS
license and considerably broad internal expertise--so-called PC's out
under the Viao branding that barely look like PC's.  Who was it that said
the Intel CPU _doubled_ the power consumption of Sony's little
laptop--that is, used more power than the screen backlight?  This doesn't
fly when you're trying to compete with real laptops using real CPU's.  
I'm sure Sony would love to ditch the Wintel Junk.

The PC's biggest competitor (Apple), and MS's biggest enemy (Linux) are
both doing incredibly well.  Public opinion and investment dollars are
both stronggly in their favour.  The usual reason for buying PC's instead
of Mac's that also run Office 2000--that the kids want to play their
games--dissappeared a few months ago.  Even Microsoft themselves is
flogging their notPC OS, Windows CE, like a donkey in a thunderstorm.  
And the last issue of PC Magazine had an iMac on the cover.

Long-term intellectual investment in the PC is looking horribly dismal,
and indeed Sun, Netscape, Oracle, iD all seem to be simply drumming their
fingers waiting for the inevitable collapse of the loathsome beast.  Sun,
for example, is willing to give you _for free_ a comforting mock-up
alternative to your Windows 95 desktop, start button and all, on one of
their Sun notPC boxes.  It runs inside a sort of ``compatibility window,''
so you can wean yourself away from the disgusting hellhole and realize all
the wonderful possibilities Outside the StarOffice Window--but, all this,
slowly, comfortably.  StarOffice has a built-in window manager and is
obviously begging to be run on a set-top box.

All the traditional hardware busses of the PC have been completely
undermined by Open Hardware alternatives (PCI, USB, IDE, FireWire), so
peripherals are now machine-independent. All the relevant chipsets are
just itching to be used with notIntel, notPC.  The cost advantage of
Wintel crap is basically gone, thanks to the recent proliferation of cheap
cleverly-planned mass quantity consumer systems that, with diabolical
planning-ahead and new low-cost external busses, are made to accept only
external expansion stuff--set-top boxes, game consoles, iMac's.

You have heard before why PC's were stupid and didn't deserve to survive.
Yet nothing happened.  What I'm telling you now, is signs that they are
_already dying._  I have not proposed one hard fact of why PC's suck.
I've only cited evidence that the platform is becoming unmarketable.  And
once it does, NetBSD becomes the only serious, modern, open-source 
operating system available.


I will agree with the general clamouring so far as to say that I still
think SMP support is critical.  But, I disagree so far as that I think the
ability to run SMP on any Intel Xenon board is _completely irrelevant._
Why?

 o Well, first of all, it's a flash in the pan.  In another year it'll be
   gone.  We can't affort to support halfassed efforts on the part of 
   companies with insecure financial futures, like Intel for example.

 o The added scalability is minimal.  We are talking 2 or 3 times the 
   performance at most.  This will barely buy you half a year on 
   single-processor systems, or even less if you'll accept Alpha or 
   PowerPC hardware.

   I suspect Yahoo wouldn't even be interested in SMP boxes for this
   reason.  They have literally _thousands_ of PC's doing a single job.
   If things get slow, they buy 500 more.  They already need more than 
   two PC's worth of performance--a single SMP PC wouldn't cut it.  so 
   why buy SMP at all?  The _last_ thing they want to do is get bugged by
   individual PC's dropping off like flies more than they already
   do, because they use some kind of experimental poorly-tested
   ``super-fast'' chipset.  I'm sure they run through PC's like kleenex 
   over there as it is.  They may as well buy cheapass single-CPU junk and
   keep replacing it with faster stuff when it dies.  That's the whole 
   _point_ of Wintel junk.  The _point_ is antithetical to SMP boxes.

 o Relevant MP is in the high-end workstation arena (where our kernel 
   also runs).  These use more than four CPU's, and have cleverer bus 
   and memory architectures so that the extra speed actually gets _used_.
   In this arena you can get more than 2x or 3x the performance of the 
   single-CPU equivalent, but with Intel's architecture and price
   bracket, you can't.

 o Future MP is going to be in putting multiple chips on one die, which I 
   don't expect to see from Intel because:

    o It is too innovative for their inane marketing strategy in which 
      single CPU's come in single shrink-wrapped boxes for single 
      outrageous prices and plug into single MP-incapable card slots.
    o It is poorly supported by the OS's that run on their hardware, such 
      that there would be no interest in MP on the low-end Wintel market.
      And the low end is just the point of multiple-cores-per-die.
    o Intel has other uses for all the extra space on their dies, like 
      supporting a 15-year-old instruction set for example.

   What's more, the point of this multiple-chips-on-one-die MP probably
   isn't well-realized by FreeBSD and Linux, since I expect it's going 
   to be marketed mostly as a real-time thing.  but, I tried to get into
   this argument before and failed horribly because I don't know enough
   about it, so i'll leave off at that.

Please don't take this personally if you own an Intel MP board.  I'm right
there with you.  I was responsible for a PA8000 box once, and I really
_did not_ like the experience of standing in sandals and a purple T-shirt
over the shoulder of a tie-choked briefcase-laden HP tech replacing this
rediculous CPU card with gigantic metal tubes that he practically pulled
out of a 2"-thick lead-lined case handcuffed to his arm--the thing was
worth more than I was--under a service contract I didn't even know we had,
in response to an error message I didn't even understand.  He was working
after-hours and telling me about where he had to go next and how long it
would be before he got to eat some dinner and kiss his wife.  I was like,
``Wow, your life really sucks.  But, you know what?  You're not welcome to
work on this box during the day--we paid $100,000 for it, and as far as
I'm concerned you HP folk are bastards for selling us a box that crashes
even _once_, and if you want the $1M that's in our pipeline for obtaining
more ultraexpensive HP junk, then you better get this pile of metal
working _right_goddamn_now_.  Or, uh, that's what i was told anyway.  So,
back to work, Mr. HP Lackey.'' I would much rather argue
what's-wrong-with-gandalf with a few buddies and make a quick trip to
Fry's over lunch with $150 in petty cash, than have to shout at overworked
fieldreps twice my age in order to earn my salary.  All I'm saying:

Given the larger industry-view that we, as users of the so-called Most
Portable Operating system, are priviledged to enjoy, these
multiple-processor Xenon boards are _completely_ _irrelevant_ _toys_.


So, what do we need?  We need SMP that can compete with the svelte
low-latency stuff that's going to show up inside the embedded systems
kernels that are going to become NetBSD's chief competitor. We need SMP
that doesn't have a global lock like the stuff in FreeBSD, and that,
unlike Linux, is MI and easily portable to new embedded chips as they show
up.  We need SMP that we can point to and say, ``If you use our kernel, in
spite of the fact that none of your customers will realize you're using
our kernel, your hardware will run tangibly faster and achieve lower
latency.''

This is a plausible reason to choose an embedded OS.  No one cares whether
it supports an AudioWizard 2000 card or does multilink PPP over V.35,
because if you need that you just pay someone to write it.  but if you can
sell a company on good modern computer science research that makes their
cost-conscious hardware feel faster, you win.  because hard-core research
is not for sale at any price.  If you're Sun or Digital, that's good for
you--you can write it yourself.  But if you're the MagickDial Internet
AdWizard company, you have to buy it from someone who's already done it.

This sort of thing has been a NetBSD strength from the beginning, and it
remains something no other modern OS does as well as NetBSD--we run real
fast on the low end, slow CPU's, small memorys.  We keep things simple and
have good VM.

IMHO, we do not need this SMP _now_.  but, we do need it soon--that is, we
need it before consumerjunk companies that use multiple-core RISC chips
start shopping around for their embedded OS.

NetBSD has already proven its ability to pull in a major completely-redone
kernel subsystem (UVM), sanely and gradually get it onto all the ports,
and then _remove the old code_--in a way that I haven't seen in any of the
other free Unixes do so far.  It was every bit as cool as watching Apple
ditch the m68k.. I'm not sure anyone else is up to the challenge of doing
this right.  Integrating first-rate SMP, not quick-and-dirty scheduler
hacks, looks to me like the key feature that will save the BSD codebase.

I'm sure people have decried the death of the BSD codebase for
years--``C++ is the only relevant programming language of the future,'' or
``in the future, all operating systems will be microkernels written in
Modula-3.'' ``And will ship in pink boxes with fuzzy balls glued on top.''
We've learned how to spot silly little pet projects and managerial
white-paper hacks.  but SMP is different.  To me at least, it looks really
ominous.  Consider this hand-waving explanation.  The RISCish multiple
pipeline idea is very clever.  With a deviously-constructed compiler and
machine language, you can order the instructions so that the CPU can run
four independent instructions at the same time.  Nice.  But, if you
actually _have_ four threads of execution ready to go, there's no need to
be deviously clever--you've got four independent instructions in your hand
for free.  MT is thus not a way to use more than one CPU, but rather a
change in what sort of Thing we think of as a ``CPU,'' what sort of
characteristics are relevant in defining ``performance.'' I'm sure Intel
and AMD's method of emulating the archaic ix86 instruction set is
deviously clever, too, but it's still glaringly stupid when you look at
the bigger picture.

Granted, that explanation is woefully uninformed, but it hints at a
significance that the Wintel and Linux people usually don't seem to
``get.'' Definitely, programming languages, inexpensive CPU designs,
classes of software (multiplayer first-person games with sound, real-time
audio/visual communication over the 'net), research (distributed
computing) all begs for multiple CPU's.  Without good MT architecture, BSD
will no longer be plausibly competitive in consumer applications, and will
cease to be interesting for research.

I think if NetBSD crashed profusely and ran on only half the PC's
currently for sale, but had a clearly superior SMP project with obvious
potential and left us UVMishly optimistic about its eventual completion,
it would be in a much more imposing position as far as the Industry's
future is concerned. The problem is, I have no idea how to bring this
about.  I don't know who's going to pay for it, or how to make sure it
doesn't fall to the ``SMP curse.'' Fortunately, I think we have a little
bit longer to figure this out.  Also lucky-for-us, we run on Alpha and
SPARC boards that are MP and yet Don't Suck.

As for other ``marketable'' directions, set-top boxes are going to need a
browser and a JRE.  but, this is a pathetic joking pittance amount of work
to do compared to the SMP stuff.  I'm sure lots of people would love to
have a non-sucking (non-Mosaicscape-based) browser and an up-to-date JRE,
but lack thereof is not going to wake me up dripping cold sweat at 4am.
The first vendor who wants that stuff can fund a couple weeks' work and
poof--problem gone.  The way I see it, from a technical standpoint we've
got a huge amount to be proud of (and relieved about), and one big scary
problem, a problem that no one else has really solved either.


NetBSD is not ``dying'' or ``losing critical mass.'' The codebase is not
outdated falling into disrepair.  This is not a bad time to start using
NetBSD. It's not going to dissappear any time soon.  It's just that
recently a lot of other similar but fundamentally inferior projects are
getting gobbs more attention than we are, and not for much more reason
than that the total amount of attention is very limited.

NetBSD simply has yet to execute the last few critical projects that will
make it clear why people have been working so hard on it for so long. We
saw the same thing happen with the PPC chip.  Then it happened with with
Linux.  Then we saw it happen to FreeBSD.  A lot of hard work quite
suddenly got a lot of attention, even though it had been going on silently
for years. We have different goals, are doing different work, and will get
different attention--but there's nothing second-rate about any of it.

It's not reasonable for us to expect the media to show the same level of
insight and future vision that we do.  They don't have the talent or the
precedent for it. But for god sakes there's no reason _we_ have to believe
their suggestive ignorance.  We know the inside story.

-- 
Miles Nordin / v:1-888-857-2723 fax:+1 530 579-8680
555 Bryant Street PMB 182 / Palo Alto, CA 94301-1700 / US