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.

[should_be_linear]

Also, how they send something via e-mail? Is FedEx involved in process?

Re:Doubt it.

[SerpentMage]

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/

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.

[DarkOx]

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.

Re:Doubt it.

[interkin3tic]

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

I was also wondering about the choice of names there. I did some research and found that actually they made the right choice given the options. Some of the other names they were considering:

- Edsel OS
- New Coke OS
- Delorean OS
- Betamax OS
- Cold fusion OS
- Cure for the common cold OS
- Esperanto OS
- Zune OS
- This OS will totally break your computer OS
- Enron OS
- weloveventurecapital OS
- Dreamcast OS
- Y2K bug OS
- Completehoax OS
- Flyingcar OS
- Windows Vista OS

Re:Doubt it.

[drik00]

IANAP, but isn't the notion of using "files" and "folders" and a "desktop" analogous to how an normal person would work WITHOUT a computer, hence the concepts being transferred to a tool used to speed up and improve the efficiency of a person's work? How are these referred to as antiquated concepts? We use compartmentalized words because of the balance of efficiency with modularity. Our brains inherently compartmentalize, so why should we try to move away from that in a new OS (that I'm betting will be on the vaporware list in the near future)?

Capt Negativity here,
J

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 :)

Re:Doubt it.

[mustafap]

>You try, fail, and your program crashes.

You try, it works, you sell, one year later it fails, and your program crashes, and the customer sues.

There, fixed that for you

Re:Doubt it.

[icebraining]

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:Doubt it.

[Artifakt]

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.
          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 .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.
        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.

 

Re:Doubt it.

[c0p0n]

Small correction to what you said; if the file being moved is on the same logical and physical volume, it's not copied then erased, just a reference being changed. "Folders" have always been named "directories". Calling them otherwise is fairly recent, since windows 3 time iirc. I do, however, fail to see your point in how the folder/file metaphor is antiquated, or perhaps inadequate, users seem well happy with it. Technically, of course. But intelectually, it's a metaphor that has worked really well for over 30 years.

Re:Doubt it.

[amRadioHed]

Macintosh has always called directories folders, so it predates Windows 3 by at least 6 years.

Re:Doubt it.

[Chuck Chunder]

You try, it works, you sell, one year later it fails, and your program crashes, and the customer sues.

You try, it works, you sell, one year later it fails, and your program crashes, and the customer thinks this is normal.

There, fixed that for you.

Re:Doubt it.

[YttriumOxide]

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.

Re:Doubt it.

[julesh]

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.

Not really. The point is that it applies to all data in the system. And also it isn't serializing in the traditional sense (transforming objects into a format that can be written to a stream) but is rather directly storing the in-memory representations of the objects in a persistent storage system.

In order to do this convincingly in a library, you'd need feedback from the operating system when data was modified. I don't believe most standard OSs do this.

Hmm...

[Tubal-Cain]

Two questions:

• Is it self-hosting yet?
• How is it licenced?

Re:Hmm...

[denis-The-menace]

You probably have "phantom" ownership of the OS so I would assume you can just get a license. ;)

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".

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

[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.

Re:Opera of the phantom

[SatanicPuppy]

Yea, I'm there with you. Power failures are a problem for one reason and one reason alone: RAM I/O is faster than disk I/O. If disk I/O was faster, we wouldn't even need RAM...RAM would be useless because it has a huge disadvantage: its volatility.

Now Phantom wipes that problem out by "...storing its complete state on disk". Either this is bullshit, or this OS will have serious performance issues.

Then, then it starts talking about C vs Java. WTF is that about? Regardless of how cool the OS' underpinings are, you could write C for it with an OS-specific compiler. That's no different from the output of Java's intermediate compiler.

It's not like Java is outputting some sort of magical instructions that are different from the output of compiled C. The difference is that C doesn't abstract the hardware layer in the user code like Java does, and that Java is compiled to be interpreted on the fly by an intermediate virtual runtime environment. Get right down to the hardware and there isn't a lot of difference.

I'd want to see some real specifics that they could deliver anything resembling what they're promising, and frankly, I think that'll never happen.

Re:Opera of the phantom

[SerpentMage]

>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.

No I think they know what they are talking about. Instead what they are saying is that if you look at the VM concept (eg .NET with AppDomains) you can run everything into a single address space.

Of course underneath there is an address space, but remember that each process has its own address space that the CPU has to maintain. There is quite a bit of legwork that the CPU does that he thinks is probably not necessary.

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

Have you read About Face from Alan Cooper? He explains in that the concept of a file is horrible from a user perspective. Files are added as a concept because it is a hack and makes it easier for the programmer. A user in fact does not want to have say, "oh I have to save this?"

Thus the idea is that you have an entity that you can manipulate. And whatever changes you make are immediately persisted. This is what users expect.

>I really don't think I'm interested in this OS.

I am extremely interested in this OS because he is simplifying things. Remember one thing that we learned with Jit'ing is that "slower" apps can actually be very fast. C++ is not the fastest game in town. And that should make us all think.

Re:Opera of the phantom

[hal9000(jr)]

I am not affiliated with these guys, but from the faq and the site, here is what I get.

Memory in all computers is mapped to address space.

Right, but you, the programmer, don't worry about memory allocation or de-allocation in the same way. You don't do pointer math or any of that shit. The OS does it for you (which is what an OS should do). Think how Java manages memory is different than now C does. Hopefully, the OS manages memory well.

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

Well, yes, there are "files" managed by the OS, but not directly reachable by a program. You treat a file like an object and just use it. No open, no close, no worrying about the proggie crashing and losing the unwritten data. The OS handles it.

Same with processes. It seems cool. Not sure it has legs, but seems cool indeed.

Re:Opera of the phantom

[Rary]

I think he's talking about programmer-land, not user-land here.

That's the problem. Everything about this appears to be designed for developers, not users. There's absolutely nothing that indicates anything that would make a user want to use this OS.

So, basically, if you're a developer, and want an OS that makes it cool, easy, and fun to develop applications that no one will use, then this is for you.

Re:Opera of the phantom

[SatanicPuppy]

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.

Re:Opera of the phantom

[hackerjoe]

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.

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: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.

Re:Opera of the phantom

[vadim_t]

Have you read About Face from Alan Cooper? He explains in that the concept of a file is horrible from a user perspective. Files are added as a concept because it is a hack and makes it easier for the programmer. A user in fact does not want to have say, "oh I have to save this?"

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:Opera of the phantom

[grotgrot]

Read Inside the AS/400 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:Opera of the phantom

[maharg]

Everything about this appears to be designed for developers, not users. There's absolutely nothing that indicates anything that would make a user want to use this OS.

I expect Babbage came up against the same attitude. Good job it didn't put him off, eh ! Not to compare this guy with Babbage, but really, does lack-of-user-appeal really mean that it's not worthwhile ? I think this is very interesting indeed. If you consider something like a database application, which needs to persist state changes to disk pronto, then why not let the OS handle this for you ? It needs to be done either way. I just wonder how a generalised object persistance layer can can handle specialised cases such as text storage (where you might want compression to save space at the expense of some speed) and video storage (where the object data is already compressed and you don't want to re-compress it). Actually thinking about video is interesting - what would the equivalent of seeking through a huge video file be if it was stored as an object ? Would the whole video object be loaded into RAM ? Some *very* interesting programming challenges here, which for some people makes it all worthwhile, even if it is ultimately a dead-end commercially, it *can* advance the field.

Re:Opera of the phantom

[nine-times]

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:Opera of the phantom

[Bryansix]

Think outside the box for a moment. Nothing you brought up could not be fixed with a simple mechanism. You could still hit "save as" when you wanted a snapshot of a document but the point is that the document will persist even though you lost power in the middle of typing it.

Re:Opera of the phantom

[__aasqbs9791]

I think their whole point is to make this easier for users, and the vast majority of users I have ever known could not be taught by anyone how to properly use a version control system. Many of them can barely understand how email works (still!). I have th same concerns as the poster before you about a system like this. Having to "save" a file is a feature, not a bug, once you understand how to use it.

Re:Opera of the phantom

[moderatorrater]

Think outside the box for a moment

Agreed. We seriously need his synergy.

However, he's got the point that it introduces problems that might have a workaround, but one that's less efficient/effective than the original problem. Why not just add a library that can be used with the dynamic programs that allows them to do this easily while still retaining the ability to do things the old fashioned way?

In addition, files are absolutely necessary. As someone pointed out, how do you take an object from one program to another? How do you find it to send it to your mom? These are all problems for which the file paradigm works very well. The solution will either be core to the OS that very closely resembles our current situation or specific to each application, requiring you to relearn everything every time. Doesn't sound all that efficient or paradigm changing to me.

That said, I think the idea deserves exploration. I just don't think it's going to revolutionize computing, and that eventually the good ideas will be incorporated into our current offerings and we'll all move on, grateful that they explored the idea but knowing that the original scope of his plans wasn't realized.

Re:Opera of the phantom

[AuMatar]

A database is the *last* thing that would want to let the OS handle something like this- how would it do transactions then? How would it efficiently lay out the data for reading (large databases can become disk bound easily).

Its a rather pointless idea all in all. You want a simpler API than file? Write a function Save() that writes it, and call Save from then on. Want it to do so automatically? Do so in response to a timer. You can even write a function that sets up the timer, or have your constructor register the object with an auto-writer.

There's a reason why files exist. They work, they work well, they're simple, and they're extremely flexible. A system like this has very small improvements to simplicity for basic work, at the cost of a lot of problems doing anything more than basic (opening data with another app, sending data to external disks, organizing data, writing efficient file formats, implementing standards, sharing data among multiple apps). Its not that this hasn't been considered before, its that we have a good solution already.

Re:Opera of the phantom

[vadim_t]

Simple OO orientated access to a bit of everything, that's the true benefit of Phantom.
You are still missing the points completely, or maybe you are just trolling?
The increased intuitiviness is mostly on the development arena how i see Phantom, it will translate to some portions of the GUI definitely, and allow many neat things done which were harder on traditional OS.

As a programmer, this tells me absolutely nothing. Concrete code examples, and pointers to documentation, please.

You are arguing a technical solution is bad on the basis of the irrelevant GUI. How hard it is to see that method of how things are done and accessed beneath the curtain has no correlation on the final GUI necessarily?

We're talking here about something that necessarily must result in the user getting a different sort of behavior. If the only difference is for the programmer, and the user doesn't see any improvements, then there's no point for the user to adopt a new OS.

As for your O(n!) algo inefficiency: You take the algo, splice it on nice swallowable chunks, and all of sudden you have a nice small problem set algo ;) /me works on huge datasets daily

Well, take the travelling salesman problem. You have a table of just 100 cities with their locations on the map. The problem is calculating the shortest (no approximations allowed) route for visiting all of them. Please tell me how you're going to split that into nice swallowable chunks (hint: 100! is a rather large number). Also, how much more hardware will you need if you add an extra city and want to get it done in the same amount of time?

IBM already did it

[ebunga]

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

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?

OMG POINTERS!

[scubamage]

POINTERS! POINTERS EVERYWHERE! OH MY GOD POINTERS! *runs around like a lunatic*POINGERSPOINTERSPOINTERSPOINTERSPOINTERS *head explodey*

Yeah, I think the development will go something along those lines.

Oh really?

[vux984]

But a file in Phantom is simply an object whose state is persisted.

Persisted to a file?

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.

I've written countless classes that work the same way. When I want to read the settings file for my app for example, I just instantiate my settings object and start reading the settings, the object handles actually opening the file (creating it if necessary), opening it if necessary, etc. If I set new settings, the object handles persisting them.

So all they've done is taken my (and anyone else who does any OO programming) model, and moved it into the OS API?

I'm not usually one to say, "no big deal, this has been done before" but seriously... this time it really is no big deal, its been done before. Hell, lots of API's for this sort of stuff even already exist, some of them even come with OSes.

The only thing that might be novel is if this phatomOS goes whole hog, and forces you to use that api and actually denies you all access directly to files using more traditional methods. But I have my doubts... that would make it needlessly incompatible with a lot of existing software.

Re:Oh really?

[noidentity]

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.

So in other words...

#ifndef PHANTOM_H
#define PHANTOM_H

#include <stdio.h>

typedef FILE* phantom_ref;

inline phantom_ref phantom_get_ref ( const char name [] ) { return fopen( name ); }
inline void phantom_read ( phantom_ref r, void* out, size_t len ) { fread( out, len, 1, r );
inline void phantom_write ( phantom_ref r, void const* in, size_t len ) { fwrite( out, len, 1, r );
inline void phantom_release_ref( phantom_ref r ) { fclose( r ); }

#endif

Re:Oh really?

[bittmann]

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...)

It's appropriately named

[halivar]

M'thinks it shares much in common with its gaming namesake, the Phantom Console.

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:How much do you like inventing wheels?

[jandrese]

The problem is when you have 500 or 5000 or 50000 different unrelated documents that you need to keep organized. Right now you just write them out to the filesystem and let the existing tools work for you. In this new system each program would have to figure something out on it's own. Having a pipe like interface or cut and paste between programs suffers from the fact that programmers will implement exactly how much they think people need, and will miss out on the last 10% of the functionality.

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.

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:Screenshots...

[mrjb]

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

Sounds lucrative..

[mr_stinky_britches]

Sounds lucrative.. not!

At first, when I read the OP's post, I thought he was being harsh. Then I actually read TFA, and here are some highlights:

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.

Then it also has a special ASM language called "Phantasm". Looking over the example code, the question "Why?" kept flashing in my brain.

Ah, then we come to Why a new os?:

The most obvious questions: why new operating system? Isnâ(TM)t Linux enough? Of course, Linux is not enough. Being a clone of Unix, Linux conceptually is a dinosaur. Donâ(TM)t be happy, Windows guys, Windows is not really far away. Lets see, what is wrong with todayâ(TM)s popular operating systems.
    >> OO-Friendly? No!
    >> Network friendly? No!
    >> Simple? No.
    >> Communication friendly? No!
    >> Future friendly? No!

Okay, so according to the guy who created it, OS's should be simple, oo-friendly (my mom always says "Hey, stinky, why isn't my computer more object oriented?" (wtf?no), and future friendly? The guy must be just another cracked out developer..

Thanks but no.

Re:Sounds lucrative..

[molarmass192]

Yeah ... I was thinking the same thing. Good bye to C and Assembler? Ahhh, they mean goodbye to any low level hardware I/O or custom drivers ... nice. We already have a Phantom OS, it's called HTML / JavaScript ... no files to persist, no access to hardware, no low level performance tuning, networking is built-in, everything is interpreted ... how exactly is Phantom OS any different? OSes succeed when they offer GREATER flexibility, not when they insulate developers for low level APIs. Look at what can be done on an iPhone versus what is possible on a Mac. I think I'll stick with my "dinosaur" UNIX variant, with all the terrifying freedom and non-restrictions it provides, thank you very much.

Re:Sounds lucrative..

[Goaway]

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:Sounds lucrative..

[mr_stinky_britches]

Mmm..tastes like reinvention. Who does that? Oh yeah.. ;) cracked out devs

Re:It know what evil lurks in the hearts of men?

[zappepcs]

If you open the CD case and your OS comes out and sees it's shadow, it means 6 more years of Linux.

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?

Re:It's just a game of names

[93 Escort Wagon]

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....

Python is rather archaic. This new OS features a brand-new scripting language called Poodle. It is designed to be forward and backward compatible with Python, both current and future versions. This means Poodle scripts and programs don't need a separate interpreter - they can use the existing Python framework you have installed. To facilitate this, the Phantom OS developer suggests you use the file extension '.py' for Poodle code.

Re:It's just a game of names

[dzavalishin]

Let me be serious and ask what do you call file extension in a system that has no files.

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...

[orclevegam]

Biggest problem I see with this, is the whole persistent process thing. 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. There's also a very good reason why we use files in some instances, such as for storing documents that parallel physical ones (that is, most things that come out of Office type products). A file represents a very convenient discrete packet of information separate from the application that produced it, and that is easily transferable, archiveable, and processable, without adding the overhead of bundling a particular instance of an application along with it. Other problems this introduces include how to handle a crashed program, or one that has managed to get itself into an inoperable state. How difficult is it to "rollback" a process to an initial state, particularly without doing the same to every other process in the system. Does doing so wipe out your configuration options? What if those options are the reason the process isn't working?

For an embedded device in certain specialized environments this sort of thing might work very well, but it's certainly not a good idea as a primary OS in your typical desktop or work environment.

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.

Re:Read About Face...

[Adam Hazzlebank]

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

[The Mighty Buzzard]

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.

Or it could be that we've been actual sysadmins long enough that we know the value of always having a working state to fall back on. Preferably one that doesn't erase all the work done in the past few years. Saying something as foolish as that can only mean you haven't had to repair a thoroughly hosed system in far too long.

Re:Read About Face...

[Jeremi]

So, how do people "expect things to happen" when it comes to computers?

For years my grandmother had a post-it note pasted to the bottom of her computer monitor. On it was the following message, in large letters: SAVE!

The reason for that was because she would often type in a document, then turn off the computer. When she turned it back on later, she would be surprised to find out that her document was gone. The concept of persistent vs non-persistent state did not come easily to her, and one has to ask, why should she have to learn about RAM and hard drives and filesystems just to type up a letter? Why can't the system work the way she expected it to, which is to say the way most other machines in the modern world work? When I stop using my notepad, my bicycle or my television, I don't have to remember to press SAVE anywhere or risk losing my work. It's an awkward and unintuitive extra step, and in an ideal world it wouldn't be necessary.

Re:Read About Face...

[dangitman]

The concept of persistent vs non-persistent state did not come easily to her, and one has to ask, why should she have to learn about RAM and hard drives and filesystems just to type up a letter?

Because that's how it works. Any alternatives also have major downsides. Your grandmother is an isolated case. Most users now understand the concepts involved. Your grandmother could simply turn on auto-save.

Why can't the system work the way she expected it to, which is to say the way most other machines in the modern world work?

Because more people than your grandmother use computers, and shouldn't be limited by the least competent users. I could expect my computer to work like a magic elf that makes me snacks, but it wouldn't be realistic.

The way most other machines work? What about my 35mm camera? When I take a picture, it needs to be developed and printed, with great care taken not to expose the film to light. I can't just open the camera and see the pictures. Or perhaps a more basic example - when your grandmother types a letter does she just leave it lying around outdoors, or does she store it in a drawer or some other more protected location? When she sends the letter, does she just put it in the mailbox, or does she put it in an envelope first?

Trying to slavishly emulate other physical devices is generally not a good idea in computing. The whole benefit of computers is that they aren't bound to the limitations of mechanical devices.

Re:Read About Face...

[arminw]

...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.

Re:Read About Face...

[pintpusher]

Our *four*...no... *Amongst* our weapons.... Amongst our weaponry...are such elements as versioning, snapshots, backups, an almost fanatical devotion to the pope, and nice red uniforms - oh damn!

Re:Read About Face...

[tylernt]

Any alternatives also have major downsides. Your grandmother is an isolated case. Most users now understand the concepts involved. Your grandmother could simply turn on auto-save.

Or, she could just use something like Phantom where a file is simply an object whose state is persisted.

I'm not seeing any downsides to the "alternatives", either. In fact Phantom seems like an improvement in every possible sense except backwards compatibility. The way things are now are just a kludgy evolution of making humans work like a computer, instead of making the computer work the way a human expects.

Solution to the wrong problem...

[pongo000]

...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:Solution to the wrong problem...

[ReeceTarbert]

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.

Maybe a long shot and not quite what you have in mind, but I think that Spotlight is close enough -- and it's fast too. So fast, in fact, that's also my application launcher of choice.

Reece

Re:Solution to the wrong problem...

[vux984]

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.

Anyone ever hear of Multics?

[DutchUncle]

Once upon a time, in the 1960s, in the dawn of the multitasking OS concept, there was Multics. It had no distinction between files and data; after all, a file is just a backing store for a piece of data currently mapped into RAM. Since RAM was expensive and small, and paging had to handle everything anyway, the data object that we think of as a file just gets paged in as it is accessed.

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.

Time to play Spin The Wheel, Techie edition...

[girlintraining]

Oh gee, look... Someone has changed the description of something and now it's completely new. It's not a file anymore, it's a persistent object. You know, I remember the day when they just called them files. Nice, simple. You could almost visualize it in your head. Files, you know, like what you put in cabinets. And there were folders too, and it made sense. Then Macintosh came along and, in order to make their mark in the world, we stopped talking about files and started talking about Resources. Well, they've added four more letters, bit harder to understand, a few more tech support calls to explain it. And then along comes the next iteration of this naming game, a persistent object. Now we're at five constants, we've added seven more letters, tech support can't explain it, and although everything looks the same, by golly it isn't. Next they'll be calling it a post-operation management data structure.

See, here's a problem in our community in plain sight but nobody's going to talk about it, and it's this: We make things unnecessarily complicated. And we buy into these complications, because we want to impress our other geek friends and cohorts with our impressive cutting-edge knowledge. So companies sell us an ever-enlarging and increasingly dense lexicon to obscure what are really simple, fundamental concepts. You know, it has taken me decades to learn even a tenth of what computers can really do. It's what has drawn me to them my whole life -- they are based on such amazingly simple principles but yet can so such incredibly complex things. Learning information technology is like peeling an onion. I never finish. And you know, truth be told I like the challenge.

But what I don't like is having to learn an ever-changing lexicon just to have a conversation with someone, when we both understand the concepts and principles already. Why should we, as a community, constantly have to re-learn the same things over and over and over again? We need to stop doing this. We are wasting more and more of our time just trying to keep up with the language, instead of actually working the problems. And before I get the petty intellectuals to jump on my case for "dumbing things down", I'd just like to say anyone can make things more complicated but it takes true genius to make things simple. So there, I've said my peace. Bring on the rebuttals.

agreed: persistence, not files

[dazedNconfuzed]

I'm inclined to agree.

Linux is, indeed, based on what is now a very old paradigm - approaching half a century. Concepts have advanced since, and much of what we do is just to retain that backwards compatability.

Windows, is, well, Windows. This being /., no more be said of that.

Grokking object-oriented programming, and users' mindsets as well, I agree that it would be worth at least examining the concept of a "file-less OS", one that simply keeps a live OO system persistent. I'd like to write software knowing that when an object is instantiated, it persists until explicitly deleted - without having to awkwardly save state to something as non-orthoganal as a file. I want to be able to manipulate & transport objects as such, not as files. Obviously the prime issues are performance (storage vs. RAM consistency) and recovering from shutdown; resolving these is simply a geeky engineering challenge, not an impossibility. The concept of "files" is archaic. Storing/transferring what we call a "file" would be better served by persistence & portability of objects.

A prime example is the notion of "restarting" a computer. Why, these days, should a computer startup time be so long? it should simply resume, but more robustly than "sleep" or "hibernate" - restoring the state of objects as they were, not restarting from practically scratch every time.

Could be that the OS ultimately does store data as "files", but that is an implementation abstraction, not a core of the paradigm. Users do not intuitively think of "files", and programmers should not force them to due to ancient rock-and-chisel backwards compatability.

"Those who say it cannot be done should not interrupt the person doing it."
- Chinese proverb

Re:agreed: persistence, not files

[Ornedan]

So you've got this really spiffy object-oriented OS automatically persisting your objects. What's the serialized representation of those objects? Any answer other than just having the system puke the memory representation of the object onto permanent storage media means that the programmer has to have a say in determining that representation. And this system was all about not having the programmer worry about those messy details. Except having the serialized form be a memory blob means the only thing you can ever deserialize it to is the exact same version of that particular object type.
This is why we have files. Letting the programmer do the de/serialization just means you're calling your files something else and added some mandatory cruft on top. Also, without files (or equivalent), you can't have standard file formats. This kind of system would then be vendor lock-in heaven.

Yes, well known idea.

[Animats]

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.

Rebooting

[dmomo]

What does this model say for Memory Leaks? If the state is persisted... rebooting won't clear the memory. I imagine there must be a "reset state" mechanism. Perhaps this can be done without actually rebooting. I dunno.

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:the idea's worked in practice before

[Bearhouse]

I worked on the S/38 - fantastic...really.
But there's a reason for nearly all the advanced features of Pacific disappearing through the generations of AS/400 and now IBM i.

Much to learn, you have, young Jedi...and answers all you will not find on Wikipedia.

Re:the idea's worked in practice before

[Shin-LaC]

I think there was a connection problem when your message was posted. It seems to have been truncated right before the part where you disclose the arcane mysteries you were hinting at.

Even if they make it work...

[shutdown -p now]

... it'll be a closed ecosystem: an OS that cannot run the a lot of the presently popular, mainstream programming languages. C/C++ - no, obviously (they say as much) - this means that vast majority of existing apps go right out of the window. Great already. Java? That should run, but how many good Java desktop apps you know? Now forget about those that use JNI in any way - now what? About 5-10 - The rest will have to be written from scratch. C#? Nope (no pointers), though a limited subset might be possible. Perl, Python, Ruby? Sure, all will work, but have fun rewriting the interpreters themselves in Java! And despite the claims that "JITs are fast enough", for stuff like that they aren't - you really need dirty tricks such as computed goto and jump tables to code fast bytecode interpreters.

So, in the end, this is going to suffer the same fate as all OSes that came bundled with their own language - death and extinction. Remember Lisp machines? Or, say, Oberon-3? Yes, that's how it usually ends...

That wouldn't work.

[SanityInAnarchy]

Keep in mind, the whole OS is designed this way, including all programs.

Let me give you an example of what happens when it's implemented as a library: GNOME and KDE sessions. At least in KDE, it's possible to save a session, or even to have it autosave when you logout. It will remember all open programs, and the geometry of their windows. It will even query the programs, asking them to save their state.

Now, this would be awesome, wouldn't it? It'd be a lot more efficient than hibernate/resume, if it worked -- for example, an ODF (plus some simple geometry and state) is much smaller than the entire virtual image of OpenOffice. If the programs were written well, to load only what they need on demand (and thus start much faster), the whole system would shut down and wake faster.

You could even start to have multiple sessions, maybe mapped to virtual desktops, maybe not, so that when you boot, you could choose whether to have it launch your web browser, text editor, and terminals, or have it launch your mail client, IM client, and softphone, or maybe have one that just launches whatever movie you were playing (which would resume from the exact moment it was at when you shut down)...

Problem is, too many programs don't support this. Some, like Firefox, seem to supply their own session management. Some don't even try, and thus, when the DE tries to resume them, it ends up launching a fresh instance. Some can't be persisted, due to their fundamental architecture -- how would you propose to save the state of a running terminal?

So, doing it as a library doesn't work, unless everything's using that library. If everything's using that library, that's pretty much what you get.

And sometimes, you do have to enforce sometimes performance-decreasing features in order to provide a better user experience. Imagine if filesystem access was just a library, and programs had access to the entire disk. It might be interesting to build an OS that way, but even if you did, I imagine you'd want to restrict most user-level programs to dealing with the POSIX API, and being bound by Unix permissions and POSIX ACLs.

Re:Lack of commit and rollback

[SanityInAnarchy]

Newton OS had the same thing. It caused me to lose data twice when I accidentally deleted a large part of a Newton Works document and then did something else. Undo only undid the something else; the deletion became permanent as soon as it passed out of the one-step undo buffer.

Two things:

First, your problem seems to be more with the fact that undo history was only one level deep than anything else.

And second, you do need revision control, and it needs to be easy enough for the masses, but more powerful than just "undo".

Is this for real ?

[ProfMobius]

"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. [...] Phantom, he says, will increase programmer productivity by at least 30 per cent - and perhaps as much as 400 per cent."

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 ?

We've been down this (exciting) road already

[piranha(jpl)]

There's little or nothing original that's being presented here. The Phantom people claim originality to the idea of orthogonal persistence, but they are flat-out wrong:

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.

To illustrate the utility and awesomeness of persistence, there's a famous story about KeyKOS, an earlier OS that embraced this notion:

At the 1990 uniforum vendor exhibition, key logic, inc. found that their booth was next to the novell booth. Novell, it seems, had been bragging in their advertisements about their recovery speed. Being basically neighborly folks, the key logic team suggested the following friendly challenge to the novell exhibitionists: let's both pull the plugs, and see who is up and running first.

Now one thing Novell is not is stupid. They refused.

Somehow, the story of the challenge got around the exhibition floor, and a crowd assembled. Perhaps it was gremlins. Never eager to pass up an opportunity, the keykos staff happily spent the next hour kicking their plug out of the wall. Each time, the system would come back within 30 seconds (15 of which were spent in the bios prom, which was embarassing, but not really key logic's fault). Each time key logic did this, more of the audience would give novell a dubious look.

Eventually, the novell folks couldn't take it anymore, and gritting their teeth they carefully turned the power off on their machine, hoping that nothing would go wrong. As you might expect, the machine successfully stopped running. Very reliable.

Having successfully stopped their machine, novell crossed their fingers and turned the machine back on. 40 minutes later, they were still checking their file systems. Not a single useful program had been started.

Figuring they probably had made their point, and not wanting to cause undeserved embarassment, the keykos folks stopped pulling the plug after five or six recoveries.

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:

• Coyotos, an OS whose orthogonal persistence falls out of the capability model of security that they embrace. Coyotos is written in BitC, a purpose-built high-level programming language with special focus on formal semantics and reasoning.
• Singularity, a language-based OS in development by none other than Microsoft Research. (Certainly the most interesting Microsoft project that I am aware of.) Singularity exploits language semantics to isolate processes.
• TUNES, a collective wet-dream of what the OS, programming language, and generally computing system of tomorrow should look like. With all due respect towards the insurmountable difficulty and endless complexity of a task like this, it must be said that TUNES is just vaporware.

BeOS

[Phantom of the Opera]

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.