Re: [9fans] heterogeneous cpu servers?

Re: [9fans] heterogeneous cpu servers?

[Richard Miller]

> Instead, it sounds like all you need to do is run
> ssh or telnet or con in an acme win to connect to
> your Unix box and run javac in that window...
>
> Combine that with running u9fs and you should be
> all set...

Other variations include using rx(1) to send individual
commands to the Unix system, and nfsserver(8) to allow
the Unix system to see your Plan 9 files.

-- Richard Miller

Re: [9fans] heterogeneous cpu servers?

[please_no_spam_to_]

Vincent D Murphy (murphyv@student.cs.ucc.ie) wrote:
: can a NT, linux, or solaris box 'be' a plan9 cpu server?  i fear not;
: if this is the case, does anybody have an idea what would need to be
: done to make it happen?

: rationale: i have to develop java at work -- my duties dictate it.
: however i have found that i am far more productive working in plan9/acme,
: and now i want to use it for java, perl and oracle development work.
: maybe i could even win over a few converts among my co-workers.  :)

Possible alternative: *some* of the Plan9 tools have been ported to **IX.
In particular "wily" is a X/UNIX port of acme - even the chording works.
See: http://www.cs.yorku.ca/~oz/wily/

-- 
	David Pick

Re: [9fans] heterogeneous cpu servers?

[Russ Cox]

There's not a lot to say about cpu.  The best 
explanation of what's going on is section 5 of the
manual (the 9P descriptions).  Clients connect
to cpu servers and after an initial handshake
the clients turn into 9P servers, serving the
terminal's entire namespace.  The cpu server
then mounts this service on /mnt/term, binds 
/mnt/term/dev/cons* into /dev, and then executes
a shell with input/output redirected to/from /dev/cons.

Two years ago I wrote such a server for Unix.
It had a user-level implementation of a 9P mux,
it "mounted" the client connection in memory, connected fd 0,1,2
to pipes to processes ferrying the appropriate data to/from
/dev/cons, and exec'ed a shell.  It was neat but
not useful, since it did nothing more than ssh does.

Instead, it sounds like all you need to do is run
ssh or telnet or con in an acme win to connect to
your Unix box and run javac in that window.  It's
not as elegant as the native setup, but it's mostly
what you'd have with a cpu-style connection.

Combine that with running u9fs and you should be
all set.  If you don't want to run u9fs as an
rhosts-style daemon (e.g., you're not behind a 
firewall), I have some diffs to u9fs that let you
run a personal one within an ssh session.

I did some jini development using such a setup
last spring and it was quite pleasant.  I think
that the java compiler already outputs plumbable
error messages.

Russ

[9fans] heterogeneous cpu servers?

[Vincent D Murphy]

can a NT, linux, or solaris box 'be' a plan9 cpu server?  i fear not;
if this is the case, does anybody have an idea what would need to be
done to make it happen?

rationale: i have to develop java at work -- my duties dictate it.
however i have found that i am far more productive working in plan9/acme,
and now i want to use it for java, perl and oracle development work.
maybe i could even win over a few converts among my co-workers.  :)

to do this, i need to access tools on other hosts, running operating
systems which are better supported than plan9 by the developers of
those tools.  hopefully it is possible to do this as transparently as
possible, through creating a distributed development environment.

for example, it would be nice to run 'java/javac foo' or similar on my
plan9 terminal, and have javac run on a solaris box, with the obvious
multiplexing of /dev/cons and friends taken care of.  then i could
process the stderr output of the compiler such that it is acme-friendly.

needless to say, such a capability would be immensely useful for
distributed systems in general, rather that just 'hacking foo with acme'.

i have looked at cpu.c, but i remain in the dark as to how plan9 cpu
servers work from having read the source.  any pointers to further
(prosey) info, apart from cpu(1)?