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

OS vs lib

[ultrabot]

So, what's the basic difference between what we have in phantom and what can already be done with a library/framework in, say, linux?

Not that much simpler...

[SuperKendall]

Anything is kept in its internal, "graph of objects" form. This means that Phantom programs are much simpler and more efficient also.

In many languages, you can easily serialize objects or trees of objects. I'm not sure how this differs much in the Phantom OS except that it is choosing when to serialize out to disc for you, but I don't really see that as being much simpler.

What happens when a Phantom user runs out of disc space? What if they attach an eternal disc and want some things there, or in both places for safe-keeping? All of the sudden you find you need something that looks and awful lot like Finder or Explorer to manage graph persistence locations...

And what happens when you have one file, er, object you may want to open with multiple apps? It didn't seem from the description like it would attach a single object to multiple app object graphs, just that it had easy IPC. So what happens when I want to open a JPG in my photo management app and then Photoshop?

Re:Opera of the phantom

[OG]

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

I think he's talking about programmer-land, not user-land here. Sure, users can do File->Open and see the documents they've created. As a programmer, though, you don't need to worry about creating a handle to a file, populating that file, closing the file, etc. Instead, you would just create a new object of whatever document class you need. Because EVERY object on the system is automatically persisted, your document objects are automatically persisted and you don't have to worry about file i/o, autosave, etc. It's built into the OS for all objects.

I think there are many interesting ideas behind this OS, but from an actual usability perspective, I'll believe it when I see it.

Read About Face...

[SerpentMage]

About face is a very old book written by Alan Cooper. And in the book he was very critical of things that have been completely ignored by the computing mainstream.

One of the things he critiques is the notion of files that need to read and written. That is not how people expect things to happen.

I actually think this guy is not a crackpot, but understands completely what is going on. What I think bothers people is that he is not following current dogma.

Having the OS as a virtual machine sounds very attractive because as we all know now, the virtual machine can do things that C, C++, assembler cannot.

For example with a virtual machine you have all of the metadata that you need to serialize, and transport data. With C, C++, and assembler you must explicitly say I have four bytes that need to go to point a. A big big difference in my mind.

We are already writing this code today, and it is called ORM, persistance frameworks, etc... He is just saying why not make this an operating that is part of the operating system?

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:Read About Face...

[rho]

There have been similar things tried in the past, for instance PalmOS had a behavior very similar to this, but it tends to be more trouble than it's worth.

I don't see how you can say that. The never-saving paradigm of the PalmOS was one of its brilliant features. Combined with the flash memory of the Tungsten E2 Palm reached its pinnacle IMO. Having a computer that never forgets what you've done is, really, what people expect a computer to be. It's just that we've been amateur sysadmins for so long we think it's normal.

Which is not to say that the PalmOS was perfect. I believe it could have been perfected, but they company was more interested in eating itself alive. And I'm also not saying that this Phantom OS is going to change the world. But the nature of what they're talking about is eminently non-crazy.

Your concerns are notable, but they're also not terribly obscure. I'm pretty sure they're thinking about such things.

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.