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