local and remote cpu resources and the acme model of interaction

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

One of acme's failings is that it tends to concentrate the computing on
a single machine again.  At the cost of some broken symmetries, one can
create a window within acme, connect it to another machine, and run
commands there.  This is clearly inferior to having big things run remotely
automatically.  In fact, I usually run acme on the cpu server, which has the
(weaker) problem that mouse motion and so on is communicated across
the wire.  Even on an ISDN line, however, the responsiveness is still better
than, say, running an X terminal and sam over the same wire.

The real answer lies in further research.  We've started exploring the
possibilities of more fine-grained distributatibilty, which would enable
acme to have remote processes available, transparently, that could
invoke all commands for it, yet keep all the symmetries.  Absent that,
another possibility is a more ad hoc solution of starting explicit slaves
across the network and communicating with them directly.  I've put
that off in favor of, I hope, more help from the system itself.

All that said, I still use acme exclusively.  It's not perfect and it's hard
to learn because its rules are so different from the usual conventions,
but the investment in learning is repaid.

-rob