future of UNIX and microport

[Norman Kohn]

In article <661 at micropen> dave at micropen (David F. Carlson) writes:
>As to helping Microport, yes, their phone reps take lots of sh*t they don't
>deserve:  AT&T bugs in the SV 386 r3.0 code they ported from are numerous
>and potentially showstopping.  However, Microport took a market strategy that
>I never quite understood.  The bulk of their customers are hackers and a 
>smattering of professional developers (like myself).

The economics of supporting an enterprise like Microport must be
daunting.  I remember having similar concerns about Aztec, before
its expansion to MSDOS (and my move to SVAT, so I could have a
more standard environment and dispense with overlays).

Every sale creates a potential support obligation for the indefinite
future, and without cumbersome accounting the cost of the support
(yes, it costs $$ to have someone intelligent sit by the phone) must
be borne by future sales.  A successful software house is thus a sort
of ponzi scheme, in which sales must grow exponentially if support staff
are to be paid out of current revenues.

I stuck with uport because, others' complaints to the contrary, it has
been the only vendor of a large, complex software system with truly
available technical people.  No, they couldn't resolve all apparent software
butgs... but in a system as large and complex as unix, running on
various hardware configurations, that's not a surprise. (I still haven't
dared try again to add swap space on a second hard drive...)

>I believe many of us where disappointed to find simple bugs (like everex tape
>driver crashes or floppy disk multiple access hangs) that would take 5 minutes
>to fix (and post diffs!) but were never attended to ...

Tape support was less of a problem, of course, back in the days when Bell
didn't fancy itself a software competitor.  Yet Bell's technical staff
is so protected you'll resolve to change vendors if you ever try to reach
them.  Even the sales staff are hard to reach, except by appointment.
Think about it, though.  Releasing source might well have been a better
strategy. Yet it would have been bound to trigger support calls from people
who'd messed up the driver, or forgotten that they'd tinkered with it.
And the source might contain proprietary code that uport isn't licensed
to release.

>because Microport wanted to support RLL drives... 

Ah, but you should see how SV386 flies with RLL!

Are other versions really any more solid?  (My pet bug: Bell XTC
tape driver seems to crash the kernel randomly during a tape backup
shell script.  Happens about 25% of the time, only since upgrade
to 3.0e (386) and subsequently adding RLL, 2nd hard drive, and
2nd Digiboard.  I don't see how I'll ever find the problem, but maybe
it'll disappear the way it came.  Only happens with tape access,
so it's unlikely to be in uport's lap.  Bell, as usual, piously asserts
"we don't support uport" and smirks... 

For SV386 I suppose that there's always the option of purchasing kernel
and runtime licenses from Interactive and using the remainder of the
386 port from uport.  gcc, which runs nicely under uport, is probably
the compiler of choice.

For controlling support costs and maintaining availability, how about
making the uport bbs into something useful?  Its present form is 
primitive, and there's no practical way to search for discussion of
specific problems.  The tech support staff must spend its days
reinventing the wheel.  (At one time, uport reportedly had the policy of
starting all new programmers in tech support... a reasonable way to break
in programmers, but also a guarantee of green staff on the other end
of the line.)

-- 
Norman Kohn   		| ...ddsw1!nvk!norman
Chicago, Il.		| days/ans svc: (312) 650-6840
			| eves: (312) 373-0564