Phantom OS
Submitted by Stephen Crawley on Mon, 02/09/2009 - 07:59.
I came across this article in "The Register" that talks about an interesting new operating system called Phantom OS that is being developed by a guy in Russia.
There is not much to look at yet. No source code is available, and the material on the website is very sketchy. In fact, it is impossible to tell if this isn't all just vaporware, let alone whether the implementation approach is practical. (Inventing your own VM instruction set / assembly language? WHAT??)
The idea of basing an operating system on persistent objects rather than files is (IMO) really cool. Aspects of this have been tried before in various ways (Grasshopper, PJama, Kissme to name some examples), but no-one has really succeeded so far.
This is the kind of thing it would be interesting to implement using parts of the JNode codebase. (And before anyone flames me, no I'm not suggesting we turn JNode into Phantom OS. This is just a suggestion for someone who wants to take a big leap into the unknown.)
- Login to post comments
FYI
http://code.google.com/p/phantomuserland/
dz
Interesting stuff
Having a global persistent database is all well and good, but at some point someone will still insert a USB stick, and at that point you still wind up needing filesystem drivers. At that point I guess you wind up either unifying the two or expecting apps to handle both APIs.
Are there any object databases which would be feasible for such a project? I have investigated db4o before, and at the time they wanted you to load the whole database into memory. One would hope that they would support memory mapping by now but I don't know either way. Loading the whole database into memory is ludicrous except in the most extremely small cases. I suppose if the system never needs to reboot then it's okay too.
You could probably do some fun stuff with the object tree plus OSGi, with each app in a separate bundle, and each bundle getting a different object tree to store their data, while apps can go through other bundles' APIs to get at their data in a programmatic fashion (so the Mail app would go via the Address Book API, the address book data itself being accessible only via that API. As long as the impl class isn't exported from that bundle, callers will receive a proxy instead of the actual thing handling the data storage.
)
You wouldn't ...
Are there any object databases which would be feasible for such a project?
You wouldn't implement object persistence that way. Instead you would implement a native persistent store that behaves like virtual memory with object granularity that survives power-off / reboot. There is 20+ years worth of research on how to implement orthogonal persistence.
"that way"?
I don't really care about the means of implementation, I just wondered if there was one around which was feasible to use.
As far as "orthogonal persistence", I'm not a big fan, because there are reasons why you would want some things to not be persistent, such as: (a) the state is what caused the crash, so bringing the same state back will just make it crash again, and (b) storing every little change to disk is much slower than storing only what you need to disk.
Re "orthogonal persistence"
(a) the state is what caused the crash, so bringing the same state back will just make it crash again,
If the state in question is OS state, that's an OS bug ... roughly equivalent to a broken root file system crashing Linux. Hopefully one would have a "repair" utility to fix such things. Or one would fix the OS to make it more robust. (Even in a fully persistent OS, you would expect core OS data structures to be non-persistent, and that they would be rebuilt each time the OS booted.)
If the state in question is application state, that's an app bug. The user may have to sacrifice the "document" that is broken.
This kind of scenario sounds more scarey, but there are analogs in the classic file-based world, and we don't know if this will really be a problem once the OS bug level has been reduced.
(b) storing every little change to disk is much slower than storing only what you need to disk.
Classic Orthogonal Persistence implementations only stored stuff when a "checkpoint" was requested by the application. This avoids the cost of lots of little saves
However, checkpointing has other problems if applied in the context of an OS. For example, it is difficult knowing when the system has reached a consistent state (*) suitable for check-pointing, and some applications really need to be able to control the timing of their own check-pointing. My gut feeling is that the way forward is some combination of transparent persistence with some form of transactions.
(* An alternative is to checkpoint inconsistent states, but include the thread(s) that are in the process of moving to the next consistent state.)
I also noticed it. It was on
I also noticed it. It was on OSNews and Slashdot too and the Phantom FAQ is here: http://www.dz.ru/en/solutions/phantom/.
At first it looked like something newish and intersting but as you say there were quite a few attempts in this direction already. I even remeber a JSR proposing orthogonal persistence for the JVM which was discontinued. Now Phantom OS looks much more like a phantom to me wich has releasd a FAQ so far with lots of provocative statements to generate discussions on the net what it succeeded. Never the less the idea of orthogonal persistence, preserving OS state between restarts or in a smaller form support for migrating procresses (isolates) from one JNode instance to an other (which also involves saving some state on one side and restoring it on the other, then continue to operate) are things that I'm thinking about but I think there are a lot of other things which are more important and urgent right now (if someone wants to specifically work on such topic soon that still fine with me). If we get to the point to implement such thing a big help for JNode might be that it is a completely object oriented OS. And at this point, if we do not consider the persistence side of it, Phantom OS has a lot of similar underlying ideas to JNode since it's also created in some kind of safe language, which doesn't allow arbitrary access to memory, it's completely object oriented, it has a single address space, and it's like JNode without isolates, since it has no concept of process, it has only threads.
I think JNode will not be a phantom OS because unlike Phantom OS which gives us a FAQ so far, JNode already provides quite a lot more and you can get involved in the development today and with some effort you could already use it for certain tasks as well.