dar@telesoft.telesoft.com (David Reisner) (08/31/89)
I'm considering the purchase of a 386 system to run 386/ix. So far, I've been unable to see one running anywhere, and I'm a bit concerned about performance. As far as user feel is concerned, how does 386/ix on a 20MHz (or 25MHz?) 386 compare to, say, a Sun 3? I'm particularly curious about the feel of X (or Sunview). Are the systems similarly responsive? Is either system responsive enough for a serious software developer actually using Unix? I'm sure some of you use both systems, and I'd very much like to hear your evaluation. Thanks. -David ucsd!telesoft!dar, dar@sdcsvax.ucsd.edu
john@stiatl.UUCP (John DeArmond) (09/02/89)
dar@telesoft.telesoft.com (David Reisner) writes: >I'm considering the purchase of a 386 system to run 386/ix. So far, I've >been unable to see one running anywhere, and I'm a bit concerned about >performance. As far as user feel is concerned, how does 386/ix on a >20MHz (or 25MHz?) 386 compare to, say, a Sun 3? I'm particularly curious >about the feel of X (or Sunview). Are the systems similarly responsive? >Is either system responsive enough for a serious software developer >actually using Unix? >I'm sure some of you use both systems, and I'd very much like to hear your >evaluation. Thanks. We use Interactive 386/IX on an AT&T 6386 and on a wyse 386 (sh*tty machine, but that's another story), Sun 386I's, and a Convergent 630 MightyFrame which is a 68020 purpose-built unix box running their port of SYS V/R2. In general, I can say that the Convergent is the fastest I/O-wise, the Suns are the fastest in the display arena and the Interactive systems both run a close second. I am extremely impressed with the speed of interactive's file system considering that it is working through an AT bus and in one case, the machine is a 16mhz unit. A 33mhz PC would probably blow both the Suns and the Convergent away speed-wise. Support from Convergent is poor at best. Sun cannot be beat for support. It is nice to have hardware and OS support from the same vendor. As an ISV, we do get support from Interactive. The things we've called about to date have been things that should not be issues. I have been very disappointed at the quality of the ISC release (2.0.1). The install script would not work from drive B: - ISC tech support admitted they'd never tested it from b:. The asy and uucp is mortally wounded. I wrote a replacement uugetty to replace the one supplied so I could trap out the spurrious signals being generated from somewhere. Handling of carrier detect is poor at best and just plain broken at worst. In one case, when we tried to read from /dev/tty01 directly, an ioctl call to put the port in raw mode resulted in the program being dumped back to the shell. No core dump, no warning messages, just a prompt. I have heard from a friend that there is a special way of opening a port and dup()ing the file handle that works around this problem but that's not too hot. Recently, I've replaced the asy drivers with the public domain ones mentioned in this group. This seems to fix most problems but it is really a poor solution for a high priced OS. The backup script was broken - I forget the problem, someone else here fixed that one. The sysadmin scripts are close but no cigar. One must still do administration manually because not all necessary functions are included. The configuration facility and kernal rebuild is difficult to work with mainly because of rather poor documentation. We had to manually edit a configuration file to turn on a second asy port. We had an apparent interrupt conflict when we added a tape drive - fixed with more manual editing. And of course, the problem previously mentioned with using disks with >1024 cylinders. We started out with an Adaptec ESDI controller and switched to the Adeptec 1542A SCSI controller after many hours of wasted time. Here, tech support broke down with ISC pointing a finger at Adaptec and vise versa. The intelligent controller and a large, smart SCSI drive is incredible. Their fast file system really does work. An alarmingly few number of devices are supported and those that are generally are not common or popular units. It is especially annoying to find very revision-specific requirements on SCSI devices like tape drives. I thought that a degree of hardware independence was a SCSI goal. My impression is that the drivers were just sorta hacked together so as to be able to list many supported devices. The VP/IX and X-windows do work, albeit with similiar gotchas caused mainly by poor documentation. And we've found that for serious X applications, VGA-level resolution is really not enough. My biggest complaint, after the obvious bugs mentioned above, is about the documentation. Aside from being somewhat poorly written, it consists of perfect-bound paperback books. You know, the kind that will never lie flat on a desk and shed pages after some use. I generally take these books to the print shop and have holes drilled and the binding sheared off. And the ones I use the most, I run through a magnifying copier and blow the pages up to 8.5 X 11". My greatest plea to Interactive is to give us decent, usuable documentation. I'd love to see it all come in 8.5X11" spiral bound books or something similiar. My conclusion is that if you are going to ship a product you must support, go with Sun. It really is not feasible in a commercial development shop to be wasting developers' hours fixing what should have been caught in alpha-testing. It is very difficult to sell a Unix solution to customers and/or upper management who are used to the reliability of VMS/DEC, with these kinds of problems. If you are strapped for bux and must build a system cheaply, then Interactive is not a bad choice. You can build a minimal system that will still perform well very cheaply if you shop around a bit. I do think Interactive needs to look at its pricing structure. It really makes me mad to see Unix unbundled in the first place. (This is NOT about the 1-2 user vs. unlimited issue.) But then to see a complete Unix system cost more than the hardware it runs on is a bit much. (It has been entertaining to see how many netlanders are so ignorant of economics.) I REALLY hate to see Unix being sold so poorly packaged and so overpriced because it leaves such a gaping hole for imitation operating systems as OS/2 to gain a foothold. I wake up nights sweating at the nightmare of having to support an OS/2 platform :-) This is kinda an ad-hoc list of thoughts. I'm planning to make a detailed post of all my problems and workarounds where they exist. But this list should do for now. John -- John De Armond, WD4OQC | Manual? ... What manual ?!? Sales Technologies, Inc. Atlanta, GA | This is Unix, My son, You ...!gatech!stiatl!john **I am the NRA** | just GOTTA Know!!!
larry@nstar.UUCP (Larry Snyder) (09/02/89)
In article <6750@stiatl.UUCP>, john@stiatl.UUCP (John DeArmond) writes: > I have been very disappointed at the quality of the ISC release (2.0.1). > The install script would not work from drive B: - ISC tech support > admitted they'd never tested it from b:. The asy and uucp is mortally > wounded. I wrote a replacement uugetty to replace the one supplied so Brian at Interactive mentioned that an fix for the uugetty problem in the asc driver will be released next week (the first full week in Sept) and I would suggest you contact him about getting on the update list. I have been having major problems getting my modems to work bi-directional (HST and PEP) on COM1 and COM2 - and have ended up with only ONE modem working dialing OUTBOUND. I was hoping that by getting a smartcard and using the vendors driver I could work around the problem - but no such luck (at least with the Computone and their latest driver - and Digiboard is aware of a problem in their ISC 2.02 driver which is being worked on in-house and should be released by Digiboard engineers within two weeks). > I could trap out the spurrious signals being generated from somewhere. > Handling of carrier detect is poor at best and just plain broken at worst. > In one case, when we tried to read from /dev/tty01 directly, an ioctl call > to put the port in raw mode resulted in the program being dumped back to the I haven't been able to get modems on COM1 and COM2 to both dial OUTBOUND. COM1 works fine (but COM2 just doesn't want to work under 386/ix). > The configuration facility and kernal rebuild is difficult to work with > mainly because of rather poor documentation. We had to manually edit a > configuration file to turn on a second asy port. We had an apparent Let me know about this one - I need my second port. > a large, smart SCSI drive is incredible. Their fast file system really > does work. That is the best thing they have going for them. > The VP/IX and X-windows do work, albeit with similiar gotchas caused > mainly by poor documentation. And we've found that for serious X applications, > VGA-level resolution is really not enough. Does one really need a math co-processor to run X-windows? -- Larry Snyder uucp: iuvax!ndcheg!ndmath!nstar!larry The Northern Star Usenet Distribution Site, Notre Dame, IN USA
palowoda@fiver.UUCP (Bob Palowoda) (09/04/89)
From article <6750@stiatl.UUCP>, by john@stiatl.UUCP (John DeArmond): > dar@telesoft.telesoft.com (David Reisner) writes: > > > I do think Interactive needs to look at its pricing structure. It > really makes me mad to see Unix unbundled in the first place. (This is > NOT about the 1-2 user vs. unlimited issue.) But then to see a complete Unix > system cost more than the hardware it runs on is a bit much. (It has been > entertaining to see how many netlanders are so ignorant of economics.) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I think you under estimate just how ignorant the netlanders are. First off most of the people out here wait until others go out and blow all that money just to see what the package is like. Than they wait to see if the *ignorant* prices of lets say ISC's package or SCO's UNIX drops. In the meantime others check out less expensive packages such as Everex's ESIX or Dells SysV. I really think that Everex has a good chance, their product is much more cost/effective than ISC. If only they can speed their X-windows up a bit. From all my information this may happen real soon. Thier prices are half that of ISC's package. Your right certain UNIX packages are definately *overpriced* to the point that the *end* buyer will not buy the package. If unix manufactures think that devolopers and vars establish these high prices as acceptable to a higher volume market, I think their dead wrong. Var's and developers are very poor salespeople. > I > REALLY hate to see Unix being sold so poorly packaged and so overpriced > because it leaves such a gaping hole for imitation operating systems as OS/2 > to gain a foothold. I wake up nights sweating at the nightmare of having to > support an OS/2 platform :-) I'm sure we all can find problems with any package we buy. But your right if you have any concerns the cost of OS2 verses UNIX as an issue. ---Bob -- Bob Palowoda *Home of Fiver BBS* login: bbs Home {sun,dasiy}!ys2!fiver!palowoda (415)-623-8809 1200/2400 Work {sun,pyramid,decwrl}!megatest!palowoda (415)-623-8806 1200/2400/9600/19200 Voice: (415)-623-7495 Public access UNIX system
cassidy@attctc.Dallas.TX.US (Cassidy Lynar) (09/09/89)
In article <6750@stiatl.UUCP> john@stiatl.UUCP (John DeArmond) writes: > >The backup script was broken - I forget the problem, someone else here fixed >that one. The sysadmin scripts are close but no cigar. One must still do >administration manually because not all necessary functions are included. I think that if you were to purchase the upgrade to 2.0.2 you will find the these things are fixxed, and work very well. >The configuration facility and kernal rebuild is difficult to work with >mainly because of rather poor documentation. We had to manually edit a >configuration file to turn on a second asy port. We had an apparent Once again, I have had very little problem using the kconfig utilities, the documentation supplied was extensive enough to allow even a first time user to configure the kernel in a short period of time through the use of the menus that interactively take the user through, step-by-step. Com2 is pre-configured and works without re-configuring the kernel in 2.0.2. I cannot speak for earlier releases however. >An alarmingly few number of devices are supported and those that are >generally are not common or popular units. It is especially annoying I guess that you did not read the realease notes then. There are more devices supported, than Microport, or SCO. And, then again, they are the MOST popular devices out in the market. >The VP/IX and X-windows do work, albeit with similiar gotchas caused >mainly by poor documentation. And we've found that for serious X applications, >VGA-level resolution is really not enough. The manuals provided for X-windows are execellent. Two thick manuals fordevelopment and one for users. I have found them to be as good as those printed by MIT. >My biggest complaint, after the obvious bugs mentioned above, is about >the documentation. Aside from being somewhat poorly written, it consists Ever tried using the AT&T manuals? They are by far the worst! Even the complete idiot can understand INTERactive's manuals. >of perfect-bound paperback books. You know, the kind that will never lie >flat on a desk and shed pages after some use. I generally take these >books to the print shop and have holes drilled and the binding sheared off. >And the ones I use the most, I run through a magnifying copier and blow the >pages up to 8.5 X 11". My greatest plea to Interactive is to give us >decent, usuable documentation. I'd love to see it all come in 8.5X11" >spiral bound books or something similiar. > >My conclusion is that if you are going to ship a product you must support, >go with Sun. It really is not feasible in a commercial development shop >to be wasting developers' hours fixing what should have been caught in >alpha-testing. It is very difficult to sell a Unix solution to customers >and/or upper management who are used to the reliability of VMS/DEC, with >these kinds of problems. Ahh! At last the obvious... Two things, SUN is great if you have 15-20 thousand dollars to spend on a machine, if not, then ISC is by far the best. Secondly, people whom are used to VMS, and want more power, should by a MS-DOS machine. Unix is a beast of it's own, and cannot be compared in anyway at all to VMS!! Yes, I have to agree, people used to VMS, probably could not be convinced to purchase a UNIX machine easily. If they want multi-tasking, then OS2 is for em. As for me, Unix is the ONLY answer, and not being rich by no means, I chose ISC for the support, the fact that THEY ported AT&T SVR3 from their version, yes I have that right, and the price. >If you are strapped for bux and must build a system cheaply, >then Interactive is not a bad choice. You can build a minimal system >that will still perform well very cheaply if you shop around a bit. Wow, I can't believe that some people are just SO arrogant. I built my machine, and purchased the ENTIRE ISC packages for under 4 thousand dollars. This system, drystones at 6907 (about 5-10% slower than a VAX 8600), has 105 megs of storage, 2 modems, 800x600 VGA, 4 megs of RAM, bus mouse, and a couple of other things. You can't even begin to TOUCH an IBM PS-2 or any other NAMEBRAND for that much WITH the OS... >to gain a foothold. I wake up nights sweating at the nightmare of having to >support an OS/2 platform :-) This I agree with... :-) >This is kinda an ad-hoc list of thoughts. I'm planning to make a detailed >post of all my problems and workarounds where they exist. But this list >should do for now. And I shall watchfor it... Ididn't want to turn this into a flame, but it would appear that it has. If I have offended anyone, than too bad. ISC is a damned good product, and offers UNIX SVR3 to people like me that don't make the hi 5 digit salaries. Also, this is my disclaimer. I am in NO WAY associated withINTERactive. I am just a very satisfied customer. -cass -------------------------------------------------------------------------------- Cassidy Lynar | Behind every good man, is a better Organization? What's that? Irving, TX | computer! ..!attctc!ydisac!cassidy --------------------------------------------------------------------------------
marc@dumbcat.UUCP (Marco S Hyman) (09/11/89)
In article <9273@attctc.Dallas.TX.US> cassidy@attctc.Dallas.TX.US (Cassidy Lynar) writes: > In article <6750@stiatl.UUCP> john@stiatl.UUCP (John DeArmond) writes: > > > >The backup script was broken - I forget the problem, someone else here fixed > >that one. The sysadmin scripts are close but no cigar. One must still do > >administration manually because not all necessary functions are included. > > I think that if you were to purchase the upgrade to 2.0.2 you will > find the these things are fixxed, and work very well. After upgrading to 2.0.2 backup was still broken. At approx line 258 of /usr/bin/backup there is an extraneous line ``done >/tmp/FILE$$'' that needs to be removed. Also, the backup script has a design flaw. If the first full backup is done after generating a new /unix only the files modifies since the /unix was generated are saved! When run without being told what device to use backup, contrary to the comments at the start of the file, selects either /dev/rdsk/f0 or /dev/rdsk/f1. I haven't been able to find a reference to these names in the documentation (although the names are obvious). What is surprising is that the default setup for those devices is not what one would expect. crw-rw-rw- 1 root sys 1, 4 May 22 09:50 /dev/rdsk/f0 crw-rw-rw- 1 root sys 1,133 May 8 15:15 /dev/rdsk/f1 I would expect f0 to be 1,0 not 1,4 and I haven't found any reference to minor type 133 in Interactive's documentation. Makes one think strongly about using GNU tar for backups. And that brings up a question. What _technical_ reasons, if any, are there for using cpio over tar or vice versa. I'm sure this question has started wars in the past but I haven't seen anything for quite a while. --marc -- // Marco S. Hyman {ames,pyramid,sun}!pacbell!dumbcat!marc
cpcahil@virtech.UUCP (Conor P. Cahill) (09/11/89)
In article <105@dumbcat.UUCP>, marc@dumbcat.UUCP (Marco S Hyman) writes: > Makes one think strongly about using GNU tar for backups. > And that brings up a question. What _technical_ reasons, if any, are there > for using cpio over tar or vice versa. I'm sure this question has started > wars in the past but I haven't seen anything for quite a while. I'm not familiar with GNU tar, but one advantage with cpio vs tar on the standard 386/ix is that you can use really big blocking factors with cpio so the tape really screams as it streams. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
tneff@bfmny0.UU.NET (Tom Neff) (09/11/89)
1. I don't know whether the backup(1) shell script Interactive supplies is the same as the one I got from AT&T 3.2, but I haven't seen the bug in question on my system. 2. Having said that, anyone with a working knowledge of UNIX utilities can put together a useful backup proc. I have one that combines full and partial capabilities as well as direct-to-tape or over-the-network; all the same script linked to several different names and it checks $0 for specific settings, that way I don't have to maintain a bunch of separate scripts. I use PAX and TEAM, both posted to comp.sources.whatever and available from the major archives, plus COMPRESS, and I get good results. (No I can't mail it so don't ask - it was done for my firm.) The point is, it ain't hard. 3. The advantages of cpio(1) over tar(1) go away when you have TEAM in the pipeline. The tape streams and screams just fine. -- Annex Canada now! We need the room, \) Tom Neff and who's going to stop us. (\ tneff@bfmny0.UU.NET
les@chinet.chi.il.us (Leslie Mikesell) (09/11/89)
In article <14650@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: > 2. Having said that, anyone with a working knowledge of UNIX utilities >can put together a useful backup proc. Sort of... Can you separately back up the system as installed and your own programs and modifications so that you can sanely either (a) restore an unmodified as-purchased system or (b) add your own modifications back after re-installing a (possibly different) system? Does your partial backup scheme catch files that have been renamed or moved to new locations or copied from somewhere else with the original date intact (it won't if it is based on "find -newer" or "find -mtime"). Can you restore your partial backup on top of an earlier full backup without running out of disk space due to the files that were deleted between the two backups coming back to haunt you? > 3. The advantages of cpio(1) over tar(1) go away when you have TEAM >in the pipeline. The tape streams and screams just fine. They are still somewhat different, at least in the standard versions. Tar only handles normal files and directories, while cpio knows about special files (devices, FIFOS). Tar always uses a 512 byte header for every file and pads the end of each file to a 512 byte boundary. This makes error recovery easier but the archives may be substantially larger than cpio's. The difference goes away if you compress the whole thing, but that tends to make error recovery impossible. GNUtar handles special files and has an option to store the directory contents so that a partial restore can (optionally) delete any files that did not exist at the time the backup was made. I'd like to see something with this option, cpio style headers and per-file compression like zoo. Les Mikesell
madd@bu-cs.BU.EDU (Jim Frost) (09/22/89)
In article <9273@attctc.Dallas.TX.US> cassidy@attctc.Dallas.TX.US (Cassidy Lynar) writes: |In article <6750@stiatl.UUCP> john@stiatl.UUCP (John DeArmond) writes: |Com2 is pre-configured and works without re-configuring the kernel in 2.0.2. I cannot speak for earlier |releases however. You are mistaken. You must hand-enable it and rebuild the kernel. I did this yesterday after a full install, so I'm pretty sure about that. | The manuals provided for X-windows are execellent. Two thick manuals fordevelopment and one for users. I have found them to be as good as those printed |by MIT. The *programming* manuals for X11 are good, but they weren't written by ISC. The installation manual is quite poor, even forgetting some obvious things like which of the X11 disk sets needs to be first, second, then third. There is also no mention of the problems in using a two-button mouse (most X software assumes three), nor does it mention that xrdb doesn't work unless you have the development package (/usr/lib/cpp, anyone?). Lest you think I'm terribly unhappy with ISC, I'm not. The system *works*, albeit with some effort, unlike the Sun 386i did when I first got it. I do really miss the megapixel display of the 386i, though. jim frost madd@std.com