gmt@cs.arizona.edu (Gregg Townsend) (02/22/91)
I have to second R. B. Jim's comments about Sequent software. It's pitiful.
Sequent's dual-universe approach is especially bad. You can't write a program
that uses both memset() and mkdir() although such a program runs on the Unix
systems from Sun, Dec, MtXinu, SGI, HP, NeXT, and Encore -- and in either
universe of an Apollo.
Sequent doesn't even seem to understand. They're so proud that they're finally
moving to SVR3.2 while that the rest of the world is moving to SVR4 -- which,
please note, is the one that merges in most of the BSD features people want.
I have been passing on these complaints to everyone who asks how we like our
Sequent. Rock-solid hardware, pathetic software.
Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
+1 602 621 4325 gmt@cs.arizona.edu 110 57 16 W / 32 13 45 N / +758mrbj@uunet.UU.NET (Root Boy Jim) (02/22/91)
In <536@coatimundi.cs.arizona.edu> gmt@cs.arizona.edu (Gregg Townsend) writes: >Sequent's dual-universe approach is especially bad. You can't write a program >that uses both memset() and mkdir() although such a program runs on the Unix >systems from Sun, Dec, MtXinu, SGI, HP, NeXT, and Encore -- and in either >universe of an Apollo. This is the real problem with dual universes. Almost every vendor has incorporated features from the both universes into their distribution. Thus, users expect and demand these features wherever they go. And where did they put getopt? Hidden away in a random library. Here's how we solved the problem when I was at NBS. First, I assumed I wanted a ucb system with att additions. I went to /usr/include and did: 'ln -s /usr/att/usr/include/* .', making available all the att include files that did not conflict with ucb. I also did this in /usr/include/sys. Then, I did a ln -s /usr/att/lib/libc.a /lib/libatt.a and linked with cc -o prog a.o b.o ... z.o -lc -latt. Notice that I used the real c library first! -- [rbj@uunet 1] stty sane unknown mode: sane
david@torsqnt.UUCP (David Haynes) (02/22/91)
rbj@uunet.UU.NET (Root Boy Jim) writes: >In <536@coatimundi.cs.arizona.edu> gmt@cs.arizona.edu (Gregg Townsend) writes: >>Sequent's dual-universe approach is especially bad. You can't write a program >>that uses both memset() and mkdir() although such a program runs on the Unix >>systems from Sun, Dec, MtXinu, SGI, HP, NeXT, and Encore -- and in either >>universe of an Apollo. >This is the real problem with dual universes. Almost every vendor has >incorporated features from the both universes into their distribution. >Thus, users expect and demand these features wherever they go. >And where did they put getopt? Hidden away in a random library. # ucb # cd /usr/lib # ar x libseq.a getopt.o # cd /lib # ar cr libc.a getopt.o # ranlib libc.a # rm /usr/lib/getopt.o >Here's how we solved the problem when I was at NBS. >First, I assumed I wanted a ucb system with att additions. >I went to /usr/include and did: 'ln -s /usr/att/usr/include/* .', >making available all the att include files that did not conflict with ucb. >I also did this in /usr/include/sys. >Then, I did a ln -s /usr/att/lib/libc.a /lib/libatt.a and linked >with cc -o prog a.o b.o ... z.o -lc -latt. >Notice that I used the real c library first! >-- > [rbj@uunet 1] stty sane This may or may not get you into trouble. For example, what does sprintf() return? int? char *? Depends on the implementation. I have taken a slightly different tack on all this by having a library of the commonly misused functions. For example, this library has copies of strtok, strcspn, strdup, as well as memset, memcpy, ... Whenever I hit a program that needs these, I just include the library (I call it libSun.a, since most of the code that has these cross-overs seems to originate on Sun systems (*)). Compilation then becomes an exercise of: cc -O -o out out.c -lSun Currently libSun.a has the following entries: memcpy.o, strpbrk.o, strspn.o, strchr.o, strrchr.o, strcspn.o, putenv.o, vfprintf.o, vsprintf.o, strstr.o, strdup.o, memset.o, strtol.o, ctype.o, memchr.o, rint.o, memcmp.o Most of these were re-written by me (as an exercise) and some were taken from the att universe libraries and placed in this library in the BSD universe. The advantage of this schema is that it can easily survive operating system upgrades and re-installations and I can track which routines are in common usage on other operating systems. BTW: This library concept is not something I created specifically for running on the Sequent. I had a similar library (called libATT.a) on my old VAX 8650 running Ultrix. -david- (*) not all code that fails to find these functions comes from a Sun environment. I really call it libSun.a so that my poor brain cells have a chance of remembering what the library is called. -- David Haynes Sequent Computer Systems (Canada) Ltd. david@torsqnt.UUCP ---------------------------------------------------------------------------- Next week we will be discussing the Canadian High Tech industry. We will be visiting both companies and talking with all eight people involved. -- C.R.
curt@oasys.dt.navy.mil (Curt Welch) (02/22/91)
In comp.sys.sequent, gmt@cs.arizona.edu (Gregg Townsend) writes: >I have to second R. B. Jim's comments about Sequent software. It's pitiful. I'm real tired of seeing this stuff. I happen to thing that Sequent has done a great job on software. I agree, it's not leading edge stuff, but it works, and it provides all the features I need. >I have been passing on these complaints to everyone who asks how we like our >Sequent. Rock-solid hardware, pathetic software. I word it this way: Rock-solid hardware, Rock-solid software. Sun offers leading edge software, and they have to pay the price for doing that. Every few months I see another article like this: In comp.security.announce, cert-advisory-request@CERT.SEI.CMU.EDU writes: > >CA-91:01 CERT Advisory > February 21, 1991 > SunOS /bin/mail Vulnerability >Sun Bug ID : 1047340 >Synopsis : /bin/mail can be caused to invoke a root shell if given the > (im)proper arguments. Someone should write a song: "50 ways to be root on a Sun". I've never seen a single bug report like this about DYNIX. DYNIX does have some bugs, and so does the Sequent hardware, but it's the best integration of hardware and software that I've seen in a long time. Curt Welch curt@oasys.dt.navy.mil Code 3531 David Taylor Research Center (A Navy Lab) Bethesda, MD (301) 227-1428
keith@sequoia.execu.com (Keith Pyle) (02/24/91)
In article <6055@oasys.dt.navy.mil> curt@oasys.dt.navy.mil (Curt Welch) writes: >>I have to second R. B. Jim's comments about Sequent software. It's pitiful. > >I'm real tired of seeing this stuff. I happen to thing that Sequent >has done a great job on software. I agree, it's not leading edge stuff, >but it works, and it provides all the features I need. You're absolutely correct - they're right there on the trailing edge. For single system installations, again, I suspect you are correct that the system will work well. In ones like ours where you have a multitude of different systems, many of which are trying to keep up, it is a more obvious and more likely to cause problems. I'm also tired of seeing it - and saying it. It would be highly desirable if Sequent would do something so we wouldn't find ourselves even having to discuss it. >I word it this way: > Rock-solid hardware, Rock-solid software. Yes, but petrified is also quite solid by definition. >Sun offers leading edge software, and they have to pay the price >for doing that. Every few months I see another article like this: > >In comp.security.announce, cert-advisory-request@CERT.SEI.CMU.EDU writes: >> >>CA-91:01 CERT Advisory >> February 21, 1991 >> SunOS /bin/mail Vulnerability > >I've never seen a single bug report like this about DYNIX. I have seen such reports, but only from Sequent, and only after we harrassed them seriously about not providing such information. They do not seem to like to even admit that they have security problems. Their attitude was the same old one: we don't want to publicize the problem since people could exploit it. Both the network manager and I pressed them on this and now we do get Sequent security notices on hardcopy - typically very terse, little info on the specifics and a comment that a patch may be available. So, maybe Sequent is just treating you the way did us and you're incorrectly assuming that there are no such problems with your version of Dynix. >DYNIX does have some bugs, and so does the Sequent hardware, but it's >the best integration of hardware and software that I've seen in a >long time. > >Curt Welch >curt@oasys.dt.navy.mil I fully agree that the hardware is good (except the 8mm - I'll keep saying that until we have a unit that works for 12 months). However, the OS needs a lot of updating and ptx is NOT it either. -- ----------------------------------------------------------------------------- Keith Pyle UUCP: ...!cs.utexas.edu!execu!keith Manager, Data Processing Services Dept. Internet: keith@execu.com Execucom Systems Corp. 108 Wild Basin Road Austin, Texas 78746 Ma Bell: 512-327-7070 -----------------------------------------------------------------------------
bakken@cs.arizona.edu (Dave Bakken) (02/24/91)
In article <6055@oasys.dt.navy.mil> curt@oasys.dt.navy.mil (Curt Welch) writes: >In comp.sys.sequent, gmt@cs.arizona.edu (Gregg Townsend) writes: >>I have to second R. B. Jim's comments about Sequent software. It's pitiful. > >I'm real tired of seeing this stuff. I happen to thing that Sequent >has done a great job on software. I agree, it's not leading edge stuff, >but it works, and it provides all the features I need. ... >I word it this way: > Rock-solid hardware, Rock-solid software. Do you use NFS? Or do you try to port PD/GNU software to DYNIX? Just wondering... I suspect that if you developed software that had to be portable across Unix implementations or did a lot of Unix systems programming you would feel quite differently. And such portability and interoperability is a main reason many people use Unix. But, hey, it all depends what you want your Sequent for. Ours was bought for a cycle server for our undergraduate program, and for that it does an outstanding job. It would probably be a reasonable if not excellent machine for a parallel database engine. But not for the development and distribution of software. >Sun offers leading edge software, and they have to pay the price >for doing that. Every few months I see another article like this: > >In comp.security.announce, cert-advisory-request@CERT.SEI.CMU.EDU writes: >> >>CA-91:01 CERT Advisory [etc.] If people really want to be more risk free and have their hands held they can get VMS... -- Dave Bakken, bakken@cs.arizona.edu, uunet!arizona!bakken, +1 602 621 4089 I am Iraq,I am an island.And Iraq feels no pain.And an island never cries.PSimon You know I've heard about people like me, but I never made the connection... Don McClean, from the song ``Crossroads'' in album American Pie
rick@uunet.uu.net (Rick Adams) (02/26/91)
In article <6055@oasys.dt.navy.mil>, curt@oasys.dt.navy.mil (Curt Welch) writes: > In comp.sys.sequent, gmt@cs.arizona.edu (Gregg Townsend) writes: > >I have to second R. B. Jim's comments about Sequent software. It's pitiful. > > I'm real tired of seeing this stuff. I happen to thing that Sequent > has done a great job on software. I agree, it's not leading edge stuff, > but it works, and it provides all the features I need. > > >I have been passing on these complaints to everyone who asks how we like our > >Sequent. Rock-solid hardware, pathetic software. > > I word it this way: > Rock-solid hardware, Rock-solid software. Not only is it not leading edge, its so far behind the edge that you can't even see wherethe edge is. It doesnt work reliably. It does not provide the features I need. As far as I know, they're all software problems. If you put a lot of effort into it, you can usually beat the system into doing what you want. Its ashame that you have to doi so much unnecessary work. Given the complete system hangs (as in push the "reset button to "continue" running) we've been experiencing several times per week, "rock solid" would indeed describe the system performance. But then you really can't do much computing with a solid rock, can you? If we were to measure the downtime of our 1 Sequent against the downtime of our dozen Suns conbined, the Sequent downtime would be an order of magnitude higher. I long for the ability of running "unstable" Sun software. Question: Which is better? 1) "buggy" Sun lock managers for NFS that don't work 1% of the time or 2) "non-existant" but rock solid Sequent lock managers? The fact that they are putting effort into System V Release THREE says a lot about the software of this company. Not content with shipping obsolete and broken Berkeley variants, they want to expand their market share by shipping obsolete and broken ATT variants at the same time they're abandoning their users of the obsolete Berkeley variants (Did you notice that their PTX abomination is the only OS available on the new S16? Not even a compatibility library. If you used sockets, expect to rewrite everything in TLI. [of course this library will be provided "someday"]) ---rick p.s. Sequent's got the same security bugs with /bin/mail you're nagging sun about. Sun at least made the effort to notify their customers. I'm already running fixed Sun binaries. With luck, I'll see it fixed in Dynix 3.2 which is probably due out in mid 1994 (If it doesnt slip...) (Ever notice that the Dynix release schedule takes longer and slips more times than the BSD release schedule? I suppose its another attempt at Berkeley compatibility even if the customers dont want that level of compatibility...)
eckert@immd4.informatik.uni-erlangen.de (Toerless Eckert) (02/27/91)
From article <124108@uunet.UU.NET>, by rick@uunet.uu.net (Rick Adams): > Given the complete system hangs (as in push the "reset button to > "continue" running) we've been experiencing several times per week, > "rock solid" would indeed describe the system performance. But then you > really can't do much computing with a solid rock, can you? Except for a few nfs daemons that refused ("D") to continue working, we don't have stability problems, and our suns are booted and crashing much more often then the sequent. I think it only depends on how much you exploit the problems of a given system, and you may much more exploit the sequent system problems than you're sun systems problems - If you want to exploit the suns problems read the buglist and patchlist from you're friendly sun support, every bug listed therein will work. Of course the "real adventure of sun" (TM) only starts after you've fiddled along with the known bugs and depart into the land of unknown bugs. Often you will meet again old old bugs from the good old days of SunOS 3 appearing again on the surface of "high performance SunOS 4.1.1" (TM). > If we were to measure the downtime of our 1 Sequent against the > downtime of our dozen Suns conbined, the Sequent downtime would be an > order of magnitude higher. I long for the ability of running "unstable" > Sun software. Question: Which is better? 1) "buggy" Sun lock managers > for NFS that don't work 1% of the time or 2) "non-existant" but > rock solid Sequent lock managers? Every os is missing someting and dynix may be missing something more some more than SunOS, but it's quite a philosophy at which step of development you put some kind of software out to the customer. Sun is very adventerous in this respect (remember the "NFS Jumbo Patch Revision 3" tape, this time for 4.1.1, now tmp and tfs filesystems start to work). If you have a favour for "untested creeping bugs" (TM), go for Sun. If you want "good old 4.2bsd software", go for dynix. If you want "The real thing" (TM) go for clean bsd, and port it to the machine of you're choice. At least you can easily get sources and fix it youreself. I though admit that the development of ptx seems to have taken the drive out of dynix development. Maybe this will change now. > (Ever notice that the Dynix release schedule takes longer and slips > more times than the BSD release schedule? I suppose its another attempt > at Berkeley compatibility even if the customers dont want that level of > compatibility...) What, 3.1 dynix is already there, but 4.4 bsd is still under development, so what ? As for sun: A company that get's out the patch tapes for their SunOS earlyer than they start shipping the CD-roms for that same SunOS is really a joke. Disclaimer: This are my personnel opinions, and nothing else. --- Toerless.Eckert@informatik.uni-erlangen.de /C=de/A=dbp/P=uni-erlangen/OU=informatik/S=Eckert/G=Toerless ;-) No signature due to pending copyright lawsuit over last signature ;-)
rick@uunet.uu.net (Rick Adams) (02/27/91)
In article <1991Feb26.173944.3570@informatik.uni-erlangen.de>, eckert@immd4.informatik.uni-erlangen.de (Toerless Eckert) writes: > > > (Ever notice that the Dynix release schedule takes longer and slips > > more times than the BSD release schedule? I suppose its another attempt > > at Berkeley compatibility even if the customers dont want that level of > > compatibility...) > > What, 3.1 dynix is already there, but 4.4 bsd is still under development, > so what ? 3.1 dynix could charitably be compared to 4.3bsd which finally came out in 1986, 4 years after 4.2bsd. So what? Only 5 years behind? (And its still missing lots of basic features that are in 4.3) Sequents System 5 release FIVE would be a better comparison to 4.4bsd as far as timing goes.
johnm@mist.CS.ORST.EDU (John Matzka) (03/02/91)
In article <124108@uunet.UU.NET> rick@uunet.uu.net (Rick Adams) writes: > Not only is it not leading edge, its so far behind the edge that you > can't even see wherethe edge is. It doesnt work reliably. It does not > provide the features I need. As far as I know, they're all software > problems. If you put a lot of effort into it, you can usually beat > the system into doing what you want. Its ashame that you have > to doi so much unnecessary work. It sounds to me like you have modified a large portion of your system. If that is the case, how can you still expect it to function perfectly? Do you test _everything_ that you do to your machine? And when it does have problems, do you try to discover why or do you just reboot and hope that it won't happen again? As for not providing the features you need, I would have to ask why you purchased it in the first place. Obviously it must meet some need or you would either have purchased something else or replaced it long ago, eh? >If we were to measure the downtime of our 1 Sequent against the >downtime of our dozen Suns conbined, the Sequent downtime would be an >order of magnitude higher. I long for the ability of running "unstable" I would be interested to see you put 500+ simultaneous users on a dozen suns. John Matzka johnm@cs.orst.edu Computer Science Dept. {ogicse,hp-pcd}!orstcs!johnm Oregon State University I is not a spokesperson, I only live here.
martinb@bottomdog.East.Sun.COM (Martin Baines - Sun UK - SE Manager Cambridge/Gatwick) (03/02/91)
In article <1991Mar01.163348.24172@lynx.CS.ORST.EDU>, johnm@mist.CS.ORST.EDU (John Matzka) writes: [delete comments regarding fitness of Sequent s/w and followups] |> I would be interested to see you put 500+ simultaneous users on a dozen suns. I really couldn't resist this one: 500 users on a dozen Suns = 500/12 Users per system = 41.67 users per system. Let's call it 50 users per system to be fair :-) Each SS400 = 22 MIPS => 0.44 MIPS/user Say the Sequent had 30 processors rated at 5 MIPS each i.e. 30*5 = 150 MIPS => 0.3 MIPS/user So it look's like the dozen Suns would give you *more* power per user than a single Sequent. For the typical s/w dev. load a SPARCsystem 400 would eat this load level for breakfast. Heck there are people running over 100 users (happily) on a SPARCserver2. Ok it varies with work load etc etc., but for more details contact your nearest Sun sales office :-) Needless to say these are my views not Sun's... +----------------------------------------------------------------------------+ | "You might say that, but I couldn't possibly comment" | | | | Martin Baines | | Consultant | | Sun Microsystems Ltd | | 306 Science Park | | Cambridge CB4 4WG | | UK | | | | Phone Email | | UK: 0223 420421 JANET: Martin.Baines@uk.co.sun | | International: +44 223 420421 Other UK: Martin.Baines@sun.co.uk | | Internet: Martin.Baines@UK.sun.com | +----------------------------------------------------------------------------+
taro@argus.CS.ORST.EDU (Hondori Taro) (03/02/91)
In article <1469@west.West.Sun.COM> Martin.Baines@UK.Sun.Com writes: >In article <1991Mar01.163348.24172@lynx.CS.ORST.EDU>, >johnm@mist.CS.ORST.EDU (John Matzka) writes: > >|> I would be interested to see you put 500+ simultaneous users on a >dozen suns. > >I really couldn't resist this one: 500 users on a dozen Suns = >500/12 Users per system = >41.67 users per system. > >Let's call it 50 users per system to be fair :-) > >Each SS400 = 22 MIPS => 0.44 MIPS/user >Say the Sequent had 30 processors rated at 5 MIPS each >i.e. 30*5 = 150 MIPS => 0.3 MIPS/user It is not fair to compare the old symmetry with new Suns. As long as you are using the latest numbers for the Suns you should likewise use the latest numbers for Sequent. Here it is. Each SS400 = 22 MIPS => 0.44 MIPS/user Say the Sequent had 30 486 processors rated at 14 MIPS each i.e. 30*14 = 420 MIPS => 0.84 MIPS/user >So it look's like the dozen Suns would give you *more* power per user >than a single Sequent. So it looks like the more power theory is out. Besides that, MIPS is not the only thing users need. Are you going to duplicate the disks on 12 suns or have a file server and use NFS through the network? administer 12 suns vs 1 machine? Waste memory, swap, CPU and other resources for 12 OSs vs one. Also there are things other than users which use the machines. Most sequents are used for applications, datebases and services server. It would be hard to split a large service like news across 12 Suns, or spread your database across 12 suns and so on. Basicaly what it comes down to is that you can't compare Suns and Sequents, they are designed and made for different purposes. To be fair, I do like Suns and I use them every day, in fact I am using one now. >For the typical s/w dev. load a SPARCsystem 400 would eat this load >level for breakfast. Most computers these days are used for more than just s/w dev, the computers are mostly for people who use them not the software engineers. I would rather have a reliable system (as old as it maybe) than a system which has lots of new things only used by the s/w engineer. >Needless to say these are my views not Sun's... Needless to say these are my views not OSU's...
david@torsqnt.UUCP (David Haynes) (03/02/91)
martinb@bottomdog.East.Sun.COM (Martin Baines - Sun UK - SE Manager Cambridge/Gatwick) writes: >In article <1991Mar01.163348.24172@lynx.CS.ORST.EDU>, >johnm@mist.CS.ORST.EDU (John Matzka) writes: >[delete comments regarding fitness of Sequent s/w and followups] >|> I would be interested to see you put 500+ simultaneous users on a >dozen suns. >I really couldn't resist this one: 500 users on a dozen Suns = >500/12 Users per system = >41.67 users per system. > >Let's call it 50 users per system to be fair :-) > >Each SS400 = 22 MIPS => 0.44 MIPS/user >Say the Sequent had 30 processors rated at 5 MIPS each >i.e. 30*5 = 150 MIPS => 0.3 MIPS/user > >So it look's like the dozen Suns would give you *more* power per user >than a single Sequent. But let's use current Sequent technology, 30 processors at 14 MIPS (486s in the Series 2000/700) This would give 30*14 = 420 MIPS => 0.84 MIPS/user Seems to swing the balance again! -david- Anyone who measures the system performance using MIPS must be the person P.T. Barnum was talking about. -- David Haynes Sequent Computer Systems (Canada) Ltd. david@torsqnt.UUCP ---------------------------------------------------------------------------- Next week we will be discussing the Canadian High Tech industry. We will be visiting both companies and talking with all eight people involved. -- C.R.
dafuller@sequent.UUCP (David Fuller) (03/03/91)
In article <1439@torsqnt.UUCP> david@torsqnt.UUCP (David Haynes) writes: >martinb@bottomdog.East.Sun.COM (Martin Baines - Sun UK - SE Manager Cambridge/Gatwick) writes: > > >>In article <1991Mar01.163348.24172@lynx.CS.ORST.EDU>, >>johnm@mist.CS.ORST.EDU (John Matzka) writes: > >>[delete comments regarding fitness of Sequent s/w and followups] > >>|> I would be interested to see you put 500+ simultaneous users on a >>dozen suns. > >>I really couldn't resist this one: 500 users on a dozen Suns = >>500/12 Users per system = >>41.67 users per system. >> >>Let's call it 50 users per system to be fair :-) >> >>Each SS400 = 22 MIPS => 0.44 MIPS/user >>Say the Sequent had 30 processors rated at 5 MIPS each >>i.e. 30*5 = 150 MIPS => 0.3 MIPS/user >> >>So it look's like the dozen Suns would give you *more* power per user >>than a single Sequent. Measure with a micrometer. Mark with chalk. Cut with an axe. -- Dave Fuller Sequent Computer Systems Think of this as the hyper-signature. (708) 318-0050 (humans) It means all things to all people. dafuller@sequent.com
paul@uxc.cso.uiuc.edu (Paul Pomes - UofIllinois CSO) (03/04/91)
david@torsqnt.UUCP (David Haynes) writes: >But let's use current Sequent technology, 30 processors at >14 MIPS (486s in the Series 2000/700) > >(More performance figures deleted) Getting back to the original subject, would anyone from Sequent care to comment WHEN a more up to date Berkeley release will be made available? Same question for NFS (under Dynix, not ptx). If Sequent does not have a commitment to support a Berkeley environment in a reasonable way, I will start recommending that we cut our losses and move to another vendor. /pbp -- Paul Pomes UUCP: {att,iuvax,uunet}!uiucuxc!paul Internet, BITNET: paul@uxc.cso.uiuc.edu US Mail: UofIllinois, CSO, 1304 W Springfield Ave, Urbana, IL 61801-2910
rbj@uunet.UU.NET (Root Boy Jim) (03/05/91)
In article <1439@torsqnt.UUCP> david@torsqnt.UUCP (David Haynes) writes: > >But let's use current Sequent technology, 30 processors at >14 MIPS (486s in the Series 2000/700) The sad thing is, that if you put 30 procs in the box, you won't be able to put much else in. Once again we run up against stupid backplane rules: "These are high priority, these are low, and these are dynamically determined." Now if only we could move that "firewall" one slot over... As a practical limit, 20 CPU's is about right. -- [rbj@uunet 1] stty sane unknown mode: sane
tim@ohday.sybase.com (Tim Wood) (03/05/91)
Here's my vote that Sequent designate Mach (or OSF/2) as their standard
operating system, and layer BSD and System V guests onto it. Would this
be doable in, say, three years?
Just trying to broaden the discussion,
-TW
---
Sybase, Inc. / 6475 Christie Ave. / Emeryville, CA / 94608 415-596-3500
WORK:tim@sybase.com {pacbell,pyramid,sun,{uunet,ucbvax}!mtxinu}!sybase!tim
PLAY:axolotl!tim@toad.com {sun,uunet}!hoptoad!axolotl!tim
Dis claim er dat claim, what's da difference? I'm da one doin da talkin' hea.ric@cs.arizona.edu (Ric Anderson) (03/06/91)
Owning a Sequent has certain been eye opening. Some things, like the performance with 100 students beating on it, are really nice. Others, like 1. Lack of Sticky Bit enforcement on directories; 2. rejecting NFS file requests from users in more than 8 groups (even if the user OWNS the file in question); 3. no NFS record locking; are a continuing problem. Dynix/ptx does not seem to address item 2 or 3 above, since ptx allegedly is still based on the same NFS that Dynix 3.0.17 has. I don't know about item 1 under ptx. Of these, I think item 1 is the biggest problem, because without it, any user can remove a file in a world writable directory. With Sticky Bit enforcement, you can only remove/rename files you own. Since some directories (tmp, /usr/tmp,...) don't work well if they are not world writable, Sticky Bit enforcement on such directories is a must. Item 2 is also serious, because it constantly frustrates people. Most older NFS implementations truncate the request to 8 groups, so you can still get to your own files across NFS, but Sequent's draconian approach disallows even that civility. Item 3 is a nuisance for us, but it would be nice to have it fixed. We knew Sequent had an older BSD implementation when we acquired the system. We did not realize the seriousness of the NFS deficiencies. I don't know if such knowledge would have changed the purchase decision, but I have no doubt it would have weighed heavily against Sequent. We have certainly learned some important additional questions to ask potential vendors as a result of this experience :-( Ric Ric Anderson Member of the Technical Staff University of Arizona Internet: ric@cs.arizona.edu Department of Computer Science UUCP: uunet!arizona!ric Gould-Simpson Room 721 Bitnet: ric%cs.arizona.edu@arizona.bitnet Tucson, Arizona 85721 AT&T: (602) 621-4048
gustav@arp.anu.edu.au (Zdzislaw Meglicki) (03/06/91)
I basically gave up on using Sequent as a file server. It's NFS facilities are too antiquated even under the recent DYNIX 3.0.17.9 (which is what I have installed right now). It's a pity, because serving file systems is one of the things that Sequent would be very good at. I am thinking about moving to a Public Domain version of NIS if I ever can get my hands on it or Andrew File System. I'm not sure if the latter would run without Mach though. -- Gustav Meglicki, gustav@arp.anu.edu.au, Automated Reasoning Project, RSSS, and Plasma Theory Group, RSPhysS, The Australian National University, G.P.O. Box 4, Canberra, A.C.T., 2601, Australia, fax: (Australia)-6-249-0747, tel: (Australia)-6-249-0158
dgb@unislc.uucp (Douglas Barrett) (03/07/91)
> But let's use current Sequent technology, 30 processors at > 14 MIPS (486s in the Series 2000/700) > > This would give 30*14 = 420 MIPS => 0.84 MIPS/user > > Seems to swing the balance again! ^^^^^^^ or the symmetry? how much would a Series 2k/700 cabnet, hdc, 1G disc, ~200MB, 30X486 system cost? Has anyone ever run your system with 15 486 proc boards?
david@torsqnt.UUCP (David Haynes) (03/09/91)
dgb@unislc.uucp (Douglas Barrett) writes: >how much would a Series 2k/700 cabnet, hdc, 1G disc, ~200MB, >30X486 system cost? Has anyone ever run your system with >15 486 proc boards? Lest everyone take this all too seriously, my point was that determining the usefulness of a computer system by adding up the MIPage or (worse) taking the price and dividing by the MIPage is just plain stupid. Firstly: No one has defined the MIP in any way that is useful. Secondly: MIPs measure CPU performance. If all you do is sit in cache and spin, it *may* be a useful measurement. If you operate with memory, disk, terminals et al, you need to determine *SYSTEM* performance, not just CPU performance. Thirdly: The SYSTEM performance measured *has* to be relevant to the work you want the machine to do. Measuring the Mflop rate of a machine for which you wish to do commercial relational database work is ludicrous! None of the commercial RDBMS use floating point in a major way. Conversely, maximizing disk performance for ray tracing may not buy you as much as additional Mflop performance. For more details on the issues of benchmarking, may I point everyone to comp.benchmarks, and especially the notes from Eugene Miya. -david- -- David Haynes Sequent Computer Systems (Canada) Ltd. david@torsqnt.UUCP ---------------------------------------------------------------------------- Sometimes I think the world is filled with mindless sheep constantly bleating "MIIIIPPPPPSSSS, MMMMIIIIIPPPPPSSSS" until they are lead to slaughter.
oneill@ulowell.ulowell.edu (Brian 'Doc' O'Neill) (03/15/91)
In article <1991Mar3.160647.7902@ux1.cso.uiuc.edu> Paul-Pomes@uiuc.edu writes: > >Getting back to the original subject, would anyone from Sequent care to >comment WHEN a more up to date Berkeley release will be made available? > >Same question for NFS (under Dynix, not ptx). > >If Sequent does not have a commitment to support a Berkeley environment in >a reasonable way, I will start recommending that we cut our losses and move >to another vendor. > >/pbp In dealing with Sequent in the past few weeks, I did receive a little information. There will be at least one new release of Dynix 3, specifically 3.1. Dynix/ptx will go to SysVR4 around the end of this year, and Dynix 3 may not be continued. Dynix/ptx is the only OS supported on the low-end S2000/200. I don't remember all the specifics, but I know 3.1 will support disk quotas. Not sure about NFS. Forgot to ask. -- ======================================================================= Brian O'Neill - Systems Manager, Computer Science, University of Lowell Internet: oneill@ulowell.edu (508) 934-3645 UUCP: harvard!ulowell!oneill