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."
Opera of the phantom (Score:5, Informative)
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.
IBM already did it (Score:5, Informative)
The S/38 and AS/400 have done this since like 1980 in COMMERCIALLY PRODUCED systems.
Re:Doubt it. (Score:5, Informative)
Frankly you are thinking like an old operating system.
How does it handle locking conflicts? Well, think about it, how do you handle locking conflicts in your program? That is your answer.
The idea from this Phantom OS is that you don't need to think about "paging", or "locking conflicts" etc. You only need to think about your objects that are serialized to the system. Contention? Well create a server process. Think Erlang...
Here is I think his link...
http://www.dz.ru/en/solutions/phantom/ [www.dz.ru]
Re:Screenshots... (Score:5, Informative)
Anyone ever hear of Multics? (Score:3, Informative)
Unix was inspired by Multics.
As for eliminating languages to prevent bad code, it's been done too - by Pr1mos, on Pr1me Computers, which you may notice doesn't exist any more. So it's not so much "we prevent you from doing bad things" as "we make it hard for you to describe bad things to do so we don't have to work hard to prevent you."
Those who will not learn from history have to make their own mistakes at their own cost. History matters.
Re:Doubt it. (Score:3, Informative)
You say that as if you have some better idea. What exactly can you do if you are regular unprivilaged process. You try, you fail, ideally sleep your I/O thread for a little while and then try again. That is all you can do; after some number of revolutions you might as well abort and tell the user sorry.
Yes, well known idea. (Score:3, Informative)
Right. "Persistent object store" machines have been around for years. In addition to the ones listed above, the Go Computer (the first tablet machine) had a persistent object system.
There are some good points and some bad points to this. On the plus side, one of the big problems today is that support for "big objects", things one calls across a protection boundary, is lacking in many operating systems. There's no standard way to talk to protected middleware, like a database. (Notably UNIX/Linux, which still has at best mediocre interprocess communication.) This problem has been addressed many times, usually badly. OLE, CORBA, etc. are attempts in that direction, as are the ways the DLL concept is abused to create "big objects" with some autonomy. Many middleware apps have their own custom approach to talking across a protection boundary; MySQL is an example. Phantom at least is trying.
Major downsides are 1) it's weird, 2) you have to trust the compiler and storage manager to manage pointers properly, 3) it can lead to excessive paging I/O, and 4) if anything gets screwed up in a persistent-state machine, it's hard to unscramble the mess.
The last item is important. Databases, with all their elaborate interlinking and indexing, have the same problem, and database developers put vast effort into maintaining the integrity of the database even when applications go bad. Phantom has to do that too, at a finer-grained level. To some extent, so do applications. Memory leaks or uncontrolled object growth in persistent object systems are, well, persistent. Restarting doesn't help.
It's not a stupid idea; good systems have been built on this approach.
Re:Opera of the phantom (Score:5, Informative)
Heard of this idea, and disagree completely with it.
Continous autosave isn't a technically difficult problem. It could be implemented quite easily. But it would take one minor inconvenience, and replace it with several more difficult ones.
Ok, so you don't have to save anymore. Great. But now you have to deal with that you went to make tea, and your document now has your cat walking on the keyboard saved in it. You can't simply choose not to save, you have to figure out how many changes to undo to get the document to its pre-cat state. How many times do you have to press the undo button?
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.
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.
It also removes safety: I spend much time telling people that they can't easily break anything. With this system they can. Somebody who accidentally selects and overwrites the whole document will find out that even pulling the plug won't bring the document back. Now there's one excellent way of making a newbie really freak out. What if you intentionally or by accident write something insulting in the document? How do you make the program remove the record of it?
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?
Resuming: You remove one small thing, the need to explicitly save, and add the requirement of eternal undo (potential issues with embedded images here), requirement for the user to understand the undo system, requirement to design it in such a way that hours of work can be undone without getting RSI, add potential problems with disclosure of things that the user doesn't want to disclose, make it harder to do large experimental changes, and remove a way for an user to completely revert a change.
IMO this is too much of a mess for so little benefit.
Re:Oh really? (Score:3, Informative)
Sounds like MUMPS (err..ummm...Cache?) to me....
S MYNODE=^SOMEGLOBAL(INDEX1,INDEX2)
S MYVAR=$P(MYNODE,"^",1)
S MYVAR=MYVAR+" BET YOU THOUGHT THIS WAS GOING TO BE MATH, DIDN'T YOU?"
S $P(MYNODE,"^",1)=MYVAR
S ^SOMEGLOBAL(INDEX1,INDEX2)=MYNODE
Wow...we never opened OR closed a file, but the next time I reference ^SOMEGLOBAL referenced by INDEX1, INDEX2, darned if the first up-arrow delimited piece of the returned value doesn't have the string "BET YOU THOUGHT..." appended to it. MUMPS (err...ummm...Cache...) must be a really advanced language if it's already doing this "Phantom" stuff already.
(In reference to the above: Slashdot really needs a "sarcasm" tag...)
Re:Read About Face... (Score:3, Informative)
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.
That's not really true is it. With C++ I can get a library that serializes my object, transmits to a file, or over a network, or to a cluster via MPI and then reconstructs it at another point or on another computer (e.g. Boost Serialisation, Boost MPI etc.). It's just isn't a language feature, it's a library feature. Because it's a library feature it can be harder to use than say Java. That's the trade off, flexibility and performance over ease of use.
Some people might say that flexibility isn't important any more. Well... for me it is. A language like C++ gives me a huge range, I can program anything from embedded controllers to operating systems, to video games, to large computational simulations in it. There are few other languages with that versatility.
Re:Sounds lucrative.. (Score:3, Informative)
The guy must be just another cracked out developer..
None of the ideas in this OS are new. They have been around for decades. He's just taking one more shot at implementing and popularizing them.
Re:Doubt it. (Score:4, Informative)
Macintosh has always called directories folders, so it predates Windows 3 by at least 6 years.
Re:Read About Face... (Score:3, Informative)
...why should she have to learn about RAM and hard drives and filesystems just to type up a letter...
Because volatile RAM happens to be one of the limitations of computers still to this very day, as it has been from the time when solid state memory replaced the earlier magnetic cores.
If all computers were 64 bit and had at least 500-1000GB of non-volatile fast RAM, computers could do exactly what Grandma wanted. Such a computer would never really "boot" because all OS type programming would be installed by the manufacturer into memory, rather than a mechanical or solid state storage device. There would only be ONE fast main memory system where everything would stay as it as last written. A given piece of data would occupy a section of the address space until that space was released for other data. Data would seldom be moved around, but only memory pointers as move, unless two copies of the same data were needed.
Is this for real ? (Score:2, Informative)
I want to know which kind of drug this guy take. He have some kind of Linus complex, thinking he can rewrite the history or something. For what i know, most computation intensive clusters are running on some flavor of *nix system, and i don't feel like flying thousands of kilometers to go type my command on a local terminal. I prefer to stay at home and use a nice ssh to do this. Call me when windows have a native ssh daemon.
From the website
Q: Is Phantom a POSIX-compliant system?
A: No. It is possible to layer POSIX subsystem above the Phantom native environment, but it is not an idea per se.
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.
So, no POSIX, no C, everything in slower, scripted languages...
Is this guy for real ?
Re:Doubt it. (Score:3, Informative)
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 .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.
AmigaOS has a system called "Workbench". It's of course exactly the same concept, but the naming is slightly different to fit around the metaphor of a real physical workbench. Data that you work on (text, pictures, movies etc) are "Projects", programs are either "Tools" (programs for editing projects) or "Utilities" (programs that basically stand alone) and directories are "Drawers". So, you "open a drawer and start using a tool to work on a project (which is probably stored in a different drawer)". I always rather liked the metaphor there compared to the whole "office" feeling with folders and files. It's still not perfect of course, but it's got a sort of charm to it.
(to clarify the difference between "Tool" and "Utility" since that is different to Windows/Linux/MacOS - a Tool can take a Project as an argument, or if it has a GUI, will have some kind of "Open" option; whereas a Utility definitely won't. Your network stack is a Utility. Your keyboard remapper is a Utility. GIMP, OpenOffice and Emacs are all Tools.
It gets a little "grey" when talking about things like the "list" command (equivalent of ls) but when using it from the commandline, the OS doesn't actually make a distinction anyway - the separation is mainly to handle things differently from the UI perspective.