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

Mon Apr 30 19:26:46 UTC 2007

----- Forwarded message from Howard Stearns <hstearns at wisc.edu> -----

From: Howard Stearns <hstearns at wisc.edu>
Date: Mon, 30 Apr 2007 13:10:14 -0500
To: croquet-user at duke.edu
Subject: Re: [croquet-user] chromium ala Howard Stearns
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
Reply-To: croquet-user at duke.edu, Howard Stearns <hstearns at wisc.edu>

Comments below, but first some general stuff:

I think it's perfectly fine to like Croquet because it exists, or because 
it's open source, or written in Smalltalk, or whatever reason one wants. But 
to me, the interesting part is how the model differs from other distributed 
systems, and what the potential consequences are of that model (e.g., 
scalability, safety, etc.).

As I see it, that core model is -- just as Paul says -- about reproducing 
results. Other distributed systems are about synchronizing results. The key 
insight of Croquet is that the same inputs at the same "time" will produce 
the same results for the same initial conditions. The entire computation is 
(re-)executed the same way on each participating machine. Given the careful 
work by smiTh, reEd, and raAb to make this happen, collaborative 
applications can be simpler, safer, more scalable, and more integrated with 
each other and their context. It does NOT have the effect of offloading 
different parts of the computation to different machines. We think this is 
ok because processors are or will be plenty cheap enough. I'd rather be more 
sparing in the use of people than of silicon.

Now, you could use Croquet's cool graphics and neato development environment 
to do distributed processing rather than replicated processing, but I don't 
think that's really playing to Croquet's deep core strengths.

The part of this discussion thread that I tuned in to was about providing 
access to legacy content that was not implemented in Croquet. It is 
interesting to me to consider not just how legacy content can be included at 
all, but how to do so while preserving Croquet's benefits for Croquet 
content, and maybe even extending some of those benefits to the legacy 
content. The exposition was between systems like VNC that centralize the 
legacy application to one processor and distribute the results, vs. having a 
copy of the legacy application on each machine. The problem with doing the 
latter is that many legacy applications simply don't have a good way to 
maintain the Croquet (TEA-time) invariant: results might be different for 
different copies on the network, even when the inputs are funneled through 
Croquet.

c.f. http://opencroquet.org/index.php/The_Core_Model

Paul Sheldon wrote:
>Howard Stearns wrote well --- I fear deathly silence as a response so 
>chime in hopefully not abnoxiously,
>I also fear being accused of not being technical after I unload a bit of 
>philosophy I've been working on,
>so I try to affirm that I understand some of the technical --- I also 
>like reading things the good professor writes
>that I can't currently understand or what's a heaven for? :

Hah! I'm on staff in the IT department of the University of Wisconsin -- not 
a professor. I don't have any Computer Science degree at all. Google me if 
you're bored.

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

I just mean "bottleneck server" as a disparaging term for a single 
centralized server, and emphasizing that that this puts limitations on 
performance.

I think I may have first heard David Smith say something like "bottleneck 
provider" in referring to an Internet Service Provider. It could have been 
someone else.

Mind you, the current version of Croquet turns limitations like these into a 
feature by making all messages go through a router for the purpose of 
timestamping and authentication.

>
>I googled in quotes for :
>http://www.cs.utah.edu/classes/cs7460/lectures/lecture2.txt
>
>"Topic: Scalability and good design practices
>
>   Discussion topic: What can lead to POOR scalability?
>
>
>   Centralization is often a culprit:
>       - centralized services --> bottleneck server(s), fault intolerance
>   - centralized data --> high latency, bottleneck server(s), faults
>   - centralized algoritms --> load imbalance, hotspots
>
>   Some characteristics of good distributed algorithms:"
>
>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 .
>
>>
>>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 .

See intro, above.

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

Right. The hope is that all approaches to legacy apps from within Croquet -- 
not just only remote or only local -- would allow people to work together IN 
CONTEXT. VNC by itself (outside of Croquet) doesn't really do that.

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

Technically, TEA-time is about being in lock sync, replicating the totality 
of the simulation. One philosophically interesting thing is that rendering 
is NOT part of the simulation and is not replicated -- every participant has 
their own point of view.  So, the boring mechanical part of the COMPUTER 
system is about being in lock step. But the value and raison detre of the 
WHOLE COMPUTER-HUMAN system comes from the individual (non-replicated) 
points of view of the participants.

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

I think it is best to NOT think about machine state for real Croquet 
applications. Just think about replicated messages and behavior.

Alas, legacy applications are not Croquet. They do tend to be oriented 
around "state" and "data."

>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.
>
>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 .
>
>>
>> 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 .
>
>>
>>Fortunately, there are a lot of legacy applications that this will 
>>work for. 
>
>what the croquet model would be good for ...
>
>>For these cases, the results should be just as snappy as Croquet in 
>>general. Again, there may be the same extra memory copy. Modulo that, 
>>with a little re-engineering, there are SOME kinds of applications 
>>where we could make it as snappy as running the application locally, 
>>outside of Croquet.
>
>be just as good for
>
>>
>>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 .

Yes.

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

Agreed.

-- 
Howard Stearns
University of Wisconsin - Madison
Division of Information Technology
mailto:hstearns at wisc.edu
office:+1-608-262-3724

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