Microport Support

[william vajk]

In article <327 at bdt.UUCP>, david at bdt.UUCP (David Beckemeyer) writes:
 
> At one point in the not too distant past I joined the "Let's
> Flame Microport" bandwagon, complaining mostly about their lack
> of response to tech. support issues.
 
> Now I feel obligated to mention that, of late, Microport has
> been very responsive to a problem that I've had for a long
> time (the 2-drive bug).   This is great!
 
> I feel a lot better about the product and the company now.  I'm
> not saying things are perfect yet, but it is a step in the right
> direction as far as I'm concerned, and I think it deserves praise
> and encouragement.

Let's call a spade a spade, even (or especially) in comp.unix.microport.
Support is when YOU have a problem. This means that they help to
educate the user in some manner which makes the existing software
package work as the purchaser needs it to operate when all the 
information is already in the documents. Now that's support, and 
deserves compensation for the time and effort involved.

Support is NOT giving out fixes for bugs in the software. Support
is NOT explaining things which should be documented and sent out
with the distribution media, and the OEM failed to include in the
documentation.

Support is NOT having to call them after paying an annual fee so they
can tell you that you must run divvy first, and then the software will
permit you to run divvy 1, when this should have been in the documents.

I'm glad you feel better about the company now. Did they really fix
anything or did they perform a service which should not have been
necessary in the first place.

Although this sounds a lot like a microport bash (which it is) it 
also applies to other software OEMs. Just because such nonsense is
known to exist in this industry does not make it any less robbery.


Bill Vajk                                              learn at igloo