Slashdot Mirror
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."
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.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
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.
M'thinks it shares much in common with its gaming namesake, the Phantom Console.
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.
I read the internet for the articles.
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:
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?:
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.
Censorship is obscene. Patriotism is bigotry. Faith is a vice. Slashdot 2.0 sucks.
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.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
>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.
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
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:
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?
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.
"You cannot simultaneously prevent and prepare for war." -- Albert Einstein
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
Can we get a "-1 Wrong" moderation option?
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.
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.
Curiosity was framed, Ignorance killed the cat.
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.
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
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.
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.
Violence is like duct tape. If it doesn't solve the problem, you didn't use enough.
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.
I don't care if it's 90,000 hectares. That lake was not my doing.
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.
... and then they built the supercollider.
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.
Don't thank God, thank a doctor!
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".
Don't thank God, thank a doctor!