Phantom OS, the 21st Century OS?

jonr writes "Phantom OS 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."

Comments

Doubt it.

[SatanicPuppy]

Yes, yes, very interesting.

Is it volatile? If it is, then no thanks. If it isn't then it must be written to disk, in which case it's simply a regular file with a spiffy interface. Does that interface take up memory? How does it handle locking conflicts? How does it handle paging?

FTFA it's more like a virtualization system that takes constant snapshots of the system states, and reverts to them if there is a power loss or a shutdown or whatever. Fine. Cool.

But TFA skips over (in true Register style) any possible downsides to that. I'm a typical geek. I have 20 things running at any given time. Over time, with a traditional software system, there are enough page faults that when I roll back around to something I opened yesterday, the performance is extremely slow while all the states are being loaded back into active memory (and the states of something I'll need in 5 more hours are being written to disk).

If I'm persisting my whole filesystem in that fashion, there are quickly going to be issues. If I'm not, then there is some bullshit in there somewhere. They may have a fancy file allocation table, they may have some fancy I/O tricks, but their stated abilities are frankly contradictory, because the state is not being maintained, it is simply being preserved, and the difference is only subtle linguistically.

In short, the Phantom OS sounds more like the Phantom game console than anything I'd want to run on my computer.

Re:Doubt it.

[Anonymous Coward]

How does it handle locking conflicts? Well, think about it, how do you handle locking conflicts in your program? That is your answer.

You try, fail, and your program crashes.

At least, that's how most programmers handle anything to do with locking.

Re:Doubt it.

[SatanicPuppy]

I still don't buy it. They're throwing an abstraction layer on top of a regular system and calling it something different, but all the underlying structures are the same.

Except they're not because you're basically forbidden direct access to any system resources! Any gains that you would traditionally expect to be able to make through use of C or assembly are right out the window, and that is acknowledged right up front.

Hardware abstraction is going to have a cost. All virtualization has a cost, and I'm not sure that this is the way to handle the problem. It seems more like a pipe dream than a practical application.

Re:Doubt it.

[black6host]

I mean no offense, but I can't help but read your comment and see myself, many years ago, feeling much the same when moving from DOS to Windows. I lost a level of control, at the hardware level, that made me question why I would want to give up peeking and poking video memory, etc. Back then, direct control meant a world of difference in performance. Of course, I have many more options now than I did then, and if I still want to get to the hardware bad enough, I still can. But I don't feel the need to nor do I feel the abstraction has held me back. We can do much more now, than we could then....

Not to say that the OS in question is the way to handle the problem or not, but I've become a little less resistant to change, a bit more willing to be open-minded and much more appreciative of pioe dreams :)

Opera of the phantom

[mcgrew]

I skipped the Register article and went to the Phantom site, and I'm still puzzled. Somehow I get the idea that somebody's trying to snow somebody.

Q: [does phantom have] separate address spaces?

A: No. No! At this point you thought to yourself something like "than Phantom can not protect one application from another", and were wrong. Phantom is one big address space. But, nevertheless, everything inside is protected. Protection is based on a simple idea. Phantom is a big virtual machine. And this VM has no means to convert integer to pointer - due to this it is impossible to scan through address space and gain access to anything you have no pointer to. That's simple. And - yes, due to the absence of separate address spaces IPCs are really cheap in Phantom. And there are no context switches, which add effectiveness to the system. One can argue that VM makes system run slowly, but nowadays this problem is solved with effective JIT compilers, so we don't expect real degradation due to the VM. Moreover, the result of JIT compilation can be stored so usual Java-like startup penalty won't exist in Phantom either.

Memory in all computers is mapped to address space. I get the idea that these guys are programmers who don't really understand how the hardware works.

Q: File system?
A: Nope. Sorry. Nobody needs files in Phantom. All the operating system state is saved across shutdowns. Phantom is the only global persistent OS in the world, AFAIK. All the state of all the objects is saved. Even power failure is not a problem, because of the unique Phantom's ability to store frequently its complete state on the disk. The most unusual Phantom property is its hybrid paging/persistence system. All the userland memory is mapped to disk and is frequently snapped. Snapshot logic is tied with the common paging logis so that snapshots are done cheap way. From the application point of view it means that all the user documents or any other program state doesn't have to be squished into the linear filespace with the help of the serialization code, as it is in classic operating systems. Anything is kept in its internal, "graph of objects" form. This means that Phantom programs are much simpler and more efficient also. Opening text document in classic OS means reading file (transferring its data to specific place in process memory) and then converting its contents to program internal form (decoding and once more moving data), and just then - showing it to a user. Opening text document in Phantom means just executing some object's printMe() method - all the data is ready and available directly without conversion.

Nobody needs files? How, exactly, can I retrieve a document then? This FA is damned short on details.

Q: OS is based on VM - does it mean that not all the possible programming languages will be supported?

A: Yes. Say goodbye to C and Assembler. On the other side, everything is in Java or C# now, or even in some even more dynamic language, such as Javascript or even PHP. All these languages will be supported.

I really don't think I'm interested in this OS. TFA didn't point to a single thing about it that would lead me to want it, except for the state saving on shutdown, and I doubt seriously that's going to work. If your data are in memory and not the hard drive when it quits, you'll lose your data. If data are all written instantly to the HD, your PC will be slower than molasses in january.

Re:Opera of the phantom

[The End Of Days]

So there's something wrong with a dude scratching an itch and having a little fun with it? There was a time when Linux was a niche system that had no real purpose aside from the fun of making it. That seems to have worked out well.

In any case, there are interesting concepts in here that deserved to be explored, and the best way to explore programming concepts is the program them.

IBM already did it

[ebunga]

The S/38 and AS/400 have done this since like 1980 in COMMERCIALLY PRODUCED systems.

How much do you like inventing wheels?

[jandrese]

Oh boy, I can't wait for every application to have to invent it's own directory system to store saved state in, since it can't just use the filesystem to save the file to like in the old days. I bet it will be all kinds of fun to try to get your data from one application into another, especially competitors applications. Not to mention the pure joy that making an incremental backup on this system must be.

This seems like a throwback to old IBM mainframes and PalmOS. It's fine if your users don't mind being more or less locked into their applications and don't want to move data around very much, but it's crappy when they want to do more sophisticated things like compressing and emailing the document they're working on.

In short: This is a compatibility nightmare. There is a good reason full fledged systems don't use it.

Re:Screenshots...

[mrjb]

Screenshots can be faked: user@phantom$ But according to this page, it's about 90% unimplemented. Someone please tag the article 'vaporware'.

It's just a game of names

[mangu]

From what I read, these "objects" are nothing but a fancy new name for files. For instance, if you are writing a program in Python you don't save a file, you pickle an object. Oh, wait, that's exactly what Python is able to do right now, in any OS that implements Python! Doh....

FTFA:

does it mean that not all the possible programming languages will be supported?
A: Yes. Say goodbye to C and Assembler. On the other side, everything is in Java or C# now, or even in some even more dynamic language, such as Javascript or even PHP. All these languages will be supported.

Think of that: you cannot program in C, but you can write programs in PHP or Javascript. How cute! I suppose it supports Logo, right?

the idea's worked in practice before

[Trepidity]

IBM also took the approach of ditching files, and just having persistence of objects (which yes, presumably somewhere in the bowels of the OS got written to disk). It was efficient enough to run on 1980s hardware, so I don't see a reason it couldn't be done today.

From Wikipedia:

In most computers prior to the System/38, and most modern ones, data stored on disk was stored in separate logical files. When data was added to a file it was written in the sector dedicated to this, or if the sector was full, on a new sector somewhere else. In the case of the S/38, every piece of data was stored separately and could be put anywhere on the system. There was no such thing as a physically contiguous file on disk, and the operating system managed the storage and recall of all data elements.

Re:Read About Face...

[mabinogi]

The only real problem with this guy's concept is that he's effectively going to rewrite the concept of a Smalltalk Image in Java.

If you read his FAQ, every point can be answered by Smalltalk. (And could be 30 years ago).
Unfortunately I have a feeling he's never seen Smalltalk, so he's going to re-implement it poorly.

Re:Hmm...

[Xtravar]

How is it licenced?

It's not called a license anymore. Licenses are a thing of the past! It's called a "contractual object". And they're not written by lawyers, but "documentary artisans".