On Thursday 08 May 2003 12:35, Cees de Groot wrote:
> On Wed, 2003-05-07 at 20:47, Andreas Raab wrote:
> > Consider a situation where we use a method in distro X which is not
> > in distro Y (or implement a selector which is not in distro Y but
> > defined by someone else in distro X).
>
> A very real danger. Although it is just as bad if people would fork
> images (which has happened to some extent - plugin image, Squeakland
> image, OpenCroquet image). The idea is:
> 1. to make sure that there's little incentive for forking off new
> distros (as opposed to different images within the same distribution
> and full compatibility);

While the Squeak/Linux analogy is a very good one technically, it is 
less so historically.

 - Linux inherited a lot of stuff from older Unixes and GNU and brought 
together people with very different traditions, so naturally 
distributions went in separate directions before people started trying 
to create standard directory structures and such. Squeak does have 
things imported from other Smalltalks, but it isn't much and doesn't 
have the same impact.

 - Linux lacked package management and installation software, so the 
distributions had no choice but to come up with their own. The current 
modules effort in Squeak has to succeed before there can be things like 
"distributions" for it, so the SM will be like if Slackware/Debian/Red 
Hat/Suse/Conectiva all shared a single package format and repository.

Given these differences, I see several images in a distribution or 
several distributions as the same thing in practice.

> 2. to have very good dependency mechanisms. To some extent, all
> RPM-based Linux distributions are dependency-compatible because they
> phrase dependencies in terms of 'this packages needs v2.3 of the C
> run-time library)', instead of specific package names.

But they still use names, which is too weak. Conectiva and Suse might 
both have a .rpm called guile-1.4...., for example, and yet the first 
is missing some library files that are present in the second one. So I 
download gEDA...rpm and all dependencies are satisfied, but it won't 
compile. And fixing things manually will cause the whole package 
edifice to come tumbling down.

So I most certainly see what Andreas is talking about. But I think a 
technical solution is possible, and want to encourage the work the 
Guides have been doing. But my own style is different, as I will 
explain below.

> But forking is dangerous. And we're way too small to survive serious
> forks. But I think most of us are very aware of that.

Didn't you say above that several forks have already happened (not 
counting older stuff that seems to have died off)? The experience of 
the Self community shows that you are right about the dangers. The Sun 
implementation was a monster that nobody but the original programmers 
had the courage to touch, so we got JSelf, tinySelf, OpenSelf and so on 
instead of picking up where the Sun people had left.

Now we have Squid, Berne Squeak, E-Squeak and probably others. It is 
dangerous. It is open source! It is needed or we will be running 
something almost exactly Squeak 3.2 in 2013. I am in this camp myself, 
but as I said above it is good that the Guides are being far more 
conservative.

I would like to thank Andreas very much for posting the link to David P 
Reed's "Naming and synchronization in a decentralized computer system". 
I have only read one fourth of it so far but it seems to validate what 
took me 20 years to figure out for myself. I wish I had seen this 
before.

OpenCroquet is based on the NAMOS ideas described in this thesis, right? 
Good. We need this kind of thing. Other stuff I wouldn't mind having: 
PIE/Us (multiple viewpoints of objects - different package versions 
living in the same image), E (capability based security), parcels 
(modules, whatever) and LOOM (object based virtual memory).

I believe that a single implementation that does all of the above and 
yet is simpler than any of them individually is possible, though it 
would require a very radical fork of Squeak to do it. This would make 
3.3 look like a picnic, but the rewards would be worth it.

   I remember giving one of those to a Xerox executive, including
   doing a portrait of him in the new painting system, and wound
   it up with a flourish declaring: "And what's really great about
   this is that only has a 20% chance of success. We're taking risk
   just like you asked us to!" He looked me straight in the eye and
   said, "Boy, that's great, but just make sure it works". This was
   a typical executive notion about risk. He wanted us to be in the
   "20%" one hundred percent of the time.

   -- Alan Kay in "The Early History of Smalltalk"

Forks are RISK, and so are start up companies. You have to bet in 10 if 
you want at least one winner. Are there enough people so that a failed 
fork will not result in Squeak dying? I think so, specially with the 
Guides' current strategy as a safety net.

-- Jecel