As Dave mentioned, the immediate priority is simply ensuring continued operation of squeaksource.com. He is heading up the transition to a new server this week whether that's box3, box4 (Gandi) or a server hosted by Robert's group. If we cannot get it running on a new image and/or VM immediately, we'll just have to deal with the crashes/lockups until we can.
While I think Squeak should host its own services, unfortunately what we have right now is unacceptably dangerous. It appears someone has hacked our SqueakSource implementation to bypass its original design for persistence to use "image-based" persistence. Image-based persistence, in itself, would be fine, except for the fact that our Linux-based SS system scripts carelessly KILL the SS process by PID as a means of opening the image under VNC -- potentially when the image could be in a half-saved state!
Such a misfortune could wipe out the entire community if we were unable to recover from a backup. Therefore, I fully support your idea to move to SqueakSource3 running on GemStone.
But there is one more option. Last month, Tim Rowledge expressed interest in having a more-capable SqueakSource that could support what Magma-based MC repositories provide today:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-July/172243.html
The advantage to this approach, besides having a working server example based on Squeak, is that all MCDefinitions across all Versions of each SSProject would be canonicalized and indexed inside the repository, so that the 'browse mc versions' and 'browse mc origin' functions which are afforded by Magma-based MCRepository's would be available on the trunk repository for everyone.
I've already begun the work for this, but if there is no interest in this, I will simply bow out and support the idea that we go with the GemStone solution.
On Mon, Aug 26, 2013 at 7:10 AM, Pape, Tobias < Tobias.Pape@hpi.uni-potsdam.de> wrote:
Am 24.08.2013 um 02:26 schrieb David T. Lewis lewis@mail.msen.com:
On Fri, Aug 23, 2013 at 03:18:19PM -0500, Chris Muller wrote:
Hi! Ok so there are a couple of questions and potential answers
brewing.
How to host? Where to host?
David Lewis expressed that we should recover the actual SS instance and stabilize it.
My immediate concern is to move the existing squeaksource.com to a new home that is stable, supportable, and sustainable for the long term. My hope is to accomplish that migration within days, not weeks. Once that has been completed, all options should be open as far as I'm concerned. But for now my only objective is to achieve operational stability and a sustainable support process for squeaksource.com.
Just to check my understanding, the reference to hosting by Robert
Hirschfeld's
group is for future consideration, and not something that I need to worry about to the migration plan for the next few days, is that right?
Well Oscar Nierstrasz is commit to us (Robert’s group) in a couple of weeks and would be able to bring a harddrive with all files… (image+mcz's)
This may include bringing it up to a more modern, Cog-supported Squeak image. I am working on doing this for source.squeak.org and so I hope that effort can overlap this one.
Yes for sure, it is important to get source.squeak.org and
squeaksource.com
onto a common code base and support structure in order to minimize the
total
support requirement. One way or another, I am quite confident that this
will
resolve the reliability and performance problems that have plagued
squeaksource
in the past.
But first things first, I'm still trying to copy files, including well
over
15 GB of compressed project files. Firefox says it might be done after
another
23 hours and 10 minutes or so ... then I'll need a box on squeak.org to
unpack
them on.
what files are you copying from where? Are you talking about source.squeak.org org squeaksource.com?
All that said, I maintained an image-based Squeaksource-installation a couple of years ago here at HPI and we ran into lockup-troubles (I figure they are quite similar to those squeaksource.com experienced over the past year) at least once if not twice a day. I tracked the problem down to Socket-related problems (one end closed, the other not, image not responding henceforth), but they were not deterministically reproducible. That was why I started participating in migrating SqS to Gemstone, Initially creating SqueakSource2, but soon changed to Squeaksource3.
From my experiences, I would _strongly_ advice not to setup a new SqueakSource based on a SqueakVM that still has this socket problem (no, it is not the wiggle-the-mouse-and-it-works-again bug).
I am currently devoting my free time to bring GemStone's Monticello-support up to par with Squeaks (read: add missing support for ScriptDefinitions), which would make SS3 on GemStone feature-wise a superset of current squeaksource.com and source.squeak.org while at the same time providing a higher reliability (esp, compared to squeaksource.com).
Best -Tobias
-- Tobias Pape Doktorand im Fachgebiet Software-Architekturen http://www.hpi.uni-potsdam.de/swa/
Hasso-Plattner-Institut für Softwaresystemtechnik GmbH Universität Potsdam Prof.-Dr.-Helmert-Str. 2-3 D-14482 Potsdam, Germany Amtsgericht Potsdam, HRB 12184 Geschäftsführung: Prof. Dr. Christoph Meinel
Not quite sure where it originally sprang from but somewhere, somebody added my ancient email 'tim@sumeru.stanford.edu' - that's even deader than the Nehru Jacket. 'tim@rowledge.org' is the working address.
FWIW, I definitely like the everything, every version, every project, forever, idea that Chris refers to.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Never do at compile-time what you can put off till run-time
box-admins@lists.squeakfoundation.org