Submission for comp-unix-microport

Dimitri Rotow dar at belltec.UUCP
Wed Jan 11 07:34:38 AEST 1989


[ Edits ... John sez our UNIX and SCO are stable, Paul sez we're stable
  only 'cause we ignore problems and don't offer support]

> 
> You mean that Bell Tech is now offering support? They didn't used to but
> kept promising they would start doing that soon. Until recently Bell Tech
> did offer NO support at all, just a (30 day?) money-back guarantee.

An old argument.  You'd rather we rip you off like some people do and *not*
provide a money back guarantee?  Paul, could you please explain to me and
the other people reading this group why an absolute "customer must be 
satisfied" money back guarantee is an evil thing?  I always thought it 
was a sign of one's confidence in one's products coupled with a respect
for one's customers.  If you convince me that a money back guarantee is
an evil thing and bad for customers, we'll change the policy.  This is
not sarcasm, I am sincerely baffled why every so often someone gets on
USENET and flames away at a money-back guarantee.


> 
> There is an argument in favor of that. If someone buys a Bell-Tech PC with
> Bell-Tech Unix, why should they try to fix a problem, known to exist with
> say a Compac and risk breaking something that used to work on the Bell-Tech
> PC? Most companies try to offer a Unix that works on ALL AT-compatibles
> (with or without 386), and that is bound to fail. Bell-Tech does not try
> to do that. Right?
> 

Au contraire, we *do* provide installation level support and have a roster
of support programs (pay for play) beyond that.  Better still, we fold 
support for bugs into new releases, just like AT&T does.  Instead of
revving the product every week, we align with major release cycles about 
every six to nine months.  That we can do so is testimony to the intrinsic
stability of the Intel/AT&T product.  

While we *do* use our own PC's in house, the majority of development work
on UNIX System V/386 is being done on Intel and AT&T boxes.   The principle
targets, of course, are Compaq and the other name brand clones.  After all,
they outsell all others by substantial margins.

I believe it is foolish, by the way, to fixate on supporting eight hundred
different systems and peripherals within one release.  After all, we all
only use one system at a time. For the guy running a Compaq, all he cares
about is that the system supports *his* machine.  He doesn't care about 
300 different varieties of X, Y, and Z clones.  That's why he bought a 
Compaq, probably, so he could get some assurance of quality and compliance
with standards.

If your O/S vendor is chasing ten thousand incompatible, poorly implemented
clones then he only has less time to do quality work on mainstream UNIX for
mainstream clones.  What would you rather have: STREAMS, RFS, NFS, X and 
the full panopy of Release 3.2 delivered today in a thoroughly debugged
release for mainstream clones, or an O/S that's a year behind the times
which supports a zillion devices you never will use and don't care about?
Isn't it the job of the clone vendors to make their clones compatible with
industry standards?

Another example is ports cards.  Our release ships without linked in drivers
for our own line of ports cards.  Why?  Because we don't think it appropriate
to clutter the kernel with lots of varient code that people might not want.
We ship our card drivers as an "installpkg" shrink wrap end user diskette
bundled with the card.  I think that's where they belong. 

When you clutter the kernel with device drivers for 80 different devices, you
simply increase the risk of problems and make life different for users. After
all, people are probably going to buy only one type of ports card for any
given computer.  Why should they pay (and you *do* pay, you know) for 
the support of 30 other cards in the kernel?  I know that if you don't know
what you want, it's nice to know you have a roster of cards to pick from,
but do you really want to tie your life to a ports card vendor that can't
deliver elementary software support for their own card?  All the leading
ports cards vendors can now do so.  I don't mean to minimize the benefit
of multiple card support:  if you want that built into your O/S you are
lucky to have a first rate vendor in the form of SCO to buy from.  In 
addition to supporting SCO, we also ship an option for those people who
have alternate needs.

For the record, our distribution supports all of the big name clones.  Some
need to be configured (on board SIO's jumpered correctly, etc) for correct
use just as they would for Microport, ISC, or any of the other releases.  If
you want a different sort of system, you are lucky to be in the Intel
processor world where you have lots of choices for operating systems vendors.
That's why we are so emphatic in our support of SCO in our peripheral line:
we think SCO provides terrific solutions in areas where other releases do
less well and vice versa.  Release 3.2 closes the deltas, but there are still
major differences between product and company offerings which customers can
use to their advantage.

- Dimitri Rotow



More information about the Comp.unix.microport mailing list