× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Well, now that Joe has hit his limit and won't be responding I can let
loose the dogs of war :^)  (that's a joke - I'm not flaming, and I don't
want to incite any rancorous posts - by me or others)

On Wed, 25 Jun 2003, Joe Pluta wrote:

> > From: James Rich
> >
> > Max. File Size
> >     Designed to scale to 9 million TB with current hardware supporting
> > scalability to 8000 TB on IRIX.  Linux-64, 2 TB Max File Size.
>
> Gz.  Now you're quoting design specs.  How low can you stoop?

I'm "stooping" to give you what you asked for.  In another post you asked
if the <some big number of bytes> was all on one system or offline
storage.  I stated above what IRIX can do.  I showed (with evidence) one
example of an OS with massive abilities.  I even gave references so they
could be independantly verified, hoping to avoid FUD and speak directly to
the truth.  I'm not interested in unverified accounts of what systems can
do, and neither are you.  I am interested (very interested) in
comparisons of systems based on documented abilities.

> > Cough cough.
>
> What was the cough for?  We regularly had clients with item history files
> with tens of millions of records in BPCS.  That's GB.  And this was back in
> the 80's and 90's.

The cough was a response to your statement "Lies, damned lies and
statistics", which followed your statement "On the other hand, I know for
a fact you can have files of multiple gigabytes on the iSeries, and up to
144GB on one machine."  The cough was meant to spur introspective thought
on the irony that "Lies, damned lies and statistics" followed your own
statistic.  Also, the statement capabilities I mentioned far exceeded all
the big filesystem claims made so far.  "files of multiple gigabytes on
the iSeries, and up to 144GB on one machine" just isn't very big.

If the ability to have extremely large files and file systems is a
requirement, then there are machines who do that very well and then some.
IOW, as compared to some, the filesystems abilities of OS/400 is not a
particular advantage.  Nevertheless, it is still a strength.

> > Interestingly there may be some substance to the idea that MS products can
> > do big work.  In the Top 500 Supercomputers list at
> > http://www.top500.org/list/2003/06/ what appears to be a windows machine
> > is listed 50th.
>
> This is LDLS (lies, damned lies and statistics).  These are scientific
> machines measured in GFlops, a completely irrelevant number for standard
> business applications.

Not completely irrelevant.  If we suppose that a requirement for a
business is that it can complete a given unit of work in a given amount of
time, then this list shows computers that may meet that requirement.  More
useful, though is that this list shows computers with large capabilities -
capabilities which may be useful.

But the list was not included to suggest that businesses (or anyone else -
I don't care if you are a business or not) need supercomputers to
function.  Rather it was included to show systems with large capabilities.
Sort of a response to the statement, "YOU'RE the one playing catch up,
YOU'RE the one who has to supply the proof."  Here is proof of systems
with large capabilities - even larger than those of OS/400.

> > Even so, I can't imagine any MS product being stable or reliable or
> > needed.  But Joe is right, you do need to look at the whole package.
> > These examples show that there are points where other OSes mop the floor
> > with OS/400.  But is that true all around?  Well that's up to you, the
> > gentle reader, to decide.  For me, sometimes it is and sometimes it isn't.
>
> More LDLS.  "Mop the floor with"?  A 1984 Ford Pinto mops all of those
> operating systems when it comes to getting on the freeway.  Which has
> exactly the same relation to the original conversation.
>
> We're talking about reliability for business applications.  This list is
> almost entirely irrelevant, just like most of the other arguments that are
> constantly put forward here.  When I used the term FUD on RPG400-L, it was
> in a large part in repsonse to senseless discussions like this.  They sound
> like they mean something, but in the end they're just empty numbers.

Actually we were talking about reliability, not necessarily reliability
for business applications.  The top 500 list therefore isn't completely
irrelevant since it requires some measure of reliability to build a
supercomputer.  But again, the list wasn't included to suggest that only
machines on it are any good and all others are bad.

These aren't empty numbers.  They provide ways to compare and contrast
different systems.  The phrase "lies, damn lies, and statistics" grows
from the interpretation of numbers to support an argument.  It is not
necessarily the statistics themselves that lie (though polls, questions,
surveys, etc. can be rigged to increase the likelihood of a desired
result).  Fortunately I'm not interpreting anything, just providing
pointers the numbers themselves.  It is up to the reader to decide if they
support a given argument.  It appears that for you, Joe, any numbers that
don't support your argument are automatically meaningless and empty, yet
are the gospel truth when applied in favor of your viewpoint.

Let me restate that I am very interested in comparisons of different
systems.  Not based on tall tales, but on documented data.  There may not
be much useful data out there on which to make a good comparison, but I
don't want to reject out of hand what little there is.

James Rich

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.