In the more recent threads here I have noticed some confusion about the seperation of
the elements of JOS, so I am going to attempt to clarify these here.
JOS is not like its predecessors, it is not one large monolithic clump-o'-OS. First we
have JOSCore, this is the minimal OS consisting of a JOSBox and a minimal JOSystem and
no more. Then we have "JOSExtensions" the devices, drivers and services it takes to be
able to use JOS for more then the RAM equivalent of a paperweight. Running on top of
this is the "Application Level" most notably JADE and its PUI (allowing the computer
to interact with the user). This is all suspended in the lime Jell-O that is the Java
and JOS API's (I think we should discriminate between JOS API's that require JOS and
those that don't, I propose that the ones that do not require JOS be reffered to as
the JOS Extra API's -- someone give that a better name...).
An Install/Uninstall library is an excellent idea, although it is not part of JOSystem
it is a JOS Extra API (I hate to seem like Im picking on it. I'm not, it's just the
first instance I thought of...). Furthermore, JOSystem is -- basically -- just a pure
java kernel (it takes on the classic role of the kernel in most senses and buffers
between everyone and the real kernel in the other cases) and an appplication runner.
The JOSBox is the computer were writing this OS for, in a sense. It is the virtual
hardware the JOSystem "kernel" is running on, if someone made this into real hardware
a modified JOSystem would run JOS on it directly. It is the true kernel and the JVM. A
JOSBox application could be made sans kernel, this is how you could run JOS on a
non-JOS machine; the JOSystem would require extra features the JOSBox supplies to run
so just running it on "any old VM" would be painful, a special JOSBox would be the way
to go. The main benifit of this I see is not in having a showcase for JOS but in
having a multi-process java environment running on ones computer, allowing (with minor
modification) to let the OS "launch" Java apps into this environment/quasiOS cutting
down on memory and start time (people would get to tour JOS then get to keep a
powerful tool like that). I think we should get a kernel/VM JOSBox up then modify it
to be an "emulator" JOSBox later on, just my opinion though.
JVM incompatabilities might be solved with the exokernel design. Exokernel is
basically a blank slate of a kernel that allows libraries to be plugged into it to
provide optimal hardware use (and, of course, having a default library for legacy
apps). Whats this have to do with JVM's!? Good question, say we have most of the stuff
that makes a JVM and then have little libraries filling the rest in, in a release
compatiable manner. That is, we have XVM (exo-VM) with a JDK 1.0 library, a 1.1 lib
and a 1.2 lib. I don't know how well that would work, but its worth a thought.
Cheers,
DigiGod
_________________________
Quote of the Moment:
No, I'm Canadian. It's like an American, but without a
gun.
-Dave Foley
_________________________
Prank of the Moment:
Using the conferencing feature of your office phone, dial
one Induhvidual, then while it's ringing dial another and
conference them together. Put your own phone on mute
and listen to see how long they'll make small talk before
figuring out that neither one placed the call.
O-
----------------------------------------------------------------
Get your free email from AltaVista at http://altavista.iname.com
_______________________________________________
General maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/general
