Phantom OS

[rhoenix]

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.

All of this sounds neat, but the astute nerd will object: "But you have to re-write all of your code for this Phantom thing. Seems like a waste of time to me." Possibly. Programming has come a long way since the days of the Segmentation Fault and the Bus Error. We have efficient virtual machines now, with write-once-run-anywhere functionality. Java, C#, Ruby, and even languages that don't suck - like Python - support this.

Phantom will target these VM-based languages so that you won't have to rebuild any code. However, it may not be as simple as just copying over bytecode, a developer may have to modify the code a bit to take real advantage of Phantom's "timeless" feature. Old code should still work fine. It would just be inefficient if it does a lot of file I/O.

The Phantom OS is still very much in development. Currently, it will boot on a computer, run programs and perform its state-preservation-to-disk magic trick. Cross-development tools are also in production, to automate porting code.

Still to be done is the GUI. You know as well as I: All that matters in this life is a good command line. Still, the daily-user type needs some sort of mouse. Sounds like a crutch if you ask me.

After the GUI, the next step for Dmitry Zavalishin is marketing Phantom. The best code in the world doesn't mean anything if nobody's buying. Actually, this step has already began, with Zavalishin telling the world that unlike Linux, Phantom is better than Windows.

"You can not compete with Windows, repeating it," Zavalishin says. "It is impossible to compete with Windows, creating a functionally weaker system, such as Linux." (This works best if you read it to yourself with an assertive, Slavic accent). Phantom, he says, will increase programmer productivity by at least 30 per cent - and perhaps as much as 400 per cent.

He likens this to the benefit of VM-based languages. "Growth in productivity from a simple shift in the development of C++ software programming language to Java and C# languages is estimated by experts to be as much as 500 per cent – as, indeed, it explains the displacement of the first language by the last two over quite short period of time."

Nonetheless, breaking into a market is no easy task. The mobile space, one of the markets Phantom will target, is dominated by the iPhone. "iPhone has strong brand name and it is difficult to surpass it technologically,” Zavalishin says. That doesn't mean there is no room for competition, as Google is, well, still trying to prove with Android. "Android got no one impressed," he says. "[But] Android will prepare the market of software developers.” True, Android's debut showed us that the iPhone isn't the only game in town, but it took resources on Google's scale to bring it to market. And even then, its adoption curve has been flaccid compared to the iPhone.

If Zavalishin can get hold of some of that Steve Jobs divinity, Phantom will likely do well. ®

Many interesting parts of the approach to this OS I found fascinating; in particular, how it handles "states" of objects. The programmer tooting his own horn about his creation is amusing, but I'd like to see some benchmarks when it's further along.

[phongn]

Phantom's ideas aren't exactly new, and I'm still skeptical on how well it can handle keeping consistent state (to say nothing about it's I/O requirements). It's certainly interesting, though.

[Xon]

Assuming it is something like like VM Motion (that is incremental changes are written to disk), it should be ok-ish. Especially if it is targetting small overall memory sizes.

[Davey]

I wonder about what'll happen when the program hits an error or encounters an unsolvable loop. Normally when that happens I can simply dump the memory and restart, and most of the time that will fix things. I've come to depend on that if I hit a problem that task manager or "$ sudo kill [process]" won't fix, I'd feel very uncomfortable if I didn't have that option.

[Stark]

Assuming it is something like like VM Motion (that is incremental changes are written to disk), it should be ok-ish. Especially if it is targetting small overall memory sizes.

I'm not sure what scale this OS is aiming at; at the low end it could well be viable.

[Xon]

I'm not sure what scale this OS is aiming at; at the low end it could well be viable.

The mobile space (ie smart phones, PDA's etc) generally have tiny chunks of ram with a large chunk of flash. Hooking deep into the kernel to track changed memory states is about the only way you could really do this. Add some write buffering so you are doing big writes instead of lots of little is also a must. Even then, I really doubt it works 'well' on truely large memory spaces with lots of random memory write operations.

[phongn]

I'm not sure what scale this OS is aiming at; at the low end it could well be viable.

At the low end "stateless" systems aren't exactly uncommon. Newton and PalmOS generally had applications without a save button, for example. Things just committed.

[rhoenix]

Was it just me or did the article's author have an extremely annoying arrogant bias? Ugh.

Anyway, I've heard of the idea before (under a different name), but I fail to see the point. You can use a computer like this already: do what I do and simply never close programs. If you need to shut the machine down, use the hibernate option. When you power it back on, it will be just how you left it.

If you don't have enough physical memory to load all your programs at once, don't worry about it; the operating system can work some magic to put what you aren't using away, while still being able to use everything else and recall that one program later just how you left it.

While this is true, wouldn't this lead to this sort of software approach being used on devices that don't always have a steady flow of power, such as tablet PC's and notebook PC's?

Some things that annoy the hell out of me are power outages and crashes, but power outages are solved with a battery backup and crashes are a symptom of shitty software; something I'm days away from correcting myself for almost all cases I see (along with a few other bonuses from what is actually very, very little effort).

All this stuff works. It works today with little to no modification to any of your hardware and software. No new operating system is required.

Well, I'm less interested in this OS specifically as I am its impact on the software world, similar to the ripples BeOS left in the software pond; ultimately it was more or less forgotten, but it did leave some traces behind. My thought in posting this would be that this OS' approach might do the same thing.

I generally seem to notice that a lot of software people, myself included, have the first instinct to say 'this sucks I'm going to replace it ENTIRELY' at every little step. (Or worse yet, 'this doesn't fit my religious worldview so I'm going to replace it ENTIRELY' - random example - how many times have you seen a new software library released whose only selling point is "written entirely in language X" and no other benefits?)

Many times; the same way with software porting, really. And honestly, I have no problem with this - it allows people to scratch their creative itch with their favorite language.

Part of the reason I think is that learning an existing system well enough to modify it has the perception at least as being just as difficult, if not more so, than just making something new yourself.

Sometimes, that is actually a decent decision, but it usually isn't. There is often a much simpler solution.

I think that's what happened here. Rather than actually think about the problem and see the simple answer, he said "oh hey this is a cool idea let me REPLACE EVERYTHING ELSE ENTIRELY to use it". I see that as being a huge waste of time.

I know he said he isn't trying to compete with Windows, but surely something like what I said above works on phones and such too.

While true, as I mentioned above - several of the ideas of the BeOS made their way into other operating systems, despite the OS itself failing and becoming forgotten. I'm not saying specifically that this Phantom OS will go the same way (though I would consider it likely), but I am interested in seeing what sort of impact on software design this will have.