Actually, this discussion is getting closer to what's actually the case. When you get anything made in Squeak (such as Etoys) you are getting all of Squeak, including a portable machine that contains a full set of sources and the development tools to make anything, including new versions of Squeak, and to easily bootstrap the system to any platform regardless of the OS (or not) the platform might have.
So the only misconception I saw in the last few exchanges was part of a lot of correct conclusions by Holger. The misconception was: "it's because the impossibility to bootstrap etoys." Etoys can be easily bootstrapped over and over (and Squeak can be bootstrapped over and over) but it is done using the tools and UIs and sources supplied in Squeak I think there are two things going on here. One is that most computer people today do not know how Smalltalk and its environment work, despite the historical fact that more than quite a few of the inventions of the personal computer and programming languages were made in Smalltalk in the 70s, and were greatly facilitated by its advanced (ironically, still advanced) integrated development system made in itself, and its ability to self modify every part of itself quite safely while it is running. (A good way to think of it is that it is an "eternal software system" rather like its spiritual codeveloped sibling, the Internet, which is at its best while continuously running, and having the loose and late binding processes to allow any and all improvements without have to stop.) The other factor that is likely operating here is that some people think their way is the only way and that any other way just has to be wrong and inferior. And perhaps they think that since their way is the only way they should be like the cardinals of the Church in the 17th century who refused to look into Galileo's telescope "because there could not possibly be anything important to see in there". Dogma closes down possibility and progress. It is the opposite of Open. Bootstrapping means being able to accomplish a certain kind of result, and there is more than one way to do it. Best wishes to all, Alan ________________________________ From: David Farning <[EMAIL PROTECTED]> To: Holger Levsen <[EMAIL PROTECTED]> Cc: [email protected] Sent: Saturday, November 8, 2008 5:19:23 AM Subject: Re: [IAEP] squeak/etoys accepted as free software... (was Re: Sugar on Ubuntu - Summary On Sat, Nov 8, 2008 at 2:37 PM, Holger Levsen <[EMAIL PROTECTED]> wrote: Hi, thanks from me to Jecel for clarifications too! On Friday 07 November 2008 19:45, Jonas Smedegaard wrote: > The Squeak image "Etoys" (the only one currently packaged officially for > Debian) is in "non-free" due to ftpmasters judging it not possible for > the security team to maintain throughout the (multiple year long) > lifespan of a Debian release. IIRC/IIUC this is one aspect why the ftpmasters didnt accept it in main. More generally said, (IIRC) it's because the impossibility to bootstrap etoys. Even though the etoys developers "don't do it" and the stateful VM (or rather patches to it) is/are the prefered form of modification. And while I dont agree with the position they are taking (should I say, "anymore"..) I can understand why they do: because it makes sense and (probably also) because this is like it always was: traditional software has to have the ability to be bootstrapped or build. Squeak is special in this case and I dare to say "new". (I know it was started in the 70ties :) But not all people do.) So my planned approach to get it into main in the long run, is to start a general discussion in Debian about this kind of software, thus stopping to special case squeak. But as you might know (or not), Debian is in the process of releasing Lenny atm, so I don't think it's a good time to start philosophical discussions now. We should rather concentrate on fixing those last bugs and getting Lenny out, so that we concentrate again on fancy new stuff! :) I was also happy to read Greg Dekoenigsberg mail in this tread and wonder the same: whether there are any lessons that can be shared between Fedora and Debian maintainers in this case. And how. My approach is to create a comprehensible document (quoted by Jonas in this thread) explaining the issue(s). Holger, Thanks for taking the time to think about and explain this issues clearly from a packager/distribution point of view. david regards, Holger _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
_______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
