Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pasteur!ucbvax!hplabs!hp-sdd!sceard!mrm From: mrm@sceard.UUCP (M.R.Murphy) Newsgroups: comp.unix.microport Subject: Re: How does Microport System V/AT handle bad blocks? Message-ID: <871@sceard.UUCP> Date: 31 Jan 89 16:51:34 GMT References: <460@tarpit.UUCP> <326@focsys.UUCP> <464@tarpit.UUCP> <2689@nuchat.UUCP> <211@trevan.UUCP> <798@splut.UUCP> <920@kksys.mn.org> Reply-To: mrm@sceard.UUCP (0040-M.R.Murphy) Distribution: na Organization: Sceard Systems, Inc., San Marcos, CA 92069 Lines: 165 In article <1131@ssbn.WLK.COM> bill@ssbn.WLK.COM (Bill Kennedy) writes: >In article <920@kksys.mn.org> gk@kksys.UUCP (Greg Kemnitz) writes: >>In article <798@splut.UUCP> jay@splut.UUCP (Jay Maynard) writes: >>>In article <211@trevan.UUCP> trevor@trevan.UUCP (trevor) writes: [many comments about Microport not fixing bugs deleted...] > >Here I disagree with Greg but only partially. He's right on target with >the overall premise, i.e. don't buy Microport. I disagree that it's >expensive. If you place any value on your system's reliability, user >satisfaction, or your own time, avoiding Microport is quite cost effective. I disagree, see below. > >I view Microport's "offerings" (no, I will still not dignify them by >calling them "products") as experimental. What *IS* expensive is what >they charge for experimental works alleged to be products. I have a >'286 that runs V/AT but it's my luggable that accompanies me when I'm on >the road. As such, the quirks, bugs, and anomalies are 100% my responsibility >and I am the only one victimized by them. I expect no support and get >none, so I am never disappointed. If you are going to run a System V >on an AT/clone, I'm not aware of anything else. AT&T had a very nice >System V for the PC 6300 PLUS. I think it will help your blood pressure >if you can accept V/AT as an experiment by experimenters, it does mine. Expense is relative. Anyone care to cite the cost history of a non-academic UNIX(tm) license over the years? > >Changing to a '386 makes a lot of sense if you have to have decent reliability >and user satisfaction (even if you're the only user :-). Avoiding Microport >makes even more sense. I tried V/386 and pitched it (and the $$) into the >street when I saw what it was going to do to my uucp neighbors and users >who have come to think of this system as "available, usable, and reliable". ruptime on our network yields: acim up 3+14:43, 0 users # AT&T 6386WGS 20MHZ 4MB,140MB, SVR3.2 getnf8.s up 20+03:55, 0 users # Clone 286 10MHZ 3MB,60MB, SVAT 2.4 getnfd.s up 17+14:35, 4 users # Clone 286 10MHZ 5MB,160MB, SVAT 2.2 getnfe.s up 53+15:13, 3 users # Clone 286 12MHZ 5MB,160MB, SVAT 2.2 Note that getnfe.s has been up over 53 days. It is our news and mail gateway. This could probably be described as "available, usable, and reliable". A great deal of care was exercised in the choice of hardware and in the configuration of the software for the system to make it so. A lot of the problems with Microport systems stem from the great variety of hardware that is "real close to just almost like" stuff from IBM(tm). That, and the fact that UNIX(tm) has had its fair share of timing problems, coding oversights, and design flaws through all of its releases. These flaws are carried over from release to release and port to port by folks who are human and who get to add their own bugs to the system (2.8bsd,2.9bsd,4.1bsd,4.2bsd, 4.3bsd,...:-). Generally, these people are doing the best they can at the time. I believe that is also true of Microport. That UNIX(tm) works as well as it does in the great range of environments in which it has found itself (IBM mainframes running UNIX over a CTS base, Univac(tm) 1100 series mainframes, on down to 8086's running hacked 22-bit memory management) is amazing. >The money hurt because it was a lot of it and it was mine, personally. I >concluded that I would have spent far more on the telephone and chasing >alleged "problems" and would never achieve what I set out to do. It was >amazing how my "hardware problems" vanished when I installed AT&T 386 UNIX. The machine "acim", a stock 386 from AT&T with AT&T SVR3.2, does not appear to have fewer problems than the clones. The hardware that didn't work in the clones with the flavor of UNIX that we are using, we dumped. As in, oh, well, this disk controller doesn't work with the OS, let's just put it in that DOS machine and get one that does work. Yes, this takes time and effort, but the resulting system performance is worth the effort (I hope :-). It is also interesting to note that the prices of the pieces are quite low when compared with pieces of similar functionality from vendors such as SUN(tm), DEC(tm), Data General(tm), ... >It's ironic how many of those "hardware problems" are documented as bug >fixes in 3.06e and disappointing how many of them would still be wrong >with my equipment if I used 3.06e. It may take some experimenting to get a system that is reliable and that works as a whole. More experimenting than I like, but it can be done. It also possible to call one of the vendors mentioned above, find a salesperson who is willing to sell a system, pay vast amounts of money, and have a system installed and running, without ever touching a keyboard, let alone a screwdriver. > >I think that what we have here is a perceptual problem. I think that the >average '286/'386 user came from one of two camps, down from minis or up >from PC's. There may be a few who dove in from nowhere but probably not >many. Those who came down from minis are apalled that fundamental things >(fsck, device drivers, etc.) don't work right. Those coming up from PC's >are puzzled because their hardware doesn't work right with this new stuff. I am not apalled that the drivers don't work right. I am disappointed, some- times a bit dismayed, but understanding of the people who tried to get it right but goofed up some. If I can, I work around the problem. If I can't, then I violate my license agreement (just a little:-) and disassemble the offending code, and see if I can fix it. So far, so good. > >The perceptual problem is compounded because we are probably mostly >individuals buying with our own money. We expect a certain minimum >functionality and we don't get it. If it was a car or a microwave oven >there's a manufacturer's warranty, statutory relief; with Microport >there's an arrogant snort. That pisses us off (just like a lemon car) >because it was our own money and our expectations, the reasonable ones, >were neither met nor are they likely to be. The arrogant snort I refer >to is not from the technically inclined and conscientious personnel at >Microport. I think that they are as outraged and upset as those of us >whose money pays their salaries. Management either doesn't care or >won't listen. I am not competent to speculate on Microport's management or on the feelings of the Microport staff. I do feel, however, that the system configuration and system management problems encountered in setting up and using a 286,1MBram,40MBdisk, 2 user UNIX system may be as difficult as the problems encountered in setting up a 24MB VAX(tm),1.2GBdisk running BSD. The problem as I see it is that the little (physically) machine that sits on the desk may be mentally larger than the mainframe and mini-computer systems that were required just a few years ago to support multi-programming and multi-tasking operating systems. The machines have shrunk in size, the support problems haven't. Individuals and small companies, like ours, couldn't afford the hardware for UNIX (or the license:-( just a few years ago. Now we all can. We may not, however, be able to accept the individual burden of support that systems of this complexity currently demand. > >So who is the winner and who is the loser? As long as we, in the >marketplace, keep approving their effort by continuing to spend money >on it, we will lose and management will win. The situation can not >and will not change until we make it change. We, the customers, >constructed the (in my opinion) fraud, and it is our responsibility to >make it stop. Greg made it stop, he changed equipment and vendors. >Now he has achieved the expected minumum functionality and probably more. >Until a clear signal is sent to Microport management, in a language they >understand, we are wasting time and blood pressure being outraged. For >all of John Plocher's efforts (I believe them to be considerable), have >we seen a significant change? I haven't. Can we expect John to make >management apply the resources to produce a respectable product? I >think not, but you and I can. I disagree. I think that, taking into consideration the problems of support in a widely varying hardware and user expertise environment, all of the UNIX vendors, not just Microport, have done a rather amazing job. I also think that the products are more than respectable. Certainly they have bugs. Freedom from bugs is a necessary and sufficient condition for triviality in a program :-). > >Am I a hypocrite for buying, using, and upgrading V/AT? For my equipment >it's the only game in town and bad breath is better than no breath at all. No, you're not a hipocrite. >Sorry for the length, but I hadn't seen this said before and I thought >it needed saying. Ditto. >-- >Bill Kennedy usenet {killer,att,cs.utexas.edu,sun!daver}!ssbn!bill > internet bill@ssbn.WLK.COM --- Mike Murphy Sceard Systems, Inc. 544 South Pacific St. San Marcos, CA 92069 mrm@sceard.UUCP {hp-sdd,nosc,ucsd}!sceard!mrm +1 619 471 0655