["Dines, Eric" <Eric.Dines@iluka.com> writes:]
>Are there any new experimental Op Systems techniques or prospective new
>directions on the horizon that VSTa may embrace?
>ie What's next on the agenda?
First thing is to get VSTa current with all those PCI systems--before ISA
disappears and VSTa can't be run on modern systems!
Longer term, I think I agree with Linus that the real game is what runs on
top of the kernel. I've mentioned Squeak (www.squeak.org) in the past, and
still think this is a very interesting system. I have reservations about
the fact that the Smalltalk runtime philosophy is that any problem in any
function can jeopardize all other functions. I think in this day and age it
simply isn't good enough that your mail, editing, news, and browsing is all
at risk from any fault.
You can run more than one virtual machine, but then you lose the ability to
seamlessly access any type of data from any other appropriate application.
This approach seems to give up much of the power of the OO environment.
So I've been pondering multiple VM's, but with really tight integration of
mechanisms similar to Java's object serialization. There'd be one VM which
owned and maintained the display. This VM might run some core set of
trusted tasks. Then additional VM instances would be fired up; the display
object in these additional VM's would be the remote handle of the single
physical display. The bulk of the work would be mapping out (based on trial
and error) which kinds of objects should be private to a VM instance, and
which should be shared. Also, how sharing is implemented, and so forth.
My current imaginings is that VSTa would make a pretty good OS to host the
VM's--it would handle clock ticks, filesystem, disks, and all that low level
stuff. When you logged onto VSTa, your VM would fire up to provide your
base GUI. As you invoked actions, other VM's would seamlessly be called
into existence. As you hacked on some app and blew up your entire runtime
environment, that VM would be debugged/scrapped, but your primary VM and all
other VM's would be isolated and thus undamaged.
Andy Valencia
Received on Fri Dec 17 11:33:55 1999
This archive was generated by hypermail 2.1.8 : Thu Sep 22 2005 - 15:12:56 PDT