Comparison of Alpha, MIPS and PA-RISC-II wanted
Dov Grobgeld
in the department of Chemical Physics. We have three companies in
consideration, HP, SGI, and DEC. (IBM still after a couple of weeks
hasn't called back...) One of the major questions that has been
raised is how stable our investment is in terms of the long time
development of the major chip of the architecture we choose.
Our general feeling is that the worst choice is SGI with the MIPS
4000A chip. Clearly, judging on the very late release of the 4000A
chip, MIPS has had problems with the development. Since the MIPS
family is an old family, and because of these problems, it seems
likely that there is not too much chance of ever seeing a MIPS 5000
chip and a MIPS 6000 chip.
On the other hand, the Alpha chip is a new architecture, which in its
design was made to be able to grow. The question is if it is not too
young in terms of software support. Even DEC themself admit that
there are problems with their OSF/1. But these problems should
certainly dissappear in a couple of years. And how good really is the
Alpha chip?
We have the least knowledge of the HP PA-RISC-II chip. How does it
compare to the Alpha chip? What are the prospects of development for
it?
Any comments will be very, very helpful. Please answer by e-mail and
I'll make a summary if there is sufficient interest.
--
___ ___
/ o \ o \
Dov Grobgeld ( o o ) o |
The Weizmann Institute of Science, Israel \ o /o o /
"Where the tree of wisdom carries oranges" | | | |
_| |_ _| |_
Marcus J. Ranum AXP
>there are problems with their OSF/1. But these problems should
>certainly dissappear in a couple of years.
What constitutes a "problem"?? Most of the complaints I've heard
internally about OSF/1 on the Alpha has to do less with robustness and
functionality than with details such as that the compiler is still not
generating the absolute fastest possible code for some cases, etc.
I believe that the first release of OSF/1 on the Alpha is going
to be Pretty Damn Good - a lot of the announcements from DEC and postings
from DEC folks here are being understated because, of course, it's not
going to be *perfect* right away.
We've had an Alpha here (locally) running a pre-release version
of OSF/1 for some time. It's stable and fast, even though the version
of the C compiler on it hardly does any optimization at all. That's an
example of the kind of "problem" that the first release (and subsequent
releases) will address - further polishing.
mjr.
Allen Akin
In article <921124133...@menora.weizmann.ac.il>, d...@menora.weizmann.ac.il writes:
> ...
> Our general feeling is that the worst choice is SGI with the MIPS
> 4000A chip. Clearly, judging on the very late release of the 4000A
> chip, MIPS has had problems with the development. Since the MIPS
> family is an old family, and because of these problems, it seems
> likely that there is not too much chance of ever seeing a MIPS 5000
> chip and a MIPS 6000 chip.
I think you should review the trade literature, and ask your SGI
representative for more information about future CPUs. This is
always a good policy when contemplating a major upgrade.
Incidentally, an R6000 already exists, though it's not a product
of evolution from the R4000.
Allen
David M. Senseman
>In article <1992Nov24.1...@decuac.dec.com>, m...@hussar.dco.dec.com (Marcus J. Ranum AXP) writes:
>> >On the other hand, the Alpha chip is a new architecture, ......
>>
>> What constitutes a "problem"?? Most of the complaints I've heard
>> internally about OSF/1 on the Alpha has to do less with robustness and
>> functionality than with details such as that the compiler is still not
>> generating the absolute fastest possible code for some cases, etc.
>
> designed around the architecture, a major new variant of an old operating
> system, and software subsystems built to operate under it. All this adds
> up to very understandable concern that this is not a family to bet one's
> company's well being on for at least a year or so. Just common sense, no ?
>
Keep in mind, DEC is in serious trouble. In the first fiscal quarter (ending
Sept 26), DEC lost $260.5 MILLION! I think you should buy DEC -- if you
don't, it may not be around much longer ;-)
--
David M. Senseman, Ph.D. | A man who has never gone to school may steal
(sens...@lonestar.utsa.edu) | from a freight car; but if he has a university
Division of Life Sciences | education, he may steal the whole railroad.
UT San Antonio | Theodore Roosevelt (1858-1919)
Thomas Sippel - Dau
- We are in the process of doing a major upgrade of our computer system
- in the department of Chemical Physics. We have three companies in
- consideration, HP, SGI, and DEC. (IBM still after a couple of weeks
- hasn't called back...) One of the major questions that has been
- raised is how stable our investment is in terms of the long time
- development of the major chip of the architecture we choose.
I fear your priorities are dead wrong. The most important part of
using computers is not the chip, not the company producing or selling
it, not the byte order, not the compilers, and not even the quality or
availability of other software, but the people who use the computers.
If they are unhappy with the computers they got from whoever pays for
the hardware, they will not get good results out of it. And you would not
believe the inventiveness of people when it comes to shifting the blame
onto the computer because "This machine just can't do it".
- Our general feeling is that the worst choice is SGI with the MIPS
- 4000A chip. Clearly, judging on the very late release of the 4000A
- chip, MIPS has had problems with the development. Since the MIPS
- family is an old family, and because of these problems, it seems
- likely that there is not too much chance of ever seeing a MIPS 5000
- chip and a MIPS 6000 chip.
If you are into buying futures, then even pork bellies would be a better
bet than computers. Evaluate the machines by all means, see if they do
NOW those things you consider important NOW, and identify whether they
could have a longer term use doing a basic job once the shine has faded.
Then base your decision not on what nice things you want, but on what
nasty things you want to avoid. Experience has shown that most of a
systems drawbacks stay with it for life, while the extra bonuses soon
get taken for granted.
Good things to avoid are high maintenance cost, aggressive engineering,
elaborate cooling requirements, expansion facilities, high discount schemes
for mass purchases ...
Good things to ignore when making a purchasing decision are those for
which you cannot sue for compliance, such as zero cycle branches, forward
looking architecture development, vendor commitment, industry leadership,
free lunches ...
Thomas
--
*** This is the operative statement, all previous statements are inoperative.
* email: cmaae47 @ ic.ac.uk (Thomas Sippel - Dau) (uk.ac.ic on Janet)
* voice: +44 71 589 5111 x4937 or 4934 (day), or +44 71 823 9497 (fax)
* snail: Imperial College of Science, Technology and Medicine
* The Center for Computing Services, Kensington SW7 2BX, Great Britain
Greg Pavlov
>
> What constitutes a "problem"?? Most of the complaints I've heard
> internally about OSF/1 on the Alpha has to do less with robustness and
> functionality than with details such as that the compiler is still not
> generating the absolute fastest possible code for some cases, etc.
Let's call it a "red flag" then. A new cpu architecture, new systems
designed around the architecture, a major new variant of an old operating
system, and software subsystems built to operate under it. All this adds
up to very understandable concern that this is not a family to bet one's
company's well being on for at least a year or so. Just common sense, no ?
greg pavlov
pav...@fstrf.org
Martin Rocek
Mhz version of the R4000 (I believe it is called a R4400) is out; it
gives about 90 SPECfp and 90 SPECint, which is pretty respectable. A
version of the R4000 optimized for mflops is not too far away; I think
that it beats an Alpha easily. SO I wouldn't count out SGI/MIPS.
Martin
Peter Shenkin
And some knowledgible people I've spoken to who recently attended the
MIPS nondisclosure seminar came away very impressed.
-P.
--
************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb************************
Peter S. Shenkin, Box 768 Havemeyer Hall, Dept. of Chemistry, Columbia Univ.,
New York, NY 10027; she...@still3.chem.columbia.edu; (212) 854-5143
*** In scenic New York: where the Third World is just a subway ride away ***
David M. Senseman
>In article <921124133...@menora.weizmann.ac.il>, d...@menora.weizmann.ac.il (Dov Grobgeld) writes:
>- We are in the process of doing a major upgrade of our computer system
>- in the department of Chemical Physics. We have three companies in
>- consideration, HP, SGI, and DEC. (IBM still after a couple of weeks
>- hasn't called back...) One of the major questions that has been
>- raised is how stable our investment is in terms of the long time
>- development of the major chip of the architecture we choose.
>
>I fear your priorities are dead wrong. The most important part of
I agree with everything Thomas Sippel said and only want to add one point.
More and more, high performance computing is graphical computing. This is
certainly true in Biology and I expect in Chemical Physics as well.
If you look at Dec, Sun, and IBM, their graphics strategy has been
pretty uninspired. As an old PDP-11 user, I have tremendous respect for
Ken Olsen -- but let's face it, if there ever was a "left-brained"
person, it was Ken. Dec never had a coherent graphics vision and as far I
can see, it still doesn't. Sun is just as bad -- witness the TACC-1,
the incompatible TACC-2, and the lastest in the line, the incompatible
Freedom 3000 (Evans&Sutherland add on board). And IBM? As someone
who still owns an IBM PC/RT, don't get me started...
I don't know much about HP except that I have been told that their
operating system isn't really UNIX. Maybe someone else might want to
comment?
sha...@adodem.enet.dec.com
In article <1992Nov25.2...@sol.ctr.columbia.edu>, she...@still3.chem.columbia.edu (Peter Shenkin) writes...
>In article <ROCEK.92N...@insti.physics.sunysb.edu> ro...@insti.physics.sunysb.edu (Martin Rocek) writes:
>>Just a comment from someone who has no particular inside knowledge: The 75
>>Mhz version of the R4000 (I believe it is called a R4400) is out; it
>>gives about 90 SPECfp and 90 SPECint, which is pretty respectable. A
>>version of the R4000 optimized for mflops is not too far away; I think
>>that it beats an Alpha easily. SO I wouldn't count out SGI/MIPS.
>
>And some knowledgible people I've spoken to who recently attended the
>MIPS nondisclosure seminar came away very impressed.
>
> -P.
When will these impressed, knowledgeable (according to spell(1)) people be able
to buy systems based on this non-disclosed information?
Before or after similarly impressed (one hopes :-) (knowledge state unknown)
people who have been to non-disclosures from Digital?
>--
>************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb************************
>Peter S. Shenkin, Box 768 Havemeyer Hall, Dept. of Chemistry, Columbia Univ.,
>New York, NY 10027; she...@still3.chem.columbia.edu; (212) 854-5143
>*** In scenic New York: where the Third World is just a subway ride away ***
Regards
Richard Sharpe
These opinions be mine, Digital has its own!
Fran Litterio
> I don't know much about HP except that I have been told that their
> operating system isn't really UNIX. Maybe someone else might want to
> comment?
HP-UX is real UNIX. HP-UX isn't BSD UNIX, but BSD is no longer a
standard in demand (it was only ever a pseudo-standard in the first
place). Even Sun knows this: the OS they're going to push for the
rest of the decade (Solaris) is System V Release 4.
From my experience if you're writing new code, you're smart to
implement in Standard C making only calls to the Standard C library,
the Posix.1 interface, and industry standard graphics interfaces.
That kind of code is maximally portable to HP-UX, Solaris, OSF/1, AIX,
DG/UX, and SVR4 (hell, it'll probably even work under Windows/NT if
that ever materializes).
--
fr...@centerline.com "So what we've decided to do is set you up in
uunet!centerline!franl Cicely, situated in an area that we Alaskans
(USA) 617-498-3255 refer to as The Alaskan Riviera."
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.0
mQCNAisQJSUAAAED/jbCQchSwFG7IFKkrCQ6QKLxB0LVbP6co87karNBb88ur1+S
FK82JT9mNlWKvP4HHFEI1kLKk0PAvd0nez/mQIriAMUT2pfOnIAtdqtpddgQseZZ
7BY2vMiorjG7pe6e11Q+UIQcvqsY3Bl89YBgqrydWm8UWMy2qXeXQmAScOodAAUR
tC9GcmFuY2lzIFAuIExpdHRlcmlvLCBKci4gPGZyYW5sQGNlbnRlcmxpbmUuY29t
Pg==
=6hNb
-----END PGP PUBLIC KEY BLOCK-----
Philip Machanick
ak...@tuolumne.asd.sgi.com writes:
>> Our general feeling is that the worst choice is SGI with the MIPS
>
>representative for more information about future CPUs. This is
>always a good policy when contemplating a major upgrade.
A few other questions to ask:
o which manufacturer has a good track record on implementing a broad
range of hardware from workstation to near-supercomputer?
o which one has a good track record on multiprocessor systems including
good programmer support and development tools?
o which manufacturer has a conservative approach to standard bechmarks
such as SPEC, rather than engineering benchmark engines that disappoint
on real problems?
On all three points I rate SGI highly. On the last, I have 2 interesting
examples. The R3000 Indigo according to SPECmarks should be about the
same speed as a SPARCstation 2. On real problems, in my experience, it is
about twice as fast as the SPARC machine. In a recent comparative
evaluation in which I gave a little help, an R4000 Indigo was only
about 1.3 times slower than a high-end IBM RS/6000 system on a floating
point-intensive problem, despite the fact that the IBM's SPEC float was
more like twice as good.
I am somewhat skeptical about how well DEC will implement MP Alpha
machines. I remember a case a few years back when a multiprocessor VAX
had to have a processor removed for maintenance and it was _faster_
without the extra processor! Of course things could have changed since
then...
--
Philip Machanick
Computer Science Dept, Univ of the Witwatersrand, 2050 Wits, South Africa
phi...@concave.cs.wits.ac.za phone: 27 (11) 716-3759 fax: 339-7965
Philip Machanick
she...@still3.chem.columbia.edu writes:
>And some knowledgible people I've spoken to who recently attended the
>MIPS nondisclosure seminar came away very impressed.
If anyone goes to a "MIPS _disclosure_ seminar" please report.
David Collier-Brown
|operating system isn't really UNIX. Maybe someone else might want to
|comment?
It's real, it's unix and it's **mighty** idiosyncratic! It's easy
to port code off HP-UX, but porting onto it was considered difficult.
The only machine I've considered harder to port to was the honeywell
dps-6, with its 32-bit integer pointers and 48-bit character pointers.
--dave (who used to work for honeywell,
but now just says ``no bull'') c-b
--
David Collier-Brown, | dav...@CCS.YorkU.CA | lethe!dave
72 Abitibi Ave., |
Willowdale, Ontario, | York Postmaster and
CANADA. 416-223-8968 | occasional sendfail(8) consultant.
richard g. adair
>I don't know much about HP except that I have been told that their
>operating system isn't really UNIX. Maybe someone else might want to
>comment?
HP makes great graphics equipment, but they don't know why. It's
kind'a an engineering exercise, like the moon shots. They all work
to a purpose, then say, "OK, now what?". HP desperately needs to
get someone who understands what graphics are FOR working in their
tech labs. Plus, a flight simulator would sell >$1M worth of
graphics tops, but staid HP doesn't do it! There are customers out
there who WANT to do graphics and NO engineering! Games which prove
capability aren't anathema to them...
Tony Burzio
Arete Associates
San Diego, CA
Mike Wilson
>sens...@ricky.brainlab.utsa.edu (David M. Senseman) writes:
>> I don't know much about HP except that I have been told that their
>> operating system isn't really UNIX. Maybe someone else might want to
>> comment?
>HP-UX is real UNIX. HP-UX isn't BSD UNIX, but BSD is no longer a
>standard in demand (it was only ever a pseudo-standard in the first
>place). Even Sun knows this: the OS they're going to push for the
>rest of the decade (Solaris) is System V Release 4.
ack! BSD is still in demand, it's just that so few are still producing
it. I don't care if that doesn't make sense, name 10 major decisions in the
computer world in the last couple of years that _have_ made sense!
HP-UX is indeed "real" unix, just not terribly stable unix (from what
I've seen...(brace for flames...)) I must say, it is getting better.
>From my experience if you're writing new code, you're smart to
>implement in Standard C making only calls to the Standard C library,
>the Posix.1 interface, and industry standard graphics interfaces.
>That kind of code is maximally portable to HP-UX, Solaris, OSF/1, AIX,
>DG/UX, and SVR4 (hell, it'll probably even work under Windows/NT if
>that ever materializes).
>--
>fr...@centerline.com "So what we've decided to do is set you up in
>uunet!centerline!franl Cicely, situated in an area that we Alaskans
>(USA) 617-498-3255 refer to as The Alaskan Riviera."
well, right on, but how relevant is it?
My 2bits on arch wars:
Dec Alpha: isn't in general availability yet...OSF/1 certainly is only in
advanced beta, whatever that means.
IBM RS/6000: Nice floating point performance. Expensive.
Sun: nobody beats them in their low end pricing. Excellent quality control
(best in business?) & technical support system.
4.1.3 works real good, Solaris doesn't. 40mhz sparcs might start volume
shipment within the next month, which puts it only 5 months late (from announce-
ment shipping goals).
SGI: incredible price/performance in midrange. Reasonable OS, & terrific
support from corp. Company hasn't grown big enough to forget that customers
are an asset, not a pain. nobody touches them on mid to high end graphics.
Also, they make the best workgroup servers in the industry. can you say
symmetric multiprocessing? Noone else can (uh, maybe sequent & solbourne).
HP: good on benchmarks & single issue workstations. mid-high price range.
current os is still immature. 7100 series arch is simply refinement of
older arch.
so, since money dictates, here are my favorites by $:
workstations:
$0 - $7k = Sun
$7k - $25k = SGI
$25k - $40k = HP/SGI
servers:
$0 - $30k = Sun
$30k - 75k = SGI
well, challenge me if you want me to support any of the above opinions.
-mike
ps: by posting header might be screwed, mail me at wils...@llnl.gov if
it is.
Mike Wilson
>so, since money dictates, here are my favorites by $:
>workstations:
>$0 - $7k = Sun
>$7k - $25k = SGI
>$25k - $40k = HP/SGI
>servers:
>$0 - $30k = Sun
>$30k - 75k = SGI
Ok, forgot 1 important thing. Above pricing reflects std educational pricing
from the various makers.
>ps: by posting header might be screwed, mail me at wils...@llnl.gov if
>it is.
it is screwed (sigh)...time to recompile.
-mike
ze...@vxcrna.cern.ch
> sens...@ricky.brainlab.utsa.edu (David M. Senseman) writes:
>
>> I don't know much about HP except that I have been told that their
>> operating system isn't really UNIX. Maybe someone else might want to
>> comment?
>
> HP-UX is real UNIX. HP-UX isn't BSD UNIX, but BSD is no longer a
> standard in demand (it was only ever a pseudo-standard in the first
> place). Even Sun knows this: the OS they're going to push for the
> rest of the decade (Solaris) is System V Release 4.
I don't reagard it a "real" UNIX, then again I wouldn't buy a "real" UNIX,
1970s software technology is not something I would want to buy today.
Getting caught up in the "pure" UNIX war will lead you to restrict yourself to
"pure" SVR4 implementations, in the mainstream camp *only* SUN have gone for
this. That in my view does not make it much of a "standard".
If a vendor decides to do something about the crass inadequacies of UNIX we
should give them three cheers, not start a flame war about how the DIRECTORY
command *must* forever and ever be called ls because that is what the great tin
pot Gods who wrote UNIX thought was a nice, clear name for it.
The most threatening thing I see in computing today is the "we have found the
answer, all heretics will perish" attitude. I have an awful lot of experience
in computing, I have used six or seven operating systems and I have even
written one. UNIX in my view is an abomination, it has serious difficulties,
these could have been fixed quite easily, but I now realize nobody ever will.
At the moment I use a VMS box, I do so because I find that I do not spend my
time having to think in the "UNIX" mentality that centers around kludges. I do
not have to tolerate a help system that begins its insults of the user by being
invoked with "man".
Apollo in my view were the only UNIX vendor to realize that they had to put
work into the basic operating system. They had ACLs, shared libraries and many
other essential features five years ago.
What I find disgusting about UNIX is that it has *never* grown any operating
system extensions of its own, all the creative work is derrived from VMS,
Multics and the operating systems it killed.
> From my experience if you're writing new code, you're smart to
> implement in Standard C making only calls to the Standard C library,
> the Posix.1 interface, and industry standard graphics interfaces.
> That kind of code is maximally portable to HP-UX, Solaris, OSF/1, AIX,
> DG/UX, and SVR4 (hell, it'll probably even work under Windows/NT if
> that ever materializes).
If you do that properly it *will* work under windows NT, and under VMS too.
That is what POSIX is all about. From now on UNIX will no longer be able to
exist as a lowest common denominator system, the pressure will be to implement
the higher POSIX levels such as threads.
In the long term basing your choice of hardware on the operating system will no
longer be neccessary, for VMS to survive against Windows NT, it will have to be
ported to other platforms. For SUN to continue to sell hardware they will have
to support Windows NT as will HP.
Phill Hallam-Baker
ze...@vxcrna.cern.ch
> In article <1992Nov25.2...@sol.ctr.columbia.edu>, she...@still3.chem.columbia.edu (Peter Shenkin) writes...
>>In article <ROCEK.92N...@insti.physics.sunysb.edu> ro...@insti.physics.sunysb.edu (Martin Rocek) writes:
>>>Just a comment from someone who has no particular inside knowledge: The 75
>>>Mhz version of the R4000 (I believe it is called a R4400) is out; it
>>>gives about 90 SPECfp and 90 SPECint, which is pretty respectable. A
>>>version of the R4000 optimized for mflops is not too far away; I think
>>>that it beats an Alpha easily. SO I wouldn't count out SGI/MIPS.
>>
>>And some knowledgible people I've spoken to who recently attended the
>>MIPS nondisclosure seminar came away very impressed.
>>
>> -P.
>
> When will these impressed, knowledgeable (according to spell(1)) people be able
> to buy systems based on this non-disclosed information?
>
> Before or after similarly impressed (one hopes :-) (knowledge state unknown)
> people who have been to non-disclosures from Digital?
I went to some damn impressive non-disclosure meetings, hell the chip was
amazing, did everything we need, ten times faster than the current product.
They were for the inmos T9000, ever seen one?
Point is, don't beleive the non-disclosure untill you have seen the iron. I
have seen an alpha and used it, it worked, was very nice. I have used gear for
quite some time that uses the same process. I am as confident as anyone could
be that they will in fact make it to market with the beast in reasonable time.
Projections of the future of the Mips chip are rather clouded by the initial
R4000 release, the concensus here is that to be keeping up with the game MIPs
should have put a bit more beef into it. Doubtless, a new and improved MIPs
chip will appear, but why non disclosure?
The only non-disclosure stuff I ever have any interest in is architecture,
providing backwards compatibility costs, you can see the effect in the tail end
of the VAX line. When someone breaks the backwards compatibility (at least at
the binary level) they can get a boost.
If Mips are going to break binary compatability then I would be interested to
hear in advance that they were planning it, the market they intended to
exploit, the reasoning behind their methodology etc. This would allow me to go
back and plan new systems.
I can't see any point in going to be told that SGI hope to bring out a faster
machine, except as an ego boost (gosh they let little *me* into a
*non-disclosure* meeting, how important I must be) or to stock up on ethanol
and cheesy snacklettes.
If you want to predict what a company is going to do:-
1) Read their balance sheet,
Forget profit and loss, that is irrelevant. what matters is cash flow,
assets etc. DEC are shedding staff in a reorganization, companies will always
report bad figures in that situation. The basic business is sound, DEC could
always just become a MIPS or SPARC chip pusher, they have no idealogical
hangups about their market that would prevent them from doing what is
necessary.
2) Look at their major market,
Don't flatter yourself that your needs represent the mainstream market.
Unless you are doing very boring computing indeed, you are in a specialist
market, some companies specialize in niche markets, others go for broader
markets. If you have a company oriented arround commercial work they are going
to be after COBOL, databases, IBM-PC emulation and the like. Real time control
provides another set of constraints, as does computer aided design.
DEC are making a loss but have huge cash flow and huge reserves. Plus a goodly
number of banks are criticaly dependent on them. They simply cannot afford for
DEC to go under because they would follow. This is known as the "IBM effect".
SGI have a niche market in graphics but have mushroomed into a very large
corporation within the last three years. Their main problem is that their niche
market is volatile, it swings widely as the market changes.
HP have the fastset box you can actually buy off the shelf today. This may
change tommorow, but HP are likely to stay in the front rank for a while.
SUN have gone into "we know better than you do what you want" mode. This was
fine for DEC and IBM, but these companies now realize they can't survive with
that mindset. SUN may report profits, but on what basis? How fast are they
writting off the capital value of the SPARC design? How much are they valuing
"goodwill" and "non-tangeable assets" at? Sun are failing to keep up, unless
they can get back in the race soon they will go under. The PC market is
producing machines that push into SPARC performance territory, but to buy a PC
is simple, just pick up the phone, dial a number and give your credit card
number. Try buying a SUN like that. Look in the current issue of byte, not a
single SUN dealer giving prices on the page for product. Remember that
technical competition is not the only kind, ease of purchase and use also
count.
CRAY may make a (re)entry into the big boys league. They have had a practice
run and may take the high end of the w/s market with multiprocessor MIMD boxes.
--
Phill Hallam-Baker
Peter da Silva
> written one. UNIX in my view is an abomination, it has serious difficulties,
> these could have been fixed quite easily, but I now realize nobody ever will.
The problem with UNIX is that in 1972 a couple of folks looked at the world
as it then existed, and realised that by making a few simplifying assumptions
that limited the system to the timeshared model, they could develop a very
simple high-level programming model that covered basically the entire set of
applications they were interested in.
This has the advantage that as long as you were interested in that basic
environment, you could run a wide variety of alien operating systems and
present the same interface to the programmer.
Where does the "problem" bit come in? The problem is that to get past the
timeshared environment, you have to either:
1. Make the basic model a little more complex, or
2. Add a few new interfaces to deal with new environments,
and make them more or less well-integrated to the basic
model, or
3. Implement it on top of a more complex model, with an escape
mechanism.
Most people have done 2 or 3. System V IPC, Berkeley sockets, and a lot of
the stuff under ioctl() are examples of 2. Mach, Amoeba, and other UNIX
clones are examples of 3. The problem is, with a few changes in the interface
you can provide a model that works well for real-time and distributed
environments. The Plan 9 model covers the distributed world pretty well,
but does little for real-time. For real-time, you need to jack up the system
call interface and provide a general asynchronous interface to it.
The result would look kind of like sockets code, but it'd be more general:
Let's introduce an opaque object like a file descriptor called an TOKEN.
A TOKEN represents a system call in progress, a TOKSET represents a group
of tokens to be tested for completion or waited on.
ttymon()
{
TOKSET ttyset;
TOKSET waitset;
TOKEN ttys[NTTY];
TOKEN gettys[NTTY];
TOKEN tty;
int i;
ttyset = new_tokset();
for(i = 0; i < NTTY; i++) {
if(ttys[i] = async_open(ttyname(i), O_RDWR))
add_token(ttyset, ttys[i]);
else
alert(DEADTTY, i);
gettys[i] = 0;
}
while(waitset = async_wait(tokset)) {
for(i = 0; i < NTTY; i++) {
if(ttys[i] && token_in(ttys[i], waitset)) {
remove_token(ttyset, ttys[i]);
if(gettys[i] = spawn_getty(i, result(ttys[i])))
add_token(ttyset, gettys[i]);
else
alert(DEADGETTY, i);
ttys[i] = 0;
}
if(gettys[i] && token_in(gettys[i], waitset)) {
remove_token(ttyset, gettys[i]);
log_result(i, result(gettys[i]));
if(ttys[i] = async_open(ttyname(i), O_RDWR))
add_token(ttyset, ttys[i]);
else
alert(DEADTTY, i);
gettys[i] = 0;
}
}
}
}
> At the moment I use a VMS box, I do so because I find that I do not spend my
> time having to think in the "UNIX" mentality that centers around kludges. I do
> not have to tolerate a help system that begins its insults of the user by
> being invoked with "man".
That's because it's not a help system. It's an online manual. If you want a
help system, I'm afraid that nobody's written one for UNIX. If there's a
demand for it, you can be sure that you'll get plenty of buyers when you
write one and sell it at a reasonable price.
> Apollo in my view were the only UNIX vendor
Apollo were another group 3 vendor, alas.
> What I find disgusting about UNIX is that it has *never* grown any operating
> system extensions of its own, all the creative work is derrived from VMS,
> Multics and the operating systems it killed.
That's because UNIX is all about simplifying the working model. Not extending
it. POSIX *is* UNIX, and if you implement POSIX you have implemented a UNIX
system, for all practical purposes. It's just got some fancy terminology tacked
on so DEC and others can save face. Because, for all its warts, UNIX is still
a *GOOD* common denominator for a wide variety of application domains.
Certainly it's a much better API than VMS or WNT provide.
--
%Peter da Silva/77487-5012 USA/+1 713 274 5180/Have you hugged your wolf today?
/D{def}def/I{72 mul}D/L{lineto}D/C{curveto}D/F{0 562 moveto 180 576 324 648 396
736 C 432 736 L 482 670 518 634 612 612 C}D/G{setgray}D .75 G F 612 792 L 0 792
L fill 1 G 324 720 24 0 360 arc fill 0 G 3 setlinewidth F stroke showpage % 100
Peter Mayne
> POSIX *is* UNIX, and if you implement POSIX you have implemented a UNIX
>system, for all practical purposes. It's just got some fancy terminology tacked
>on so DEC and others can save face. Because, for all its warts, UNIX is still
>a *GOOD* common denominator for a wide variety of application domains.
>
So running POSIX on OpenVMS means I've really got UNIX? Great!
>Certainly it's a much better API than VMS or WNT provide.
What standard of reference are you using?
>--
>%Peter da Silva/77487-5012 USA/+1 713 274 5180/Have you hugged your wolf today?
PJDM
--
Peter Mayne | My statements, not Digital's.
Digital Equipment Corporation |
Canberra, ACT, Australia | "AXP!": Bill the Cat
Philip Machanick
writes:
>If you want to predict what a company is going to do:-
>
>1) Read their balance sheet,
> Forget profit and loss, that is irrelevant. what matters is cash flow,
>assets etc. DEC are shedding staff in a reorganization, companies will
always
>report bad figures in that situation. The basic business is sound, DEC
could
>always just become a MIPS or SPARC chip pusher, they have no idealogical
>hangups about their market that would prevent them from doing what is
>necessary.
Then why aren't they hedging their bets by producing an R4000 box? Or have
I missed something?
>2) Look at their major market,
> Don't flatter yourself that your needs represent the mainstream market.
>Unless you are doing very boring computing indeed, you are in a
specialist
>market, some companies specialize in niche markets, others go for broader
>markets. If you have a company oriented arround commercial work they are
going
>to be after COBOL, databases, IBM-PC emulation and the like. Real time
control
>provides another set of constraints, as does computer aided design.
>
>
>DEC are making a loss but have huge cash flow and huge reserves. Plus a
goodly
>number of banks are criticaly dependent on them. They simply cannot
afford for
>DEC to go under because they would follow. This is known as the "IBM
effect".
Well I don't give much for IBM's chances either. They have split into 14
companies perhaps in the hope that some parts can be salvaged.
>SGI have a niche market in graphics but have mushroomed into a very large
>corporation within the last three years. Their main problem is that
their niche
>market is volatile, it swings widely as the market changes.
SGI's strength is covering a wide range of markets. Graphics is important
because the performance issues it presents eventually float up in more
maintream computing (memory bandwidth, floating point performance). If
they could drop to the sub-$5000 market, they'd cover everything from
high-end PCs to the lower end of super computers. Another critical
strength is in multiprocessor systems, an area where most competition
is still finding its feet.
Damon
>sens...@ricky.brainlab.utsa.edu (David M. Senseman) writes:
>|I don't know much about HP except that I have been told that their
>|operating system isn't really UNIX. Maybe someone else might want to
>|comment?
>
> It's real, it's unix and it's **mighty** idiosyncratic! It's easy
>to port code off HP-UX, but porting onto it was considered difficult.
> The only machine I've considered harder to port to was the honeywell
>dps-6, with its 32-bit integer pointers and 48-bit character pointers.
For a benchmark on the Snake series for Parallelogram I did a quick
port of some Sun C code in about 30 minutes. A couple of library calls
missing on the HP, but, what the heck---I knew my code and wrote them
out within 30 mins. This was many months and at least one major OS
version ago.
Damon
--
Damon Hart-Davis Internet: d...@exnet.co.uk, d...@hd.org
Public-access UNIX (Suns), news and mail for UK#5 per month. FIRST MONTH FREE.
[1.35] Cheap Sun eqpt. UUCP news/mail feeds. Tel/Fax: +44 81 755 0077.
richard g. adair
>Dec Alpha: isn't in general availability yet...OSF/1 certainly is only in
>advanced beta, whatever that means.
From which division are the 6000 people being laid off from?
>4.1.3 works real good, Solaris doesn't. 40mhz sparcs might start volume
>shipment within the next month which puts it only 5 months late (from announce-
>ment shipping goals).
That's ok, I waited for the HP 68040 processor a similar
period :-)
>SGI: incredible price/performance in midrange. Reasonable OS, & terrific
>support from corp. Company hasn't grown big enough to forget that customers
>are an asset, not a pain. nobody touches them on mid to high end graphics.
SGI has more effective use of 3D graphics because it's easier to use.
For example, you can create an object in a window with many less
calls than with an HP. In addition, once drawn the window can be
transformed at will with the mouse. On the HP, it's all up to the
programmer to handle the many and often complicated 3D calls. HP
has faster graphics, but they'll never win over SGI.
Even though a 730 will toast an 8 processor SGI!
Dileep Bhandarkar
In article <ROCEK.92N...@insti.physics.sunysb.edu>, ro...@insti.physics.sunysb.edu (Martin Rocek) writes...
>Just a comment from someone who has no particular inside knowledge: The 75
>Mhz version of the R4000 (I believe it is called a R4400) is out; it
>gives about 90 SPECfp and 90 SPECint, which is pretty respectable. A
These must be SPEC92 numbers. Are these numbers published by SGI or MIPS?
Are they estimates, simulated, or measured?
The only numbers I have seen are 95 SPECint89, 126 SPECfp89, 113 SPECmark89
all based on simulations by MIPS.
/d
Steve McIntosh
wil...@moonshine.cs.athabascau.ca (Mike Wilson ) writes:
|> Dec Alpha: isn't in general availability yet...OSF/1 certainly is only in
|> advanced beta, whatever that means.
For the record...
General availability for Alpha systems (DEC 3000 Model 400, etc.) is here.
They began shipping last week with VMS.
I don't know what "advanced beta" means either but, while general availability
of DEC OSF/1 V1.2 (Alpha) is scheduled for March, several hundred Alpha OSF/1
systems have now begun shipping to software developers under an early release
program. Also, Version 1.0 of DEC OSF/1 was released last March.
OPEN SYSTEMS
TODAY reviewed it in their May 11 issue and praised it's stability and
speed, even
though V1.0 was only a developer's release for some DECStations. (They
later
compared its performance with Solaris 1.0 and 2.0 on the same speed
processors
and it proved much faster than either the BSD or SVR4 versions of
Solaris on the
majority of the benchmarks (Sept 21 issue, pg. 73.). And, V1.2 has
performance
improvements over V1.0.
Steve
Unix Product Marketing ---> you may have guessed this ;-)
mcin...@decvax.dec.com
SGI_Junkie
>> The 75 Mhz version of the R4000 (I believe it is called a R4400) is out; it
>> gives about 90 SPECfp and 90 SPECint, which is pretty respectable. A
>
>The only numbers I have seen are 95 SPECint89, 126 SPECfp89, 113 SPECmark89
>all based on simulations by MIPS.
>
Just to clear it up, the R4400 is a complete new chip which runs
at either 50, 67, or 75Mhz, The above ratings are for the 75Mhz
versions. The R4400 is more than just a 75Mhz version of the R4000.
It features 32K of on chip primary cache and can control up to
4 MB of secondary cache, it also has a write buffer which allows
the CPU to overlap execution of instructions with writes to the
screen.
--
______ _ _
_/ ____) _( )_ _( )_ Scott Klosterman
_ (____ ____ ___ (__ __) (__ __) sc...@sgisupport.lerc.nasa.gov
\____ \_/ __) / \ ( ) ___( ) _
____) _ (__ ( O ) ( \_/ ___ \_/ )
(______/ \____) \___/ \___/ \___/
Russ Jones
>
> I agree with everything Thomas Sippel said and only want to add one point.
> More and more, high performance computing is graphical computing. This is
> certainly true in Biology and I expect in Chemical Physics as well.
>
> If you look at Dec, Sun, and IBM, their graphics strategy has been
> pretty uninspired. As an old PDP-11 user, I have tremendous respect for
> Ken Olsen -- but let's face it, if there ever was a "left-brained"
> person, it was Ken. Dec never had a coherent graphics vision and as far I
> can see, it still doesn't. Sun is just as bad -- witness the TACC-1,
> the incompatible TACC-2, and the lastest in the line, the incompatible
> Freedom 3000 (Evans&Sutherland add on board). And IBM? As someone
> who still owns an IBM PC/RT, don't get me started...
>
> David M. Senseman, Ph.D. | A man who has never gone to school may steal
> (sens...@lonestar.utsa.edu) | from a freight car; but if he has a university
> Division of Life Sciences | education, he may steal the whole railroad.
> UT San Antonio | Theodore Roosevelt (1858-1919)
David,
Check out the Sept'92 issue of Computer Graphics World. The "Output" column contains a good, concise overview of Digital's graphics strategy. The net of it is consistent 2D APS's (X, GKS, Display Postscript) and 3D API's (GKS-3D, PHIGS, PEXlib, OpenGL) across both Unix and VMS.
--
Russ Jones
UNIX Marketing
Digital Equipment Corporation, Palo Alto, CA
All opinions expressed are mine, and not necessarily those of my employer
Doctor Math
>SGI's strength is covering a wide range of markets. Graphics is important
>because the performance issues it presents eventually float up in more
>maintream computing (memory bandwidth, floating point performance). If
>they could drop to the sub-$5000 market, they'd cover everything from
>high-end PCs to the lower end of super computers.
I don't think it's a question of whether they COULD ship a $5000 machine,
and it's certainly not a question of whether anyone would buy one.. the
thing I wonder about is whether they can do it SOON ENOUGH. Sun has already
entered the sub-$5000 market, which makes it a safe bet that other vendors
will follow... SGI still has other strengths over them (3D graphics being
their strongest), but what happens when someone buys a bunch of Suns
because SGI can't compete with Sun on price? Isn't that a bunch of sales
that SGI didn't make? (This comparison is only valid assuming that the
machines are for "general" use; obviously a Sun won't run Insight.)
It runs deeper than that with me, though; I have found SGI to have the
most bizarre pricing "strategy" I've ever seen. Example: For a little
more than the price of a 4D/20 -> 4D/35 upgrade, I can buy an Indigo and
use the 4D/20 as a rather large doorstop with 3D rendering capability.
Then I can put another 16MB of RAM in the Indigo with what I saved by
not paying the FSE to install the 4D/35 upgrade. For what it would cost
to upgrade all the 4D/20 and 4D/25 machines we have here, we could buy
a Crimson and use the old machines as a stand for the Crimson; that way
I could stub my toes on old technology when I come in to work at night.
When the machines are no longer supported by SGI, I will be able to trade
them in against the price of new machines. This is happening now with
certain old SGI machines (3030 if I'm not mistaken). Only 4 years away...
Disclaimer: Bitter sarcasm from a slightly embittered sysadmin.
Jussi Eloranta
>later
>compared its performance with Solaris 1.0 and 2.0 on the same speed
>processors
>and it proved much faster than either the BSD or SVR4 versions of
>Solaris on the
>majority of the benchmarks (Sept 21 issue, pg. 73.). And, V1.2 has
>performance
>improvements over V1.0.
If this is the same comparison (that dec made) posted earlier to ths solaris
group then I can tell it was just *slightly* biased. The machines benchmarked
were not equal on cpu power.
jussi
--
============================================================================
Jussi Eloranta Internet(/Bitnet): ! The ultimate trip is
University of Jyvaskyla, Jussi.E...@jyu.fi ! death.
Finland [130.234.0.1] ! -- Jim Morrison
william E Davidsen
| My 2bits on arch wars:
And I won't repeast it all here. As far as I can see, with one
exception "part is parts" and the o/s is a bigger selling point (or
drawback) than the vendor. I admin BSF, Ultrix, SunOS, V.4/386, Xenix,
SCO UNIX, V.3.2, Ultrix (MIPS and VAX), HP/UX and a little AIX, and the
biggest problem I have with some of them is the stuff the vendors put in
software.
I'd love V.4 instead of HP/UX, but that's my opinion.
--
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
Keyboard controller has been disabled, press F1 to continue.
richard g. adair
>of DEC OSF/1 V1.2 (Alpha) is scheduled for March, several hundred Alpha OSF/1
>systems have now begun shipping to software developers under an early release
HP did an early release of OSF/1 once too, and it sucked soooo bad
it was pulled immediately. Apparently OSF/1 has some real problems,
probably down in the kernel where it was too hard to fix...
>OPEN SYSTEMS
>TODAY reviewed it in their May 11 issue and praised it's stability and
>speed, even
>though V1.0 was only a developer's release for some DECStations. (They
>later
Oh great, that's the rag that includes VMS as an "open system?"
UNIX is bad enough, even decades into development. What about the
compilers? Even SGI, a stable and venerable company, had a MAJOR
bug in it's FORTRAN compiler that we found which messed up do loops
on some occasions (it's been fixed). How could DEC find all the
defects before releasing product, with all the pressure from
management to make up for their bungling? Naw, OSF/1 isn't ready yet...
>Steve
>Unix Product Marketing ---> you may have guessed this ;-)
Will OSF/1 be available on the DECstations?
Rob Healey
|> >and it proved much faster than either the BSD or SVR4 versions of
|> >Solaris on the
|>
|> group then I can tell it was just *slightly* biased. The machines benchmarked
|> were not equal on cpu power.
|>
of iron and software packages? i.e. A machine I can use to solve
my problems today with the software I want is MUCH more
valuable than a promise of something being available RSN.
-Rob
-Rob
Rob Healey
|> General availability for Alpha systems (DEC 3000 Model 400, etc.) is here.
|> They began shipping last week with VMS.
|>
|> I don't know what "advanced beta" means either but, while general availability
|> of DEC OSF/1 V1.2 (Alpha) is scheduled for March, several hundred Alpha OSF/1
|> systems have now begun shipping to software developers under an early release
|> program. Also, Version 1.0 of DEC OSF/1 was released last March.
|> OPEN SYSTEMS
|> TODAY reviewed it in their May 11 issue and praised it's stability and
|> speed, even
|> though V1.0 was only a developer's release for some DECStations. (They
I.e. job blow user can't buy it where as they can by Solaris
1.1, 2.0 and now 2.1. They can also get HP-UX 8.x and 9.x(?).
Again, vapor city UNIX wise.
|> later
|> compared its performance with Solaris 1.0 and 2.0 on the same speed
|> processors
|> and it proved much faster than either the BSD or SVR4 versions of
|> Solaris on the
|> majority of the benchmarks (Sept 21 issue, pg. 73.). And, V1.2 has
|> performance
|> improvements over V1.0.
|>
Ya, but people couldn't BUY IT. i.e. vaporware.
Now that both are out maybe lucky new owners can post OSF/1
and Solaris 2.1 numbers? Both have performance improvements
and I assume the new OSF/1 can be purchased by Joe User along
with any end user apps (s)he may need?
-Rob
M Darrin Chaney
Rob Flamebait just needed it too badly.
rhe...@dellr4.digibd.com (Rob Healey) writes:
> Solaris dumped the built in compiler
Good thing, too. It was just too easy to ftp a C source and compile it
on your workstation. Now you have to find a C compiler too. How are
you going to build gcc?
> and cleaned up the VERY messy
> BSD administration, or I should say standard lack thereof. How is
> this "we know better than you do what you want".
Let's start with OpenLook...
>I'd say it's
> the exact opposite, they are no longer foisting their C compiler
> on you.
Yeah, I've always noticed those Sun users: "Damn, I wish Sun didn't include
this C compiler with the system. I can't delete it, and, since it's here, I
can't get another one..."
>You are now free to choose just like PC users everywhere.
Guess what, genious, I'M FREE TO CHOOSE A C COMPILER ON MY DECSTATION! I
know it's hard to believe, since it comes with a C compiler. But, guess what,
even though it has a C compiler, it is possible to install another one. And,
it's not just me. I've heard from other people who have done the same thing.
Unbelievable, isn't it?
> I suppose you prefer IBM, DEC and HP to dictate to you what compiler
> you can and cannot use?
You don't get it, do you? They include a compiler with the system, although
it's not the best. But, it works, and I can compile most net software with
it.
But, I can also get gcc if I want, and I've even seen commercial third-party
compilers out there. The point is, neither IBM, nor DEC, nor HP "dictates"
what compiler I have to use with their system. They simply include one that
I can use, but that doesn't stop me from using another.
I'll act like you can answer this, Rob: Why is it you think that these machines
have been rendered incapable of using multiple C compilers by the
manufacturer?
> I can get current rev. of popular PC
> software for SPARC, IBM, DEC and HP lag in versions compared to
> the PC version of the software.
Is the comma after SPARC supposed to be a period, or are you trying to win
some kind of run on sentence award?
>Seems to me for a long time SPARC
> has gotten new versions of PC software for others. DEC and HP have
> ported THEIR packages to SPARC, Sun hasn't seen the financial
> need to do so.
What packages might you be talking about? Borland C?
> Alot of techy types are pissed off at Sun for dumping their pet
> BSD tastes for System V Release 4.
No, it's just us silly purists who don't like proprietary systems.
After reading your other two postings of anti-(DEC,IBM,HP) tripe, I really
have to wonder what your deal is. This post was, at best, silly and
inaccurate. I haven't seen postings from you before. You wouldn't happen
to be some high-schooler who just discovered the Internet, would you?
Just wondering...
Darrin
--
mdchaney@iubacs mdch...@bronze.ucs.indiana.edu mdch...@rose.ucs.indiana.edu
"I want- I need- to live, to see it all..."
peter da silva
> In article <id.4I...@ferranti.com>, pe...@ferranti.com (Peter da Silva) writes:
> > POSIX *is* UNIX, and if you implement POSIX you have implemented a UNIX
> >system, for all practical purposes. It's just got some fancy terminology tacked
> >on so DEC and others can save face. Because, for all its warts, UNIX is still
> >a *GOOD* common denominator for a wide variety of application domains.
> So running POSIX on OpenVMS means I've really got UNIX? Great!
If it's complete enough for your porpoises it's effectively UNIX. I haven't
looked at it, so I don't know if I'd classify it as a high quality UNIX, but
yes...
Just because something's effectively UNIX doesn't mean it's a high quality
implementation. You can run Minix 1.x on a vanilla IBM/PC with two floppies,
but I wouldn't want to try to use Emacs on it.
> >Certainly it's a much better API than VMS or WNT provide.
> What standard of reference are you using?
Complexity (bad) uniformity (good) information hiding (good) ... all the same
criteria I use to evaluate a programming language or application.
--
%Peter da Silva/77487-5012 USA/+1 713 274 5180/Have you hugged your wolf today?
david carlton
> In article <1992Nov30.1...@e2big.mko.dec.com>, mcin...@unix.enet.dec.com (Steve McIntosh) writes:
>> Also, Version 1.0 of DEC OSF/1 was released last March. OPEN
>> SYSTEMS TODAY reviewed it in their May 11 issue and praised it's
>> stability and speed, even though V1.0 was only a developer's
>> release for some DECStations.
> I.e. job blow user can't buy it where as they can by Solaris
> 1.1, 2.0 and now 2.1.
Actually, Joe Blow user can buy it and has been able to for several
months. The "developer's release" title refers more to its lack of
tuning and of final testing than to its availability.
david carlton
car...@husc.harvard.edu
I want you to MEMORIZE the collected poems of EDNA ST VINCENT
MILLAY.. BACKWARDS!!
Dave Olson
| It runs deeper than that with me, though; I have found SGI to have the
| most bizarre pricing "strategy" I've ever seen. Example: For a little
| more than the price of a 4D/20 -> 4D/35 upgrade, I can buy an Indigo and
| use the 4D/20 as a rather large doorstop with 3D rendering capability.
| Then I can put another 16MB of RAM in the Indigo with what I saved by
| not paying the FSE to install the 4D/35 upgrade. For what it would cost
| to upgrade all the 4D/20 and 4D/25 machines we have here, we could buy
| a Crimson and use the old machines as a stand for the Crimson; that way
| I could stub my toes on old technology when I come in to work at night.
| When the machines are no longer supported by SGI, I will be able to trade
| them in against the price of new machines. This is happening now with
| certain old SGI machines (3030 if I'm not mistaken). Only 4 years away...
Not too surprising. The 30 and 35 were done *after* the idea of Indigo
was well along, mainly as an upgrade path for 20 and 25 customers who
required the VME slot, or had other reasons for preferring the upgrade
path. Originally it wasn't as horrible a mechanical upgrade, but it
pushed past what the 20/25 chassis was designed for, and so the chassis
had to be modified to meet EMI and thermal requirements (which also
raised the cost) The 30 and 35 did ship sooner than Indigo, but I'm
pretty sure it was after Indigo was officially announced.
--
Let no one tell me that silence gives consent, | Dave Olson
because whoever is silent dissents. | Silicon Graphics, Inc.
Maria Isabel Barreno | ol...@sgi.com
Greg Pavlov
> In article <921124133...@menora.weizmann.ac.il>, d...@menora.weizmann.ac.il (Dov Grobgeld) writes:
> - We are in the process of doing a major upgrade of our computer system
> - .... We have three companies in consideration, HP, SGI, and DEC. ...
> - One of the major questions that has been
> - raised is how stable our investment is in terms of the long time
> - development of the major chip of the architecture we choose.
>
> I fear your priorities are dead wrong. ...
As someone who rather recently invested quite a bit of my company's money
in DEC's MIPS-based systems, I find the above question to be very relevant.
Too late and after the fact, unfortunately....
greg pavlov
pav...@fstrf.org
Dave Bernard
>OPEN SYSTEMS
>TODAY reviewed it... (They later
>compared its performance with Solaris 1.0 and 2.0 on the same speed processors
>and it proved much faster than either the BSD or SVR4 versions of Solaris on the
>majority of the benchmarks (Sept 21 issue, pg. 73.). And, V1.2 has
>performance improvements over V1.0.
>Steve
>Unix Product Marketing ---> you may have guessed this ;-)
>mcin...@decvax.dec.com
Steve, how ya doin'? :-)
For the record, Solaris 2.1 will be shipping next week, with performance improvements;
Solaris 2.2 will also be shipping in 4/93, again with further enhancements.
Dave Bernard, Sun Microsystems
Dave Bernard
In article <ByLI2...@digiboard.digibd.com>, rhe...@dellr4.digibd.com (Rob Healey) writes:
> Solaris dumped the built in compiler and cleaned up the VERY messy
> BSD administration, or I should say standard lack thereof. How is
> this "we know better than you do what you want". I'd say it's the
> exact opposite, they are no longer foisting their C compiler on you.
> You are now free to choose just like PC users everywhere.
To carry it a step further, Sun has realized that a good majority of its
customers simply use canned software on their systems, and never do a compile...
(Solaris 2.X no longer requires recompiling the kernel each time a new device
is added, and even earlier SunOS versions supported loadable modules). Thus,
the absence of an uneeded compiler allowed a reduction of cost. Also, Sun's
compiler group is now in a different "satellite" company, with its own profit
center...
Dave Bernard, Sun Microsystems
Jussi Eloranta
Yes, but if you are to benchmark operating systems then the machines must
have equal cpu & I/O power.
Michael A. Thomas
>
> To carry it a step further, Sun has realized that a good majority of its
> customers simply use canned software on their systems, and never do a compile...
> (Solaris 2.X no longer requires recompiling the kernel each time a new device
> is added, and even earlier SunOS versions supported loadable modules). Thus,
> the absence of an uneeded compiler allowed a reduction of cost.
Um, exactly what might that cost be? The extra $1 worth of tape to put
the compiler on the distribution tape? Sorry if I less that impressed with
this amazing cost reduction. But oh, you say, it's the cost of keeping
the compiler group gainfully employed? Well, consider this: don't write
compilers at all and see how long you keep selling hardware. There are
costs of doing business, and when vendors realize that software is just
as integral as putting a case around their iron the better.
> Also, Sun's
> compiler group is now in a different "satellite" company, with its own profit
> center...
Of course this is the real answer. May I suggest that Sun carefully
review the myriad of DEC's mistakes in the last decade and take heed
of them? Sun IMHO, is making the *exact* same mistakes of "knowing what's
good for the customer" customer be damned that DEC made over the last
decade; mistakes which have cost DEC dearly.
Does the phrase "nickling and diming you to death" ring a bell?
--
Michael Thomas (mi...@gordian.com)
"I don't think Bambi Eyes will get you that flame thrower..."
-- Hobbes to Calvin
USnail: 20361 Irvine Ave Santa Ana Heights, Ca, 92707-5637
PaBell: (714) 850-0205 (714) 850-0533 (fax)
Phill Hallam-Baker
(M Darrin Chaney) writes:
|>rhe...@dellr4.digibd.com (Rob Healey) writes:
|>> Solaris dumped the built in compiler
|>
|>Good thing, too. It was just too easy to ftp a C source and compile it
|>on your workstation. Now you have to find a C compiler too. How are
|>you going to build gcc?
So every sun user will have a different compiler?
Aggghhhh!!!!!
It is bad enough having to support the bugs in umpteen different manufacturers
compilers. Having to support more than one compiler for the same platform?
Forget that for a lark.
|>>I'd say it's
|>> the exact opposite, they are no longer foisting their C compiler
|>> on you.
|>
|>Yeah, I've always noticed those Sun users: "Damn, I wish Sun didn't include
|>this C compiler with the system. I can't delete it, and, since it's here, I
|>can't get another one..."
Last time I looked I had more C compilers on the DECstation than I needed. Viz
cc, the portable C compiler, gcc in several versions and a couple of cross
compilers.
|>>Seems to me for a long time SPARC
|>> has gotten new versions of PC software for others. DEC and HP have
|>> ported THEIR packages to SPARC, Sun hasn't seen the financial
|>> need to do so.
|>
|>What packages might you be talking about? Borland C?
DEC ported Motif to the Sun, basicaly to stop their attempt to foist Open Look
on everybody. They also ported stuff to the IBM-PC, the Mac and a few other
boxes. They have at last realized that if the software is single platform, then
people don't want it.
--
Phill Hallam-Baker
Phill Hallam-Baker
Sense of Deja vu, this looks and smells just like the notes that DEC used to
send out in the mid 80s. As I said, the suits are running sun and they are going
to drive everything on 3 month profit forcasts and short term planning. Profits
up for two years, company bust in four.
I once worked in a company like that. In fact I used to live in a country run by
a government that ran on those lines. They destroyed the ecconomy in a little
under two years.
Back in the dim and distant past, the reason why many people bought UNIX was
that it came with a compiler.
So now when we hear of Suns "sub $4200" computer we know that it is about as
much use as one minus a plug.
--
Phill Hallam-Baker
M Darrin Chaney
I was joking, but this actually wraps around to the original post. Rob said
that DEC and HP ported their code to Sun, but "you don't see Sun doing it
because they don't have to."
In actuality, Sun is too stupid to do it right now (they'll be catching on
soon, DEC did). Take Motif, for instance. A recent poll shows that something
like 40% of sites with OpenLook also have Motif installed. DEC sells X
software for the Mac and PC. They also have DECwrite for the Sun platform.
What Rob doesn't seem to understand is that DEC is filling voids that Sun
doesn't realize need to be filled yet. Motif and DECwrite are two good
examples because neither have parallels in the Sun world (Sorry,
Sunview^H^H^H^H^H^H^HOpenLook doesn't matter to the rest of the world).
Sun doesn't see the financial need to do so because they've been blinded
by the roaring success of the last couple of years. The only way that they
are able to carry on with any success nowadays is because of their tradeup
program (which is excellent). Hardware-wise, they are a couple of years
behind DEC, HP, and IBM. Software-wise, they're behind Babbage. But, if
I already have a Sun-anything, I can get a huge discount off a new Sparc.
Even if it is much slower than some of the machines other companies have,
it's also _much_ cheaper. They keep with the price-performance curve, but
only on the low end.
But, I have faith that they'll wise up. The same elements that made them
successful a few years ago can make them successful now. But, the main
element was meeting customer needs. With the new and improved "we know what
the customer needs more than they do" attitude, they'll just hurt. DEC and
IBM just gave up that attitude, and it's definitely helping. We'll see
what happens with Sun.
Douglas Miller
phi...@concave.cs.wits.ac.za (Philip Machanick) writes:
> I am somewhat skeptical about how well DEC will implement MP Alpha
> machines. I remember a case a few years back when a multiprocessor VAX
> had to have a processor removed for maintenance and it was _faster_
> without the extra processor!
You must be thinking of DEC's first and most short-lived multi-processor
VAX, the 11-782. It was very asymmetric, and under the right load
conditions, it could indeed exhibit the behavior you describe. Please note
that this was all a long time ago.
> Of course things could have changed since then...
Yes, a lot! If you want to evaluate DEC's performance in multi-processor
design, look at current models such as the VAX 6000, 7000, 10000 series.
Phill Hallam-Baker
(Douglas Miller) writes:
But every shared memory machine suffers from the n+1 effect at some point. It is
the principle disadvantage with the shared memory system. .For the 11-782, n was
1. For one of the Convex machines it was 16. For most machines it hovers in the
range of 4-6.
This is the big problem with producing "high end" machine just by adding
processors, unless your communications bandwith scales with the number of
processors , you will have a limit to the number of processors that work.
This is why point to point networks like the transputer, and switching networks
(which have a limit but in the 100+ processor range) are so interesting.
--
Phill Hallam-Baker
Ian Jefferson
I was interested to see the length and breadth of this thread. It`s
fascinating that few of the contributers made comments, as above, to the
effect "who cares if we can do nothing fast".
I can't believe the interest in better faster hardware that runs O/S's
that do so little for the user. For years in the PC community I could
not understand why anyone would buy a Mac when it was arguably slower
and more expensive than an IBM clone PC. Finally after years it dawned
on me that while I was running Wordstar *real fast* they were making
documents that I could SIMPLY NOT CREATE! In fact now I realize how
much of a line (fish) I've been swallowing from the whole computer
industry.
Now I'm into NeXT and while the *Better Faster Iron* community is
arguing about how to multiply matrixes faster I'm doing more USEFULL
work on my 030 NeXT than on machines 10 or 20 times faster. Why?
Because with NeXT I can do anything that the fast Iron can do (ok slower
:-) BUT I can do stuff that is simply impossible on other platforms.
Sure there are reasons to have fast hardware I have access to that stuff
when I need it, thats why we have a heterogenious Network here. Do you
think that Mac's and PC's outsell UNIX workstations 100:1 ? because they
multiply better?
Gad I wish I was writing this on my NeXT so I could run the dictionary
and thesaurus. Gad I wish every one had multimedia mail so I could post
pictures of dinasour's from the dictionary to the net.
Just go buy an i860 HyperCube if you want to multiply !
Ian
--
---------------------------------------------------------------------------
Ian Jefferson ij...@ccs.carleton.ca No NeXT mail please!
ij...@computeractive.on.ca NeXT mail please!
J. D. McDonald
>Gad I wish I was writing this on my NeXT so I could run the dictionary
>and thesaurus. Gad I wish every one had multimedia mail so I could post
>pictures of dinasour's from the dictionary to the net.
So why didn't you, if its so much better?
We'd like to know???
Doug McDonald
P.S. I'm writing this from my PC.
John Mount
[why]
|> Do you
|> think that Mac's and PC's outsell UNIX workstations 100:1 ? because they
|> multiply better?
Because (with a few exceptions) PC's and Mac's are much cheaper.
|> Gad I wish I was writing this on my NeXT so I could run the dictionary
|> and thesaurus. Gad I wish every one had multimedia mail so I could post
|> pictures of dinasour's from the dictionary to the net.
Don't need a NeXT to do that- dictionary/thesaurus CD roms are available for
most computers and workstations. And sending/posting multimedia objects
(e.g. stupid pictures) didn't begin and doesn't end with the NeXT (ie.
ever heard of SmallTalk or Andrew?)
--
--- It is kind of strange being in CS theory, given computers really do exist.
John Mount: jmo...@cs.cmu.edu (412)268-6247
School of Computer Science, Carnegie Mellon University,
5000 Forbes Ave., Pittsburgh PA 15213-3891
Thomas Sippel - Dau
- In article <1992Nov25....@cc.ic.ac.uk>, vul...@imperial.ac.uk (hey, that's me) writes:
- > In article <921124133...@menora.weizmann.ac.il>, d...@menora.weizmann.ac.il (Dov Grobgeld) writes:
- > - One of the major questions that has been
- > - raised is how stable our investment is in terms of the long time
- > - development of the major chip of the architecture we choose.
- >
- > I fear your priorities are dead wrong. ...
-
- As someone who rather recently invested quite a bit of my company's money
- in DEC's MIPS-based systems, I find the above question to be very relevant.
- Too late and after the fact, unfortunately....
Yes, and ?
Do these DECstations work or do they not ?
Did you commission a worldbeating development on MIPS chips from DEC ?
Did DEC fail to fulfill the contract ?
Did you ever buy a car to get to that tantalizing open road in the ads ?
Dis you ever see a movie because you knew the director needed the money
for making the next film ?
Because if you have a contractual problem, talk to your contracts droid or
your lawyer. DEC have quite openly committed themselves for low cost upgrades
to R4000 chips on the DECstation 5000-xxx range. If they are not available
yet, I would guess that is because the R4000 chips are not that low cost yet.
If you cannot wait the few months until they are, you may have to sacrifice
the low cost attribute.
If you bought the dream of problems solved by compute power from a hardware
vendor, then you will have a few problems to come your way. Car ads always
show you the free road with one car on it - your car, once you paid your money.
But regardless of how much you spend on a car, or how many you buy, actual
roads always seem to stay congested. Try complianing ...
I also see people here spending money on things that are plainly not on offer,
not just in computing; it is the stuff that sales and marketing are made off.
If you spend your own money on your dreams, go ahead, but that is not a solid
business decision.
If the computers you buy earn enough for you to pay for themselves, they are
a good buy, regardless of what they cost or how fast they are. But if they
inhibit you in what you want to do, don't buy them, or walk away from those
you bought.
That primarily means you need to know what you want to do with those computers,
and that is a lot harder than comparing feature lists, discount schemes, or
other marketing hype. Actually, life as such was never easy ...
Thoams
--
*** This is the operative statement, all previous statements are inoperative.
* email: cmaae47 @ ic.ac.uk (Thomas Sippel - Dau) (uk.ac.ic on Janet)
* voice: +44 71 589 5111 x4937 or 4934 (day), or +44 71 823 9497 (fax)
* snail: Imperial College of Science, Technology and Medicine
* The Center for Computing Services, Kensington SW7 2BX, Great Britain
Lee Sailer
: In article <1992Nov25....@cc.ic.ac.uk> cma...@imperial.ac.uk writes:
: I don't know much about HP except that I have been told that their
: operating system isn't really UNIX. Maybe someone else might want to
: comment?
:
I can't think of any ways that HP-UX is not really Unix.
--
Lee Sailer
- Let's leave my employer
out of this, OK?
Maurice J. LeBrun
sens...@ricky.brainlab.utsa.edu (David M. Senseman) writes:
|I don't know much about HP except that I have been told that their
|operating system isn't really UNIX. Maybe someone else might want to
|comment?
It's real, it's unix and it's **mighty** idiosyncratic! It's easy
to port code off HP-UX, but porting onto it was considered difficult.
The only machine I've considered harder to port to was the honeywell
dps-6, with its 32-bit integer pointers and 48-bit character pointers.
I typically have little trouble porting applications to HPUX. There are some
that are well-nigh impossible ports, mind you -- those that are heavily
infested with BSD'isms, for example. But otherwise there are just a few
things to do, like (1) change 'cc' to 'c89', (2) add a -D_HPUX_SOURCE to the
compile line, and (3) add the appropriate X11 and Motif directories to the
link and include paths (i.e. -L<dir> and -I<dir>). These alone do the trick
for a surprising number of programs I've pulled off the net.
--
Maurice LeBrun m...@fusion.ph.utexas.edu
Institute for Fusion Studies, University of Texas at Austin
Faire de la bonne cuisine demande un certain temps. Si on vous fait
attendre, c'est pour mieux vous servir, et vous plaire.
[menu of restaurant Antoine, New Orleans]
Philip Machanick
hal...@zeus02.desy.de writes:
>This is why point to point networks like the transputer, and switching
networks
>(which have a limit but in the 100+ processor range) are so interesting.
I ran a benchmark (a real non-toy example) on a 16-processor T800-based
machine and it was 3 times slower than a single R3000 processor SGI
Indigo.
If you need 50 processors to better a single-processor machine, you'd
better be scalable to 100+. (I know the T9000 is supposed to be better
but vapourware always is.)
I do not believe that shared-memory is inherently less scalable than
distributed memory. You obviously can't scale a single bus design very
far especially with fast processors, but other interconnects are possible.
Distributed memory machines are generally limited by communication cost,
and so are shared memory machines, except in the latter case the
communication is effected by caching. A scalable distributed memory
program
is one in which communication cost is controlled (ideally does not grow
with number of processors). The same is true of shared memory, except
the programming techniques may be different.
--
Philip Machanick
Computer Science Dept, Univ of the Witwatersrand, 2050 Wits, South Africa
phi...@concave.cs.wits.ac.za phone: 27 (11) 716-3759 fax: 339-7965
jac...@pravda.enet.dec.com
|>|> I don't know what "advanced beta" means either but, while general availability
|>|> of DEC OSF/1 V1.2 (Alpha) is scheduled for March, several hundred Alpha OSF/1
|>|> systems have now begun shipping to software developers under an early release
|>|> program. Also, Version 1.0 of DEC OSF/1 was released last March.
|>|> OPEN SYSTEMS
|>|> TODAY reviewed it in their May 11 issue and praised it's stability and
|>|> speed, even
|>|> though V1.0 was only a developer's release for some DECStations. (They
|>
|> I.e. job blow user can't buy it where as they can by Solaris
|> 1.1, 2.0 and now 2.1. They can also get HP-UX 8.x and 9.x(?).
|> Again, vapor city UNIX wise.
Call a sales rep, tell him you want a DEC 3000 workstation with
the OSF/1 advance kit and they'll be more than happy to sell it to you and
deliver it before the end of the year if you choose to have it that way.
You can also buy DEC OSF/1 V1.0 on DECstation (MIPS R3000) platforms. That's
been shipping since March 1992.
|> Who cares about equal CPU, were they equal in COST and AVAILABILITY
|> of iron and software packages? i.e. A machine I can use to solve
|> my problems today with the software I want is MUCH more
|> valuable than a promise of something being available RSN
Oh, I see that you've swallowed McNeally's line that "Performance now
equal's volume and we've won". Now that Sun is asking its customers to
pay the same amount for a fraction of the performance offered by the other
vendors, they want you to believe. Take a look at a SS10-30 and a
DEC 3000 Model 400 . Same price, Alpha is TWICE the performance. The
Alpha machine also outperforms the SS10-41 which costs $5K more.
Yea, performance is volume all right. Those who need performance need
Volumes of Suns to do the job....
--
William M. Jackson
Alpha Workstation Product Marketing Manager
Workstation Engineering
Digital Equipment Corporation
146 Main Street
Maynard, MA 01754
Ian Jefferson
>In article <ijeff.723393631@cunews> ij...@hank.carleton.ca (Ian Jefferson) writes:
>>Gad I wish I was writing this on my NeXT so I could run the dictionary
>>and thesaurus. Gad I wish every one had multimedia mail so I could post
>>pictures of dinasour's from the dictionary to the net.
>So why didn't you, if its so much better?
>We'd like to know???
That's easy. The machine I have access to to read news is a SUN, although we have some
NeXT's here I don't get to sit in front of them. My NeXT is at my home and I havn't had
time to install the SLIP connection.
>Doug McDonald
>P.S. I'm writing this from my PC.
--
M Darrin Chaney
>David M. Senseman (sens...@ricky.brainlab.utsa.edu) wrote:
>: In article <1992Nov25....@cc.ic.ac.uk> cma...@imperial.ac.uk writes:
>
>: I don't know much about HP except that I have been told that their
>: operating system isn't really UNIX. Maybe someone else might want to
>: comment?
>:
>
>I can't think of any ways that HP-UX is not really Unix.
It's a System VR4 variant. As for their graphical interface, they use Motif,
and they pass my standards for excellence in a GUI: Apple sued them.
Doug Mohney
>Oh, I see that you've swallowed McNeally's line that "Performance now
>equal's volume and we've won".
Well, it could be argued he's following the same strategy (more units lock out
better machines) as the IBM-PC/Intel world...
Play in the intelluctual sandbox of Usenet
-- > SYS...@CADLAB.ENG.UMD.EDU < --
Doug Siebert
>>
>>I can't think of any ways that HP-UX is not really Unix.
>It's a System VR4 variant. As for their graphical interface, they use Motif,
>and they pass my standards for excellence in a GUI: Apple sued them.
I don't think your standards are very high then....Apple also sued Microsoft.
--
/-----------------------------------------------------------------------------\
| Doug Siebert | "I don't have to take this abuse |
| Internet: dsie...@isca.uiowa.edu | from you - I've got hundreds of |
| NeXTMail: dsie...@chop.isca.uiowa.edu | people waiting in line to abuse |
| ICBM: 41d 39m 55s N, 91d 30m 43s W | me!" Bill Murray, Ghostbusters |
\-----------------------------------------------------------------------------/
Phill Hallam-Baker
McDonald) writes:
|>In article <ijeff.723393631@cunews> ij...@hank.carleton.ca (Ian Jefferson)
|>writes:
|>
|>
|>>Gad I wish I was writing this on my NeXT so I could run the dictionary
|>>and thesaurus. Gad I wish every one had multimedia mail so I could post
|>>pictures of dinasour's from the dictionary to the net.
|>
|>So why didn't you, if its so much better?
|>
|>We'd like to know???
Ian is of course completely right. As far as the low end goes NeXt have ease of
use sewn up. I'm not sure that other vendors haven't started to catch up though.
If NeXtstep was avaliable for the Alpha I would be very pleased to use it.
Problem with NeXt step is that it only realy takes off when everybody has the
same standard. We need tools which allow these sorts of things, there is already
a global hypertext network, the world wide web.
I haven't got a dinasour and if I could post it not enough would read it to
warrant the bandwidth. Herese a postscript picture from my thesis instead:-
http://zws009.desy.de.:2784/ZWS009$DKA0/
hallam/www/docs/pictures/MULTIPLEXING_ROUTING_PLANES.GRA'
For more details try :-
telnet info.cern.ch
Passowrd Web (or is it www?)
--
Phill Hallam-Baker
Phill Hallam-Baker
<phi...@concave.cs.wits.ac.za> writes:
|>In article <Byoo9...@dscomsa.desy.de> Phill Hallam-Baker,
|>hal...@zeus02.desy.de writes:
|>>This is why point to point networks like the transputer, and switching
|>networks
|>>(which have a limit but in the 100+ processor range) are so interesting.
|>
|>I ran a benchmark (a real non-toy example) on a 16-processor T800-based
|>machine and it was 3 times slower than a single R3000 processor SGI
|>Indigo.
|>
|>If you need 50 processors to better a single-processor machine, you'd
|>better be scalable to 100+. (I know the T9000 is supposed to be better
|>but vapourware always is.)
I have used arrays >1000 without switches and >100 with.
ZEUS has a 1000 node embedded array.
Comparing a 1986 processor with a 1992 processor for speed is garbage, and you
should know that. T800 is in 2 micron CMOS and was a first generation device.
The R3000 is a second iteration floating point unit and should be able to take
on 10 or so T800s on an equal footing.
Comparing two architectures on the basis of a single test on two processors from
different generations does not have much value. Parallel code is very sensitive
to the algorithm, partitioning, load balancing system etc.
There is no reason why you could not add link engines to the R4000, Alpha or HP
chip. Given the right O/S you could then take on CRAY and give them a whipping.
DEC will in fact license the alpha chip die so if someone was willing to do the
work it could happen.
|>I do not believe that shared-memory is inherently less scalable than
|>distributed memory.
Read Hockney and Jesshope, Parallel computers II. They go through it in all the
gorry detail. Switches and busses simply do not scale. Either the performance
does not keep up or the cost rises with the square of the connections.
|>You obviously can't scale a single bus design very
|>far especially with fast processors, but other interconnects are possible.
And those interconnects end up as loosely coupled ensembles of locally tightly
copuled macines. The point about shared memory is not so much the hardware
model, by all means use shared memory to implement fast links. ZEUS uses that
very architecture. But the shared memory is only being used as an optimisation
of a losely coupled paradigm and not as a fundamental basis.
|>Distributed memory machines are generally limited by communication cost,
|>and so are shared memory machines, except in the latter case the
|>communication is effected by caching. A scalable distributed memory
|>program
|>is one in which communication cost is controlled (ideally does not grow
|>with number of processors). The same is true of shared memory, except
|>the programming techniques may be different.
As the chip die shrinks it will no longer be possible to efficiently use the
extra area to optimize a sequential processor. Two routes suggest themselves,
either grow a large on board cache or stick an extra processor on. Small scale
parallelism on the tightly coupled model will happen at the chip level. For the
large machines you need to get out of the shared memory paradigm. You have to
reduce communication costs by accepting data locality.
I consider the demand that every processor in a network have equal access time
to every memory element to be an unreasonable one. If you abandon it you have
very much more freedom to design the hardware.
--
Phill Hallam-Baker
David M. Senseman
>: In article <1992Nov25....@cc.ic.ac.uk> cma...@imperial.ac.uk writes:
>
>: I don't know much about HP except that I have been told that their
>: operating system isn't really UNIX. Maybe someone else might want to
>: comment?
>:
>
>I can't think of any ways that HP-UX is not really Unix.
>
Like I said, I don't know much about HP. I went back and asked my
colleague (computer scientist) and this is what he said:
"It is fairly nonstandard although my impression is that it is not as
nonstandard as AIX. This means that porting software is harder to HP-UX
than most versions."
This same idea was mentioned by several other individuals, both on
"comp.sys.sgi" and to me via E-Mail. Remember that an academic
institution such as ours must make HEAVY use of public domain
software. For better or worse, much of this software is written
on Sun workstations -- and often uses a number of BSDisms. As I
understand it, HP-UX offered much less BSD "stuff" than Sun or
SGI's IRIX for that matter. Also remember that many faculty are
really OVERWORKED between teaching, reseach and f*#@$ committees.
We just don't have that much free time to hack away at "non-standard"
code. Also keep in mind that the original thread was from an academic
department (chemistry) and it was to them who I was responding
in my post.
While I will spend hours bashing IBM for what they did
to me (long story), I have no axe to grind with HP or DEC for that
matter. I wish them both well. SGI needs alittle competition to
keep the new products coming :-)
--
David M. Senseman, Ph.D. | A man who has never gone to school may steal
(sens...@lonestar.utsa.edu) | from a freight car; but if he has a university
Division of Life Sciences | education, he may steal the whole railroad.
UT San Antonio | Theodore Roosevelt (1858-1919)
Phill Hallam-Baker
sens...@ricky.brainlab.utsa.edu (David M. Senseman) writes:
|>In article <BypLx...@hpuerca.atl.hp.com> sai...@hpuerca.atl.hp.com (Lee
|>Sailer) writes:
|>>David M. Senseman (sens...@ricky.brainlab.utsa.edu) wrote:
|>>: In article <1992Nov25....@cc.ic.ac.uk> cma...@imperial.ac.uk
|>writes:
|>>
|>>: I don't know much about HP except that I have been told that their
|>>: operating system isn't really UNIX. Maybe someone else might want to
|>>: comment?
|>>:
|>>
|>>I can't think of any ways that HP-UX is not really Unix.
|>>
|>
|>Like I said, I don't know much about HP. I went back and asked my
|>colleague (computer scientist) and this is what he said:
|>
|>
|>"It is fairly nonstandard although my impression is that it is not as
|>nonstandard as AIX. This means that porting software is harder to HP-UX
|>than most versions."
|>
|>This same idea was mentioned by several other individuals, both on
|>"comp.sys.sgi" and to me via E-Mail. Remember that an academic
|>institution such as ours must make HEAVY use of public domain
|>software. For better or worse, much of this software is written
|>on Sun workstations -- and often uses a number of BSDisms.
There are two sorts of Public domain software, the stuff that is usefull and the
stuff that is not. Of the useful stuff the vast majority is avaliable for VMS.
Since HP have one of the hottest boxes on the market it is a fair bet that most
of the useful stuff would be ported even if they decided to run RSX-11 or CP/M.
If you want to have an easy life then you will have to keep throwing out your
old machines and buying new ones. Five years ago VAX/VMS was the "standard", now
there are more suns, next year it will probably be HP/DEC/SGI. This is only a
transient advantage.
Sun are still trying to push Sunview (open look) when the rest of the world got
together and agreed to use motif. Their current policy is leaving them in the
cold as far as standards go.
I have ported a lot of software between UNIX boxes. There are a number of hacks
that you have to know, but these are in general more dependent on site specific
hassles. The lack of a logical name facility makes this a real pain but provided
the code is not coded arround one platform I find that a DECstation-SGI port no
more hassle than a DECstation->Decstation port.
In fact in general "porting" is not the problem, the real hassle is trying to
boot code that uses a lot of other packages and is really dependent on the
precise version of a package. I once tried to port a program that required a
particular Tk/Tcl widget that only ran on the previous version of Tk.
To port on UNIX on a regular basis I would recommend demanding super user privs
and configure the machine so that it looks as much as possible like the ones at
MIT.
Porting VMS to UNIX is only a hassle if the code was written using a lot of
system calls. Even programs written using VAX-Fortran extensions can often be
compiled, many manufacturers sell VAX-FORTRAN compilers.
PORTING VMS-UNIX is only a hassle if the program wants to get system information
by reading files that either do not eist in VMS or are not read access for
security. Just load up the POSIX shell and it usually runs.
--
Phill Hallam-Baker
Eric Jones
In article <ByrFJ...@dscomsa.desy.de>, hal...@zeus02.desy.de (Phill Hallam-Baker) writes:
|>
|> There is no reason why you could not add link engines to the
|> R4000, Alpha or HP chip. Given the right O/S you could then take
|> on CRAY and give them a whipping. DEC will in fact license the
|> alpha chip die so if someone was willing to do the work it could happen.
|>
already licensed alpha, presumably with the idea of putting together
a clever massively parallel system. Whether it'll be the architecture
you're describing or not is another question, but CRAY _does_ know something
about building heavy iron (and selling it, which is at least as important,
unfortunately).
Yamanari
> Umm, actually, whipping CRAY that way would be tough...they've
>already licensed alpha, presumably with the idea of putting together
Even the Japanese couldn't whip CRAY after 550 million of
gov't spending.
This is not a dispute or a flame, but could you provide a
source for your comment--I'd not heard it.
--
Snout: O Bottom, thou art chang'd! What do I see on thee?
Bottom: What do you see? You see an ass-head of your own, do you?
---"I despise mystics, they fancy themselves so deep, when they----
----aren't even superficial" --Nietzsche ---------------------
Jonathan Thornburg
>
> Even the Japanese couldn't whip CRAY after 550 million of
> gov't spending.
Err, not to start a dispute over the desirability of such government
subsidies of supercomputer industries, but the US government has
historically given large subsidies to the US supercomputer industry.
In particular, large amounts of applied research are funded by the
US government (NRL in the "old days", lately DARPA and SEMATECH),
and the US government also lobbies strongly against government-funded
organizations (eg NCAR, US universities) buying Japanese supercomputers.
Moreover, the bomb labs (Los Alamos and Livermore) and NSA all sign
up well in advance to buy the latest US supercomputers (IBM Stretch,
CDC 6600/7600, Cray 1/1-S/X-MP/Y-MP/2/C-90/, CM-1/2/5, ... [*]).
In an industry where *total* sales of a successful model generally
fit in an (8 bit) byte with room to spare :-), having a guaranteed
3 sales up front (Los Alamos, Livermore, NSA) can be a significant
boost in raising capitol to finance development. And having these
sales be almost independent of price, and knowing that NSA will
pay large amounts of money for custom crypto hardware in place of
FP, certainly doesn't hurt either...
The above statements, I believe, are all matters of historical
record, and aren't (shouldn't be) controversial. The *desirability*
of such subsidies is a topic for considerable debate (flame wars),
but that's beyond the charter of comp.arch .
[*] Yes, I know about the Cray-3. But it was (is) a superfailure,
not a supercomputer.
- Jonathan Thornburg
<jona...@geop.ubc.ca> through end of (calendar) 1992, then
<jona...@einstein.ph.utexas.edu> or <jona...@hermes.chpc.utexas.edu>
[for a few more months] U of British Columbia / {Astronomy, Physics}
[then through Aug/92] U of Texas at Austin / Physics / Relativity
Phill Hallam-Baker
|>In article <1992Dec6.0...@ll.mit.edu> ej...@ll.mit.edu (Eric Jones)
|>writes:
|>> Umm, actually, whipping CRAY that way would be tough...they've
|>>already licensed alpha, presumably with the idea of putting together
|>
|>
|> Even the Japanese couldn't whip CRAY after 550 million of
|> gov't spending.
|>
|> This is not a dispute or a flame, but could you provide a
|> source for your comment--I'd not heard it.
Every DEC salesman seems to come out with the CRAY-alpha project almost as soon
as they are in the door.
I wasn't so much commenting on outperformming CRAY on raw performance, however
since they are using a readily avaliable technology they could be outperformed
on other fronts, Cost, for example. Architecture for another. Seymour may be
good at building computers, but is CRAY?
--
Phill Hallam-Baker
mj...@minster.york.ac.uk
>In article <ByLJC...@digiboard.digibd.com> rhe...@dellr4.digibd.com (Rob Healey) writes:
>> Who cares about equal CPU, were they equal in COST and AVAILABILITY
>> of iron and software packages? i.e. A machine I can use to solve
>> my problems today with the software I want is MUCH more
>
>Yes, but if you are to benchmark operating systems then the machines must
>have equal cpu & I/O power.
Even that's not enough -- it gets far worse. Caches, MMUs, paging, DMA and a
host of other effects can render your carefully constructed benchmark results
meaningless. Benchmarking OSes is _extremely hard_.
>Jussi Eloranta Internet(/Bitnet): ! The ultimate trip is
>University of Jyvaskyla, Jussi.E...@jyu.fi ! death.
>Finland [130.234.0.1] ! -- Jim Morrison
Mat
| Mathew Lodge | "I don't care how many times they go |
| mj...@minster.york.ac.uk | up-tiddly-up-up. They're still gits." |
| Langwith College, Uni of York, UK | -- Blackadder Goes Forth |
J. Eric Townsend
jonathan> applied research are funded by the US government (NRL in the
jonathan> "old days", lately DARPA and SEMATECH), and the US
jonathan> government also lobbies strongly against government-funded
jonathan> organizations (eg NCAR, US universities) buying Japanese
jonathan> supercomputers.
Also include NASA in that list. It's no secret (ie: it was in the
newspapers) that congress cut our budget when they heard a rumor that
we were *considering* buying a SX-3. Right now we're in negotiations
to buy a C90 with all the bells & whistles (to the tune of ~$70
million). Also, sites like NASA are likely to buy "not ready for
prime-time" supercomputers like the iPSC/860, CM-2, or KSR which have
an even smaller market than Convexen, Crays, etc.
--
J. Eric Townsend -- j...@nas.nasa.gov -- 415.604.4311
'92 R100R, DoD# 0378, BMWMOA, AMA, ACLU, EFF, CPSR
"HotHead Rules!"
Eric Jones
|>
|> This is not a dispute or a flame, but could you provide a
|> source for your comment--I'd not heard it.
|>
Not taken as such. Reference _Digital Review_ Feb 17, 1992:
Headline article: "Cray Research licenses Alpha CPU for use in
massively parallel system". It also seems to get mentioned in about
every third article which gives an overview of DEC's Alpha strategy.
Eric Jones
In article <1fs63a...@cs.ubc.ca>, jona...@geop.ubc.ca (Jonathan Thornburg) writes:
|>In article <1992Dec6.0...@wam.umd.edu> rsro...@wam.umd.edu (Yamanari) writes:
|>>
|>> Even the Japanese couldn't whip CRAY after 550 million of
|>> gov't spending.
|>
|>Err, not to start a dispute over the desirability of such government
|>subsidies of supercomputer industries, but the US government has
|>historically given large subsidies to the US supercomputer industry.
|>In particular, large amounts of applied research are funded by the
|>US government (NRL in the "old days", lately DARPA and SEMATECH),
|>and the US government also lobbies strongly against government-funded
|>organizations (eg NCAR, US universities) buying Japanese supercomputers.
|>
|>record, and aren't (shouldn't be) controversial. The *desirability*
|>of such subsidies is a topic for considerable debate (flame wars),
|>but that's beyond the charter of comp.arch .
|>
Actually, any discussion about government policy with respect
to computer purchases belongs elsewhere (unless it's contingent on
architectural concerns). However, I don't think this should be allowed
to pass without comment. My comment is simply that "turnabout is fair play."
In my last job, I worked with a group of high-energy physicists who
were doing an experiment at a facility in Japan, in collaboration with
University of Tokyo and some other institutions. The Japanese government
was very reluctant to allow any US-built computer hardware be used on
the experiment, preferring instead that everyone be forced to use a
Fujitsu supercomputer. When it was made clear to the government that
the experiment _couldn't_ work that way, our institution was allowed to
import a VAX, but had to retain ownership of it in spite of the fact
that this abrogated the agreement in which the Japanese were expected
to provide the computing equipment for the experiment.
I decline to state whether rigid government regulations about
whose equipment can be acquired is rational or irrational. I simply
argue that the Japanese can least of all cry "foul."
Followups by mail, please.
Philip Machanick
writes:
> Actually, any discussion about government policy with respect
>to computer purchases belongs elsewhere (unless it's contingent on
>architectural concerns).
>University of Tokyo and some other institutions. The Japanese government
>was very reluctant to allow any US-built computer hardware be used on
>the experiment, preferring instead that everyone be forced to use a
>Fujitsu supercomputer. When it was made clear to the government that
>the experiment _couldn't_ work that way, our institution was allowed to
>import a VAX, but had to retain ownership of it in spite of the fact
>that this abrogated the agreement in which the Japanese were expected
>to provide the computing equipment for the experiment.
Very weird. Only politics could make a VAX and a supercomputer
alternatives.
Thomas Sippel - Dau
-
- Even that's not enough -- it gets far worse. Caches, MMUs, paging, DMA and a
- host of other effects can render your carefully constructed benchmark results
- meaningless. Benchmarking OSes is _extremely hard_.
It can be done, if you keep your objective in mind.
True, industry benchmarks suffer from the "Molehill effect": A certain
task is accepted as a benchmark and the time it take the machine to do it
is quoted, whicg is all very sporting as long as moles are doing it. It is
often followed by cries of "unfair" when somebody then brings out a
Caterpillar Truck and cleans up.
But it is difficult to see how manufacturers of computers can do anything
else, as the resulting numbers must be comparible. It is also not realistic
to set up "standard tasks" that should be run in an hour in a few years time,
but unfortunately take several months to run with today's computers.
As a user, however, you can do a lot better, by taking a scaleable task and
testing the machine to breakdown. And many finite element tasks are easily
scaleable, just increase the mesh size, and take note whether the problem
complexity grows linear or with the cube (or whatever) of the parameter.
This gives you in particular an idea of where a system breaks down first.
Take an example I once had, I used a matrix inversion by an algorithm similar
to gaussian elimination on two machines, fred and bill, and I increased the
matrix size. I got the following results:
machine N arraysize real time user time system time %
name bytes 000 h:m:s h:m:s h:m:s
fred 100 160 0:05.4 0:01.2 0.0 23
fred 200 640 0:25.3 0:08.3 0.0 33
fred 500 4,000 9:51.4 3:53.8 0.6 40
fred 1000 16,000 2:02:18.4 38:10.6 3.0 31
fred 1500 36,000 154:31:54.7 3:12:01.9 6.5 2
bill 100 160 3.2 1.8 0.0 56
bill 100 160 4.0 1.8 0.0 40
bill 200 640 30.0 13.9 1.2 50
bill 200 640 41.0 15.0 0.1 36
bill 500 4,000 10:53.0 5:10.7 3.8 48
bill 1000 16,000 1:15:03.5 45:08.3 59.6 61
bill 1000 16,000 1:19:09.3 45:22.0 1:00.0 59
bill 1500 36,000 9:21:58.0 2:56:07.8 29:59.3 37
Both machines had 32 Mbytes memory, for small arrays fred was a little faster
in user time spent. For the last size tested (1500x1500), bill got nominally
a better user time than fred, but had a significant system time overhead, so
that fred was still "faster". But looking at the real time required, bill
did that overnight, while fred spent almost a week.
The reason is that naive Gaussian elimination algorithms have an almost
random memory access pattern and page furiously once the matrix is no
longer completely in memory. Thus, bill could still be used for tasks of
this ilk if they were handled sensibly, like only one of them and not
during the day, while on fred this task would have prompted administrative
action. Needless to say, bill felt "strained" while this was going on,
fred totally bombed out (ever tried editing a file when character echo
takes a minute :-()
Such scale tests to destruction also allow you to see what configuration
is still suitable. Just a fast CPU does not help if you cannot add enough
memory so that your typical tasks can make use of the CPU speed.
Unfortunately test results like that are almost impossible to report ...
Thomas
George Carr
You may wish to reconsider your comment concerning who is "not ready
for prime-time". The KSR I played on at Supercomputing '92 looked ready
for real work to me!
Rob Healey
|> I wasn't so much commenting on outperformming CRAY on raw performance, however
|> since they are using a readily avaliable technology they could be outperformed
|> on other fronts, Cost, for example. Architecture for another. Seymour may be
|> good at building computers, but is CRAY?
|>
tad bit different as the Cray 3 situation has shown.
Cray Research has a few things going for it:
1) About 16 years of experience in Chippewa Falls and Eagan, don't
knock 16 years of building supers, it's definitiely a plus.
2) Experience with the SOFTWARE end of try to get the most out
of hardware. As everyone knows, it's usually NOT the hardware
that's the problem, it's the software that drives the hardware.
3) 16 years gives you lot's of contacts to find and get the people
you need to make a product work.
4) Years of experience in cooling, cases and mechanical issues. Cray
Research has a knack of using fairly common technology but
cranks up the clocking and provides more efficiant cooling. You
don't just perfect this sort of thing overnight. It takes a while
to get it right and to train a workforce that can consistantly
build things correctly.
Of these, I think the software is the biggest thing in Cray Research's
favor. The company that licks the software issues in massively
parallel machines wins the prize and Cray Research has a good
start.
Cray Research has done the Y-MP and C-90 without much input from
Seymour and they seem to have done OK. They also seem to see
the writing on the wall of a small number of custom processors
thus the switch to SPARC and Alpha as main CPU and using Cray
Research know how in other areas to drive performance up on
commodity CPU's. The SPARC servers also let them leverage
the software applications into their market, i.e. running
1-2-3 directly on a CRI SPARC superserver feeding into/out of
a cruncher running on a CRI Alpha massively parallel box. Seems
like a shrewed move on CRI's part.
The future belongs to companys that can get software to work
on massivley parallel hardware that uses commodity parts in
clever ways and sell it all at a decent price. I'd be willing
to bet a fair chunk of money that CRI will be one of the prominent
companys in this area.
-Rob
Thor Lancelot Simon
Healey) writes:
> Gad I wish I was writing this on my NeXT so I could run the dictionary
> and thesaurus. Gad I wish every one had multimedia mail so I could post
> pictures of dinasour's from the dictionary to the net.
Gad, I wish everyone was using Andrew. All that, and it runs on reasonably
fast processors. And you can't beat the price, either. I like the NeXT,
but you're giving some pretty simpleminded and not exactly correct reasons
why one ought to...
Incidentally, I'm posting this via NewsGrazer.
Rob Healey
|> In article <ijeff.723393631@cunews> ij...@hank.carleton.ca (Ian Jefferson)
|> writes:
|> > In <ByLJC...@digiboard.digibd.com> rhe...@dellr4.digibd.com (Rob
|> Healey) writes:
|> > Gad I wish I was writing this on my NeXT so I could run the dictionary
|> > and thesaurus. Gad I wish every one had multimedia mail so I could post
|> > pictures of dinasour's from the dictionary to the net.
in the building. PLEASE attribute the right people when you
quote somebody.
Thank you,
-Rob
Adrian Hassall Lewis
>
> I agree with everything Thomas Sippel said and only want to add one point.
> More and more, high performance computing is graphical computing. This is
> certainly true in Biology and I expect in Chemical Physics as well.
>
> If you look at Dec, Sun, and IBM, their graphics strategy has been
> pretty uninspired. As an old PDP-11 user, I have tremendous respect for
> Ken Olsen -- but let's face it, if there ever was a "left-brained"
> person, it was Ken. Dec never had a coherent graphics vision and as far I
> can see, it still doesn't. Sun is just as bad -- witness the TACC-1,
> the incompatible TACC-2, and the lastest in the line, the incompatible
> Freedom 3000 (Evans&Sutherland add on board). And IBM? As someone
^^^^^^^^^^^^^^^^^^^
> who still owns an IBM PC/RT, don't get me started...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> --
> David M. Senseman, Ph.D. | A man who has never gone to school may steal
> (sens...@lonestar.utsa.edu) | from a freight car; but if he has a university
> Division of Life Sciences | education, he may steal the whole railroad.
> UT San Antonio | Theodore Roosevelt (1858-1919)
Excuse me but I'd like to get you (and anyone else) started.
Firstly, on the RS/6000's a large amount of the graphics hardware and software
is licenced from SGI, so what's the big problem with IBM's graphics?
Secondly, I am looking at doing computational chemistry on an RS/6000 and I'd
like to see you (or anyone else) try to talk me out of it (or support it).
ajax
PS Sorry about the cross-posts, but I don't know where this thread first
started.
PPS Please attack via email.
Sean McLinden
>1970s software technology is not something I would want to buy today.
[And here I was beginning to like you because you commented, correctly, that
BSD was still in demand. Oh well.]
Statements like the above excerpt I would expect from Bill Gates but not from
a real programmer. To say that you wouldn't use Unix because it is 1970s
technology is a bit like saying you wouldn't speak French (or English or...)
because it is centuries old. What we call Unix, today, is hardly anything
like what came out of AT&T Bell Labs in the early days and is even a long
way from early System V and BSD 4.2 of a few years (well, maybe more than
a few) ago. Like most modern languages, Unix has survived because it is
dynamic and accommodating and while it is hardly the perfect operating
system (though most people's complaints, including your references to 'ls'
have more to do with the command shells than the kernel architecture) it is
not the dinosaur that the NT zealots makes it out to be.
>Apollo in my view were the only UNIX vendor to realize that they had to put
>work into the basic operating system. They had ACLs, shared libraries and many
>other essential features five years ago.
They are essential for some tasks and totally unnecessary for others. It
depends upon the environment in which you operate. Unix didn't, originally,
have ACLs because the people for whom it was implemented didn't need it.
They had a different concept of a programming environment than you do.
>What I find disgusting about UNIX is that it has *never* grown any operating
>system extensions of its own, all the creative work is derrived from VMS,
>Multics and the operating systems it killed.
So? If originality was important Microsoft would still be a niche vendor.
First of all, your statement was inaccurate and inflammatory. More to the
point, it is meaningless. I mean, who cares. How many people have ported
VMS to their boxes? How many open systems are being developed in Multics?
What is the point?
Unix (whatever that is) is not just an operating system, it is has been the
seed of a marvelous technosocial experiment which is still being carried out.
It isn't fair to say that Unix isn't everything...it wasn't intended to be.
But I doubt that the world would have evolved on a production basis the
concept of horizontal integration of systems without something like Unix to
make it possible.
Sean McLinden
Josh Osborne
>In article <1gt111...@hpscit.sc.hp.com>, t...@computer.bri.hp.com (Tim Phipps) writes:
>|> In a previous article Phil Hallam wrote:
>|> [...The OS kernal only supports sequential files...]
[someone else said, no fseek means they are random access files... then: ]
>But isn't that exactly his point? Sure you can write an ISAM file
>structure using fseek (and if you're REALLY smart, you might even
>write an efficient one), but then how's anyone else going to use
>your files?
If you want others to access your files you make a lib that has functions
to access them. For example: libdbm, libdbz, and libgdbm, and 4.4's libdb.
This has many benifits, and many drawbacks. Take it elsewhere to disscuss
it, it's gone far astray from comp.arch (assuming comp.arch is really
comp.arch.hardware, as the FAQ seems to imply).
--
str...@pix.com "Security for Unix is like
Josh_Osborne@Real_World,The Multitasking for MS-DOS"
"The dyslexic porgramer" - Kevin Lockwood
We all agree on the necessity of compromise. We just can't agree on
when it's necessary to compromise. - Larry Wall
Eric Jones
|> In a previous article Phil Hallam wrote:
|>: 6) File system limited to sequential file, forcing
|>: applications to create their own file system on top of
|>: the UNIX one, thus preventing any standardization or
|>: application independent optimization.
|>(Snore) Try "man fseek".
|>
|>Phippo the Hippo.
|>
But isn't that exactly his point? Sure you can write an ISAM file
structure using fseek (and if you're REALLY smart, you might even
write an efficient one), but then how's anyone else going to use
your files?
Eric
David Fox
>I disagree. It passed it's sell by date years ago.
>
Well, no one said you had to buy it, then. The free unix OSes for the
386, for example, are very modern, very powerful. You could go with
DOS, but it's crippleware by comparison.
>The kernel is a major factor in determining how useful the system is. Only AT&T
>had the capability to introduce a shell to replace the standard ones that could
>have achieved a degree of acceptance.
What about GNU? They wrote BASH, not AT&T. And BASH is a lot better in
my opinion than the other shells out there.
>
>If UNIX was ever allowed to become the sole O/S it would halt O/S deelopment
>completely. The only effort UNIX has ever made is in catching up.
>
How could it possibly, when *source code* is freely available to anyone
for 386BSD and Linux?
>There were other choices. PICK for instance was a very highly regarded system
>but was killed through over agressive attempts to control it. Imagine a world in
PICK didn't use EBCDIC, and it's not a bad OS.
I can imagine a world with EBCDIC as opposed to ASCII is prominent. I
realize EBCDIC does have some problems that ASCII doesn't have, and
ASCII is of course more prevalent. In and of themselves, a machine
using an EBCDIC character set isn't really better or worse than a
machine using an ASCII character set. But the traditional EBCDIC
machines, of course, have been IBM mainframes running (pick one)
DOS/VSE, OS, OS/MVS, etc. They are horribly patched together operating
systems, IMHO. They don't hold a candle to Unix in terms of
user-friendlyness, simplicity, and sheer power.
Phill Hallam-Baker
|>In article <1992Dec19.0...@ll.mit.edu> ej...@ll.mit.edu (Eric Jones)
|>writes:
|>>In article <1gt111...@hpscit.sc.hp.com>, t...@computer.bri.hp.com (Tim
|>Phipps) writes:
|>>|> In a previous article Phil Hallam wrote:
|>>|> [...The OS kernal only supports sequential files...]
|>
|>[someone else said, no fseek means they are random access files... then: ]
|>
|>>But isn't that exactly his point? Sure you can write an ISAM file
|>>structure using fseek (and if you're REALLY smart, you might even
|>>write an efficient one), but then how's anyone else going to use
|>>your files?
|>
|>If you want others to access your files you make a lib that has functions
|>to access them. For example: libdbm, libdbz, and libgdbm, and 4.4's libdb.
|>
|>This has many benifits, and many drawbacks. Take it elsewhere to disscuss
|>it, it's gone far astray from comp.arch (assuming comp.arch is really
|>comp.arch.hardware, as the FAQ seems to imply).
But it is the paucity of software that prevents anything more novel than
floating point accelerators for standard Von Neumann machines gaining wide
acceptance.
If you want to discuss hardware, you cannot ignore the software aspect. Take the
above for instance. In RMS the filestore offers high level functionality. In
UNIX only low level functionality is offered. Now let us consider the
difficulties of producing an intelligent filestore:
VMS/RMS,
Done years ago with the HSC. Nothing special about VMS here of course. ICL were
offering intelligent filestores that could do sorting years ago.
UNIX,
Because the filestore knows only about the fopen, fseek, fread, fwrite and
fclose operations it is easy to interface to any sequential device. However when
the filestore receives an instruction it is only told *what* to do. There is no
clue as to *why* to do it. In this circumstance it is very difficult to do any
form of intelligent cacheing.
--
Phill Hallam-Baker
J. D. McDonald
>But isn't that exactly his point? Sure you can write an ISAM file
>structure using fseek (and if you're REALLY smart, you might even
>write an efficient one), but then how's anyone else going to use
>your files?
By RTFM of course!!
Consider the converse:
You write a file using the oddball formats of VMS.
You send it to someone else.
He can't read it because it's oddball.
How does he read it??
The only way is to RTFM and here the FM refers to the 1600 pounds
of VMS stuff or Disk 47 of the 677 volume CD manuals.
The Unix way has proven to be the best way; its one of the biggest
reasons VMS is a current sales disaster.
The doc for your own ISAM is maybe 2 pages long.
Also consider this: if you write that file on VMS using the VMS
proprietary method, you can't read it on any other machine using
the same code. If you did it the C/Unix way, you code will run as-is
on any machine using standard C. Even VMS.
Doug McDonald
Phill Hallam-Baker
<se...@andrew.cmu.edu> writes:
es: 48
|>
|>>I don't reagard it a "real" UNIX, then again I wouldn't buy a "real" UNIX,
|>>1970s software technology is not something I would want to buy today.
|>
|>[And here I was beginning to like you because you commented, correctly, that
|>BSD was still in demand. Oh well.]
|>
|>Statements like the above excerpt I would expect from Bill Gates but not from
|>a real programmer. To say that you wouldn't use Unix because it is 1970s
|>technology is a bit like saying you wouldn't speak French (or English or...)
|>because it is centuries old.
If I wanted to spend my time looking at centuries old technology I would be an
archeologist.
|> What we call Unix, today, is hardly anything
|>like what came out of AT&T Bell Labs in the early days and is even a long
|>way from early System V and BSD 4.2 of a few years (well, maybe more than
|>a few) ago.
Bugs they still need to fix:-
1) Online manual still designed with aim of minimizing disk space rather than
providing information.
2) No help facility.
3) No standardized user firendly shell.
4) Command qualifiers hard coded into applications making multilanguage
customization impossible.
5) Requires expensive expert to have a chance of any security.
6) File system limited to sequential file, forcing applications to create their
own file system on top of the UNIX one, thus preventing any standardization or
application independent optimization.
|> Like most modern languages, Unix has survived because it is
|>dynamic and accommodating and while it is hardly the perfect operating
|>system (though most people's complaints, including your references to 'ls'
|>have more to do with the command shells than the kernel architecture) it is
|>not the dinosaur that the NT zealots makes it out to be.
I disagree. It passed it's sell by date years ago.
The kernel is a major factor in determining how useful the system is. Only AT&T
had the capability to introduce a shell to replace the standard ones that could
have achieved a degree of acceptance.
|>>Apollo in my view were the only UNIX vendor to realize that they had to put
|>>work into the basic operating system. They had ACLs, shared libraries and
|>many
|>>other essential features five years ago.
|>
|>They are essential for some tasks and totally unnecessary for others. It
|>depends upon the environment in which you operate. Unix didn't, originally,
|>have ACLs because the people for whom it was implemented didn't need it.
|>They had a different concept of a programming environment than you do.
They had a limited problem and provided a limited solution. I find it hard to
see how you can consider UNIX to be a superior system to VMS while admitting
that it is inadequate for many tasks. It would appear to me that the strongest
statement to be made would be that UNIX was superior for some tasks (presumably
through simplicity).
|>>What I find disgusting about UNIX is that it has *never* grown any operating
|>>system extensions of its own, all the creative work is derrived from VMS,
|>>Multics and the operating systems it killed.
|>
|>So? If originality was important Microsoft would still be a niche vendor.
|>First of all, your statement was inaccurate and inflammatory. More to the
|>point, it is meaningless. I mean, who cares. How many people have ported
|>VMS to their boxes? How many open systems are being developed in Multics?
|>What is the point?
If UNIX was ever allowed to become the sole O/S it would halt O/S deelopment
completely. The only effort UNIX has ever made is in catching up.
|>Unix (whatever that is) is not just an operating system, it is has been the
|>seed of a marvelous technosocial experiment which is still being carried out.
|>It isn't fair to say that Unix isn't everything...it wasn't intended to be.
|>But I doubt that the world would have evolved on a production basis the
|>concept of horizontal integration of systems without something like Unix to
|>make it possible.
There were other choices. PICK for instance was a very highly regarded system
but was killed through over agressive attempts to control it. Imagine a world in
which EBSIDIC, not ASCII was the standard for charaters. We would see people
praising the merits of the EBSIDIC standard as if the deliberate convolutions of
the system were an advantage rather than a serious drawback.
--
Phill Hallam-Baker
Tim Phipps
: 1) Online manual still designed with aim of minimizing disk space rather than
: providing information.
Not if your sys-admin runs catman 8-)
: 2) No help facility.
Since I read this in comp.sys.hp try vuehelp or the help button in a Motif
window.
: 3) No standardized user firendly shell.
Got me there, I don't recall Posix doing a freindly shell standard.
: 4) Command qualifiers hard coded into applications making multilanguage
: customization impossible.
Since when is "ps -dfla" or "cpio -paduvmx" language dependent?
: 5) Requires expensive expert to have a chance of any security.
Security is expensive. It starts with physical security ie big blokes
who don't smile, then you can have an expensive OS with good security or
Unix with an expensive security guru or DOS and take the disk home.
: 6) File system limited to sequential file, forcing applications to create their
: own file system on top of the UNIX one, thus preventing any standardization or
: application independent optimization.
(Snore) Try "man fseek".
: |> Like most modern languages, Unix has survived because it is
: |>...
: I disagree. It passed it's sell by date years ago.
So have I.
Phippo the Hippo.
Josh Osborne
>In article <BzIG5...@pix.com>, str...@pix.com (Josh Osborne) writes:
this isn't a good comp.arch topic...]
>But it is the paucity of software that prevents anything more novel than
>floating point accelerators for standard Von Neumann machines gaining wide
>acceptance.
You forget bitblt'ers, and line drawers.
[I am word wraping the following text...]
>If you want to discuss hardware, you cannot ignore the software aspect. Take
>the above for instance. In RMS the filestore offers high level functionality.
>In UNIX only low level functionality is offered. Now let us consider the
>difficulties of producing an intelligent filestore:
>
>VMS/RMS,
> Done years ago with the HSC. Nothing special about VMS here of course. ICL
>were offering intelligent filestores that could do sorting years ago.
>
>UNIX,
> Because the filestore knows only about the fopen, fseek, fread, fwrite and
>fclose operations it is easy to interface to any sequential device. However
>when the filestore receives an instruction it is only told *what* to do.
>There is no clue as to *why* to do it. In this circumstance it is very
>difficult to do any form of intelligent cacheing.
The we need a way for user level code to tell the OS what file info is
important to cache, and what isn't. Then you can be almost as efficent
as VMS/RMS (you will have extra context switch overhead for the extra
syscalls), but you will still be able to allow any user to create new
filetypes.
Keith Smith
>but was killed through over agressive attempts to control it. Imagine a world in
>which EBSIDIC, not ASCII was the standard for charaters. We would see people
EBCDIC maybe, what is EBSIDIC?
And, EBCDIC has some superior features to ASCII, Especially when
converting Zone Style (string) and Packed (BCD) numbers into printable
characters and back.
IBM shops have been using EBCDIC for 30 years. It *IS* a standard for
them, and the S/36 enviroment we use on our SCO UNIX box does everything
EBCDIC also. There are some interesting searching & sorting impacts
from using EBCDIC also.
>praising the merits of the EBSIDIC standard as if the deliberate convolutions of
>the system were an advantage rather than a serious drawback.
here is no SERIOUS drawback to EBCDIC. None, other than compatability
with ASCII systems. There are also some advantages with business
applications. EBCDIC was no "deliberate convolution", and when you look
at the BINARY representation of the codes *AND* the way numbers are
represented on the IBM style RPG/COBOL/... systems it begins to make
very good sense.
I grew up on ASCII and used EBCDIC later, and while I generally use
ASCII now whenever possible, this is more for portability reasons,
rather than because it is "BETTER" in any way. Be real.
--
Keith Smith uunet!ksmith!keith 5719 Archer Rd.
Digital Designs BBS 1-919-423-4216 Hope Mills, NC 28348-2201
Somewhere in the Styx of North Carolina ...
richard g. adair
>providing information.
The new CDROM programs have just what you want. HP's help browser
with the bookshelf idea make searching through manuals fun!
> 2) No help facility.
> 3) No standardized user firendly shell.
The best way to provide a help facility is to make sure users don't
need help very often, like on the Mac. The ballon help is really
nice for novice users, and you can turn it off when you are familiar
with the OS.
> 4) Command qualifiers hard coded into applications making multilanguage
>customization impossible.
Perhaps the .Xdefaults should be generalized for all UNIX commands??
Something like: ls*F: G would replace the F option in ls with a
G instead?
> 5) Requires expensive expert to have a chance of any security.
NO computer system is secure. PERIOD!
>6) File system limited to sequential file, forcing applications to create their
>own file system on top of the UNIX one, thus preventing any standardization or
>application independent optimization.
This is feature, not a bug! Have you ever worked with a record
oriented system like VMS? You spend most of you programming time
defeating the file system :-(
>The kernel is a major factor in determining how useful the system is. Only AT&T
>had the capability to introduce a shell to replace the standard ones that could
>have achieved a degree of acceptance.
All shells are the same, since they all share the same weird
restriction that the user know a specific language to converse with
them. VMS is more wordy, but none the less has specific commands
that you just have to know to survive. We should be more concerned
with what the new interface which will replace shells will look like.
>They had a limited problem and provided a limited solution. I find it hard to
>see how you can consider UNIX to be a superior system to VMS while admitting
>that it is inadequate for many tasks. It would appear to me that the strongest
>statement to be made would be that UNIX was superior for some tasks (presumably
>through simplicity).
No, UNIX is better for these reasons:
pipes
make
light sub-processes
the path
transparent networking
network file sharing
no RMS
choice of shells
machine independant, choice of vendor freedom
vendor price and speed wars
better hardware
graphics
it does't have DEC-this DEC-that all over (gak!)
simplicity
>If UNIX was ever allowed to become the sole O/S it would halt O/S deelopment
>completely. The only effort UNIX has ever made is in catching up.
UNIX is like English. If it sees a concept it likes, it takes it!
:-) There isn't anything wrong with this. UNIX is set up
flexibly so that you can add all sorts of new concepts easily as
software technology advances...
>There were other choices. PICK for instance was a very highly regarded system
>but was killed through over agressive attempts control it. Imagine a world in
>which EBSIDIC, not ASCII was the standard for charaters. We would see people
>the system were an advantage rather than a serious drawback.
PICK is not dead, it's being used to run the Tax rolls in Moscow!
Tony Burzio
Arete Associates
San Diego, CA
geze...@rlgsc.com
> In article <1992Dec19.0...@ll.mit.edu> ej...@ll.mit.edu (Eric Jones) writes:
>
>
>>But isn't that exactly his point? Sure you can write an ISAM file
>>structure using fseek (and if you're REALLY smart, you might even
>>write an efficient one), but then how's anyone else going to use
>>your files?
>
> By RTFM of course!!
Remember, while it is easy to implement a record management system, it is also
easy to create a record management system with bugs. Whether or
not you want to consider it, the RMS file formats and
implementations represent a choice in favor of STANDARDS, which
while they are specific to a particular vendor, are standard for
all conforming programs on the platform, something which is
certainly not true on platforms where everybody writes their own
ISAM implementation.
>
> Consider the converse:
>
> You write a file using the oddball formats of VMS.
>
> You send it to someone else.
>
> He can't read it because it's oddball.
>
> How does he read it??
sending files between systems, namely SEQUENTIAL, FLAT format.
Sending an ISAM type file to another site running a different
type of hardware/operating system is rather chauvanistic, and not
a good example.
> The only way is to RTFM and here the FM refers to the 1600 pounds
> of VMS stuff or Disk 47 of the 677 volume CD manuals.
>
remember correctly, less than 5). In any event, you can find the
information required to unload an indexed to a sequential file in
the online help text.
> The Unix way has proven to be the best way; its one of the biggest
> reasons VMS is a current sales disaster.
>
> The doc for your own ISAM is maybe 2 pages long.
>
better" is also two pages long, leading to thousands of pages of
documentation covering equivalent facilities with small
differences.
> Also consider this: if you write that file on VMS using the VMS
> proprietary method, you can't read it on any other machine using
> the same code. If you did it the C/Unix way, you code will run as-is
> on any machine using standard C. Even VMS.
>
Incorrect. The reason that you cannot read it with C is that C
has consistently ignored the standardization of IO interfaces. If
you used a language which included a standard for keyed record
access (e.g. COBOL((shudder..shudder)), you would be able to use
the same code on both machines/operatinig systems)
> Doug McDonald
--
- Bob
+--------------------------------------------------------------------------+
| Robert "Bob" Gezelter E-Mail: geze...@rlgsc.com |
| Robert Gezelter Software Consultant Voice: +1 718 463 1079 |
| 35-20 167th Street, Suite 215 Fax: (on Request) |
| Flushing, New York 11358-1731 |
| United States of America |
+--------------------------------------------------------------------------+
You never forget your first gale
>The Unix way has proven to be the best way; its one of the biggest
>reasons VMS is a current sales disaster.
Not true. Unix became popular because it was the software shipped with all
the newer faster workstation and server hardware. Beginning, middle and end of
story. This is obvious, it's not even worth contesting.
>Also consider this: if you write that file on VMS using the VMS
>proprietary method, you can't read it on any other machine using
>the same code. If you did it the C/Unix way, you code will run as-is
>on any machine using standard C. Even VMS.
Another red herring. It's because the 'standard' C runtime library on any
system is an emulation of the unix system. RMS emulations for unix are also
available which would allow the same interoperability for VMS native format
files.
Tom O'Toole - ecf_...@jhuvms.hcf.jhu.edu - JHUVMS system programmer
Homewood Computing Facilities, Johns Hopkins University, Balto. Md. 21218
>Here comes a jet ski.
>weuh weeuhh weeuhh weeuhh WEEUHH WEEUHH WEEUHH WEEUHH weeuhh weeuhh weeuhh weuh
peter da silva
> providing information.
Well, it's better than most systems which provide no online manual at all, or
provide one that requires some fancy hardware/software combination to use, and
can only be used from one seat at a time.
> 2) No help facility.
It's a fair cop, but in general I find I rarely use the help facility on VMS
unless I *can't* get to the offline manual and need to find an option. A help
facility is no replacement for a tutorial, and a tutorial and manual is more
useful than any of the three.
> 3) No standardized user firendly shell.
A fair cop, but there have been pretty nice front ends. I think that this will
show up in a matter of time as windows finally filter down to the commodity
market.
> 4) Command qualifiers hard coded into applications making multilanguage
> customization impossible.
I wouldn't want multilanguage customization of command qualifiers. Help
messages and error messages, yes, I'll go with that.
> 5) Requires expensive expert to have a chance of any security.
A fair cop, and I blame the vendors. It's not HARD to ship a system with
good default security. SCO claims to.
> 6) File system limited to sequential file, forcing applications to create
> their own file system on top of the UNIX one, thus preventing any
> standardization or application independent optimization.
On the other hand, there are some very strong traditions about file formats
and semantics that have proven extremely useful, and are one of the reasons
UNIX is so popular.
> The kernel is a major factor in determining how useful the system is. Only
> AT&T had the capability to introduce a shell to replace the standard ones
> that could have achieved a degree of acceptance.
Um, the kernel and shell are separate components. Which are you talking about?
> If UNIX was ever allowed to become the sole O/S it would halt O/S deelopment
> completely.
Actaully, UNIX has allowed a lot of OS research that would otherwise be
impossible. By providing a useful lowest comon denoinator interface people
have been able to spend more time on the operating system and less time
reinventing the wheel. The amount of variety "under the hood" of UNIX and
UNIX-like systems is incredible.
--
Peter da Silva `-_-'
Ferranti International Controls Corporation 'U`
Sugar Land, TX 77487-5012 USA
+1 713 274 5180 "Zure otsoa besarkatu al duzu gaur?"
peter da silva
> structure using fseek (and if you're REALLY smart, you might even
> write an efficient one), but then how's anyone else going to use
> your files?
Well, you have two choices:
1. You bind the ISAM interface into your application and
ship binaries. You don't document it, and hope that you
sell enough packages that you have a cpative market for
the next 10 years.
2. You document the ISAM interface, ship libraries or source
to the library, and provide shell commands to hook your
package into the rest of UNIX.
When Oracle does all three parts of (2) I'll quit badmouthing them.
geze...@rlgsc.com
> The we need a way for user level code to tell the OS what file info is
> important to cache, and what isn't. Then you can be almost as efficent
> as VMS/RMS (you will have extra context switch overhead for the extra
> syscalls), but you will still be able to allow any user to create new
> filetypes.
> --
> str...@pix.com "Security for Unix is like
> Josh_Osborne@Real_World,The Multitasking for MS-DOS"
> "The dyslexic porgramer" - Kevin Lockwood
> We all agree on the necessity of compromise. We just can't agree on
> when it's necessary to compromise. - Larry Wall
Josh,
Important point that you bring up tangentially in your post.
While VMS does provide RMS as an operating system service, there
is nothing which prevents you from "folling your own" type of
file structure. However, every program which wants to read from
your special file structure will have to be intimately familiar
with it. Programs which use RMS can process files which were
created using RMS with no problems.
A misnote about the HSC which appeared in this thread. The HSC
does not really know anything about the content of the disk
files. However, RMS will do things inside of the CPU, such as
maintain index caches on a system wide basis, which are a
signifigant performance improvement. One problem with rolling
yourself is that, invariably, the management and monitoring tools
and utilities are bare-bones.
Michael Paddon
>If I wanted to spend my time looking at centuries old technology I would be an
>archeologist.
However, to work in a vaccuum is to repeat old mistakes and forget hard
earned lessons. As the computer industry matures, more is accomplished
through evolution.
>Bugs they still need to fix:-
>
> 1) Online manual still designed with aim of minimizing disk space rather than
>providing information.
This one always amuses me. I've used VMS and it's printed manuals are far less
useful than Unix's, and they are not online. Yet the VMS example is held up
as a paragon. You are mistaking quantity for quality.
Example: try to use the VMS backup command in a way that isn't covered in
one of the examples in the manual.
> 2) No help facility.
The VMS help facility does not provide 10% of the information provided
by the the Unix online manuals.
> 3) No standardized user firendly shell.
Last time I looked POSIX had standardized at least one of the Unix shells.
You can move to any modern Unix, and be able to use your favorite shell.
In comparison, VMS provides DCL. A language with 60's control structures
(no for loops, while loops etc). No pipes. No command output substitution.
No globbing, so that's its done different by every command. God save us!
> 4) Command qualifiers hard coded into applications making multilanguage
>customization impossible.
This is not a drawback of Unix. The need is for appropriate mechanisms
to be standardised and made available. You can bet that when that happens,
the implementation will be much easier under Unix than VMS.
> 5) Requires expensive expert to have a chance of any security.
No more so than any other multiuser OS I've dealt with. However,
"Unix is insecure" is another one of those unsubstantiated myths.
Yes, early versions in loose environments (universities, etc.) were
insecure. However, VMS systems on campus were also notoriously easy
to break in to.
Modern Unix systems are as secure as any other mass market OS,
so long as the vendor or sysadm don't do anything stupid.
>6) File system limited to sequential file, forcing applications to create their
>own file system on top of the UNIX one, thus preventing any standardization or
>application independent optimization.
Let's look at a system with file types. List the file... Sorry you can't
do that with XYZ. Run may application on that data... Sorry don't know
how to access that file type.
This is real 1960's stuff.
>They had a limited problem and provided a limited solution. I find it hard to
>see how you can consider UNIX to be a superior system to VMS while admitting
>that it is inadequate for many tasks. It would appear to me that the strongest
>statement to be made would be that UNIX was superior for some tasks (presumably
>through simplicity).
After using both, I found that I produce code up to 10 times faster under
Unix. Which is superior?
>If UNIX was ever allowed to become the sole O/S it would halt O/S deelopment
>completely. The only effort UNIX has ever made is in catching up.
There should never be a sole OS. That way lies stagnation. However Unix
has broken ground in some extremely important areas; examples are easy to
find, for instance the BSD networking development.
The most important point, however, is that Unix is *not* perfect. The
problem with commercialization is that is becomes harder and harder to
throw away old ideas, because code must be supported.
So Unix grows crusty with age, and thereby creates room for a newcomer.
What will it be? That's the real question.
Michael
Thomas Sippel - Dau
- |>(Snore) Try "man fseek".
- But isn't that exactly his point? Sure you can write an ISAM file
- structure using fseek (and if you're REALLY smart, you might even
- write an efficient one), but then how's anyone else going to use
- your files?
Well, on IRIX from Silicon Graphics (not exactly a company known for its
database prowess ..) there is an ISAM library that comes with the fortran
compiler. Admittedly you have to look for it, the first I noticed of it
was the recommendation to add -noisam to the fortran compile statement
to reduce the size of compiled programs - shows you the vast market for
isam.
Thomas Sippel - Dau
- But it is the paucity of software that prevents anything more novel than
- floating point accelerators for standard Von Neumann machines gaining wide
- acceptance.
-
- If you want to discuss hardware, you cannot ignore the software aspect.
....
And unfortunately that goes very deep and does certainly not stop at the
operating system. Once you deart from a von-Neuman architecture, many
respected truths are no longer applicable. Take the well-known suggestion
that a binary chop is the fastest way to serch an ordered list. If you have
two processors (and a few more performance parameters ...) you will find
the fastest search splits the population at the 62/38 % rather than at 50/50.
Once you design hardware that requires people to redefine and rethink
their problems before they can use of it you have some selling to do.
Robin Fairbairns
Paddon) writes (in a rather tetchy, but pretty well-informed post):
|> [...]
|> > 3) No standardized user firendly shell.
|>
|> Last time I looked POSIX had standardized at least one of the Unix shells.
|> You can move to any modern Unix, and be able to use your favorite shell.
|>
|> In comparison, VMS provides DCL. A language with 60's control structures
|> (no for loops, while loops etc). No pipes. No command output substitution.
True, all true. VMS enthusiast though I am, I have to agree here.
|> No globbing, so that's its done different by every command. God save us!
Indeed no globbing (in the Un*x sense). RMS (or is it the underlying
ACP? - I don't have direct access to VMS systems any more, boo hoo)
provide wildcard searching to every application. An application that
rolls its own is distinctly out of order here...
There are advantages to the Un*x globbing mechanism, but on the whole
I prefer the VMS way.
|> [...]
|>
|> After using both, I found that I produce code up to 10 times faster under
|> Unix. Which is superior?
Depends what you want it for. For me now, using a Un*x platform to
support research into other OSs is fine. In my previous job,
developing applications to _sell_, I appreciated what I perceived as
the solid base that VMS offered.
|> >If UNIX was ever allowed to become the sole O/S it would halt O/S deelopment
|> >completely. The only effort UNIX has ever made is in catching up.
|>
|> There should never be a sole OS. That way lies stagnation. However Unix
|> has broken ground in some extremely important areas; examples are easy to
|> find, for instance the BSD networking development.
|>
|> The most important point, however, is that Unix is *not* perfect. The
|> problem with commercialization is that is becomes harder and harder to
|> throw away old ideas, because code must be supported.
|>
|> So Unix grows crusty with age, and thereby creates room for a newcomer.
|> What will it be? That's the real question.
If anyone comes up with the real answer any time soon, let me know...
--
Robin (Campaign for Real Radio 3) Fairbairns r...@cl.cam.ac.uk
U of Cambridge Computer Lab, Pembroke St, Cambridge CB2 3QG, UK
"They had twelve years to lay in wait for us" - Bush supporter on Nov 4
M Darrin Chaney
>In article <BzKGK...@pix.com>, str...@pix.com (Josh Osborne) writes:
>> The we need a way for user level code to tell the OS what file info is
>> important to cache, and what isn't. Then you can be almost as efficent
>> as VMS/RMS (you will have extra context switch overhead for the extra
>> syscalls), but you will still be able to allow any user to create new
>> filetypes.
>--
>
>Important point that you bring up tangentially in your post.
>While VMS does provide RMS as an operating system service, there
>is nothing which prevents you from "folling your own" type of
>file structure. However, every program which wants to read from
>your special file structure will have to be intimately familiar
>with it. Programs which use RMS can process files which were
>created using RMS with no problems.
>
>A misnote about the HSC which appeared in this thread. The HSC
>does not really know anything about the content of the disk
>files. However, RMS will do things inside of the CPU, such as
>maintain index caches on a system wide basis, which are a
>signifigant performance improvement. One problem with rolling
>yourself is that, invariably, the management and monitoring tools
>and utilities are bare-bones.
>
>- Bob
Actually, I've seen alot of people here call RMS "the file system." For those
of you who still think that RMS is the file system, I'll clue you in: RMS
is not the file system.
Let's think of what RMS stands for: "Record Management Services." Hmm, sounds
more like a record manager than a file system, doesn't it though.
The file system is accessed via QIO calls, and knows nothing about file
formats. All it knows about is disks and files, files via file ids. It is
actually easy to open a file by id and read virtual blocks from it. If you
want to roll your own Unix functions (fread and fwrite), this is the way
to do it. It might be a little faster, and you needn't worry about RMS.
For stream-lf files, just buffer those blocks, and keep track of where the
lf is. It's not difficult, and you can easily get around the 65534 limit
that RMS places on files. Have fun...
Darrin
--
mdchaney@iubacs mdch...@bronze.ucs.indiana.edu mdch...@rose.ucs.indiana.edu
"I want- I need- to live, to see it all..."