by homeworld.redbacknetworks.com with SMTP; 13 Dec 1998 17:01:11 -0000
	by shell17.ba.best.com (8.9.0/8.9.0/best.sh) id IAA08974;
	Sun, 13 Dec 1998 08:58:49 -0800 (PST)
From: Todd Whitesel <toddpw@best.com>
Message-Id: <199812131658.IAA08974@shell17.ba.best.com>
Subject: Re: Something I noticed on the Yahoo site
In-Reply-To: <367033D0.65500F29@trisignal.com> from jb at "Dec 10, 98 03:49:20 pm"
To: Jb@trisignal.com (jb)
Date: Sun, 13 Dec 1998 08:58:49 -0800 (PST)
Cc: netbsd-advocacy@NetBSD.ORG
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

>> say that when Wintel finally starts to seriously crack, NetBSD would be the
>> best choice to enable a hugely competitive hardware market, by giving
>> software vendors a superior middle-ground O/S that performs well, runs
>> everywhere, and is very uniform across its ports.
> 
> Interesting could you go into more detail?

The non-x86 desktop market (in America at least) is basically Macintoshes and
UNIX machines from Sun and HP (I'm ignoring AIX, maybe they'll just go away). 

The trend in Mac and Sun hardware over the last few years has been to adopt
pieces of the modern PC architecture (PCI, USB, IDE) that have finally become
"good enough" to represent no or minor loss of technical leadership versus
proprietary technologies. This allows them to cut prices and stay competitive.

In principle, there is no reason why you could not go shopping at Fry's, and
in the motherboard aisle find a rack of Pentium II compatible modules with
all kinds of different RISC chips in them. But in practice, there are a lot
of barriers, and all of them are derived from the Wintel duopoly value chain:

  1. to execute the BIOS (x86 code) you must emulate an x86 or port the BIOS.
  2. to initialize PC video cards you have the same problems as with the BIOS.
  3. whatever O/S's are popular must be ported to all these different CPU's.
  4. app developers need source-level compatibility across all O/S ports.
  5. app developers need lots of pre-fab middleware (MFC,COM) on all ports.
  6. app developers need comprehensive development tools, also on all ports.

The first two points should explain why I am interested in OpenBIOS. Turns
out they are more inclined towards OpenFirmware than I thought, but they
don't expect O/S's to call back into the BIOS once they are booted, which
is the main thing I was afraid of. The important thing is to get lots of
MI drivers written in C and available for other OSS projects to leverage.

The next two items are clear selling points for NetBSD in its present state.

The last two need work on pretty much all of the free O/S's right now, maybe
not in _our_ eyes but certainly in the eyes of commercial ISVs who are used
to being spoiled by the Wintel value chain. For the middleware I think we
can rely on the ISPs and MIS directors who are establishing beachheads with
Linux (http://www.softwareag.com/corporat/solutions/entirex/linux/default.htm
for DCOM is one example).

>> I'm not assuming that this will happen on the desktop -- that actually seems
>> less likely as time goes on.
> 
> Why?

What I was thinking of is that x86 clone machines keep getting cheaper and
cheaper every quarter, yet Intel manages to push x86 SPEC numbers up with
the desktop RISCs at the same time. This keeps all the desktop-related
vendors from straying too far from Wintel -- but look what's happening to
them in the sub-laptop mobile computing market, where power consumption,
software reliability, and code bloat are such high concerns that Wintel is
at a fundamental disadvantage.

In spite of all the money Microsoft has poured into Windows CE, it still
hasn't taken off. Sure, it will be a major player as long as Microsoft keeps
pouring money into it, but the real effect of WinCE has been to legitimize
the embedded and mobile computing markets in the eyes of the public, and also
to touch off a round of consolidation within them. It hasn't done much else.

But it _has_ taught a whole generation of the more adventurous Wintel dudes
that there are lots cleaner architectures out there than x86, and that there
are infinitely simpler APIs out there the minute they quit slurping on pablum
from Microsoft.

So what may actually happen is this: the vanguards of Wintel app development
tool up for WinCE on (say) StrongARM, get disillusioned with Microsoft, and
then realize that they could be developing for the Corel or Funai boxes, or
maybe even license the same hardware and set out to become the next WebTV.

The other side, high end, is currently dominated by Linux clusters, or will
be very soon, as far as I can tell. Everyone up there is either academia,
military/science, or render farm -- people who are used to doing without
"value chain" products like cushy GUI development tools. They won't fund
this sort of stuff that the desktop vendors think they have to have.

> I am in the process of deciding whether to install Linux or NetBSD on my
> Amiga. I have read the www pages in www.netbsd.org/goals/index.html and

Linux for 68k? Wow, I hadn't actually heard of that yet. Amazing...

>If you could add some information on the differences in the different Un*x
>flavors and NetBSD (say Linux vs. NetBSD or FreeBSD vs. NetBSD). It would help
>beginners such as myself make an informed decision about what is best for their
>needs.

This is often a touchy subject. Here is my take on it (solely my opinions):

Linux is not really Un*x, but it plays one on TV. Linus started out writing
his own replacement for Minix (which was written by a professor to help teach
Unix concepts) and later made it emulate Un*x once it became obvious that
loads of software would be ready-to-run on it if he did so. Linux' "include
everyone" model has been very successful, but it has also produced a fair
amount of chaos along the way. The nice part is, support for new hardware is
usually limping on Linux almost immediately, and bubbles into the various
distributions at a reasonable rate. Linux support for PC's is excellent, but
for Alpha/SPARC/PowerMac/ARM things are much more informal and unpolished.

FreeBSD is really Un*x, but it has been exclusively x86 PC clone based until
recently, and only supports a few RISC chips at this time. Like Linux, FreeBSD
allows parallel development of features with overlapping functionality, which
lets them use more developers faster, but also bites back in the form of code
that eventually needs to be reworked later. Unlike Linux, FreeBSD manages its
parallel development within one packaged distribution (Walnut Creek CDROMs).
This means you get good turnaround times on solid support for new PC hardware.

NetBSD is also really Un*x, supports more platforms than anything else, and
tries its damnedest not to unduly favor any of the platforms that it supports.
NetBSD carefully avoids duplicated effort, which is arguably most efficient
but can cause projects to be delayed by the structural dependencies between
them. When NetBSD adds new hardware or facilities, they are usually available
on all applicable machines immediately, or can be enabled with minor patches.
If you use obscure hardware or lots of dissimilar hardware, NetBSD is your
best, and except for OpenBSD probably your only serious choice.

OpenBSD originally began as a "security development branch" of NetBSD managed
independently by Theo de Raadt, who operates out of Canada to avoid US export
restrictions on encryption software. I don't know what he will do now that
Canada has signed that fascist encryption treaty the US Gov't has been
leaning on the rest of the world to sign. Lately the OpenBSD project has
come into its own, probably because Theo works on OpenBSD full time (it is
his primary source of income). I get the impression that OpenBSD leads in
security fixes but lags on most everything else due to manpower limitations
(they are the smallest of the three *BSD projects).

There is copious sharing of code and technical info between all four O/S's,
because it often is the only way to obtain documentation for all that
undocumented proprietary hardware out there. There are occasional issues
caused by the copyright differences, but as long as people are willing to go
to the effort to write their own code using the other source file as if it
were a printed reference manual, nobody sues and everyone benefits.

Todd Whitesel
toddpw @ best.com