Path: utzoo!attcan!uunet!lll-winken!ames!pacbell!belltec!dar From: dar@belltec.UUCP (Dimitri Rotow) Newsgroups: comp.unix.microport Subject: Re: Submission for comp-unix-microport Summary: At the risk of getting commercial ... Message-ID: <332@belltec.UUCP> Date: 10 Jan 89 21:34:38 GMT References: <8901081128.AA17414@handel.TOLERANT> <104@john.UUCP> <8710@alice.UUCP> Organization: Bell Technologies, Fremont, CA Lines: 90 [ 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