It's nine degrees Fahrenheit in Moscow right now. That's the kind of cold that makes a man concentrate on his work so he can keep from remembering that the tears the wind blows out of his eyes will freeze on the side of his face before they hit the ground.

In the middle of this icebox, Dmitry Zavalishin is cooking up a new operating system. He calls it Phantom. Phantom is a different approach on the OS than any other out there, with the primary goal of being immortal. In Phantom, powering off the computer will not cause programs to lose state. They can pick up where they left off as soon as the machine is turned back on.

There are a few obvious uses to this sort of technology - medical, military, and mobile - where automatic state preservation will save the programmer from a lot of mistakes and wasted time. But there's also a possibility that the increased productivity may give Phantom some headway into the commercial server market.

To accomplish this automatic state preservation, Phantom continuously snapshots system memory on to disk. At first glance, that seems like a big synchronization problem: All the programs running should have to pause while the snapshot process reads their internal state. However, if you design the operating system around this goal, the process isn't that intense. The fundamental competency of Phantom is creating this snapshot cheaply, without disturbing current processes.

As a side effect of this design principle, Phantom's programming model is different from what developers are used to. To store persistent data in something like Windows or Linux, you need to explicitly write it to a file. Inventing an object serialization scheme can be tricky and error-prone, especially if your object structure is highly connected. Some languages, like Java, provide basic serialization functionality, but in complicated programs, you still need to remember exactly what state needs to be persisted through invocations of the code.

For example, in something like Microsoft Word, you can't just save the user's document to disk. You have to know whether they checked the “bother me every four seconds with helpful hints" or freeze the system for thirty seconds while you launch a help program when I press the button by accident" preference boxes. All that has to go to a file as well.

Because of this different line of thinking, Phantom doesn't have files. Well, there are no files in the sense that a developer opens a file handle, writes to it, and closes the file handle. From the user's perspective, things still look familiar – a desktop, directories, and file icons. But a file in Phantom is simply an object whose state is persisted. You don't have to explicitly open it. As long as your program has some kind of reference to that object, all you need to do is call methods on it, and the data is there as you would expect. That's definitely an advantage in an unstable environment.