future of UNIX and microport

[David F. Carlson]

This is in reference to a recent flame from John Sully's account.  (John,
if you lend out your account again make sure the "flamer" refrains from
scatological material that devalues this news group.  Such postings do none
of us any good!)

To answer the poster, the thought of a bastardized SIII/S7/usoft-kluge *did*
make me choose to support standard AT&T UNIX, no doubt about it.  But as to
Microport's owning sole keys to the kingdom--I doubt it!  Since the advent
of UNIX SV/386 r3.2, Xenix is now AT&T standard and Microport is less than
up to date.  So, given my already stated goal of staying on the AT&T course,
going to r 3.2 soon is a probability.  Why not?  (I'm glad I'm not a XENIX
developer needing to do a mega-port back to AT&T and I thank Microport for
being AT&T up to the recent AT&T SV/386 R3.2.)

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).  We are a rare technical
breed that don't mind working hard to get the job done if tools are present
to do the job.  Source code to "simple" Microport programs should have always
been available for customization.  Source code for Microport device drivers
should have been easily available for modification since Microport obviously
didn't have the man-power to do it themselves.  This would encourage developers
and hacker to contribute to the driver collection (like Mark deGroots excellent
tone generator which I use daily.)  This could have been a hackers paradise:
UNIX and USENET and tons of free software to play with!  Support would be better
since all mods would be tested on many machines and all released back to
the author.  For Microport, thin engineering budgets would be eased by claiming
AS-IS basis on everything except AT&T code (which would be fixed by AT&T "in
the next release...")

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 because Microport wanted 
to support RLL drives or the IBM PS/80 or some other limited utility 
foolishness.  Perhaps I am still clinging to the open nature of CP/M and other
hacker environments like BSD/UNIX several years ago when *everyone* had source.
But I truly believe a market niche exists for such a product.

The other weak spot for me with Microport is as a developer I *need* certain
material concerning the UNIX kernel.  The kernel debugger is useless without
any doc.  Ditto adb(1M).  Certain questions about kernel interrupt structure
I have found no answers for in a year of trying.  (Why do external interrupts
have at times *very* large latencies?  Why do lower level interrupts, ie lower 
than the clock tick, have the potential to stop callout table procedures from 
running for several clock periods?) This is what I *need* for support to get 
my job done.

Microport has my gratitude and would (will) have my support if I can get my job
done in a professional and efficient manner.  Otherwise, no dice.

-- 
David F. Carlson, Micropen, Inc.
micropen!dave at ee.rochester.edu

"The faster I go, the behinder I get." --Lewis Carroll