[Box-Admins] Re: SqueakSource

[Levente Uzonyi]

On Mon, 26 Aug 2013, Chris Muller wrote:

>       > 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!
> 
> Which SqS are you referring to? Fabrizio once send Andreas and Me a (then current) image of the squeaksource.com (SS.C) and
> IIRC, it just had VNC running, so you probably are referring to source.squeak.org (S.S.O)?
>
>         Sorry, I also do not understand what you mean by the original design being “hacked” for image-based persistence.
> 
> 
> Yes, I was referring to SSO, which is running a slightly newer/forked version of SqueakSource and using the save-the-image persistence.
> 
> SSO is also running on an old version of Squeak and old VM.  Whatever is good for the SS upgrade will be good for SSO and vice-versa.

The only reason why SSO is running on an old VM is that the server's CPU 
doesn't support SSE2 instructions, so it can't run Cog VMs.

And don't forget that Bert implemented extra features for SqueakSource2 
(the thing we use for SSO) to support the Trunk process.


What are the advantages of using Gemstone instead of Squeak?


Levente

>
>       > 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 had the Idea (but not yet enough pressure) to provide similar features for SS3.
> 
> 
> McModel is self-contained.  Besides substituting an RcDictionary for the MagmaPreallocatedDictionary, you might be able to lift it straight from Magma.  It's indexing is sufficient to provide the minimum
> MCRepository subclass-responsibility API, plus the aforementioned (#historyOf: aMCDefinition) and (#originOf: aMCDefinition) functions, all without MC even knowing it exists.
>  
>       > 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.
> 
> SS3 already cracks open MCZs for determining diffs, browsing code, finding parents, reading
> version informations. It would be easy to just cache this information and provide links inbetween.
>   Remember, however, that both, a Magma-Based solution or a SS3-feature would have to respect
> acls in the sense, that you shouldn't be able to browse into a non-readable project by means of
> 'browse mc origin'.
> 
> 
> Yes, I'd planned for each SSProject to have its own McModel instance, so access is allowed only through the existing Project level ACL.
>  
> We have ODBMS' we should use them to exceed what we had before with only the filesystem.
> 
>  - Chris
> 
> PS -- I attached McModel.st.gz in case you're interested.
> 
> 
>