[IAEP] etoys now available in Debian's non-free repository

[Yoshiki Ohshima]

  After writing the most of reply here, I found it now largely
off-topic (thanks to Frank for understanding!)

At Wed, 25 Jun 2008 21:00:24 -0400,
Frank Ch. Eigler wrote:
> 
> 
> Yoshiki Ohshima <yoshiki at vpri.org> writes:
> 
> >> The gist of the argument is that one can't currently know what's
> >> really inside an etoys image, except beyond what it itself tells us,
> >
> > BTW, do you now agree that this was not true?
> >
> > If you give me an image file and ask me "why the word at offset
> > 0x12345 in the file is 0x89ABCDEF?", I can answer that by opening the
> > image file externally with InterpreterSimulator, examine the bits and
> > answer something like "this is a second slot of an Array that points
> > to a number object, and the array is pointed to by this, this and ths
> > object.", etc.
> 
> Yes, that sounds much better (from a security/trust point of view)
> than having to ask the virtual machine itself to introspect.

  Well, if you understand more about the relationship between
InterpreterSimulator and the VM, external or not would not make so
much difference.  And, the VM is compiled by a foreign system (a C
compiler), there cannot be a place to hide something like Tompson's
attack.  External or not wouldn't be the factor.

  (And you probably meant that better than "asking the image itself".)

> It stills seems somewhat too low level to enable version control.
> (Back in the early 90's, when I wrote Smalltalk code for a living
> (sort of), we ended up having to use external system
> ("teamwork/envy" IIRC) to get decent version control and
> reproducible builds.)

  Of course, what you would like to version control is the code people
write.  ENVY and others are designed for that purpose.

  For doing version control, we could more or less freeze an image to
be a base (like our etoys-dev-3.0.image), and make a release image
automatically by applying the updates
(http://tinlizzie.org/updates/etoys/updates/) and evaluate the do it
("ReleaseBuilderSqueakland new prepareReleaseImageForOLPC") from a
Makefile (if that makes people happy).  The diffs are all in small
textual files.  As long as you trust the base image, you only have to
look at the updates.

  Now and then, we may want to change the base image.  We do something
that gave the perception to people that the previous base image is
trustable there and that would do.

> It may be a useful exercise to run this over the whole etoys image to
> identify those parts that are recompilable from the .source/.changes
> files, those that represent plain data that could be serialized, and
> perchance surprise objects whose existence was only known to Alan Kay
> or Adele Goldberg back in the 80s. :-)

I don't know in what sense it is *useful*, but the core image of Spoon
(http://netjam.org/projects/spoon/) is 1,337 bytes (and of course
every byte is understood).

-- Yoshiki

  (And '80s is wrong time to go back in that sense, and Alan Kay and
Adele Goldberg aren't the names to be mentioned in that context.)