ron%brl-vgr@sri-unix.UUCP (02/10/84)
From: Ron Natalie <ron@brl-vgr> You don't really need the expansion box if your system is like an XT with the 10MB disk in the main cabinet. The ones at UNIFORUM used two XT drives (the basic system takes between 6-8 MB depending on the amount of superflous junk you keep loaded) and they put them both in the expansion box to make things neat. -Ron
isc.net@ism780.UUCP (08/29/84)
#N:ism780:12800007:000:5906 ism780!isc.net Aug 27 14:53:00 1984 The following is a response from your good friends at Interactive to some recent gripes/problems voiced on the net about PC/IX. The original notes are prefixed with ">"; our comments are indented. Note that the "next release of PC/IX" should be available quite soon. >There definitely seem to be some port related problems with PC/IX. Not >only the run-PC/IX-after-MSDOS problem Lee Merrill spoke of, but other >somewhat mysterious conditions where tty0 or tty1 will get into a wedged >state and refuse further commands. An attempt to shutdown at that point >will cause shutdown to sit quietly for close to a minute, print the >message "init: something won't die%s", and then MAYBE finish the shutdown. This behavior is the result of two bugs, both of which have been fixed for the next release of PC/IX. The first is a hardware bug in many of the async cards used in PCs; I believe this has been mentioned before on the net. We have altered the kernel to circumvent the problem. The second is a bug in the kernel shutdown procedure which we have fixed. >One problem that is still plaguing me is a behavior problem with certain >utility programs *only* when used from tty0 or tty1. They're fine from >the local console. Seems that any extra characters entered after >the final c/r of the password prompt and before the system types to you >when using login, su or passwd will kill the port. You can still send >to it and the machine will respond (you'd only know that if it were >right next to you), but no output of any kind comes from the port. Once >you have disconnected, the port is in its famous wedged state and nothing >at all seems to clear it. Only solution at that point is a one minute >shutdown (described above). IBM says its because PC/IX isn't running on >an IBM! What help. > >For example: login: yourid<c/r> password: yourpass<c/r> <c/r> >will kill it every time. Anything entered at the point of the second c/r >after your password, but before you receive more output from PC/IX on >any of the three utilities I mentioned will do it. > >I'm using the MicroLine BabyBlue II board for both ports. It works >flawlessly in MS-DOS. > >Any suggestions? (please mail me directly, and I'll summarize if necessary) > >--Bill Blue {sdcsvax, sdchema, ihnp4}!bang!crash!bblue We cannot duplicate this behavior. It is quite possible that it is also due to the bad async card. Sorry, but that's the best we can tell you! ------------------------------------------------ >I have been "experimenting" with PC/IX since May 1, 1984. My problems >are/were: > >1. I was only able to install PC/IX after IBM replaced EVERY board >in my PC XT. restore -x didn't like my computer! Your hardware was a lemon. Sorry! >2. I could only get connect to work after spending several days >with local "gurus". When I connect to a DEC VAX 11/780, I >can't use vi, but with SIMTERM, etc. I can. Termcap problems? The configuration files associated with connect (/etc/sites and /usr/lib/INnet/connect.con) are really not that hard to figure out, although I suspect somewhat better documentation would be helpful. There was a bug in the connect "talker" program which prevented programs such as vi and e from operating properly when connected. It is fixed for the next release of PC/IX. >3. I had to rm /dev/lp and ln /dev/lp1 /dev/lp to get the printer >to work. We distribute the system with /dev/lp linked to /dev/lp0, which seems the most logical choice. You must have put your printer card in the second slot instead of the first, which obviously means reconfiguring the devices (or /etc/qconfig) accordingly. >4. I can't run more than one or two processed without crashing the >system. > mm filename > temp & > ps -ef >( the above will kill my system, ungracefully) There was a highly unfortunate bug in the shell which went out with PC/IX. It will manifest itself in relatively random ways whenever the shell is running on a heavily loaded system. I suspect that if just the two processes above killed your system, that you must be configured with a very small amount of memory (perhaps the minimal 256K?). The bug is fixed for the next release of PC/IX. However, you can (and probably should) circumvent the problem, at the cost of some efficiency, by executing the following commands: mv /bin/sh /bin/sh.old cp /bin/sh.old /bin/sh chmem +60000 /bin/sh >5. I can't print on standard output the graphics character set while >in connect mode ( e.g., echo "\0333" won't generate graphics ) Same bug as item 2., I believe. >6. usr/games/bj doesn't work! Shocking! Actually, this is pretty surprising, as the level of testing that went into the PC/IX release should have caught this easily. We will look into this bug. >7. You cant type in the password after the login UNTILL the password >prompt appears This is standard UNIX System III. An ioctl with a TCSETAF command is issued just prior to printing the password prompt, in order to discourage people from typing in their password while echoing is still enabled. >8. INed ( e editor ) is the SLOWEST editor I have ever used. It can't >keep up with my typing speed which is 10 words/minute on a good day. Again, you must be configured with VERY little memory. On our 640K systems, e keeps up with anything we can give it; indeed, it performs about as well as it does on a lightly-loaded VAX. Also, keep in mind that while some of the function keys may seem slow, they often perform complex tasks with a single keystroke, so the illusion of sluggishness can sometimes manifest itself. >The bottom line is that I am going to shelve the product and try >Santa Cruze's XENIX. No comment. Have fun. >David S. Green Bell Labs mhuxi!dsg phone 201-564-4468 --isc.net (ima!ism780!isc.net) INTERACTIVE Systems Corp.
gemini@homxb.UUCP (Rick Richardson) (12/01/85)
[Person Wants to know PC/IX&XT vs AT&*NIX vs 6300+&UNIX, w.r.t. doing nroff, C compiles, and uucp] Having owned an XT at one time running Venix 2.1, and having benchmarked PC/IX on an XT, my advise is to stay clear of either if you are seriously considering using nroff or doing software development. They just don't have the horses to do it properly. I'd recommend either getting an AT and Venix SVR2 (or XENIX, as you prefer, the Venix is slightly faster), or if you can wait till next year, an AT&T 6300+ and UNIX SVR2. The AT+Venix SVR2 combination is what I personally use, and I am real happy with the performance doing nroff and C compilation [but don't waste your time with the optimizer]. The Venix SVR2 doesn't have Honey DanBer uucp, but the uucp supplied has been hacked to provide a modem-capabilities L-modems file. -Rick Richardson PC Research, Inc. ..!ihnp4!houxm!castor!pcrat!rer
davidsen@steinmetz.UUCP (Davidsen) (12/12/85)
I have been running PC/IX since early 1984. First on an XT, then a beta test version for the AT, then release 1.1 from IBM. I have also had a chance to test XENIX 1.0 from IBM. Since I have had a chance to run the two systems on two AT's, I have had a perfect chance to compare the systems. I have a copy of SCO XENIX 5.0 on order. For those who want the bottom line, with a copy of each system in hand, I'm running PC/IX on my personal AT system. Some comparisons: XENIX is *much* faster at nroff/troff. In fact, the 6Mhz AT runs about as fast as a lightly loaded VAX 11/780 in that respect. XENIX has made some "enhancements" to the macro packages (our local expert says particularly mm) which can lead to developing input text which won't pass through other systems. This is reason one for my choice of PC/IX. XENIX uses all the memory in the machine, but allows only 64k for any given chunk (array or whatever). Another interesting gotcha is that static arrays may be 64k, but calloc() will only go to 32k (I suspect signed arithmetic in there somewhere). The XENIX compiler runs slower than the pcc compiler in PC/IX, but not much. The compiled programs run considerably faster, and you can compile with a DOS option and produce a DOS version of the program. The gotcha here is that the C compiler is *not* pcc, and on my personal benchmark suite (developed over 21 years as a programmer/software engineer/consultant, etc) fully 1/3 of the programs either did not compile or did not run to completion. This suite has been run on everything from PC's to a Cray2, V7, Sys3, SysV, BSD4.2, etc, without changes, but failed miserably under XENIX. This is reason two for my personal choice not to run XENIX. Configuration of PC/IX is very versatile for things like ports which autobaud at strange baudrates, such as 9600, 1200, 300. XENIX allows groups for the lower speeds, but doesn't seem to have the ability to pick a group of speeds and parity selections. The selection in PC/IX is done using a text file with entries such as "speed=9600,300,1200", which is easier to remember than the coded entries in XENIX. Reason three for PC/IX, but I realize that most people don't have this problem, and therefore the solution is not of value. PC/IX gives reasonably explicit directions for writing new dialers. They provide dialers for a number of common modems, but allow easy user installation of new dialers. Although most people will not have to support three or four new modems (bet you wish you did), the new 2400 and 9600 baud modems require handling of additional status messages, etc, back from the modem. Another reason for me to go with PC/IX. PC/IX also allows easy installation of printer filters, including multiple modes in the same physical printer being treated as separate printers. I haven't had to do this yet in XENIX, and have no idea what is entailed. The queueing system also allows producing queues for troff, format and uucp for remote printing, etc. It is quite versatile and easy to use, and most of the setup is done by setting cleartext parameters in system files. Although neither o/s provides support for additional serial ports from IBM, XENIX drivers are available for the XT if you look hard, and readily for the AT. I hope to try the MA systems 2.5 MB +2 serial in 1986. This is just not available in any way for PC/IX. XENIX requires a minimum of 15MB on a 20MB disk in an AT, while PC/IX may be run in as little as 7MB for a complete system, or 3MB if you just want to run applications and mail. XENIX (as from IBM) won't work properly on a 32MB hard disk. It installs, won't use more than 20MB of the disk, and fails to boot with a CRC in a non-existant sector. This was on three drives tried in two machines. If booted from floppy, the 20MB system runs fine, but takes three partitions of the disk. PC/IX has worked on every disk size tried to date, including 20 and 32MB, and a few oddballs. I have seen patches from CORE (as I recall) which allow use of other disk sizes. Installation is *not* trivial, and the instructions were for one odd disk size with no general info on how to do disk X. At power-up, XENIX requires two keystrokes to put it into multi-user mode. This means that if a power failure occurs, the system must be visited by a live human being. PC/IX checks the file system and goes into multiuser mode by default (although this may be modified). This gives recovery after power failure and also allows system startup by people you would *never* let make a decision, such as young children and computer haters; "see the red switch on the rihgt side? push it UP! Thank you". One PC/IX system was inadvertently cycled five times by electricians, and rebooted correctly each time. The XENIX system on the same feed required manual intervention to recover the file system (but did not lose any useful data). XENIX has all of the standard archival programs: tar, cpio, and dump/restore (renamed to backup/restore). PC/IX is notably missing tar. XENIX also has vi and more (the program more), although PC/IX has INed and l, and both more and less have been posted to net.sources, so the features may be user installed. The vi editor is more standard, but INed is perhaps a bit easier to use (this is more a matter of religion than a technical issue). INed can not be used from a remote terminal (a marketing decision, the version on a VAX can) while vi will work remotely. For all the ease of configuration of PC/IX, the XENIX method, while harder to use and less flexible, looks closer to my generic Sys3 documentation. The XENIX manuals are easier to read, but somehow always leave me looking for just a bit more detail. The PC/IX manuals are standard UNIX manuals and are best described as "concise". The XENIX manuals win hands down for the starting user. The installation of PC/IX is a snap. It takes only one partition, of any size, does not need to be any particular partition, and can be run without the manual by those able to read the menus and questions. I have installed XENIX at least eight times in the last six months, and finally wrote a cheat sheet to avoid having to read the manual every time. This is one place where I favor menus rather than commands, since a complete installation is (hopefully) not something you want to do often enough to learn by heart. Finally, if you have to live with the DOS world, the file transfer to/from DOS disks and partitions works well in PC/IX, with the exception of singlesided DOS disks, which don't seem to write correctly. XENIX has given me "learning experiences" with a number of floppy formats, and the one time I tried to write the DOS partition of the hard disk, I had to reformat the partition. The XENIX commands for DOS interface seem somewhat better chosen than those in PC/IX, but neither is a joy to use. XENIX offers the visual shell (vsh) and csh in addition to sh. PC/IX has only sh, but offers TEN+(tm?) as an option (for more money) which seems to be slightly better. There is some form of vsh alailable in public domain, for those who like that sort of thing (another religious matter). Finally, the price of the complete systems is about the same, but the PC/IX system is not unbundled, while XENIX is available as three parts: UNIX, C, and word processing. Power: for the power hungry single user, the AT with an 80287 (an perhaps a fast clock) is a good alternative to sharing a mini. Every benchmark I have run, both my own and such things as Dhrystone, have indicated that an AT at 8MHz is faster than a VAX 11/750 in every CPU category, and although slower in disk access, is still faster in total time for things like compilation, nroff, awk, grep, etc. No version of UNIX for the AT currently supports the "huge model" with objects > 64k, but I am told that this will happen in XENIX eventually. XENIX runs in protected mode, while PC/IX runs in real mode. For the person using UNIX tools for software development or applications there is little difference in the performance of the two systems. The larger memory of XENIX may be offset by the non pcc compiler. FORTRAN is available for both systems, but since I have no XENIX version I will not comment. ---------------------------------------------------------------- Disclamer: these are my personal findings and opinions after several years of running UNIX on PC's. My work with VENIX and Coherent has been too casual to report, and there may be some non-obvious features of either or both systems which I have not used or reported. These finding are mine alone, and do not reflect the findings or opinion(s) of the General Electric Company. -- billD (..seismo!rochester!steinmetz!crdos1!davidsen) (davidsen@GE-CRD.ARPA) "It seemed like a good idea at the time..."