Hi Igor,

do you know the KernelImage? Because it is the process you are talking
about. It's the set of images where you have a small kernel.image that can
load packages through morphicCore.image  up to etoys.image (with the code
base very close to standard 3.10 image) and you can shrink it back down to
kernel.image and repeat the process again. The current limitation is that
you should use morphicCore.image as the starting point of shrinking because
upper packages do not have cleaned unloading process yet.

http://www.squeaksource.com/KernelImage.html
http://squeak.cz/public/pub/KernelImage/current/

Cheers,
-- Pavel

On Sun, May 18, 2008 at 10:14 PM, Igor Stasenko <siguctua at gmail.com> wrote:

> 2008/5/18 Matthew Fulmer <tapplek at gmail.com>:
> > I finally compiled the notes from the last release meeting,
> > which was slightly over a month ago:
> >
> > http://installer.pbwiki.org/MeetingNotes005
> >
> > The meeting was the first discussion about what should be in
> > 3.11 and who will be doing and organizing it.
> >
> > I will put this into a more central web page soon.
> >
> > --
> > Matthew Fulmer -- http://mtfulmer.wordpress.com/
> >
> >
>
> # Major changes
>
>    * KernelImage: Pavel and Edgar
>    * Build system: Keith, Matthew, and Ken
>          o Definitely involves Installer
>          o Would be nice to involve DeltaStreams if/when it is ready
>
> Last time i speak with Egar, he don't likes the idea of using
> Installer (or maybe i didn't understood well, at which stages he wont
> use it, which possible also :) ).
>
> My 2 cents about making things modular:
> HAVING SMALLER IMAGE DOESN'T MEANS MODULAR IMAGE.
> Example: you can unload traits (thanks to Matthew), but can't load
> them back, or iterate load/unload multiple times :)
>
> I'm okay with idea of having smaller image as a base, which means that
> it easier to maintain by small team and delegate different parts to be
> handled by other teams.
> But we all need to work in environment having at least basic set of
> tools for coding & debugging. And this definitely requires UI.
> And UI currently can't be loaded/unloaded by will. So, you need to
> develop your project in dev-image, which having all these tools, but
> for deployment use different one, where morphic, or other dev-related
> packages not installed.
>
> So, i see that in 3.11 we should pay attention how make things more
> modular: by introducing automated scripts which can unload & load
> things back automatically.
> And this is where such Installed can be very helpful:
>
> 10 timesRepeat: [ Installer install: 'Morphic'. Installer uninstall:
> 'Morphic' ]
>
> Edgar having different view on this:
> use minimal base kernel image, and then build new image, from a
> scratch by loading different packages.
> It easier to use (since we need to support for loading code), but not
> truly modular, since you really unable to unload things , when you
> don't  need them.
>
> My vision, that initially, 3.11 should be based on 3.10 (to support a
> development continuity) and using automated and well-tested scripts,
> strip image to minimal kernel.
> A received artifact should support then loading things back (Morphic
> e.t.c.), as well, as unloading them again.
> That's what i call 'modular' :)
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080519/7e25e790/attachment.htm