[comp.unix.i386] Cooperation

rick@pcrat.uucp (Rick Richardson) (12/13/89)

In article <6087@gssc.UUCP> jdm@gssc.UUCP (John David Miller) writes:
>
>My beef then with the "big three" (AT&T, ISC, SCO) is that the system 
>administration and kernel configuration is all different.  As a software 
>house trying to support all three platforms with an X Server, this
>sucks.  At that level they are all incompatable, not even considering the
>differences in networking software, keyboard/mouse interfaces, and local
>Xlib connections.

John's remarks are similar to my recent remarks as an application
developer (and as an X application developer specifically).  The
problem is not with any one particular UNIX vendor, but with them
as a collection.  After the initial 3.2 port was completed, they
seem to have dissolved whatever communications paths had been put
in place.

The results are beginning to show.  Each new "dot" release shows
greater and greater divergence from the commonality that was
supposedly established in 3.2.  Some examples of this are:

	- You can only depend upon the kd.h graphics modes
	  up to EGA resolution.  Beyond that, each vendor has
	  added modes for VGA, super VGA, and others.  The
	  numbers assigned to each mode are unique to each vendor.
	- The vendor supplied Xlibs contact the Xservers on a
	  local connection incompatibly.  I'm wondering what
	  John's package is using.
	- The system administration varies.  This forces a
	  software vendor into doing their own administrative
	  functions, rather than integrating them with the
	  existing system(s).
	- Undocumented calls are being used in some vendor supplied
	  applications to "lock in" purchasers to that vendors UNIX.

To add insult to injury, I cannot determine a method by making
a documented system call that will indicate exactly whose variant
the application is running on.  You can figure this out in shell,
of course, by rummaging through the filesystem for "telltale signs".

I realize, of course, that much of what is different is documented
as such, and some features that we use are undocumented (but in
the header files).  Much of this is what makes each vendors 3.2 a
more powerful platform for applications while at the same time still
the being the version specific headache that software developers
asked to be relieved of.

As an example, a vendor could have realized that local X
connections vary between the vendors.  Instead of just
using the excuse "but ours is better", and failing a common
agreement amongst the vendors, their Xlib could have tried
all (two, three, four?) methods to contact the server.
There could have been ranges of console graphics modes reserved
as "vendor specific" to prevent assigning a mode number two
or more incompatible meanings.  There could have been more
realization that "system administration" has been the weakest
area in the fight to gain market acceptance of UNIX; that
it is costly to train people to do SA; and that one common
system administration mechanism is a requirement for furthering
UNIX acceptance into non-traditional markets.

The race is now on for V.4.  I hope that this time each vendor
takes the *same* road to the destination, using superior 
underlying implementation, compatibility, service, support,
and pricing to distance themselves from the competition.

Finally, it should be obvious that the primary goal is not to
fight over the division of a limited market between the various
UNIX vendors.  The goal is to expand the UNIX market for all vendors,
thus increasing each individual share.

-Rick

-- 
Rick Richardson |       Looking for FAX software for UNIX/386 ??????     mention
PC Research,Inc.|                  WE'RE SHIPPING			 your
uunet!pcrat!rick|    Ask about FaxiX - UNIX Facsimile System (tm)        FAX #
(201) 389-8963  | Or JetRoff - troff postprocessor for the HP {Laser,Desk}Jet