etoys now available in Debian's non-free repository

[Yoshiki Ohshima]

  Albert,

  Before drifting to a new topic, let me make sure one thing; did you
get convinced that FSF's definition of software freedom doesn't
contradict with a binary image file with right tools to fully
explore/understand/modify it?

  If not, please explain.  If so, I understand that you don't like it,
and that is ok with me.

  In the following, you are discussing "my preference" part but here
goes:

At Thu, 26 Jun 2008 02:41:00 -0400,
Albert Cahalan wrote:
> 
> Sure, but I actually can get an independent implementation
> of an editor for such data -- it doesn't depend on itself.

  You can edit a file out with your favorite text editor and file it
in to the image to do any kind of stuff.

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

  You never explained why these things are "good".

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

  We don't exactly treat the image file as "code".  Image is a
snapshot of state of objects.

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

  You can of course file out and file in textual code and if the code
is compatible with GNU Smalltalk, you can share the code.

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

  No, no. You don't get it.  Applying patch happens when building a
release image and the resulting image gets into a package to be
distributed.  It is just the same as compiling an executable binary
from source code and distribute the binary.

-- Yoshiki