OS design...

[David Jeske]

I agree with everything else you said above this point, although here
I think you are ignoring some very important issues when heralding the
distribution of software in source form.

On Tue, Oct 20, 1998 at 12:47:45PM +0200, Francois-Rene Rideau wrote:
> > 	1) Compiled code produced by earlier versions of the
> > 		compiler.  A commercial application's customers [...]
> 
> First answer: FUCK with software hoarders who won't make the sources
> available for recompiling! Second answer: they can distribute
> uglified/optimized/otherwise_transformed source, if they fear we'd see
> through them by looking at their code (but we don't need to; they're all
> too obvious). Third answer: if they want to be nasty, then the burden
> to recompile their components with 100 different targets is up to THEM;
> of course, there can be standard tools to automatize it, in the form of
> a standard, cacheing, server, that takes the (private) source and the
> (public) compiler specs handled by customers, and outputs an according
> binary. [My, I've described already it in the TUNES list a few years ago;
> surely this should be written down on the web pages...]

Source is fragile. Source, because of it's role in the development
process, is something which can easily fail to compile based on tons
of different interdepdent parts.

Having software 'fail' is not useful to the user. Thus, distributing
it in something close to a traditional 'source' form is not a good
idea.

Distributing source only works well in the old-school monolithic
software UNIX model. As software becomes more modular, it becomes very
difficult to get the right versions of all the libraries necessary to
compile a package from source. This is not something which should be
happening under the end user, at least not until we completely change
the concept of 'source' into something which is rigidly bound into the
system around it, something which isn't so fragile. 

Those are (for me) the distinguishing facets which make a "VM"
different from "source". For example, JavaVM is practically source
form already, you can run a simple 'decompiler' over it and have the
source back. The difference is that the VM is specified in a rigid
form which has already been resolved against the externalities you
wrote into the source code. Those externalities are explicitly listed
in the VM representation. I don't think the JavaVM is good enough at
this, because I should be able to uniquely resolve a dependency with a
better method than just a "class name".

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net