carson@point.UUCP (Carson Wilson) (12/18/90)
I'm trying to build an Intel 80386-based Unix machine for programming, and am having a difficult time determining which of the various i386 Unix vendors to support with my purchase. As anyone shopping around for Unix system software soon discovers, there is a war on. At least two or three manufacturers are actively competing for the desktop Unix market. It appears that the Santa Cruz Operation (SCO) has grabbed the largest piece of the market so far, but is facing intensive competition from Interactive Systems Corporation. AT&T and Intel also market Unix software for the i386, but seem to be less aggressive in pushing their product lines. There is also a product named "Xenix." Xenix was originally Microsoft's tradename for its Unix clone. The name has now been licensed to SCO and probably other firms. From what I understand, Xenix is a less sophisticated, but also less expensive alternative to desktop Unix. Xenix lacks some of the capabilities of Unix, but requires only about 1/2 the memory and disk storage Unix needs. According to a salesperson at SCO, though, Xenix is "on the way out" as a system standard. I have generally found plenty of sales and support people who are happy to "inform" me of the relative merits of their software over that of other firms, but I haven't seen any discussion of this on Usenet. I'd like to know your views on: 1) Relative merits of Xenix vs. Unix. 2) Experiences of end users with SCO, Interactive, and other firms. The i386 Unix market is evolving quite rapidly. I feel we should discuss this topic far more actively while we still have a chance to determine the direction desktop Unix will take. If we allow market forces alone to decide which standards succeed, we may be disappointed in the long run. -Carson Wilson [carson@point.UUCP]
tneff@bfmny0.BFM.COM (Tom Neff) (12/18/90)
Warning -- this took its own reins and turned into a flame. In article <276d312d-8aecomp.unix.i386@point.UUCP> carson@point.UUCP (Carson Wilson) writes: >I'm trying to build an Intel 80386-based Unix machine for programming, and >am having a difficult time determining which of the various i386 Unix >vendors to support with my purchase. Try defining what you want to DO with your system, then checking to see who offers what you need to do it. Individual value added UNIX vendors do differ in terms of which options they support, which they bundle and so forth. Right now it's not hard to make an informed choice if you read the literature. >As anyone shopping around for Unix system software soon discovers, there >is a war on. Oh please. Until they start issuing gas masks at COMDEX, the only thing a 'war' means to the average UNIX consumer is that pricing is more attractive. That's good news, but functionality is still more important. > At least two or three manufacturers are actively competing >for the desktop Unix market. More like six or seven. Crack a magazine! > It appears that the Santa Cruz Operation >(SCO) has grabbed the largest piece of the market so far, but is facing >intensive competition from Interactive Systems Corporation. AT&T and >Intel also market Unix software for the i386, but seem to be less >aggressive in pushing their product lines. This is like a Computer Newsflash for October 1988. Dell and Everex are going crazy. Intel bought Bell Tech and is putting full page spreads in the trade mags. AT&T has always sold hardware to institutional accounts and supplied standard software to run on it. >There is also a product named "Xenix." Xenix was originally Microsoft's >tradename for its Unix clone. The name has now been licensed to SCO and >probably other firms. From what I understand, Xenix is a less >sophisticated, but also less expensive alternative to desktop Unix. Xenix >lacks some of the capabilities of Unix, but requires only about 1/2 the >memory and disk storage Unix needs. According to a salesperson at SCO, >though, Xenix is "on the way out" as a system standard. Did I say 1988? I may have been too generous. >I have generally found plenty of sales and support people who are happy to >"inform" me of the relative merits of their software over that of other >firms, but I haven't seen any discussion of this on Usenet. In what, the past three days? All we do is beat this subject to death with a posthold digger six times a month until Hell freezes over! > I'd like to >know your views on: > >1) Relative merits of Xenix vs. Unix. > >2) Experiences of end users with SCO, Interactive, and other firms. Is that all. See below. >The i386 Unix market is evolving quite rapidly. Did it say that in the WEEKLY READER UNIX Supplement, or what? > I feel we should discuss >this topic far more actively while we still have a chance to determine the >direction desktop Unix will take. If we allow market forces alone to >decide which standards succeed, we may be disappointed in the long run. Excuse me a moment. <SCREEEEEAAAAMMMMSSS into paper bag> >Ahem< OK, all better. My gentle suggestion is that it might be better to get some kind of a ****ing clue where UNIX 386 is at today (1990 for readers with calendars) before worrying overmuch about thumping the nasty ole market forces and determining "direction." In the meantime, shut up and buy something. You want the best deal in town? Buy one of the SVR4 developer upgrades. For $400 to $800 you get a full developer kit including NFS, RFS, ANSI C, debuggers, Open Look, TCP/IP etc., plus a little buglist a blind man could work around. Some of them claim to want your 3.2 boot disk in exchange. If nobody you know has a backed-up original they'll part with, just send the money and see if you don't get the software. These people aren't in business to refuse your money. Apologies to the readership for the flame portions above -- something rang my fatuity meter.
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (12/19/90)
I used Microport System V/AT for a year or so, and from a hacker's point of view, it was a great inexpensive system. Currently I'm running ESIX Revision D and again, from a hacker's point of view it's a great relatively inexpensive system. For business purposes, however, based on the experience with these two systems, I don't recommend getting UNIX from either Microport or Everex (ESIX). Microport had fair documentation but terrible quality control. Everex has a fair implementation (except for one or two things that don't work at all) but the worst documentation I have seen for an operating system (based on the two manuals included with what I bought -- you can buy more manuals, which I suspect will be of the same miserable quality). For business purposes I recommend SCO. Although I personally haven't used SCO Xenix, I did use Microsoft's Xenix on a number of different machines in the past, and it was more stable than System V/AT or ESIX. I also uses AT&T's System V (a. UNIX PC, sort of System V Release 2 with Release 1 utilities; b. System V Release 3 on an AT&T 3B2). Although it was stable and relatively free of bugs, the quality of documentation was standard AT&T, which means no indexes, poor organization, and nonexistent information about system administration procedures. The Xenix documentation was little better. For good documentation and powerful features, you have no choice but to try to find a BSD derivative (anything except Ultrix). Right now I use SunOS at work and find it to be relatively stable and moderately well documented. AT&T's SVR3 seemed to be to a little better debugged than SunOS, but it also did far less and the documentation was pretty bad. Unfortunately nobody sells BSD for 386-based machines. Sun used to sell SunOS for its own proprietary 386-based machine, but phased it out. Maybe you could get a used machine with the software. Also available, still in beta-test (though they call it a "production release") is System V Release 4. I would wait another year, but by then it may be the best choice available. It has about 80% of the good features of BSD plus most of System V Release 3. So, although the picture looks pretty bleak right now for UNIX on the 386, things should improve when SVR4 stabilizes (and, I hope, becomes cheaper). -- Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (12/19/90)
In 2812@cirrusl.UUCP I wrote:
>The Xenix documentation was little better.
I meant to say:
The Xenix documentation was a little better.
English is a strange language.
--
Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com>
UUCP: oliveb!cirrusl!dhesijfh@rpp386.cactus.org (John F Haugh II) (12/19/90)
In article <2812@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: >For business purposes I recommend SCO. Although I personally haven't >used SCO Xenix, I did use Microsoft's Xenix on a number of different >machines in the past, and it was more stable than System V/AT or ESIX. I've used SCO Xenix on this machine (a 386) for 3 1/2 years, and it works very well. The original purpose for this system was to develop business software for clients who would eventually be running SCO Xenix. For clients with no on-site technical experience, SCO Xenix is probably your best bet. It's sad that SCO UNIX is in such a sorry state. There are no "industrial strength" UNIX ports out there, and I was hoping at least SCO would have something with all the newer features. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org "While you are here, your wives and girlfriends are dating handsome American movie and TV stars. Stars like Tom Selleck, Bruce Willis, and Bart Simpson."
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (12/20/90)
In article <18842@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: | I've used SCO Xenix on this machine (a 386) for 3 1/2 years, and it works | very well. The original purpose for this system was to develop business | software for clients who would eventually be running SCO Xenix. | | For clients with no on-site technical experience, SCO Xenix is probably | your best bet. It's sad that SCO UNIX is in such a sorry state. There | are no "industrial strength" UNIX ports out there, and I was hoping at | least SCO would have something with all the newer features. I hate to agree that this is the state, but having tried a number of the 3.2 flavors, I'm convinced that if you don't need some feature which is in 3.2 which is not in Xenix, and NFS is the only one which comes to mind, your reliability will be better with Xenix than and 3.2 I've tried. I will also note that as a group the V.4 ports seem far less prone to actual crashes (kernel panic) than any 3.2 port. They are all very rough in lots of ways, but that's not one of them. This is my view of where 386 desktop unix is going, the new versions are cheap and solid, and the low cost of memory takes the curse off the larger size of the kernel. New products and market directions may cause this prediction to be wrong, but at the moment that's the way it looks to me, from a prospective going back to V7. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
tneff@bfmny0.BFM.COM (Tom Neff) (12/20/90)
In article <350@metran.UUCP> jay@metran.UUCP (Jay Ts) writes: >I am *scared* of SVR4!! When/if my clients have to upgrade, they will have >to add at least 4 Mb of memory and probably suffer a performance degradation >as well. (Someone please tell me this isn't really true!) And it won't >markedly improve the functioning of their existing software, either. I'll tell you it's not true if you'll tell us why you thought it WAS true. For equivalent functionality -- note that phrase please -- SVR4 looks about 20% bigger than the comparable SVR3v2.2 system. But remember that SVR4 adds a lot of functionality! Yes, if you blindly take the install tape and say 'give me everything', you're looking at a lot more disk and memory consumption. But that's up to you. Not everyone needs three networks, all of Open Look, six different file systems and so forth. Anyway, memory is so damn cheap these days. My only beef is that, for a UNIX release packing so many additional files, SVR4/386 doesn't have better support for huge ESDI disks. It chafes to have to throw away 100MB of my Maxtor just to keep upder 1024 cylinders. I would like to see this addressed in a future rev. -- "Just when we finally got good at this, we \_i_/ Tom Neff run out of planets." - a Voyager scientist --[o]-- tneff@bfmny0.BFM.COM
jay@metran.UUCP (Jay Ts) (12/20/90)
In article <2812@cirrusl.UUCP>, dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: > Everex has a fair implementation (except for one or two > things that don't work at all) but the worst documentation I have seen > for an operating system (based on the two manuals included with what I > bought -- you can buy more manuals, which I suspect will be of the same > miserable quality). Nonsense. AT&T's manual set for System V/386 r3.2 (published by Prentice Hall) work fine for ESIX. You can order them from you local bookstore. I *like* working it this way; my clients don't have to shell out extra bucks for manuals they won't even open, and if they or I want to obtain extra copies of the manuals, we can get them with no hassles, and in any quantity we want. I am running ISC, and one of my clients is running ESIX. They have more documentation than they want to see, and I have all the documentation I want/need. Whereas ISC and SCO have "enhanced" (read: added bugs to :-) AT&T UNIX, ESIX has left AT&T's code relatively alone (read: left the bugs in :-). Judging from postings in this newsgroup, ESIX has fewer bugs or other problems than ISC 2.2 or SCO UNIX. In working with ESIX, so far I haven't run into any problems that I couldn't work around or solve either on my own or with the help of ESIX tech support. They are responsive *and* helpful both over the phone and by email. > For good documentation and powerful features, you have no choice but to > try to find a BSD derivative (anything except Ultrix). > Right now I use > SunOS at work and find it to be relatively stable and moderately well > documented. My ESIX client is an office automation environment. They don't need a GUI or networking. Their 386 ESIX system supports 7 users and cost them about $5000 TOTAL, including application software. For their needs, any machine running a BSD-derivative (i.e., Sun, Silicon Graphics) would be a waste of money. > So, although the picture looks pretty bleak right now for UNIX on the > 386, things should improve when SVR4 stabilizes (and, I hope, becomes > cheaper). I am *scared* of SVR4!! When/if my clients have to upgrade, they will have to add at least 4 Mb of memory and probably suffer a performance degradation as well. (Someone please tell me this isn't really true!) And it won't markedly improve the functioning of their existing software, either. I think you've just been spoiled by using SunOS :-) Jay Ts Metran Technology uunet!pdn!tscs!metran!jay
woods@eci386.uucp (Greg A. Woods) (12/21/90)
In article <2812@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: > Everex has a fair implementation (except for one or two > things that don't work at all) but the worst documentation I have seen > for an operating system (based on the two manuals included with what I > bought -- you can buy more manuals, which I suspect will be of the same > miserable quality). I can't speak directly for the ESIX implementation, but from most accounts I've heard, it is very solid, and quite efficient! As for ESIX documentation, they did the right thing. Let the publishers publish and the programmers programme. Standard SysVr3.2/386 doc's from Prentice Hall are all you need for ESIX beyond the rather wonderful release notes, etc. I've seen from Everex. > For business purposes I recommend SCO. Although I personally haven't > used SCO Xenix, I did use Microsoft's Xenix on a number of different > machines in the past, and it was more stable than System V/AT or ESIX. > I also uses AT&T's System V (a. UNIX PC, sort of System V Release 2 > with Release 1 utilities; b. System V Release 3 on an AT&T 3B2). I've re-booted more SCO XENIX (286 & 386) systems because they've hung or paniced than almost everything else I've ever used, combined! The most reliable system I've used is my AT&T 3B2. Even our shoddy old ISC 386/ix 1.0.6 is more reliable than any SCO O/S I've used. The scariest O/S I currently have access to is the AT&T 3B1 3.1.5.4, with Starlan. It trashes things like wtmp and panics for no obvious reason. I've not used SCO's UNIX 3.2 enough to know if it is any more stable, but because of other issues I strongly recommend against using it. > Although it was stable and relatively free of bugs, the quality of > documentation was standard AT&T, which means no indexes, poor > organization, and nonexistent information about system administration > procedures. The Xenix documentation was little better. EXCUSE ME?!?!?! What do you call the permuted index? I call it the best damn index ever invented! Even the SysVr3.0/386 Guide's have good (normal) indexes for each section! XENIX documentation always scared me because of the re-organisation. I was never sure if something had been moved, or removed. > For good documentation and powerful features, you have no choice but to > try to find a BSD derivative (anything except Ultrix). Right now I use > SunOS at work and find it to be relatively stable and moderately well > documented. AT&T's SVR3 seemed to be to a little better debugged than > SunOS, but it also did far less and the documentation was pretty bad. Hmm... It's real hard to determine your prejudices when you say BSD doc's are great, one paragraph after giving some praise to XENIX doc's. I find the BSD doc's (i.e. Sun's or the USENIX version) slightly clunky, since they are attempting to hang on to an organisational methodology invented for a doc set that would easily fit in your slim briefcase. I find the SysVr3.x doc's to be extremely good. The 3.0 stuff was missing some info about new features, though a lot of that stuff was in the release notes for particular implementations. The 3.2 doc's fixed my major complaint of splitting the User's Ref. and the Admin's Ref. > So, although the picture looks pretty bleak right now for UNIX on the > 386, things should improve when SVR4 stabilizes (and, I hope, becomes > cheaper). Hmm... I thought SysVr4.0/386 was quite stable already! It is quite cheap from most current suppliers (eg. Dell and UHC). From what I've seen of the Prentice Hall 4.0 doc's, they are terrific! If only Prentice Hall would publish a version in/for 8x11 binders, and publish update sets and "bug" fixes. I'd pay the extra money! -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP ECI and UniForum Canada +1-416-443-1734 [h] +1-416-595-5425 [w] VE3TCP Toronto, Ontario CANADA Political speech and writing are largely the defense of the indefensible-ORWELL
larry@nstar.rn.com (Larry Snyder) (12/21/90)
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) writes: > I hate to agree that this is the state, but having tried a number of >the 3.2 flavors, I'm convinced that if you don't need some feature which >is in 3.2 which is not in Xenix, and NFS is the only one which comes to >mind, your reliability will be better with Xenix than and 3.2 I've >tried. I disagree. We run Interactive 3.2 2.20 and have had NFS up and running for weeks without problems. With the fast file systems - NFS really shines -- -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar.rn.com, uunet!nstar!larry, larry%nstar@iuvax.cs.indiana.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
larry@nstar.rn.com (Larry Snyder) (12/21/90)
tneff@bfmny0.BFM.COM (Tom Neff) writes: >Anyway, memory is so damn cheap these days. My only beef is that, for a >UNIX release packing so many additional files, SVR4/386 doesn't have better >support for huge ESDI disks. It chafes to have to throw away 100MB of >my Maxtor just to keep upder 1024 cylinders. I would like to see this >addressed in a future rev. My beef is that I can only put 12 megs in my machine without causing problems with the multiport boards (which I can't seem to get to work below 1 megabyte).. -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar.rn.com, uunet!nstar!larry, larry%nstar@iuvax.cs.indiana.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (12/21/90)
In <350@metran.UUCP> jay@metran.UUCP (Jay Ts) writes: >Nonsense. AT&T's manual set for System V/386 r3.2 (published by Prentice >Hall) work fine for ESIX. You can order them from you local bookstore. Two problems. 1. AT&T's manauls do not include anything about sendmail, TCP/IP, and associated programs such as remsh, ftp, rlogin, and slconfig. 2. AT&T's manuals are generally of poor quality. -- Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi
tneff@bfmny0.BFM.COM (Tom Neff) (12/21/90)
SO many people have mailed or posted insisting that SVR4 really can handle more than 1024 ESDI cylinders that I'm actually going to break down and try another install... after Christmas. (I can't believe I'm deciding this.) I'll let you know how it comes out. Mail any more hints.
tim@delluk.uucp (Tim Wright) (12/21/90)
In <94408977@bfmny0.BFM.COM> tneff@bfmny0.BFM.COM (Tom Neff) writes: >Anyway, memory is so damn cheap these days. My only beef is that, for a >UNIX release packing so many additional files, SVR4/386 doesn't have better >support for huge ESDI disks. It chafes to have to throw away 100MB of >my Maxtor just to keep upder 1024 cylinders. I would like to see this >addressed in a future rev. Which version of SVR4 is this ?? Does it really not cope with > 1024 cylinders ? I've installed Dell SVR4 on a 640MB ESDI drive with no difficulty at all - 1628 cylinders, 54 sectors/track, 15 heads ~= 664,000,000. SVR3.2 could do this. The code ought to try to get the geometry from the drive anyway, but prompt to check that what it has got is correct. It doesn't matter that the AT BIOS is braindead and has to truncate the FDISK partition at 1023 cylinders since UNIX should ignore it. -- Tim Wright, Dell Computer Corp. (UK) | Email address Bracknell, Berkshire, RG12 1RW | Domain: tim@dell.co.uk Tel: +44-344-860456 | Uucp: ...!ukc!delluk!tim "What's the problem? You've got an IQ of six thousand, haven't you?"
james@bigtex.cactus.org (James Van Artsdalen) (12/21/90)
In <350@metran.UUCP>, jay@metran.UUCP (Jay Ts) wrote: > I am *scared* of SVR4!! When/if my clients have to upgrade, they > will have to add at least 4 Mb of memory and probably suffer a > performance degradation as well. (Someone please tell me this isn't > really true!) I recently used some of our test hardware on SysVr4 and discovered that the interrupt handler latency (time from interrupt acknowledge to reading from device) is better than the handler latency in SysVr3. This isn't the whole story by any means, but it's a good sign. Another feature is that the "sticky" bit doesn't appear to be needed any more to avoid excess disk activity when a binary is started. If you run emacs twice in a row, there isn't any disk activity the second time (if you have that much RAM). The SysVr4 compiler isn't real bright (worse than SysVr3 I think), but you can use gcc for production code. > And it won't markedly improve the functioning of their existing > software, either. Well, what about job control, BSD-style line editing (I'm not sure what BSD calls this), long file names, etc? Something in there seems useful. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Dell Computer Co 9505 Arboretum Blvd Austin TX 78759 512-338-8789
beattie@visenix.UUCP (Brian Beattie) (12/21/90)
In article <2812@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes:
-> Everex has a fair implementation (except for one or two
->things that don't work at all) but the worst documentation I have seen
->for an operating system (based on the two manuals included with what I
->bought -- you can buy more manuals, which I suspect will be of the same
->miserable quality).
compared to what.
I have the full manual set and it is as good as anything I have seen.
->
->For business purposes I recommend SCO. Although I personally haven't
With *GAG* C2 security from *cough* secureWare?
->For good documentation and powerful features, you have no choice but to
->try to find a BSD derivative (anything except Ultrix). Right now I use
no can do on a 386/AT unless you have a source license ($100,000)
->SunOS at work and find it to be relatively stable and moderately well
good for you but I the issue is 386 UNIX's
->
->Also available, still in beta-test (though they call it a "production
->release") is System V Release 4. I would wait another year, but by
at least a year
->
->So, although the picture looks pretty bleak right now for UNIX on the
->386, things should improve when SVR4 stabilizes (and, I hope, becomes
I think it is just fine. I would guess that the main problem you have
with the 386 UNIX's is the lack of BSD features.
->--
->Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com>
->UUCP: oliveb!cirrusl!dhesi
--
It is easier to build a | Brian Beattie (703)471-7552
secure system than it is | 11525 Hickory Cluster, Reston, VA. 22090
to build a correct system.|
M. Gasser | ...uunet!visenix!beattiemike@atc.SP.Unisys.COM (Mike Grenier) (12/22/90)
From article <350@metran.UUCP>, by jay@metran.UUCP (Jay Ts): > In article <2812@cirrusl.UUCP>, dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: > > Judging from postings in this newsgroup, ESIX has fewer bugs or other > problems than ISC 2.2 or SCO UNIX. In working with ESIX, so far I haven't > run into any problems that I couldn't work around or solve either on my > own or with the help of ESIX tech support. They are responsive *and* > helpful both over the phone and by email. Judging from the experience of setting up a half dozen ESIX systems, I'll never buy from them again! Anybody (ISC, SCO, Microport) has less bugs. -Mike Grenier mike@cimcor.mn.org
jgd@Dixie.Com (John G. DeArmond) (12/22/90)
>In article <2812@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: -> Everex has a fair implementation (except for one or two ->things that don't work at all) but the worst documentation I have seen ->for an operating system (based on the two manuals included with what I ->bought -- you can buy more manuals, which I suspect will be of the same ->miserable quality). Plus Esix is a dog performance wise. I benchmarked it against many other machines for my last client's fairly large project. Our benchmark performed typical transaction-styled database lookups and modifications. A compaq DeskPro 33 mhz system running ISC 2.2 and a compaq supplied 300 meg disk permformed about 300 "transactions" per second. The client's Sequent (4 processor unit) did about 170. An IBM Sh*tstation 6000/54 (I think that's right, anyway, second from the top) would do about 310 when it was not crashing. This system (20 mhz clone board with fast SCSI drives and ISC 2.0.2) does about 120. A 25 mhz clone system with ESDI drives did exactly ONE transaction per second. This is the same performance we observed from an NCR 200 (4 tps) and an NCR 400 (1 tps). What this tells me is that the Esix port is pure AT&T file system without any performance enhancements at all. The compaq was most impressive coupled with the new release of ISC. >-> >->For business purposes I recommend SCO. Although I personally haven't >With *GAG* C2 security from *cough* secureWare? Yeah, SCO is pretty much all 'round bad. Even though ISC has their stupid little authorization-style copy protection, it is no where near as bad as SCO's. I think SCO is following in the footsteps that IBM laid with the PC and is giving up the lead through sheer stupidity. >->For good documentation and powerful features, you have no choice but to >->try to find a BSD derivative (anything except Ultrix). Right now I use >no can do on a 386/AT unless you have a source license ($100,000) Plus I don't know that I'd want to mess with BSD in a commercial environment. Perhaps if someone like ISC took BSD and made a product from it by cleaning it up and adding value, I'd be interested. But after spending the past little while crawling through bezerklyware networking code, I'd not want to risk my reputation on unadorned BSD. Besides anyone who is complaining about documentation should really look at ISC's 2.2 release docs. All 62 lbs of them! The installation and administration guide in particular is as good of Unix documentation as I've seen. Particularly the part on line printer management. True, there is no "This is Unix" style beginner's guide but I as an experienced unix system admin and developer have found just about everything I've wanted to know in the manuals. I've advocated pinging ISC for their stupidity over things like the authorization manager (I can hardly wait for this thing to take a client's system down. I'll do everything I can to sic the lawyers on 'em.) and their moronic support policy. At the same time, I advocate giving them credit where it is due. Their performance and their documentation are excellent. Hey Interactive! How about rediscovering the spirit that must exist in the tech writing department and applying it to your support policies. And can the authorization manager and call it a bad wet dream. Ok? And stick the Korn shell in the distribution just for good measure. >-> >->Also available, still in beta-test (though they call it a "production >->release") is System V Release 4. I would wait another year, but by >at least a year I hope never. I hope that by the time we have to look at R4, commercial Mach and/or commercial free BSDs will be available. AT&T's new motto: "Unix: The product that we just couldn't kill - though we tried real hard." ------------------------------------ $finger AT&T Logname: ATT In real life: The Phone and Cash Register Company project - Kill Unix plan - Issue Release 4, buy NCR. ------------------------------------- John -- John De Armond, WD4OQC | "Purveyors of speed to the Trade" (tm) Rapid Deployment System, Inc. | Home of the Nidgets (tm) Marietta, Ga | {emory,uunet}!rsiatl!jgd | "Vote early, Vote often"
rcd@ico.isc.com (Dick Dunn) (12/22/90)
larry@nstar.rn.com (Larry Snyder) writes: > tneff@bfmny0.BFM.COM (Tom Neff) writes: ... > >Anyway, memory is so damn cheap these days... ... > My beef is that I can only put 12 megs in my machine without causing > problems with the multiport boards ... Larry's problem is one of a larger class, which says that memory upgrades are not necessarily cheap and trivial. While it's true that you can almost go to the corner grocery and buy SIMMs at $50/Mb, come home, plug 'em in to a modern motherboard, fire up and go, there are cases where "just add more memory" doesn't work now, and more cases where it won't work in the future: - Larry's example--memory-I/O problems limits max memory. - Common SX boards are limited to 8 Mb. That may not seem too bad now, but (a) it's a hard limit for those boards and (b) there's no indication that kernel bloat is slowing. - Large installations: It may be no big deal to add 4 Mb ($200) each to a few machines...but what if you've got a thousand machines in the field to upgrade? - Memory for older machines/motherboards can be very expensive. The wonder of memory < $50/Mb becomes less wondrous if you have to spend $1000 on a new motherboard to get it. - Memory-intensive applications: If you're using your machines for something real, and it happens to need a lot of memory, sucking up that memory for the kernel may either push you into heavy paging or reduce the size of the largest problem you can solve. The incremental cost of adding a little waste to the kernel can be very high. But perhaps the reason I find the ever-increasing kernel size so galling is not so much that it creates certain problems as that it's entirely un- necessary... -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...Mr. Natural says, "Use the right tool for the job."
bill@unixland.uucp (Bill Heiser) (12/22/90)
In article <1990Dec20.233843.28559@nstar.rn.com> larry@nstar.rn.com (Larry Snyder) writes: > >My beef is that I can only put 12 megs in my machine without causing >problems with the multiport boards (which I can't seem to get to work >below 1 megabyte).. > Why is this? Does this mean (do you think?) that if I up my machine to 16MB, my AST 4-port board will not work? -- home: ...!{uunet,bloom-beacon,esegue}!world!unixland!bill bill@unixland.uucp, bill%unixland.uucp@world.std.com Public Access Unix - Esix SYSVR3 - 508-655-3848 12/24/96-HST 508-651-8733 12/24/96-PEP/V32
bill@unixland.uucp (Bill Heiser) (12/22/90)
In article <1990Dec21.173407.10249@atc.SP.Unisys.COM> mike@atc.SP.Unisys.COM (Mike Grenier) writes: > >Judging from the experience of setting up a half dozen ESIX systems, I'll >never buy from them again! Anybody (ISC, SCO, Microport) has less bugs. > bugs like what? It's funny how this "which 386 unix is best" conversation goes round and round. Back in Aug/Sep when I was deciding between SCO/Interactive/Everex, practically everyone on the net was talking about the problems they'd been having with SCO and Interactive. Now it seems that Esix-bashing has come in vogue! Geeeesh! :-) -- home: ...!{uunet,bloom-beacon,esegue}!world!unixland!bill bill@unixland.uucp, bill%unixland.uucp@world.std.com Public Access Unix - Esix SYSVR3 - 508-655-3848 12/24/96-HST 508-651-8733 12/24/96-PEP/V32
john@jwt.UUCP (John Temples) (12/22/90)
In article <5407@rsiatl.Dixie.Com> jgd@Dixie.Com (John G. DeArmond) writes: >What this tells me is that the Esix port is pure AT&T file system without >any performance enhancements at all. No. The default ESIX file system is their version of the BSD FFS. But although I've never run any quantitative benchmarks, I would tend to agree that ESIX's file system is slower. I run ESIX-D on a 386/33 with 8 MB at home, and ISC 2.0.2 on a 386/25 with 4 MB at work. Both have Miniscribe 6085 drives running 1:1 interleave. The ISC system just feels faster, even though it's on a slower machine with less RAM. But overall, ESIX seems more robust. No panics, crashes, or spurious reboots like I have with ISC. -- John W. Temples -- john@jwt.UUCP (uunet!jwt!john)
sef@kithrup.COM (Sean Eric Fagan) (12/22/90)
In article <1990Dec21.223449.14660@unixland.uucp> bill@unixland.uucp (Bill Heiser) writes: >Why is this? Does this mean (do you think?) that if I up my machine to >16MB, my AST 4-port board will not work? It really depends. If a card puts it's data space in the "magic" 340k that lives between 640k and 1Mb, then it's safe. However, if it puts it at, oh, say, 0xc00000, then you cannot put in physical memory that will conflict with it. (That address, incidently, is where my ancient Cornerstone Monitor puts its frame buffer; really nice, except it doesn't work 8-(.) I've seen indications that one video card puts its frame buffer at 0xd0000000; as you may suppose, that is an EISA card. Since ISA is limited to 24 address bits, you can see the problem. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
larry@nstar.rn.com (Larry Snyder) (12/22/90)
jgd@Dixie.Com (John G. DeArmond) writes: >Plus Esix is a dog performance wise. I benchmarked it against many other >machines for my last client's fairly large project. Our benchmark >performed typical transaction-styled database lookups and modifications. I've heard this from several others -- >What this tells me is that the Esix port is pure AT&T file system without >any performance enhancements at all. The compaq was most impressive coupled >with the new release of ISC. what release of ESIX were you using? I understood that D contained the BSD FFS -- >Yeah, SCO is pretty much all 'round bad. Even though ISC has their stupid >little authorization-style copy protection, it is no where near as bad >as SCO's. I think SCO is following in the footsteps that IBM laid with >the PC and is giving up the lead through sheer stupidity. I agree - only the OS and Visix contain serial numbers (with 2.20 ISC) >credit where it is due. Their performance and their documentation are >excellent. Hey Interactive! How about rediscovering the spirit that must >exist in the tech writing department and applying it to your support >policies. And can the authorization manager and call it a bad wet dream. >Ok? And stick the Korn shell in the distribution just for good measure. ISC 2.20 and SCSI is a screamer - no doubt about it. -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar.rn.com, uunet!nstar!larry, larry%nstar@iuvax.cs.indiana.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
larry@nstar.rn.com (Larry Snyder) (12/22/90)
bill@unixland.uucp (Bill Heiser) writes: >In article <1990Dec20.233843.28559@nstar.rn.com> larry@nstar.rn.com (Larry Snyder) writes: >> >>My beef is that I can only put 12 megs in my machine without causing >>problems with the multiport boards (which I can't seem to get to work >>below 1 megabyte).. >> >Why is this? Does this mean (do you think?) that if I up my machine to >16MB, my AST 4-port board will not work? your board shouldn't effect you being able to install 16 megs - my problem relates to the address that the board requires for proper operation. Computone in their wisdom designed a board which requires 256k to run - even through they only have 128K on the board. I don't have 256k free below 1 megabyte. I've went round and round with Computone tech support without any success. The board runs fine at it's current address (14 megs) - I wonder if I could place it just shy of 16 megs (16 megs - 256k) and if ISC Unix 2.20 would use all that memory (up to 16 megs - 256k)? I usually have 4 users on my machine downloading (we all know very few BBS users actually upload), 1 X session (with 6 applications), complete news processing for 15-18 machines (of 1100+ newsgroups), plus a couple of telnet sessions - and I really could use more memory. Plus - I plan on opening up shell access on nstar.rn.com - then users will have access to word perfect, and all the other utilities and tools which consume memory (like the compilers and such).. -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar.rn.com, uunet!nstar!larry, larry%nstar@iuvax.cs.indiana.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
larry@nstar.rn.com (Larry Snyder) (12/22/90)
john@jwt.UUCP (John Temples) writes: >RAM. But overall, ESIX seems more robust. No panics, crashes, or >spurious reboots like I have with ISC. I never have had problems like this with either 2.02 or 2.20 - this machines runs and runs without problems. Sometimes we loose power 2-3 times a week, and nstar reboots, checks all the file systems and comes back up in around 25 minutes (we have lots of file systems to check).. ISC here on nstar is very solid - but on the same machine - Intel release 4.0 (2.0) is another ballgame -- -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar.rn.com, uunet!nstar!larry, larry%nstar@iuvax.cs.indiana.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
jay@metran.UUCP (Jay Ts) (12/23/90)
In article <94408977@bfmny0.BFM.COM>, tneff@bfmny0.BFM.COM (Tom Neff) writes: > In article <350@metran.UUCP> jay@metran.UUCP (Jay Ts) writes: > >I am *scared* of SVR4!! When/if my clients have to upgrade, they will have > >to add at least 4 Mb of memory and probably suffer a performance degradation > >as well. (Someone please tell me this isn't really true!) And it won't > >markedly improve the functioning of their existing software, either. > > I'll tell you it's not true if you'll tell us why you thought it WAS true. Mostly a number of informal and unreliable sources... But then there's Microport's product info with words to the effect that "you can use a minimum of 4Mb, but you should really have 8", and a usenet posting a couple of months ago from an employee from Unisoft stating that SVR4 does not run smoothly in any less than 5 Mb. This means my clients with 4Mb systems that already run smoothly will need to get another 4 Mb chunk. > For equivalent functionality -- note that phrase please -- SVR4 looks > about 20% bigger than the comparable SVR3v2.2 system. But remember that > SVR4 adds a lot of functionality! None of which will be used by my clients. I am trying not to nitpick at this point (I still want to be friends, after all), (ahem...) but, if the functionality is *equivalent* and the kernel takes up 20% more space with a lot *more* functionality, then ... um ... what were your trying to say, anyway??? > Anyway, memory is so damn cheap these days. I remember reading that just about *everywhere* immediately prior to the big RAM drought a couple years ago. I am not going to be happy until RAM is less than $25 per Mbyte. (And available :-) Hey, I didn't mean to be so negative, after all, I'm a UNIX enthusiast, too! My point is that for the common office automation environment, UNIX is getting to be serious overkill. It's hard to sell UNIX against, for example, TurboDOS, which is small, efficient, inexpensive, and easy to administrate. I'm not trying to suggest we all switch to a CP/M-variant or a Mach-derivative :-), but I think that UNIX is getting a little too monolithic for small systems. OK? In fact, what really scares me is not the size of the kernel, but the size of the documentation. Back in the days when computers costed millions of dollars, took up their own rooms and had their own air conditioners, it was not unreasonable to hire a team of system managers to be experts on the bookshelf full of documentation. But now the computer sits under a table in an office and costs about $5000. There is no team of system managers, there is just me. And I happen to think that a bookshelf-full of documentation is a bit much. I first became interested in UNIX because it was a neat, simple, efficient and sensible alternative to the big, bad, ugly IBM, Burroughs and Sperry mainframes. I am starting to feel like someone is weaning me away from my favorite toy. > My only beef is that, for a > UNIX release packing so many additional files, SVR4/386 doesn't have better > support for huge ESDI disks. It chafes to have to throw away 100MB of > my Maxtor just to keep upder 1024 cylinders. I would like to see this > addressed in a future rev. You're kidding? There must be a way around that problem! Someone help this guy. Jay Ts, Director Metran Technology Tampa FL uunet!pdn!tscs!metran!jay -------------- I feel like going into a submarine for a few months.
jay@metran.UUCP (Jay Ts) (12/23/90)
In article <1990Dec20.233843.28559@nstar.rn.com>, larry@nstar.rn.com (Larry Snyder) writes: > tneff@bfmny0.BFM.COM (Tom Neff) writes: > > My beef is that I can only put 12 megs in my machine without causing > problems with the multiport boards (which I can't seem to get to work > below 1 megabyte).. Curiosity strikes again. Just which multiport boards would those be? Jay Ts Metran Technology uunet!pdn!tscs!metran!jay
jay@metran.UUCP (Jay Ts) (12/23/90)
In article <51537@bigtex.cactus.org>, james@bigtex.cactus.org (James Van Artsdalen) writes: > In <350@metran.UUCP>, jay@metran.UUCP (Jay Ts, I) wrote: > > > I am *scared* of SVR4!! > > > And it won't markedly improve the functioning of their existing > > software, either. > > Well, what about job control, BSD-style line editing (I'm not sure > what BSD calls this), long file names, etc? Something in there seems > useful. Job control, line editing? Do you think that office workers use the shell? Mostly, they are entering data and making menu selections. Long file names are a noticeable improvement. Well, maybe. Just offhand, I don't remember seeing any truncated filenames in users' home directories. Not many, anyway. (Boy, now I've done it -- I've stuck myself into playing devil's advocate against one of my favorite pieces of technology. Somewhere there must be a cure for me :-) Jay Ts, Director Metran Technology uunet!pdn!tscs!metran!jay
jay@metran.UUCP (Jay Ts) (12/23/90)
In article <1990Dec21.173407.10249@atc.SP.Unisys.COM>, mike@atc.SP.Unisys.COM (Mike Grenier) writes: > > In article <2812@cirrusl.UUCP>, dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: > > Judging from the experience of setting up a half dozen ESIX systems, I'll > never buy from them again! Anybody (ISC, SCO, Microport) has less bugs. > > -Mike Grenier > mike@cimcor.mn.org Jay Ts uunet!pdn!tscs!metran!jay
jay@metran.UUCP (Jay Ts) (12/23/90)
In article <1990Dec20.175625.17487@eci386.uucp>, woods@eci386.uucp (Greg A. Woods) writes: > In article <2812@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: > > > Although it was stable and relatively free of bugs, the quality of > > documentation was standard AT&T, which means no indexes, poor > > organization, and nonexistent information about system administration > > procedures. The Xenix documentation was little better. > > EXCUSE ME?!?!?! What do you call the permuted index? I call it the > best damn index ever invented! Omigod! I'll run for the fire hose, you call 911 for the fire department! [Sorry, but I gotta do this; I've been saving this up for years.] Of all parts of AT&T's (or anyone else's) documentation, I think the permuted index is the most flammable by far! If it works, it works great, but if it doesn't, you have nothing left to do but sit back and meditate (which usually works for me :-). Unfortunately, the permuted index is the *only* index for the Reference Manuals, and this seems to be standard practice for not just AT&T/ESIX, but other vendors as well. The problem is, it's essentially produced by machine. To get it to work, you have to think of the right keyword in UNIXspeak. For example, I recently had to write a small program to do unbuffered, character-at-a-time terminal I/O. I thought, "This should be simple, I'll just grab the Programmer's Reference Manual, and take a look at the wonderful permuted index." Searches based on "character", "buffer", "canonical", and everything else I could think of all utterly failed to bring me nearer to termio(7) in the *System Administrator's* Reference manual. (Looking in the SA's Ref Manual in the first place would not have worked any better.) And once I found termio(7) with a combination of my understanding of UNIX, clairvoyance and exhaustive search, I still had to read carefully before I discovered it really was the right place to look! The programming method was simple; just do a ioctl() to clear the ICANON bit, and a few other things. I just can't believe how hard it was to look up. Now get this: I just looked through the whole permuted index (in the SARM) and every reference to termio(7) is generated from the line termio(7): general terminal interface which is what is listed under NAME on the termio(7) manual page! Now, feel free to flame at me if you think I'm misguided (I've got the firehose now) but I think this method of indexing is a little deficient. (But it was great back when I was working in a research environment with a number of UNIX gurus, at least one of which would tell me something other than "RTFM!" :-) Basically, the permuted index works well only for those with enough experience and knowledge to already know exactly where to look. If you think there's nothing wrong with having the permuted index as the sole index, then I guess you can take this as a compliment. What is needed, IMO, is a real index (IN ADDITION to the permuted one) that is created the old fashioned way, by a thoughtful human reading through the book and making index entries for each subject wherever it appears. Am I crazy or stupid, or is that not a good idea? Jay Ts, Director Metran Technology uunet!pdn!tscs!metran!jay
sef@kithrup.COM (Sean Eric Fagan) (12/23/90)
In article <51537@bigtex.cactus.org>, james@bigtex.cactus.org (James Van Artsdalen) writes: > Well, what about job control, BSD-style line editing (I'm not sure > what BSD calls this), long file names, etc? SCO's 3.2v2 already has job control, and line editing via ksh. It shouldn't be too difficult to make a long-filename filesystem (only about, oh, three or four months worth of work 8-)), so you industrious hackers out there can get started now... 8-; Seriously, once again, I *like* 3.2v2. It's decent, it's only crashed due to my stuff (playing with the console driver does strange things to the rest of the system.. 8-)), and it's got most of the features I like in it. It's got a way to go before it's perfect, but, then, so does any other OS. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
bill@unixland.uucp (Bill Heiser) (12/23/90)
In article <1990Dec22.134904.25395@nstar.rn.com> larry@nstar.rn.com (Larry Snyder) writes: > >your board shouldn't effect you being able to install 16 megs - my >problem relates to the address that the board requires for proper >operation. Computone in their wisdom designed a board which requires >256k to run - even through they only have 128K on the board. I don't >have 256k free below 1 megabyte. I've went round and round with I couldn't find anything in the documentation for the AST board saying anything about any memory address. I guess since it's not an intelligent board, maybe it doesn't have any of its own memory? >I usually have 4 users on my machine downloading (we all know >very few BBS users actually upload), 1 X session (with 6 applications), >complete news processing for 15-18 machines (of 1100+ newsgroups), >plus a couple of telnet sessions - and I really could use more memory. Larry, what kind of video hardware are you using to provide adequate performance in X? I don't use X much myself, because this little Multisync II (14") and ATI VGA Wonder (only supported to 640*480 in Esix X) just don't cut it -- too small and too slow on re-draw. >Plus - I plan on opening up shell access on nstar.rn.com - then >users will have access to word perfect, and all the other utilities >and tools which consume memory (like the compilers and such).. What made you decide to start offering shell access, Larry? A while back you mentioned that you were concerned about the potential security risk here. I haven't seen much posted from you for a while (until the past few days). Have you been away? Bill Heiser -- home: ...!{uunet,bloom-beacon,esegue}!world!unixland!bill bill@unixland.uucp, bill%unixland.uucp@world.std.com Public Access Unix - Esix SYSVR3 - 508-655-3848 12/24/96-HST 508-651-8733 12/24/96-PEP/V32
bill@unixland.uucp (Bill Heiser) (12/23/90)
In article <351@metran.UUCP> jay@metran.UUCP (Jay Ts) writes: >not run smoothly in any less than 5 Mb. This means my clients with 4Mb >systems that already run smoothly will need to get another 4 Mb chunk. This means that people with boards like mine will have to jump to 16MB! My board only supports chunks of 8mb... -- home: ...!{uunet,bloom-beacon,esegue}!world!unixland!bill bill@unixland.uucp, bill%unixland.uucp@world.std.com Public Access Unix - Esix SYSVR3 - 508-655-3848 12/24/96-HST 508-651-8733 12/24/96-PEP/V32
evan@telly.on.ca (Evan Leibovitch) (12/23/90)
In article <352@metran.UUCP> jay@metran.UUCP (Jay Ts) writes: >In article <1990Dec20.233843.28559@nstar.rn.com>, larry@nstar.rn.com (Larry Snyder) writes: >> tneff@bfmny0.BFM.COM (Tom Neff) writes: >> >> My beef is that I can only put 12 megs in my machine without causing >> problems with the multiport boards (which I can't seem to get to work >> below 1 megabyte).. > >Curiosity strikes again. Just which multiport boards would those be? I'm not sure about others, but... Both the Corollory 8x4 boards and the Consensys Powerports require you to set a separate memory address for each board (you shouldn't need too many boards, though, as they can be configured to hold 32 and 48 ports per board, respectively). On both cards, the address is settable to EITHER somewhere above 12Meg or somewhere between 640K and 1Meg. One has to be a bit careful about a setting in the latter range because it can conflict with auxilliary BIOS locations (often found on video or disk boards). But it is preferable, and necessary if you want to install >12Meg of RAM. Both cards require you to set a port, and the Corollory needs an interrupt too. -- Evan Leibovitch, Sound Software, located in beautiful Brampton, Ontario evan@telly.on.ca / uunet!attcan!telly!evan / (416) 452-0504 Ididntdoit, nobodysawmedoit, youcantproveathing. - Bart
cpcahil@virtech.uucp (Conor P. Cahill) (12/24/90)
In article <357@metran.UUCP> jay@metran.UUCP (Jay Ts) writes: > > [flame of permuted indexes deleted] > >Basically, the permuted index works well only for those with enough experience >and knowledge to already know exactly where to look. If you think there's >nothing wrong with having the permuted index as the sole index, then I guess >you can take this as a compliment. You go on and on about how bad the permuted index is when our real complaint (and somewhat justified) is that the one-line description of the manual page (which is used to build the permuted index) is not always conceived with the thought that it is the basis for the index. >What is needed, IMO, is a real index (IN ADDITION to the permuted one) that >is created the old fashioned way, by a thoughtful human reading through the >book and making index entries for each subject wherever it appears. I would rather see a better description line which would make the permuted index even better. Perhaps a better solution would be to insert a couple of different description lines, if appropriate. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (12/24/90)
In article <879@visenix.UUCP> beattie@visenix.UUCP (Brian Beattie) writes: | -> | ->For business purposes I recommend SCO. Although I personally haven't | | With *GAG* C2 security from *cough* secureWare? The discussion, had you followed it before posting, was about Xenix for business use. I agree, for people who want to use their system instead of play with it, Xenix is fine. It runs a hugh number of applications, and is reliable. It also handles more peripherals than any other version I've seen. | ->Also available, still in beta-test (though they call it a "production | ->release") is System V Release 4. I would wait another year, but by | | at least a year If you want beauty, wait that year. If you want a system which doesn panic, V.4 is pretty fine right now. The documentation is somewhat sparse, but other than that it looks good. | -> | ->So, although the picture looks pretty bleak right now for UNIX on the | ->386, things should improve when SVR4 stabilizes (and, I hope, becomes | | I think it is just fine. I would guess that the main problem you have | with the 386 UNIX's is the lack of BSD features. Having used BSD, SunOS and Ultrix on a regular basis for some years, I fail to identify these features which I'm supposed to miss. The only feature I regularly find useful is symbolic links, and that's usually used to get around poor system administration. What else is supposed to be so useful? -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (12/24/90)
| Why is this? Does this mean (do you think?) that if I up my machine to | 16MB, my AST 4-port board will not work? It only effects cards which are memory mapped and can't be put between 640k and 1MB. You also have to turn off memory shadow in that range if you have memory mapped devices there. Original poster: you did turn off shadow memory when trying to put the board in that range, right? I think the AST is i/o mapped, but the clone I ordered hasn't come yet. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
alan@ahmcs.com (Alan Mintz) (12/24/90)
In article <1990Dec21.214440.20985@ico.isc.com>, rcd@ico.isc.com (Dick Dunn) writes: > larry@nstar.rn.com (Larry Snyder) writes: > > tneff@bfmny0.BFM.COM (Tom Neff) writes: > ... > > >Anyway, memory is so damn cheap these days... > ... > > My beef is that I can only put 12 megs in my machine without causing > > problems with the multiport boards ... > > Larry's problem is one of a larger class, which says that memory upgrades > are not necessarily cheap and trivial. While it's true that you can almost > go to the corner grocery and buy SIMMs at $50/Mb, come home, plug 'em in to > a modern motherboard, fire up and go, there are cases where "just add more > memory" doesn't work now, and more cases where it won't work in the future: > - Memory for older machines/motherboards can be very expensive. > The wonder of memory < $50/Mb becomes less wondrous if you have > to spend $1000 on a new motherboard to get it. Or people like Northgate, who produced machines that actually required a PAL change to change from 256K to 1Mb chips (even on some machines that use SIMMs). They actually have the balls to charge $100 for two PAL chips. (Of course, the salesman mentions, they are included if you buy your memory from them - at $150/Mb) -- < Alan H. Mintz | Voice +1 714 980 1034 > < Micro-Quick Systems, Inc. | FAX +1 714 944 3995 > < 10384 Hillside Road | ...!uunet!ahmcs!alan > < Alta Loma, CA 91701 USA | alan@mq.com >
larry@nstar.rn.com (Larry Snyder) (12/24/90)
evan@telly.on.ca (Evan Leibovitch) writes: >Both the Corollory 8x4 boards and the Consensys Powerports require you >to set a separate memory address for each board (you shouldn't need too >many boards, though, as they can be configured to hold 32 and 48 ports >per board, respectively). >On both cards, the address is settable to EITHER somewhere above 12Meg >or somewhere between 640K and 1Meg. One has to be a bit careful about a >setting in the latter range because it can conflict with auxilliary BIOS >locations (often found on video or disk boards). But it is preferable, >and necessary if you want to install >12Meg of RAM. >Both cards require you to set a port, and the Corollory needs an >interrupt too. Likewise on the Computone Intelliport - they require an interrupt and can be addressed either from 12-16 megabytes - or below one megabyte - but the issue is finding enough memory below 1 MEG in one block to get the job done.. -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar.rn.com, uunet!nstar!larry, larry%nstar@iuvax.cs.indiana.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
larry@nstar.rn.com (Larry Snyder) (12/24/90)
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) writes: > Original poster: you did turn off shadow memory when trying to put the >board in that range, right? of course. -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar.rn.com, uunet!nstar!larry, larry%nstar@iuvax.cs.indiana.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
jay@metran.UUCP (Jay Ts) (12/25/90)
In article <1990Dec23.160807.3207@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) writes: > In article <357@metran.UUCP> jay@metran.UUCP (Jay Ts) writes: > > > > [flame of permuted indexes deleted] > > > >Basically, the permuted index works well only for those with enough experience > >and knowledge to already know exactly where to look. If you think there's > >nothing wrong with having the permuted index as the sole index, then I guess > >you can take this as a compliment. > You go on and on about how bad the permuted index is when our real complaint > (and somewhat justified) is that the one-line description of the manual page > (which is used to build the permuted index) is not always conceived with > the thought that it is the basis for the index. Well, sorry for the verbosity :-), but my complaint really is that the permuted index is built not from the DESCRIPTION, but the NAME field of the manual page. Especially for entries like termio(7), which I had used as an example, there are a number of subtopics in the DESCRIPTION that are not simply and obviously connected with the vague overview given in the NAME field. > I would rather see a better description line which would make the permuted > index even better. Perhaps a better solution would be to insert a couple > of different description lines, if appropriate. Or to have some intelligent software (or a human) look through the DESCRIPTION part of the manual page and make its own, and then make the permuted index from that... Jay Ts uunet!pdn!tscs!metran!jay
duc@mport.COM (Richard Ducoty) (12/25/90)
tneff@bfmny0.BFM.COM (Tom Neff) writes: >In article <350@metran.UUCP> jay@metran.UUCP (Jay Ts) writes: >>I am *scared* of SVR4!! When/if my clients have to upgrade, they will have >>to add at least 4 Mb of memory and probably suffer a performance degradation >>as well. (Someone please tell me this isn't really true!) And it won't >>markedly improve the functioning of their existing software, either. ... >Anyway, memory is so damn cheap these days. My only beef is that, for a >UNIX release packing so many additional files, SVR4/386 doesn't have better >support for huge ESDI disks. It chafes to have to throw away 100MB of >my Maxtor just to keep upder 1024 cylinders. I would like to see this >addressed in a future rev. =========================================== Which version of SVR4 are you running? Microport SVR4 can use >1024 cylinders. The /stand and root filesystems should be inside 1024 [just to make sure that unix is below 1024. I have a Maxtor 8380E - with 1600+ cylinders - I have access to all of it. Speaking of Maxtor - I've had a few occurances of my drive suddenly going nuts It sounds like someone knocked the needle across a record. Anyone have an idea what goes on? Also - Maxtor's warranty period starts when the WHOLESALER buys the drive - not the user. I got a good price, but 6 months of Maxtor's warranty period was gone. I don't get the best of feelings talking to them on the phone either. I wish all companies were as good as Telebit in suporting their product. By the way - the first 8380E I got didn't work at all! Richard Ducoty Richard Ducoty \\\\\\\ Microport Inc. (.)(.) root@mport.com voice=> (408) 438-8649 > duc@mport.com fax=> (408) 438-7560 - uunet!mport!duc " militiae species amor est "
james@bigtex.cactus.org (James Van Artsdalen) (12/27/90)
In <355@metran.UUCP>, jay@metran.UUCP (Jay Ts) wrote: > And it won't markedly improve the functioning of their existing > software, either. | Well, what about job control, BSD-style line editing (I'm not sure | what BSD calls this), long file names, etc? Something in there seems | useful. > Job control, line editing? Do you think that office workers use the shell? > Mostly, they are entering data and making menu selections. Sounds like their existing software is Mess-DOS. > Long file names are a noticeable improvement. Well, maybe. Just > offhand, I don't remember seeing any truncated filenames in users' > home directories. Not many, anyway. Even Mess-DOS has line editing. The only thing about SysVr4 an "office worker" is likely to really notice is that TCP/IP and NFS work much better than SysVr3, and then only if they're running over NFS or something. The big win for SysVr4 is for the programmer. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Dell Computer Co 9505 Arboretum Blvd Austin TX 78759 512-338-8789
robinro@bomber.ism.isc.com (Robin Roberts) (12/28/90)
tneff@bfmny0.BFM.COM (Tom Neff) writes: >Anyway, memory is so damn cheap these days. My only beef is that, for a >UNIX release packing so many additional files, SVR4/386 doesn't have better >support for huge ESDI disks. It chafes to have to throw away 100MB of >my Maxtor just to keep upder 1024 cylinders. I would like to see this >addressed in a future rev. Have you considered IDE instead of ESDI? I put a 200meg IDE drive with 1272 cylinders on my machine running ESIX rev B [two revisions out of date...] and it sees all the cylinders. Which is more than I can say for the MSDOG 4.01 fdisk ... -- Robin D. Roberts | <This space closed for remodeling. Watch for Interactive Systems Corp. | a new witty quotation scheduled to open in Calabasas, Calif. | the Spring of 1991! > Internet: robinro@ism.isc.com CompuServe: 72330,1244 GEnie: R.ROBERTS10
woods@eci386.uucp (Greg A. Woods) (12/28/90)
In article <2829@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: > In <350@metran.UUCP> jay@metran.UUCP (Jay Ts) writes: > > >Nonsense. AT&T's manual set for System V/386 r3.2 (published by Prentice > >Hall) work fine for ESIX. You can order them from you local bookstore. > > Two problems. 1. AT&T's manauls do not include anything about > sendmail, TCP/IP, and associated programs such as remsh, ftp, rlogin, > and slconfig. 2. AT&T's manuals are generally of poor quality. Well, since AT&T didn't bundle any of the TCP stuff into UNIX System V Release 3.2, I don't doubt the manuals are devoid of information about it. If you have the manuals for the Networking package, I think you'll find further information. Certainly ESIX and ISC deliver supplementary manuals for this stuff when you buy the appropriate package. As for the AT&T quality, you obviously have narrow experience with computer manuals. They are of relatively high quality, being reasonably free of bugs, and reasonably complete, and have understandable organization. They are certainly orders of magnitude better than the SysVr2.2 manuals! -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP ECI and UniForum Canada +1-416-443-1734 [h] +1-416-595-5425 [w] VE3TCP Toronto, Ontario CANADA Political speech and writing are largely the defense of the indefensible-ORWELL
jackv@turnkey.tcc.com (Jack F. Vogel) (12/28/90)
In article <1990Dec27.191554.21098@ism.isc.com> robinro@bomber.ism.isc.com (Robin Roberts) writes: >Have you considered IDE instead of ESDI? I put a 200meg IDE drive with 1272 >cylinders on my machine running ESIX rev B [two revisions out of date...] ^^^^^^^^^^ >Robin D. Roberts | <This space closed for remodeling. Watch for >Interactive Systems Corp. | a new witty quotation scheduled to open in ^^^^^^^^^^^^^^^^^^^^^^^^ Egad, this guy works for ISC and yet advertises running the competitor's software! Is this bad press or what :-}! Naturally, I have an excuse, if turnkey were a 3090-600 of course I would ONLY be running AIX370 :-} :-}!! Disclaimer: What, me speak for the company? Surely you jest :-}! -- Jack F. Vogel jackv@locus.com AIX370 Technical Support - or - Locus Computing Corp. jackv@turnkey.TCC.COM
larry@nstar.rn.com (Larry Snyder) (12/28/90)
robinro@bomber.ism.isc.com (Robin Roberts) writes: >tneff@bfmny0.BFM.COM (Tom Neff) writes: >>Anyway, memory is so damn cheap these days. My only beef is that, for a >>UNIX release packing so many additional files, SVR4/386 doesn't have better >>support for huge ESDI disks. It chafes to have to throw away 100MB of >>my Maxtor just to keep upder 1024 cylinders. I would like to see this >>addressed in a future rev. >Have you considered IDE instead of ESDI? I put a 200meg IDE drive with 1272 >cylinders on my machine running ESIX rev B [two revisions out of date...] >and it sees all the cylinders. Which is more than I can say for the MSDOG >4.01 fdisk ... better yet if one wants a screaming system - SCSI - the 1542B remaps the drives to have 64 heads - -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar.rn.com, uunet!nstar!larry, larry%nstar@iuvax.cs.indiana.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
robinro@bomber.ism.isc.com (Robin Roberts) (12/29/90)
In article <1990Dec28.080341.8331@turnkey.tcc.com> jackv@turnkey.TCC.COM (Jack F. Vogel) writes: >In article <1990Dec27.191554.21098@ism.isc.com> robinro@bomber.ism.isc.com (Robin Roberts) writes: > >>Have you considered IDE instead of ESDI? I put a 200meg IDE drive with 1272 > ^^^^^^^^^^ >>Robin D. Roberts | <This space closed for remodeling. Watch for >>Interactive Systems Corp. | a new witty quotation scheduled to open in > ^^^^^^^^^^^^^^^^^^^^^^^^ > >Egad, this guy works for ISC and yet advertises running the competitor's >software! Is this bad press or what :-}! Naturally, I have an excuse, if >turnkey were a 3090-600 of course I would ONLY be running AIX370 :-} :-}!! > >-- >Jack F. Vogel jackv@locus.com >AIX370 Technical Support - or - >Locus Computing Corp. jackv@turnkey.TCC.COM Well Jack certainly had fun with me 8-). Good shot as a matter of fact! I do not run ESIX at Interactive. My ESIX experiences predate my employment at Interactive. I was attempting to provide my assistance to the orig poster about something I had previous experience with. I did not intend and do not now to discuss the relative merits of ESIX vs. Interactive products. That would not be appropriate. Suffice it to say that I run Interactive products both at work and on my personal machine now. I look forward in the future to learning which of Locus' competitors Jack Vogel has previous experience with . 8-) -- Robin D. Roberts | <This space closed for remodeling. Watch for Interactive Systems Corp. | a new witty quotation scheduled to open in Calabasas, Calif. | the Spring of 1991! > Internet: robinro@ism.isc.com CompuServe: 72330,1244 GEnie: R.ROBERTS10
carson@point.UUCP (Carson Wilson) (12/29/90)
I am disappointed that NOBODY has dared to comment publicly on my post about "'386 Unix Wars." However, I did receive quite a bit of private mail in response to my message. Most of the respondents expressed a desire to remain anonymous. I suppose I should have expected this. Anyone qualified to give an educated opinion on the various brands of i386/i486 Unix available most likely has already invested large amounts of cash in one package or another, and the support staffs of SCO and Interactive both monitor this network. Nonetheless, below are excerpts from the private mail I've received so far, edited for anonymity. Hopefully they will spur others to add to the discussion. I haven't invested in an operating system yet, so perhaps I'm in the unique position of being able to post my opinions publicly. So far my impression is that ISC emphasizes technical excellence above all else (making developers happy, but alienating end users) while SCO emphasizes marketing above all else (making end users and retailers happy, but alienating developers). *** Response #1: ************* For whatever it's worth.... my comments. I work at SCO. > 1) Relative merits of Xenix vs. Unix. XENIX is SVID and SVVS compliant pretty much. It has no NFS, no FFS, no FSS (i.e., can only mount XENIX file systems), no CDROM support, limited support for shared memory. It's cheap, small, and mature code (The new 2.3.4 version has ksh, fast SCSI and some other benefits). It will be supported indefinitely. If you believe that real standards are de facto, then XENIX wins hands down over all others. (over 250,000 sold). > 2) Experiences of end users with SCO, Interactive, and other firms. I've only used SCO. The current SCO UNIX 3.2 version 2 is pretty solid and fast. Quite a few peripherals are supported, and it's backward compatible for XENIX apps. The best buy is Open Desktop, runtime at $995 list. > this topic far more actively while we still have a chance to determine the > direction desktop Unix will take. If we allow market forces alone to > decide which standards succeed, we may be disappointed in the long run. SCO has been successful at listening. We dont really do much else except shoot ourselfs in the foot occasionally (as with C2). Pls dont quote me. Thx. Good luck! I agree that the more discussion the better. I know that SCO, at all levels, welcomes and participates in these discussions, but we cannot speak out on the net too much for the obvious reasons. *** Response #2: ************* My reading of the situation is that if you are looking for a production platform, SCO is more stable and better supported. If you want an OS that is "just like my 3B2," you'll prefer Interactive. The point I'm trying to make is that SCO has a lot more "value added" features. Those that need to use several different Sys V hardware platforms and don't have the time to learn about the "new improved" system administration methods of SCO (for instance) will prefer Interactive. Some of SCO's value added features are of debatable value -- see the ongoing discussion of C2-like security -- but the point is that SCO is commited to enhancing and supporting the System V OS. My recommendation is to go with SCO unless you specifically need compatibility with something else. *** Response #3: ************* My main recommendation is to stay away from Interactive Systems Corp. They have arguably the worst technical support I have ever seen (and I've seen some bad support operations over the years). Not only are they unlikely to help you with your problem, they are likely to be very rude while they do so. There have been countless horror stories here of the form, ``I called ISC with problem XYZZY, they said they would work on it, my thirty days of free support are over with no fix yet and when I call them they say my thirty days are up and I'll have to buy a support contract.'' Then they usually hang up immediately. Our experiences with ISC have been somewhat different, but have evidenced similar behavior, and it is getting much worse, not better. In fact, it is so bad I ask that if you quote me to the net I ask that you not use my name or my company's name. Please be very careful about this. We still occassionally need to talk to people at ISC, and they seem to take criticism very personally there. (At one time we sold ISC almost exclusively, now we try to avoid it at all costs. That's a shame, their product has a lot to offer, they were first in many areas (host based TCP/IP, and X Windows to name but two) in their product category. They still have what is arguably the best X windows product around. But it just isn't worth it. I have seen a comment in this newsgroup that their ISV support is much better than their end-user support. I can't comment on whether that is true. As for SCO, it is a decent product, and we have found their technical support to be excellent. (We are a distributor, or some such, as an end-user your mileage may vary.) They have free mailing lists and a newsgroup and seem very responsive to questions asked there. I have some concerns about SCO. Many have complained about their C2 security. I share these complaints, although I have learned to live with it, I would much rather be able to delete it entirely. There X Windows is primitive and slow compared to Interactive's. It also sometimes seems like you are joining the version-of-the-month club with SCO, which is probably a direct consequence of their being as esponsive to user complaints as they are. More recently, products based on Unix V.4 are available from several vendors including Dell, UHC, Microport, and Intel. We just bought a copy of Dell, and it looks quite solid, although the X Windows is again not up to ISC's standards. I personally think V.4 is going to be the way to go in the future, but it may be a little premature today. Significantly, ISC's telnet daemon has problems with V.4 telnet clients. This is because of something ISC did, and is another strike against ISC. I guess this sums up to be a recommendation for SCO. Especially if you are less interested in X. They have some definite features including support for WD7000 SCSI adapters (our favorite, despite Adaptec's dominance) and a CD-ROM file system. About the only down side is their C2 security and (to some extent) their insistence on mmdf over sendmail. (But we use neither -- smail3.1.19 is the way to go, and we have compiled for ISC and SCO.) Oh yes, you asked about Xenix. Xenix seems to be a thing of the past. SCO keeps threatening to drop support for it. Then the existing users complain and SCO promises they won't do that as long as customers who want to continue using it exist in sizable numbers. Nonetheless, it now seems pretty low on the support food chain (i.e. it is the last to get the latest enhancements) and the chances of being orphanned in the next few years probably rule it out. Xenix was THE system for 286 boxes. I think its time has passed. (I also suspect a similar result for V.3, but that will probably take some years.) Hope this helps. Maybe I'm being paranoid about wanting my quotes on ISC to be anonymous, but I'd definitely appreciate your not including my comments in any posting or email without deleting references to my name and organization. We've had a lot of experiences that lead me to believe we are being singled out as a ``bad organization''. We once had them refuse to ship us an update because ``those guys find too many bugs''. I'd rather not risk alienating the few people there who still look out for us. (What a shame it has come to that.) *** Response #4: ************* ... Support from the vendor (for the retailer) is important, and ISC has definitely been taking hits for that lately. They are under a lot of fire over their new (4-5 months) policy of charging an additional fee for support to vendors of their products. News flash -- SCO ALWAYS did this! ... Buy what you want. The real bottom line though, is buy from someone who will support you. You're going to need it. *** Response #5 ************** I hope this helps. I installed SCO UNIX V/386 on a 80486 box app. 3 months ago. Whatever you do, if you go the SCO route make sure you get version 3.2.2. I had the most horrible problems with 3.2.0 and 3.2.1. Also, remember that SCO is a "trusted" systems conforming to the C2 security level of your DoD. This can be good ot bad, dependent of what you expect of security. If you want tight security, it's great, if you like to do some hackking around, it's terrible because of the things you canNOT do.
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (12/29/90)
As quoted from <51823@bigtex.cactus.org> by james@bigtex.cactus.org (James Van Artsdalen): +--------------- | In <355@metran.UUCP>, jay@metran.UUCP (Jay Ts) wrote: | > Job control, line editing? Do you think that office workers use the shell? | > Mostly, they are entering data and making menu selections. | | Sounds like their existing software is Mess-DOS. +--------------- Most of our (Telotech, no relation to ncoast) customers run either Uniplex or MS Word, either Informix or Unify 2000, and/or RealWorld accounting --- all from AOM menus. All Unix. And very few of them ever use the shell or would know what to do with job control (indeed, I expect "bug reports" from customers on ACS5000's when SCO Unix 3.2.2 comes out --- we got them on the AViiON, which has job control). Most office workers couldn't care less about the shell. They want an easy-to- use menu system, the OS is irrelevant. These are neither sysadmins nor gurus; they just want the silly computer to do what they tell it to do, and prefer that telling it what to do be as easy as possible. (Which I can't fault; after all, my primary home machine is a Mac.) ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
karl@ddsw1.MCS.COM (Karl Denninger) (12/31/90)
In article <277bb1de-8ae.1comp.unix.i386-1@point.UUCP> carson@point.UUCP (Carson Wilson) writes: >I am disappointed that NOBODY has dared to comment publicly on my post >about "'386 Unix Wars." However, I did receive quite a bit of private >mail in response to my message. Most of the respondents expressed a >desire to remain anonymous. I suppose I should have expected this. >Anyone qualified to give an educated opinion on the various brands of >i386/i486 Unix available most likely has already invested large amounts >of cash in one package or another, and the support staffs of SCO and >Interactive both monitor this network. Well, that's what you should have expected with the way you phrased your question and the subject of your posting! >Nonetheless, below are excerpts from the private mail I've received so >far, edited for anonymity. Hopefully they will spur others to add to >the discussion. I haven't invested in an operating system yet, so >perhaps I'm in the unique position of being able to post my opinions >publicly. So far my impression is that ISC emphasizes technical >excellence above all else (making developers happy, but alienating end >users) while SCO emphasizes marketing above all else (making end users >and retailers happy, but alienating developers). Actually, there are a few other differences. I'll comment as I go. >*** Response #1: ************* > >For whatever it's worth.... my comments. I work at SCO. > >> 1) Relative merits of Xenix vs. Unix. >XENIX is SVID and SVVS compliant pretty much. It has no NFS, no >FFS, no FSS (i.e., can only mount XENIX file systems), no CDROM >support, limited support for shared memory. It's cheap, small, and >mature code (The new 2.3.4 version has ksh, fast SCSI and some >other benefits). It will be supported indefinitely. If you believe >that real standards are de facto, then XENIX wins hands down over >all others. (over 250,000 sold). Correct. Xenix is also damn solid. As for "limited support of shared memory" don't tell that to any of my SVID-style applications which use it VERY heavily without trouble! Older versions were prone to panicking when heavy use was made of S5 IPC features; 2.3.2 and beyond should be ok (2.3.2 is known to be ok here). >> 2) Experiences of end users with SCO, Interactive, and other firms. >I've only used SCO. The current SCO UNIX 3.2 version 2 is pretty solid >and fast. Quite a few peripherals are supported, and it's backward >compatible for XENIX apps. The best buy is Open Desktop, runtime at $995 >list. NO! Open Desktop has a few (actually, several) problems: 1) It's "open" about the same way that Sun's Openwindows is -- that is, a window manager with an X environment which others can write to IF they want to. It's definately not MOTIF! Ask about something like Framemaker for ODT -- then try to run that copy on someone else's X server, such as ISC's or Dell's. Good luck! Also, that $995 is somewhat of a loss leader. Expect to spend another $1000 on a development system (which anyone will need if they want to program) and another $1000 by the time you get everything else you might want (like a NFS server, etc). Also, that $995 is a single-user (perhaps actually two user), single-workstation license. Their "C2" security, which can't be turned completely off, will frustrate you to no end. Forget about doing things "your way" -- you get to do it "the secure way". C2 could easily be SCO's biggest mistake in 10 years. The concept is good -- the mandatory nature of it bites! >>this topic far more actively while we still have a chance to determine the >> direction desktop Unix will take. If we allow market forces alone to >> decide which standards succeed, we may be disappointed in the long run. > >SCO has been successful at listening. We dont really do much else except >shoot ourselfs in the foot occasionally (as with C2). > >*** Response #2: ************* > >My reading of the situation is that if you are looking for a >production platform, SCO is more stable and better >supported. If you want an OS that is "just like my 3B2," >you'll prefer Interactive. Note that SCO also has had trouble with stability with their Unix 3.2. I have a customer who had HORRIBLE problems with 3.2.0, and it took him months to get SCO to listen to him at all! >Some of SCO's value added features are of debatable value -- >see the ongoing discussion of C2-like security -- but the >point is that SCO is commited to enhancing and supporting >the System V OS. System V is a specification of features and functionality. When you remove some of that by adding something like C2 which you can't disable, it isn't really System 5 anymore! >*** Response #3: ************* > >My main recommendation is to stay away from Interactive Systems Corp. >They have arguably the worst technical support I have ever seen (and >I've seen some bad support operations over the years). Not only are >they unlikely to help you with your problem, they are likely to be >very rude while they do so. There have been countless horror stories >here of the form, ``I called ISC with problem XYZZY, they said they >would work on it, my thirty days of free support are over with no fix >yet and when I call them they say my thirty days are up and I'll have >to buy a support contract.'' Then they usually hang up immediately. SCO has done the same kind of thing. BOTH companies seem to feel that you have no right of expectation to a bug-free product, or one which conforms to the appropriate documentation and standards in the industry -- unless you buy a nice expensive support contract. Welcome to the world of Desktop Unix. The entry price is $1499; please fork up an additional $900 per year to make sure it works once you have given us our money. >As for SCO, it is a decent product, and we have found their technical >support to be excellent. (We are a distributor, or some such, as an >end-user your mileage may vary.) As an end user SCO has the same problem that ISC has. Fork up the cash or forget about BUG FIXES. Folks, support and bug fixes are TWO DIFFERENT ISSUES. Asking how to add an account is support. Getting a fix for a persistant PANIC problem is a BUG FIX. The first companies should and do charge for. The second is something I should be able to get for free, since I paid for a WORKING package, not "15 diskettes with whatever happens to be on them". >Oh yes, you asked about Xenix. Xenix seems to be a thing of the past. >SCO keeps threatening to drop support for it. Then the existing users >complain and SCO promises they won't do that as long as customers who >want to continue using it exist in sizable numbers. Nonetheless, it >now seems pretty low on the support food chain (i.e. it is the last to >get the latest enhancements) and the chances of being orphanned in the >next few years probably rule it out. Xenix was THE system for 286 >boxes. I think its time has passed. (I also suspect a similar result >for V.3, but that will probably take some years.) Of course Xenix is low on the food chain - it doesn't need to be fed! Xenix has ONE big advantage -- it works, and is ROCK solid. I would still recommend it for business use, as you know what you have to spend up front. Now, if you need solid TCP/IP, any form of NFS, or a few other things then it's no longer a viable option. For those who want a single-station system with lots of terminals plugged in, it's still (and has been for a couple of years) a winner. >*** Response #4: ************* >... >Support from the vendor (for the retailer) is important, and ISC has >definitely been taking hits for that lately. They are under a lot of fire >over their new (4-5 months) policy of charging an additional fee for >support to vendors of their products. News flash -- SCO ALWAYS did this! >... Correct. SCO has always charged their dealers for support. So has ISC. As they well should -- anyone who can't read the documentation needs to be hit in the wallet for "babysitting". However, system-crashing problems are another matter entirely, and one that vendors have addressed in the same was as "support". They ARE NOT THE SAME ISSUE! 'Nuff said. I still like ISC despite the problems with getting help. 2.2 is a pretty solid release, with a relatively short exception list. -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Public Access Data Line: [+1 708 808-7300], Voice: [+1 708 808-7200] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"
sef@kithrup.COM (Sean Eric Fagan) (12/31/90)
In article <1990Dec30.170614.22573@ddsw1.MCS.COM> karl@ddsw1.MCS.COM (Karl Denninger) writes: >Correct. Xenix is also damn solid. And small, and relatively fast. (Some comments about this below.) It's simple, in many ways, and doesn't have as many features as 3.2. But that may be what you want. In which case, I'd say go for xenix. >Also, that $995 is somewhat of a loss leader. Expect to spend another $1000 >on a development system (which anyone will need if they want to program) and >another $1000 by the time you get everything else you might want (like a NFS >server, etc). Also, that $995 is a single-user (perhaps actually two user), >single-workstation license. Well, some comments here. First of all, ODT is being targeted as a workstation, but not completely. A desktop X machine, with local processing, I guess is what you would call it. (Face it, you can get a '386SX, some semi-decent display, a bit of ram and a smallish disk, for only a little more than most X terminals. Granted, the display size of the X terminals is larger, but that isn't the only issue.) Since that is the case, having more than two users doesn't make sense for that configuration (and, in fact, to get that price, it *needs* to be a two-user license). Similarly, not everybody in your company, where you've just bought 100 copies of ODT, is going to program; most likely, you're going to have one or two people doing the programming and support for everyone else. >Their "C2" security, which can't be turned completely off, will frustrate >you to no end. Forget about doing things "your way" -- you get to do it >"the secure way". C2 could easily be SCO's biggest mistake in 10 years. >The concept is good -- the mandatory nature of it bites! It's going, it seems. Various messages from the net alone say that the next version of 3.2 from SCO will at least potentially be non-C2. That is, you will at least be able to completely disable the C2 stuff, if it isn't shipped like that. >Note that SCO also has had trouble with stability with their Unix 3.2. I >have a customer who had HORRIBLE problems with 3.2.0, and it took him months >to get SCO to listen to him at all! I agree with 3.2.0. Note, however, that 3.2v2 is the latest release, and that's what kithrup is running (do you think I would run something at home that I didn't trust?). Also, at work, we're using 3.2v2 in all of systems engineering; that is, the machines we get mail on, and read news from, and work on, are 3.2v2 (well, the development machines are often a strange hybrid 8-)). 3.2v2 is fairly robust and stable. kithrup has panic'ed twice, once due to a badly written device driver (my own, unfortunately). I am *happy* with 3.2v2, and I *like* it. And, once again, this is stated as someone who *uses* it, not as someone who produces it. >SCO has done the same kind of thing. BOTH companies seem to feel that you >have no right of expectation to a bug-free product, or one which conforms to >the appropriate documentation and standards in the industry -- unless you >buy a nice expensive support contract. Well... look at it another way. Support personel are expensive. Development people are expensive (as are all the people to back them up: production, documentation, sales, managers, internal support, hardware maintainance, etc.). So... would you rather have to pay $8000 for a single license, and get the support you want, or pay $1000, and get somewhat limited support? Note that people at SCO and ISC *do* read this group, and some of them (us) are very protective towards their (our) respective products. While not everyone has access to usenet, it *is* something. (I've also gotten email from people who had other people give them my name, and I do try to help. It's not my highest priority, but it is something I pay attention to.) I've been told that SCO has lots of its SLS's available for free (read about them in the monthly postings). I am sure ISC does something similar, even if my biases do get in the way 8-). The upgrade from 3.2.0 to 3.2v2 costs money (unless you bought 3.2.0 after a certain date, if I remember correctly); this is largely because 3.2v2 added lots of features, not just fixing bugs. In particular, 3.2v2 is *lots* faster in terms of filesystem performance, and in other areas as well. (It outperforms xenix in some respects, now.) >[bug fixing] is something I should be able to get for free, since I paid for a >WORKING package, not "15 diskettes with whatever happens to be on them". For the most part, I agree. However, if you are the only customer experiencing this panic, and it is not readily reproducible, why should a company spend thousands of dollars to fix it? I know it sounds callous, but money has to come from *somewhere*. And, of course, see the comment about SCO's SLS's above. >However, system-crashing problems are another matter entirely, and one that >vendors have addressed in the same was as "support". They ARE NOT THE SAME >ISSUE! Agreed. And, again, the 'support' part of it comes from the fact that people, who get paid, are needed just to interface with you while describing the problem. Then they need to test it, and, if it behaves as indicated, they then get back to you and say, 'Yep, it's a problem, we're putting an engineer on it right now.' Now, if it *is* a system-crashing problem, that more than two or three people run into, it is probably worth it. But what if it *isn't* a problem? That your hardware is what's causing it? Are you going to fork over the money that the company spent afterwards? No? Then how do you expect the company to stay in business? Work out the math yourself; it's not that hard. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
ronald@robobar.co.uk (Ronald S H Khoo) (12/31/90)
sef@kithrup.COM (Sean Eric Fagan) writes: > First of all, ODT is being targeted as a > workstation, but not completely. A desktop X machine, with local > processing, I guess is what you would call it. What's wrong with using Xenix for this, other than the outrageous "extra" cost of Streams in order to be able to buy TCP for it ? Other than "No NFS" I suppose. Hrrmph. The *only* piece of functionality that you don't get from Xenix. And that's a *marketing* decision isn't it ? With all the mention of FFS in the various bits of Xenix TCP documentation, it can't be that most of the work to put it in hasn't been done ? Not that it's a particularly difficult hack anyway, compared to some of the SYSV->Xenix hacks SCO have already done, it seems (looking from the sidelines :-) > Granted, the display size of the X > terminals is larger, but that isn't the only issue.) aww, 16" SVGA/8514 screens for PCs aren't *that* expensive anymore. Especially not if you only want monochrome. I could live with non-interlaced 1024x768 16" mono... H'm. When the free X for Xenix patches come out next month (cross fingers) maybe that'll be an incentive to swap back to Xenix ... > I am *happy* with 3.2v2, and I *like* it. And, once again, this is stated > as someone who *uses* it, OK Sean, I believe that, but have you considered how much happier you might be running SVR4 instead ? Hey, that's a *good* idea...... -- ronald@robobar.co.uk +44 81 991 1142 (O) +44 71 229 7741 (H)
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (12/31/90)
In article <1990Dec30.170614.22573@ddsw1.MCS.COM> karl@ddsw1.MCS.COM (Karl Denninger) writes: | Correct. Xenix is also damn solid. As for "limited support of shared | memory" don't tell that to any of my SVID-style applications which use it | VERY heavily without trouble! | | Older versions were prone to panicking when heavy use was made of S5 IPC | features; 2.3.2 and beyond should be ok (2.3.2 is known to be ok here). That's been my experience. | 1) It's "open" about the same way that Sun's Openwindows is -- that is, | a window manager with an X environment which others can write to IF | they want to. It's definately not MOTIF! | | Ask about something like Framemaker for ODT -- then try to run that copy | on someone else's X server, such as ISC's or Dell's. Good luck! I'm not sure what you mean about that one... I have run my WM on ODT and clients on lots of other machines (Sun, Ultrix, Convex, Xenix, Stardent) and run the WM from other machines and used ODT applications, both without unexpected problems. If you mean that SCO is on X11R3 and the world is on X11R4 about to go to X11R5, that's true. I've given up on that issue, they have told me about enhancements coming for X11R3, and asked for a non-disclosure agreement to get a copy of the *public domain* Athena widgets for ODT. However, the disk is free, and if it doesn't cost you $500 to run the agreement past a corporate lawyer you can just ask for it. | | Also, that $995 is somewhat of a loss leader. Expect to spend another $1000 | on a development system (which anyone will need if they want to program) and | another $1000 by the time you get everything else you might want (like a NFS | server, etc). Also, that $995 is a single-user (perhaps actually two user), | single-workstation license. For someone who wants to run applications it's just perfect. It needs no development set or anything else, and you can have one server with shared applications mounted. A bargain, if it it what you need. I'm told that the price will go up a lot in 1991, and if that's tre it may effect our vendor, since we budgeted for a certain price we get by buying in quantity from a VAR. | SCO has done the same kind of thing. BOTH companies seem to feel that you | have no right of expectation to a bug-free product, or one which conforms to | the appropriate documentation and standards in the industry -- unless you | buy a nice expensive support contract. SCO has a nice free machine loaded with SLS's to solve many of the common problems. They have released things as complex as a new C compiler there. Many bug fixes can be gotten there. | Folks, support and bug fixes are TWO DIFFERENT ISSUES. | | Asking how to add an account is support. | Getting a fix for a persistant PANIC problem is a BUG FIX. | | The first companies should and do charge for. | | The second is something I should be able to get for free, since I paid for a | WORKING package, not "15 diskettes with whatever happens to be on them". I agree completely! I have also asked for an option of four hours of support anytime for a year, instead of all the time I can use in 30 days. This would allow me to ask the tricky questions when they come up. | Xenix has ONE big advantage -- it works, and is ROCK solid. I would still | recommend it for business use, as you know what you have to spend up front. Yes, yes, yes! And it runs in at least 2MB less memory than SCO UNIX. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
sef@kithrup.COM (Sean Eric Fagan) (12/31/90)
In article <1990Dec31.053142.10444@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes: >OK Sean, I believe that, but have you considered how much happier you might >be running SVR4 instead ? Hey, that's a *good* idea...... Actually, yeah, I have. And I've also considered how much happier I might be if I ran xenix. Or ISC. Or (*gasp*) Microport. Or Dell. Or Esix. Etc. My reasons for going with SCO aren't all the same as everyone else's (I mean, not everyone knows the home phone number of quite a few of the kernel engineers 8-)), but I think some of them are relevant. And, as has been demonstrated time and time again, quite a bit of what I want matches quite a few people's desires. Faster kernel, more reliable system, smaller kernel (quite possibly synonymous with the faster part 8-)), bugless devsys, etc. Some of the reasons I do use SCO UNIX instead of some other one (including Mach or BSD, which I can get through various means): familiarity with the product (as if you couldn't guess 8-)), stability, features I want/like, ease of installation, ease of use, ease of maintainance. kithrup has three main uses: email, playing around, and news (roughly in that order of importance). A friend set up the MMDF system while I was in Canada for a while, so I really cannot say how easy or difficult it was. He said it was fairly easy. I've since changed it a few times, in relatively minor ways. While I admit the documentation could be better (all I had was the online stuff), it wasn't too hard. (I think my major gripe with it was the fact that I ended up, at one point, with a 25Mb log file, which had eaten up about three quarters of my available disk space. *grrr* Hooray for the quot command! 8-)) For development, I now only do '386 development. I use both /bin/cc and gcc (with a slight emphasis on the latter, recently, since I've been doing lots of inline assembly lately), and have no real non-standard libraries (I think I replaced the opendir et al in libx.a with the ones from libc, and did some appropriate changes on the header files to match). I run into about as many problems as I did on my Sun-3/50 three years ago, when trying to port stuff from the net. Most of the time, I end up trying to teach programs that BSD systems aren't the only ones with SIGTSTP and company... For news, well, I run trn, rn, and C News. Fairly simple to get working. I spent about three hours worth of work on C news, including compiling times. Using cc, not gcc, incidently. The couple of problems I ran into, I mailed to Henry, and got some feedback. Despite my diatribe against C2, I really do have to admit I run into it rarely. (When I do, I might scream at my snake for a few minutes, though... 8-) 8-)) If it were just a *little* bit more unobtrusive, I think the only reason I would notice it's there is because I use sysadmsh to create users instead of vi, mkdir, and cp. Anyway, kithrup is a very stable machine. uptime reports: 1:57am up 11 days, 6:15, 6 users, load average: 0.14, 0.02, 0.00 (the six users are: root, sef, sef, sef, news, sef.) It was brought down 11 days ago so that I could install an FPU, and move some of the cars around to fit better. Four of those days, I wasn't here at all, and it still handled mail and news (including forwarding three messages to some people who are no longer around to play with kithrup). It took me a shade less than 12 hours to compile the entire X11R4 distribution, a couple of weeks ago (without the FPU, I should add). Although not incredible, I do believe that is credible performance, especially, again, while running other tasks (including news, email, some playing around, and being used as a terminal). Look, this is a bit longer than I'd intended. All I'm trying to say is that 3.2v2 is, I think, worthwhile. I like it, and I *have* considered the alternatives. None of them offers me enough benefits to go with the risk (i.e., a non-SCO supplier [including, potentially, myself!]). About the only thing I want on kithrup right now, I think, is dynamic linking, and I've got a couple ideas about that anyway... This was not intended to be a sales plug or anything. Just reasons why I'm satisfied, for the most part, with what I have. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (01/01/91)
In <1990Dec23.160807.3207@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes: >You go on and on about how bad the permuted index is... ^^^ Maybe I'm looking at the wrong UNIX derivative, but: (a) There is no such thing as *the* permuted index; there are many of them, and the user's first challenge is to find the right one. Also, there are many manuals for which there is no entry in any permuted index, because there are many things that are documented in manuals that are not considered to be part of the traditional "manual pages" (the "programmer's manual" entries). The new SVR4 documentation is even more bizarre than usual: Each volume contains three to five different "indexes" of varying quality, and to find anything in a volume one must look at all of these "indexes" and then do some additional browsing. (b) A permuted index based solely on a title cannot be an effective index. It may be desirable to have many index entries for a given topic. It is not always likely that there will be enough words in the title of the relevant "manual page" to yield all these entries. -- Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi
geoff@Veritas.COM (Geoffrey Leach) (01/01/91)
From article <1990Dec30.193929.16181@kithrup.COM>, by sef@kithrup.COM (Sean Eric Fagan): > In article <1990Dec30.170614.22573@ddsw1.MCS.COM> karl@ddsw1.MCS.COM (Karl Denninger) writes: >>SCO has done the same kind of thing. BOTH companies seem to feel that you >>have no right of expectation to a bug-free product, or one which conforms to >>the appropriate documentation and standards in the industry -- unless you >>buy a nice expensive support contract. > > Well... look at it another way. Support personel are expensive. > Development people are expensive (as are all the people to back them up: > production, documentation, sales, managers, internal support, hardware > maintainance, etc.). So... would you rather have to pay $8000 for a single > license, and get the support you want, or pay $1000, and get somewhat > limited support? In essence, Sean says that the Karl (as an SCO customer) has no right to expect that their product should work "as advertised", given their price point which Sean describes as, "somewhat as a loss leader." If SCO (or any oem!) had a disclaimer on their shrink wrap packages that read something like this, I'd be inclined to agree. Notice to Purchaser. SCO makes no warranty, express or implied that this product functions according to the documentation which SCO furnishes as part of the package. The purchasor has no rights whatsoever. The purchasor must purchase a support contract before SCO will even speak to him concerning the use, functioning or operation of this product. Its been some time since I opened any SCO products, but I think I would remember seeing it if it was there. I expect ISC is no better. To say nothing of ATT! Their shrink wrap 386 SVR3 comes with free support for something like three months. But try to collect. If you don't have a piece of their hardware, their service organization won't talk to you. (That's my experience as of almost two years ago. Perhaps they've changed.) Rather than having a discussion of what <your oem> has done to you lately, perhaps we could shift the discussion to what are reasonable expectations for product labeling and performance. Keep in mind, that we are talking about low-end product here. Stuff that competes with OS2. Many -- perhaps the majority -- of potential purchasors are upgrading. They have no knowledge of UNIX and have never heard of UseNet. Do the oems have any responsibilities, or is it buyer beware? My response to this question is radical. I believe that it is in the economic self-interest (albeit long term) of the oem to provide full support as part of the cost of the package. In other words, "fre" support. The model I have in mind is that used by Word Perfect, who (as of a year ago, at least) had an 800 number that would talk to you about any aspect of the product whatsoever.They didn't even attempt to eliminate bootleg copies. As I see it, the basic advantage to the vendor of such a policy is that it builds good customer relations. Would the vendor perfer to have a customer that loves him and his product -- and will, as a result, be willing to put up with a lot of hassle should a bad release ever get out -- or one that is looking for any way at all to replace the vendor's product with a new one? Perhaps less obvious, but still a real advantage, is that the vendor is forced to face up to the necessity of producing a quality product. Bugs become a cost to the organization rather than a profit center. Unfortunately, the computer industry is run, for the most part, by bean ounters. Anything that reduces the cost of the product is OK by them. Well, I disagree. If we don't know that a buggy product is not a product at all, then we are making a fatal mistake. If we don't learn that if we ship products (hardware or software) that do not live up to the customers' expectations for quality, then our industry will go the way of the American automobile industry. Geoff Leach
carson@point.UUCP (Carson Wilson) (01/01/91)
Here's another response to my request for opinions about i386 Unix: ************************** From: ddsw1!riacs!rutgers!sirius.ctr.columbia.edu!david (David Freidlander) Date: Sun, 30 Dec 90 00:35:59 -0500 To: riacs!lll-winken!ddsw1!point!carson (Carson Wilson) In-Reply-To: carson@point.UUCP's message of 28 Dec 90 22:00:03 GM Status: O Just thought I should respond to your posting. One of your correspondents says he(she) has had very bad experiences with Interactive Systems. I can only say that my experiences have been quite the opposite. A real human being answers the phone very quickly, and this person almost always has an answer. If they don't have an answer, they DO get back to you, invariably. I have been working with Interactive for about 2 years now. Possibly this depends partly on the area of the country in which you are. I am in New York, and my support is from the office in New Hampshire. This part (I don't know how large a part it is) has recently broken away and formed its own company called "Multi-User Systems", which makes me think that something unusual may have been happening there. For the record, I have been selling Interactive Unix as well, so perhaps I'm an interested party. But I will say that their support is a major reason why I have continued to work with them. You can quote me on this if you want, with or without my name. David Friedlander
barton@holston.UUCP (Barton A. Fisk) (01/01/91)
In article <1990Dec30.170614.22573@ddsw1.MCS.COM> karl@ddsw1.MCS.COM (Karl Denninger) writes: >In article <277bb1de-8ae.1comp.unix.i386-1@point.UUCP> carson@point.UUCP (Carson Wilson) writes: > >As an end user SCO has the same problem that ISC has. Fork up the cash or >forget about BUG FIXES. > This is just plain FALSE, bugfixes are freely available via the uucp box "sosco". We all have our faults and SCO is not without theirs, but let's give credit where credit is due as well. If they (sco) would ever stop this service, then I would scream too, but right now, I'm a happy camper. -- uucp: holston!barton pseudo: barton@holston.UUCP
sef@kithrup.COM (Sean Eric Fagan) (01/01/91)
In article <1990Dec31.213625.5481@Veritas.COM> geoff@Veritas.COM (Geoffrey Leach) writes: >In essence, Sean says that the Karl (as an SCO customer) has no right to >expect >that their product should work "as advertised", given their price point which >Sean describes as, "somewhat as a loss leader." Really? Where did I say that? What Sean says, in essence, is that support is expensive, and I would not expect any vendor to spend too much money on a no-win proposition. If a product just does not work, that's one thing, and I mentioned that. But you seem happier to believe that I think software support should cost lots of money, something I never said. Why don't you try a) reading what I wrote, and b) try dealing with the vendors in question before you start saying how they operate? Or is that too much effort? -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (01/01/91)
As quoted from <1990Dec31.100329.23178@kithrup.COM> by sef@kithrup.COM (Sean Eric Fagan): +--------------- | that order of importance). A friend set up the MMDF system while I was in | Canada for a while, so I really cannot say how easy or difficult it was. He | said it was fairly easy. I've since changed it a few times, in relatively | minor ways. While I admit the documentation could be better (all I had was | the online stuff), it wasn't too hard. (I think my major gripe with it was +--------------- MMDF is one of the things SCO did right. I plan to bring it up on a number of other systems --- it beats sendmail all hollow for ease of maintenance. And the fact that it can handle a pathalias file by itself is nice, too. +--------------- | the fact that I ended up, at one point, with a 25Mb log file, which had | eaten up about three quarters of my available disk space. *grrr* Hooray | for the quot command! 8-)) +--------------- The MMDFIIb #43 distribution on louie.udel.edu is worth getting just for the documentation. There is an automatic log maintenance facility in MMDF, where you set a threshhold size and MMDF will run a program CMDFLDIR/setlogs when a log exceeds that size. "setlogs" is user provided, although there are examples in the distribution; you can use a shell script and pretty much have it do whatever you want. (One of the benefits of having real documentation.) +--------------- | Using cc, not gcc, incidently. The couple of problems I ran into, I mailed | to Henry, and got some feedback. +--------------- Speaking of which.... (Please note that this is NOT an official bug report. I'm still trying to determine the exact problem and will pass it through official channels when I have done so.) I've been building MGR for the system I have to install. (X is just too big and too demanding for the circumstances. A window manager which is complete in 400K has a lot going for it....) Anyway, cc will not compile the bitmap code properly; it looks like a bit-twiddling macro used very often in the code is being mis-compiled by cc. I used gcc instead. (On the other hand, gcc botches the bitblt code completely; I had to use cc to get it to work. And rcc handled *neither* properly.) +--------------- | 8-) 8-)) If it were just a *little* bit more unobtrusive, I think the only | reason I would notice it's there is because I use sysadmsh to create users | instead of vi, mkdir, and cp. +--------------- Far and away, my *biggest* complaint with C2 is that some of the things it does actually *reduce* system security. If I want to su to another account to deal with something (say, bsa -> mmdf), I must become root first. I could make mmdf "owned" by bsa, but what if lenj needs to do some maintenance on it? Or I could make it a normal account and log out and back in, but this reopens security holes closed by the concept of an administrative account. Additionally, the administrative accounts collide with the use of luid's by cron and at: I must either make accounts like mmdf regular accounts or make crontab changes as root directly to the crontab file *and* *then* *reboot* to make cron see it; the "crontab" command uses the luid to determine whose crontab to update, and you can't kill and restart cron without setting its luid. (Or using a hack to start it from init --- hack because cron puts itself in the background, so the process started by init has to fork cron, then sleep and occasionally kill -0 the process to see if it still exists.) The reboot is inconvenient, to say the least (especially on a production system); having to make changes as root pretty much cancels out security. These flaws pretty much make the concept of administrative accounts useless. A pity, as some of the things done in the name of security are d*mned useful. My favorite example of the latter is allowing group "lp" to maintain the spooler system, in conjuction with group vectors so that authorized users can be given group "lp". +--------------- | (i.e., a non-SCO supplier [including, potentially, myself!]). About the | only thing I want on kithrup right now, I think, is dynamic linking, and | I've got a couple ideas about that anyway... +--------------- All it would take to add dynamic linking to COFF is for someone with some time to study the COFF format and write the COFF equivalent of BSD's "ld -A". Someday --- except that things have moved on, and I'll probably wait for SVR4 and ELF if it isn't in there already. ++Brandon (The most frustrating thing about SCO UNIX is that it contains the seeds of greatness. But it BADLY needs fertilizer, and the sh*t that comes with it isn't working....) -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
jeffl@comix.UUCP (Jeff Liebermann) (01/01/91)
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: >In <1990Dec23.160807.3207@virtech.uucp> cpcahil@virtech.uucp (Conor P. >Cahill) writes: >>You go on and on about how bad the permuted index is... >Maybe I'm looking at the wrong UNIX derivative, but: >(a) There is no such thing as *the* permuted index; there are many of >them, and the user's first challenge is to find the right one. Also, Great. Now we have the "index wars". Think of the permuted index as a crude form of what is now called hypertext (or give me a word, and I'll give you a clue). Since the number and size of the manuals, documents, updates, release notes, tutorials, user guides, references, and such tend to grow linearly with code size, the days of the PRINTED index are numbered. Documentation is no longer released with the software, but staggered to meet the realities of printing schedules. A printed permuted index is usually obsolete when the first release notes, updates, and bug fixed arrive. The answer to this problem is in front of your face. The index should be on-line. One should be able to type a keyword and some database should belch the document name, current version, and page references. My illusions are a hypertext like indexer with context sensitive suggestions. The final output should be either a man page or a manual page reference. I've been lobbying for such an on-line index with various vendors and have attracted zero interest. I've suggested to some database vendors that their "demo" database should be an index to their documentation. No interest again. Oh well.... Trivia: From the cover of Radio Shack's latest catalog; "Creating New Standards". I always wondered where standards came from. -- # Jeff Liebermann Box 272 1540 Jackson Ave Ben Lomond CA 95005 # (408)336-2558 voice (408)429-0483 digital pager wb6ssy CIS:73557,2074 # PC REPAIR & RF DESIGN uunet!comix!jeffl ucscc.ucsc.edu!comix!jeffl # universe!milky_way!solar_system!earth!na!us!uunet!comix!jeffl
geoff@Veritas.COM (Geoffrey Leach) (01/02/91)
From article <1991Jan01.000527.14406@kithrup.COM>, by sef@kithrup.COM (Sean Eric Fagan): > In article <1990Dec31.213625.5481@Veritas.COM> geoff@Veritas.COM (Geoffrey Leach) writes: >>In essence, Sean says that the Karl (as an SCO customer) has no right to >>expect >>that their product should work "as advertised", given their price point which >>Sean describes as, "somewhat as a loss leader." > > Really? Where did I say that? You're right. It was Karl. Sorry 'bout that. > What Sean says, in essence, is that support is expensive, and I would not > expect any vendor to spend too much money on a no-win proposition. If a > product just does not work, that's one thing, and I mentioned that. But you > seem happier to believe that I think software support should cost lots of > money, something I never said. > > Why don't you try a) reading what I wrote, and b) try dealing with the > vendors in question before you start saying how they operate? Or is that > too much effort? Well, to answer (b) first. I have delt with the vendors in question, although I'm not entirely sure what the point that you're trying to make is. Are you saying that they're shipping a bug-free product? Or that the problems that Kieth referrs to are unimportant? As to (a), here's the text from your article: "Well... look at it another way. Support personel are expensive. Development people are expensive (as are all the people to back them up: production, documentation, sales, managers, internal support, hardware maintainance, etc.). So... would you rather have to pay $8000 for a single license, and get the support you want, or pay $1000, and get somewhat limited support?" This does sound to me like you think support IS expensive. If you think support shoulod NOT be expensive, then its certainly not apparent. However, its not what you think that's at issue here, and I didn't intend to dump on you. Sorry if it seemed that way. My point was that there seems to be a mindset in this industry that product quality is an economic issue, i.e., that one can "afford" to ship buggy software, because its "too expensive" to get it right. Making a profit center out of product support makes this easier to do. My proposal is that product support should be provided free with the product. If this is felt to be too expensive, then the vendor should take a look at why its expensive. If the reason is that the product has bugs, then the vendor should do a better job of building the product in the first place. If computers were cars, everyone but the Amish would be dead by now.
sef@kithrup.COM (Sean Eric Fagan) (01/02/91)
In article <1991Jan01.183414.19220@Veritas.COM> geoff@Veritas.COM (Geoffrey Leach) writes: >You're right. It was Karl. Sorry 'bout that. 'Sokay. I was tired and cranky when I followed up to your posting. Sorry 'bout that 8-). >This does sound to me like you think support IS expensive. It is. >My point was that there seems to be a mindset in this industry that product >quality is an economic issue, i.e., that one can "afford" to ship buggy >software, because its "too expensive" to get it right. Making a profit center >out of product support makes this easier to do. Yes and no. Yes, one can "afford" to ship buggy code, provided it meets most peoples requirements, because it will never be noticed. Note that, in some cases, it is impossible to prove current software bugfree. >My proposal is that product support should be provided free with the product. And I suggest you take a look at the costs for it. It takes too much money to support everyone, especially when, as I said in another article, it's not necessarily the software vendor at fault. >If computers were cars, everyone but the Amish would be dead by now. Do you expect the person you buy your car from to provide "support" indefinitely? Do you go up to mechanics and ask them detailed questions about what's wrong with your car? Do you give them the keys to the car and ask them to find out what's wrong and fix it? This is, is a lot of ways, quite close to the problem with software, since a large part of the cost is diagnosis. You commented about software not working as advertised. I don't know exactly, since I haven't taken too close a look, but I believe that both ISC and SCO have a list of hardware vendors whose products are known to work with the software. If you go to a third party, or mix things not covered by either party, who should pay for anything that breaks? Software support *is* expensive. I do believe that the approach most vendors take, of offering a limited amount of support with the product, is the correct thing to do (I may have quibbles with the exact details for each, mind you, but the idea is right), because it gives the "average" person, who is most likely to run into problems when setting up the system initially, a chance to get started. For the people who are running into problems all the time, well, they should pay for the time they're using. This is known as capitalism. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
rli@buster (Buster Irby) (01/02/91)
geoff@Veritas.COM (Geoffrey Leach) writes: >My proposal is that product support should be provided free with the product. >If this is felt to be too expensive, then the vendor should take a look at >why its expensive. If the reason is that the product has bugs, then the >vendor should do a better job of building the product in the first place. Your point is well taken. However, you seem to believe that the only problems that people call support for are caused by the vendor. This is seldom the case in a high volume product. A lot of calls to support happen simply because a self styled expert failed to RTFM. Do you believe that vendors should provide free support for self inflicted problems? I do agree that free upgrades (read charges for copying and shipping only) should be provided. Also, there should be no charges when reporting bugs. I also believe that the user must accept some responsibility as well. I do not want to pay a higher price for any product simply because some other people refuse to RTFM. -- Buster Irby (buster!rli)
shwake@raysnec.UUCP (Ray Shwake) (01/02/91)
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) writes: >MMDF is one of the things SCO did right. I plan to bring it up on a number of >other systems --- it beats sendmail all hollow for ease of maintenance. And >the fact that it can handle a pathalias file by itself is nice, too. Consider yourself one of the lucky ones. I've had a few frustrating years working with earlier and more recent versions of the package, and experienced nothing but frustration with the version included in ODT 1.0. Since we distribute our own mailer, it's not like we "need" MMDF, but we did want to see what, if anything, it offered and how well we would work together. As it happens, the more we substituted our own components, the more reliable the box became. The last straw came one morning when I found 104 undelivered messages in the spool directory, but all the tools indicated an empty queue. I'll certainly check out the next version when ODT 1.1 comes out, but for now, it's been purged from our system. As to pathaliasing, we found no way to use the existing paths file; rather we had to create an mmdf-specific variant of same. Given a 1 MB paths file, the variant came to more than 2 MB. We junked it. ---------------- uunet!media!ka3ovk!raysnec!shwake shwake@rsxtech
sef@kithrup.COM (Sean Eric Fagan) (01/03/91)
In article <1991Jan02.133014.26506@buster> buster!rli writes: >I do agree that free upgrades (read charges for copying and >shipping only) should be provided. Do you also believe that, say, Ford should give you a free car every year when they come out with the new model? Why not? Most upgrades have new "features." While I will agree (usually 8-)) that bug fixes should be readily available (free or cheap), I don't thing new "features" should be free. >Also, there should be no >charges when reporting bugs. Now, here is something I completely agree with. And I also think that someonw who reports a bug should get the bug fix free (or reasonably priced, depending on exactly what the "fix" is), if one becomes available. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
jackv@turnkey.tcc.com (Jack F. Vogel) (01/03/91)
In article <1990Dec23.122201.3819@unixland.uucp> bill@unixland.uucp (Bill Heiser) writes: [......] >What made you decide to start offering shell access, Larry? > >I haven't seen much posted from you for a while (until the past few days). >Have you been away? I generally try to avoid flaming but I just can't resist a comment here. Bill, you know if you and Larry want to "chat" there is this arcane application just perfect for such things...ITS CALLED EMAIL...you know, you press 'r' instead of 'f' :-}. Enough said?? There, I feel better now :-}. -- Jack F. Vogel jackv@locus.com AIX370 Technical Support - or - Locus Computing Corp. jackv@turnkey.TCC.COM
chip@tct.uucp (Chip Salzenberg) (01/03/91)
According to sef@kithrup.COM (Sean Eric Fagan): >Look, this is a bit longer than I'd intended. Yeah, right. :-) >All I'm trying to say is that 3.2v2 is, I think, worthwhile. Since I've often railed against C2, let me chime in here with some agreement. SCO UNIX is a worthwhile product and a useful environment. It's only the C2 that really gets my goat. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "Please don't send me any more of yer scandalous email, Mr. Salzenberg..." -- Bruce Becker
larry@nstar.rn.com (Larry Snyder) (01/03/91)
bill@unixland.uucp (Bill Heiser) writes: >Larry, what kind of video hardware are you using to provide adequate >performance in X? I don't use X much myself, because this little Multisync >II (14") and ATI VGA Wonder (only supported to 640*480 in Esix X) just don't >cut it -- too small and too slow on re-draw. I have an ATI VGA wonder with 512K - and Interactive X supports 800*600 on my NEC 3D.i >What made you decide to start offering shell access, Larry? A while back >you mentioned that you were concerned about the potential security risk >here. I would like to offer shell accounts - so folks can use nn (and trn if I get it installed) - but I haven't had the time to "secure" the system - maybe sometime in the near future I will have time to make the system secure -- -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {..!uunet!mailrus!iuvax!ndcheg!nstar!larry, larry%nstar@ndcheg.cheg.nd.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
rli@buster (Buster Irby) (01/03/91)
sef@kithrup.COM (Sean Eric Fagan) writes: >In article <1991Jan02.133014.26506@buster> buster!rli writes: >>I do agree that free upgrades (read charges for copying and >>shipping only) should be provided. >Do you also believe that, say, Ford should give you a free car every year >when they come out with the new model? Why not? No, but I do believe that they should offer to fix any mistakes that they made during a reasonable warranty period, say the first 12 months or so for free! I am not against them charging reasonable copying and shipping fees, just no profit should be made on bug fixes! >Most upgrades have new "features." While I will agree (usually 8-)) that >bug fixes should be readily available (free or cheap), I don't thing new >"features" should be free. WRONG, most upgrades are just that, bug fixes. Furthermore, ISC and others won't even tell you that the upgrades are available. For example, there were six bug fix upgrades between version ISC version 2.0 and version 2.2. How many people were aware of that? These were strictly bug fixes, not enhancments. -- Buster Irby (buster!rli)
debra@svin02.info.win.tue.nl (Paul de Bra) (01/03/91)
In article <94408977@bfmny0.BFM.COM> tneff@bfmny0.BFM.COM (Tom Neff) writes: >... >Anyway, memory is so damn cheap these days. My only beef is that, for a >UNIX release packing so many additional files, SVR4/386 doesn't have better >support for huge ESDI disks. It chafes to have to throw away 100MB of >my Maxtor just to keep upder 1024 cylinders. I would like to see this >addressed in a future rev. The 1024 cylinder limitation is not an AT&T invention. Complain to your vendor. AT&T Unix sVr3.2 and sVr4.0 (at least the beta i have seen) have no problems with drives with more than 1024 cylinders, without the need for funny translation procedures. I have used a CDC Wren V (383H) with 1224 cylinders and an Adaptec 2322 controller with both versions of Unix and never had any problem. ISC 2.0.1 (but i believe later versions have the same problem) decided (wrongly!) that my system would not support more than 1024 cylinders and would not let me access the last 200 cylinders. Paul. (debra@research.att.com, debra@win.tue.nl)
geoff@Veritas.COM (Geoffrey Leach) (01/04/91)
From article <1991Jan02.133014.26506@buster>, by rli@buster (Buster Irby): > geoff@Veritas.COM (Geoffrey Leach) writes: > >>My proposal is that product support should be provided free with the product. >>If this is felt to be too expensive, then the vendor should take a look at >>why its expensive. If the reason is that the product has bugs, then the >>vendor should do a better job of building the product in the first place. > > Your point is well taken. However, you seem to believe that the > only problems that people call support for are caused by the > vendor. This is seldom the case in a high volume product. A lot > of calls to support happen simply because a self styled expert > failed to RTFM. Do you believe that vendors should provide free > support for self inflicted problems? Let's not get moral, now. Remember, part of my argument is that its in the vendor's self-interest to provide the free support because it promotes a happy customer. But there's obviously a limit.
gary@sci34hub.sci.com (Gary Heston) (01/04/91)
In article <1991Jan02.133014.26506@buster> buster!rli writes: >geoff@Veritas.COM (Geoffrey Leach) writes: > >>My proposal is that product support should be provided free with the product. [ etc. ] > [ .... ] I also believe that the user must >accept some responsibility as well. I do not want to pay a >higher price for any product simply because some other people >refuse to RTFM. Folks, how about a vendor offering a training course (for a fee), the participants of which receive free or very low cost support. This training would be optional; anyone who doesn't want to pay for the training/support doesn't have to. This would eliminate a lot of the problems with people asking questions instead of reading TFM, but allows the already-experienced person a low purchase price. Not perfect, but it's a suggestion I haven't seen yet. -- Gary Heston System Mismanager and technoflunky uunet!sci34hub!gary or My opinions, not theirs. SCI Systems, Inc. gary@sci34hub.sci.com * In Memory of White Sox, the family dog, 1975-1/1/1991. * * Loyal, faithful, and stubborn to the end. We miss him. *
tmh@bigfoot.FOKUS.GMD.DBP.DE (Thomas Hoberg) (01/04/91)
In article <1991Jan02.081223.21793@kithrup.COM>, sef@kithrup.COM (Sean Eric Fagan) writes: |> |> Do you expect the person you buy your car from to provide "support" |> indefinitely? Do you go up to mechanics and ask them detailed questions |> about what's wrong with your car? Do you give them the keys to the car and |> ask them to find out what's wrong and fix it? This is, is a lot of ways, |> quite close to the problem with software, since a large part of the cost is |> diagnosis. With a car I can usually detect if not repair the problem myself, even it is a problem that has come built into the car at manufacture. If there is a problem I can't fix, I can chose the mechanic, on the base of competence, price and workload. There is no secret knowledge about the car that's available to the mechanic only and that he is prohibited to tell me about. Yes I do expect him to provide support indefinetely or for about 10-20 years, after an initial warranty period of one year or more. Yes, I do ask my mechanic detailed questions about my cars problems and the way he intends to solve them. If I don't get satisfactory answers, I take it somewhere else. If he doesn't solve the problems or if he charges an unreasonable amount of money for the fix, or if he actually induces an other problem I am willing to take him into court, where I can have independent experts testifying on my behalf. I have some expertise with cars and I have some with Unix and computer hardware. A lot of times with Unix I have been quite sure about the source of a problem and I could and even would have fixed it myself, even if I think that it's not really my responsability and that the vendor should have fixed it for me. Instead I am confronted with fools and spend hours with them before they realize, that I got a problem they can't handle and call in the 'knowledgable' guys. With software I might never get to talk to those guys and my messages might get to them garbled beyond recognition. Even if they get there, they might ask me to trade my '88 model X in for a '90 model X.1beta at $$$$ with sound conditioning and recolorable seats even though the '88 model X needed only a change of sparc plugs. |> ... |> For the people who are running into |> problems all the time, well, they should pay for the time they're using. |> Actually I think it's the other way around. A software company that sells me a faulty piece of software should pay for the time I lost tracking down and reporting the problem as well as in some cases for consequential dammage. Software companies that don't provide free bug fixes and don't listen to the experts in the field shoot themselves in the foot *and* hurt a lot of innocent people beside. It is they, who will spur increasing interest in the gospel of Richard Stallman and the FSF and thus bring about the end of software mono- polies and an end to profits never 'earned'. |> |> This is known as capitalism. |> Yes indeed, it is, even though the post industrial age might even make good old capitalism obsolete... |> |> -- |> Sean Eric Fagan | "I made the universe, but please don't blame me for it; |> sef@kithrup.COM | I had a bellyache at the time." |> -----------------+ -- The Turtle (Stephen King, _It_) |> Any opinions expressed are my own, and generally unpopular with others. ---- Thomas M. Hoberg | UUCP: tmh@prosun.first.gmd.de or tmh%gmdtub@tub.UUCP c/o GMD Berlin | ...!unido!tub!gmdtub!tmh (Europe) or D-1000 Berlin 12 | ...!unido!tub!tmh Hardenbergplatz 2 | ...!pyramid!tub!tmh (World) Germany | BITNET: tmh%DB0TUI6.BITNET@DB0TUI11 or +49-30-254 99 160 | tmh@tub.BITNET
edhall@rand.org (Ed Hall) (01/04/91)
In article <1659@svin02.info.win.tue.nl> debra@svin02.info.win.tue.nl (Paul de Bra) writes: > . . . . ISC 2.0.1 (but i believe later versions have the same >problem) decided (wrongly!) that my system would not support more >than 1024 cylinders and would not let me access the last 200 cylinders. > This is false; ISC 2.0.1 supports disks with more than 1024 cylinders just fine (I'm using all 1070 of mine, using a WD1006 controller). The partitioning program gives a bogus indication that there is a 1024 cylinder upper-bound, but if you ask it for more, it will give it to you. I even had to use ISC's formatter, since the WD1006 BIOS didn't format above cyl #1023. No problem. I just pretended everything was OK, and lo and behold, it was. -Ed Hall edhall@rand.org
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (01/04/91)
As quoted from <188@raysnec.UUCP> by shwake@raysnec.UUCP (Ray Shwake): +--------------- | allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) writes: | | >MMDF is one of the things SCO did right. I plan to bring it up on a number of | >other systems --- it beats sendmail all hollow for ease of maintenance. And | >the fact that it can handle a pathalias file by itself is nice, too. | | Consider yourself one of the lucky ones. I've had a few frustrating | years working with earlier and more recent versions of the package, and +--------------- Let me correct that: one of the first things I did was replace SCO's MMDF with the distribution from louie.udel.edu, which was more recent. It also got me full documentation. My experience is that MMDF is quite robust when treated correctly. It *can* be thrown out of whack by incorrect permissions... but that's what /usr/mmdf/checkup (/usr/mmdf/bin/checkup under SCO UNIX) and /usr/mmdf/setup (also in bin/ under SCO) are for. Checkup gives reports and can fix things on the fly; setup fixes up more things than checkup does, and is intended for fixing up new installations. Run setup after making major changes to mmdftailor and checkup weekly, is my suggestion. (And show me a tool for sendmail that makes sure things will work!) +--------------- | more reliable the box became. The last straw came one morning when I found | 104 undelivered messages in the spool directory, but all the tools indicated | an empty queue. I'll certainly check out the next version when ODT 1.1 comes +--------------- I had this happen to me once as well... but when I ran checkque as root instead of mmdf, I saw stuff in the queue. Red flag... I immediately ran checkup and it straightened out permissions for me. And pointed out the only bug I've found in MMDFIIb #43 to date: you can't change the lock directory in mmdftailor, it gets misread. Since I've got the source, if it annoys me enough I'll track it down and fix it. +--------------- | As to pathaliasing, we found no way to use the existing paths file; | rather we had to create an mmdf-specific variant of same. Given a 1 MB paths | file, the variant came to more than 2 MB. We junked it. +--------------- You have to build the MMDF database (using dbm) with it, which gets large. But you'd be crazy not to use the dbm paths databases that smail and sendmail+IDA use, and those get big as well. Perhaps release #32 didn't use the same format, but #43 looks an awful lot like the stuff I feed smail on our SVR3.1 box.... MMDFIIb #32 was, admittedly, a mistake. (And I'm told that SCO has put the finishing touches on their own port of #43. I hope they found and fixed the bug with the lock directory.) But MMDF itself is much easier to babysit than sendmail, which I've been trying to maintain on ncoast for a few years. That SCO went with MMDF instead of sendmail is what I find commendable --- they broke with what everyone else did (as usual) but there is a net gain in this case because sendmail is widely known to be a pain in the *ss to maintain. (Mind you, there are sendmail gurus out there who can read a sendmail.cf as if it were English. G*d alone knows how....) And it's one h*ll of a lot better than the "execmail" nonsense under Xenix (a poor, unconfigurable sendmail clone). ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (01/04/91)
As quoted from <1991Jan3.174300.968@sci34hub.sci.com> by gary@sci34hub.sci.com (Gary Heston): +--------------- | Folks, how about a vendor offering a training course (for a fee), the | participants of which receive free or very low cost support. This +--------------- "There is nothing new under the sun." Plexus did something very much like this for hardware support: if you took their (3-day) training course for a fee, they would let you sign onto their lower-cost parts exchange program. For a fixed and relatively low cost per month, you could call at any time with hardware problems and they'd just ship boards to you and let you put them in and ship back the originals until the problem went away. No labor charge, no extra hourly charge for phone support, just the cost of the board(s). Be nice to see this for software, though, I'll admit. On the other hand, it may be notable that Plexus is no more. (On the *third* hand, they were the last of the companies from the early Silicon Vally boom to disappear --- many other computer companies from the same time period died much earlier. (Second last if you want to quibble about Acer buying Altos. But do your quibbling elsewhere, please.)) ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
debra@wsinis03.info.win.tue.nl (Paul de Bra) (01/04/91)
In article <1991Jan4.025218.21453@rand.org> edhall@rand.org writes: >... >This is false; ISC 2.0.1 supports disks with more than 1024 cylinders just >fine (I'm using all 1070 of mine, using a WD1006 controller). The >partitioning program gives a bogus indication that there is a 1024 >cylinder upper-bound, but if you ask it for more, it will give it to >you. So how did you do it? I told it to use up to cylinder 1223 (the last one on my disk) and ISC 2.0.1 complained and told me my system did not support more than 1024 cylinders and it changed the last cylinder back to 1023. I didn't give up that easily. I went back to AT&T sVr3.2 and partitioned the disk so now I had the correct Unix partition. I interrupted the AT&T installation, went back to ISC, and skipped the partitioning step (since I already had a Unix partition). Shortly thereafter the system promptly crashed (panic). For some reason 2.0.1 did not like my partition that went up to cylinder 1223. (I have tried with a partition to 1023 and 2.0.1 did install.) Needless to say I trashed the 2.0.1 and went back to AT&T Unix, which happily uses all cylinders up to 1223. Maybe there is a problem because of the Adaptec 2322 controller? Paul. (debra@research.att.com, debra@win.tue.nl)
martin@mwtech.UUCP (Martin Weitzel) (01/04/91)
In article <1659@svin02.info.win.tue.nl> debra@svin02.info.win.tue.nl (Paul de Bra) writes: >In article <94408977@bfmny0.BFM.COM> tneff@bfmny0.BFM.COM (Tom Neff) writes: >>... >>Anyway, memory is so damn cheap these days. My only beef is that, for a >>UNIX release packing so many additional files, SVR4/386 doesn't have better >>support for huge ESDI disks. It chafes to have to throw away 100MB of >>my Maxtor just to keep upder 1024 cylinders. I would like to see this >>addressed in a future rev. > >The 1024 cylinder limitation is not an AT&T invention. >Complain to your vendor. >AT&T Unix sVr3.2 and sVr4.0 (at least the beta i have seen) >have no problems with drives with more than 1024 cylinders, >without the need for funny translation procedures. >I have used a CDC Wren V (383H) with 1224 cylinders and an >Adaptec 2322 controller with both versions of Unix and never had >any problem. ISC 2.0.1 (but i believe later versions have the same >problem) decided (wrongly!) that my system would not support more >than 1024 cylinders and would not let me access the last 200 cylinders. This is NOT so. The system on which I just compose this article runs with a CDC Wren V (383H), a WD 1007V-SE2 ESDI controller and ISC 2.2. and it ran with ISC 2.0.2 until Oct. 1990. I can use ALL of the disk WITHOUT any funny translation from the controller (which in fact would support this, but I decided not to use it for several reasons). There are a few things you should remember (note that fdisk-partitions here refer to the partitions you create with `fdisk', while UNIX-partition refer to the ones you - or the installation procedures - creates with `mkpart'): - Be sure to physically format ALL of the disk before you install UNIX. Either the disk manufacturer supplies special software for that or you can use the formatter in the controller's firmware. (For the WD 1007V-SE2 you call this formatter from the DOS debug command with `G=CC00:5' but the location may also depend on some jumper settings of the controller.) - When you partition your disk with fdisk, the maximum number of cylinders you can specify is in fact 1023. This doesn't hurt as long as you place the fdisk-partition(s) you want to use with DOS first and the fdisk-partition you plan to use with UNIX has at least ~40 MByte within the first 1024 cylinders. - When the installation procedures of ISC ask you about the `real' disk size, give the CORRECT number here (or one less than that - I will not go into details but I have experienced problems when I tried to use the very last cylinder with ISC 2.0.2; the problems may be cured in 2.2 but I only specified 1222 cylinders for my disk when I installed 2.2, so I can't really say.) - Create the UNIX-partitions (ie. the SUB-partitions WITHIN the fdisk-partition you use for UNIX) so that the one which holds the root directory after booting (/dev/[r]dsk/0s1) does not extend behind cylinder 1023. (This is due to the limitation that the kernal is read in with the PC-BIOS after boot and the BIOS can not access parts of the disk behind cylinder 1023. Note that the chances are you may never have a problem even if you don't follow that recommendation - until, one day, you make a new kernal and it, or part of it, is accidentially placed behind the 1023th cylinder!). - The WD 1007V-SE2 (I know, not the controller in question, but the one I have the docs for) has several translation modes, and there are in fact TWO "non-translation" modes. But there is only one which lets you acces the disk behind cylinder 1024. The docs warn not to use this mode unless the disk has more than 1023 cylinders and "...you are using a special driver or operating system..."% Good luck. %: I was in fact reluctant at first to use this mode, since I rather consider MS-DOS a special operating system, while UNIX is the standard for me :-) -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
edhall@rand.org (Ed Hall) (01/05/91)
In article <1663@svin02.info.win.tue.nl> debra@info.win.tue.nl writes: >In article <1991Jan4.025218.21453@rand.org> edhall@rand.org writes: >>This is false; ISC 2.0.1 supports disks with more than 1024 cylinders just >>fine (I'm using all 1070 of mine, using a WD1006 controller). The >>partitioning program gives a bogus indication that there is a 1024 >>cylinder upper-bound, but if you ask it for more, it will give it to >>you. > >So how did you do it? I told it to use up to cylinder 1223 (the last one >on my disk) and ISC 2.0.1 complained and told me my system did not support >more than 1024 cylinders and it changed the last cylinder back to 1023. The problem is in their disk partitioning program, which not only prints the bogus message saying you can't go above 1023, but also forces the partition display to reduce the upper bound to 1023. Just the same, you get what you asked for. This is as counter-intuitive as all hell--the only reason I even tried it was that it was mentioned in a net posting a year or two back. For the average user who isn't going to be silly enough to ignore two warning indications, 2.0.1 is as good as limited to 1024 cylinders. The only credit ISC gets from me on the matter is that they didn't manage to break the rest of the system with regards to disks larger than 1024 cyls. Be aware, however, that there are some disk controllers around that won't go above cyl 1023. Like I mentioned, the BIOS in my controller didn't allow for it, although the controller itself did. -Ed Hall edhall@rand.org
del@fnx.UUCP (Dag Erik Lindberg) (01/05/91)
In article <1659@svin02.info.win.tue.nl> debra@svin02.info.win.tue.nl (Paul de Bra) writes: >any problem. ISC 2.0.1 (but i believe later versions have the same >problem) decided (wrongly!) that my system would not support more >than 1024 cylinders and would not let me access the last 200 cylinders. I am not absolutely sure about ISC 2.0.1, but 2.0.2 is similar to this in that the installation script will *tell* you that it is only letting you use 1024 cylinders, but a footnote in the release notes tell you that it is OK to specify the whole 1200 or whatever cylinders when making the file systems. The limitations are that you must format the drive using some other program than the unix formatter, and the *root* file system must fit entirely within the first 1024 cylinders. Given that you already have a running system, my suggestion would be to back up the last file system on the disk (or all of them if you are paranoid), use mkpart to delete that file system. Then edit /etc/partitions to add the extra disk space to the last partition/filesystem defined. Use mkpart to add the partition/filesystem, and initialize with mkfs, you should be in business with the extra disk space. -- del AKA Erik Lindberg uunet!pilchuck!fnx!del Who is John Galt?
akcs.greg@ddsw1.MCS.COM (*Greg*) (01/06/91)
Really, alot of your answers lead me back to where I first began reading the querry of Carson Wilson. Reading about the responses that both ISC and SCO have given to people, I'm inclined to go with Xenix! 8-> Make way for stable operating systems! Or else!
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (01/09/91)
In article <1659@svin02.info.win.tue.nl> debra@svin02.info.win.tue.nl (Paul de Bra) writes: | The 1024 cylinder limitation is not an AT&T invention. | Complain to your vendor. I saw that problem in some form with Intel V.4 but not Dell V.4. I can't quite make out what happened, and I did take notes, but I couldn't get the 1224 to work until I went to Dell. However, I'm thinking seriously of going back long enough to get some X stuff off either the Intel tape or the earlier Dell beta releases. The X server Dell supplies with V.4 seems very robust, but it lost 800x600 when it went from the earlier betas to the last release, because if only worked on the chips for which it was designed. Read between the lines. My interpretation is that so many beta testers tried to use 800x600 on unsupported VGA boards that they pulled the feature. And I can't blame them, but I still want higher resolution!! -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (01/09/91)
In article <1991Jan3.174300.968@sci34hub.sci.com> gary@sci34hub.sci.com (Gary Heston) writes: | Folks, how about a vendor offering a training course (for a fee), the | participants of which receive free or very low cost support. This | training would be optional; anyone who doesn't want to pay for the | training/support doesn't have to. This would eliminate a lot of | the problems with people asking questions instead of reading TFM, | but allows the already-experienced person a low purchase price. I have suggested many times that instead of 30 days support SCO offer 4 hours support any time within the first year. That way the people who can't read would blow it on low level support (I bet the people who answer the phone the first time are cheaper than the backup team so SCO should like that) and the expert users could hoard the time for serious problems. If a vendor was being really fair they would charge for time if it turned out they had a bug! -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
aab@cichlid.com (Andy Burgess) (01/09/91)
In article <95@comix.UUCP> jeffl@comix.UUCP (Jeff Liebermann) writes: > >The answer to this problem is in front of your face. The >index should be on-line. One should be able to type a keyword >and some database should belch the document name, current >version, and page references. My illusions are a hypertext >like indexer with context sensitive suggestions. The final >output should be either a man page or a manual page reference. Sun OS has something similar to this. man -k <subject> returns a list of manual entries that contain <subject> in their description. Not perfect but very handy sometimes. I'll bet this is in sysvr4... Andy -- Andy Burgess Independent Consultant aab@cichlid.com uunet!silma!cichlid!aab
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (01/09/91)
Re "support". In the software business, "support" includes a number of different things: fixing existing bugs; adding new features; hand-holding users through installation; helping them figure out the documentation; helping them figure out how to do undocumented things; etc. I can see asking users to pay for all of the above *except* fixing existing bugs. I see no justification for selling a buggy product and then refusing to fix the bugs without collecting more money. The price of the product should include the overhead of future bug fixes. This is not as costly as it sounds. If the software is properly written, there will be very few bugs in the production release. Software doesn't last very long -- maybe two or three years at most. The technology is changing too quickly. Sure any vendor with a decent product who isn't undercapitalized can afford to fix bugs for two years. -- History never | Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> becomes obsolete. | UUCP: oliveb!cirrusl!dhesi
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (01/09/91)
In <95@comix.UUCP> jeffl@comix.UUCP (Jeff Liebermann) writes: >The answer to this problem is in front of your face. The >index should be on-line. One should be able to type a keyword >and some database should belch the document name, current >version, and page references. Ah, for standard UNIX tools: cd /usr/man egrep 'bunch|of|things|to|look|for' */* This is partly why I give BSD and SunOS much higher marks than System V. Although BSD's printed manual pages are only slightly better than those of System V, the fact that they are online and can be searched easily makes them much more useful. Alas, I hear that newer BSD's won't have the online documentation (I hope this is a vicious and false rumor). The System V philosphy, of making documentation available only in printed form, and then having almost every page numbered 1 or 2, is very silly. I can understand this if the printed manuals are simply copies of the online manuals and mimic their individual page numbering. But if the printed manuals are the only documentation, then AT&T should at least get the page numbering right. Pages are numbered beginning from 1, and then you continue with 2, 3, 4, etc., until you run out of pages. Then you add an index, and the index refers you to specific pages. -- History never | Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> becomes obsolete. | UUCP: oliveb!cirrusl!dhesi
khai@adi.com (S. Khai Mong) (01/10/91)
In article <52585@bigtex.cactus.org> james@bigtex.cactus.org (James Van Artsdalen) writes:
It's very expensive for a vendor to offer the man pages on line, but
it's also pretty popular with end users.
Why should it be very expensive? Is it the cost of cutting the tape?
Surely the man pages are quite a smaller fraction of the whole
release. It would have been more costly to include the printed pages
in the package.
--
Sao Khai Mong: Applied Dynamics, 3800 Stone School Road, Ann Arbor, Mi48108
(313)973-1300 (uunet|sharkey)!amara!khai khai@adi.comjtc@van-bc.wimsey.bc.ca (J.T. Conklin) (01/11/91)
In article <KHAI.91Jan10082730@snapper.adi.com> khai@adi.com (S. Khai Mong) writes: |In article <52585@bigtex.cactus.org> james@bigtex.cactus.org (James Van Artsdalen) writes: | | It's very expensive for a vendor to offer the man pages on line, but | it's also pretty popular with end users. | |Why should it be very expensive? Licence fees to AT&T. -- J.T. Conklin jtc@wimsey.bc.ca, ...!{uunet,ubc-cs}!van-bc!jtc
det@hawkmoon.MN.ORG (Derek E. Terveer) (01/12/91)
Please note that i'm not arguing against you because i disagree but, rather, because i'm playing devil's advocate here... dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: >This is not as costly as it sounds. If the software is properly >written, there will be very few bugs in the production release. >Software doesn't last very long -- maybe two or three years at most. >The technology is changing too quickly. Sure any vendor with a decent >product who isn't undercapitalized can afford to fix bugs for two >years. But, if the ephemeralness of a software product is recognised by the bean counters and/or the managers, they will most likely be less than enthusiastic about fixing bugs, especially non-critical ones, i.e., can't boot. For example, by analogy, if you know that your car will be replaced with a new one in two years (or perhaps even that your type of car (gasoline, etc) will be obsolete in that time frame), you will probably be reluctant to spend $1000 on a new paint job to fix that rusted body or to get those rips repaired in the upholstery. The human species seems to be pretty adept at procrastination and pushing the "just getting by" envelope. -- Derek "Tigger" Terveer det@hawkmoon.MN.ORG - MNFHA, NCS - UMN Women's Lax, MWD I am the way and the truth and the light, I know all the answers; don't need your advice. -- "I am the way and the truth and the light" -- The Legendary Pink Dots
det@hawkmoon.MN.ORG (Derek E. Terveer) (01/12/91)
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: >In <95@comix.UUCP> jeffl@comix.UUCP (Jeff Liebermann) writes: >Alas, I hear that newer BSD's >won't have the online documentation (I hope this is a vicious and false >rumor). It seems to me that the trend is towards providing on-line man pages on a CDrom platter. -- Derek "Tigger" Terveer det@hawkmoon.MN.ORG - MNFHA, NCS - UMN Women's Lax, MWD I am the way and the truth and the light, I know all the answers; don't need your advice. -- "I am the way and the truth and the light" -- The Legendary Pink Dots
pcg@cs.aber.ac.uk (Piercarlo Grandi) (01/13/91)
On 10 Jan 91 19:58:22 GMT, jtc@van-bc.wimsey.bc.ca (J.T. Conklin) said: jtc> In article <KHAI.91Jan10082730@snapper.adi.com> khai@adi.com (S. jtc> Khai Mong) writes: khai> In article <52585@bigtex.cactus.org> james@bigtex.cactus.org khai> (James Van Artsdalen) writes: james> It's very expensive for a vendor to offer the man pages on line, james> but it's also pretty popular with end users. khai> Why should it be very expensive? jtc> Licence fees to AT&T. The reason for their being so high is A&T's relationship to Prentice Hall. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
jeffl@comix.UUCP (Jeff Liebermann) (01/14/91)
In article <2862@cirrusl.UUCP>, dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: > In <95@comix.UUCP> jeffl@comix.UUCP (Jeff Liebermann) writes: > > >The answer to this problem is in front of your face. The > >index should be on-line. One should be able to type a keyword > >and some database should belch the document name, current > >version, and page references. > > Ah, for standard UNIX tools: > cd /usr/man > egrep 'bunch|of|things|to|look|for' */* > This command is useful only if you know what to look for. What I'm proposing is something useful to users as well as experienced programmers. One starts with a basic concept (backing up, file manipulations, error analysis, mail, communications, ad nausium) and yields a book and page number. System and application updates should include index entries to their release notes. Note that I did NOT suggest that it be used as an entry point into the online man pages. There are no online copies of the System Administrators Guide, Users Guide, Users Tutorial, various release notes, updates, and the sosco stuff (Ref: SCO Unix 3.2.2). There may never be. The online man pages are incomplete. (Dull red glow before the flame.....) What is entertaining to me is the resistance that I've generated over this simple idea. I've proposed an online page index to 6 local software companies. 4 of these sell databases. I suggested that the "demo" program supplied the with these databases be an index to their documentation. All 5 ignored or turned down the idea. I was recently involved in editing a Unix book. I suggested an online index to the book available by a mail-in card or bbs download. This one also went nowhere. (IMHO), I think that the reason it's not being done is that no other company is doing it. No one (I've talked to) seems to want to risk their job on an untried idea or considers it sufficiently important to supply with their products. Hypertext and context sensitive help is all over the DOS and MacOS world, but not in UnixLand. So I leave it to the smaller companies to impliment so the industry leaders can clone in safety. -- # Jeff Liebermann Box 272 1540 Jackson Ave Ben Lomond CA 95005 # (408)336-2558 voice (408)429-0483 digital pager wb6ssy CIS:73557,2074 # PC REPAIR & RF DESIGN uunet!comix!jeffl ucscc.ucsc.edu!comix!jeffl # universe!milky_way!solar_system!earth!na!us!uunet!comix!jeffl
mike@bria.UUCP (Michael Stefanik) (01/14/91)
In article <97@comix.UUCP> comix.UUCP!jeffl (Jeff Liebermann) writes:
:(IMHO), I think that the reason it's not being done is that no
:other company is doing it. No one (I've talked to) seems to
:want to risk their job on an untried idea or considers it
:sufficiently important to supply with their products.
:Hypertext and context sensitive help is all over the DOS
:and MacOS world, but not in UnixLand. So I leave it to the
:smaller companies to impliment so the industry leaders can
:clone in safety.
Uhh, what about AIX 3.1 "Golden" InfoExplorer that does provide manual
references, on-line text, context sensitive searching and hypertext links?
(And that's just the half of it ...)
--
Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation
UUCP: ...!uunet!bria!mike
--
technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly
found to be saying things like "Well, it works on my DOS machine ..."gary@ke4zv.UUCP (Gary Coffman) (01/17/91)
In article <27888cf2-8ae.5comp.unix.i386-1@point.UUCP> wek@point.UUCP (Bill Kuykendall) writes: >>Reading about the responses that both ISC and SCO >>have given to people, I'm inclined to go with Xenix! > >Shoot, why not go with CP/M? It's very stable these days, and the hardware >is certainly cheaper. Single user response time is a lot better too. On a 8 Mhz Z80H Wordstar really flies! Gary