Miguel, here's the thing.  You're words are just plain wrong man and
touching some nerves in the process.  You keep saying that with Squeak
you start with a kitchen-sink and delete what you don't want.  Wrong.
Ok, yes, it's still true today, but of course Squeak is just not
"done" yet.  The unloadability is just the beginning of the path that
can and will lead to a "Core" Squeak image, where you start with
"nothing" and then add the packages you want.  Patience, we're getting
there, ok?

True, right now a Squeak image may be a few extra meg than a Pharo
core image, but we are talking about a little-bit of memory and disk
not cpu-cycles by any meaningful stretch.  So I think you make a
pretty strong complaint when, in a production system, it really just
boils down to a few meg of memory and, perhaps, the psychological
benefit of feeling "clean" (although sometimes missing modules are a
problem in production systems!).

My sense is that Squeak cares about it's legacy software, wants to go
smaller in a way that keeps most of those "paleolithic" things
loadable.  The easiest way to do that, we feel, is to massage it while
it's still in the image, make it unloadable, reloadable, THEN unload
it, save the smaller image and deploy that as "core".

I believe the difference with Pharo is that their priority is to be
modern and corporate-friendly.  The way Pharo is being positioned is
very good for Squeak because I believe it relieves Squeak itself from
the pressures to corporate.  Except from you man!  Please, won't you
ease up?   :)

The reality of "suitability for any particular purpose", be it
educational or communiticating with industrial-grade switches to
peform real-time call-routing, Squeak is out there doing these things,
right now, this second, and have been for a long time.
Squeakers/Smalltalkers/XP'ers rely heavily on manual and automated
*testing* to determine the suitability of a system for a particular
purpose, not marketing.  I believe, even if Pharo is more corporate
"friendly," Squeak is just still just as corporate "capable".

True, for someone looking for, (I quote you here), "the way" to go,
then Pharo is the one that suits you, and you've made that clear.  But
I think if you step back and and just watch the Squeak side, let the
unencumbered imaginations over there run wild, you will witness some
potentially great treasure to be harvested for Pharo in the future.
Personally, I would like to see and assist this kind of exchange
occur, wouldn't you?

Cheers Miguel,
  - Chris


2010/3/6 Miguel Enrique Cobá Martinez <miguel.coba at gmail.com>:
> El vie, 05-03-2010 a las 15:45 -0800, Randal L. Schwartz escribió:
>> >>>>> "Miguel" == Miguel Enrique Cobá Martinez <miguel.coba at gmail.com> writes:
>>
>> Miguel> Then Squeak refuses to remove Etoys from base image, even is in process
>> Miguel> the update and resync of Etoys with upstream squeakland code.
>>
>> I do believe the intent is to make etoys unloadable.  If you've heard
>> otherwise, can you poin at it, so that I can be up to date?
>
> Yes, it is unloadable since a month ago like someone else said, but that
> doesn't make Squeak a vehicle for deploying commercial apps? Again, as
> in another thread I said, the fact you can disassemble the image doesn't
> mean that you want to disassemble it for deployment.
>
> The modularity is one thing.
> The easy to deploy web/desktop images is also important.
> You can give a full installed desktop linux server with gui and pidgin
> and firefox and thunderbird and everything. That doesn't mean that I
> would accept it for deploying my email server using it. I prefer to
> start from a minimal linux install and add it only the email server. Not
> search everything that I don't need and delete it manually.
>
> That is why I refer like not commercial-friendly. There is not roadmap
> that you can rely in order to base your app for a couple of years if you
> don't know what direction Squeak will be going with the new board.
>
> You don't have a defined board blessed support for oldstable images.
> What will happen to current deployed 3.10 applications when 4.1 is out?
> and when 4.2 is out? As you surely know, that is a very important thing
> for selling a solution using Squeak. And the one-man minimal images
> can't be relied on, (not because of the people behind that efforts they
> are brilliant, but because the truck factor is crucial here) a community
> effort is needed for the minimal images to be successful.
>
> You don't have well defined deployment setups (the ones that Torsten
> have made for one-click install are very good, as are the ones that you
> can find in the lists archives, but no one place where you can go and
> review all your options for deployment and not just for using a Squeak
> image) Check: http://rubyonrails.org/deploy is a link in the home page
> of rails. for squeak you must search the lists.
>
> You don't have recipes for deploying Morphic apps, without all the
> things you don't need to give your customers like squeakmap, universes,
> monticello, etc. Again, we return to use the unload scripts and hope
> that you get a working image.
>
> Finally I apologize for stating that Squeak don't care for uses other
> than educational ones, but *my opinion* is that don't ease the use for
> commercial uses either.
>
>
>
>
>>
>> Miguel> If the board refuses to remove etoys that is for me that they have a
>> Miguel> preference for the educational use of squeak than the commercial use of
>> Miguel> squeak.
>>
>> As a member of the board, I can tell you this is *not* an intent.
>>
>
> --
> Miguel Cobá
> http://miguel.leugim.com.mx
>
>
>
>