[Vm-dev] Compiling squeak-vm for Linux 64bit

José L. Redrejo Rodríguez jredrejo at edu.juntaextremadura.net
Tue Mar 17 10:28:04 UTC 2009

El mar, 17-03-2009 a las 10:32 +0100, Bert Freudenberg escribió:
> On 17.03.2009, at 08:37, José L. Redrejo Rodríguez wrote:
> > El lun, 16-03-2009 a las 19:57 -0400, David T. Lewis escribió:
> >> On Mon, Mar 16, 2009 at 07:36:22PM -0400, whaevr wrote:
> >>> On Mon, Mar 16, 2009 at 7:27 PM, David T. Lewis  
> >>> <lewis at mail.msen.com> wrote:
> >>>> Excellent, good progress. A word of caution though: Be careful not
> >>>> to set the expectation that this is a solid VM. It compiles and  
> >>>> runs,
> >>>> but I can guarantee 100% that there will be problems at runtime,
> >>>> including crashing the VM when certain functions are exercised.  
> >>>> This
> >>>> is just a matter of working though the type declarations in some VM
> >>>> plugins (and the sound functions apparently), but we are not there
> >>>> yet for 64-bit platforms and EToys users are not going to be happy
> >>>> if the VM crashes in the middle of their creative work ;)
> >>>
> >>> Alright then, I'll hold off on sending the pkgbuilds then. I  
> >>> haven't sent
> >>> them yet, I've been trying to figure out if its possible to do a  
> >>> selective
> >>> svn checkout. I don't need to checkout the the windows and mac  
> >>> versions.
> >>
> >> Bert, help me out on this. Who is the target audience? It's great if
> >> this get released to folks on an experimental basis, but it would be
> >> a mistake to provide it to EToys users who expect a stable and  
> >> reliable
> >> system.
> Etoys and the Squeak VM is getting packaged into many more Linux  
> distributions recently. José pioneered this last year with his  
> packaging for Debian. It went into Fedora a few weeks ago and  
> yesterday Mandriva.  It's not even that we (Etoys devs) are pushing  
> this, but it is a natural outcome of us trying to work with the larger  
> open source community. In fact we don't even know of all packaging  
> efforts - such as Pat's attempt to make it work in 64 bit archlinux.
> A big surge is coming from Etoys being distributed as part of the  
> Sugar platform (the UI originally developed for the OLPC XO-1 kids  
> laptop). SugarLabs just released version 0.84.0 with big fanfare and  
> so I expect many more packagers to try and making Etoys work on their  
> favorite system, for which the Squeak VM is a dependency.
> >>> Suppose I should wait then for the next stable squeak release?
> >>
> >> I'm not sure what the timing would be on this. The stable, supported
> >> Squeak VMs are currently targeted at 32-bit platforms, and for the
> >> most part people using 64-bit platforms are probably building their
> >> own. My hunch is that most users of 64-bit VMs are either hobbyists
> >> like me, or people running servers (such as Seaside web applications)
> >> where the various multimedia plugins are not important. For EToys,
> >> the multimedia functions should work without problems, so that is
> >> why I am saying to be cautious.
> >
> >
> > I can not agree. I'm using the ltsp project in the secondary schools  
> > of
> > my region: there is a ltsp server with 8 Gb of RAM in every classroom
> > with 15-30 thin clients. These servers use amd64, betweeen some other
> > non so obvious reasons, to be able to use correctly the 8 Gb of ram,  
> > and
> > I have to use i386 emulation to be able to poorly run Squeak because  
> > the
> > vm breaks whenever they want to use sound, the plugin (in fact the
> > plugin doesn't work in i386b either), pango, gstreamer, etc. I'm
> > speaking of 3.200 servers plus 60.000 clients. And the users are
> > teachers and students, not hobbyists who can compile a vm by
> > themselves... Also, the squeak-vm is in the Debian repository,  
> > compiled
> > for non-i386 architectures used in the sugar project and, obviously,
> > with the same bugs.
> > And many other places using Debian Edu now know of Squeak and,  
> > whenever
> > they want to use a good ltsp server for the classes, they can not use
> > Squeak. So, from my point of view, at least fixing sound and pango is
> > urgent in 64 bits VMs, as both things are used by default in the etoys
> > image. Fixing the browser plugin should be done also for all the  
> > archs,
> > obviously.
> >
> > Regards.
> > José L.
> That is interesting news. I was not aware anybody is seriously wanting  
> to use Etoys on 64 bits. Besides, I though that amd64 is capable of  
> running 64 and 32 bit software side-by-side just fine so there is no  
> urgent need to clean up the VM (although I'm of course thankful to  
> David who is hacking away on this). As far as I know it's not  
> "emulation" at all, so why do you say it runs "poorly"?
Not, it's not emulation, and running 32 bits applications in a 64 bits
environment works, it's what I'm doing, but the perfomance is worse, and
the integration with the user desktop with all the applications (and the
desktop itself) running in 64 bits has aesthetical issues. And you know,
for end users, the way an application looks uses to be important.

So, for my end users, I've workarounded most of the problems (appart
from the browser plugin that segfaults in 32 bits whenever you close the
tab where it's running), but the problems are still there, and everyday
there are more people trying to use amd64 and don't want (or don't know)
to hack the applications to make them work. And there are some projects
(as the sugar project in Debian, or Debian Edu) that want to use Squeak
and are stalled because of the 64 bits issues. I don't know if that's
urgent for the Squeak community, but it's something that has to be known
to decide if it is important or not. That's why I begun my intervention
in this thread answering to David that the 64-bits are needed not only
for hobbyists, but for many more people. 

José L.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada
Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20090317/5691a78a/attachment-0001.pgp

More information about the Vm-dev mailing list