karl@ddsw1.UUCP (Karl Denninger) (12/02/87)
The following is a summary of the responses that I have received to date on my inquiry regarding the various Unix/Xenix derivitives in the marketplace for 80386 systems. The entire contents of this article are the opinions of myself and others. ********** If you're interested in the technical side of this, read here. If you're interested in gut reaction and some flaming, see the companion article by the same posting to alt.flame. ********** The verdict seems to be that Microport, while cheap and nice, still isn't stable. This is emphatically *NOT* the case with SCO. We have (since posting this inquiry) obtained SCO Xenix V/386, and are quite impressed with the solidity, not to mention the performance. (See end of this article for our own impressions on Xenix) [Begin included responses - I have maintained identification where possible. Note that these have all been edited severely, if anyone feels as though I've taken things out of context please email me and I'll see what I can do about a correction followup] From uucp Tue Nov 24 05:39 EST 1987 >From obdient!blair Tue Nov 24 05:38:58 1987 remote from chinet [This is the most heavily hacked response, as it was the longest and contained great detail; the best parts are retained -- KSD] =============================================================================== This document lists problems encountered during installation of Microport Sys V/386 unix on our Trillian Power Systems PS/386 computer beginning on 8/30/87. Doug Blair, Obedient Software Corporation, 1007 Naperville Road, Wheaton, Illinois 60187. 312-653-5527 8/30/87 This is the second time this document has been created. The first erased during destructive reinstall of earlier incarnation of unix! >>> Followup: sysviz as shipped does not use HDB networking utilities. This must be corrected. sysadm/packagemgmt/uucpmgmt/modifyport encounters a test argument expected error when attempting to change a tty line from outgoing only to bidirectional. The signifigance of the entries in etc/gettydefs that end in H is not explained. These apparently must be used for uugettys on bi- directional modem ports, but this was only learned through reading the modifyport file while trying to find bug above. What is bdflush and why is it taking so much time? Could not find manual entry for this process? Following normal startup by init in runmode 2, switch to single user mode via init s or telinit s. Then return to mode 2 via init 2. A new copy of /etc/cron is started. This can make accounting files TREMENDOUS! In the event that the break key is pressed during a cu process during the period when cu has sent a command to the modem but the modem has either not yet responded or has not sent the expected response, cu calls its cleanup and mode routines (determined this with cu -d) but never returns from the mode(0) call. Only way to get out of this lockup is to become root on another terminal and do a kill -9 on the root console's sh process. Note the cu processes do NOT go away, even when their parent (sh) is killed. Made the mistake of trying the cu and break condition while in the single user mode - unable to become root on another terminal. Got out with control-alternate-delete reboot. 9/6/87 When using vi with term = at386 on virtual console device, messages written to the status line (such as number of characters in the file, number of lines yanked or put) cause the display to scroll up one line. Subsequent cursor positioning is off by one line, causing MUCH frustration! The cursor is incorrectly positioned in vi (as above) when a line is opened above the current line with the command O. Cursor appears one line above proper position in the file. Above problem also noted when displaying lines that begin with a tab. >>> Followup on this condition - seems to be avoided if you redraw the screen with a control-L before scrolling down below the status line. If you don't redraw the screen the status line becomes part of the display (not the file) and scrolls up, causing the line count and cursor position to be off by one line.... 9/8/87 [Section deleted] 9/30/87 The program /usr/lib/sa/sa2 generates a Floating Exception error message every time it runs. I have about 40 of them now in sys's mbox! 10/15/87 When running vi with the at386 terminal, lines beginning with a tab character displayed at the bottom of the screen cause an extra newline to be sent to the screen, thus double spacing the text. If such a line is on screen, cursor movement will be off by one or more lines, causing unintentional destruction of some displayed text. 10/27/87 After some experimentation have learned that vi problem is NOT present when using vi logged in as root on console terminal with term set to at386, but IS present when logged in as any other user on console. [Most of the merge problems deleted (this was a beta.... except for one episode of a unformatted disk #3 in the kit....)] 11/2/87 Called microport; new copy finally dispatched. 11/4/87 New copy of disk #3 arrived, however it is from limited user version instead of unlimited user version. Proceding with installation anyway. Ordered second replacement copy of disk #3 from unlimited version. 11/4/87 Error message from /usr/lib/merge/dosinstall script reports that: VM_DIED: dossvr: ERROR The VM86 process died. Warning: EGA image was not made. 11/8/87 Each transition from run state S to run state 2 causes another copy of process /etc/fssel console to begin. I have three running at the moment. Don't know what fssel is, but it won't stop, even with a -9 kill for the pid's. Also - don't know if this problem is connected, but now seem to be unable to cu to any of my devices (entry in Device and Dialers files unchanged. >>> Followup on this problem. Aparrently cu problem was not a problem but a correctly reported CANNOT ACCESS DEVICE error. cu could not hook up to tty00 while there was a getty running on ttyM00. This setup has still not been completely explained. 11/12/87 Third copy of DosMerge install disk #3 arrived. It is also from the Limited release instead of the Unlimited release. C'mon guys..... I need a new 386 Dos Merge Beta release 0.2 U Unlimted install disk #3. 11/12/87 Have finally succeeded in setting up a uucp connection to another machine. Will send this file to techs at microport.... Doug Blair From qetzal!upba!ihnp4!cfg!slxsys.uucp!jpp Mon Nov 30 23:15:22 1987 Date: Wed, 25 Nov 87 16:56:57 GMT From: John Pettitt <upba!ihnp4!slxsys.specialix.co.uk!jpp> Message-Id: <8711251656.AA22854@slxsys.specialix.co.uk> To: ddsw1!karl Subject: Re: Unix V/386 -- which would you buy? Newsgroups: comp.unix.xenix,comp.sys.ibm.pc In-Reply-To: <361@ddsw1.UUCP> Organization: Specialix Systems, London, UK Cc: >o Microport (System V/386) >o Interactive (Same) >o SCO (Xenix V/386) >o Bell Tech (?) > >We're looking for the following: > >o Speed -- Performance is very, very important. Speed: Xenix 386 wins - a better compiler and far better device drivers >o Adherance to standards -- SVID is foremost, although utility-level > compatibility would also be nice. SCO claim SVID, all the V.3's should be SVID. At a utility level the V.3 systems have it. >o Reliability -- We cannot tolerate a product that panics or crashes. > We *need* 9600 baud communications ability, 19,200 is desired. SCO Xenix 386 all the way, the drivers a far better and the standard serial driver will manage 1 port at 9600. >o Must handle 'smart' serial boards (requirement above mandates it). We make smart cards ! We support Xenix 386 and uPort and ISC Unix 386 >o Must have a full link kit (ability to handle custom drivers *AND* tune > some kernel parameters); a section in the manuals that is worthwhile on > writing drivers for the particular varient of Unix is even more helpful. Xenix has it again >o MUST (repeat, MUST) handle disk drives which are not in the standard > 15-type set from an IBM AT. Soft configuration (ala Microport SysV/286) > is perfect, but any other configurable solution is also fine (I'm willing > to link a new kernel to change it, for example). What is *NOT* fine is > a scheme which limits you to those types which are in your BIOS. I believe > that this disqualifies Interactive (from their literature), but perhaps > that's not the whole story... ISC will not work with 34 sector ESDI drives ! (SCO if fine, uPort not yet tested) >In addition, ability to run DOS/MERGE in some form is also desired, but not >necessary (we have other systems for that if needed). VP/ix on ISC is good, SCO say VP/ix is 'real soon', merge on uPort is similar but not as polished as VP/ix. We run uPort, Xenix and ISC 386 in house (we have to develop drivers for all of them). Overall Xenix 'feels' better, a bit faster, and a lot more solid. Hope this helps, if you have any specific question please ask. -- John Pettitt G6KCQ, CIX jpettitt, Voice +44 1 398 9422 UUCP: ...uunet!mcvax!ukc!pyrltd!slxsys!jpp (jpp@slxsys.co.uk) Disclaimer: I don't even own a cat to share my views ! From: ihnp4!sw1e!uusglp To: ddsw1!karl Subject: 386 Subject: Unix V/386 -- which would you buy? We have tested the following here at SWBT: o Microport (System V/386) o SCO (Xenix V/386) Run on 3 COMPAQ 386 Deskpro's with 2Meg RAM, Irwin/Compaq 40 Mbyte tapes 40 Mbyte hard disks, and EGA monitor. In addition, all machines have an IBM compatible (XT) serial port. One machine has an ARNET Smartport 4 which is an intelligent asynchronous controller with 4 ports on it. Our current thinking is that SCO XENIX V2.2 386 and 286 are superior to Microport offerings. I suspect that our evaluation criteria may be different than yours. In our environment we need the following: o NO BUGS - SCO is far superior in this area. Both the 286 and 386 versions are reletively bug free. I personally haven't found any but of course some things are reported on the net. - uP 286 version is fairly stable and bug free however the 386 version still needs some work. o Easy Installation - SCO is EASY to install. One of our Microcomputer support people who installed it (read no real UNIX experience) had no trouble and was up from scratch in under 4 hours. - uP is a pain to install. It took two days to install uP from scratch on the same machine. (COMPAQ 386) His biggest problem in installing was getting the disk drives set up properly. o Cross Development Environment - SCO's Development Kit supports MS-DOS development as well as development for 086, 286, and 386 XENIX versions. I can create MS-DOS file.EXE executables on my system. I have also written C code (20K lines) on XENIX which I then moved to an AT&T 3B20 and recompiled without a hitch. The code uses many AT&T System 5.2 section 2 and 3 calls including message queues. No problem. We have also taken the korn shell and some other fairly hairy system utilities from our AT&T source code and ported to the SCO XENIX environment without trouble. - uP is real UNIX 5.2. I would say good enough to use as a development base for other 5.2 boxes. It is lacking MS-DOS development capability. (Excluding DOS-MERGE.) o System Utility Compatibility - SCO is fairly compatible in system utilities but not exact. The same differences that we see on larger machines running 5.2 ports crop up here. I can't think of any examples. - uP has very few differences, if any, here. We are not aware of any differences. o System Administration Compatibility - SCO system administration, while very user friendly, is not the same as that found on AT&T 3B2's. All of the administrator files are there but the shells that many administrators use are very different. - uP administration matches almost exactly 3B2 administration. o 3rd Party Vendor Support - SCO XENIX drivers for additional hardware seems a bit easier to come by. Nothing Scientific. - uP I haven't really looked all that hard. o Speed The rough benchmarks that we ran indicated that SCO XENIX is faster than uP UNIX especially on the area of disk access. This may be due to system tuning problems and as such we aren't ready to say that one is really faster than the other. o Adherance to standards Both vendors adhere to SVID for 2.2. o Reliability I do not have unexplainable crashes on SCO XENIX. It's been running on my machine since January. Don't know about uP - haven't used it consistently. The serial communications capability at 19.2K BAUD - If you buy a good intelligent asynchronous controller (I have an ARNET Smartport 4) then you can run easily at 19.2K. I haven't done anything other than 9600 BAUD - All terminals connected to my machine are connected to Bridge terminals servers which talk to the Bridge terminal server connected to my machine. (run on sentence alert!) These servers are not capable in our current environment of supporting above 9600 BAUD. o Must handle 'smart' serial boards (requirement above mandates it). No sweat - I know of about 4 vendors who supply drivers and hardware for both. The use of smart serial boards are critical. o Full link kit - drivers - tune kernel parameters - manual SCO allows easy linking of drivers as well as tunable kernal parameters. It is fairly straight forward. The manuals have a section on writing device drivers. I haven't fiddled with this. There is an example of a character device driver. I don't have any experience with uP in this area. o Non-standard disk drives Trade offs. SCO allows some degree of fiddling with disk drives but I haven't needed to even look at this since COMPAQ 386's are well supported. This is one area where you definetly make a trade off between ease of installation customization. DOS/MERGE The analgous product for XENIX is VP/ix. We don't have this in our hands yet so there is nothing to say. It is on order but SCO isn't shipping yet. We heard that it would be released around the end of the year. Hold your breath! Larry Pearson Program Analyst - Information Systems UNIX User Support Group Southwestern Bell Telephone Co. One Bell Center Room 24-U-4 St. Louis, MO 63104 (314) 235-7260 Disclaimer - All of the above are the opinions of the author only and do not reflect any policy or opinion of Southwestern Bell Telephone in any way, shape, or form. From ihnp4!chinet!blair Sun Nov 29 13:15:34 1987 To: karl Subject: Re: Your system, Microport, other stuff Message-Id: <8711291213.AA04696@chinet.UUCP> Date: 29 Nov 87 12:13:06 CST (Sun) From: ihnp4!chinet!blair (Douglas M. Blair) obdient runs microport SysV/386 - I selected it on the basis of "they had 386 first" and the price wasn't too bad either! Have never installed another unix system or Xenix system, so I can't really compare how well this one runs. Spent the past decade or so making a living programming radio stations with software I wrote to run on Tandy I's, III's and IV's. Had to invent many wheels, including one of the first multiplexors for a hard disk. Have 4 III's & IV's sharing two hard disks with the SECOND Level IV Products (Livonia, MI) NetFour system. Works well, but not as well as the 386 with unix. Have not noticed real serious problems with microport. My problems can all be attribvuted to the marvelous unix documentation. It's all in there in hideous detail, but you have to know what you want to know before you can figure out where to look up what you want to know, you know? Thanks Doug Blair ..... chinet!obdient!blair or 653-5527\033 [[[[[[ END INCLUDED TEXT ]]]]]] The following is all my opinion (mine, you hear me! :-) Some home-style impressions of the SCO System V/386 Xenix product. We've had it up now since last Friday (day after Turkey day). Installation was a snap, came up on the first try (and stayed up). Very, very easy to install this product... Hardware: Televideo Tele-386, 16 Mhz, 2M 32-bit RAM, 3M 16-bit RAM WA-2 Western Digital controller 1.2M floppy 72M (formatted) Miniscribe 6085 fixed disk 42M (formatted) Seagate ST251 fixed disk Amber monitor, Hercules compatible board Software packages: Runtime Development System Text processing & man pages Foxbase + SCO CGI (Computer Graphics Interface) The entire installation took about 4 hours, including a low-level format. NOTE: The low level format appears to have to be done from outside of Xenix. Since bringing up the system we've been busily recompiling our megs and megs of Microport applications and utility software. I expected to find major differences (from older Xenix systems) and have several problems. *Surprise* - virtually everything I tried has compiled and ran on the first shot, including News 2.11, rn, elm, AKCS (our conferencing/bbs software), ELBS (file udl area for AKCS), MCS/Menus, atc, compress, etc....... The *only* thing that has failed to run so far is 'warp' -- I get an "infinite spill" message from the compiler. My understanding is that this is caused by an overly complicated expression.... will have to look at this. The secret? Tell the makefile (config script, etc) you're a System V Unix box, and everything seems to work fine. Score one for compatibility. Note that the most I have had to do with these programs, in most cases, is change the name of the curses library from '-lcurses' to '-lcurses -lx'. Other than that, tell it you're a Vax running System V and it should work. Performance is very good -- subjectively, it feels about twice as fast as our old Microport SysV/286 release (this is on the SAME hardware, just different software packages). The benchmark numbers do *not* confirm this, which is expected -- the slow memory in the machine is crippling performance. I would love to see this box with 4-6M of 32-bit memory -- and will soon, we're getting another fast board for the system soon. Nonetheless, it feels fast - programs load and execute in a blink, and the system shrugs off the load of a few compiles without problems. RS-232 communications, even through standard IBM serial boards, are stable and don't drop charcters. Incoming Usenet feeds no longer make the machine slow to a crawl. Solidity -- no comment here, there isn't one to make. Everything works, 100%. This is in great contrast to Microport, which would drop uucp connections (missed characters on the serial lines all the time) and crash seemingly at random with a double-panic. Once again, this is on the same hardare that was executing Microport. Finally, a comment on delivery -- SCO had the product here in three days, INCLUDING Thanksgiving. The best Microport has ever done by us is two weeks. Quite a difference. If you can afford it, buy SCO. In my experience with microcomputer Unices, the old adage is seemingly true: You get what you pay for. -- Karl Denninger UUCP : ...ihnp4!ddsw1!karl Macro Computer Solutions Dial : +1 (312) 566-8911 (300-1200) "Quality solutions at a fair price" Voice: +1 (312) 566-8910 (24 hrs)
caf@omen.UUCP (Chuck Forsberg WA7KGX) (12/06/87)
Here are some of my impressions of the two, from the perspective of a developer of comm software (Professional-YAM/ZCOMM/DSZ). Hardware: 386 Intel motherboard, 2.5 MB 32 bit RAM, sometimes 2 MB 16 bit RAM (slooow), 72 and 30 MB drives, AST dumb 4-port (5 total serial ports). Microport 286 is run on an AT clone with 20 MB partition on a Seagate 4051. 386 Xenix: 2.2 Xenix 386 runs quickly and smoothly (as long as you don't let it get near that 16 bit ram). Compiler passes are native 386 and run much faster than the older 286 passes. It's possible to have a make in the background and forget about it, but news-unpack does slow the system. With dumb serial ports, I/O at 19200 bps works well provided TTYHOG doesn't bite. At 38k it is possible to bring down the system with a specific sequence of operations which is very easy to avoid. Despite numerous power blips etc. I don't recall losing any files while running production kernels. SCO warns not to use 16 bit memory on 386 motherboards. I have not seen any problems resulting from this, other than speed. Code running from 16 bit memory behaves like a 4 mHz 286 box. So I only use the extra memory when running VP/ix. VP/ix on SCO Xenix: this emulates a virtual machine. A hacker's delight, you can switch virtual BIOS roms by pointing to a different file. By making a copy of your EGA's rom, you can access 640x480 etc. modes in graphics programs. It will be interesting to see how this product matures. 386 Microport: I only have an early version whose serial I/O was an unmitigated disaster above 1200 bps. Unix Pro-YAM did compile on it without problem. I've heard that Microport 386 Unix has improved since then. 286 Microport: Lacks medium and huge memory models. Unix Pro-YAM is too big for a fully featured version to fit in the small model, and the compiler flips out when large model is attempted. Compiles are rather slow. As far as I know, none of the 386 Unix systems have any understanding of the fact that some memory is fast 32 bit and some is slow 16 bit. Many 386 boxes have a limited amount of fast 32 bit memory which should be used for active text and stack segments, not the buffer cache.