Quote:> The reference you're referring to basically implies that you launch
> processes on multiple nodes sitting at your desk. rsh is (Very loose
> comparisson here, dont flame me please) for this purpose, the equivalent
> opening an xterm on your workstation, telnetting to a node, and firing up
> that 6 hour compile. Then minimizing the xterm, openning a new one, and
> doing the same for that other app you want to do (telnetted to another
> this time).
Do you mean that rsh a) only runs with xterm, b) cannot be automated?
Quote:> Basically, instead of the cluster chosing the location of each
> process, you do it yourself.
If this is ONLY possible manually, then that would be unsuitable. If,
however, this can be automated, this is PRECISELY the level of control I
want. Especially if remote processes can be monitored visually on a
Why? Because I want to REMOTELY manage node power-on/off, perform
load-balancing, manage data redundancy and no/low-fault computation, perform
diagnostics, dedicate certain nodes to special tasks at times. In short,
having tentatively examined the option, I do NOT want what is essentially a
32 or 64-CPU computer laced together with LAN.
Quote:> Whereas beowulf is sometimes called the
> poor-man's cluster, this would be the broke-man's cluster. *shrug* I guess
> all of my linux servers are in a cluster since I have xterms to all of
> open running processes.
:-) What an amazing world... where a person with a group of connected
PERSONAL computers at his fingertips-- a billion dollars of computing power
only five decades ago-- speaks (however impishly) in terms of poverty.
Yes, in a sense this IS a cluster, with YOU as the executive program. Now,
if you cannot be replaced with a computer program, or if any automated
implementation is inherently slow as molasses, then it would be a poor
In a nutshell: From a central system I want to programmatically launch apps
on computers connected by LAN. (I am willing to run a process, hopefully a
small one, on each node to facilitate communication.) I want to do this
with the simplest arrangement possible even if there is some speed
trade-off, and the shortest learning and development period.
A "script" language would be OK, especially for prototyping. Will consider
Java (despite my negative impressions of Win98 implementations and apps),
C++ or whatever, but need to keep deployment time at a minimum. Important
to get something working quickly, then hang features on it later.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----