(Was: Can't backup to floppy)

[Scott Turner]

In article <272 at belltec.UUCP> dar at belltec.UUCP (Dimitri Rotow) writes:
>I agree with you 100% that if someone desiring extended phone support, custom
>bug fixes, etc, gets sold a product which does not include such services, 
>and is not informed of such, then a bad thing happened.  If that's what
>happened to you, I'm sorry, but I can tell you that no salesperson here
>(especially not Al Holmes) would do so deliberately.   There is, by the way,

I don't think it was deliberate, both of us were chasing W.G.E.'s not unix's,
sort of like buying a VCE and being told you need some tapes/batteries to
go with it and saying "Fine, toss 'em in too." And everyone forgets to check
the warranty. :)

>I know you got UNIX from us only to run the Blit card, so it's a fair comment
>that you didn't have much choice in liking our support policy for UNIX if you
>wanted the Blit.  To remedy that, we ported the Blit software over to 386/ix
>and to SCO Xenix (on their pre-release with STREAMS).   The only reason we
>didn't do Microport is that we have the resources to target only one
>"generic" release, and if you can only do one you pretty much have to do
>the Intel/AT&T/Microsoft ("IAM") product.  I hear that future Microport
>releases will be able to accept device drivers, etc, done for the IAM product
>unmodified. 

Yeah, well the big beef turned out to be that the blit card drivers work
quite well with Microport System V/386 3.0e... Your unix wasn't required.
Your drivers ALSO work with the 2.2 release. I guess I should amend that
statement real quick though, everything except the new kd.o (to handle
using the blit as the system console) that is. The other trick is that the
order of modules in the system.btb is WRONG for Microport. You have to use
Microport's system.nse and tack on the blit/X modules at the right places,
then it works fine.

And for all I know the new kd.o might work if the system was configured
minus DOSMerge/386... (kinda tough to check)

>Well, fixing bugs IS support of the highest order.  In terms of the Adaptec,
>you're being unfair to Jennifer by quoting only part of the issue.  The
>Adaptec, sales literature from Adaptec notwithstanding, is *not* the same
>as a Western Digital standard AT controller.  That's why they have on board
>ROMs: to fool DOS into thinking it is a real WD clone when it's not.  by

I guess I have a different idea of what support is, to me support is answering
questions about how to setup a direct UUCP link, or how to create a new user
account... You know R.T.F.M. and O.E. type issues.

Frankly you can be superman when it comes to system integration and still
hit a bug that will stop you DEAD, like a yacc compiled with the wrong
#define for memory size. These are issues that can ONLY be addressed by the
unix vendor. These are the kind of issues I expect support on with any unix
product I use/integrate/sell.

I expect to field the R.T.F.M. questions from end users once I integrate
your product into a product I sell.

As for the Adaptec, you're just plain WRONG. The ROM is onboard to provide
a really neat formatter and device drivers for using their pre-DOS 4.0
solution to using a >32mb disk drive. They also provide a rather nifty
P.O.S.T. routine that BUILDS you a drive descriptor so you don't have to
play burn-the-BIOS games to provide support for your architecture drive.

That's it. The controller IS register compatible, I've used SEVERAL other
register level programs with it (not to mention Microport's driver :) and
they were all quite happy with the ACB2322. Your unix is the first software
product to cough over it.

>Hey, if integration were easy anybody could do it!  :)

I'm all in favor of a little sweat, if system integration weren't a bitch it
wouldn't be any fun. :)

>Well, I can't fault you for having fun at our expense, but don't misconstrue
>what we legitimately say.  The "option" you otherwise wouldn't have is the
>ability to get direct access to the Intel/AT&T/Microsoft code without being
>*forced* into paying for either a) proprietarizations or b) technical support
>that *you* don't want.  Now, if you don't want that deal, fine!  Go buy 

Well I guess part of the problem is that yall threw ALL the support out the
window with this policy. I agree that people like myself don't want R.T.F.M.
level support, but we DO need support in the form of bug fixes/information.
If we have to buy R.T.F.M. level support to get bug fixes then what's the
benifit of your unix policy then? I suspect yall might want to consider adding
a level or two to the support options, you know like:

		1. New unix user (so new s/he thinks a shell is something
		   you find at the beach and can hear the ocean in.)
		2. Experienced unix user new to System V/386 (Knows what a
		   shell is, but has no idea what /usr/lib/uucp/Systems is.)
		3. Your basic guru-to-be who doesn't have a System V/386
		   source license and thus must get yall to fix bugs/throw
		   switches.
		4. Experienced System V/386 user, using know compatible
		   hardware, or level 3 user back to buy more copies.
	
>It will look bad to those who want support bundled into the price they pay
>initially.  It looks good to those who don't want to pay for support they
>don't need.  What's so wrong with giving people a choice?

It would be great if they DO have a choice. But we've already flogged that
horse...

>Scott, don't get me wrong: we're not uptight about legitimate bashing (did
>I really just say that? :) )  but we're real concerned about misunderstandings
>with our customers.   That's why the length of the responses, despite their
>tendencies to act as lightning rods.

Well we had a first class "Cool Hand Luke" on this one. It didn't take me long
to piece together that "I weren't gettin' no support 'round here." :)

I also noticed that you totally skipped my comments about the X10R4 received
here being incomplete. Alan decided to ship me a 3.1 update since it was
supposed to come standard with X, ergo it should solve the problem (as well
as maybe seducing me away from Microport with support for more than 62
defects. :) But the 3.1 update received was JUST the "base" 3.1, not even
a C compiler! X10R4 is still limping, and I hate to make a fuss with X11R2
just around the corner, but then X11R2 wouldn't BE just around the corner
if this had been dealt with quickly, sigh.

Your comments about more pix on the latest dist tape just make matters worse
if you know what I mean. :( I don't care if money has to be handed over at
this point. If there's one thing I've figured out about '386 unix integration
is that if you want something NOW rather than a free a couple months from
now, ya have to *PAY* (sometimes dearly), to have it happen.

Although I have noticed an "Embarrassment Quotient" to update pricing... The
ACB-2322 BIOS upgrade from Rev. A to Rev. C was free, the ACB-2322 Microcode
upgrade from Rev. A to Rev. C cost $10. The difference? After wolfing off
about how *superior* the ACB2322 was because it could handle drives with
more than 1024 cylinders their super-duper formatter only went to 1024
cylinders... They were QUITE happy to fix that little problem! :)

Now in it's dark hour, the X10R4 as delivered won't fire up uwm *as described
VERY early in the "Intro to X" manual), Bell fumbles the ball (or should I
say update?)

I'll pay, but I might also add that we have some interesting pix around here
as well. Just got a GIF to X10R4 8 bit per pixel bitmap format convertor
going... (If you want it and the IFS Explorer [Boy, does that fern look
GOOD at 1kx1k!] maybe we can work a swap :)

>- Dimitri Rotow	
>
>
>PS - There are some spiffy new images in the X image tape we distribute, if
>you haven't gotten a copy recently. 

The postscript interp posted to Usenet is almost working. It draws the fishes
demo supplied, but alas some kinkiness with floating point has things stalled
right now:

DeltaX = enow.x - ehere.x;

DeltaX!1.0
s
enow.x/ reveals: 567.1027
ehere.x/ reveals: 46.1027
DeltaX/ reveals: 1!!!

It's like the damn subtraction didn't occur, sigh...

Several ray tracers are also almost not quite there, also grounded due to
floating point problems...

Me thinks the '387 code generator in the 386 PCC is not quite ready for
prime time. There have been no end of floating point related problems, the
good news is that they're with the Microport System V. (At least as far as
Bell is concerned that is. :) I suspec they lerk in the heart of the Bell
compiler as well though.

Let me express my gratitude for your not doing another white-wash-it-and-
hope-that-does-it posting and taking the time to reply to my questions
in a helpful manner. Now if I can just get someone to deal with the X
problem...

Scott Turner
scotty at l5comp -or- uunet!l5comp!scotty

"Are you ready for the *X* boys?" (Sung to the popular tune)
		-Great tunes to hum while reading X documentation