tbray@mprvaxa.UUCP (Tim Bray) (06/16/86)
I have observed lots of questions/comments about the 286 machines and SCO Xenix in this group, answered a couple, (lots of mail failures these days!), and thought I might share some experience. Herewith a terse overview: 1. Experience Development of a medium size (~10 person-year) application to be hosted on the 286 machines, originally IBM, then AT&T. Included heavy use of IPCs, record locking, and other Sys V goodies. Included writing of a device driver for the WD4025 X.25 interface board. Included lots of BIG BIG programs and a methodology that requires big complicated Make files. Developed & module tested on the vax, downloaded to the xenix box for integration via uucp. 2. Hardware The AT&T 6300+ is a faster CPU than the vanilla IBM. This only proves how dependent Unix is on disk throughput - we have a generic 30 Mb drive and the 6300+ is a dog. I hear the Tandon 50-odd Mb drive is much better. The hardware seems reliable, either way - no downtime to speak of. However, bear in mind that you are dealing with a piddly segmented architecture - like a really fast lawnmower with a 2-inch wide swath - more gripes on this later. You MUST HAVE LOTS OF MEMORY, ~2Mb, I think, to do anything significant. SWAPPING IS DEATH! Luckily it's cheap. These machines are noisy. You don't want one on your desk. 3. SCO Xenix The quality of this software is in general pretty good, and improving. The best part is the Sys V compliance. We observed few problems. The IPC's run VERY fast, and the record locking seems reliable, and once again, fast. We have a remote-login style application depending on a server task supporting multiple clients using IPC's, packetized per editing character (return, ^H, whatever), and this runs very fast. Uucp to the vax runs at 9600 baud, no problems. The worst part are the software development tools. The compiler is not PCC, and is buggy. My favourite was 'line 34: infinite spill', caused by trying to get the address of a character pointer in a union in a structure. These were irritating and cost valuable time, but were work-around-able. The linker is apt to ignore certain global variables if they are not initialized. Our most serious problem was with 'make' - our big files with hundreds of source modules with long names caused random insanity on the part of 'make'. We eventually gave up and, since we're source licensed for everything on everything, copied the 4.2bsd make source down and built that - needed a few mods, but runs pretty good. WRONG I LIED, the worst part, once again, is this brain-damaged segmented architecture. If your application is big, you are driven to the 'middle', then 'large' and 'huge' models. Don't ask what all this means, you don't want to know. The bottom line is every time you go up one you take a kick in the head with respect to performance and certain things get buggy. Some smart people who I respect were totally unable to get their application running the large model, they claimed because of memory allocation wierdness, had to break it up into small medium-model multiple processes, which is fine until you have to start one up and it takes 15 sec. to load the process from the teeny slow disk. To think there are still CS profs misleading the innocent with praise of segmented architectures... One nice feature is the multiscreens-at-the-touch-of-a-button switching, which allows you to do several things at once nearly as efficiently as with job control and Emacs. Oh yes, SCO xenix installs smoothly and reliably (except on AT&T 6300+'s shipped in Canada, on which it DOES NOT INSTALL AS SHIPPED - DON'T TRY, IT WILL EAT YOUR DISTRIBUTION FLOPPIES!). 4. Support It's nice that the software runs pretty well, because when it breaks, you're on your own. SCO is ridiculously understaffed. Called up with my 'make' problem, 'all analysts busy', said I'd let them get back to me, 'Oh no sir, they don't have time for that, they're on the phone pretty well all their working hours'. They typically take > 2 weeks to call back. NOW: They are very good if you are a Unix virgin wondering what "tar: can't stat /what/you/want/to/save" means, and especially good if you're having trouble installing. Very responsive about sending out replacement disks when required, too. Anything complicated, you may know more about Unix than the analyst, and when s/he calls back two weeks later, will read the manual to you. Some of the things they said led me to believe that they did not have access to complete source!!! Polite and friendly for what that's worth. Also (not probably of interest to this group) we had problems with their micky mouse policies the areas of payment, site licensing, OEM issues, and so on. 5. Documentation The documentation is good, too, as long as you keep it simple. As far as internals go, the documentation is grossly incomplete and incorrect. The examples of device driver code don't compile. Physio() doesn't work as advertised. Luckily, we have Sys V source (for the vax mind you) and through the good offices of a few people on the net, we were able to dope our way through. 6. Conclusion It's a cheap way to run System V, and the only thing that's unbearably wrong is the underlying 286 architecture. If you possibly can, jump up one notch to a reasonable processor family. If you can't, make sure you have a wizard around so you can solve your own problems, and you should be ok, probably not ecstatic but ok.