[info] [croquet-user] chromium ala Howard Stearns

[Eugen Leitl]

----- Forwarded message from Kyle Hamilton <aerowolf at gmail.com> -----

From: Kyle Hamilton <aerowolf at gmail.com>
Date: Mon, 30 Apr 2007 11:29:23 -0700
To: croquet-user at duke.edu, Paul Sheldon <psheldon at flash.net>
Subject: Re: [croquet-user] chromium ala Howard Stearns
Reply-To: croquet-user at duke.edu, Kyle Hamilton <aerowolf at gmail.com>

On 4/29/07, Paul Sheldon <psheldon at flash.net> wrote:
>> I'm not really following how a Chromium app would work. It might work
>> as a sort of "better VNC". It could be that the Chromium app is
>> running on a single bottleneck server, but that instead of sending
>> damaged rectangles back across the wire, it sends drawing instructions.
>
>I wondered at the term bottleneck server .
>
>But, remembering Vivarium, I might like little tiny (poor?) children of
>Palo Alto to play with supercomputers because the commercial markets
>might not have so much imagination or might (I read a free book sent me
>by Smarr and Kaufman on commercial uses of supercomputers). Distributed
>processing, however, is supercomputing . Collectively, with distributed
>processing, poor people could own a supercomputer .

Supercomputing means a lot of things to a lot of people.  My personal
take on it is that it is any situation where several computers are all
programmed to perform portions of a much larger calculation.

Croquet is not 'supercomputing' under this view.  Croquet is
'distributed processing' -- rather than have a single server that
performs all the calculations and then distributes the results of
those calculations, Croquet distributes the data to perform the
calculations and the calculations to be performed.  This allows each
participant in the world to calculate the simulation state
independently.

>> I'll define my terms:
>>
>> REMOTE APPS: At one extreme of an external app, we have a bunch of
>> replicated VNC clients communicating with a shared session on a VNC
>> server. It works. On the one hand, doing this on panels within Croquet
>> provides a lot of context and gives external apps some (but not all)
>> of the benefits of Croquet.
>
>Does that mean that my poor construction worker family will have to get
>four computers to not fight over who uses croquet? I think you are
>pushing for distributed processing rather than having the children share
>a cpu .  We might imagine distributed graphics processing would be cheap
>with the cheap graphics cards mentioned this list .

You're rather missing the point here.

VNC is a means of transporting the framebuffer output of a session --
be that session an X server, a Windows desktop, a MacOS desktop, or
anything else.  It has the ability to transport this framebuffer to
multiple locations, and all of them can share it.  However, the
processing that creates this framebuffer must put its output in a
single place -- the 'host' of the framebuffer.  (Multiple X clients
from multiple machines can output to a single Xvnc session, but that's
only because of the X protocol.)  VNC doesn't lend itself to taking
the applications that output to it and letting them run across the
multiple VNC client machines ('application sharing').

>> On the other hand, there's some extra memory copying and so it might
>> be slightly slower in principle than a stand-alone 2D VNC client.
>
>I think we're fumbling around studying candidate network architectures
>for candidate management of creative people. I am trying to write a
>piece about "the angst of Penny at Stanford against the Stanford-Binet
>IQ test". She wanted to study learning and teaching candidate strategies
>rather than have children be the candidate study.

Actually, we're looking at the History -- those that do not learn from
history are doomed to repeat it.  We're looking at the characteristics
of what's happened before, and trying to figure out what
characteristics are good versus what characteristics should be left by
the wayside.

>> I don't know if that matters in the grand scheme of things. (The
>> current KAT implementation is certainly slower.) The current
>> architecture is also going to be one round trip slower than
>> stand-alone VNC, but it doesn't have to be. In any case, VNC within
>> Croquet is not going to be faster than a stand-alone 2D VNC client. I
>> find that I cannot play video games over stand-alone 2D VNC.
>
>I hope the implication is that croquet, rather than merely control each
>others computers, will allow creative people to play with each other
>better .

I believe that this is what it's always tried to do.

Croquet creates a simulation, and the simulation is distributed such
that any subset of the individual simulation clients can continue the
simulation even in the absence of the original location where the
simulation was obtained.

>> LOCAL APPS: At the other extreme is individual copies of local
>> applications, each displayed in a replicated window in a replicated
>> Croquet world.
>
>One can study a situation by studying extremes, extremes that might be
>ludicrous, but, nonetheless, illuminating .

Again, without examining the history and characteristics of that
history, there is relatively little room and capability to advance the
art and the science.  Sometimes situations themselves must be studied
and examined, to determine how best to modify them.

>I wonder that visiting another person's world means you share their
>total experience . My brother wishes that people would go into phone
>booths with their cell phones so he wouldn't have to hear about their
>business . He is jealous that they aren't really accessible . Creative
>collaboration isn't folks in lock sync replicating the totality of each
>others lives . Its something else .

Creative collaboration isn't the situation of being in lock-step in
the totality of life.  However, there is a very important aspect of
collaboration which you appear not to recognize:  In order to
collaborate, two or more must communicate.  In order to effectively
communicate, there must be at least some aspect of experience which is
shared (sensed independently).

Croquet is a means of sharing experience.  In order to effectively
share experience, Croquet replicates the state of the simulation in
such a way that it can be sensed in more than one location, in
multiple ways (however it makes sense to sense it).

Croquet is NOT a means of forcing people to think the same way.  It is
a means of sharing information such that the computers (clients) that
people use can do their own processing on that information.

>> As Josh described, this will only work when two requirements are met:
>>
>>  1. The applications must produce the same deterministic results when
>> given the same inputs in the same order. The inputs cannot depend on
>> real time, network activity, machine state (e.g., for entropy
>> generators or for additional files that may or may not be there), or
>> numeric computation.
>
>The use of the words "machine state" suggest this croquet model may be
>related to automata theory and state machines. I remember my profound
>shame at failing a course in artificial intelligence and my tears of joy
>at working my heart out on automata theory one summer. I felt I had
>recovered my honor and soon after started beta testing LiveMath computer
>algebra wondering if I could understand it as a state machine like my
>early Hewlett Packard 32 instructions summarized a whole book of
>instructions in a flow diagram state machine.

Short answer, yes.

Croquet can be viewed as:
a) the data that makes up the simulation
b) the behavior which allows the simulation to proceed.

Perhaps not-so-oddly, an "object" (in object oriented programming) can
also be viewed that way -- the data, and the operations which can be
applied to the data.

>I hated when the "old boys" at Rockwell tried to impose flow graph
>expositions of code, but, privately, later, in CS I became reinvigorated
>with that HP experience .
>
>Entropy has references in network theory and Shannon information theory
>. Programming has as fundamental the way you store work or record . In
>my time asymmetry studies, you only record (files) by generating entropy
>. If you didn't, you couldn't.
>
>I think what is being spoken of is an application must be like science
>having reproducible results so consumers can count on their behavior .

Because one of the requirements of the Croquet simulation is that each
one must be able to continue independently, the machine must be
deterministic.  This means that it is a state machine -- because with
each input, it can be determined from the knowledge of the entire
simulation how the simulation will change.

If any of the clients become out-of-sync, then input which is
meaningless will be given to other instance simulations, which may
cause them to behave erratically at best or meaninglessly at worst.

>>  2. When someone joins late, the app has to have some way to get to
>> the same state. Maybe there's little enough interaction that this can
>> be done by replaying saved Croquet inputs. But if that takes too long,
>> there has to be a way to serialize the current state and get that to
>> the newly joined participant.
>
>There are candidates being thought of for getting this "scientific
>reproducibility" and accountability .

Let's look at it this way: as soon as there is a way of writing out
the state of the simulation to disk, there is a way of writing out the
state of the simulation to a new client.

(To see the truth of this statement, look at the concept that "writing
out the state of the simulation to disk" is "getting the state of the
simulation ready for a new client".  Then, if the current simulator is
killed, creating a new simulator and then "loading the state of the
simulation from disk" is the same as "synchronizing the simulator to a
different simulation state" -- no matter that it may have been
time-shifted.)

>> Although this can give better performance than remote bottlenecked
>> apps, local apps are not as general. We don't have a general
>> plug-and-play local app mechanism in the SDK right now.
>
>I think you are saying the croquet model can give better performance
>than remote bottlenecked apps, however its local apps are not as general
>because they need the two restrictions above .

The concept of a 'remote bottlenecked app' is something where there is
only /one/ place to obtain the information necessary to update the
simulation state.  it is also something where only /one/ place must
become unreachable for the application to become unusable.

Unfortunately, this matters.

>> ------------------
>> Separately: it is true that pointing at a window gives ownership. But
>> that's a property of the current default UI, not a fundamental
>> consequence of the Croquet model.
>
>I think this being not a fundamental consequence of the Croquet model is
>"good" and has something to do with not programming modally .

I rather wish that I could find

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE