Set User (aka su)

[rob@plan9.att.com rob@plan9.att.com]

>hp takes 100+ Kb to implement something which could be
>done in fifty bytes of code in 81/2, scrolls awfully slowly
>and does not handle resizing properly.

>I.e. not implementing a display instead of a typewriter in
>81/2 simply moved the complexity to other place (hp) and
>made user interface incoherent (can't call sam in the same
>window as telnet!)

The point was to try new ways of working, not reproduce the old ways.
I left cursor addressing out on purpose: what Plan 9 offers is a different
way to edit, both local and remote.  No, you can't run sam on a telnet
window but you can run it in a cpu window, and we prefer that way of
working.  Even when connected to unix, sam -r unixmachine works
fine.  Sure, that doesn't work in a telnet window, but that's a minor point.
Putting cursor addressing in 8½ would make it too easy to fall back
to the old style of interaction, obscuring the new ideas.

All your carping is really about Plan 9's interface incompatibilities with
Unix.  If it's that important to you to use Unix, go use it.  Plan 9 is
a statement about its own environment, not about how to connect to
Unix using telnet.  Putting the kind of support you want into Plan 9
compromises the ideas in the system itself.  We oppose that.

If you decide that things need to be compatible with all that's gone
before, you end up on the road Unix is on.  You'll get something like
Spring or Mach, which are really just reengineerings of the Unix
interface.  An O.S. is only as good as its view of the system.  Plan 9
provides a different view, and its tools take advantage of those
differences.  You could port emacs or whatever other tool you
feel is missing, but why bother?  You already have it where you
work now.  If you want to see what Plan 9 is about, try it as it is.
The true test is not how easily you can reproduce what Plan 9
is trying to replace; rather it's how the new environment makes
new things possible.

-rob