Proposal to get to the triad; agree with Cees

goran.hultgren at bluefish.se goran.hultgren at bluefish.se
Mon Mar 10 18:10:01 UTC 2003


Hi!

Hannes Hirzel <hannes.hirzel.squeaklist at bluewin.ch> wrote:
[SNIP]
> > Because of this and because I think it is eminently important to prevent
> > VM-level forks I would propose to keep 'friction' as high as possible
> > and therefore ignore VM forks in categorizing, naming, process
> > descriptions, etcetera.=20

I can buy that too.

> I agree and I especially like the layers graph Goran did because it
> captures
> nicely the complexity.
> 
> - The core packages directly sit on the kernel.
> - The base packages use the core packages and the kernel.
> - The extra packages use the base, the core and the kernel packages.
> 
> I think all these situations apply.
> 
> I would remove then the two blue rectangles at the left hand
> side "unofficial kernels" and "unofficial VMs"
> 
> In case there is an agreement on the graph we can put it
> on the swiki.
> 
> -- Hannes

Perhaps we should try to get some form of agreement on the names - there
is a long thread about better names that I haven't had the time to comb
through. I do agree that core/base/kernel are a bit hard to intuitively
grasp.

Personally I am not to hung up on cool metaphors, I just want the
ordering to be dead obvious, here are some variants:

kernel/base/full

kernel/dev/full

kernel/dev/base

kernel/minimal/full

....well. I am still also wondering if we really need to distinguish
between core and base. Cees had some nice arguments but I need to reread
them I think. Note that I am not saying we shouldn't have these concepts
- its just that I think that perhaps they are merely "distros" or in SM
speak - different "load scripts", and not really different package
groups.

regards, Göran

PS. If someone wants to fiddle further with the picture I did post it as
a .pr the first time on the sqf-list I think. Otherwise mail me and I
can give it to you.



More information about the Squeak-dev mailing list