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

[K. K. Subramaniam]

On Saturday 28 Jun 2008 8:05:41 am Alan Kay wrote:
 The sources and changes files (the changes are the incremental history
 to the sources) don't have to be external to the image, but they have been
 made so since Smalltalk started to be implemented on computers that had
 fallen back to the bad old idea of operating systems and file systems. This
 is easy to find out about in a variety of ways.

 But there is something further to ponder about this method from the 70s.
 And that is the idea that as scaling advances under Moore's Law, it will be
 less and less a good idea to rebuild from scratch (and more and more
 difficult).
Well, there will always be people who will seek to build (or trace the path of 
evolution) from scratch, if only to study how the whole thing evolved. 
Others may want to study a suspended image to see what is in it and how it 
managed to get into such a state. Some people just choose to become 
archaeologists, paleontologists and even pathologists.

For those who have been working with live images for decades, this direction 
of learning may not be of interest, but it would help if they can point out 
the way and let others make their own journey.

Subbu
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

P.S. Re: [IAEP] etoys now available in Debian's non-free repository

[Alan Kay]

P.S. I thought of a different way to possibly resolve this.

It occurs to me that this discussion and differences of opinion could really be 
about how executables are made. One of the main issues cited has to do with 
security, and a notion that being able to see the sources will help.

The simplest application model today has a file which contains executable code 
and one or more files of non-executable data which is manipulated by the 
executable file when they are combined into an OS process. For example, a text 
editor in Linux will have a file of executable code and a file that is a text 
document that (presumably) has no executables in it.

Since (Squeak) Smalltalk is set up to run under various OSs (even though it 
doesn't need them), this model is followed. There is an executable file which 
contains all the executable machine code in the system -- it usually has a name 
like Squeak.exe -- and there can be any number of document files which 
contain only data. The image file is such a document file, and it contains no 
executable code wrt any computer which might use it -- it is a pure data 
structure.

Squeak.exe or its equivalent is ultimately made by (a subset of) the C compiler 
and tools of the operating system that will: invoke it, give it access to the 
screen and keyboard and file system, etc. Every piece of C code that is fed to 
the C compiler is on one file or another and available for perusal. In 
practice, we don't write most of this code by hand, but generate it from a 
higher level architecture and debugging process that is internal to the Squeak 
system. But still, the result is C code that is compiled by someone else's C 
compiler (in this case one of the Linux compilers) into standard Linux 
executables that will be run in a standard way. Any Linux person can examine 
all the source files using tools they are familiar with.

The executable file is like an OS kernel that can incorporate executable 
plugins -- for graphics, sound, the particle system, (Mozilla has even been run 
as a plugin, etc.)), so there can be lots of stuff in this file -- but again, 
all of it ultimately has to be made in a form that is acceptable to the 
underlying OS which owns the machine resources.

Seems as though this should do it. And all these files are readily available 
for all of the OSs we deal with.

We would build the Squeak kernel very differently if there were no OS to 
contend with or that has to be cooperated with But, since we don't regard 
ourselves as a religion or the one right way, we are content to go along with 
current conventions where the alternative is needless argumentation.

The rest of the misunderstandings seem to me to be epistemological, and 
ultimately go back to very different POVs taken by different research groups in 
the 60s.

From several different motivations, the ARPA (and then the PARC branch of 
ARPA) community got into thinking about highly scalable architectures, partly 
motivated by the goal of a world-wide network which had to scale better than 
any computer artifact by many orders of magnitude. This community also took 
Moore's Law seriously, particularly wrt personal computing and just how many 
nodes the proposed network might have. This led to a no-centers style which 
manifested itself most strongly in the 70s. The most extreme successful 
versions of this style eliminated the OS, file systems, applications, data 
structures, simulated punched cards/teletype, etc., in favor of what Marvin 
Minsky called a hetarchical (as opposed to hierarchical) organization of as 
much as possible.

Several of the formulators of this style had considerable backgrounds in 
biology, whose no-center scaling then and now goes far beyond anything 
successfully done in computing.

It was realized that most computing of the 50s and 60s was rather like 
synthetic chemistry in which structures are built atom by atom and molecule by 
molecule. This gets more and more difficult for larger and more complex 
combinations. Life generally uses a process quite different -- instead of 
building cells and organisms, it grows them. This leads to seeming paradoxes in 
the epistemology of making -- i.e. to make a cell we need a cell., to make a 
chicken we need a chicken. However, all works fine in the epistemology of 
growing. But the initial bootstrapping is a little tricky. Once the bootstrap 
is done to make life then life can assist much more powerfully in making more 
life, and to vary life, etc. As mentioned before, the Internet is one of these, 
and so is Smalltalk.

In biologically inspired architectures one is much more interested in how the 
organism and ecologies of them are to be sustained, and how the dynamical 
systems can be understood, fixed, changed, evolved, reformulated, etc., while 
they are running and with the help of tools that work within them. Just as a 
cell, and especially e. g. a human baby, is not made by hand, we are more 
interested in making growth 

Re: etoys now available in Debian's non-free repository

[Frank Ch. Eigler]

Yoshiki Ohshima [EMAIL PROTECTED] writes:

 [...]
 You'd be all set if you had Smalltalk source code that you
 could feed into any random Smalltalk system to create
 your build tools.

 While I happen to like C, and it's a very popular way to
 achieve the required ability to bootstrap, it isn't needed.
 You even get a certain amount of respect from writing
 the whole thing in Smalltalk. Use GNU Smalltalk.

 Your view on systems are way too limited.  Where did this any
 random Smalltalk came from?  [...]  Please just don't make up new
 complaint whenever the old one didn't work.

He is trying to help you by giving an example how bootstrapping could
-- not must -- work for squeak.  GNU Smalltalk does it.  (It's more
elaborate than your write(\x12.., 1), but logical - study it!)
Emacs does it.  Prologs, LISPs do it.  Just about every really free
language system I can think of nowadays does it.  Once squeak  etoys
can do it too, these issues disappear.

You would no longer have to explain/justify that change set passing
is how we do things, because it wouldn't matter.  You wouldn't have
to explain to others whether .sources/.changes files are separate or
internal to the image, which is a distinction without a difference.  A
new public release could consist of just a fileOut:.

You wouldn't have to just *claim* that the new image blob is just
that old image blob, plus these .changes chunks, because you could
*prove* something even stronger.  You wouldn't have to refer others to
tools like SystemTracer that you hardly ever seem to use yourselves.

You wouldn't have to rely on strangers trusting the long chain of
custody/ancestry of the binary image blobs.  That worked fine when
Smalltalk was a commercial product, but not now, when one's upstream
can be any web site with redistribution rights and lawsuit-immune
contributors.

Even you may rest a bit easier, knowing that the image blob would no
longer be a precious heirloom with a murky history embedded within it,
but something that can be recreated clean and new on demand.


- FChE
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: P.S. Re: [IAEP] etoys now available in Debian's non-free repository

[Dan Krejsa]

On Sat, 2008-06-28 at 04:21 -0700, Alan Kay wrote:

 It was realized that most computing of the 50s and 60s was rather like
 synthetic chemistry in which structures are built atom by atom and
 molecule by molecule. This gets more and more difficult for larger and
 more complex combinations. Life generally uses a process quite
 different -- instead of building cells and organisms, it grows them.
 This leads to seeming paradoxes in the epistemology of making -- i.e.
 to make a cell we need a cell., to make a chicken we need a chicken.
 However, all works fine in the epistemology of growing. But the
 initial bootstrapping is a little tricky. Once the bootstrap is done
 to make life then life can assist much more powerfully in making more
 life, and to vary life, etc. As mentioned before, the Internet is one
 of these, and so is Smalltalk.
 
 In biologically inspired architectures one is much more interested
 in how the organism and ecologies of them are to be sustained, and how
 the dynamical systems can be understood, fixed, changed, evolved,
 reformulated, etc., while they are running and with the help of tools
 that work within them. Just as a cell, and especially e. g. a human
 baby, is not made by hand, we are more interested in making growth
 processes that can be influenced with far more ease than direct
 construction. So, most objects are made by other objects acting under
 conditions that include the dynamic state in which they will become
 part of the ecology.

It seems to me that this analogy is a fairly good one -- although
there are definite differences, in that the 'cell' needed to make
another 'cell' in the etoys/squeak case has been designed with lots
of tools to make it easy to inspect and modify itself, as well as
to completely sequence its DNA or produce a new generation on demand.

Living systems are however notorious for carrying historical baggage
along with them in their genotype, and, since the phenotype cannot
easily be recreated without starting with a parent phenotype, the Ken
Thompson hack implies that inheritable baggage can (paradoxically) be 
carried in the phenotype as well. I think the number of somewhat independent
tools provided to in[tro]spect a running image would make an intentional
malicious Thompson hack in Sqeak quite difficult to maintain for long
without discovery; but I would naively guess that there is some 'harmless'
baggage that looks reasonable and is allowed to continue just due to inertia.
Since the 'DNA' (source code) of etoys/squeak is readily available in a
transparent, human-understandable form, it seems to me that the only issue
of possible concern is the lesser visibility of the 'paradoxical' inheritance
via phenotype/image. Or at least, its lesser visibility if one refuses
to run etoys/squeak to use the tools it provides to inspect itself or
its images.

Continuing with the biological analogy, the folks who want to be able to
bootstrap a Squeak/etoys image (starting from 'scratch' without such an image)
want literally to be able to make ontogeny recapitulate phylogeny -- not
necessarily every time an image starts, possibly not necessarily every time
Squeak is 'built' -- but at least with similar frequency and the ease of
bootstrapping gcc using a different C compiler. (Like using a turtle egg to
hatch a dinosaur ;-)

I don't have a strong opinion on this myself, but I do find the
discussion interesting.

- Dan



___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: P.S. Re: [IAEP] etoys now available in Debian's non-free repository

[Yoshiki Ohshima]

 Continuing with the biological analogy, the folks who want to be able to
 bootstrap a Squeak/etoys image (starting from 'scratch' without such an image)
 want literally to be able to make ontogeny recapitulate phylogeny -- not
 necessarily every time an image starts, possibly not necessarily every time
 Squeak is 'built' -- but at least with similar frequency and the ease of
 bootstrapping gcc using a different C compiler. (Like using a turtle egg to
 hatch a dinosaur ;-)

  I believe that the question is not whether a system can do it or
not.  Smalltalk-72 did it, GNU Smalltalk and Scheme 48 do it, and our
fonc project is right now taking similar approach.  So bootstrapping
is possible.  However, given the current status, the trade off between
having to change the existing system fundamental way and its value is
the question.

-- Yoshiki
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: P.S. Re: [IAEP] etoys now available in Debian's non-free repository

[K. K. Subramaniam]

On Saturday 28 Jun 2008 4:51:47 pm Alan Kay wrote:
 It was realized that most computing of the 50s and 60s was rather like
 ...
 state in which they will become part of the ecology.
I propose that this overview be included as part of Squeak. Squeak is very 
different from conventional programming toolkits. A good overview like this 
would help set the right perspective at the beginning and eliminate many 
misunderstandings down the road.

Subbu
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: etoys now available in Debian's non-free repository

[Yoshiki Ohshima]

At Thu, 26 Jun 2008 18:47:11 -0700,
Edward Cherlin wrote:
 
 On Tue, Jun 24, 2008 at 11:04 AM, Albert Cahalan [EMAIL PROTECTED] wrote:
  I'm glad that Debian didn't break the rules for etoys.
  You're claiming to be open source, yet you've LOST the
  source code decades ago.
 
 This turns out not to be the case. All of the source code for the
 parts of Etoys written in Squeak/Smalltalk is in the image.

  ... is in .sources and .changes and the image holds the compiled
results of them and each of these compiled results hold a file offset
of the source chunk.

 The .sources file and .changes file contain all of this code nicely
 formatted.

  Yes.

 The core of Smalltalk, the part not written in Smalltalk,
 is also available in both source and in binary parts of the usual
 image. The usual tools for handling all of this are in
 Smalltalk/Squeak. Nothing prevents you from rewriting them in C,
 Python, or what you like.

  Oh, yes.  Speaking of which, Dan did a version in Java:

http://news.squeak.org/2008/06/21/jsqueak-smalltalk-interpreter-written-in-java/

 Now, for the rest of you, let's see what we can produce, to make
 Albert happy, but more importantly Debian. We have .sources and
 .changes. Albert and Debian would like to see source for the VM, in
 the manner of gst, and the binary core of Smalltalk that goes with it.
 What can we show them, and what would it take to show them the rest?
 The Squeak system includes code for generating a new version of the
 virtual machine (VM) on which it runs. It also includes a VM simulator
 written in itself (Squeak). For this reason, it is easily ported.
 What's missing? Is there anything in bytecode without Smalltalk
 source? It doesn't seem so. The primitives like memory management and
 BitBlockTransfer get translated to C and compiled along with the VM.
 Is that right?

  Yes.

  A sidenote. The repository on squeakvm.org seems is a tree of .c and
.h source files and you can compile it by gcc to produce the VM.
However, many of these files are not the sources in a strict sense;
These .c and .h files are target files from another phase.

  It is almost the same manner as Scheme48 ships scheme48vm.c.  If
(only if) somebody claims that Squeak's way of doing is wrong, that
person should also claim that Scheme48 should be taken out from
Debian.

 Smalltalk/X [Gitt95] and SPiCE [YaDo95] generate C code from programs
 using the full range of Smalltalk semantics, including blocks.
 http://users.ipa.net/~dwighth/squeak/oopsla_squeak.html, Related Work.
 So apparently we can translate all of the Smalltalk tools for creating
 code files and rebuilding an image to C source, and we can presumably
 preserve the original comments from the Smalltalk.

  I'm not sure what you mean by code files and an image to C source.

 Since the result was a complete Squeak
 image with all Smalltalk source code, and C source where needed, is
 anything else missing?

  No would be the answer, If I understand your question.

 The interpreter is structured as a single
 class that gets translated to C along with the ObjectMemory and BitBlt
 classes. Is that it?

  The modern version has basically different set of primitives in
different files, but that is it.

 Is there any reason not to simply check .changes into git?

  The public version of (so to speak) .changes and .sources are
already in the SVN on dev.laptop.org, and it is installed in
/usr/share/etoys.

  Should we
 have a way to split out changes to specific objects, and write a tool
 to merge a sequence of such changes into a .changes file? Hm, it
 appears that this is unnecessary with Monticello and squeakvm.org.

  Before commiting it, we need to ask why splitting the file adds any
value (when the editor can provide such views to the user).

 As far as I am concerned, you should write any such tools in
 Smalltalk/Squeak, and offer that source code to anybody who demands a
 translation to another language. No, I'm wrong, not a problem. We can
 translate it to C ourselves. There you go.

  The Squeak-to-C translator is designed specifically to translate the
subset of Smalltalk that can be mapped onto C.  IOW, you write C code
in Smalltalk syntax, and debug it in Smalltalk.  For writing
interesting tools, you would certainly like to use the full power of
Smalltalk language but then it wouldn't be translatable to C.

  If any such tool is written in Smalltalk, you would give the
Smalltalk code to other people.  That is source.  Translated C program
isn't source; it is a target object file that uses characters between
0x00-0x7f.

 Or set up an instance of Monticello for Etoys versioning
 and package management.

  Not Monticello, but this was tried.  But the problem is that it just
adds unnecessary complexity and gets in the way of *actual*
development effort.

-- Yoshiki
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: etoys now available in Debian's non-free repository

[Edward Cherlin]

I think that the result of all this is that we can produce all of the
C (or some other language, maybe CLOS) and Smalltalk source files that
Debian wants (even if we think of the C as compiler output, we don't
have to bother them with that interpretation.) One of the compilers
translates a subset of Smalltalk to C, but I gather that other
compilers can translate all of Smalltalk/Squeak/Etoys/what you like to
their chosen target language. As I understand it, Debian wants to see
a commented set of semi-human-readable code in ASCII files (although
we can discuss using Unicode source) together with various multimedia
files in known open formats, from all of which an Etoys image can be
constructed, and they don't care how we generate them, or what mix of
languages we use, as long as there are Free/Open Source compilers and
any other needed apparatus for them.

I gather that all of this can be done by a fairly trivial Smalltalk
program. Would somebody write it and post it, and would somebody run
it and make the results available? Then if Albert agrees we've done
it, we can invite Debian to examine it, and get back to work.

On Thu, Jun 26, 2008 at 11:15 PM, Yoshiki Ohshima [EMAIL PROTECTED] wrote:
 At Thu, 26 Jun 2008 18:47:11 -0700,
 Edward Cherlin wrote:

 On Tue, Jun 24, 2008 at 11:04 AM, Albert Cahalan [EMAIL PROTECTED] wrote:
  I'm glad that Debian didn't break the rules for etoys.
  You're claiming to be open source, yet you've LOST the
  source code decades ago.

 This turns out not to be the case. All of the source code for the
 parts of Etoys written in Squeak/Smalltalk is in the image.

  ... is in .sources and .changes and the image holds the compiled
 results of them and each of these compiled results hold a file offset
 of the source chunk.

 The .sources file and .changes file contain all of this code nicely
 formatted.

  Yes.

 The core of Smalltalk, the part not written in Smalltalk,
 is also available in both source and in binary parts of the usual
 image. The usual tools for handling all of this are in
 Smalltalk/Squeak. Nothing prevents you from rewriting them in C,
 Python, or what you like.

  Oh, yes.  Speaking of which, Dan did a version in Java:

 http://news.squeak.org/2008/06/21/jsqueak-smalltalk-interpreter-written-in-java/

 Now, for the rest of you, let's see what we can produce, to make
 Albert happy, but more importantly Debian. We have .sources and
 .changes. Albert and Debian would like to see source for the VM, in
 the manner of gst, and the binary core of Smalltalk that goes with it.
 What can we show them, and what would it take to show them the rest?
 The Squeak system includes code for generating a new version of the
 virtual machine (VM) on which it runs. It also includes a VM simulator
 written in itself (Squeak). For this reason, it is easily ported.
 What's missing? Is there anything in bytecode without Smalltalk
 source? It doesn't seem so. The primitives like memory management and
 BitBlockTransfer get translated to C and compiled along with the VM.
 Is that right?

  Yes.

  A sidenote. The repository on squeakvm.org seems is a tree of .c and
 .h source files and you can compile it by gcc to produce the VM.
 However, many of these files are not the sources in a strict sense;
 These .c and .h files are target files from another phase.

  It is almost the same manner as Scheme48 ships scheme48vm.c.  If
 (only if) somebody claims that Squeak's way of doing is wrong, that
 person should also claim that Scheme48 should be taken out from
 Debian.

 Smalltalk/X [Gitt95] and SPiCE [YaDo95] generate C code from programs
 using the full range of Smalltalk semantics, including blocks.
 http://users.ipa.net/~dwighth/squeak/oopsla_squeak.html, Related Work.
 So apparently we can translate all of the Smalltalk tools for creating
 code files and rebuilding an image to C source, and we can presumably
 preserve the original comments from the Smalltalk.

  I'm not sure what you mean by code files and an image to C source.

 Since the result was a complete Squeak
 image with all Smalltalk source code, and C source where needed, is
 anything else missing?

  No would be the answer, If I understand your question.

 The interpreter is structured as a single
 class that gets translated to C along with the ObjectMemory and BitBlt
 classes. Is that it?

  The modern version has basically different set of primitives in
 different files, but that is it.

 Is there any reason not to simply check .changes into git?

  The public version of (so to speak) .changes and .sources are
 already in the SVN on dev.laptop.org, and it is installed in
 /usr/share/etoys.

  Should we
 have a way to split out changes to specific objects, and write a tool
 to merge a sequence of such changes into a .changes file? Hm, it
 appears that this is unnecessary with Monticello and squeakvm.org.

  Before commiting it, we need to ask why splitting the file adds any
 value (when the editor can provide such views to the 

Re: etoys now available in Debian's non-free repository

[david]

On Thu, 26 Jun 2008, Edward Cherlin wrote:

 I think that the result of all this is that we can produce all of the
 C (or some other language, maybe CLOS) and Smalltalk source files that
 Debian wants (even if we think of the C as compiler output, we don't
 have to bother them with that interpretation.) One of the compilers
 translates a subset of Smalltalk to C, but I gather that other
 compilers can translate all of Smalltalk/Squeak/Etoys/what you like to
 their chosen target language. As I understand it, Debian wants to see
 a commented set of semi-human-readable code in ASCII files (although
 we can discuss using Unicode source) together with various multimedia
 files in known open formats, from all of which an Etoys image can be
 constructed,

so far so good

  and they don't care how we generate them

I think you are wrong here

 , or what mix of
 languages we use, as long as there are Free/Open Source compilers and
 any other needed apparatus for them.

this part is again correct.

 I gather that all of this can be done by a fairly trivial Smalltalk
 program. Would somebody write it and post it, and would somebody run
 it and make the results available? Then if Albert agrees we've done
 it, we can invite Debian to examine it, and get back to work.

if you send them C that's generated and call that your source, it's the 
same thing as writing your code in C and sending assembler as your 
'source' (assuming there was a cpu independant assembler)

breaking out the .source and .changes files that have been referred to in 
this thread and having the build process create the resulting blob that 
you use would probably be acceptable (and far more useful as people can 
then send out patches to those files)

David Lang

 On Thu, Jun 26, 2008 at 11:15 PM, Yoshiki Ohshima [EMAIL PROTECTED] wrote:
 At Thu, 26 Jun 2008 18:47:11 -0700,
 Edward Cherlin wrote:

 On Tue, Jun 24, 2008 at 11:04 AM, Albert Cahalan [EMAIL PROTECTED] wrote:
 I'm glad that Debian didn't break the rules for etoys.
 You're claiming to be open source, yet you've LOST the
 source code decades ago.

 This turns out not to be the case. All of the source code for the
 parts of Etoys written in Squeak/Smalltalk is in the image.

  ... is in .sources and .changes and the image holds the compiled
 results of them and each of these compiled results hold a file offset
 of the source chunk.

 The .sources file and .changes file contain all of this code nicely
 formatted.

  Yes.

 The core of Smalltalk, the part not written in Smalltalk,
 is also available in both source and in binary parts of the usual
 image. The usual tools for handling all of this are in
 Smalltalk/Squeak. Nothing prevents you from rewriting them in C,
 Python, or what you like.

  Oh, yes.  Speaking of which, Dan did a version in Java:

 http://news.squeak.org/2008/06/21/jsqueak-smalltalk-interpreter-written-in-java/

 Now, for the rest of you, let's see what we can produce, to make
 Albert happy, but more importantly Debian. We have .sources and
 .changes. Albert and Debian would like to see source for the VM, in
 the manner of gst, and the binary core of Smalltalk that goes with it.
 What can we show them, and what would it take to show them the rest?
 The Squeak system includes code for generating a new version of the
 virtual machine (VM) on which it runs. It also includes a VM simulator
 written in itself (Squeak). For this reason, it is easily ported.
 What's missing? Is there anything in bytecode without Smalltalk
 source? It doesn't seem so. The primitives like memory management and
 BitBlockTransfer get translated to C and compiled along with the VM.
 Is that right?

  Yes.

  A sidenote. The repository on squeakvm.org seems is a tree of .c and
 .h source files and you can compile it by gcc to produce the VM.
 However, many of these files are not the sources in a strict sense;
 These .c and .h files are target files from another phase.

  It is almost the same manner as Scheme48 ships scheme48vm.c.  If
 (only if) somebody claims that Squeak's way of doing is wrong, that
 person should also claim that Scheme48 should be taken out from
 Debian.

 Smalltalk/X [Gitt95] and SPiCE [YaDo95] generate C code from programs
 using the full range of Smalltalk semantics, including blocks.
 http://users.ipa.net/~dwighth/squeak/oopsla_squeak.html, Related Work.
 So apparently we can translate all of the Smalltalk tools for creating
 code files and rebuilding an image to C source, and we can presumably
 preserve the original comments from the Smalltalk.

  I'm not sure what you mean by code files and an image to C source.

 Since the result was a complete Squeak
 image with all Smalltalk source code, and C source where needed, is
 anything else missing?

  No would be the answer, If I understand your question.

 The interpreter is structured as a single
 class that gets translated to C along with the ObjectMemory and BitBlt
 classes. Is that it?

  The modern version has basically 

Re: etoys now available in Debian's non-free repository

[Edward Cherlin]

On Fri, Jun 27, 2008 at 12:04 AM,  [EMAIL PROTECTED] wrote:
 On Thu, 26 Jun 2008, Edward Cherlin wrote:

 I think that the result of all this is that we can produce all of the
 C (or some other language, maybe CLOS) and Smalltalk source files that
 Debian wants (even if we think of the C as compiler output, we don't
 have to bother them with that interpretation.) One of the compilers
 translates a subset of Smalltalk to C, but I gather that other
 compilers can translate all of Smalltalk/Squeak/Etoys/what you like to
 their chosen target language. As I understand it, Debian wants to see
 a commented set of semi-human-readable code in ASCII files (although
 we can discuss using Unicode source) together with various multimedia
 files in known open formats, from all of which an Etoys image can be
 constructed,

 so far so good

  and they don't care how we generate them

 I think you are wrong here

I don't think your opinion or mine count. Debian's counts. What did they say?

 , or what mix of
 languages we use, as long as there are Free/Open Source compilers and
 any other needed apparatus for them.

 this part is again correct.

 I gather that all of this can be done by a fairly trivial Smalltalk
 program. Would somebody write it and post it, and would somebody run
 it and make the results available? Then if Albert agrees we've done
 it, we can invite Debian to examine it, and get back to work.

 if you send them C that's generated and call that your source, it's the same
 thing as writing your code in C and sending assembler as your 'source'
 (assuming there was a cpu independant assembler)

The analogy doesn't work. If I have C, I'll send the C. I have friends
who used to write APL and ship Ada as source, and their military
customers never complained. If the generated C is well-structured and
has the comments from the Smalltalk embedded, so that people can
understand it, what's the problem?

 breaking out the .source and .changes files that have been referred to in
 this thread and having the build process create the resulting blob that you
 use would probably be acceptable (and far more useful as people can then
 send out patches to those files)

I personally don't mind which files are generated or how. If .source,
.changes, and VM source are sufficient, hooray. If we generate the
files some other way, hooray. I want to see readable, commented C and
Smalltalk, or some other such combination.

 David Lang

 On Thu, Jun 26, 2008 at 11:15 PM, Yoshiki Ohshima [EMAIL PROTECTED]
 wrote:

 At Thu, 26 Jun 2008 18:47:11 -0700,
 Edward Cherlin wrote:

 On Tue, Jun 24, 2008 at 11:04 AM, Albert Cahalan [EMAIL PROTECTED]
 wrote:

 I'm glad that Debian didn't break the rules for etoys.
 You're claiming to be open source, yet you've LOST the
 source code decades ago.

 This turns out not to be the case. All of the source code for the
 parts of Etoys written in Squeak/Smalltalk is in the image.

  ... is in .sources and .changes and the image holds the compiled
 results of them and each of these compiled results hold a file offset
 of the source chunk.

 The .sources file and .changes file contain all of this code nicely
 formatted.

  Yes.

 The core of Smalltalk, the part not written in Smalltalk,
 is also available in both source and in binary parts of the usual
 image. The usual tools for handling all of this are in
 Smalltalk/Squeak. Nothing prevents you from rewriting them in C,
 Python, or what you like.

  Oh, yes.  Speaking of which, Dan did a version in Java:


 http://news.squeak.org/2008/06/21/jsqueak-smalltalk-interpreter-written-in-java/

 Now, for the rest of you, let's see what we can produce, to make
 Albert happy, but more importantly Debian. We have .sources and
 .changes. Albert and Debian would like to see source for the VM, in
 the manner of gst, and the binary core of Smalltalk that goes with it.
 What can we show them, and what would it take to show them the rest?
 The Squeak system includes code for generating a new version of the
 virtual machine (VM) on which it runs. It also includes a VM simulator
 written in itself (Squeak). For this reason, it is easily ported.
 What's missing? Is there anything in bytecode without Smalltalk
 source? It doesn't seem so. The primitives like memory management and
 BitBlockTransfer get translated to C and compiled along with the VM.
 Is that right?

  Yes.

  A sidenote. The repository on squeakvm.org seems is a tree of .c and
 .h source files and you can compile it by gcc to produce the VM.
 However, many of these files are not the sources in a strict sense;
 These .c and .h files are target files from another phase.

  It is almost the same manner as Scheme48 ships scheme48vm.c.  If
 (only if) somebody claims that Squeak's way of doing is wrong, that
 person should also claim that Scheme48 should be taken out from
 Debian.

 Smalltalk/X [Gitt95] and SPiCE [YaDo95] generate C code from programs
 using the full range of Smalltalk semantics, including 

Re: etoys now available in Debian's non-free repository

[david]

On Fri, 27 Jun 2008, Edward Cherlin wrote:

 Subject: Re: etoys now available in Debian's non-free repository
 
 On Fri, Jun 27, 2008 at 12:04 AM,  [EMAIL PROTECTED] wrote:
 On Thu, 26 Jun 2008, Edward Cherlin wrote:

 I think that the result of all this is that we can produce all of the
 C (or some other language, maybe CLOS) and Smalltalk source files that
 Debian wants (even if we think of the C as compiler output, we don't
 have to bother them with that interpretation.) One of the compilers
 translates a subset of Smalltalk to C, but I gather that other
 compilers can translate all of Smalltalk/Squeak/Etoys/what you like to
 their chosen target language. As I understand it, Debian wants to see
 a commented set of semi-human-readable code in ASCII files (although
 we can discuss using Unicode source) together with various multimedia
 files in known open formats, from all of which an Etoys image can be
 constructed,

 so far so good

  and they don't care how we generate them

 I think you are wrong here

 I don't think your opinion or mine count. Debian's counts. What did they say?

I don't think ayone has asked them this exact question.

 , or what mix of
 languages we use, as long as there are Free/Open Source compilers and
 any other needed apparatus for them.

 this part is again correct.

 I gather that all of this can be done by a fairly trivial Smalltalk
 program. Would somebody write it and post it, and would somebody run
 it and make the results available? Then if Albert agrees we've done
 it, we can invite Debian to examine it, and get back to work.

 if you send them C that's generated and call that your source, it's the same
 thing as writing your code in C and sending assembler as your 'source'
 (assuming there was a cpu independant assembler)

 The analogy doesn't work. If I have C, I'll send the C. I have friends
 who used to write APL and ship Ada as source, and their military
 customers never complained. If the generated C is well-structured and
 has the comments from the Smalltalk embedded, so that people can
 understand it, what's the problem?

remember that there are several reasons for the source requirement

1. so that people can check that there isn't bad stuff in the code

2. so that people can change the code

3. so that people can contribute changes to others

4. so that people can learn how the code works

checking for bad stuff could be done on generated C code. changing the 
code can be done with generated C code.

but the resulting C code is worhless for people contributing changes if 
the people they are trying to contribute the changes to are working in 
smalltalk.

learning how the code works _could_ be done on generated C code (although 
not well). my Dad tought himself C by taking the KR book, typing in the 
examples and examining the resulting binaries, but he came from a 
mainframe systems background. most people won't go to that extreme.

 breaking out the .source and .changes files that have been referred to in
 this thread and having the build process create the resulting blob that you
 use would probably be acceptable (and far more useful as people can then
 send out patches to those files)

 I personally don't mind which files are generated or how. If .source,
 .changes, and VM source are sufficient, hooray. If we generate the
 files some other way, hooray. I want to see readable, commented C and
 Smalltalk, or some other such combination.

remember that te GPL talks about the 'preferred form for modification'. 
generated files are definantly not that form.

in this case the dispute is that the squeek/etoys people are arguing that 
there 'preferred form' is the monolithic blob/bundle and others are 
objecting to that and asking for it to be broken down a bit so that the 
various pieces can be dealt with seperatly

the fact that etoys is diverging from the upstream squeek/smalltak is an 
example (in many people's opinion) of the problem cause by everything 
being dealt with as a monolithic chunk.

a similar situation would be if someone were to write a python program 
that edited the python source, but bundled the editor, the program, and 
the python interpreter into one binary. then when you ask for the source 
they offered to give you the C code that the python translates to.

if this were to happen people would rightly demand that this blob be 
seperated into the python interpreter, the editing tools, and the programs 
being worked on, and not accept the C code as being the source.

it sounds to me as if that is the same request being made of the etoys 
people (and if it's not it should be). it doesn't mater what language the 
individual pieces are in (for the python analogy above, the editor could 
be a C-based thing that gets loaded into the python interpreter as a 
module), what matters is sperating the various pieces cleanly into their 
various pieces (the readable, commented code you refer to above)

David Lang

 David Lang

 On Thu, Jun 26, 2008 at 11

Re: etoys now available in Debian's non-free repository

[Jim Gettys]

Albert,

There are many communities out there; some of which have used/use even
closed source tools for developing free code.  That does not make the
code itself any less free.

Using other tools may have other costs, in particular a higher entry
cost for contributors, but it doesn't make the resulting software less
free.
  - Jim


On Thu, 2008-06-26 at 16:13 -0400, Albert Cahalan wrote: 
 On Thu, Jun 26, 2008 at 1:38 PM, Bert Freudenberg [EMAIL PROTECTED] wrote:
  Am 26.06.2008 um 10:53 schrieb Albert Cahalan:
 
  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.
 
  I got that. The fundamental problem is the patch collection.
  There is a problem even if you can distribute the result.
  Patches need to be applied. If you do that, and distribute
  a blob, then we're back to the blob problem. If you don't do
  that, then we have the Minix problem.
 
  I don't actually disagree with that. Smalltalk is an excellent personal
  computing environment (well, you would expect that from the guys who largely
  invented personal computing). It does not fare nearly as well for
  distributed, collaborative development (although the Squeak community has
  developed work-arounds, like Monticello, a nice distributed SCM).
 
  But: Why should these shortcomings in development style be a reason to not
  include it in a Linux distribution? It's not like if every other app is
  well-coded or well-maintained.
 
 The very foundation of the Linux development community
 (which Squeak developers are asking to be accepted by)
 includes an expectation that software can be handled in
 certain ways. Any person can browse the source, with the
 worst case being that one must download an archive file
 or perform a check-out. (better: web git/cvs/svn access)
 Any person can use external tools, which themselves are
 likewise open, to view/edit/save/create/share the source.
 (better: those tools are standard, like emacs/gimp/audacity)
 We also expect a certain degree of openness (not a lot of
 non-public communication) and a certain degree of modularity
 (parts are interchangable across similar projects and versions,
 allowing distributions to mix and match).
 ___
 Devel mailing list
 Devel@lists.laptop.org
 http://lists.laptop.org/listinfo/devel
-- 
Jim Gettys [EMAIL PROTECTED]
One Laptop Per Child

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: etoys now available in Debian's non-free repository

[Gerard J. Cerchio]

[EMAIL PROTECTED] wrote:
 learning how the code works _could_ be done on generated C code (although 
 not well). my Dad tought himself C by taking the KR book, typing in the 
 examples and examining the resulting binaries, but he came from a 
 mainframe systems background. most people won't go to that extreme.

   
Interesting Dad.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: etoys now available in Debian's non-free repository

[Yoshiki Ohshima]

At Thu, 26 Jun 2008 23:43:45 -0700,
Edward Cherlin wrote:
 
 I think that the result of all this is that we can produce all of the
 C (or some other language, maybe CLOS) and Smalltalk source files that
 Debian wants (even if we think of the C as compiler output, we don't
 have to bother them with that interpretation.) One of the compilers
 translates a subset of Smalltalk to C, but I gather that other
 compilers can translate all of Smalltalk/Squeak/Etoys/what you like to
 their chosen target language. As I understand it, Debian wants to see
 a commented set of semi-human-readable code in ASCII files (although
 we can discuss using Unicode source) together with various multimedia
 files in known open formats, from all of which an Etoys image can be
 constructed, and they don't care how we generate them, or what mix of
 languages we use, as long as there are Free/Open Source compilers and
 any other needed apparatus for them.

  As Alan precisely put it (we are dealing with stories, not
reality.), this seems to be a backward way to work on this problem.
When (if) Debian guys asked something based on wrong understanding,
what we should do is not to cater the wrong story, but have them have
real understanding.

  The reality is that the all description of classes and methods are
already accessible (even in text files like .sources and .changes) and
anyone can see all the code, and modify in the way the core developers
do.  That is the equal basis we provide to the world.  Giving the
translated stuff, except the C code for the virtual machine that is
needed for bootstraping purpose, is wrong.

  David, Antoine, and Jonas, thank you for the comments.  But let us
not take this way anyway.

  (Still I see some comments that says the source code is in the
image but it is absolutely false.  In the image, the compiled result
of source is stored, and the texual code is always kept outside of the
image.)

David:

breaking out the .source and .changes files that have been referred to in 
this thread and having the build process create the resulting blob that 
you use would probably be acceptable (and far more useful as people can 
then send out patches to those files)


  We are already sending out textual files called changesets to
people.  That is the way we work.

Jonas:

If I understand correctly, the Squeak community accepts patches 
generated from their binary images.

So the real question is, if images built from C sources can generate 
patches acceptable by the Squeak community.


Generate is a wrong word!  We write code textually in a text editor
(happens to be written in Smalltalk) and save it.  Of course the
patches (changesets) are valid, we accept them.  We won't notice if
the changesets are written in Squeak, a image running on different VM,
Emacs or vi.  It is just text.  The only difference is that the effect
of accepting (saving) takes effects right away, as it is running in
the same session.  Just as same as writing Emacs Lisp in Emacs.
(Think writing lisp-mode.el in Emacs.)

  The image contains pre-made objects starting from nil, true, false,
etc., to the Compiler and beyond.  It also contains pre-loaded artwork
and user contents.  But all of them can be modified, and accessed
fully.

-- Yoshiki
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

[Antoine van Gelder]

 The analogy doesn't work. If I have C, I'll send the C. I have friends
 who used to write APL and ship Ada as source, and their military
 customers never complained. If the generated C is well-structured and
 has the comments from the Smalltalk embedded, so that people can
 understand it, what's the problem?


What happens if I  make my changes to that generated C and then try to  
submit those changes to the generated code back to the Squeak project?

I think this is what Yoshiki means when he says:


 if you send them C that's generated and call that your source, it's  
 the same
 thing as writing your code in C and sending assembler as your 'source'
 (assuming there was a cpu independant assembler)


Free software is also the freedom to develop code with the source you  
are supposed to have access to.

Otherwise you may have gotten some of the things that are necessary  
for software freedom, but you do not have all the things that will  
make it sufficient for you to have actual living breathing farting  
software freedom.

Kind of like how freedom of speech may be a necessary part of  
political freedom but just because a politician is not messing with  
that freedom does not mean that s/he is not putting all the other  
sufficiencies for political freedom into the smoothie blender.

PLUR kiddies and shout it out for all to hear:  Smalltalk inspect.

  - antoine
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

[Jonas Smedegaard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Jun 27, 2008 at 10:17:54AM +0200, Antoine van Gelder wrote:
 The analogy doesn't work. If I have C, I'll send the C. I have friends
 who used to write APL and ship Ada as source, and their military
 customers never complained. If the generated C is well-structured and
 has the comments from the Smalltalk embedded, so that people can
 understand it, what's the problem?


 What happens if I  make my changes to that generated C and then try to  
 submit those changes to the generated code back to the Squeak project?

 I think this is what Yoshiki means when he says:


 if you send them C that's generated and call that your source, it's  
 the same
 thing as writing your code in C and sending assembler as your 'source'
 (assuming there was a cpu independant assembler)


 Free software is also the freedom to develop code with the source you  
 are supposed to have access to.

...and the deroute through C does not conflict with that freedom.

The freedom to develop based on the provided source is what we call 
forking.

You are talking about the ability to give back to the original 
community, which is a different thing.

If I develop based on the source provided by Linus Torvalds (the Linux 
kernel) and want to give back to the original community my changes, then 
they will get rejected if I do not follow their coding style and their 
way of commiting patches.

If I understand correctly, the Squeak community accepts patches 
generated from their binary images.

So the real question is, if images built from C sources can generate 
patches acceptable by the Squeak community.


I honestly do expect Debian to approve Squeak if such C decompiler is 
invented.

And I imagine the Squeak community will support it too, if recompiled 
code generates images workable with them (rather than working as a 
slight fork).


Hope I made sense here - I am _very_ new to the Squeak concepts, 
following these discussions as part of my packaging Sugar software 
officially for Debian.


Kind regards,

  - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  - Enden er nær: http://www.shibumi.org/eoti.htm
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkhkq4MACgkQn7DbMsAkQLjptQCgns8VuwXTa4hqrICtcUA2gPGU
r/AAn1iAK9KwAy9i+WmMumfawwUNfzQ3
=eFlz
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: etoys now available in Debian's non-free repository

[Edward Cherlin]

I am no slouch at understanding a bootstrap process, but it has taken
me a few days to find the information I'm trying to understand by
myself, given the refusal to even consider that someone might need
this information in order to answer Debian's concerns, and thus the
refusal to provide the pointers to it. So it is no surprise to me that
Debian still has those concerns. It is no good being right if you
can't explain or demonstrate _why_ you are right in terms that make
sense to someone else who is willing to understand, but doesn't know
how.

On Fri, Jun 27, 2008 at 11:17 AM, Yoshiki Ohshima [EMAIL PROTECTED] wrote:
 At Thu, 26 Jun 2008 23:43:45 -0700,
 Edward Cherlin wrote:

 I think that the result of all this is that we can produce all of the
 C (or some other language, maybe CLOS) and Smalltalk source files that
 Debian wants (even if we think of the C as compiler output, we don't
 have to bother them with that interpretation.) One of the compilers
 translates a subset of Smalltalk to C, but I gather that other
 compilers can translate all of Smalltalk/Squeak/Etoys/what you like to
 their chosen target language.

Now I see that this is unnecessary. We have the directly executable
Smalltalk source for the VM, including memory management and graphics
primitives written in Smalltalk. It is already in the .sources files.
We can therefore provide all of the source code for Etoys in a
conventional file system in the way that users of compiled languages
expect. This may be necessary in order to educate the Debian license
people. It might even be useful to somebody who wanted to base another
language on Smalltalk. Yes, they should probably modify the Smalltalk
interpreter in the image instead, and use Smalltalk to run, test, and
debug it, and export/translate/compile everything necessary once it's
all working. But it's their choice.

 As I understand it, Debian wants to see
 a commented set of semi-human-readable code in ASCII files (although
 we can discuss using Unicode source) together with various multimedia
 files in known open formats, from all of which an Etoys image can be
 constructed, and they don't care how we generate them, or what mix of
 languages we use, as long as there are Free/Open Source compilers and
 any other needed apparatus for them.

  As Alan precisely put it (we are dealing with stories, not
 reality.), this seems to be a backward way to work on this problem.
 When (if) Debian guys asked something based on wrong understanding,
 what we should do is not to cater the wrong story, but have them have
 real understanding.

Right. So that means we have to educate them. Which means, just as in
Piaget's research, we have to educate ourselves first about how the
Debian people have constructed their understanding of the programming
process, and how we can assist them to construct an improved model.
Saying, We're right! What's the matter with you people? doesn't cut
it.

I find it useful to meet people half way in such a situation. Well, we
don't have to have our code in a conventional file system, but here is
how you can fairly trivially create such a file system and rebuild an
image, even though we never do this in practice. Well, almost never.
Aha! You can do it that way, somebody might need to do it that way,
that's what I'm looking for in the first place. So give. Don't tell me
I don't need to know.

I want to _see_ that fairly trivial script. I want Debian to see it
and to be able to run it and examine its output. Once they understand
how one can generate source code in the traditional form whenever
desired from the real source, and where that real source lives, they
may be able to believe in using the code in the image and not
bothering with generating a conventional representation. They seem to
want proof that we can do something unnecessary but comforting. Well,
it shouldn't be any real effort, so why not give them that
demonstration?

We had an issue like this in the IETF on multilingual URIs in
ASCII-encoded UTF-8. It was claimed that this would break everything,
so we showed how to translate between this form and normal UTF-8 in
two or three lines of Perl for each direction. The final question was
whether Japanese users would be able to type a mixed ASCII-Japanese
URL containing Katakana, Hiragana, and Kanji. So I didn't just say,
Motiron dekiru naa! Nihonjin wa baka da to omou desyou ka nee? I
gave it to them, keystroke by keystroke, with the keyboard layout and
IME switching and the conversions to Kana and Kanji. And then they
said, Oh, of course. Now I can see that there isn't a problem. OK, we
can make a standard for this.

  The reality is that the all description of classes and methods are
 already accessible (even in text files like .sources and .changes) and
 anyone can see all the code, and modify in the way the core developers
 do.  That is the equal basis we provide to the world.  Giving the
 translated stuff, except the C code for the virtual machine that is
 needed 

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

[Alan Kay]

To: all the parties who are worrying about this ...

Given the history (not just PARC but going all the way back to the enormous 
differences of style and results from the ARPA community compared to the Bell 
Labs community), why is there any burden of proof here? 

For example, we published in 1983 a still readily available (including online) 
book (Smalltalk-80 and its implementation) about how Smalltalk is implemented 
and bootstrapped, and there is a readily available paper about the more recent 
Squeak version which was built on that. And there is ample information 
available at the Squeak site.

Folks who are willing to understand actually put some effort into it instead 
of jumping to conclusions based on internal logic and scant information rather 
than available external evidence. We have seen many claims about many things -- 
for example, where the source code might or might not be -- but scant 
evidence that any effort was made to find out. 

As I mentioned previously, this seems more like stories than reality. And it 
seems like a culture clash, where one culture thinks it is somehow standard, 
and other ways are not.

The use of an image goes back further than Unix and C text files (one of the 
earliest good versions of this was BBN Lisp, which became Interlisp, in the 
latter part of the 60s), so this is at least as standard as any other way to 
build things. At PARC, this idea went further, because Smalltalk served as the 
entire environment of the PARC computers, and there was no separate OS, file 
system, etc. If you think about it this way, then you can see that the 
Smalltalk image is simply the entire virtual environment for Smalltalk 
computing. So it is quite equivalent to the package of stuff in the Unix world 
that includes text files, OS, tools, etc.

The sources and changes files (the changes are the incremental history to 
the sources) don't have to be external to the image, but they have been made so 
since Smalltalk started to be implemented on computers that had fallen back to 
the bad old idea of operating systems and file systems. This is easy to find 
out about in a variety of ways.

But there is something further to ponder about this method from the 70s. And 
that is the idea that as scaling advances under Moore's Law, it will be less 
and less a good idea to rebuild from scratch (and more and more difficult). For 
example, the most comprehensive object oriented system on the planet is the 
Internet itself, with the hardware computers as the objects, and TCP/IP as the 
underlying messaging system. This was invented and built by the very same 
computer research community (ARPA/PARC) that invented and built Smalltalk, the 
personal computers, GUI and Ethernet, etc., at PARC. 

Part of the idea here was that computing is going to have to learn how to 
completely build and completely change all computer systems while they are 
running and without being able to take them down for maintenance. This was done 
successfully for the Internet and for Smalltalk. Another part of the idea is 
that if you have a really strong and better system, why not be able to use it 
to improve itself (why go back to decontextualized editors and simplistic 
systems builds, etc.)?

In any case, all of this has been well documented and available for decades. I, 
for one, am happy to answer any questions put to us about how our system works 
(why it bootstraps so well and completely), but I have no interest in spending 
any time defending against opinions that are not well informed.

Best wishes to all,

Alan


- Original Message 
From: Edward Cherlin [EMAIL PROTECTED]
To: Yoshiki Ohshima [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; devel@lists.laptop.org
Sent: Friday, June 27, 2008 6:44:26 PM
Subject: Re: [IAEP] etoys now available in Debian's non-free repository

I am no slouch at understanding a bootstrap process, but it has taken
me a few days to find the information I'm trying to understand by
myself, given the refusal to even consider that someone might need
this information in order to answer Debian's concerns, and thus the
refusal to provide the pointers to it. So it is no surprise to me that
Debian still has those concerns. It is no good being right if you
can't explain or demonstrate _why_ you are right in terms that make
sense to someone else who is willing to understand, but doesn't know
how.

On Fri, Jun 27, 2008 at 11:17 AM, Yoshiki Ohshima [EMAIL PROTECTED] wrote:
 At Thu, 26 Jun 2008 23:43:45 -0700,
 Edward Cherlin wrote:

 I think that the result of all this is that we can produce all of the
 C (or some other language, maybe CLOS) and Smalltalk source files that
 Debian wants (even if we think of the C as compiler output, we don't
 have to bother them with that interpretation.) One of the compilers
 translates a subset of Smalltalk to C, but I gather that other
 compilers can translate all of Smalltalk/Squeak/Etoys/what you like to
 their chosen target language.

Now I see

Re: etoys now available in Debian's non-free repository

[Yoshiki Ohshima]

  Hi, Edward,

  Thank you (again) for thinking about these things!

  Well, now I see a reply from Alan.  I'll try to concentrate on the
pure technical part.

  I think that the result of all this is that we can produce all of the
  C (or some other language, maybe CLOS) and Smalltalk source files that
  Debian wants (even if we think of the C as compiler output, we don't
  have to bother them with that interpretation.) One of the compilers
  translates a subset of Smalltalk to C, but I gather that other
  compilers can translate all of Smalltalk/Squeak/Etoys/what you like to
  their chosen target language.
 
 Now I see that this is unnecessary. We have the directly executable
 Smalltalk source for the VM, including memory management and graphics
 primitives written in Smalltalk. It is already in the .sources
 files.

  A little correction is that the source for the VM is in a separated
package called VMMaker; the etoys image currently doesn't contain it.

 We can therefore provide all of the source code for Etoys in a
 conventional file system in the way that users of compiled languages
 expect.

  There still seems some misunderstanding, but I can't tell how.
The word therefore cannot connect the previous sentense with the one
that follows here.  .sources (and .changes) contains the all behaviors
of objects. and it is in text.

 I find it useful to meet people half way in such a situation. Well, we
 don't have to have our code in a conventional file system, but here is
 how you can fairly trivially create such a file system and rebuild an
 image, even though we never do this in practice. Well, almost never.
 Aha! You can do it that way, somebody might need to do it that way,
 that's what I'm looking for in the first place. So give. Don't tell me
 I don't need to know.

  Hmm.  I'm not sure what you mean by rebuilding an image.  If you
mean to do it from the situation there is no .image it would be very
hard.  For example, the nil object (the sole instance of its class
named UndefinedObject) sits at the beginning of the image file.  You
cannot create the memory words that represents the instance in
meaningful manner from text (in the current Squeak way of doing).

  You can have a big C file that looks like:

-
  unsigned char image[] = {0x12, 0x34, goes to 1 million entries or so};

int
main()
{
   FILE *image = fopen(etoys.image, w);
   fwrite(image, sizeof(image), 1, image);
   fclose(image);
}
-

And this .c file is all text.  This could satisfy Debian people, if
they accept some other languages that are bootstrapped.

 I want to _see_ that fairly trivial script. I want Debian to see it
 and to be able to run it and examine its output. Once they understand
 how one can generate source code in the traditional form whenever
 desired from the real source, and where that real source lives, they
 may be able to believe in using the code in the image and not
 bothering with generating a conventional representation. They seem to
 want proof that we can do something unnecessary but comforting. Well,
 it shouldn't be any real effort, so why not give them that
 demonstration?

  The misunderstanding may lie around what kind of translated C can be
compiled and executed.  We can have a smaller image that is 1MB or so
(can be even smaller but I don't a real point to go for extreme) and
file in everything else to build the etoys.image.  But I cannot see
anywhere that transated code plays any role in the picture.

 Somebody, somewhere, gave Debian the impression that .sources and
 .changes do not contain the code for everything. I don't know how this
 happened. You are almost correct that we don't need to show them the
 translated stuff. But given the damage that has been done, we now have
 to show them the entire process from full Smalltalk source to
 generated code to new image, and the generated C is part of that
 process, even if not source.

  They contain all code (plus some history even).  They don't contain
the instanciated objects.  They can contain texutal expressions that
creates objects, but the textual expressions have to be compiled by
the Compiler object that needs to exist.

 So let's just show them where all the code is and how to get at it in
 a way that they already understand, so that they can begin to
 understand why they don't need to do it that way.

  I should know who are they.
 
 Who here is with Debian? Whom do we have to convince?

  I dug up an email archive of squeak-dev
a few month back and find a name (Thomas Viehmann).

  David:
  
  breaking out the .source and .changes files that have been referred to in
  this thread and having the build process create the resulting blob that
  you use would probably be acceptable (and far more useful as people can
  then send out patches to those files)
  
 
   We are already sending out textual files called changesets to
  people.  That is the way we work.
 
 That does not answer the question asked.

  I still don't understand 

Re: etoys now available in Debian's non-free repository

[Albert Cahalan]

On Thu, Jun 26, 2008 at 9:47 PM, Edward Cherlin [EMAIL PROTECTED] wrote:
 On Tue, Jun 24, 2008 at 11:04 AM, Albert Cahalan [EMAIL PROTECTED] wrote:

 The Smalltalk community is puzzled that anybody would
 prefer to work on Smalltalk in something other than Smalltalk.

Unless you want to rewrite emacs in Smalltalk... :-)

 No point. Anybody who wants to can extract the source code from an
 Etoys image and create the objects you desire. That is the point. You,
 and apparently some of the Debian people, are complaining about two
 things, as far as I can tell.

Great. Do that, and THROW AWAY the Etoys image.
I gather that you can't do this though, which is the problem.

 One is that the Etoys people haven't given you a directory tree of
 text files including appropriate makefiles that would recreate the
 entire Etoys image, bit-identical to what they ship. I'm happy to
 discuss that, since creating those files would apparently let Etoys go
 into the Free repository.

Yes.

 The other complaint is that all of the tools for working on
 Smalltalk source are written in Smalltalk, except for the
 bits to be compiled in C.

Nope.

You'd be all set if you had Smalltalk source code that you
could feed into any random Smalltalk system to create
your build tools.

While I happen to like C, and it's a very popular way to
achieve the required ability to bootstrap, it isn't needed.
You even get a certain amount of respect from writing
the whole thing in Smalltalk. Use GNU Smalltalk.

You might even scrape by with Squeak building itself.
(not involving copy the currently running image)
If you can create a new image from loose UTF-8 text
files and standard media files, without any data being
swiped from the currently running image, then you've
met the requirement.

 http://users.ipa.net/~dwighth/squeak/oopsla_squeak.html

That's in interesting read. It does admit to depending
on a system image from decades ago:

Alter the ST-80 SystemTracer to write an image in the new format.
no longer needing to port images forward from Apple Smalltalk

 What is the source management system for the Etoys and Squeak VMs? Is
 _everything_ done in Smalltalk and kept in the image file? Wait, I see
 it. http://www.squeakvm.org/cgi-bin/viewcvs.cgi/. Albert?

That appears to be the OS interface layer. No problem there.
Feel free to write that in Smalltalk instead though.

 As far as I am concerned, you should write any such tools in
 Smalltalk/Squeak, and offer that source code to anybody who demands a
 translation to another language. No, I'm wrong, not a problem. We can
 translate it to C ourselves. There you go.

I don't see any reason to demand a specific other language,
or even any other language at all. I can see a reason to want
portable code (example: runs on Squeak and GNU Smalltalk),
to eliminate paranoia about a malicious compiler, but this isn't
critical. The really important thing is an ability to generate
everything from source. That means you can create a new
image without grabbing bits from an existing image.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: etoys now available in Debian's non-free repository

[Yoshiki Ohshima]

  Albert,

 You'd be all set if you had Smalltalk source code that you
 could feed into any random Smalltalk system to create
 your build tools.

 While I happen to like C, and it's a very popular way to
 achieve the required ability to bootstrap, it isn't needed.
 You even get a certain amount of respect from writing
 the whole thing in Smalltalk. Use GNU Smalltalk.

  Your view on systems are way too limited.  Where did this any
random Smalltalk came from?  For example, if you write a GUI
application in Python, it doesn't mean that it only uses standard
Python's features.  It certainly is going to use GTK or some other GUI
bindings.  Then, you cannot feed it to another Python implementation
that doesn't have it.

  Please just don't make up new complaint whenever the old one
didn't work.

 You might even scrape by with Squeak building itself.
 (not involving copy the currently running image)
 If you can create a new image from loose UTF-8 text
 files and standard media files, without any data being
 swiped from the currently running image, then you've
 met the requirement.

  Not to mention that don't make up requirement.

  http://users.ipa.net/~dwighth/squeak/oopsla_squeak.html
 
 That's in interesting read.

  The trouble is that people make such wrong claims before reading
such a basic document.

 It does admit to depending on a system image from decades ago:
 
 Alter the ST-80 SystemTracer to write an image in the new format.
 no longer needing to port images forward from Apple Smalltalk

  And?

  What is the source management system for the Etoys and Squeak VMs? Is
  _everything_ done in Smalltalk and kept in the image file? Wait, I see
  it. http://www.squeakvm.org/cgi-bin/viewcvs.cgi/. Albert?
 
 That appears to be the OS interface layer. No problem there.
 Feel free to write that in Smalltalk instead though.

  Vast majority part in this repository is written in Smalltalk.
Please understand the problem before spreading wrong impressions.

 The really important thing is an ability to generate
 everything from source. That means you can create a new
 image without grabbing bits from an existing image.

  But after seeing my big C file idea:

-
  unsigned char image[] = {0x12, 0x34, goes to 1 million entries or so};

int
main()
{
   FILE *image = fopen(etoys.image, w);
   fwrite(image, sizeof(image), 1, image);
   fclose(image);
}
-

then you will probably make up new important thing.

-- Yoshiki
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: etoys now available in Debian's non-free repository

[Albert Cahalan]

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

Re: 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
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: etoys now available in Debian's non-free repository

[Albert Cahalan]

On Thu, Jun 26, 2008 at 3:02 AM, Yoshiki Ohshima [EMAIL PROTECTED] wrote:

  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?

I don't subscribe to the notion that the FSF defines open source.
Heck, I don't care for them and they don't care for open source.

 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.

Right. I'm also not explaining why software freedom is
good, why maintainability is good, why interoperability
is good, etc. Values are values.

 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.

I got that. The fundamental problem is the patch collection.
There is a problem even if you can distribute the result.
Patches need to be applied. If you do that, and distribute
a blob, then we're back to the blob problem. If you don't do
that, then we have the Minix problem.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: etoys now available in Debian's non-free repository

[Bert Freudenberg]

Am 26.06.2008 um 10:53 schrieb Albert Cahalan:

 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.

 I got that. The fundamental problem is the patch collection.
 There is a problem even if you can distribute the result.
 Patches need to be applied. If you do that, and distribute
 a blob, then we're back to the blob problem. If you don't do
 that, then we have the Minix problem.

I don't actually disagree with that. Smalltalk is an excellent  
personal computing environment (well, you would expect that from the  
guys who largely invented personal computing). It does not fare nearly  
as well for distributed, collaborative development (although the  
Squeak community has developed work-arounds, like Monticello, a nice  
distributed SCM).

But: Why should these shortcomings in development style be a reason to  
not include it in a Linux distribution? It's not like if every other  
app is well-coded or well-maintained.

- Bert -


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: etoys now available in Debian's non-free repository

[Albert Cahalan]

On Thu, Jun 26, 2008 at 1:38 PM, Bert Freudenberg [EMAIL PROTECTED] wrote:
 Am 26.06.2008 um 10:53 schrieb Albert Cahalan:

 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.

 I got that. The fundamental problem is the patch collection.
 There is a problem even if you can distribute the result.
 Patches need to be applied. If you do that, and distribute
 a blob, then we're back to the blob problem. If you don't do
 that, then we have the Minix problem.

 I don't actually disagree with that. Smalltalk is an excellent personal
 computing environment (well, you would expect that from the guys who largely
 invented personal computing). It does not fare nearly as well for
 distributed, collaborative development (although the Squeak community has
 developed work-arounds, like Monticello, a nice distributed SCM).

 But: Why should these shortcomings in development style be a reason to not
 include it in a Linux distribution? It's not like if every other app is
 well-coded or well-maintained.

The very foundation of the Linux development community
(which Squeak developers are asking to be accepted by)
includes an expectation that software can be handled in
certain ways. Any person can browse the source, with the
worst case being that one must download an archive file
or perform a check-out. (better: web git/cvs/svn access)
Any person can use external tools, which themselves are
likewise open, to view/edit/save/create/share the source.
(better: those tools are standard, like emacs/gimp/audacity)
We also expect a certain degree of openness (not a lot of
non-public communication) and a certain degree of modularity
(parts are interchangable across similar projects and versions,
allowing distributions to mix and match).
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: etoys now available in Debian's non-free repository

[Bert Freudenberg]

Am 26.06.2008 um 22:13 schrieb Albert Cahalan:

 On Thu, Jun 26, 2008 at 1:38 PM, Bert Freudenberg [EMAIL PROTECTED] 
  wrote:
 Am 26.06.2008 um 10:53 schrieb Albert Cahalan:

 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.

 I got that. The fundamental problem is the patch collection.
 There is a problem even if you can distribute the result.
 Patches need to be applied. If you do that, and distribute
 a blob, then we're back to the blob problem. If you don't do
 that, then we have the Minix problem.

 I don't actually disagree with that. Smalltalk is an excellent  
 personal
 computing environment (well, you would expect that from the guys  
 who largely
 invented personal computing). It does not fare nearly as well for
 distributed, collaborative development (although the Squeak  
 community has
 developed work-arounds, like Monticello, a nice distributed SCM).

 But: Why should these shortcomings in development style be a reason  
 to not
 include it in a Linux distribution? It's not like if every other  
 app is
 well-coded or well-maintained.

 The very foundation of the Linux development community
 (which Squeak developers are asking to be accepted by)
 includes an expectation that software can be handled in
 certain ways. Any person can browse the source, with the
 worst case being that one must download an archive file
 or perform a check-out.

check

 (better: web git/cvs/svn access)
 Any person can use external tools, which themselves are
 likewise open, to view/edit/save/create/share the source.

check

 (better: those tools are standard, like emacs/gimp/audacity)
 We also expect a certain degree of openness (not a lot of
 non-public communication)

check

 and a certain degree of modularity
 (parts are interchangable across similar projects and versions,
 allowing distributions to mix and match).


check

No problems, great.

- Bert -


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: etoys now available in Debian's non-free repository

[Yoshiki Ohshima]

  Albert,

 The very foundation of the Linux development community
 (which Squeak developers are asking to be accepted by)
 includes an expectation that software can be handled in
 certain ways.

  I don't know if it is *very* foundation, yeah there is an
expectation.  I know it because I was one of them.  But the questions
are that what would be the greater benefit for everybody, and whether
the exepectation justifies to limit other people's freedom.

  The technical stuff you wrote below (ah, Bert replied, too) *can* be
done (though not common practices) with Etoys/Squeak.  How many times
you try to spread the same false information, the fact doesn't change.
Anyway, you now seem to agree that Etoys qualifies as open source.
That is good.

 and a certain degree of modularity (parts are interchangable across
 similar projects and versions, allowing distributions to mix and
 match).

  Again and again and again, you can just write a method or two
internally or externally and send it to your friend or post it to
trac, etc.  And a person who are using similar versions of Squeak, he
can just load it.

-- Yoshiki
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: etoys now available in Debian's non-free repository

[Edward Cherlin]

On Tue, Jun 24, 2008 at 11:04 AM, Albert Cahalan [EMAIL PROTECTED] wrote:
 I'm glad that Debian didn't break the rules for etoys.
 You're claiming to be open source, yet you've LOST the
 source code decades ago.

This turns out not to be the case. All of the source code for the
parts of Etoys written in Squeak/Smalltalk is in the image. The
.sources file and .changes file contain all of this code nicely
formatted. The core of Smalltalk, the part not written in Smalltalk,
is also available in both source and in binary parts of the usual
image. The usual tools for handling all of this are in
Smalltalk/Squeak. Nothing prevents you from rewriting them in C,
Python, or what you like.

The Smalltalk community is puzzled that anybody would prefer to work
on Smalltalk in something other than Smalltalk.

 Hacking up binary images is
 shockingly horrible software non-engineering.

It isn't hacking up, and it isn't a binary image. They mostly leave
.sources alone, and write code in Smalltalk, which normally goes into
the .changes file as structured text within a structured and
documented programming object until a new release. The .changes file
is recompiled whenever needed, such as when refactoring previously
defined objects.

 GNU Smalltalk is built in a relatively normal way.

s/normal/conventional/

OLPC could
 ship that instead, assuming that Smalltalk is desirable.

No point. Anybody who wants to can extract the source code from an
Etoys image and create the objects you desire. That is the point. You,
and apparently some of the Debian people, are complaining about two
things, as far as I can tell.

One is that the Etoys people haven't given you a directory tree of
text files including appropriate makefiles that would recreate the
entire Etoys image, bit-identical to what they ship. I'm happy to
discuss that, since creating those files would apparently let Etoys go
into the Free repository.

The other complaint is that all of the tools for working on Smalltalk
source are written in Smalltalk, except for the bits to be compiled in
C. I don't get it. All of your C tools are in C. A .tgz of a directory
tree of files is a binary object just as much as an Etoys image is,
neither more nor less. If your tree includes the sources for some app,
plus emacs and gcc and the necessary libraries (source or binary), the
.tgz is still a binary object with all of your tools in it. In the
extreme case we have a complete Gentoo distribution, and we compile
_everything_ from source, including another instance of gcc. I can
examine the sources elsewhere, but I have to trust the compiler to
some extent, and a lot of other code that I haven't examined. Most of
it has been examined by somebody, but there are arcane parts of X, for
example, where I don't know that you or even Jim Gettys could give me
the name of anybody who still understands it. In any case, this has no
practical significance. If _you_ want to write tools external to Etoys
and Smalltalk that replicate functions in Smalltalk, knock yourself
out. But does Debian want them? I don't see any reason to.

But it doesn't matter what I think. What does Debian think?

Now, for the rest of you, let's see what we can produce, to make
Albert happy, but more importantly Debian. We have .sources and
.changes. Albert and Debian would like to see source for the VM, in
the manner of gst, and the binary core of Smalltalk that goes with it.
What can we show them, and what would it take to show them the rest?
The Squeak system includes code for generating a new version of the
virtual machine (VM) on which it runs. It also includes a VM simulator
written in itself (Squeak). For this reason, it is easily ported.
What's missing? Is there anything in bytecode without Smalltalk
source? It doesn't seem so. The primitives like memory management and
BitBlockTransfer get translated to C and compiled along with the VM.
Is that right?

Smalltalk/X [Gitt95] and SPiCE [YaDo95] generate C code from programs
using the full range of Smalltalk semantics, including blocks.
http://users.ipa.net/~dwighth/squeak/oopsla_squeak.html, Related Work.
So apparently we can translate all of the Smalltalk tools for creating
code files and rebuilding an image to C source, and we can presumably
preserve the original comments from the Smalltalk. Would that make
Albert happy? What about Debian?
Albert, would you take a look at
http://users.ipa.net/~dwighth/squeak/oopsla_squeak.html? It explains
the bootstrapping process from Apple Smalltalk to Squeak, including
writing tools in Smalltalk to generate compilable C code from a
Smalltalk interpreter written in Smalltalk, and writing a small C
program to interface to the OS. Since the result was a complete Squeak
image with all Smalltalk source code, and C source where needed, is
anything else missing? The interpreter is structured as a single
class that gets translated to C along with the ObjectMemory and BitBlt
classes. Is that it?

What is the source management system for 

A greater cause (Re: etoys now available in Debian's non-free repository)

[Yoshiki Ohshima]

  Hello,

  Sorry for causing some email traffic last a few days.

  We, everybody who are participating the project, including Albert,
John, Bert and myself, are working for a greater cause; that is to
empower children all over the world via computer technology and
education.  There are some difference of opinions, but let us not lose
the sight of the bigger goal.

  Etoys is already installed millions of computers, and children all
over the world have been using it several years.  If we get Etoys to
the hands of more children, more children can exchange projects, share
ideas, work together, and unite.  It doesn't matter whether the
computer they use is XO or not because Etoys happens to run
everywhere.  And, on XO, I heard from people at deployments/pilots
often that Etoys is one of the most important activity.  So, I think
that trying to get Etoys into major Linux distributions serves for the
greater cause.

  Of course, even if Etoys gets in a Linux distribution, not every
user/developer has to work on Etoys nor everybody has to understand
how it is implemented.  For those, it is just several unfamiliar files
on their disk and there is absolutely no harm.

  On the other hand, we would like to get more people to help Etoys
development And I can assure you that you can go deeper than any other
systems once you dive in.  Please join us!  Even if your only computer
is XO, you can participate as good as the core developers.  (If you
are good, you can join/take over the core team, in fact.)

  Also, please think about making a similar/better system in any other
languages.  Alan Kay gave a keynote speach at Euro Python a few years
ago and urged the community to think about it.  It seems that a few
project got started but it takes years to be somewhat usable.

  Finally, thank you for everybody who have been involved in the
actual process of getting Etoys accepted to these distributions!

-- Yoshiki

  In a sense, Albert, John, Frank and others are kindly playing the
devil's adovocate role so that we can write stuff that we usually
don't.  Thank you guys, too^^;
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

[Yoshiki Ohshima]

At Tue, 24 Jun 2008 17:12:23 -0400,
Frank Ch. Eigler wrote:
 
 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, have you now understood that this was not true?

-- Yoshiki
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

[Frank Ch. Eigler]

Yoshiki Ohshima [EMAIL PROTECTED] 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.  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.)

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

- FChE
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [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 [EMAIL PROTECTED] 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.)
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: etoys now available in Debian's non-free repository

[K. K. Subramaniam]

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. A video file encoded 
using a secret patented codec would constitute a closed binary blob in the 
first sense since it cannot be decoded with publicly available readers nor 
can one be written without overriding someone's legal rights.

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.

Subbu

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: etoys now available in Debian's non-free repository

[Albert Cahalan]

I'm glad that Debian didn't break the rules for etoys.
You're claiming to be open source, yet you've LOST the
source code decades ago. Hacking up binary images is
shockingly horrible software non-engineering.

You've no justification for taking shots at gcc, which
is entirely capable of being bootstrapped from any other
C89 (ANSI C) compiler. BTW, Ken Thompson's hack is not
viable without perfect AI because source code gets modified.

GNU Smalltalk is built in a relatively normal way. OLPC could
ship that instead, assuming that Smalltalk is desirable.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: etoys now available in Debian's non-free repository

[Bert Freudenberg]

Am 24.06.2008 um 20:04 schrieb Albert Cahalan:

 I'm glad that Debian didn't break the rules for etoys.
 You're claiming to be open source, yet you've LOST the
 source code decades ago. Hacking up binary images is
 shockingly horrible software non-engineering.

Sorry Albert, this just shows your shocking ignorance.

*All the source code* for *every* piece of byte code in the image is  
available, and not only that, we even *ship* it (unlike all those GPL  
C binaries where you have to go out of your way to find the source,  
let alone being able to modify it). You can open a system browser  
right on the XO and inspect and modify every bit of the system.

Please take your propaganda elsewhere.

 GNU Smalltalk is built in a relatively normal way. OLPC could
 ship that instead, assuming that Smalltalk is desirable.


It is not Smalltalk that is desirable, but Etoys. I'd be very  
interested to hear of equivalent software packages.

- Bert -


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: etoys now available in Debian's non-free repository

[Albert Cahalan]

On Tue, Jun 24, 2008 at 2:18 PM, Bert Freudenberg [EMAIL PROTECTED] wrote:
 Am 24.06.2008 um 20:04 schrieb Albert Cahalan:

 I'm glad that Debian didn't break the rules for etoys.
 You're claiming to be open source, yet you've LOST the
 source code decades ago. Hacking up binary images is
 shockingly horrible software non-engineering.

 Sorry Albert, this just shows your shocking ignorance.

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

It's not source code unless I can:

a. build a bit-for-bit identical image from it (aside from timestamps)
b. edit it with an editor of my choice
c. manage it with svn, git, or anything else
d. diff it with standard tools
e. patch it with standard tools

 GNU Smalltalk is built in a relatively normal way. OLPC could
 ship that instead, assuming that Smalltalk is desirable.

 It is not Smalltalk that is desirable, but Etoys. I'd be very interested to
 hear of equivalent software packages.

Unless you can separate Etoys from Smalltalk, you sure
do desire Smalltalk. If you had source code, you could just
use the GNU Smalltalk interpreter.

Fortunately, you do have the possibility of recreating your
long-lost source code. You can mostly regenerate it from
your binary blob, then rewrite the bits that didn't survive.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: etoys now available in Debian's non-free repository

[Bert Freudenberg]

Am 24.06.2008 um 20:38 schrieb Albert Cahalan:

 On Tue, Jun 24, 2008 at 2:18 PM, Bert Freudenberg [EMAIL PROTECTED] 
  wrote:
 Am 24.06.2008 um 20:04 schrieb Albert Cahalan:

 I'm glad that Debian didn't break the rules for etoys.
 You're claiming to be open source, yet you've LOST the
 source code decades ago. Hacking up binary images is
 shockingly horrible software non-engineering.

 Sorry Albert, this just shows your shocking ignorance.

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

 It's not source code unless I can:

 a. build a bit-for-bit identical image from it (aside from timestamps)
 b. edit it with an editor of my choice
 c. manage it with svn, git, or anything else
 d. diff it with standard tools
 e. patch it with standard tools

Well, your view then is way more narrow than even the Free Software  
Foundation's. Let me recall the four fundamental software freedoms for  
you:

• The freedom to run the program, for any purpose (freedom 0).
• The freedom to study how the program works, and adapt it to your  
needs (freedom 1). Access to the source code is a precondition for this.
• The freedom to redistribute copies so you can help your neighbor  
(freedom 2).
• The freedom to improve the program, and release your improvements  
to the public, so that the whole community benefits (freedom 3).  
Access to the source code is a precondition for this.

All of these freedoms are satisfied with the way Etoys is developed.  
It might not fit your personal taste, but then, you are very welcome  
to rewrite it to suit your taste. Our time is better spent actually  
improving the software, not reassembling it for no good reason.

 GNU Smalltalk is built in a relatively normal way. OLPC could
 ship that instead, assuming that Smalltalk is desirable.

 It is not Smalltalk that is desirable, but Etoys. I'd be very  
 interested to
 hear of equivalent software packages.

 Unless you can separate Etoys from Smalltalk, you sure
 do desire Smalltalk.

To the kids it is of no real importance that Etoys is written on top  
of Smalltalk. It's just an implementation detail. But I'd still be  
interested in learning about alternatives.

- Bert -


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

[Robert Withrow]

John and others seem to be making the argument that unless something is 
technologically similar to GCC (in the way it is distributed, developed, 
and coded) it can't be --- picking a term --- open source.  For example, 
Albert says that code has to be manageable by traditional SCM tools, 
patch tools, diff tools, editing tools, etc to be called source code.  
Different tools need not apply.

It seems to me to be a little narrow to define software freedom in terms 
of specific (traditional) development tools; in the same way that it 
seems narrow to define a vehicle as something powered by an animal that 
eats oats.

Isn't it enough for free software to be software that is free (both as 
in beer and speech)?  Or does it also have to be editable by Emacs?

-- 
Robert Withrow, R.W. Withrow Associates, Swampscott, MA, USA
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

[Frank Ch. Eigler]

Robert Withrow [EMAIL PROTECTED] writes:

 John and others seem to be making the argument 

Only seem.

 that unless something is technologically similar to GCC (in the way
 it is distributed, developed, and coded) it can't be --- picking a
 term --- open source.  [...]

Not at all.

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,
and cannot even be rebuilt from the sources it claims to contain.

Someone else threw out the Thompson compiler hack and GCC as if it
were an answer to this concern.  Instead, it turns out that GCC is on
the other (positive) extreme of bootstrappability.

- FChE
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

[Bert Freudenberg]

Am 24.06.2008 um 23:12 schrieb Frank Ch. Eigler:

 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,

This is indeed a valid concern. As I wrote before, an external tool  
could be written to examine what exactly is in the image.

 and cannot even be rebuilt from the sources it claims to contain.


even be rebuilt from the sources ... why would you want to do that?  
It could be done, as well as you could tear down the Empire State  
building and rebuild it from scratch, but why?

- Bert -


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

[david]

On Wed, 25 Jun 2008, Bert Freudenberg wrote:

 Am 24.06.2008 um 23:12 schrieb Frank Ch. Eigler:

 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,

 This is indeed a valid concern. As I wrote before, an external tool
 could be written to examine what exactly is in the image.

 and cannot even be rebuilt from the sources it claims to contain.


 even be rebuilt from the sources ... why would you want to do that?
 It could be done, as well as you could tear down the Empire State
 building and rebuild it from scratch, but why?

leaving aside all the opensource arguments and just looking at it from a 
purely pragmatic point of view:

becouse paranoid people want to be able to verify that what's in the blob 
is really what it claims to be.

and we need to support these paranoid people becouse there are people who 
really are out to get us, and the small number of paranoid people protect 
us all.

David Lang
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

[Bert Freudenberg]

Am 25.06.2008 um 00:12 schrieb [EMAIL PROTECTED]:

 On Wed, 25 Jun 2008, Bert Freudenberg wrote:

 Am 24.06.2008 um 23:12 schrieb Frank Ch. Eigler:

 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,

 This is indeed a valid concern. As I wrote before, an external tool
 could be written to examine what exactly is in the image.

 and cannot even be rebuilt from the sources it claims to contain.


 even be rebuilt from the sources ... why would you want to do that?
 It could be done, as well as you could tear down the Empire State
 building and rebuild it from scratch, but why?

 leaving aside all the opensource arguments and just looking at it  
 from a purely pragmatic point of view:

 becouse paranoid people want to be able to verify that what's in the  
 blob is really what it claims to be.

That would be accomplished by the tool I mentioned above.

 and we need to support these paranoid people becouse there are  
 people who really are out to get us, and the small number of  
 paranoid people protect us all.


I think you forgot a smiley to mark this as sarcasm.

- Bert -


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

[Yoshiki Ohshima]

  After seeing that Jim Gettys and Alan Kay combined failed to
convince a guy on a software issue, it is uncertain that how much I
can add^^; But here goes:

At Wed, 25 Jun 2008 00:04:36 +0200,
Bert Freudenberg wrote:
 
 
 Am 24.06.2008 um 23:12 schrieb Frank Ch. Eigler:
 
  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,
 
 This is indeed a valid concern. As I wrote before, an external tool  
 could be written to examine what exactly is in the image.

  Yes, and the argument seems to be going as if having these tools
externally would make some difference.  However, I think that whether
it is inside or not doesn't make any real difference.

  Frank, *all* bits in the binary image file is well-understood.  In
fact, we can open the binary file from an externally running program
(called InterpreterSimulator written in Squeak) and examine every bits
in the file.

  All bytecodes in the image file can be decompiled to human readable
text files and that could also be done externally; not exactly that,
but I once wrote such a thing.  (It was modified InterpreterSimulator;
wo it happened to be written in Squeak^^;)

  You can also compile all code by calling something like:

  SystemNavigation current allBehaviorsDo: [:cls | cls compileAll].

to make sure that the compiled bytecode in the image reflect the
source code text (the code for the compiler included).

  For knowing what bytecodes do and how fast it runs, many people have
been looking at the generated C code and assembly code for the VM to
make sure that the VM does the right thing.  (I mean many people.)

  Of course, one cannot prove that something (bad) would ever never
happen with any piece of software; Squeak probably has some
vulnerability, but we are not talking about vulnerability, but
intentionally put malicious code, yes?  We can (almost) assure that
nobody has spotted any intentionally put malicious code in the image
file.  And subsequent incremental changes are either in the form of
text change set, or some content.  A sizable community will make sure
that malicious code won't get in.

  I don't think Squeak's vulnerability is not particularly higher than
other language interpreters (it would be somewhat lower than most of
other scripting languages, as Squeak has somrestrictions on what you
can do with external C libraries.)  I can imagine a random analog
would be a situation where an email client is compromized and executes
the binary in an email it receives.  But you wouldn't reject the
client because of the vulnerability; rather you would fix it and use
it as an example of strength of open-source development, right?

-- Yoshiki
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

[Jim Gettys]

On Tue, 2008-06-24 at 11:41 -0700, John Gilmore wrote:
 Jim:
  My point is somewhat different: the only way out of the compilation
  trust trap is another compiler.  Unless someone has done this for gcc,
  it has the identical problem, and there are many possible upstream
  attacks.  I see no reason (probably less) to trust the chain of trust
  for gcc than I do Squeak, as the rewards of attacking gcc are so much
  higher.
 
 Alan:
  We are dealing with stories here, not with any kind of reality. 
 
 Here's a story for you.
 
 GCC is regularly compiled with non-GCC compilers.  It has been
 bootstrapped thousands of times, using dozens of different compilers
 (Sun's, Intel's, Apple's MPW, Green Hills, Code Warrior, MIPS's, ...).
 GCC includes lots of hacks and configuration code to allow it to build
 on other vendors' buggy or divergent compilers.  I've bootstrapped it
 myself hundreds of times, and Cygnus built the testing infrastructure
 to do it nightly on many architectures.  The makefiles are set up to
 do the classic 3-stage bootstrap:
 
   stage1 = binaries from GCC sources compiled with vendor compiler
   stage2 = binaries from GCC sources compiled with stage1 GCC
   stage3 = binaries from GCC sources compiled with stage2 GCC
 
 We then make sure that the stage2 and stage3 binaries are identical.
 (This check has caught hundreds of bugs in gcc, binutils, and in
 vendor compilers.)
 

Ah, yes, I remember this.  I've even struggled to do this once or twice,
but that was about 15 years ago...

 (The 3-stage bootstrap does not prevent or detect a Ken Thompson style
 all-binary attack -- but to succeed on a particular platform, you'd
 have to patch both the vendor compiler and GCC, and keep these patches
 in sync over time.  GCC also supports full blown cross-compilation (of
 itself and anything else), so a cross-bootstrap from any other host
 architecture would break the chain of an all-binary attack.  Debian's
 issue is not about resistance to Thompson attacks; this is just an aside.)
 
 It is trivial to build working binaries of GCC from a source tree, if you
 have a C compiler from any other source.  ./configure  make install.
 
 This is quite different from the eToys situation, in which there is a
 single binary implementation of the language; and the sources, where
 present, are all mixed into a binary blob that's only readable by the
 single implementation.  I have the same concerns that Debian does.  Is
 there even a tool internal to eToys that confirms that everything in a
 blob includes the matching source?  Let alone a tool that would
 extract that source and rebuild the blob from scratch, using a
 virgin binary environment.
 
 We could've bootstrapped GCC once, and limped along ever afterward
 with binaries built from that one original GCC binary.  (In a sense,
 the entire C compiler market has done this.  Bell Labs' original C
 compiler was bootstrapped from a BCPL compiler, and every other C
 compiler probably bootstrapped from Bell's C compilers.)  Instead, the
 GCC maintainers built lots of infrastructure to allow GCC to be
 bootstrapped anytime somebody wants to.  And to test it regularly.
 That's the part that eToys hasn't done.
 
 It turns out to be quite hard to reproduce a GCC release or Linux
 release, bit-for-bit identical, from its source tree.  If you haven't
 tested it, I'd pretty much guarantee that it isn't working.  It has
 subtle dependencies on its build environment, which predates the
 release.  GCC depends on the binutils, on libc, and on many external
 include files, for example.  Even unpacking a source release depends
 on tar and gzip or bzip2, each of which depends on the installed
 shared libc.  Cygnus was bit by such build-environment dependencies
 several times, when trying to produce patches against its old GCC
 binary releases.
 
 Are Fedora releases verified before release to build an identical
 binary CD/DVD image, starting from only a bare Fedora (release X)
 bootable binary CD/DVD, a freshly bought bare PC, and the pile of
 source code RPMs in the Fedora (release X) source CD/DVD?  (I think
 not -- I don't see source or binaries of pilgrim, which makes the
 bootable CD image.)
 
 Are Debian releases tested to reproduce themselves the same way?
 Perhaps eToys can get a reprieve until Debian confirms that it,
 itself, can do what it asks of eToys.
 
   John
 
 PS: Several distros don't make it easy to *find* source code releases.
 There's no obvious path on http://getfedora.com to get the definitive
 F9 source code release; you have to troll around in the mirrors
 looking for it.  OLPC will groan when it gets the first letter asking
 for the matching sources for its binary (flash) release.  It's only a
 few cranky geeks like me who insist on actually obtaining the sources
 for their free binary software.

I hope/believe Dennis has this cleaned up now  I'll check to make
sure.  Please pick on Fedora first, as they are upstream of us ;-).


Back to the 

Re: etoys now available in Debian's non-free repository

[Jecel Assumpcao Jr]

Frank Ch. Eigler wrote on Sat, 21 Jun 2008 14:57:52 -0400
 On Sat, Jun 21, 2008 at 02:50:59PM -0400, Jim Gettys wrote:
   Plus it requires them (and users) to run the tools embedded into the
   possibly suspect image in order to describe itself.  Do you see how
   there could be a trust problem there?
  
  Note this is no different than any time you use a compiler binary
  provided by someone else...  The attack is just as complete...
  http://cm.bell-labs.com/who/ken/trust.html
 
 If that's the best attempt to reassure etoys users/packagers, no
 wonder the debian people are balking.  The Thompson Trojan is a
 noteworthy idea, but surely you see the wholly different degree of
 paranoia we're talking about when we're asked to trust a decades-old
 virtual machine image as compared to a bootstrappable system.

I think Jim's point is valid - you have to consider very carefully every
link in your web of trust and understand just how complex it is if you
want a realistic notion of security. And you have to be clear about your
needs. As an extreme example: most x86 processors currently have enough
spare transistors to easily hide an attack similar to the one described
in the cited paper. I don't think anybody here would spend even a single
second worrying about Intel or AMD, right? But a person in a country
that might go to war with the USA might have to think about it.

Squeak, and Smalltalk in general, represents the opposite extreme in
that it was mostly developed in that 1970s hacker spirit that gave us
SMTP and other equally secure systems. And here we run into a common
problem in the Squeak community: there are those who can (easily, even)
do something and there are those who feel it is a top priority to do
that something, but hardly ever there is an overlap between the two
groups. In the case of security most of the development effort is
happening in the form of forks rather than changes to Squeak itself, so
that doesn't help the problem we are discussing at all.

One way to deal with weak links in a web of trust is to have more
parallel links. If you have several tools with separate origins then an
attack that depends on their cooperation will be very unlikely. A tool
in Python that could investigate a Squeak image file, as has been
suggested, would be an example of using parallel links.

About the issue of sourceless objects, this is something that varies
from image to image. If you start out from some standard image and use
the paint tool to make a few drawings and open new workspaces and type
some notes into them then your new image will be more problematic than
the original. It is likely that with some effort you could have a usable
image that contained absolutely no objects like this at all. Some other
Smalltalks have this, which shows it isn't a technical problem.

So we have two things that should be done: a tool in a language other
than Smalltalk that can inspect Squeak images and an image which can be
generated from the sources using that tool. Who will do it? I can't
think of a name to suggest, which is the problem I mentioned above.

-- Jecel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

[Jim Gettys]

My point is somewhat different: the only way out of the compilation
trust trap is another compiler.  Unless someone has done this for gcc,
it has the identical problem, and there are many possible upstream
attacks.  I see no reason (probably less) to trust the chain of trust
for gcc than I do Squeak, as the rewards of attacking gcc are so much
higher.

So to what standards should one hold squeak vs. gcc?
  - Jim


On Mon, 2008-06-23 at 15:52 -0300, Jecel Assumpcao Jr wrote:
 Frank Ch. Eigler wrote on Sat, 21 Jun 2008 14:57:52 -0400
  On Sat, Jun 21, 2008 at 02:50:59PM -0400, Jim Gettys wrote:
Plus it requires them (and users) to run the tools embedded into the
possibly suspect image in order to describe itself.  Do you see how
there could be a trust problem there?
   
   Note this is no different than any time you use a compiler binary
   provided by someone else...  The attack is just as complete...
   http://cm.bell-labs.com/who/ken/trust.html
  
  If that's the best attempt to reassure etoys users/packagers, no
  wonder the debian people are balking.  The Thompson Trojan is a
  noteworthy idea, but surely you see the wholly different degree of
  paranoia we're talking about when we're asked to trust a decades-old
  virtual machine image as compared to a bootstrappable system.
 
 I think Jim's point is valid - you have to consider very carefully every
 link in your web of trust and understand just how complex it is if you
 want a realistic notion of security. And you have to be clear about your
 needs. As an extreme example: most x86 processors currently have enough
 spare transistors to easily hide an attack similar to the one described
 in the cited paper. I don't think anybody here would spend even a single
 second worrying about Intel or AMD, right? But a person in a country
 that might go to war with the USA might have to think about it.
 
 Squeak, and Smalltalk in general, represents the opposite extreme in
 that it was mostly developed in that 1970s hacker spirit that gave us
 SMTP and other equally secure systems. And here we run into a common
 problem in the Squeak community: there are those who can (easily, even)
 do something and there are those who feel it is a top priority to do
 that something, but hardly ever there is an overlap between the two
 groups. In the case of security most of the development effort is
 happening in the form of forks rather than changes to Squeak itself, so
 that doesn't help the problem we are discussing at all.
 
 One way to deal with weak links in a web of trust is to have more
 parallel links. If you have several tools with separate origins then an
 attack that depends on their cooperation will be very unlikely. A tool
 in Python that could investigate a Squeak image file, as has been
 suggested, would be an example of using parallel links.
 
 About the issue of sourceless objects, this is something that varies
 from image to image. If you start out from some standard image and use
 the paint tool to make a few drawings and open new workspaces and type
 some notes into them then your new image will be more problematic than
 the original. It is likely that with some effort you could have a usable
 image that contained absolutely no objects like this at all. Some other
 Smalltalks have this, which shows it isn't a technical problem.
 
 So we have two things that should be done: a tool in a language other
 than Smalltalk that can inspect Squeak images and an image which can be
 generated from the sources using that tool. Who will do it? I can't
 think of a name to suggest, which is the problem I mentioned above.
 
 -- Jecel
 ___
 Its.an.education.project mailing list
 [EMAIL PROTECTED]
 http://lists.lo-res.org/mailman/listinfo/its.an.education.project
-- 
Jim Gettys [EMAIL PROTECTED]
One Laptop Per Child

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

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

[Alan Kay]

Exactly! Jim sees the real problem.

We are dealing with stories here, not with any kind of reality. 

Cheers,

Alan


- Original Message 
From: Jim Gettys [EMAIL PROTECTED]
To: Jecel Assumpcao Jr [EMAIL PROTECTED]
Cc: its. an. education. project [EMAIL PROTECTED]; OLPC Devel 
devel@lists.laptop.org
Sent: Monday, June 23, 2008 12:00:10 PM
Subject: Re: [IAEP] etoys now available in Debian's non-free repository

My point is somewhat different: the only way out of the compilation
trust trap is another compiler.  Unless someone has done this for gcc,
it has the identical problem, and there are many possible upstream
attacks.  I see no reason (probably less) to trust the chain of trust
for gcc than I do Squeak, as the rewards of attacking gcc are so much
higher.

So to what standards should one hold squeak vs. gcc?
  - Jim


On Mon, 2008-06-23 at 15:52 -0300, Jecel Assumpcao Jr wrote:
 Frank Ch. Eigler wrote on Sat, 21 Jun 2008 14:57:52 -0400
  On Sat, Jun 21, 2008 at 02:50:59PM -0400, Jim Gettys wrote:
Plus it requires them (and users) to run the tools embedded into the
possibly suspect image in order to describe itself.  Do you see how
there could be a trust problem there?
   
   Note this is no different than any time you use a compiler binary
   provided by someone else...  The attack is just as complete...
   http://cm.bell-labs.com/who/ken/trust.html
  
  If that's the best attempt to reassure etoys users/packagers, no
  wonder the debian people are balking.  The Thompson Trojan is a
  noteworthy idea, but surely you see the wholly different degree of
  paranoia we're talking about when we're asked to trust a decades-old
  virtual machine image as compared to a bootstrappable system.
 
 I think Jim's point is valid - you have to consider very carefully every
 link in your web of trust and understand just how complex it is if you
 want a realistic notion of security. And you have to be clear about your
 needs. As an extreme example: most x86 processors currently have enough
 spare transistors to easily hide an attack similar to the one described
 in the cited paper. I don't think anybody here would spend even a single
 second worrying about Intel or AMD, right? But a person in a country
 that might go to war with the USA might have to think about it.
 
 Squeak, and Smalltalk in general, represents the opposite extreme in
 that it was mostly developed in that 1970s hacker spirit that gave us
 SMTP and other equally secure systems. And here we run into a common
 problem in the Squeak community: there are those who can (easily, even)
 do something and there are those who feel it is a top priority to do
 that something, but hardly ever there is an overlap between the two
 groups. In the case of security most of the development effort is
 happening in the form of forks rather than changes to Squeak itself, so
 that doesn't help the problem we are discussing at all.
 
 One way to deal with weak links in a web of trust is to have more
 parallel links. If you have several tools with separate origins then an
 attack that depends on their cooperation will be very unlikely. A tool
 in Python that could investigate a Squeak image file, as has been
 suggested, would be an example of using parallel links.
 
 About the issue of sourceless objects, this is something that varies
 from image to image. If you start out from some standard image and use
 the paint tool to make a few drawings and open new workspaces and type
 some notes into them then your new image will be more problematic than
 the original. It is likely that with some effort you could have a usable
 image that contained absolutely no objects like this at all. Some other
 Smalltalks have this, which shows it isn't a technical problem.
 
 So we have two things that should be done: a tool in a language other
 than Smalltalk that can inspect Squeak images and an image which can be
 generated from the sources using that tool. Who will do it? I can't
 think of a name to suggest, which is the problem I mentioned above.
 
 -- Jecel
 ___
 Its.an.education.project mailing list
 [EMAIL PROTECTED]
 http://lists.lo-res.org/mailman/listinfo/its.an.education.project
-- 
Jim Gettys [EMAIL PROTECTED]
One Laptop Per Child

___
Its.an.education.project mailing list
[EMAIL PROTECTED]
http://lists.lo-res.org/mailman/listinfo/its.an.education.project



  ___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: etoys now available in Debian's non-free repository

[K. K. Subramaniam]

On Saturday 21 Jun 2008 4:11:52 pm Bert Freudenberg wrote:
 Anyway, the Debian ftpmasters did not even object to that, but they
 were concerned about how to be sure what changed from one image to the
 next. Squeak comes with all the necessary tools built into it, but
 this does not work well with their established work flow.
Is there a tool in Squeak that would give the diff between two images? Atleast 
a replay tool that tracks all state changes and applies them to one image to 
generate another? AFAIK, Squeak only tracks changes to methods and not all 
state changes.

I crashed an image while trying to change the parent of a class. Luckily, I 
had a snapshot on disk and reapplied the changeset. But the snapshot had 
lingering instances of a class which the changeset tried to re-parent and the 
image crashed again :-(. The doIts I did to clean up the instances were not 
in the changeset.

Subbu


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: etoys now available in Debian's non-free repository

[Frank Ch. Eigler]

Hi -

On Sat, Jun 21, 2008 at 12:41:52PM +0200, Bert Freudenberg wrote:
 [...]
 (Sorry, this is probably OT for this list.)  Considering the age of
 this smalltalk-derived image, is there some reason to be convinced
 that it contains no code/data other than that could be regenerated
 from sources today? [...]

 [...] The images contains instances that were created interactively
 for which there is no source code. I'm not entirely sure how many of
 these instances there are, but it's not only a few for sure. It
 would be a huge undertaking, for no obvious benefit than to satisfy
 those who erroneously believe source code must come in text
 files. [...]

I was trying to hint at another (non-quaint) reason for that.  How
could someone be sure that such an image contains no malware; no
hidden code that only pretends to run the embedded source code?  This
is one of the fundamental benefits of bootstrapping: one knows exactly
what's in there.


 [...] Anyway, the Debian ftpmasters [...]  were concerned about how
 to be sure what changed from one image to the next. Squeak comes
 with all the necessary tools built into it, but this does not work
 well with their established work flow.

Plus it requires them (and users) to run the tools embedded into the
possibly suspect image in order to describe itself.  Do you see how
there could be a trust problem there?


- FChE
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: etoys now available in Debian's non-free repository

[Jim Gettys]

On Sat, 2008-06-21 at 08:47 -0400, Frank Ch. Eigler wrote:

 
 Plus it requires them (and users) to run the tools embedded into the
 possibly suspect image in order to describe itself.  Do you see how
 there could be a trust problem there?
 

Note this is no different than any time you use a compiler binary
provided by someone else...  The attack is just as complete...

http://cm.bell-labs.com/who/ken/trust.html
- Jim

-- 
Jim Gettys [EMAIL PROTECTED]
One Laptop Per Child

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

etoys now available in Debian's non-free repository

[Holger Levsen]

Hi,

etoys is now available in Debian's non-free repository, so it's not officially 
part of Debian (non-free isnt Debian), but technically can be installed with 
apt-get/aptitude easily.

The reason for having it in non-free is that the Debian ftpmasters don't think 
it passes the criteria for inclusion in main. The etoys maintainers disagree 
with that but have decided to upload it to non-free for the time being, for 
the benefit of the users, so they can install it easily. 

The reasons are described in more detail 
in /usr/share/doc/etoys/README.non-free - readable for the next 72h at 
http://paste.debian.net/6962/

The next step will be to file a bug against ftp.debian.org to (hopefully) get 
this resolved and etoys moved into main. Most probably this will take some 
time until I do that, to not distract us (Debian people) from releasing Lenny 
in time.

That's also why we gave up trying to convince the ftpmasters now (we tried..), 
time is running out to get new software into Lenny...


regards,
Holger


pgpGxPBqNljDm.pgp
Description: PGP signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: etoys now available in Debian's non-free repository

[Frank Ch. Eigler]

Holger Levsen [EMAIL PROTECTED] writes:

 [...]  The reason for having it in non-free is that the Debian
 ftpmasters don't think it passes the criteria for inclusion in
 main. [...]
 http://paste.debian.net/6962
 [...]

(Sorry, this is probably OT for this list.)  Considering the age of
this smalltalk-derived image, is there some reason to be convinced
that it contains no code/data other than that could be regenerated
from sources today?  If there is a mechanical way of assuring that,
how big a step would it be to re-create the image from those sources?

- FChE
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel