Real people (was RE: [UNIX]Building modular VMs)
dmaxwell at banana.exobox.com
Thu Oct 12 19:26:09 UTC 2000
This is really a pointless debate, because Squeak has a variety of
different types of current and potential users, and each type has different
needs and practical experience, and there's no single solution.
As a developer, I go back and forth on the convenience of a small number of
files vs. the flexibility of a larger number of finer granularity. My Mac
heritage rebels even against the notion of installation - most of my
commercial apps were usually "drag the (single) application icon from the
floppy onto your hard drive", or just "run the app from the CD-ROM"
variety. The only times I ever had an installer was to handle installing
things out of my control like QuickTime - and I hated doing that. My view
was the the only things that should be exposed to the user are ones that
the user should have some need to directly manipulate.
Nobody "installs" books, video tapes, DVDs, music CDs or Nintendo games, so
why should they have to install software?
Some Squeak developers, especially of the Tim variety, have to occasionally
directly manipulate small pieces of the VM, so those should be exposeable
to that class of user. Most developers who stick purely to the Smalltalk
side have no need to manipulate anything other than image files - they
technically don't even need to manipulate the VM except to move it, since
it can only be used with images. My personal dilemma is that I sometimes
do Tim things (testing plugins, fixing VM bugs, pontificating), and
sometimes pure Smalltalk things (pretending I know what I'm doing).
One of our goals at exobox is to make an _end user_ system that can be
network managed - which means that we can update the client machines
remotely - with the rather ambitious goal of doing as much of that as
possible _without exiting Squeak_. This is why we've invested in Tim's
efforts to have at least the _ability_ to split out as much from the base
VM as possible. Frankly, we'd love to have the VM be tiny - just a place
to launch the rest of the system from, and a hideyhole to hunker down in
while the remainder of the VM functionality is updated.
The complexity of such a system in terms of number of files and layout,
etc., is irrelevant since the user never sees it, and the management is
The Mac had an interesting solution to this with its "simple file system
within the file" resource idea, in that the end user manipulated a single
object (the application icon), while in reality moving a collection of
related objects (resources). It was rare but possible to update resources
in a running application, including code resources. As functionality
spread across multiple files, there was brief flirtation with functionality
(Wild Magic?) that attempted to create dependency relationships between
files, enforced by the Finder - ie. trash the application, and all of its
related files would automatically go with it, and warn you about trashing
things that were shared. Apple did that when QuickTime separated the data
of frames of movies from the movie frame ordering and timing - you could
trash a seemingly unused movie file and unwittingly break many others.
We are extremely sympathetic to the view of the simple minimal-file
distribution, and there's no question that that should be one of the most
commonly available, especially for newbies. What we'd like to avoid,
however, is that philosophy arbitrarily imposed on Squeak as the _only_ way
More information about the Squeak-dev