[Vm-dev] Re: [squeak-dev] Re: can't start Squeak on one Ubuntu system anymore

[David T. Lewis]

On Wed, Jun 04, 2014 at 09:36:46AM +0200, Bert Freudenberg wrote:
> > If I hadn't had access to the working laptop, I don't know what I
> > would have done.  Hopefully we'll be able to improve Squeak's
> > accessibility someday..
> 
> Doesn't get much easier than
> 
>       apt-get install squeak-vm
> 

Indeed :-)


> If that doesn't work, file a bug report. 
> 
> That won't get you Cog at the moment. But it could, if someone put in the effort. 
> 
> Tim's new Scratch release would be a fine incentive if it was packaged to require either a Cog or Stack VM. This worked for Etoys, which I packaged to require a Squeak VM package. That's why a Squeak VM is now in every major Linux distro. 
> 
> Of course, that plan would require to get two new packages into all distros, which isn't exactly easy. Another plan would be to package the interpreter and cog in a single source package and just call that the new release. Then this would be picked up almost automatically by the distro maintainers.
> 

For the near term, the source packages should be separate. It is easy to manage
that way, and we should not allow the task of merging the trunk and oscog code
bases to stand in the way of providing good Linux installation packages for
both Cog and squeak-vm. We should name the packages in some way that emphasizes
that they are strongly related. The "squeak-vm" name is established and makes
sense, so possibly "squeak-cogvm" or something similar could be used.

> Long-term this might even be the better plan because then the user wouldn't have to worry which VM to use for which image. We might even be able to consolidate the VMs into a single executable which chooses a pluggable execution engine and object memory at runtime. 
> 

This is the right direction, and the /usr/bin/squeak script already contains
hooks for the Cog executable, with the intent that Cog should be selected
where possible, and fall back on an interpreter VM for images that require it.
My own opinion is that this is premature, because 32 and 64 bit modules cannot
be mixed, and I think we have now reached at the point where 64 bit platforms
are the norm rather than the exception. Nevertheless, the hooks are in place
and we should aim in that direction.

> So, basically this just requires some effort on making nice source packages for distro maintainers. David and lately tty have been working towards that, and maybe someone else can join in (and be it just testing and commenting in what they produce).
> 
> - Bert -

In my view, supporting one or more Linux distros is an important function,
and in many ways similar to the platform owner role that we have traditionally
used within the VM team, in which the original authors of the various VM platform
implementations (initially John, Ian, Andreas, Tim) have assumed responsibility
for specific OS platforms. We have never really had someone officially in the
role of coordinating Linux distributions of the VMs, for which the ability to
build from source is critical, and where various licensing issues may come
into play.

Bert has provided leadership in making the initial Linux distributions happen,
but I'm not sure that he intended this to be an ongoing responsibility (Bert,
please correct me if I'm wrong). So if someone is interested in taking on some
work in that area, please do speak up. Discussion should go to the vm-dev list. 

I think it is important to say also that that Eliot is currently providing
a range of Cog VMs on various platforms at the same time that he is doing
cutting edge new work on VMs and object memories. We are all grateful and
happily taking advantage of that work, but as a community we need to support
this, and if someone can put some energy into providing supported packages
for both squeak-vm and Cog for Linux distributions, I think that it would be
a welcome contribution.

Dave