RE: [MLUG] what is IBM's linux?

[Michael <EMAIL:PROTECTED>]

> Inst gives you a nice, scriptable shell that actually works.  You can
> update hundreds of packages at a time, and resolve all your conflicts
> before a single package gets installed.  Trust me, inst is way better.
> Ask any of the other IRIX admin types here.

Umm I do that with RPM. I have plenty of problems with RPM but that dosn't
sound like one of them. Unless I'm misunderstanding you.

> > I don't understand what you mean by the kernel internals? Could you
> > explain in more detail?
>
> Not if I value being employed.

In this job market playing it safe is probably a good idea. :)

> > I don't know if I can see a point in supporting massive numbers of
> > processors in a single system. Server clusters seem to me to be more
> > scalable, cleaner to support, and the way things are headed. They seem to
> > be working on that portion of Linux anyway and I know you can configure it
> > for big server support but I really don't see it being all that important.
>
> Right.  It depends on what you do.  If your code breaks up into nice, little
> chunks, then it's great.  NFS, HTTP, DNS, etc, are all like this, too.  The
> only advantage a big box would have is more CPUS to handle all your i/o
> interrupts.  Or, to be more pertinent to the target market, if you do
> optimization for molecular structures and each node has its own small, finite
> dataset and you're primarly CPU bound rather than memory bound,  and your
> individual processess don't have to share data or memory, then a cluster is
> great.  If you have an infinite amount of time to optimize your code to run
> that way, it's good, too.  Note that "infinite amount of time" clause.
> I'd like to state that NOT EVERYTHING WORKS WELL ON A CLUSTER!  If you have
> a lot of free man hours (like physics graduate students), then it makes more
> sense than if you run a national lab or a manufacturing company that
> actually has to pay its employees.
>
> Large single system image machines are good for people who do things like
> weather simulations, computational fluid dynamics (think virtual, real-time
> wind tunnels), or, in this case, too, anyone that requires *huge* amounts
> of i/o.  They're also a better general purpose compute intensive solution
> than clusters.  Notice I said general purpose.  Sometimes clusters will
> be cheaper--that's why people make them.  But they're very, very far from
> the end-all be-all of computing.  Grand challenge computing problems
> require the sorts of machines that SGI builds.  Why else would Fleet
> Numeric Ocenographic (weather prediction), Nasa Ames (virtual wind tunnel,
> CFD), Nasa Goddard (weather prediction), and various and sundry other
> large customers buy 512p Origin 3000s?

I'm not quite sure I see your point. Isn't the problem more that most
clusters use ethernet to connect each node and ethernet is pretty slow? If
you used a faster data pathway wouldn't clusters be just as good for those
other tasks? I'd think support for more devices etc would be improved as
you can connect an infinite number of devices just by plugging in more
cluster nodes. Unless you have a single device that needs a huge list of
IO's which to me would suggest poor design. Memory could be somewhat of a
hassle to split between cluster nodes but if I remember right things like
MOSIX remap the normal memory operations to a clustered version so the
original code doesn't need to be rewritten. I've been limited to testing
on very small clusters though so maybe something about that design sucks?
--
To unsubscribe, go to http://mlug.missouri.edu/members/edit.php

Archives are available at http://mlug.missouri.edu/list-archives/