etoys now available in Debian's non-free repository

[Albert Cahalan]

On Wed, Jun 25, 2008 at 11:13 PM, K. K. Subramaniam <subbukk at gmail.com> wrote:
> On Wednesday 25 Jun 2008 12:08:44 am Albert Cahalan wrote:

>> > *All the source code* for *every* piece of byte code in the
>> > image is available, and not only that, we even *ship* it
>>
>> No. This is not true. You ship a binary blob. That doesn't
>> count, even if so-called "source code" is viewable from
>> within the blob.
> Albert,
>
> You are confusing "binary" as in "secret encoding" with "binary" as
> in "encoding based on freely available specifications". A UTF-8 encoded file
> containing Mandarin or Hindi text would be unreadable on an ASCII text
> editor, but that doesn't make it a closed binary blob.

Sure, but I actually can get an independent implementation
of an editor for such data -- it doesn't depend on itself.

A good situation would be that you can build the image from
plain text just like GNU Smalltalk does. That could happen on
the laptop when the activity starts, or when the activity is created.

The next best thing would be to supply a custom editor
which is **external** to the image, along with any other
tools needed to edit and create the image. It should be
possible to start from some standard build tools, feeding
in a mix of source code and standard media files, to end
up with a set of tools. Note that you could write such
tools in Smalltalk if you used GNU Smalltalk, which is
able to be bootstrapped. This solution essentially
treats the image like a multimedia file instead of code.
(a dump tool is all you have AFAIK; there is no editor
that can reliably edit a VM image)

Best would be both. Currently, you have neither.

> Squeak image is not a blob in the first sense. One can write a program to
> decode any image file and recover any data stored in it. The problem with the
> blob is not that it is closed, but it is monolithic and limited in capacity.
> The limit is not that restrictive for personal computing purposes, but it
> will hurt when one has to deal with audio/video clips, 3-D simulations or
> large databases. There is no checksum to verify integrity. Objects are stored
> higgedly piggedly making even partial recovery difficult. However, these are
> programming limits, not that of policy.

It's also a problem for change tracking, shared development,
use of one's favorite editor, code sharing with GNU Smalltalk, etc.

This idea of applying patch collections is disturbing. It reminds
me of the terrible mess that Minix was back in 1991, when the
license permitted people to share patches but not code with
the patches applied. Here you have a technical limit instead
of a legal one, but I expect that the result is not much different.