This seems to be very hot, dizzyingly close to the jackpot. Two tightly related questions:
1) The idea here is that nesters are strictly OS facilities, is it? There's no expectation that a nester can be user code—that a user can write his or her own nester application and run it as he/she would any other executable binary, or is there?
2) There's no expectation that nesters can "intercept" messages to fictitious children, or is there? By fictitious children I mean child nesters or applications that don't actually exist in the VM system's tree of VMs, and instead are just "made up" by the nester. But in truth anything that can send and receive messages is just as much a real process as any other. Think recursively-nested dynamic HTTP servers, or a Unix mount(1) that mounts (arbitrary)* processes instead of files. Or having a conversation with someone else's imaginary friend ... and then with their imaginary friend's imaginary friend. ;)
In the spirit of Plan 9ish userspace mount, some nesters do have to be fast, but not everything has to be fast to be a nester. And not everything has to be reliable or trustworthy to be a nester, either. Also, nesters should have direct access to the state of all their descendants—grandchildren and so on—at least as a matter of principle. Note that a nester which exposes "fictitious" children automatically has such access to the state of those children's descendants.
* A file being a special case of a process. (And distinguishing files from file bodies, the immutable/abstract values that may be the state of some given file at some time.)
P.S. If anyone can assist me in finding the Fluke or Flux OSKit source code, that would be appreciated. The Utah FTP server appears unresponsive from my end, so I'm looking for mirrors.
Do you have a reference for what license Fluke is available under or the others? The website gave one for OSKit but not Fluke. Additionally, I just found a GPL in /dist on FTP server but wasn't clear if that was GNU tools or Fluke, etc.
Clarifying on web site or FTP might help future researchers thinking of building on this stuff. It was landmark work for its time after all & still interesting. ;)
That's a REALLY good question. I just dug through the site on Wayback Machine and FTP server without finding that. I found GPL license file but it's not clear if it was just for the GNU tools or whole project. Also looks like a template they didn't fully fill in. Neither site nor DTOS paper referencing it mention a license.
Now, I know that many projects have used OSKit in open-source software and I haven't heard of a problem. I just found a license for it:
If you're doing a practice project, there's probably no harm in using Fluke work. You can always contact them if unsure. However, it seems like the work was intended to get out and be built on (definitely OSKit). Far as academia and industry types, this work has long been superceded by other tech and government contracts by those involved. I doubt they'd feel threatened.
Just my estimate on the situation. Never guarantees. Except for OSKit given its license.
> that allows recursive virtual machines (virtual machines running on other virtual machines) to be implemented efficiently.
Does this mean one can dream of: compiling HotSpot's C++ source to WebAssembly, load the JVM in the browser, load a jar, and expect decent performance?
JigSaw allows some lightweight and modular JVMs, and wasm could be just another target architecture.
1) The idea here is that nesters are strictly OS facilities, is it? There's no expectation that a nester can be user code—that a user can write his or her own nester application and run it as he/she would any other executable binary, or is there?
2) There's no expectation that nesters can "intercept" messages to fictitious children, or is there? By fictitious children I mean child nesters or applications that don't actually exist in the VM system's tree of VMs, and instead are just "made up" by the nester. But in truth anything that can send and receive messages is just as much a real process as any other. Think recursively-nested dynamic HTTP servers, or a Unix mount(1) that mounts (arbitrary)* processes instead of files. Or having a conversation with someone else's imaginary friend ... and then with their imaginary friend's imaginary friend. ;)
In the spirit of Plan 9ish userspace mount, some nesters do have to be fast, but not everything has to be fast to be a nester. And not everything has to be reliable or trustworthy to be a nester, either. Also, nesters should have direct access to the state of all their descendants—grandchildren and so on—at least as a matter of principle. Note that a nester which exposes "fictitious" children automatically has such access to the state of those children's descendants.
* A file being a special case of a process. (And distinguishing files from file bodies, the immutable/abstract values that may be the state of some given file at some time.)