OS design...

[Francois-Rene Rideau]

>>: Fare
>: David Jeske

[About distributing source]

> 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.
So what? That's what "stable releases" and stable version branches all about.
See Linux version numbering, CVS branches, etc.

> 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.
Source code encourages bug fixes and isn't incompatible with stability.
See RedHat Linux vs MS Windows.

> Distributing source only works well in the old-school monolithic
> software UNIX model.
I don't think RedHat Linux is monolithic. Hundreds of RPMs.

> 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.
Which is what RPM is all about (also, make). Certainly it's not perfect.
I hope we can do better in a fully reflective system, where we can develop
system-wide consistent tools instead of multi-level kluges
(rpm, make, configure, CVS, etc).

> This is not something which should be
> happening under the end user [...]
The end-user uses pre-packaged co-released things.
Again, see SLS, Slackware, RedHat, SuSE, Debian, etc.

> Those are (for me) the distinguishing facets which make a "VM"
> different from "source".
Uh? From source to a VM, you compile code from one language to the other,
losing some of the original specification (semantics or lack thereof),
and adapting to a given target. The lowest-level the VM, the more information
is lost and added in the process. Distributing source ensures the semantic
integrity of the original program, and prevents semantic noise from being
introduced by the intermediate VM.

> For example, JavaVM is practically source form already,
> you can run a simple 'decompiler' over it and have the source back.
JVM sucks. It's a very bad way to transport source; plus it introduces
lots of noise, and hypes lots of people into being even dumber.
If you want to transport source-code, go to the real thing.
See Juice technology.

> 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".

What difference does that make? It's not a VM vs source issue at all.
It's a matter of being able to uniquely identify "external" objects,
using some ultimately *global* naming of objects (extensions)
and projects (intensions). It's also a matter of being able to track
versions/releases of projects, as above.

## Faré | VN: Уng-Vû Bân   | Join the TUNES project!  http://www.tunes.org/ ##
## FR: François-René Rideau |    TUNES is a Useful, Not Expedient System     ##
## Reflection&Cybernethics  | Project for a Free Reflective Computing System ##
As far as natural selection applies to the human world, we don't ever get to
"let nature decide", because we ARE part of that nature that decides. Hence,
any claim to "let the nature decide" is just a fallacy to promote one point
of view against others, or to ignore one's responsibilities.