[9fans] Remote access

[9fans] Remote access

[Chris Drelich]

Alright.  Let me start by saying this, I know plan9 is not unix, I don't want
it to be unix.  Now on with my questions.

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?

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.

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?

Chris

Re: [9fans] Remote access

[Lucio De Re]

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

Re: [9fans] Remote access

[Douglas A. Gwyn]

Lucio De Re wrote:
> drawterm again obviates this drawback quite successfully.

I urge that people keep in mind the fact that some computer users
are blind and *need* a text-oriented user interface instead of a
graphical user interface.  That doesn't mean dragging everyone
down to a common denominator, but it does mean not *unnecessarily*
forcing graphics upon an application.  Quite a few apps can be
designed as two processes: a GUI controller and a text-driven
computational engine.  There are other reasons for preferring
such a design, but it's also a very good compromise between the
needs of the blind and the desired of the sighted.

Thanks for listening.

Re: [9fans] Remote access

[forsyth]

>>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.

try

man 1 vt

(then telnet from within vt)

Re: [9fans] Remote access

[Lucio De Re]

On Mon, Aug 21, 2000 at 10:52:14AM +0000, forsyth@caldo.demon.co.uk wrote:
> 
> try
> 
> man 1 vt
> 
> (then telnet from within vt)

Nah, vt is broken :-)  Even vt -2.  It is adequate but not for curses
intensive operations, it doesn't delete lines in the bottom half of
the screen properly and doesn't clear to end of line either.

Of course, I should have fixed it long ago, but I stand by my
opinion that the effort is far greater than the gain.  There's no
guarantee that _I_ can fix it, either.

And the request was for operating the other way, like, how do you read
man pages without Rio?

++L

Re: [9fans] Remote access

[Lucio De Re]

On Mon, Aug 21, 2000 at 01:25:16PM +0200, Lucio De Re wrote:
> 
> Nah, vt is broken :-)  Even vt -2.  It is adequate but not for curses
> intensive operations, it doesn't delete lines in the bottom half of
> the screen properly and doesn't clear to end of line either.
> 
I didn't mean to sound ungrateful, by the way.  Vt has improved
dramatically between 2ed and 3ed, but mutt and vi on my NetBSD box
have a real bad time of it.  Good enough out of necessity, but I'm
hoping vncviewer will be much better.

++L

Re: [9fans] Remote access

[Douglas A. Gwyn]

Lucio De Re wrote:
> ... mutt and vi on my NetBSD box have a real bad time of it.

That might not be the fault of "vt".  Check that the TERM env. var.
and termcap/terminfo entry for that TERM are accurate.  Most "vt100"
termcap descriptions I've encountered over the decades have been
incorrect.  In any case, you might benefit from a termcap entry
that describes precisely the emulated "vt" terminal instead of a
true DEC VT-100.

Re: [9fans] Remote access

[Boyd Roberts]

i just don't see the point of cursor addressed stuff.

plan 9 should not be poisoned by curses (sic).

Re: [9fans] Remote access

[Wladimir Mutel]

Lucio De Re <lucio@proxima.alt.za> wrote:

> And the request was for operating the other way, like, how do you read
> man pages without Rio?

	To add, is it possible to start 'acme' instead of 'rio' on terminal
	bootup ? Or 'acme' needs to be started in 'rio' window only ?

--
mwg@alkar.net

Re: [9fans] Remote access

[Doug Henderson]

I have a fixed version of vt close to release status. The results from an
old version of vttest suggest that it will be adequate for running unix
sessions as a vt100, with a few limitations.

I hope to be able to release a patch for vt to correct some of the more
blatant errors in the vt100 protocol handler. My version has too many
changes to be considered a patch.

----- Original Message -----
From: "Lucio De Re" <lucio@proxima.alt.za>
To: <9fans@cse.psu.edu>
Sent: Monday, August 21, 2000 5:25 AM
Subject: Re: [9fans] Remote access


> On Mon, Aug 21, 2000 at 10:52:14AM +0000, forsyth@caldo.demon.co.uk wrote:
> >
> > try
> >
> > man 1 vt
> >
> > (then telnet from within vt)
>
> Nah, vt is broken :-)  Even vt -2.  It is adequate but not for curses
> intensive operations, it doesn't delete lines in the bottom half of
> the screen properly and doesn't clear to end of line either.
>
> Of course, I should have fixed it long ago, but I stand by my
> opinion that the effort is far greater than the gain.  There's no
> guarantee that _I_ can fix it, either.
>
> And the request was for operating the other way, like, how do you read
> man pages without Rio?
>
> ++L
>

Re: [9fans] Remote access

[rob pike]

	To add, is it possible to start 'acme' instead of 'rio' on terminal
	bootup ? Or 'acme' needs to be started in 'rio' window only ?

You can run acme without first starting rio.  Or sam or anything else.
Rio's windows present a simulation of the underlying system, and
programs run as well on the real thing as on the simulation.

-rob

Re: [9fans] Remote access

[Anthony Sorace]

//you might benefit from a termcap entry
//that describes precisely the emulated "vt" terminal

while i've had pretty good luck running vt, i have run into
several problems, especially as more and more *nix progrmers
forget about people on dumb terminals, or just about any
terminal dumber than what they're using, usually xterm. so...
do you (or anyone else) have such a termcap entry?
: anothy;

Re: [9fans] Remote access

[Russ Cox]

when you have to deal with the rest of the
world, it's sometimes not effective to sit
in a corner and chant "TERM=dumb".

as much as i am opposed to cursor addressing,
i use a fair number of legacy applications
through vt (for example, library catalogs
and various network management stuff).
these interfaces are orders of magnitude
better than the web replacements that are
appearing.  "constrained" to just text, the
authors had to worry about making it usable.
with the web, now they worry (only, i fear)
about making it pretty.

if you have fixes that make it better handle
missing or incorrectly implemented control
sequences, send them to me and i'll put them in.

russ

Re: [9fans] Remote access

[Douglas A. Gwyn]

Russ Cox wrote:
> when you have to deal with the rest of the
> world, it's sometimes not effective to sit
> in a corner and chant "TERM=dumb".

Judging by the tenor of Boyd's comments on such matters,
it appears that he wants Plan 9 to be (remain?) a pure
work of art, unsullied by practical considerations.
I don't say that's wrong, but I do say that one needs
to identify what the goals of the software are.
It should be possible to isolate interface "ugliness"
into modules that are entirely separate from the
artistic portions of the system.

Re: [9fans] Remote access

[Boyd Roberts]

----- Original Message ----- 
From: Douglas A. Gwyn <gwyn@arl.army.mil>
To: <9fans@cse.psu.edu>
Sent: Tuesday, August 22, 2000 10:40 AM
Subject: Re: [9fans] Remote access


> 
> Judging by the tenor of Boyd's comments on such matters,
> it appears that he wants Plan 9 to be (remain?) a pure
> work of art, unsullied by practical considerations.
> I don't say that's wrong, but I do say that one needs
> to identify what the goals of the software are.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> It should be possible to isolate interface "ugliness"
> into modules that are entirely separate from the
> artistic portions of the system.

excellent analysis.  i'm not opposed to adding in 3rd
party stuff, but look what happened to linux; kitchen
sink syndrome.

Re: [9fans] Remote access

[Boyd Roberts]

From: Douglas A. Gwyn <gwyn@arl.army.mil>
To: <9fans@cse.psu.edu>
Sent: Tuesday, August 22, 2000 10:40 AM
Subject: Re: [9fans] Remote access

> Judging by the tenor of Boyd's comments on such matters,
> it appears that he wants Plan 9 to be (remain?) a pure
> work of art, unsullied by practical considerations.
> I don't say that's wrong, but I do say that one needs
> to identify what the goals of the software are.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> It should be possible to isolate interface "ugliness"
> into modules that are entirely separate from the
> artistic portions of the system.

excellent analysis.  i'm not opposed to adding in 3rd
party stuff, but look what happened to linux; kitchen
sink syndrome.

Re: [9fans] Remote access

[Boyd Roberts]

From: Douglas A. Gwyn <gwyn@arl.army.mil>
To: <9fans@cse.psu.edu>
Sent: Tuesday, August 22, 2000 10:40 AM
Subject: Re: [9fans] Remote access

> Judging by the tenor of Boyd's comments on such matters,
> it appears that he wants Plan 9 to be (remain?) a pure
> work of art, unsullied by practical considerations.
> I don't say that's wrong, but I do say that one needs
> to identify what the goals of the software are.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> It should be possible to isolate interface "ugliness"
> into modules that are entirely separate from the
> artistic portions of the system.

excellent analysis.  i'm not opposed to adding in 3rd
party stuff, but look what happened to linux; kitchen
sink syndrome.

Re: [9fans] Remote access

[Nigel Roles]

Absolutely.

I particularly hate that gungy stuff which accumulates
in the plug hole.

> 
> excellent analysis.  i'm not opposed to adding in 3rd
> party stuff, but look what happened to linux; kitchen
> sink syndrome.
> 
> 
>