dan@hrc.UUCP (Dan Troxel) (02/03/89)
Posted for a down site: In article <2410@stiatl.UUCP> todd@stiatl.UUCP (Todd Merriman) writes: >Our company is trying to select a Unix (Sys. V) for 386. On the >basis of: I recently did an extensive evaluation of all three of the major PC-AT based UNIX operating systems - SCO, Interactive, and Microport. The results will be published in an upcoming Infoworld article. I have also sold and installed both SCO and Interactive products to my customers. I don't know the particulars of your application but based upon my experience and evaluation I can offer you my conclusions: > SVID compliance All of them claim this. The only way to be sure is to port your application over and test it. All three will more than likely run fine. > Availability of drivers for add-on peripherals SCO has by far the most drivers available either within the product or from third party vendors. Drivers are available for dozens of different types of devices including dumb serial cards, intelligent serial cards, MFM, RLL, ESDI, and SCSI disk drives, a wide variety of tape units, video boards, etc. Interactive Systems also has a large number of drivers available but not as many as SCO. Microport has the least number available. > Support for X-Windows They all have in some form or other, but not completely. It's really all up in the air at this point. I'd say that Interactive leads in this area. > Ethernet-TCP/IP support SCO and Interactive support Ethernet-TCP/IP. Check out Interlan's TCP/IP products for both SCO and Interactive. > Quality of documentation and support Interactive has very little documentation, offering Prentice Hall's ATT UNIX 386 manuals as an option. SCO documentation although improved still needs to be cleaned up and made more professional looking. I liked the documentation from Microport (although it's mostly ATT based). They give you a couple of nice guides which are invaluable to a novice UNIX user. Microport also has the sharpest looking covers of the three vendors. SCO offers the most extensive support plan of all three including a BBS, monthly newsletter, and bug fix bulletin. Microport has telephone support contracts and services available but not as extensive as SCO. Interactive's support policies are an abomination. You must go through your dealer or distributor to get support or updates. And the cost of their latest update (version 2.0) is so high that it could cause their customers to convert over to SCO or Microport. They don't seem to be in touch with the market. > 3rd party software availability The lions share of applications are available for SCO. And with their new version 2.3.1 available with UNIX 386 COFF file compatibility they can't be touched in this area. Microport comes in second and Interactive is a distant third (although their 2.0 version is supposed to be XENIX compatible, it's too early to pass judgement.) > No system call differences with 3B2 and Convergent (shmem(), semctl()) I can't say with your particular application, you'll have to try it out. That's the only way to tell. Don't trust unproven promises. > Up-to-date curses and terminfo All the vendors do a pretty good job of keeping up-to-date with termcaps and terminfo. SCO just recently released a new & larger termcap and terminfo database that includes previously unsupported terminals. And you can always find someone on the net who has a solution to "termcap hell". > Full complement of uucp utilities All three offer HoneyDanBer UUCP utilities. Both SCO and Interactive have a menu driven front end for setting up uucp. >The system in production will be handling multiple communications >sessions with modems and a user interface under X-Windows. I have two 386 boxes in my office, one with SCO, one with Interactive, and a friend of mine down the street has a 386 running Microport. We have no problems with any of the systems. SCO has a nice Telebit Trailblazer dialer in binary. I do suggest getting a smart card for your system. Most of the AT boxe's standard serial ports are best described as "dog meat". Avoid using COM1 or COM2 at all costs. >What are your suggestions? To summarize: I like Interactive 386/ix for it's performance and purity. They have an excellent product but the poorest support. If they would get in tune with the market, offer better support, they could pose a serious threat to SCO. Technically they are the best. SCO has a nice product, especially 2.3.1 but not all their binaries take advantage of the 80386 chip. Try running 'find / -exec file {} \; | grep 8086' and see how many of the utilities are in 8086 binary form. Yuk. But it's a minor gripe because they have excellent support, good documentation, good support people, great update policies and the largest software base. SCO is also getting lean and mean, ready for the long haul. Microport has a good product, almost as pure as Interactive's but they need to provide more driver support. Their prices are the best of all three. If all you want is bang-for-the-buck, Microport wins. Nice people too. All three vendors have happy and unhappy customers. I've heard of horror stories and I've of heard success stories about all three. The ideal or dream UNIX 386 product would be a combination of: 1) Interactive's technical side, 2) SCO's support, marketing and XENIX code, and 3) Microport's prices and documentation. -- Jeff Tye @ Copperstate Business Systems VOICE (602) 244-9391 ncar!noao!asuvax!hrc!swusrgrp!jeff southwest!/usr/group (602) 275-2541 -- Dan Troxel @ Handwriting Research Corporation WK 1-602-957-8870 Camelback Corporate Center 2821 E. Camelback Road Suite 600 Phoenix, AZ 85016 ncar!noao!asuvax!hrc!dan hrc!dan@asuvax.asu.edu
fnf@estinc.UUCP (Fred Fish) (02/04/89)
In article <197722@hrc.UUCP> dan@hrc.UUCP (Dan Troxel) writes: >> No system call differences with 3B2 and Convergent (shmem(), semctl()) > >I can't say with your particular application, you'll have to try it out. >That's the only way to tell. Don't trust unproven promises. Speaking of shared memory with SCO 2.3.1, our application makes heavy use of shared memory. It runs without any problems on all other systems that implement system V style shared memory, including ones based on BSD that have added system V shared memory as an enhancement. However, we occasionally see problems on some SCO systems, that do not appear to be repeatable. We are inclined to believe there may be a subtle bug of some sort lurking the SCO implementation, that we are triggering. I would like to hear from anyone else that is in a similar situation (shared mem code runs fine everywhere but on SCO). We are still trying to pinpoint the problem. It could be our code with some sort of machine dependent bug, so any additional data would be helpful. -Fred -- # Fred Fish, 1835 E. Belmont Drive, Tempe, AZ 85284, USA # 1-602-491-0048 asuvax!{nud,mcdphx}!estinc!fnf