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
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 programmin
> 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 e
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. "Li
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
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 simple
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 amo
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 rewr
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
efending 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: [
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 point
-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 gene
> 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, wha
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
[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 K&R book, typing in the
> examples and examining the resulting binaries, but he came from a
> mainframe systems background. most people won't go
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 resul
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
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
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 interpr
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 o
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 tur
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 diffe
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
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 o
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 w
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
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
> Right. I'm also not explaining why software freedom is
> good, why maintainability is good, why interoperability
> is good, etc. Values are values.
That is alright. You tried several claims to say Etoys is not open
source based on incorrect ideas, and now it seems that you exhausted
such clai
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/
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
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
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
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
> >
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 of
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, do you now agree that this was not true?
If you give me an image file and ask me "why t
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
__
Thank you, Jim!
I've missed previous conversation on this one so it is probably
redundant, but here is some additional information:
> > 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 compiler
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
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 a
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,
>
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 ex
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 exactl
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 g
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 to
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
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
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
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 yo
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 boots
OLPC Devel
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 prob
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 Squea
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 p
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 wi
Hi -
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 y
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 c
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
On 20.06.2008, at 16:36, Frank Ch. Eigler wrote:
> 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, th
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
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 inc
59 matches
Mail list logo
