Phantom OS, the 21st Century OS? 553
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."
Hmm... (Score:3, Interesting)
Two questions:
OS vs lib (Score:5, Interesting)
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... (Score:5, Interesting)
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 (Score:5, Interesting)
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... (Score:4, Interesting)
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?
Solution to the wrong problem... (Score:4, Interesting)
...now, if they gave me a desktop that no longer had files, file directories, links, and other archaic throwbacks that map directly (in a fashion) to the hardware, then I'd be impressed. Give me a "semantic" desktop like my desktop at home: The ability to quickly, and visually, rifle through documents stacked on my desk so I can find that recent copy of my dissertation I made. I don't need a filename -- just give me the document based upon some quantifiable characteristic about the document, such as keywords, format, or even the visual layout. Folders? I don't keep the stuff on my real desktop in a file cabinet, so why the hell would I want to use folders on my virtual desktop?
Re:Opera of the phantom (Score:4, Interesting)
The thing is, it's only pushing the work down a level, it's not that the work doesn't still have to be done. The "file" still has to be saved, the memory still has to be loaded and unloaded.
And it doesn't truly fix the problem of crashes and failed writes. If my program shits itself and dies before it's complete, how is that going to result in complete data? It may be complete up to the point where it died, but for many things that's not sufficient.
the idea's worked in practice before (Score:5, Interesting)
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 [wikipedia.org]:
Re:Opera of the phantom (Score:2, Interesting)
Actually the idea makes sense. When they say VM, they mean like Java VM, or .NET runtime VM. The quote you pasted has the goods: "this VM has no means to convert integer to pointer". So you can't make a pointer into your neighbour process' data unless that neighbour process gives you such a pointer, because the only way to get pointers in the first place is from malloc().
This is the basis of security in sandboxed Java applications, it's not controversial or new. IIRC MS Research is working on a similar operating system that uses the .NET runtime -- ah yes, Singularity OS [wikipedia.org].
The state save on shutdown, far from being the best thing about this OS, as far as I'm concerned is the worst thing. Even if the software written for this thing is bug-free and never corrupts its own state, hardware is not 100% reliable -- memory gets corrupted, disks get corrupted, drivers end up wedged in unexpected states due to flaky hardware.
Imagine if a BSOD-equivalent occurs due to something that got corrupted 30 seconds ago, and that state got persisted to disk. From now on, every time you turn the machine on, you have less than 30 seconds before that exact same BSOD happens. Congratulations, your computer is now useless until you reinstall your OS! Brilliant.
The obvious workaround is, of course, to save program state out regularly as files in a constrained, standard format, which is independent of your program's implementation. Other reasons you might want to do this include upgrading software and interoperation between different applications.
But of course, as soon as you admit that, you admit that the new paradigm is not actually going to be a programming revolution at all, from an application perspective. You have to be able to save your state to a file and restore it: the only difference is that now that code will get executed less. As a programmer, though, it makes no difference to me whether the code is executed once or a million times, it's exactly the same effort to write it.
The filesystem is an ugly anachronism in a lot of ways, but it's also really, really technically practical.
That said, I wouldn't be surprised either if we were using VM-based operating systems in 10 years or so. There are some really interesting things you can do with JIT compilation when the OS and application code are not divided by a giant wall. But I do think they'll have filesystems of some sort.
Re:Read About Face... (Score:5, Interesting)
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:Solution to the wrong problem... (Score:3, Interesting)
Give me a "semantic" desktop like my desktop at home: The ability to quickly, and visually, rifle through documents stacked on my desk so I can find that recent copy of my dissertation I made. I don't need a filename -- just give me the document based upon some quantifiable characteristic about the document, such as keywords, format,
Ever heard of Desktop Search?
Windows Vista this is done by pressing the start button and then typing a few letters or words. It will pull up results that match filenames, file contents, keywords, ID3 tags for MP3s, email messages, etc.
There is an advanced mode where you can specify things like when you last modified it or how big it is... etc.
OSX has spotlight which does essentially the same thing.
Do you not use computers?
or even the visual layout.
Ok, yeah, this isn't here yet. But give it time. They are still trying to figure out how to give you a useful way of specifying 'visual layout' as a search criteria. However, the document thumbnail preview in Vista or OSX is pretty good... so if you can narrow it down to a few dozen docs some other way, you can probably identify the the one you are looking for by the icon preview if it has distinctive layout. I've done it.
Folders? I don't keep the stuff on my real desktop in a file cabinet, so why the hell would I want to use folders on my virtual desktop?
I shudder to imagine what your desktop looks like. Either you don't do much. Don't keep much. Or its a holy friggen mess. I have files for different clients (real files) for paper materials. I have files for tax related items. A lot of us use real files.
And my PC is full of files and folders too. Again for different projects with countless subfolders, and clients, etc. It makes it easy to find, and to copy/move/backup them in neat blocks too.
Re:Opera of the phantom (Score:3, Interesting)
Read Inside the AS/400 [amazon.com] by Frank Soltis (or a more recent edition) and you can see exactly how they did all these things starting with the System/38 in the 1970s.
You don't have to have multiple address spaces. Heck even the first Linux kernels just used one huge address space with each process getting a 64MB chunk of that.
The System/38, AS/400 and whatever they call it this week has always had persistent "objects". They are named but they aren't files although if you squint hard enough you could claim they similar enough. Phantom is only 30 years late in claiming to be the first.
The advantage to using a VM is that code above the VM is insulated from changes below the VM. For example the very first System/38 program will still run today and in all that time they have gone through several generations of processors including changing from CISC to RISC and changing address sizes. You can still have C and assembler but they target a virtual environment rather than a concrete one with the OS doing the right thing at run time.
Re:Read About Face... (Score:5, Interesting)
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.
Re:Opera of the phantom (Score:1, Interesting)
Same goes for extensive modificatons. Maybe you decided to drastically reformat the document, but then decide the idea doesn't look good after all. You can't choose not to save, you've either got to undo 50 times, or have created a copy before starting making the changes.
How about using version control?
Here's another issue: since there's no save operation, the undo history has to be kept forever. This means that whoever you're sending the document to, if they're so inclined, can replay your writing process backwards to see if there was anything you changed your mind on. Or if using another document as a starting point, what was there before.
Who said there's no "current version of document" operation? It could even be named "Prepare for public consumption", in the File menu.
Here's another one: Imagine this sequence of commands: I type a long document, decide I didn't like the last changes, undo too much, and then press a single letter. Does in this moment the undo history become a tree, or do I lose the ability to redo the excessive undo?
Undo histories are usually treated as stacks. Maybe that should be handled differently, but it's hardly a show stopping issue. This is an issue real life programs deal with today.
On the other hand, you probably don't want a tree data structure here, unless you are comfortable with things like merging and branching in a version control system.
Re:Opera of the phantom (Score:3, Interesting)
It seems to me that a lot of your issues might just be cultural issues. For example, if you do have an "eternal undo" and don't want to pass that along, get people into the culture of exporting the file to something else when they want to send it to someone. The problem already happens, with metadata and tracking information being passed along, but people don't think about it because it's not their experience that these things get saved. If the undo was always saved, maybe people would think more about what metadata is being passed along, and actually think to export the file (or whatever clears the metadata) before they send it out.
Some of your other problems may have trade-offs. For example, it is easier to revert to an earlier version of your file when the cat runs across the keyboard if you've saved it right before you left the keyboard. But what about the case where you haven't saved it recently? Then having to hit "save" hasn't really made the cat problem any better. On the other hand, I suspect that it's much more common that people accidentally close things and forget to save them. So you lose something, but you get something too.
Or this one:
Imagine this sequence of commands: I type a long document, decide I didn't like the last changes, undo too much, and then press a single letter. Does in this moment the undo history become a tree, or do I lose the ability to redo the excessive undo?
Again, you have that same problem with "undo" in general, and your main point is, what if I want to go back to what the document was like an hour ago, but the undo (for whatever reason) isn't letting me do that. I would assume that part of the idea is to keep system snapshots so that you can still retrieve documents in a prior state. If that's not the case, it should be.
Re:Doubt it. (Score:3, Interesting)
This could be implemented as a library. It seems to be basically a class which implements "auto-serializing" (maybe activated by a system callback) and make every class which needs to save data to extend it.
This is taking Python's and such higher level languages simple libraries to an OS level and enforcing everyone to write using them, along with it's performance penalty. And that is useless, because we're seeing that switch already. The applications that use C or C++ and becoming less frequent but are still important for performance reasons.
Re:How much do you like inventing wheels? (Score:3, Interesting)
The biggest annoyance would be that you would always have to start the original program in order to open it's data with another program. I'm sure the people who think this is a good idea will point out that programs never technically stop in their system, but there's not much practical difference between starting Word from scratch and merely swapping it's entire runtime in from disk. Then you would have to navigate through whatever custom organization scheme the program uses to find the data you want and hit the "export" (or "copy") button, and then switch back to the program you actually wanted to use and hit the "import" (or "paste") button. This is as opposed to just going to the destination program, opening up a file browser, and pointing it at the file you want. This is the sort of stuff that people do all day long and the current system we use may not be perfect, but it's certainly a lot better than the proposed one.
Re:Doubt it. (Score:2, Interesting)
I hope the analogy I'm going to offer isn't too simple. Not being a programmer doesn't make you stupid or anything, but I'm going to go to a very simple argument to respond, so, first off, that means nothing personal. .AVI or .MP3 and not a text file? You wouldn't store a pile of videotapes, or CDs, or LP records in a real manila folder! An already stressed analogy now becomes less useful and more strained.
A lot of concepts such as 'files', 'folders', 'desktops', and such just don't match very well with what actually goes on in a machine. Take the 'move' operation - unlike the analog world, you never really move a file into a folder or move a folder from one desktop to another. In a PC a 'move' is really a 'copy' followed by an 'erase'. If that process gets interrupted by a power loss, say, just when that happens greatly affects what you have to do to correct the problem. The 'good' copy could be on either machine, both, or neither.
In many architectures, an 'erase' isn't really an erase either, as the file is simply labeled as blank space, not necessarily overwritten.
So, analogies such as folders are necessarily only very rough analogies to start with. Now, what happens when the file you are putting in a symbolic folder is an
There are 'compartmentalizing' words that sometimes would fit better, such as calling your folders 'directories'. You could also draw a sharp distinction between data files and program files, by calling them programs and data, rather than using bulkier terms such as 'executable files' and 'non-executable files' that don't seem to work well, and so on. But, you'd have to change a lot of graphics too, for GUI users. Right now, Microsoft is still going to default to showing a sheaf of papers moving from one manila folder to another all too often.
The issue of the metaphors becoming antiquated isn't the core. Yes they are, but the core of it is the metaphors were already not a very good fit, even back when the typical file was text that could be printed to real world paper and fit in a real manila folder.
We've been down this (exciting) road already (Score:3, Interesting)
There's little or nothing original that's being presented here. The Phantom people claim originality to the idea of orthogonal persistence [www.dz.ru], but they are flat-out wrong:
To illustrate the utility and awesomeness of persistence, there's a famous story about KeyKOS [eros-os.org], an earlier OS that embraced this notion:
The notion of a language-based OS exploiting the semantics of pointerless/"safe" programming languages in order to isolate processes, rather than the norm of executing untrusted native machine code in different address spaces, is nothing new either.
If these ideas shift your bits, take a look at some real, interesting work done by real people that have more clue than fashion:
Re:It's just a game of names (Score:2, Interesting)
BeOS (Score:3, Interesting)
BeOs is probably what you wanted then. Its files could be tagged and accessed through a relational database. That means the files could be sorted and displayed based on any criteria you wanted.