A couple of people have now answered by "who is harmed by the present image
size" questions.

Looking back through an old OOPSLA proceedings, I stumbled across a
paper about Squeak.  The image back then was about 1MB.  Now it is about 9MB.

It would be interesting to know roughly where the space is going.
- IDE
- Morphic
- Scamper
- Celeste
- Balloon3D
- Alice
- Sound
- Speech
 - ...

Scamper is cute, but it feels even slower than HotJava (which is saying
something) and I can't print from it, so *for me* it is bloat.
Celeste is cool, but I continue to use /usr/bin/mailx as my mailer
precisely because it *can't* do fancy things, and I had trouble hooking
it into UNIX mail anyway, so *for me* it is bloat.
3D graphics is an important part of making Squeak a great multimedia
system, but *for me* it's bloat.

I put up with this "bloat" for several reasons.

One hasn't been mentioned in _this_ context, at least not recently.

If something isn't in the base image, it stops working.
Simply because all of these "modules" share an address space,
you have no reason to believe that a "module" will work in any
combination of modules you haven't actually tested it in.

The things I've mentioned as bloat *for me* are core functionality for
many many other people, and it is important that those things not stop
working.

There is an indirect benefit, or would be if I knew how to run regression
tests for all those other things.  If I develop something useful (and I'm
working on it, I'm working on it) I would like to be sure that it won't
break anything.

Now, I don't delete any existing classes, and I don't delete any existing
methods, but I *do* add some methods to existing classes.  (For example,
I have added methods
	reverseDetect: aBlock ifNone: exceptionBlock
	reverseDetect: aBlock
to SequenceableCollection.)  That could well break some other project
that wants to use these methods for something else.  (In the case of those
two methods, I seriously doubt it.  But you never know.  And they are not
the only such methods.)

It would certainly be nice to be able to do "Smalltalk testEverything" before
going home at night...  There's something I don't know, isn't there (:-)?

	Anyone who would like to use Squeak, but does a lot of programming "for the 
	web" (e.g. needing to run on someone else's webhost where they only have CGI 
	access) or system administration.  It seems like novice programmers 
	(sysadmins with little programming experience) would be greatly benefitted by 
	squeak's environment, but would be unable to squeeze the image down into 
	their environments where something like Python, Perl, or sh would be 
	suitable.  (The python and perl environments end up being about the same size 
	as squeak, and take much longer to load if you need everything -- but you 
	have options as to how much you want to load.)
	
An empty wish or TkPerl isn't that far off Squeak 1.x in size.  (AMAZING!)
(We're talking orders-of-magnitude here, not percentage points.)

	> It seems fair to say that if you are happy to use Acrobat reader, the size
	> of Squeak 2.7 should not worry you either.
	
	If you're thinking in terms of huge graphical applications, yes.

It is not at all obvious to me why Acrobat Reader *should* be a "huge"
graphical application.

	But if you're talking about scripts or CGIs, it's a problem.

Is _any_ Smalltalk dialect used for such applications?  I suppose
GNU Smalltalk or Budd's Little Smalltalk might be usable.

Squeak is
 - a multimedia library
 - a compiler and development environment
amongst other things.  Let's compare it with another OO compiler.

I ran javac, compiling a 60-SLOC example from IBM.  (ClientServer.java, if
you know it.)  Total VM size: 38MB; RSS: 15MB.  And that's just compiling.
Somehow, I don't think Sun's "javac" does 3D graphics in its spare time...

I found this result for java very very surprising.  Don't take it too
seriously until someone else can reproduce it.  The command I used was

    javac ClientServer.java & ps -lu -u $LOGNAME

I'm not sure that I *have* a position on the "is Squeak bloated" question.
I can see value in having a smaller image; but everywhere I look I see
systems that are _less_ useful to me taking _more_ memory.