Results of "Installation help needed"

Dan Ingalls DanI at wdi.disney.com
Wed Mar 3 16:18:41 UTC 1999


>On Wed, Mar 03, 1999 at 08:00:31AM -0500, kpgrant at mindspring.com wrote:
>> .... We're still thinking about how to install it on the
>> department system and, knowing a little bit more about what these
>> files are for, a new question comes up.  As it stands now every student
>> who wants to play with squeak will need to have his own copy of all 4
>> files (or at least 3, since it seems you can do without the source
>> file if necessary).  This means an extra 8 to 14 megs of disk space
>> per student.  Is there any convenient way around this?  

Marcus Denker <marcus at ira.uka.de> replied...
>-> Not everyone needs his own VM. The binary can live somewhere else.
>   (e.g. in the directory /usr/local/bin)
>
>-> Squeak (normally) does not need to write to SqueakV2.sources. So use
>   Symbolic Links to a shared global read-only copy. This global copy
>   can be in e.g /usr/local/share/squeak/) 
>  
>-> Write a new Squeak Source File. The SqueakV2.sources is from Squeak2.0,
>   so the code of all improvements since V2 is in the changefile. 
>   Write a new Sourcefile with 
>             Smalltalk condenseSources.

Thank you, Marcus for explaining how to do this, and how it can be made convenient for the end user.

I have two further suggestions...

	The first is that if you condense the sources, use a different name such as 
		SqueakV2a.sources
	You can do this after the fact by renaming the file and appropriately editing 
		SystemDictionary>>sourcesName
	and saving the image (which should similarly be renamed to Squeak2.3a).
	 (I know this should be suggested and supported as part of condenseSources,
	but we haven't got a Round Tuit ;-).

	There are two reasons for this:

	1.  If someone loses a reference to the file, they might think they could use
	any other copy of SqueakV2.sources, which is not so.

	2.  If you do this, then a normal Squeak release can coexist in the same
	directory as your condensed variant, and things will not get confused if
	someone does this.

	It's just a bit safer that way.

The other suggestion relates to extreme file space reduction...

	With a couple of changes, ALL files could be remote and shared.

	1.  Condense sources, thus leaving the changes file empty.

	2.  Use internalizeChangeLog to eliminate the need for a changes
	file (this will require two minor fixes which I can supply).

	3.  (optional) Change quit so you cannot save the image

This would allow someone to start up and run Squeak, essentially diskless.  If they want to save their work, they can do so using the changeSet fileout mechanism.  If they do this to a remote file then you have a truly diskless Squeak.  It would lack the wonderful property of "having everything right where you left it" when you resume a saved image, but at the same time it would give you a full squeak not only in a diskless environment, but one where each student only needs file space for their own source code in a change set.

	- Dan





More information about the Squeak-dev mailing list