Re: [9fans] Remote access

[Lucio De Re <lucio@proxima.alt.za>]

On Mon, Aug 21, 2000 at 09:00:10AM +0000, Chris Drelich wrote:
> 
> 1) What are ways for plan9 to be accessed remotely, specificly by machines that
> do not run Plan9?  Can one telnet or ssh into a plan9 system from a
> unix/windows/mac system?
> 
I find drawterm awesome.  You'll have to read about it and try it, but
you can take my word for it that the concept is very, very good.  The
implementation is flawed in almost clownish ways, although it is very
stable (what I mean is that when something does go wrong, I find the
behaviour quite amusing: under Linux/KDE, for example, it seems to
cause arbitrary sessions to close; I can't quite put my finger on it
because I have too many sessions active :-(  Drawterm itself seems
either to freeze or continue unperturbed.

> 2) I understand that the OS uses RIO.  If one was to say ssh into a plan9
> system, could one use the system without RIO?  I understand that a lot of
> applications would not work without RIO.  However, for minimum remote access
> from a non-plan9 machine, a few applications could be compiled with APE for use
> only from this form of remote access.
> 
Telnet works, but lack of cursor addressing in typescripts means that
many of the fundamental applications are inaccessible, not unlike
windows, I guess.  There's enough Unix in there to manage the remote
host, but it is a tight fit.  Ssh and remote execution are possible,
in fact fundamental to Plan 9's distributed processing model.  But
drawterm again obviates this drawback quite successfully.

> 3) If it is impossible to ssh or telnet into a plan9 system from a non-plan9
> system, how much work would it take to make this possible?  Would anyone else
> be interested in this?
> 
It is contrary to the Plan 9 philosophy to add cursor addressing to
typescript terminals.  I guess it could be done, but the gain would be
far smaller than the effort required; there are naturally better ways.
And the Plan 9 philosophy tends towards providing the presentation on
the client workstation, so your approach is really a reversal of this
philosophy; you'd be swimming against the tide.

On the other hand, compute intensive tasks with simple interfaces are
very readily adapted to remote execution on compute servers.

++L