Against package removal

Tim Rowledge tim at sumeru.stanford.edu
Thu May 8 17:57:40 UTC 2003


Anthony Hannan <ajh18 at cornell.edu> wrote:

> The latest updates include package removals.  What does this buy me
> except a smaller image file?
Plenty of people have been asking for exactly that. For years.

> Who cares how big the image file is
> especially once its downloaded.
Anyone with a smaller machine - like a PDA or an embedded project
device. Or an information appliance (exobox). Or a Squeak PVR. Ad almost
infinitum.

> Hard drives are big and virtual memory
> only loads what is used.
Not on PDAs and many other devices. Not all computational machines are
high-end desktop machines. As a total proportion of cmputational devices
I'd suspect desktop machines are a very small chunk.

> So the only benefit is quicker initial
> download, which is just a one-time event.  After that, you can download
> incremental updates.
No, the benefit is a wider range of possible systems that can use Squeak
and a wider range of possible things one can do with it. That's been
_my_ vision for nearly twenty years.

> 
> [snip] But more importantly, you can no
> longer find all senders and implementors of a class/method.
So we need extended tools for this. We needed extended tools in the
first place to even have the concept of looking for senders/etc by means
other than grep. Life evolves. We get used to it or die out.

> This makes
> it hard to confidently make changes since you can no longer see all
> dependent code.  With a full image, I find all dependent code and make
> changes accordingly.  This allows me to make wholesale changes,
> confidently.  I wouldn't be able to build a robust closure compiler if I
> didn't have Etoys, MessageTally, ProcessBrowser, ImageSegments, etc.
> loaded because I wouldn't know to update them to work correctly with the
> new closure compiler.
Which implies to me that a lot of stuff was poorly written to
improperly depend on things it shouldn't. We are attempting to improve
that, in between writing emails.

> 
> I do agree we need modules in the image to better structure our code,
> but the modules should all be in the same image so we can see all
> dependents (to confidently make changes).
Load them all and they will all be there.

[snip]
> 1. Keep a single full image.
As has been said quite a number of times recently there _will_ be a full
image. It's just that there won't _only_ be a full image.

A distributed image than loads what it needs when it needs it is a
lovely idea (and one I was proposing to Esprit committees over ten years
ago for research funding) but requires reliable, secure, fast, pervasive
connectivity. The world is certainly moving towards that capability but
it isn't there yet and it doesn't help anywhere near all use cases so we
cannot have a design that only works that way.

tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Useful random insult:- If you stand close enough to him, you can hear the ocean.



More information about the Squeak-dev mailing list