Path: utzoo!attcan!uunet!l5comp!scotty From: scotty@l5comp.UUCP (Scott Turner) Newsgroups: comp.unix.microport Subject: Re: (Was: Can't backup to floppy) Summary: I'd LOVE to get an X update... Keywords: /dev/tty, console, cpio, Merge386 Message-ID: <434@l5comp.UUCP> Date: 26 Sep 88 11:58:41 GMT References: <913@cygnet.CYGNETSYSTEMS> <425@l5comp.UUCP> <270@belltec.UUCP> <433@l5comp.UUCP> <272@belltec.UUCP> Reply-To: scotty@l5comp.UUCP (Scott Turner) Organization: L5 Computing, Edmonds, WA Lines: 177 In article <272@belltec.UUCP> dar@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@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