Path: gmdzi!unido!fauern!ira.uka.de!sol.ctr.columbia.edu!samsung!caen!uwm.edu!ux1.cso.uiuc.edu!phil
From: p...@ux1.cso.uiuc.edu (Phil Howard KA9WGN)
Newsgroups: comp.sys.sequent
Subject: mv not atomic in dynix
Keywords: mv
Message-ID: <1991Feb16.000101.4149@ux1.cso.uiuc.edu>
Date: 16 Feb 91 00:01:01 GMT
Organization: University of Illinois at Urbana
Lines: 21
I discovered the following when trying to use "mv" to rename a directory in
order to syncronize a shell script so that only one could operate on a set
of files at one time under circumstances where more than one instance might
get started at once occaisionally. The shell script runs in the background
and today I had a situation where a couple of them got started in parallel.
When two (or more) "mv" commands try to rename the same file OR DIRECTORY
to two DIFFERENT names at the same time, the result can be two separate
hard links to the same inode. In the case of directories, "ln" (or the
underlying system call) will refuse to allow this to happen except if the
uid is root.
While the non-atomic nature of "mv" might cause some syncronizing problems
with shell scripts that assume it is atomic, the fact that this can happen
to directories appears to be a more serious problem.
Has this been reported anywhere yet?
--
--Phil Howard, KA9WGN-- | Individual CHOICE is fundamental to a free society
<p...@ux1.cso.uiuc.edu> | no matter what the particular issue is all about.
Path: gmdzi!unido!mcsun!sunic!uupsi!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!pyramid!csg
From: c...@pyramid.pyramid.com (Carl S. Gutekunst)
Newsgroups: comp.sys.sequent
Subject: Re: mv not atomic in dynix
Keywords: mv
Message-ID: <145463@pyramid.pyramid.com>
Date: 19 Feb 91 23:55:23 GMT
References: <1991Feb16.000101.4149@ux1.cso.uiuc.edu>
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 17
If you are talking about DYNIX (4.2BSD), this is not true; the rename(2)
system call is used and it is atomic. Assuming you aren't using the mv(1) in
the att universe, of course.
If you are talking about DYNIX/ptx (SVR3.2), then you are correct. There is
no rename(2) call, mv(1) is not atomic (it uses link(2) and unlink(2)), and
you are SOL. That's just the way System V works.
[Editorial Comment: Companies that give the same name (or a trivial variation,
like the version code) to radically different operating systems should be
lynched by their justifiably outraged customers. That includes the old Gould,
which had who-knows-how-many different things all called UTX; Sun, which last
I knew is going to call their SVR4 port "SunOS 5.0"; and many others. Sequent
chose to walk a very well trodden path, and I know of other companies that
plan to follow.]
<csg>
Path: gmdzi!unido!fauern!ira.uka.de!sol.ctr.columbia.edu!samsung!spool.mu.edu!uunet!zephyr.ens.tek.com!tektronix!sequent!petebob
From: pete...@sequent.UUCP (Pete_Bob Apple)
Newsgroups: comp.sys.sequent
Subject: Re: mv not atomic in dynix
Keywords: mv
Message-ID: <53625@sequent.UUCP>
Date: 20 Feb 91 17:57:30 GMT
References: <1991Feb16.000101.4149@ux1.cso.uiuc.edu> <145463@pyramid.pyramid.com>
Reply-To: pete...@eng3.UUCP (Pete Apple)
Organization: Sequent Computer Systems, Inc.
Lines: 31
In article <145...@pyramid.pyramid.com> c...@pyramid.pyramid.com (Carl S. Gutekunst) writes:
>If you are talking about DYNIX (4.2BSD), this is not true; the rename(2)
>system call is used and it is atomic. Assuming you aren't using the mv(1) in
>the att universe, of course.
The att universe version of mv_dir uses the rename(2) system call.
The ucb universe is just as described, the standard 4.2BSD version of mv(1).
>If you are talking about DYNIX/ptx (SVR3.2), then you are correct. There is
>no rename(2) call, mv(1) is not atomic (it uses link(2) and unlink(2)), and
>you are SOL. That's just the way System V works.
That's not how DYNIX/ptx works. There is a rename(2) system call in
DYNIX/ptx and mv(1) has been changed to use it. rename(2) has been
there from the beginning of DYNIX/ptx. I believe mv(1) was changed to
use rename(2) for the V1.1 release.
[Editorial Comment: Remember, I'm a just an en-g-neer, not a spokesman:]
One of the ideas behind calling the new operating system DYNIX/ptx was
to give the impression that it is based on the original DYNIX. Many
important features from DYNIX (such as rename(2)) were added to
DYNIX/ptx while still maintaining industry standards. (SVR3.2, SVID,
POSIX, XPG, etc)
Personally, I wanted to call it DYNIX_Bob, but no one listened to me. :-) :-)
--
Pete_Bob Apple Sequent Computer Systems
pete...@sequent.com, sequent!petebob 15450 S.W. Koll Parkway
Bob is not just a name.. Beaverton, Oregon 97006
It's a way of life.. (503) 626-5700
Path: gmdzi!unido!fauern!ira.uka.de!sol.ctr.columbia.edu!spool.mu.edu!uunet!rbj
From: r...@uunet.UU.NET (Root Boy Jim)
Newsgroups: comp.sys.sequent
Subject: Re: mv not atomic in dynix
Keywords: mv
Message-ID: <123459@uunet.UU.NET>
Date: 21 Feb 91 00:01:45 GMT
References: <1991Feb16.000101.4149@ux1.cso.uiuc.edu> <145463@pyramid.pyramid.com> <53625@sequent.UUCP>
Organization: UUNET Communications Services, Falls Church, VA
Lines: 62
In article <53...@sequent.UUCP> pete...@eng3.UUCP (Pete Apple) writes:
?In article <145...@pyramid.pyramid.com> c...@pyramid.pyramid.com (Carl S. Gutekunst) writes:
?>If you are talking about DYNIX (4.2BSD), this is not true; the rename(2)
?>system call is used and it is atomic. Assuming you aren't using the mv(1) in
?>the att universe, of course.
?
?The att universe version of mv_dir uses the rename(2) system call.
It took AT&T long enuf to realize they needed mkdir, rmdir, and rename
system calls. Unfortunately, they still insist on this nonsense mvdir command.
?The ucb universe is just as described, the standard 4.2BSD version of mv(1).
Except that the standard isn't 4.2 anymore. It's 4.3. And beyond.
There are many of your customers who are distressed at the low
baud rate at which bits flow from UCB to each of your companies.
?>If you are talking about DYNIX/ptx (SVR3.2), then you are correct. There is
?>no rename(2) call, mv(1) is not atomic (it uses link(2) and unlink(2)), and
?>you are SOL. That's just the way System V works.
Ooooh, that's scary! However, I wonder about the AT&T broken ln syndrome.
Somewhere along the line, AT&T broke ln(1) so that if you do:
who > a; ls > b; ln a b
you will get one file with two links successfully,
rather than two different files and failure.
?That's not how DYNIX/ptx works. There is a rename(2) system call in
?DYNIX/ptx and mv(1) has been changed to use it. rename(2) has been
?there from the beginning of DYNIX/ptx. I believe mv(1) was changed to
?use rename(2) for the V1.1 release.
Well, Carl, that'll teach you to post flames in a hostile newsgroup :-)
?[Editorial Comment: Remember, I'm a just an en-g-neer, not a spokesman:]
?One of the ideas behind calling the new operating system DYNIX/ptx was
?to give the impression that it is based on the original DYNIX. Many
?important features from DYNIX (such as rename(2)) were added to
?DYNIX/ptx while still maintaining industry standards. (SVR3.2, SVID,
?POSIX, XPG, etc)
And SVR3.2 isn't the standard either. SVR4 is.
And don't forget the most important standard: BSD.
I hope that PTX will not include this dual universe nonsense.
A unified approach (such as the one taken by Sun and Dec, probably others)
is much better. Users want the best features from both systems.
?Personally, I wanted to call it DYNIX_Bob, but no one listened to me. :-) :-)
?--
?Pete_Bob Apple Sequent Computer Systems
?pete...@sequent.com, sequent!petebob 15450 S.W. Koll Parkway
?Bob is not just a name.. Beaverton, Oregon 97006
?It's a way of life.. (503) 626-5700
I think you're too close to Twin Peaks :-)
--
[rbj@uunet 1] stty sane
unknown mode: sane
Path: gmdzi!unido!fauern!ira.uka.de!sol.ctr.columbia.edu!caen!sdd.hp.com!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!asuvax!noao!arizona!gmt
From: g...@cs.arizona.edu (Gregg Townsend)
Newsgroups: comp.sys.sequent
Subject: obsolete Sequent software
Keywords: mv
Message-ID: <536@coatimundi.cs.arizona.edu>
Date: 21 Feb 91 16:57:09 GMT
References: <1991Feb16.000101.4149@ux1.cso.uiuc.edu> <145463@pyramid.pyramid.com> <53625@sequent.UUCP> <123459@uunet.UU.NET>
Sender: n...@cs.arizona.edu
Organization: University of Arizona, Tucson
Lines: 16
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 g...@cs.arizona.edu 110 57 16 W / 32 13 45 N / +758m
Path: gmdzi!unido!fauern!ira.uka.de!sol.ctr.columbia.edu!caen!sdd.hp.com!spool.mu.edu!uunet!rbj
From: r...@uunet.UU.NET (Root Boy Jim)
Newsgroups: comp.sys.sequent
Subject: Re: obsolete Sequent software
Keywords: mv
Message-ID: <123562@uunet.UU.NET>
Date: 22 Feb 91 04:23:27 GMT
References: <53625@sequent.UUCP> <123459@uunet.UU.NET> <536@coatimundi.cs.arizona.edu>
Organization: UUNET Communications Services, Falls Church, VA
Lines: 25
In <5...@coatimundi.cs.arizona.edu> g...@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
Path: gmdzi!unido!fauern!ira.uka.de!sol.ctr.columbia.edu!caen!uakari.primate.wisc.edu!relay.nswc.navy.mil!oasys!curt
From: c...@oasys.dt.navy.mil (Curt Welch)
Newsgroups: comp.sys.sequent
Subject: Re: obsolete Sequent software
Message-ID: <6055@oasys.dt.navy.mil>
Date: 22 Feb 91 14:35:52 GMT
References: <1991Feb16.000101.4149@ux1.cso.uiuc.edu> <536@coatimundi.cs.arizona.edu>
Reply-To: c...@oasys.dt.navy.mil (Curt Welch)
Organization: David Taylor Research Center, Bethesda, MD
Lines: 40
In comp.sys.sequent, g...@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-requ...@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
c...@oasys.dt.navy.mil
Code 3531
David Taylor Research Center (A Navy Lab)
Bethesda, MD
(301) 227-1428
Path: gmdzi!unido!mcsun!uunet!bywater!scifi!hybrid!torsqnt!david
From: da...@torsqnt.UUCP (David Haynes)
Newsgroups: comp.sys.sequent
Subject: Re: obsolete Sequent software
Keywords: mv
Message-ID: <1438@torsqnt.UUCP>
Date: 22 Feb 91 13:09:28 GMT
References: <53625@sequent.UUCP> <123459@uunet.UU.NET> <536@coatimundi.cs.arizona.edu> <123562@uunet.UU.NET>
Organization: Sequent Computers (Canada) Ltd., Toronto, CANADA
Lines: 78
r...@uunet.UU.NET (Root Boy Jim) writes:
>In <5...@coatimundi.cs.arizona.edu> g...@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. da...@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.
Path: gmdzi!unido!fauern!ira.uka.de!sol.ctr.columbia.edu!spool.mu.edu!uunet!uunet.uu.net!rick
From: r...@uunet.uu.net (Rick Adams)
Newsgroups: comp.sys.sequent
Subject: Re: obsolete Sequent software
Summary: rigor mortis is also rock solid
Message-ID: <124108@uunet.UU.NET>
Date: 25 Feb 91 21:31:38 GMT
References: <1991Feb16.000101.4149@ux1.cso.uiuc.edu> <6055@oasys.dt.navy.mil>
Sender: use...@uunet.UU.NET
Lines: 55
Nntp-Posting-Host: uunet.uu.net
In article <6...@oasys.dt.navy.mil>, c...@oasys.dt.navy.mil (Curt Welch) writes:
> In comp.sys.sequent, g...@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...)
Path: gmdzi!unido!fauern!faui43.informatik.uni-erlangen.de!eckert
From: eck...@immd4.informatik.uni-erlangen.de (Toerless Eckert)
Newsgroups: comp.sys.sequent
Subject: Re: obsolete Sequent software
Message-ID: <1991Feb26.173944.3570@informatik.uni-erlangen.de>
Date: 26 Feb 91 17:39:44 GMT
References: <124108@uunet.UU.NET>
Organization: CSD., University of Erlangen, Germany
Lines: 60
From article <124...@uunet.UU.NET>, by r...@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.Eck...@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 ;-)
Path: gmdzi!unido!mcsun!uunet!uunet.uu.net!rick
From: r...@uunet.uu.net (Rick Adams)
Newsgroups: comp.sys.sequent
Subject: Re: obsolete Sequent software
Summary: timelines
Message-ID: <124172@uunet.UU.NET>
Date: 26 Feb 91 23:10:54 GMT
References: <124108@uunet.UU.NET> <1991Feb26.173944.3570@informatik.uni-erlangen.de>
Sender: use...@uunet.UU.NET
Lines: 16
Nntp-Posting-Host: uunet.uu.net
In article <1991Feb26.173944.3...@informatik.uni-erlangen.de>, eck...@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.
Path: gmdzi!unido!fauern!ira.uka.de!sol.ctr.columbia.edu!caen!uakari.primate.wisc.edu!dali.cs.montana.edu!ogicse!usenet!mist.CS.ORST.EDU!johnm
From: jo...@mist.CS.ORST.EDU (John Matzka)
Newsgroups: comp.sys.sequent
Subject: Re: obsolete Sequent software
Message-ID: <1991Mar01.163348.24172@lynx.CS.ORST.EDU>
Date: 1 Mar 91 16:33:48 GMT
References: <124108@uunet.UU.NET>
Sender: @lynx.CS.ORST.EDU
Organization: Computer Science Department, Oregon State Univ.
Lines: 27
Nntp-Posting-Host: mist.cs.orst.edu
In article <124...@uunet.UU.NET> r...@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 jo...@cs.orst.edu
Computer Science Dept. {ogicse,hp-pcd}!orstcs!johnm
Oregon State University I is not a spokesperson, I only live here.
Path: gmdzi!unido!fauern!ira.uka.de!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!sun-barr!newstop!west!bottomdog!martinb
From: mart...@bottomdog.East.Sun.COM (Martin Baines - Sun UK - SE Manager Cambridge/Gatwick)
Newsgroups: comp.sys.sequent
Subject: Re: obsolete Sequent software
Message-ID: <1469@west.West.Sun.COM>
Date: 1 Mar 91 17:36:24 GMT
References: <124108@uunet.UU.NET> <1991Mar01.163348.24172@lynx.CS.ORST.EDU>
Sender: n...@west.West.Sun.COM
Reply-To: Martin.Bai...@UK.Sun.Com
Organization: Sun Microsystems Ltd
Lines: 47
In article <1991Mar01.163348.24...@lynx.CS.ORST.EDU>,
jo...@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.Bai...@uk.co.sun |
| International: +44 223 420421 Other UK: Martin.Bai...@sun.co.uk |
| Internet: Martin.Bai...@UK.sun.com |
+----------------------------------------------------------------------------+
Path: gmdzi!unido!mcsun!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!censor!geac!torsqnt!david
From: da...@torsqnt.UUCP (David Haynes)
Newsgroups: comp.sys.sequent
Subject: Re: obsolete Sequent software
Message-ID: <1439@torsqnt.UUCP>
Date: 2 Mar 91 02:42:53 GMT
References: <124108@uunet.UU.NET> <1991Mar01.163348.24172@lynx.CS.ORST.EDU> <1469@west.West.Sun.COM>
Organization: Sequent Computers (Canada) Ltd., Toronto, CANADA
Lines: 40
mart...@bottomdog.East.Sun.COM (Martin Baines - Sun UK - SE Manager Cambridge/Gatwick) writes:
>In article <1991Mar01.163348.24...@lynx.CS.ORST.EDU>,
>jo...@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. da...@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.
Path: gmdzi!unido!mcsun!uunet!spool.mu.edu!news.cs.indiana.edu!ux1.cso.uiuc.edu!uxc.cso.uiuc.edu!paul
From: p...@uxc.cso.uiuc.edu (Paul Pomes - UofIllinois CSO)
Newsgroups: comp.sys.sequent
Subject: Re: obsolete Sequent software
Message-ID: <1991Mar3.160647.7902@ux1.cso.uiuc.edu>
Date: 3 Mar 91 16:06:47 GMT
References: <124108@uunet.UU.NET> <1991Mar01.163348.24172@lynx.CS.ORST.EDU> <1469@west.West.Sun.COM> <1439@torsqnt.UUCP>
Sender: use...@ux1.cso.uiuc.edu (News)
Reply-To: Paul-Po...@uiuc.edu
Organization: University of Illinois at Urbana
Lines: 22
Posted: Sun Mar 3 10:06:47 1991
da...@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: p...@uxc.cso.uiuc.edu
US Mail: UofIllinois, CSO, 1304 W Springfield Ave, Urbana, IL 61801-2910
Path: gmdzi!unido!mcsun!uunet!samsung!usc!orion.oac.uci.edu!cerritos.edu!arizona.edu!arizona!ric
From: r...@cs.arizona.edu (Ric Anderson)
Newsgroups: comp.sys.sequent
Subject: Re: obsolete Sequent software
Message-ID: <1037@caslon.cs.arizona.edu>
Date: 5 Mar 91 18:24:05 GMT
References: <124708@uunet.UU.NET>
Organization: U of Arizona CS Dept, Tucson
Lines: 41
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: r...@cs.arizona.edu
Department of Computer Science UUCP: uunet!arizona!ric
Gould-Simpson Room 721 Bitnet: ric%cs.arizona....@arizona.bitnet
Tucson, Arizona 85721 AT&T: (602) 621-4048
Path: gmdzi!unido!mcsun!uunet!tut.cis.ohio-state.edu!ucbvax!mtxinu!sybase!ohday!tim
From: t...@ohday.sybase.com (Tim Wood)
Newsgroups: comp.sys.sequent
Subject: Re: obsolete Sequent software
Keywords: mv
Message-ID: <12617@sybase.sybase.com>
Date: 5 Mar 91 02:34:31 GMT
References: <53625@sequent.UUCP> <123459@uunet.UU.NET> <536@coatimundi.cs.arizona.edu> <123562@uunet.UU.NET>
Sender: n...@Sybase.COM
Organization: Sybase, Inc.
Lines: 10
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:t...@sybase.com {pacbell,pyramid,sun,{uunet,ucbvax}!mtxinu}!sybase!tim
PLAY:axolotl!...@toad.com {sun,uunet}!hoptoad!axolotl!tim
Dis claim er dat claim, what's da difference? I'm da one doin da talkin' hea.
Path: gmdzi!unido!mcsun!uunet!snorkelwacker.mit.edu!spool.mu.edu!munnari.oz.au!manuel!gustav
From: gus...@arp.anu.edu.au (Zdzislaw Meglicki)
Newsgroups: comp.sys.sequent
Subject: Re: obsolete Sequent software
Message-ID: <1991Mar6.164654@arp.anu.edu.au>
Date: 6 Mar 91 06:46:54 GMT
References: <124708@uunet.UU.NET> <1037@caslon.cs.arizona.edu>
Sender: n...@newshost.anu.edu.au
Reply-To: gus...@arp.anu.edu.au (Zdzislaw Meglicki)
Organization: Australian National University, Canberra
Lines: 14
Originator: gus...@diana.anu.edu.au
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, gus...@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
Path: gmdzi!unido!mcsun!uunet!wuarchive!zaphod.mps.ohio-state.edu!rpi!uwm.edu!rutgers!news-server.csri.toronto.edu!utgpu!utzoo!mnetor!tmsoft!torsqnt!david
From: da...@torsqnt.UUCP (David Haynes)
Newsgroups: comp.sys.sequent
Subject: Re: Mach as a replacement O/S (was obsolete software)
Keywords: mv
Message-ID: <1443@torsqnt.UUCP>
Date: 10 Mar 91 13:22:06 GMT
References: <53625@sequent.UUCP> <123459@uunet.UU.NET> <536@coatimundi.cs.arizona.edu> <123562@uunet.UU.NET> <12617@sybase.sybase.com>
Organization: Sequent Computers (Canada) Ltd., Toronto, CANADA
Lines: 48
t...@ohday.sybase.com (Tim Wood) writes:
>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
This is interesting....
A couple of points come to mind.
1. You can get Mach for the Sequent systems now and have been able to
get it for at least 3 years that I know of.
2. I have never been asked by a university for it.
3. Right now, I wouldn't say that Mach was a commercially viable
alternative to UNIX. While systems such as the NeXt are running it
successfully, they have the advantage of a tightly defined hardware
environment. In a more general environment, there are more choices
and therefore more places for errors to occur.
4. Discussions I have had with some folks from CMU indicate that Mach
needs a lot of work under the hood, before even they will feel
comfortable with it.
5. I spend a good portion of my day hearing people say things like,
"We've decided to standardize on COBOL. We are now converting
all our FORTRAN code to the standard."
Do you really think these folks are ready for a new O/S?
6. Please notice that I have not said that Mach is not a technologically
viable O/S or that Mach does not have its place in the universities,
and eventually the commerical market place, but I do question the
timeframe outlined above.
These opinions are definitely my own and in no way, shape or form should
be thought to reflect Sequent philosophy, policy or corporate direction.
I have enough troubles... ;-)
-david-
--
David Haynes Sequent Computer Systems (Canada) Ltd. da...@torsqnt.UUCP
----------------------------------------------------------------------------
Sometimes I think the world is filled with mindless sheep constantly bleating
"MIIIIPPPPPSSSS, MMMMIIIIIPPPPPSSSS" until they are lead to slaughter.
Path: gmdzi!unido!mcsun!uunet!stanford.edu!msi.umn.edu!s13.msi.umn.edu!zoo
From: z...@aps1.spa.umn.edu (david d [zoo] zuhn)
Newsgroups: comp.sys.sequent
Subject: Re: Mach as a replacement O/S (was obsolete software)
Message-ID: <ZOO.91Mar11005948@grumpy.spa.umn.edu>
Date: 11 Mar 91 05:59:48 GMT
References: <53625@sequent.UUCP> <123459@uunet.UU.NET> <536@coatimundi.cs.arizona.edu>
<123562@uunet.UU.NET> <12617@sybase.sybase.com> <1443@torsqnt.UUCP>
Sender: n...@s1.msi.umn.edu
Reply-To: z...@aps1.spa.umn.edu
Organization: Minnesota Automated Plate Scanner Lab
Lines: 29
In-Reply-To: david@torsqnt.UUCP's message of 10 Mar 91 13:22:06 GMT
Nntp-Posting-Host: grumpy.spa.umn.edu
>>>>> On 10 Mar 91 13:22:06 GMT, da...@torsqnt.UUCP (David Haynes) said:
David> 1. You can get Mach for the Sequent systems now and have been able to
David> get it for at least 3 years that I know of.
David> 2. I have never been asked by a university for it.
This doesn't surprise me at all. We heard about Mach for the Symmetry
when I was working on the systems staff of the local CS dept, which
runs an S27 as the departmental backbone machine. We started to look
into Sequent's Mach, and what we saw scared us:
1) Sequent said that they would not support anything on that OS. We
could not afford to have an unsupported machine as the backbone.
2) No NFS at all. Another *VERY* negative point for our site.
3) A fairly high cost for unsupported software (the number $15,000
sticks in my mind.
Things may have changed much in the couple of years since these first
looks into Mach. I somehow doubt it, given the rate of change in
Sequent OS releases.
NOTE: I no longer work for the above mentioned CS dept, and am in no
way, shape or form speaking for them or expressing an official opinion
of the CS dept. I don't even think we formally brought up the idea
with the head honchos, given the lack of support and NFS.
david d [zoo] zuhn Univ. of Minnesota Dept. of Astronomy
z...@aps1.spa.umn.edu Automated Plate Scanner Project
Path: gmdzi!unido!fauern!ira.uka.de!sol.ctr.columbia.edu!spool.mu.edu!munnari.oz.au!manuel!gustav
From: gus...@arp.anu.edu.au (Zdzislaw Meglicki)
Newsgroups: comp.sys.sequent
Subject: Re: Mach as a replacement O/S (was obsolete software)
Message-ID: <1991Mar13.221353@arp.anu.edu.au>
Date: 13 Mar 91 12:13:53 GMT
References: <53625@sequent.UUCP> <123459@uunet.UU.NET> <536@coatimundi.cs.arizona.edu> <ZOO.91Mar11005948@grumpy.spa.umn.edu>
Sender: n...@newshost.anu.edu.au
Reply-To: gus...@arp.anu.edu.au (Zdzislaw Meglicki)
Organization: Australian National University, Canberra
Lines: 37
Originator: gus...@diana.anu.edu.au
In article <ZOO.91Mar11005...@grumpy.spa.umn.edu>, z...@aps1.spa.umn.edu (david d [zoo] zuhn) writes:
|> >>>>> On 10 Mar 91 13:22:06 GMT, da...@torsqnt.UUCP (David Haynes) said:
|>
|> David> 1. You can get Mach for the Sequent systems now and have been able to
|> David> get it for at least 3 years that I know of.
|> David> 2. I have never been asked by a university for it.
That's strange, because I represent the University (the Australian National University)
and I have asked for Mach on the Sequent. What more, I have gone through all the
trouble and expense of getting AT&T UNIX V R4 license that was required by
the Sequent, and in spite of numerous e-mail messages I still didn't get
the tapes.
In the meantime, I've been told by David Golub from Carnegie Mellon, that
they actually have Mach 3.0 single-server BSD 4.3 system running on
their Sequent. Sequent itself provides only Mach 2.5 with DYNIX instead
of BSD 4.3 put on top of it. Their, i.e., Carnegie's version "doesn't fit Sequent's
list of bugs, but then many of those listed involve Dynix/Mach
compatibility, which CMU is not interested in." (D.G.)
Since our S27 is configured mostly as a research machine, and we don't have any
DYNIX based commercial software installed, a system such as that from Carnegie
Mellon would suit me just fine.
I've written to D.G. asking for more details and a possibility of getting
the installation from them (19th Feb), but I didn't get any information
back yet.
I am not exactly paranoid, but it smacks of a conspiracy... Am I ever going
to see Mach on my S27, I wonder? (In the meantime it's been turned into
a GNU machine - at least that I can get via ftp).
--
Gustav Meglicki, gus...@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
Path: gmdzi!unido!fauern!ira.uka.de!sol.ctr.columbia.edu!spool.mu.edu!munnari.oz.au!manuel!gustav
From: gus...@arp.anu.edu.au (Zdzislaw Meglicki)
Newsgroups: comp.sys.sequent
Subject: Re: Mach as a replacement O/S (was obsolete software)
Message-ID: <1991Mar13.222938@arp.anu.edu.au>
Date: 13 Mar 91 12:29:38 GMT
References: <53625@sequent.UUCP> <123459@uunet.UU.NET> <536@coatimundi.cs.arizona.edu> <ZOO.91Mar11005948@grumpy.spa.umn.edu> <1991Mar13.221353@arp.anu.edu.au>
Sender: n...@newshost.anu.edu.au
Reply-To: gus...@arp.anu.edu.au (Zdzislaw Meglicki)
Organization: Australian National University, Canberra
Lines: 15
Originator: gus...@diana.anu.edu.au
Aha, one more thing... Someone suggested here in comp.sys.sequent
that Sequent should embrace OSF/2. What Sequent could do is to
provide two alternative OSs - much like DIGITAL (VMS and Ultrix)
or CRAY (once upon a time). A system such as OSF/2 may turn to
be highly portable and with much of the work already done by OSF
maintenance on the side of the Sequent could be much reduced.
Also, since OSF/1 is based on Mach 2.5, and Sequent has already
Mach 2.5/DYNIX combination working (although not without problems),
to offer OSF/1 or 2 should be that much easier.
--
Gustav Meglicki, gus...@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
Path: gmdzi!unido!fauern!ira.uka.de!sol.ctr.columbia.edu!caen!sdd.hp.com!hplabs!pyramid!csg
From: c...@pyramid.pyramid.com (Carl S. Gutekunst)
Newsgroups: comp.sys.sequent
Subject: Re: Mach as a replacement O/S (was obsolete software)
Message-ID: <148150@pyramid.pyramid.com>
Date: 13 Mar 91 21:49:44 GMT
References: <ZOO.91Mar11005948@grumpy.spa.umn.edu> <1991Mar13.221353@arp.anu.edu.au> <1991Mar13.222938@arp.anu.edu.au>
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 11
>A system such as OSF/2 may turn to be highly portable and with much of the
>work already done by OSF maintenance on the side of the Sequent could be
>much reduced.
Haw! Haw! Haw! Haw!!!! *Guffaw* *Gasp* *Giggle*
Oops, I better restrain myself.
Never worked for a system vendor, I see. :-)
<csg>
Path: gmdzi!unido!mcsun!sunic!uupsi!rpi!usc!apple!bbn.com!ulowell!oneill
From: one...@ulowell.ulowell.edu (Brian 'Doc' O'Neill)
Newsgroups: comp.sys.sequent
Subject: Re: obsolete Sequent software
Message-ID: <1991Mar15.151338.18355@ulowell.ulowell.edu>
Date: 15 Mar 91 15:13:38 GMT
References: <1469@west.West.Sun.COM> <1439@torsqnt.UUCP> <1991Mar3.160647.7902@ux1.cso.uiuc.edu>
Organization: University of Lowell Computer Science, Lowell MA
Lines: 28
In article <1991Mar3.160647.7...@ux1.cso.uiuc.edu> Paul-Po...@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: one...@ulowell.edu (508) 934-3645
UUCP: harvard!ulowell!oneill
Path: gmdzi!unido!mcsun!uunet!timbuk!cs.umn.edu!spool.mu.edu!sol.ctr.columbia.edu!emory!gatech!purdue!haven!boingo.med.jhu.edu!aplcen!wb3ffv!ka3ovk!raysnec!shwake
From: shw...@raysnec.UUCP (Ray Shwake)
Newsgroups: comp.sys.sequent
Subject: Re: Mach as a replacement O/S (was obsolete software)
Message-ID: <266@raysnec.UUCP>
Date: 15 Mar 91 21:43:39 GMT
References: <53625@sequent.UUCP> <123459@uunet.UU.NET> <536@coatimundi.cs.arizona.edu> <ZOO.91Mar11005948@grumpy.spa.umn.edu> <1991Mar13.221353@arp.anu.edu.au> <1991Mar13.222938@arp.anu.edu.au>
Organization: IRS/CI - Technical Solutions Branch
Lines: 16
gus...@arp.anu.edu.au (Zdzislaw Meglicki) writes:
>Aha, one more thing... Someone suggested here in comp.sys.sequent
>that Sequent should embrace OSF/2. What Sequent could do is to
>provide two alternative OSs - much like DIGITAL (VMS and Ultrix)
>or CRAY (once upon a time). A system such as OSF/2 may turn to
>be highly portable and with much of the work already done by OSF
>maintenance on the side of the Sequent could be much reduced.
Might one be so blunt as to point out that OSF/2 does not exist!
Heck, OSF only released OSF/1 last November. Realistically, don't expect
OSF/2 for another 18-24 months, perhaps another year beyond that for it
to appear as a robust, commercial product.
-----------
uunet!media!ka3ovk!raysnec!shwake shwake@rsxtech
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!pitt!vax.cs.pitt.edu!jonathan
From: jonat...@cs.pitt.edu (Jonathan Eunice)
Newsgroups: comp.sys.sequent
Subject: Re: Mach as a replacement O/S (was obsolete software)
Message-ID: <JONATHAN.91Mar25052942@speedy.cs.pitt.edu>
Date: 25 Mar 91 10:29:42 GMT
References: <53625@sequent.UUCP> <123459@uunet.UU.NET>
<536@coatimundi.cs.arizona.edu> <ZOO.91Mar11005948@grumpy.spa.umn.edu>
<1991Mar13.221353@arp.anu.edu.au> <1991Mar13.222938@arp.anu.edu.au>
<266@raysnec.UUCP>
Sender: n...@pitt.UUCP
Organization: University of Pittsburgh Computer Science
Lines: 21
In article <2...@raysnec.UUCP> shw...@raysnec.UUCP (Ray Shwake) writes:
gustav> Aha, one more thing... Someone suggested here in comp.sys.sequent
gustav> that Sequent should embrace OSF/2. What Sequent could do is to
gustav> provide two alternative OSs - much like DIGITAL (VMS and Ultrix)
gustav> or CRAY (once upon a time). A system such as OSF/2 may turn to
gustav> be highly portable and with much of the work already done by OSF
gustav> maintenance on the side of the Sequent could be much reduced.
shwake> Might one be so blunt as to point out that OSF/2 does not exist!
shwake> Heck, OSF only released OSF/1 last November. Realistically, don't
shwake> expect OSF/2 for another 18-24 months, perhaps another year beyond that
shwake> for it to appear as a robust, commercial product.
I'd be *real surprised* to see OSF/2 in 18-24 months. This mythical
beast is nowhere close. OSF is much more likely to release
incremental systems, some of which may partially adopt the true
micro-kernel approach. Specialized server implementations, for
example. At least, this is what Ira Goldstein et al were saying at
Uniforum this Janurary. At this point, OSF/2 is identical to Microsoft's
NT -- micro-kernel-vaporware.
Path: gmdzi!unido!mcsun!uunet!cs.utexas.edu!helios!mtecv2!jgabriel
From: jgabr...@mtecv2.mty.itesm.mx (Ing. J. Gabriel Ruiz P.)
Newsgroups: comp.sys.sequent
Subject: Sequent & DYNIX new user
Keywords: sequent dinix unix
Message-ID: <3441@mtecv2.mty.itesm.mx>
Date: 5 Jun 91 18:33:15 GMT
Organization: ITESM. Campus Monterrey
Lines: 14
Actually in our university we are evaluating some computers to
choose a good account server (NIS server). We'll try a Sequent with
six 386 microprocessors. I like to hear about some experiences with
this kind of machines and about NIS on DYNIX. And one more question
any body knows if DINIX is a System V like, or BSD like or POSIX like
UNIX?
Thank's in advance.
--
Juan Gabriel Ruiz Pinto Internet:
Ing. Sistemas Electronicos jgabr...@mtecv2.mty.itesm.mx
I.T.E.S.M. Campus Monterrey
Path: gmdzi!unido!mcsun!uunet!cs.utexas.edu!sun-barr!ccut!wnoc-tyo-news!astemgw!icspub!taeko!sqsosk!caz
From: c...@psq.mei.co.jp (Caz Yokoyama)
Newsgroups: comp.sys.sequent
Subject: Re: Sequent & DYNIX new user
Message-ID: <CAZ.91Jun21175735@sqsosk.psq.mei.co.jp>
Date: 21 Jun 91 08:57:35 GMT
References: <3441@mtecv2.mty.itesm.mx>
Sender: c...@sqsosk.psq.mei.co.jp
Organization: Pana-Sequent Inc. Osaka
Lines: 21
In-reply-to: jgabriel@mtecv2.mty.itesm.mx's message of 5 Jun 91 18:33:15 GMT
Currently Sequent computer has two OS named Dynix V3 and Dynix/ptx.
I guess you will purchase Dynix V3 because you are belong to university.
Dynix V3 is based on BSD, and Dynix/ptx is based on ATT System V R3.2.
Dynix V3 has two universe which are ATT universe and UCB universe.
You can traverse UCB universe and ATT universe at login time or
by ucb and att command after you login. Basically Dynix 3 is BSD machine.
Sequent putted ATT layer upon BSD based machine line Pyramid.
-caz
-----------------------------------------------
this kind of machines and about NIS on DYNIX. And one more question
any body knows if DINIX is a System V like, or BSD like or POSIX like
UNIX?
--
$@2#;3!!OBM3(J, Caz Yokoyama
Pana-Sequent Inc.
Office: 3-12-22 Minami-Senba, Chuuou-ku, Osaka 542 Japan
Phone: +81-6-281-1850, Fax: +81-6-281-1867
E-mail: c...@psq.mei.co.jp, Call sign: JH3JJZ
|