On Wed, Jun 25, 2008 at 11:13 PM, K. K. Subramaniam <[EMAIL PROTECTED]> 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. _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel