What about this?

[Fare Rideau]

>: Maneesh

> Sorry for bringing out a beaten topic.
You're welcome. Perhaps a search on the mailing-list archives would help...
	http://www.tunes.org/~tunes/doc/mailing-list.html
	http://www2.tunes.org/tunes/list/

> I saw the Juice page, very impressed.
Impressive.

> OK mind differentiating between slim and fat.
> I am assuming fat means bin+source and slim = ?

Nope, FAT binaries, as popularized in MacOS since the m68k->PPC move,
are binaries that include object code for every platform they must run on;
other platforms cannot run them (least they use some expensive emulation).

Bytecodes code contain some code for a low-level "abstract machine"
(usually stack-based as in JVM or old Caml-light), to be interpreted
(though it's still possible to compile them, at a cost).

Virtual Processor code, as in ANDF or TAO OS, contains RISC code for
a pseudo-processor that more-or-less maps existing hardware, to be
assembled and peephole-optimized into local code by a back-end.

SLIM binaries (as in Juice) contain compressed high-level abstract code,
to be compiled by the back-end. If you consider compression as an optional
or orthogonal issue (which it is), then some LISP/Scheme systems
have been doing that for years, too.

For static code distribution, I propose the concept of FIT binaries,
that contain high-level code (as in SLIM), as well as arbitrary
compilation tactics (usual FAT being but a very very stubborn special-case),
to help the back-end straightforwardly optimize the code.

Now, as David Manifold remarked, for dynamic distribution of code
in an active network (rather than static CD-ROMs or such),
the exact format in which code is moved can be negociated between hosts,
so as to minimize overhead, so as to minimize code conversion, recompilation,
endianness/wordsize adjustment, library copying, etc, etc.

Negociating hosts can do much better than even FIT binaries,
(which are still useful when negociation is too costly or impossible).
The remote network storage of unnecessary trusted parts that you suggested
is just one of the many things that could be done.

## Faré | VN: Уng-Vû Bân   |    TUNES is a Useful, Not Expedient System     ##
## FR: François-René Rideau | Project for a Free Reflective Computing System ##
## Reflection&Cybernethics  |          http://www.tunes.org/~tunes           ##
Man usually avoids attributing cleverness to somebody else -- unless it
is an enemy.
                -- Albert Einstein