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.

[Anonymous Coward]

Since it is a Russian OS, I'd guess they they'd use their army of bots to send email.

Re:Doubt it.

[Anonymous Coward]

While this is both amusing and true, the operating system is far worse placed to manage these locks than the application.

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.

[Anonymous Coward]

I think this is missing the point that the benefit is to the developers who can write more maintainable, cheaper code (which helps all of us in this industry)

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.

[Goaway]

Nobody said that this OS is suddenly incapable of serializing data to a byte stream.

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.

[kkrajewski]

How does it handle locking conflicts? Well, think about it, how do you handle locking conflicts in your program? That is your answer.

Synchronized blocks around the entire program?

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.

[AmberBlackCat]

The thing about the abstraction layer on top of a regular system... that's how I feel about using the /proc file system to get system information. I assume their goal was to make it possible to read system settings using standard C functions. But I definitely think something like cpu.name() would be better than opening and reading a file, and parsing a string, just to get the name of the CPU.

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.

[Anonymous Coward]

The applications that use C or C++ and becoming less frequent but are still important for performance reasons.

As are those applications written in assembly. No question there. My previous comment was more an observation on our natural tendency to resist change, rather than an argument for or against the particular implementation of change discussed in the original submission.

Re:Doubt it.

[amRadioHed]

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

Re:Doubt it.

[jythie]

Abstraction is great, as long as it gives you what you need. As soon as it doesn't then you have a problem. So you can do more as long as you are only doing what the developer guess you will want to do. But the more layers of abstraction you have the more difficult it becomes to do anything else.

Re:Doubt it.

[mr_mischief]

It could be implemented as a permanent virtual address space in which the programmer treats everything like a memory-resident object and the pages of memory regularly get written to disk or read from it if needed. It seems to have worked for OS/400 (now IBM i) for over two decades.

Re:Doubt it.

[Anonymous Coward]

that layer of abstraction created many benefits.. virtualizing every AGAIN brings diminishing returns while eating away at precious cpu time/battery life/power cost.

Re:Doubt it.

[xigxag]

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

Even if you wouldn't want to use it as a production system, it's possible that he may work on some ideas that would be fruitful folded back into Linux or Windows.

For example, since I've been using Firefox (or, if daring, tabbed IE) it irks me that FF can to some extent carry a persistent state between sessions but few other Windows programs can do so. Yes, hibernate works pretty well now in mature operating systems but I want the ability to hibernate apps on an individual basis. This should be built into the OS -- Firefox shouldn't have to roll its own persistent save mechanism. I want to be able to shut down Notepad and restart exactly where I left off without having to explicitly save or reopen a document. Or to close an mp3 on WMP and have it (optionally) pick up when I reopen the program. Or VLC, or whatever. And for any Windows/Linux program to be able to do this by default because the OS takes care of the plumbing.

Re:Doubt it.

[wisty]

But why the hell do I want files and folders? I want a bunch of photos that I've taken, I want my documents (and I don't want to manage back-ups - version systems are better), I want my music, and I want my movie and 'art' collection. I also want programs. Folders have some use in my office, but a URL system would be better.

I also want to be able to install software (or write it), which requires some anarchic file operations, but I don't give a toss about "organizing" my personal documents into folders. Not if I can search and sort.

Re:Doubt it.

[X0563511]

I'm seeing this as the storage device is used as giant database.

It kind of makes sense, but at the same time, isn't this history repeating itself?

Re:Doubt it.

[X0563511]

Well, users of /proc don't care what provides it.

Users of cpu.name() do care - in the sense of ABI and calling conventions.

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.

[cryptoluddite]

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.

Protecting processes from each other in a traditional system accounts for ~20% overhead on hardware designed to make this fast (google: singularity research papers). Java generally runs ~%30 slower than C.

It's plain to see that cutting out memory protection has potential. This particular project will almost certainly fail, but that has more to do with network effects than anything else.

All virtualization has a cost, and I'm not sure that this is the way to handle the problem.

If you write over random memory locations does your whole system crash? No, because your program is running in a virtualized memory space. Your traditional linux or NT style system is using virtualization, and it's a much bigger and clumsier hammer than a typesafe language.

Re:Doubt it.

[zippthorne]

IANAP either, but just because something is initially intuitive based on previous methods doesn't mean it's the best choice. It's probably a good choice, especially for a new technology.... Y'know, change the least amount possible at a time to get used to it.

But eventually, "The enemy's gate is down." You want to try and discover the best method for the medium that you're actually using. That can mean most efficient, or most flexible, or most understandable, or some combination thereof. But it probably isn't the paradigm you came in with.

That is not to say that everything that isn't the paradigm you came in with is superior to it. Only that there's a good chance that your "first guess" wasn't the best possible choice.

Incidentally, the objective measure of "best" is that it leaves the greatest amount of time and resources in the hands of the programmers and users at the end of the day. i.e. economic efficiency.

Re:Doubt it.

[MikeBabcock]

Have you used Zope?

Have you read why Microsoft wanted to go to a more database-driven file system?

These ideas are not hokum, even if they are far-flung for a desktop.

The sloup system on the Newton was brilliant for its time, and deserves recognition in modern desktop OS design IMHO.

Just a few ramblings ... move along.

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.

[MaskedSlacker]

Incidentally, the objective measure of "best" is that it leaves the greatest amount of time and resources in the hands of the programmers and users at the end of the day. i.e. economic efficiency.

I disagree. That is AN objective measure of "best." It is not the only objective criteria that can be used however.

Re:Doubt it.

[ToasterMonkey]

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

Other OS's still do refer to them as directories, but 'folder's aren't a new concept by a longshot. You do realize that "Windows 3 time" means about 19 years ago right? I'm having a hard time calling that recent. Even Windows 95 has been around about half of those 30 years now, that's nothing to sneeze at. God only knows where Microsoft got the idea from too, we're probably greatly underestimating the age of both metaphors.

Neither really make a whole lot of sense. "Directory" implies a flat level of organization is really completely irrelevant to the computer, and mostly to us. A computer doesn't look up data based on its file's position in a directory, but it presents files to us organized in some manner so we can make a selection easier. What's a sub-directory? OK, the computer directory concept was probably around for a while before subdirectories. Back then, maybe it really did matter what order your files were stored in? We might as well call them moving boxes. Isn't that a better fit? I can put a box inside another box, and there is no implied order to things, they are just in the same box together. Like a phone book that was divided up into counties at a top level, then inside were towns, then streets after that, and finally the names and phone numbers, so only people living on the same street were listed in any order. That's really what a filesystem really does, it provides depth. I vote moving boxes for the next UI metaphor.

Re:Doubt it.

[krischik]

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.

Actualy No - With a 64bit CPU a hole harddrive could be used as virtual memory. A couple of hints to you:

1) In Linux the swapper is usually not stored in a file but in a raw partition. But you could use a raw harddrive as well.

2) In BeOS the swapper must be at least as large as main memory. A dead give away that BeOS uses a one to one relation ship between main memory and swapper.

So even before I do RTFA I can see how it could be done: Hard-drive and Memory is mapped one to one and before you shut down the system all volatile main memory is written non volatile hard drive memory.

So I now go and RTFA to see if I am right ;-) .

Martin

Re:Doubt it.

[Anonymous Coward]

I assume their goal was to make it possible to read system settings using standard C functions. But I definitely think something like cpu.name() would be better than opening and reading a file, and parsing a string, just to get the name of the CPU.

On the contrary, their goal was to make system "user friendly" (when it actually meant "sysadmin friendly") and provide in-depth system information in human-readable form. They would probably laugh if anyone complained about having to open, read file and parse a string, because at the time that was programmers' bread and butter.

Re:Doubt it.

[Anonymous Coward]

Don't Forget:

Madoff OS (MadOS)
Liemann Bros. OS? (L-BrOS)
Citibank OS? (CitOS)
Royal Bank of Scotland OS (RBOS)

Re:Doubt it.

[pipingguy]

I'm conflicted and can't decide. The fact that a SerpentMage and a SatanicPuppy are debating this in detail confuses me even more. Lawn, etc.

Re:Doubt it.

[Anonymous Coward]

"They're throwing an abstraction layer on top of a regular system and calling it something different"

No F...ing Way.

dz.

Re:Doubt it.

[Anonymous Coward]

Duke Nukem Forever OS

Re:Doubt it.

[FudRucker]

you forgot one...

Vaporware OS

Re:Doubt it.

[TheLink]

Many programmers should be grateful to Microsoft for this!

Re:Doubt it.

[davolfman]

Things I don't like:

VM only - either it's slow on some hardware like dynamic instruction translation or it's slow on all hardware like Java. Also killing C and Assembler just shows they're the kind of language purists who can't write a practical powerful system, same as Java again.

Memory compactness - serialized objects done right are tiny.

Interaction with other computers - if you want to do it you WILL need to write data to disk in a process and system independent format. We in the real world call it a file.

It's not GPL - seriously it's going to be next to impossible to drum up support for an underdog system that doesn't give people the code to tinker with these days. Think BeOS: sure it was pretty cool but it died real easily.

Re:Doubt it.

[Anonymous Coward]

Wow - even when we're talking about a bad practice, Mac guys have to come out and say that Apple did it first.

Re:Doubt it.

[julesh]

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

Or, you know, 3 years if you know arithmetic.

(Windows 3: 1987 release; Macintosh: 1984 release; difference: 3 years)

Re:Doubt it.

[julesh]

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.

Your argument doesn't make sense. That software is slow because it's having to go to disk to get memory that it needs. This is thousands of times slower than ordinary memory reads, so the software runs slowly until all the memory it needs gets paged back in. Your filesystem, however, you don't _expect_ to be in memory. Accessing the filesystem is usually that slow anyway, so it isn't an issue if it gets paged out.

Alternatively, you could mean that you're concerned that filesystem use will cause application memory to be paged out. This is a concern, but is easily addressed (e.g. by introducing different virtual memory pools for different types of object with rules about how far one is allowed to grow at the expense of others).

Re:Doubt it.

[julesh]

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.

No, it doesn't look that way to me. Think about this way: Unix is built around the philosophy that everything can be treated as a file. Most other modern OSs use the same paradigm, or one strongly influenced by it.

Phantom, it seems, is built around a different way of thinking: everything's virtual memory. Your computer is a persistent chunk of virtual memory, the same size as your hard disk. Every time you modify memory, it's flushed out to disk (presumably journalled and checkpointed in such a fashion that memory corruption cannot occur). When you restart it, the memory state is loaded back in (or allowed to demand-page back in, perhaps) and the system can restart in exactly the same configuration it was in when you switched it off.

The idea isn't entirely new. Smalltalk, for instance, works similarly: it has a virtual machine with a memory image that's persisted to disk, although in this case the persistance is not automatic and continuous.

In Unix, you can implement virtual memory by storing data in a file. In Soviet Russia^W^WPhantom, you can implement a file by storing data in virtual memory.

Re:Doubt it.

[julesh]

(Windows 3: 1987 release; Macintosh: 1984 release; difference: 3 years)

Erm. Scratch my previous comment. Source I was looking at had the wrong date for Windows 3 release.

*blush*

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.

Re:Doubt it.

[Anonymous Coward]

Directories are part of what I call the "hierarchicalization problem". Roughly half of the people love hierarchicalism, and love to nest things deeply; the other half have big trouble with it. Personally I can use it but I don't like it; it's inefficient and clunky. For example "src/com/java/sun/foobar" - note that most levels have only one entry.

"Foldering" should be implemented more as an attribute of files in a flat system. They should not be "places" that you would "go to", but simply collections. That would be much easier for everyone to use.

Hierarchicalists will hear that and say "that's dumb" and ignore it. That just proves them to be dabblers with a love of complexity. Actually, excess complexity is a waste of resources and time. When you get more experience you'll realise that.

Re:Doubt it.

[Anonymous Coward]

"files" and "folders" and a "desktop" are analogous to how we work with hard paper. However, the way they are saved is not.

When you are writing on a piece of paper, and you are suddenly interrupted you can leave the room. When you come back, you expect everything to be how you left it. However, with modern operating systems, leaving the desktop requires saving everything. This isn't really the best analogy, but hey, you started it.

The point is that you shouldn't have to explicitly save things. When I write words on a piece of paper I expect them to stay there until I scratch them out, or throw away the paper. It would be nice if files in computers worked the same way.

Also, you need to read the actual article/website. From userland files/folders are unchanged. It's only from the developers standpoint that things are different. What phantom is basically doing is taking the modern way of accessing disk files (streaming) and propagating it downwards to make it the only way of accessing disk files. So, instead of opening the file and changing it, then closing it - you just keep the file on the desktop and write every change when it happens.

Re:Doubt it.

[Anonymous Coward]

I heard they also considered a partnering contract with 3D realms and to brand it "Duke Nukem Forever OS".

Re:Doubt it.

[LWATCDR]

"If it isn't then it must be written to disk, in which case it's simply a regular file with a spiffy interface."
You do know that files on a disk are really just a different extraction. All that is on a disk are sectors of bytes. Files are just a spiffy interface to the raw data.
Object oriented file systems are nothing really new. At some time people have tried to make Object oriented everything.
I am not saying that it is a bad idea just that it isn't all that new.

Re:Doubt it.

[Anonymous Coward]

Polling? And that is rated informative? huh?

Kids these days...

Re:Doubt it.

[Anonymous Coward]

What is this vaporware you speak of? I have it on good sources that Phantom OS will run Duke Nukem Forever.

Re:Doubt it.

[Anonymous Coward]

Anyone ever think of instead of a hierarchial directory system, we could have a system where files are instead given labels? An MP3 of say, an ACDC song would have the 'ACDC' label. Labels themselves could have labels, i.e. a 'Music Artists' label which would be applied to all of the artist labels.

This in fact could be implemented today just by judicious use of hard/symlinks. The change is mainly in verbage - instead of putting a thing in a folder, we attach a label to the thing. The first verbage implies that the thing has a definite place and that it can only reside in that one place. However, for filesystems which support hardlinks and symlinks that's not the truth - files can reside in multiple places in a volume and other volumes can point to the file too.

In short, our fs browsers should work more like Gmail.

Re:Doubt it.

[amRadioHed]

Nice try but I'm a Linux guy. I just happen to know other stuff too.

Re:Doubt it.

[ioshhdflwuegfh]

It could be implemented as a permanent virtual address space in which the programmer treats everything like a memory-resident object and the pages of memory regularly get written to disk or read from it if needed. It seems to have worked for OS/400 (now IBM i) for over two decades.

Isn't this called swap or page file nowadays? Also, there is mmap to map any file into virtual address space just like in your description.

Re:Doubt it.

[mustafap]

Love the signature. I *almost* clicked on it.

Re:Doubt it.

[mr_mischief]

No, this isn't just a swap file for inactive processes or for when you run out of main memory. It's how storage is handled on some systems. You read from a named resource and write to a named resource. The OS determines what's in RAM and what's on disk. IIRC, IBM's actually moving more towards files and away from object persistence because files are more flexible.

Re:Doubt it.

[QuietObserver]

I only wonder how many people understand the Edsel reference.

Several years ago, I can't remember the year, my family and I watched "The Ghost and Mr. Chicken" for the first time (many, many years after the film was released in theaters). Early into the film, Don Knotts character states something to the effect of "I was driving my Edsel", and my parents burst out laughing. My brothers, sisters, and I were completely confused, and I think we may have needed to stop the video so they could explain the joke; I was born in 1973, and until that time (probably early nineties, considering the series of events that lead to us getting hold of the movie), I had absolutely no clue what an Edsel was.

Of course, it is possible that my lack of information on that particular subject was not the norm, even then, though I do come across people who don't know what an Edsel is. Anyway, thanks for the laugh.

Great

[LordKaT]

I can't wait to handle the consistently changing data in my DB applications.

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

Re:Hmm...

[Anonymous Coward]

> "documentary artisans".

I take it you get those from a SharkFactory?

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

[geekoid]

Be waery of anyone who acn't completly and clearly explain what they are developing. It means they don't understand it.

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

[sjames]

It may be one big address space, but nothing says that everything has permission to access the whole thing. It might also be handled through x86(_64) style segmentation. As to no context switching, I'm not so sure about that. Unless it's cooperatively tasked (yuck), it must be doing something context switch like.

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

There is an object that points to a bunch of document objects.

I don't see why C wouldn't work just fine in a system like that, it's just libc that would need some changes since there are no files.

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

[gbjbaanb]

That's simple. And - yes, due to the absence of separate address spaces IPCs are really cheap in Phantom

Just like Windows 3.1. Separate address spaces are a good thing, for process security. This is a bit like Apache running all virtual hosts under the same user account, everyone can trash all over any other user's space, unless protected from doing so in some way. Unfortunately, there's always a way round it - especially if you're allowing IPC to take place in a fast and cheap manner.

I think he's simplified things... back to an 80s OS.

As for files being memory mapped to disk storage, that's not that big a deal given that all modern OSs can do this. That they don't is just custom; that and the fact that you don't want to write to disk continually 'cos that'll kill performance in a huge way.

Still, I hope there are good ideas in there that do bubble up, maybe they will be incorporated into mainstream OS design.

PS. JIT can be faster that natively optimised code - but only in benchmarks.

Re:Opera of the phantom

[inviolet]

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

We saw a similar paradigm-shift when we went from landlines to cellphones. The process of dialing a number went from instant-persistent (touch-tones that the exchange listened to as you typed) to a compose-save process (enter number then hit 'send'). Humans are obviously capable of understanding both paradigms and they both have benefits and costs.

I for example love being able to mess with a file in a memory buffer, save it when I see fit, make further adjustments, discard them and reload, and so forth. Sure, I usually always commit to disk, in fact my left hand hits Alt+Z to save almost automatically... except when I don't. Same with landlines and cellphones -- I don't always hit 'send' after typing in a number, and there is very little mental CPU load expended in remembering whether or not I have or should.

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

[Anonymous Coward]

It is protected in some way -- by running in a VM. Erlang has multiple threads running in the same address space without protection and is rock solid.

Re:Opera of the phantom

[Anonymous Coward]

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.

The question was whether programs have separate address spaces. The answer is that no, they do not. All processes share a single global address space. Process isolation is managed and achieved by the VM.

There are (real-life, currently existing) systems which can work this way. It's called capability-based addressing.

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

I would speculate that you start a program, create your document or whatever, and then save the state of the program (which naturally contains the document as part of it). Then, to load your document, you restore your program's state, which will, as a side effect, restore the document you were editing. This is pretty much directly analogous to suspend-to-disk (aka hibernation) implemented at a program level.

If you look at it this way, their comments about not needing a filesystem also begin to make sense. You simply map your hard disk (and other devices) straight into your global address space. So now it's utterly trivial to save a program's state: you just copy it from one memory location (which is backed by RAM) to another (which is backed by disk). All the heavy lifting is handled by the virtual memory manager.

Now of course, saying they won't need a filesystem is more than a little disingenuous. They need to keep track of all the saved states for a program so they can be retrieved later. This mapping will also need to be stored to disk so that it can be retrieved after rebooting the box. Most people would call that a filesystem. And while you could make it more lightweight in some ways, you also make your virtual memory manager much more complicated because that disk is nothing more than a giant swap file. Which means you're going to end up journaling your swap file, writing an fsck equivalent for it, etc etc. Still, it's a different angle on an old problem, which makes it interesting.

It's also worth mentioning that this has all been done before -- as early as 1979 -- in the IBM System/36 (which became the AS/400, though it lost some of these features at the name change; now it's the System i). I encourage anyone who, like me, is interested in weird approaches to common problems to check out some of IBM's old iron. (Not just IBM, the others too; but it's easiest to find lots of information on IBM because they are actually still making some of the things.)

Re:Opera of the phantom

[laddiebuck]

Exactly. Plus we already have an OS keeps data on disk and merely uses memory as a checkpoint -- Coyotos. You can unplug it and boot it again and everything will be exactly the same, it's just slower.

Plus, it is actually a good thing to serialise/unserialise data sometimes. First of all, the serialised representation is much, much more compact. Second, what if the program crashes or gets into some undefined state? You can't share the data between processes, so whatever you were editing is lost. Imagine a system where the persistence of any piece of data is guaranteed only so long as the program that created it is still running and able to access it! Now imagine just one program in the system with a memory leak...

Sorry, but this is a horrible idea.

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

[Anonymous Coward]

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

So, this is the new Amiga?

Re:Opera of the phantom

[Anonymous Coward]

"I get the idea that these guys are programmers who don't really understand how the hardware works."
They never did, they don't want to.

Re:Opera of the phantom

[mabinogi]

Users aren't the target market of any operating system.
The point of an operating system is to provide a convienient programming environment to make a computer do stuff. It's the kernel plus a set of APIs and frameworks.

The parts a user care about are the programs written on top of that operating system.

So when introducing a concept for a new operating system, it makes no sense to hype it up to users until you have the developers on side. In fact, it never makes sense to hype it up to users, save the hype for the flashy user interface that one of the developers will have to write.

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

[Anonymous Coward]

Really?

It couldn't possibly mean, say, that English isn't their primary language?

Re:Opera of the phantom

[Citizen of Earth]

So I accidentally write a bug into my program that creates objects in a tight loop until all virtual memory is exhausted. Is my system now hosed? Do I need to wipe it clean, reinstall the OS, and start over?

Re:Opera of the phantom

[Jezza]

It sort of sounds like Squeak (a Modern Smalltalk) running "on the metal". ZFS could be bent to work in the way they "describe" (they don't really describe anything - just hint at).

Their approach of assembler sounds a bit like PrimeOS (very old OS - which actually had things called phantoms, makes me think they might have seen it)

Sure I'm sceptical, but never say never.

Re:Opera of the phantom

[imboboage0]

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.

Oh, it works all right. The rest of us called this 'Hibernate' and moved on with their lives. I'm not impressed by this 'Phantom OS' one bit. I call BS on just about the whole thing also. I know they're trying really hard to be smart and all... but really? Let's not reinvent the wheel.

Re:Opera of the phantom

[Anonymous Coward]

Same goes for extensive modificatons. Maybe you decided to drastically reformat the document, but then decide the idea doesn't look good after all. You can't choose not to save, you've either got to undo 50 times, or have created a copy before starting making the changes.

How about using version control?

Here's another issue: since there's no save operation, the undo history has to be kept forever. This means that whoever you're sending the document to, if they're so inclined, can replay your writing process backwards to see if there was anything you changed your mind on. Or if using another document as a starting point, what was there before.

Who said there's no "current version of document" operation? It could even be named "Prepare for public consumption", in the File menu.

Here's another one: Imagine this sequence of commands: I type a long document, decide I didn't like the last changes, undo too much, and then press a single letter. Does in this moment the undo history become a tree, or do I lose the ability to redo the excessive undo?

Undo histories are usually treated as stacks. Maybe that should be handled differently, but it's hardly a show stopping issue. This is an issue real life programs deal with today.

On the other hand, you probably don't want a tree data structure here, unless you are comfortable with things like merging and branching in a version control system.

Re:Opera of the phantom

[Zencyde]

Yeah, but all of the programming tricks in the compiler and virtual machines are being used. And it's all been optimized. So, bad programmers start becoming good programmers. Assuming, of course, that good programmers made the subsystems.

Re:Opera of the phantom

[Anonymous Coward]

More like classic MacOS.

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

[Anonymous Coward]

lol talk about getting hung up on non-problems. only a 'cat' person who drinks tea would think of this nonsense. This is what happens when stupid people think they are clever or "thinking outside the box". Kind of like when retards make sound.

thanks for the epic LuLz.

Re:Opera of the phantom

[Skal Tura]

If you'd be an developer, you'd understand the clear advantages of the system.

Also, the state is not saved ON shutdown, but the states are being persisted constantly. It's a clever trick how they keep up the performance however. However, they do say it's a cheap operation.

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

[andy_t_roo]

because all modifications to the object are done by manipulations of the the OS stored object if the program barfs, either the last call to modify object was executed, and the object was modified by the OS, or the program died before object.change() was called, in which case the object is still perfectly in the old state.

Because the OS actually holds the object itself the only manipulation of it not actually saved will be the single action which caused the crash.

The current paradigm is:
1) user creates new file
2) user types "have a nice day"
  2a) as each letter is typed the internal memory buffer is updated
3) user saves
  3a) internal memory buffer is passed to os.file.write
  3a) OS writes "have a nice day" to the file

The paradigm here is
1) user creates a new file
  1a) os passes program file.handle
2) user types "have a nice day"
  2a) as each letter is typed file.handle.addData() is called
3) the user does not save ever
3a) at appropriate times the OS synchronises the version of file in its memory and on disk.

The difference if program crashes at any time is large

2b) the program crashes after the 2nd 'a' is typed.

original paradigm:
the file is left empty, and the programs internal memory buffer is lost

with phantom:
OS.file.data is "have a", which at an appropriate time gets written to disk, and is available for editing to continue after a handle to that document is retrieved again.

Re:Opera of the phantom

[nschubach]

From what I got it's protected because the program will only know about the address space it has mapped. When it needs more, it requests it from the layer below it which will either return or deny the process the additional space needed. I think the idea of the Phantom OS is to abstract the hardware completely out of the program scope and have the programs request access to an item instead of being told what's there.

Re:Opera of the phantom

[Jezza]

Did someone say "new Amiga"?!

Oh you were only illustrating a point (I got all excited there for a moment...)

Re:Opera of the phantom

[Skal Tura]

You aren't thinking clear at all!

No one said we couldn't provide the user 'Save As' functionality or 'Save' functionality.

Furthermore, it would be utterly stupid to have your current under work object be the same as the stored object ... How immensively stupid it would be to spread across images with ALL of their edit history?

Edit history is something we don't need persistence in, and having such information on the final document ... Just plain stupid

Therefore: None of your described downsides actually exists.

Re:Opera of the phantom

[mveloso]

Well, you may be thinking about it incorrectly, which is why you're confused.

You want a document. Do you really care how it's stored, or what it's internal representation is? No...you just want the phosphors on your monitor to show the correct patterns when you look at it.

Why do you need separate address spaces? Separate address spaces are required for protection. But that protection is needed because of how programs are written today.

etc etc etc.

In any case, a file today is just a representation of an ordered set of bits. No different than anything else.

Re:Opera of the phantom

[Skal Tura]

Uhm, who said we even need a filesystem?
Sure we need pointers, but there's no reason we should be running a full blown filesystem underneath, most likely with the completely wrong feature set (if reusing existing filesystems).

It might not be the current dogma, but that doesn't make it any less or more wrong. There was a day when watching movies on computer was considered a joke and practically impossible. There even was a day when fire was magic.

Think outside the box for a while, will you? :)

Re:Opera of the phantom

[nschubach]

I would assume that a document would have a preset configurable undo level and "states" or "versions." You are somewhat confident in yourself, you might set the undo level at 100. You want to try a new design? Fine. Set a document state and fork it. If you don't like it. Revert to the previous state.

As far as sending your resume to a company, why would you need to send them your full history? Just send them a snapshot of the current resume. You wouldn't actually be sending them a copy of the object. You'd send them the latest version of it with no history.

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

[CannonballHead]

One only needs to visit distrowatch and look at #315. 1 page hit for Nepa Linux! Woohoo!

NepaLinux, a localized Linux Distribution in Nepali developed by Madan Puraskar Pustakalaya (MPP) [...]

Re:Opera of the phantom

[vadim_t]

No one said we couldn't provide the user 'Save As' functionality or 'Save' functionality.

Oh, you can "Save as", ok. But you need to do so before any important change, and do so consistently, because the moment you start editing, your on-disk document changes!

Furthermore, it would be utterly stupid to have your current under work object be the same as the stored object ... How immensively stupid it would be to spread across images with ALL of their edit history?

It's what every single office user does? Very very few users will even think about making backups. The vast majority isn't aware of that a document can be in more than one format.

Edit history is something we don't need persistence in,

Then how are you going to deal with accidental changes? If saving is automatic then obviously there's no confirmation when you close the program, and changes persist even if power goes out. There has to be a way to undo a change after the file is reopened then.

Re:Opera of the phantom

[CannonballHead]

Additionally, I'd like to point out that even with typewriters (which did not have "files"), users still wnated (with the expensive/advanced ones) to be able to undo something... type a line or two, make sure it's right, and THEN print it. Basically, the equivalent of typing and saving (permanently).

Put it in the gaming world. Not everyone likes persistent worlds where if you die, you're dead forever. Not everyone would want to play a game where there are no save points, and you can never go back to do something over, etc. Some people like the idea of "Hmmm, I want to save here, just in case I do something to completely mess it up."

Imagine programming on a changes-"save"-automatically environment... or say, image editing. Video editing. Etc.

Re:Opera of the phantom

[Jezza]

I still don't see how the hell I even begin to "send" the document! It's a running program, how do I send it?!

I guess I could clone it, and discard the snapshots (no "undo" for that - probably best done as an "atomic" operation).

The cat problem is interesting. Apple's "time machine" springs to mind, but yeah, not easy.

I got another example, you're using an editor, you go to look something up which requires you to log in (remote machine perhaps) and you accidentally move the focus back to the word processor and you end up typing your user name and password into the document... OUCH!

Still, interesting.

Re:Opera of the phantom

[Wannabe Code Monkey]

get people into the culture of exporting the file to something else when they want to send it to someone

So you're saying it's too hard to get people into the culture of saving the file often, but easy to get people into the culture of 'exporting the file'. You're just renaming 'save' to 'export' just like renaming 'file' to 'persistent object'.

Re:Opera of the phantom

[vadim_t]

And here's where things start getting into a bizarre territory.

The rationale for this whole idea is that poor dumb users find the concept of having to save so awfully unintuitive. But in that case, how well do you think they're going to deal with concepts of "undo levels" and "versions"? How will they know what to set the undo level to?

And now you're adding a new concept, that the file you're working on isn't good for sending as-is. Instead there's a way to generate a "special version for sending to other people", magical in a way that most people won't understand, and with unclear distinctions from the kind you normally work on.

Re:Opera of the phantom

[pondermaster]

"If your data are in memory and not the hard drive when it quits, you'll lose your data."

I guess you would be *really* surprised to hear about how long Linux keeps data buffered before committing it to disk...

Re:Opera of the phantom

[vadim_t]

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.

But make sure to do that right before touching anything!

Because since saving is automatic, you can only make a backup before you start touching things. Once you start editing, it's too late.

Re:Opera of the phantom

[Jezza]

If I'm going to trash your address space I need to refer to it. It seems this isn't possible (you never deal with addresses in that way) you can't even say:

address-of someObject + integer

If I can't refer to memory outside my application then I really can't trash the address space - normal memory protection isn't needed.

Re:Opera of the phantom

[Jezza]

If the data and the program are the same thing - the whole shooting match is toast anyway. The OS has persisted an object that's hosed (stuck in a loop perhaps).

ZFS seems like a good model for HOW the disk part could work. But if my object hangs, persisting this state exactly is really very helpful.

I also want to know how you "upgrade" anything.

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

[Ambiguous Coward]

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.

So, what you're saying is, it'd be like writing documents with cat?

*rimshot*

Re:Opera of the phantom

[M. Baranczak]

No, just kill the misbehaving program. Since this program is the only object that holds references to the mistakenly created objects, they are now eligible for garbage collection, and will be removed by the OS. (I'm just speculating here, I've no idea how they do it; this just seems like the most logical solution.)

Contrast that with a traditional OS. Let's say you have a program that goes apeshit and starts creating files until you run out of disk space. Most of us have seen this happen at least once. If you stop the program, and even if you delete it, the files still remain. And there's no explicit connection between a file and the program that created it, so it can be difficult or impossible to tell which files were created by the program.

Re:Opera of the phantom

[Znork]

There is quite a bit of legwork that the CPU does

Fairly efficient such tho, and pretty deeply woven into architecture issues such as DMA, I/O TLB's and virtualized OS's. VM memory management isn't just about preventing programs writing all over eachother anymore, it's also about preventing the dozens of independent chips from writing all over your memory.

And whatever changes you make are immediately persisted.

I've heard of tries like this before; the thing is, with software bugs, logic problems and not entirely trustworthy storage, execution and memory you may not always want anything that happens to be persistent. You'll still want to have sane states to go back to, and most likely without code (think of the 'file' as simply an instruction for the code to reach the desired state).

This is what users expect.

You know, the 'killer feature' on electric typewriters was that things were not immediately persisted and, while perhaps not what users 'expect', it's certainly something they desired. In fact, I'd say many people would prefer _everything_, including reality, behaving in a non-persistent fashion with the ability to save certain states to restart from.

So I have to agree with the GP, this is not something I find particularly desirable.

Re:Opera of the phantom

[icebraining]

That happens already! Java, C#, PHP, Python are already more used than C/C++, aren't them? Why should we force people? It will happen naturally, gradually, with plenty of support for legacy applications.

Re:Opera of the phantom

[davros-too]

Try google docs - while you 'can' hit save you never do. The history features completely solve all of the above problems.

Re:Opera of the phantom

[Skal Tura]

You are still missing the point, there can be a working copy (you could say this is persistant as long as user wants) and the archival copy, nothing stops implementing that feature.

Please, think of the whole. CS is not limited by technical limits, only your imagination (and time)

The method Phantom works does not prevent at all basic functionality such as that, infact, if wanted to all user interface and usability features can be 100% exactly the same.

The true benefit of Phantom's OO approach is development is far easier, and faster. Everything is reusable, recyclable, and simple objects (for the most part).

Re:Opera of the phantom

[MrCrassic]

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.

So you're trying to invent something like what hibernating your computer does now, and has done for at least a decade...

Good luck with marketing.

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

[bcrowell]

You're really discussing three separate things here: (1) autosave, (2) keeping all the old versions around forever by default, and (3) eliminating the ability to give someone else a file without also giving them access to all the old versions. You can have 1 without 2 and 3 (commonly implemented in word processors), or 1 and 2 without 3 (as in VMS).

Autosave is bad in the situation where the cat walks across your keyboard while you're making tea. Autosave is good in the situation where the power goes out unexpectedly.

In a version control system, it's useful to have ways for the user to tell the system that the project is in a sane state at a certain point (e.g., git commit), and also to have ways for the user to say that certain states of the project are especially good/complete/debugged (e.g., git tag). The good thing about explicit saves, as opposed to autosaves, is that they perform this function. On the other hand, the user may have other mechanisms available for performing this function. For instance, I use a file synchronizer (unison) to sync up a certain set of machines that mirror my files. Usually I do a sync when I'm at a good, sane stopping point in a certain task. Suppose I'm using a word-processor, and the cat walks across the keyboard while I'm making tea, causing my entire novel to be erased and then autosaved. No big deal. I just sync up with the mirror machine and grab the undamaged version. I think MacOS's Time Machine provides similar "oh shit" functionality.

When a user is used to explicit saves, it could be argued that autosaves are bad because they're inconsistent with the way the user's other apps work. On the other hand, we seem to be seeing a proliferation of systems these days that are essentially version control systems reimplemented in different ways -- built into file systems, built into applications, etc. E.g., if I'm editing file foo using emacs, I could potentially have three files: foo, foo~, and #foo#, which sort of represent three levels of version control. This is good in the sense that it's consistent with the usual explicit-save paradigm, but bad in the sense that it's inconsistent with the way other applications handle it.

Re:Opera of the phantom

[vadim_t]

You are still missing the point, there can be a working copy (you could say this is persistant as long as user wants) and the archival copy, nothing stops implementing that feature.

There can be many things, but most of them conflict with the aim of increasing intuitiveness.

I don't disagree with that things like versioning are a good thing. My claim is that versioning adds more complications than the lack of need for explicit save removes, making it a bad tradeoff when targeting clueless users. Experts are a completely different matter.

CS is not limited by technical limits, only your imagination (and time)

Yes it is. No amount of imagination is going to make your hard disk larger, or make O(n!) algorithms efficient.

The method Phantom works does not prevent at all basic functionality such as that, infact, if wanted to all user interface and usability features can be 100% exactly the same.

If it's going to be 100% the same, there's no reason for the user to bother with it

The true benefit of Phantom's OO approach is development is far easier, and faster. Everything is reusable, recyclable, and simple objects (for the most part).

No clue what you mean here. You could be as well referring to Visual Basic, or Perl, both of which seem to fit what you said.

Re:Opera of the phantom

[Thiez]

> Regardless of how cool the OS' underpinings are, you could write C for it with an OS-specific compiler.

Actually, if the VM doesn't allow casting numbers to pointers, you won't be able to do things like
  int * ptr = (int *)0x12;
unless you implement a VM on their VM.

Re:Opera of the phantom

[vadim_t]

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?

You're probably not a programmer? Saving files can get pretty complex, and is specific to the task.

Continous saving is really quite trivial to hack into a program. For instance on Linux, fork, save to temp file, replace original when done. But that's not even 10% of the task, because now that you made saving work differently the interface will need changes to support this new way of working properly. And a library can't do that automatically.

Re:Opera of the phantom

[Skal Tura]

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.

The underlying technology has quite much nothing to do with what the user gets. Never heard of phones having office apps for example? ;)

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?

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

Re:Opera of the phantom

[againjj]

Your views are constrained to a model that is based on files and the save operation. Think first about the big picture: save, undo, revision control, backups, and all other means of saving state of some document. A document exists as a file in a variety of versions in a variety of places. There is what is showing on your screen. There are all the intermediate states in memory (undo). There is the state on local disk. With something like Apple's Time machine, this is basically a series of states. Then you might have svn or cvs or git, which then has a different collection of revisions, some of which might be tagged. Each backup tape also has a copy of what existed at the time. What is the unifying theme?

Saved states are checkpoints. The current system of undo, backups, revision control, etc. is really simply an ad hoc collection of operations that create checkpoints, with an ad hoc collection of operations to go between those checkpoints. I may want the version of the tax forms from three years ago, or the version of a document that existed before my cat walked across the keyboard. I may have thought I did not want a document anymore and decided to get rid of it, and found out later that I needed it. I may have altered a picture and then decided my alterations were not what I wanted. In all these cases, I want to recover the object as it existed some time in the past. How can I do this?

Suppose we come up with a totally new way of checkpointing documents. We can create an object and modify it as always, but then once we get to a state that we think we like, we checkpoint it. Perhaps we could label it with some meaningful identifier. Suppose we alter it some more and checkpoint again. However, we are not sure that these alterations are the best, so we go to our previous checkpoint and make different changes and checkpoint that. We can then compare the two versions. We do this a lot and then decide that we have something we want to distribute, so we mark it as a draft and distribute it. Final drafts are the versions that are complete.

Checkpoints can be at differing levels of privacy and persistence. Maybe undo only works to the last explicit checkpoint. Maybe every undo checkpoint is saved for the last 1000, and then only every tenth. Maybe "snapshots" could be made which preserves the document as-is, but without any checkpoints. Maybe You could distribute documents with all undo information in it so that someone could see exactly what you did to get to the present point.

Checkpoints might be configurable, where you have only (say) three levels by default, undo checkpoints, marked checkpoints, and draft checkpoints. Say that each level of checkpoints is discarded when the higher level is used. Then power users could expand the number of checkpoints and there persistence level as well. At the extreme, you might get a strong revision control system, in essence, where every change ever made was saved and made available to a varying number of people with varying levels of access, allowing very detailed traceability.

Your blanket objection to trees (as it sounded to me) is wrong. Why not a tree? How often does a person take an idea, make a number of mockups and then compare them or have someone else compare them? Then the best items are developed further, again with possible variations. Over time branches die off, and the living branches fork. Eventually the branches are winnowed down to one that is "best". The failing designs and intermediate stages are often kept.

Notice that nowhere do I talk about files. That is an implementation detail. What the user sees on the desktop does not necessarily match what exists on disk. Do "My Computer" and "Recycle Bin" actually exist right next to each other as files somewhere on disk? I could see checkpoints being view in some sort of checkpoint browser the is similar to Windows Explorer that is integrated with viewing of all objects.

This also makes for interesting ideas for backups. May

Re:Opera of the phantom

[Anonymous Coward]

It's not that you can't save. It's that you don't have to. Your working copy is automatically saved. If you want a copy you can revert to you can make it. The issues with undo exist today in many applications.

If it helps you understand, try thinking of it as a swap file in vim, the original copy (file) will always exist unmodified until you explicitly modify it. However, if your system crashes (or the power it cut), you still have your working copy.

Re:Opera of the phantom

[vadim_t]

You're really discussing three separate things here: (1) autosave, (2) keeping all the old versions around forever by default, and (3) eliminating the ability to give someone else a file without also giving them access to all the old versions. You can have 1 without 2 and 3 (commonly implemented in word processors), or 1 and 2 without 3 (as in VMS).

That is something different from what's been suggested here.

The suggestion is not saving every 5 minutes, or even automatically creating backups, but that really no save operation is required because things get saved the moment you change them, to the point that even sudden loss of power doesn't result in a loss of data. In this case, yes, you need a permanent undo because there's nothing getting asked when you close the word processor, as all the changes have been written already, and the whole concept of unsaved changes has been eliminated.

Re:Opera of the phantom

[Prof.Phreak]

It also seems they've reinvented mmap.

Re:Opera of the phantom

[21mhz]

Good subject, heh :)

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.

You almost said it yourself. C doesn't abstract things like processes, so you cannot change the implementation of the OS in interesting ways without modifying all the applications. With the entire system as a virtual machine, you have greater freedom of implementation, while the application code may last.

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?

Re:Opera of the phantom

[dacut]

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.

I would read their claims about "address space" as "separate address space" -- that is, everything runs in a single address space. Then it makes some sense.

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

I'm guessing you don't "retrieve" documents; they're always there in memory (whether that memory is RAM or disk appears to be irrelevant for this OS; it looks like they're treating it all as a giant instance of virtual memory). Don't ask me how selecting which document to read/edit works; it would seem that lack of files breaks the window-per-open-document model, and I certainly wouldn't want to have a window around for every document I've ever written or received.

Removing the distinction between "document open in memory" vs. "document stored on disk" can be a very powerful metaphor, but it does break down rather easily. There are times when the user does care about where the document resides: e.g. that text file better be on my USB stick so I can transport it to the office.

The only alternative I can think of is a single, global, virtual memory mapping which spans every computer you would ever want to interact with. Interesting idea, but not terribly practical.

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.

This isn't all that different from hibernation, which ensures that the entire system state is written out before power is removed. That said, this doesn't mean you can remove power arbitrarily...

Re:Opera of the phantom

[vadim_t]

I will repeat for the 5th or 6th time what this discussion started about:

[...] 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?""

Now please think how would you explain your system of undo checkpoints, marked checkpoints, and draft checkpoints to the above implied target user, who finds files unintuitive and the need to save confusing.

Re:Opera of the phantom

[mr_mischief]

Users do in fact often want to have to save something. Oh, I guess maybe someone out there has never made a mistake and wanted to go to an older version of a document before those changes. I know I have, though. Lots of people have. I don't want to save my work until I save my work. Don't save things I was just trying out into a permanent storage. I don't want them there.

Re:Opera of the phantom

[mr_mischief]

think about this: save it, then save it again after more changes! OOo and MS Office and such already have automatic saving after a number of minutes. Do you really think every character you type will be saved to disk when you lose power, or only the last snapshot the program took?

Re:Opera of the phantom

[master_p]

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?

This can happen now as well. A cat walking over a keyboard can accidentally hit Ctrl+S and save the document or Alt+F4 and close the window. In either case, you don't want your cat around to mess with your computer. And then there is this thing called 'locking'.

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

Or pick a previous version from the available ones...like versioning systems provide for.

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.

Nope. The document is archived in the versioning system when the user wants.

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.

You have never used a versioning system, have you?

What if you intentionally or by accident write something insulting in the document? How do you make the program remove the record of it?

Does it say anywhere that the user could not delete objects? it doesn't.

Here's another one: Imagine this sequence of commands: I type a long document, decide I didn't like the last changes, undo too much, and then press a single letter. Does in this moment the undo history become a tree, or do I lose the ability to redo the excessive undo?

Undo/redo has nothing to do with automated persistence.

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.

Obviously, you don't have a clue. And so do slashdot modders, from what I can see.

Re:Opera of the phantom

[master_p]

That's what journaling filesystems are for: you write the data to a different place, and if all goes ok, then you switch data.

Look, you've never used a database? do databases suffer from this problem? no? why not?

Come on people, let's do some thinking and discover some real problems with automated persistence!

Re:Opera of the phantom

[mr_mischief]

What's so different between revision control on that object and just keeping multiple revisions of the file automatically? If the revision control is the selling point, who cares if it's a persistent object store or an explicit file store?

Re:Opera of the phantom

[Guido von Guido]

The System/38, AS/400 and whatever they call it this week [...]

It's IBM i now. I think. Well, that's the operating system. The hardware they run it on is now called Power Systems--they're trying to merge the hardware product line for their mid-range offering formerly known as System p, pSeries and RS/6000.

Honestly, once you've figured out IBM's marketing, they change it on you.

Re:Opera of the phantom

[bensch128]

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

I doubt they're going to disallow serialization. that's required to transfer data from computer to computer.
However, it would be interesting if the OS had the ability to save out the complete history of a file to be transferred.
Then once the file is deserialized on another computer, you'd have the file fully restored.

So the article does have some good points. However, the authors seem to have very bold predications about how awesome their OS is going to be.
It'll be interesting to see how far they get.

Re:Opera of the phantom

[Anonymous Coward]

There is a subtle difference between a "document" and a "file."

You save documents. Right now, they are saved to a file. They do not have to be. They can be stored to a persistent object database. Or across the network. There is little reason these different kinds of "files" can't have the same programmatic interface. You get some neat benefits as a side-effect, too.

Re:Opera of the phantom

[he-sk]

Most of the problems you describe can be solved by automatic transparent versioning and a snapshot feature. A "Save" operation would create a named snapshot of the current object state. Snapshots are of course auto-deleted like old backup copies, unless the user locks them.

The privacy issues with sharing object history when sharing a file are bogus as well. A user could simply export the current version without any history. The downside here is that it requires interaction by the user. On the other hand, it could be wrapped in a "Share" operation.

IMNSHO, the explicit "File-Save" operation is a 30-year-old crutch that is bad UI design and I can't wait until an operating system implements auto-save and transparent versioning.

Re:Opera of the phantom

[Anonymous Coward]

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.

No, this is a unifying idea. By treating every data store the same way, you can program generically. The operating system/environment could automatically handle version control/undo/redo, and lots of other neat things. OS X's CoreData does this already.

To send stuff to your mom, you would use the operating system's "Send Document To" (or equivalent) method. You wouldn't need a "file browser" to see stuff on disk. You would use a generic "Data Store Browser" to see the data an application knows about. Again, OS X is a good example here: the "Services" submenu, under the "application menu", has a ton of generic actions like these, and they work automatically for every Cocoa application. Spotlight shows that you don't even need a "file browser", just a "data finder". (There's good reason why OS X is such a good example. Objective-C/Cocoa is the most popular SmallTalk in the world)

The "program" distinction is also blurred here (a little), since everything shares a memory space. You don't "open a file" in the other program. You "call a method" on the object, which (essentially) is the other program. In Ruby, you could do this with a "Mixin" or the Template pattern. In Haskell, you would likely use a Type Class. On the one hand, this is just an implementation detail. On the other hand, it allows for easy dynamism or generality.

Re:Opera of the phantom

[Anonymous Coward]

It would probably also be much simpler to create a revisioning file system on top of something like this.

Re:Opera of the phantom

[Anonymous Coward]

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.

 
Low-level languages? We don' need no stinkin' low-level languages!

Re:Opera of the phantom

[Anonymous Coward]

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.

A horrible idea. I can ruin my document, by just opening the file and pressing select all and pressing any key.

That would be what the Amish expect.

Re:Opera of the phantom

[Zencyde]

But having the operating system handling it simplifies the process for everyone else. :)

Re:Opera of the phantom

[Anonymous Coward]

"This button undoes changes to your document, and this button re-does them. It's like a time machine for your document. See how the version number changes? Now, pick a version. This button lets you give this version a 'name', so you can keep track of your milestones. You don't have to use that button if you don't want to, but can make managing a project easier. And this button 'exports' the version, so that other people can read your document."

That was no harder than "Undo/Redo/Save". Heck, there's less potential for confusion, since nobody else can read the document unless it is exported.

If you want to have a really hard time, try explaining how to implement simple revision control without operating system or application support. "No no, you can't just hit 'Save'. You will lose the old version." (Why? I just want to save my changes, says the interlocutor.) "You need to use 'Save As', and give the document a distinct file name so that you don't overwrite your old versions. NO! SAVE AS." (Well Word lets me use save to save my changes!)

Re:Opera of the phantom

[YttriumOxide]

Java, C#, PHP, Python are already more used than C/C++, aren't them?

Depends on the type of work you're talking about. I do C# as my day job, but my background is mainly C and C++. I recently attended a training course on VxWorks and had to work my mind back in to the "C" way of thinking... I was actually pretty happy by the end of the course, and for the kinds of things one would write on VxWorks (think robotics control etc), you REALLY wouldn't want to do it in something like C# - C is just MUCH more suited to that (especially with some of the nice stuff the VxWorks design gives you for that sort of thing, but that's another topic)

Re:Opera of the phantom

[Anonymous Coward]

Or pick a previous version from the available ones...like versioning systems provide for.

Ok, now go explain versioning to a user who doesn't understand the concept of 'save'.

Re:Opera of the phantom

[YttriumOxide]

It's in the summary for $DEITY's sake... From the user's perspective, things still look familiar - a desktop, directories, and file icons

From the user's perspective there ARE files - it just works a differently from the developer's perspective. Users don't worry about saving before they close their word processor - it's just "back again" next time they open it. They're probably still opening it by double-clicking on the "Letter to Mom" file which they found by opening their "Documents" folder though.

How do you find it to send it to your mom?

When they go to email the document, the object is wrapped up as a "file" and attached like any other attachment. What's the difference between a stream of bytes stored on a drive and a file? Nothing... it's just how you look at it. What this OS is doing (from the summary and articles) is simply making it much less work from the developers point of view how to write these - there should be no difference between "create a new object" and "write that object to disk". For the user, this means persistent files (open, edit, close - without the "save" step), but other than the save step being removed, they'll still follow the same paradigm that they always have.

Re:Opera of the phantom

[YttriumOxide]

Well, take the travelling salesman problem

But in the real world, NO-ONE needs to do the travelling salesman problem perfectly. You introduced an artificial barrier when you said, "no approximations allowed", simply because in the real world if I needed to do something like the travelling salesman problem on a large set (e.g. 100 cities), I wouldn't do it. I'd come up with something that's "good enough but not perfect", because it's almost certainly going to be faster to do it "slower" than wasting the time computing how to do it the "fastest". (e.g. If I can come up with a simple, but imperfect solution in 1 day to do it 20, and know that it would take more than 21 days to come up with a "perfect" solution, then I'll take the imperfect one, because the final result of computation plus actual "visits" is quicker. (actually, I can make an educated guess that even the perfect solution may take at least 10 days, so I wouldn't even accept to take 11 days to work it out))

Re:Opera of the phantom

[YttriumOxide]

And now you're adding a new concept, that the file you're working on isn't good for sending as-is. Instead there's a way to generate a "special version for sending to other people", magical in a way that most people won't understand, and with unclear distinctions from the kind you normally work on.

This should be handled by the application developer that defined the object. History, revisions, and undo levels are separate objects to "the current document" within the system, but to the user it appears as one thing. When they email it to someone, they're only emailing "the current document" (which other systems will see as a perfectly normal file)

Re:Opera of the phantom

[cbhacking]

Regardless of how cool the OS' underpinings are, you could write C for it with an OS-specific compiler.

If you don't mind never using a pointer, sure. Of course, writing literally anymore much more complex than "Hello, World!" using C without one variable of a pointer type or one instance of &varName is effectively impossible; the language just isn't designed that way.

This OS is exclusively for managed code. Memory pointers are anathema to managed code, and also make serious security vulnerabilities for more likely. As was mentioned in another post, Phantom doesn't even run programs in different memory spaces - why should it, when the software can only access memory that it explicitly requested from the system? Without the ability to access arbitrary memory addresses, and with modern memory managers, separating process memory spaces is wasted effort. Thread switching is faster than process switching for a reason...

Re:Opera of the phantom

[cbhacking]

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.

This doesn't make any sense to me. Sure, while you're editing the document you would need to be able to undo fully. If the editor unexpectedly crashed, it would be nice to be able to restore not only its most recent state, but those immediately preceding it, too.

However, there's no remotely logical reason that you would *need* to copy all this history when you serialize your document to a file on a flashdrive or a bunch of encoded ASCII in an email. Sure, maybe you could send it along if you want - that's the purpose of Word's "Track Changes" feature - but you don't have to. When you "send" the document, even if it's just to a removable storage device, it's reasonable to assume that it is in the state you want it to be in, and therefore you no longer care about its prior state(s).

Re:Opera of the phantom

[Anonymous Coward]

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.

And how's your solution different from what we have nowadays? There are autosave mechanisms around. I don't find that benefit enough to switch to an OS that can't be fed C.

Re:Opera of the phantom

[sproketboy]

Well I don't entirely disagree with you but most of what your arguing now are UI issues really.

IntelliJ saves continuously as you work. When my cat walks across my keyboard (it does happen) I can right-click the file and look at local history which shows all save states + times + comments.

I can easily click the good version and roll it back.

Re:Opera of the phantom

[Mr Thinly Sliced]

All of your above problems are easily resolved by allowing the user the ability to version the objects in question.

The history of versions then provides the necessary mechanic for walking the modifications tree.

Versioned object databases have been doing this for years.

Re:Opera of the phantom

[Mr Thinly Sliced]

Well lets say the system is automagically under the hood tracking changes and saving versions.

The user gets to a "happy place" in the document, clicks 'Label This Version' and types in 'ready for accountant'.

The system creates a version of the object in question and labels it (a-la CVS tagging).

Further forward in the future, disaster happens, users sighs, clicks 'Revert to an earlier version' and selects the 'ready for accountant' version.

Document reverts back.

I've read a lot of your replies on this subject here, and don't understand your hostility to versioning?

Versioning with user friendly labels is about as easy as it is possible to make it.

Re:Opera of the phantom

[angel'o'sphere]

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.

Come on! What are you talking about? From the user perspective that system would just look like any other system. Of course data will still be organized in a folder/file structure. But also it can be tagged or organized in other ways. The point is: the native format of data is its memory structure, it is not serialized, de-serialized, it has no "file format" ... but a user would still see it in a kind of explorer.

I find it really interesting how limited the experience on /. is how a computer actually is working and how computers could work (or more precisely: how older computers or systems like Newton, Smalltalk, old Mainframes or early magnet memory computers did work ...)

angel'o'sphere

Re:Opera of the phantom

[Rary]

So when introducing a concept for a new operating system, it makes no sense to hype it up to users until you have the developers on side.

And how exactly do you get developers on side before the users?

I'm a developer. I develop software. Who do I develop software for? Users. Therefore, there is one important requirement of all software I develop: it must run on the OS that my users are using. My users are not using this OS. Therefore, neither will I.

Re:Opera of the phantom

[julesh]

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.

I think you're missing the point. A standard OS has multiple processes, each of which has its own page tables, meaning that there are multiple address spaces that the processor switches between. In Phantom, all processes are being run in the same address space, a design decision which cuts down on switching overhead. Of course, in order to achieve this, you really need to provide some alternative mechanism for achieving what those multiple address spaces used to achieve, which is preventing one running program from modifying the working space of another; in this case, that's achieved by using a virtual machine rather than direct execution, and presumably the VM is designed such that such issues cannot occur.

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

My guess is that somewhere or other in the system's memory image there's a data structure that contains pointers to documents that any application can add items to or get existing items from, something rather like PalmOS's persistent databases.

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.

I'd like to see how it performs. My suspicion is it flushes transactions to disk periodically (say in 5 second batches), which would provide an appropriate level of data retention in case of power failure, and I suspect could maintain reasonable performance.

My main concern with this is how reliable the data structures are if power fails in the middle of a write.

Re:Opera of the phantom

[Spy Hunter]

Memory in all computers is mapped to address space.

Of course, but in traditional OSes the mapping changes at every context switch. What they're saying is if you write all your code in a memory-safe language, there's no need to use separate address spaces for every process, which removes most of the overhead of process switching. This is not a unique idea; for example Microsoft's Singularity experimental OS does this too.

Nobody needs files? How, exactly, can I retrieve a document then?

This is a good question. The filesystem in a traditional OS serves two completely different purposes: persistent storage, and communication between programs. The article describes how Phantom does persistent storage, but there's no mention of how you'd transfer a document from one program to another, or one computer to another. I'd be interested to see their solution.

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.

The data doesn't have to be written instantly. Program state can be checkpointed at intervals, and only the checkpoints need be written to disk. The interval can be adjusted for a performance/safety tradeoff. While a checkpoint is being written, programs can continue running unaffected using a copy on write scheme. If the whole thing is built into the OS from the ground up and all the applications are written with it in mind, the performance could be just fine.

Re:Opera of the phantom

[mabinogi]

And how exactly do you get developers on side before the users?

Linus didn't release a full user desktop in 1991, yet somehow developers developed for it.

Developers _like_ programming as a rule, and new and interesting platforms on which to develop excite and interest them.

Re:Opera of the phantom

[Simetrical]

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.

You're assuming that the OS has a routine to execute a binary file of some kind, like exec(). Picture an OS where exec() only supported scripts. The only code that would run would be the kernel itself, and maybe some "special" programs like Java or C# interpreters. Every other program would then need to be written in some supported language, Java or whatever. Of course you could probably still write a kernel module or whatever, but it doesn't have to be possible for normal user-space programs to be written in C.

Picture this scenario: an operating system where programs can only be written in Java (or in other languages, provided they can compile to Java bytecode or run interpreters in Java). Then as long as the Java compiler is secure -- which isn't too much more of a problem than the OS itself being secure -- all programs are trusted. They can't even try to interfere with other programs, because Java bytecode doesn't have any way of encoding that concept.

Then you don't need user mode. Run all code in kernel space, give everything direct memory access and direct device access. Skip all the expensive runtime permissions checking that modern CPUs are forced to implement. There would be no mode switches, just function calls. You wouldn't have to take all the elaborate security measures OSes and CPUs must take, like flushing caches on context switches, or zeroing freed memory pages before giving them to a new process.

Of course, whether this would be worth the performance penalty of running in Java instead of C is questionable. Whether it has anything to do with TFA I have no idea. But it's an interesting idea. I got it from Tanenbaum's Modern Operating Systems, 3rd Ed. -- although I can't find it now, due to the lousy index, I recall the book mentioned that Microsoft was studying the possibility. Probably a dumb idea in practice, but it's interesting to think about radically different paradigms occasionally.

Re:Opera of the phantom

[Anonymous Coward]

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.

The same safety is, in fact, provided by current applications which do not present continuous auto-saving as their UI paradigm. They simply write extra copies of the file periodically as a safeguard, so people can recover from that version after a crash - but the last version for which the user did "File/Save" is still considered the most recent edition of the file unless the user says otherwise.

Re:Opera of the phantom

[vadim_t]

You miss the point though.

The grandparent said "CS is not limited by technical limits, only your imagination". I'm saying that no, no amount of imagination removes fundamental limits, like limits to computation and storage, and no amount of "splitting into manageable chunks" makes an O(n!) problem with a large enough n tractable.

That this particlar problem can be solved with an approximation is beside the point. I used it because the difficulty of brute forcing the solution should be very easy to understand without any specialized knowledge.

Re:Opera of the phantom

[vadim_t]

I'm not hostile to versioning. I like versioning. I used CVS, SVN, SVK, and Git.

My fundamental claim is not that there's anything wrong with versioning. It's that if you present your target user as a complete moron who is incapable of understanding the concepts of a file, and the need to save, that you can't really claim to solve this particular user's problem by introducing a much more complex versioning mechanism.

Just for a start, you somehow removed the concept of a file but added concepts of versions, tags and maybe even branches, and replaced the need to save with the need to create checkpoints.

Now if you throw out the "idiot user" idea and just say that it'd be nice if the OS allowed you to efficiently make snapshots in say, ZFS style, then that's a perfectly fine and useful thing, but nowhere near the aim of being more user friendly than the current way of saving documents.

Re:Opera of the phantom

[YttriumOxide]

You are, technically correct (the best kind of correct).

However, I think you might have actually missed my point (which admittedly I wasn't too clear on since I focused more on the specific case rather than the general concept). My point was that while you're absolutely correct that there are hard fundamental limits to certain kinds of problems, it is almost always possible to use ones imagination to come up with another solution without having to solve the expensive problem.

This of course does depend on what kind of development you're doing - someone writing an image processor for example will of course always come up against these problems and will have NO choice in the matter if he wants to implement certain kinds of image processing. However, if you're writing a specific bit of code to "blur an image" and you don't care HOW it gets blurred, only that it "looks good" (subjective, which in this case is good), you can play around with various different kinds of things until you find one that is both fast and gives the result you want. Compare this to "perform a specific blur function", where you're choosing the algorithm to use, not the final result.

If it makes you feel warm and fuzzy, I'll happily say, "Yep, you're right, and the other guy was wrong", but from a more practical viewpoint than theory, I do actually side with his statement in general.

Re:Opera of the phantom

[Bryansix]

I guess you never heard of an undo history.

Re:Opera of the phantom

[Bryansix]

every character. Read the fucking article.

Re:Opera of the phantom

[againjj]

You have undo/redo right here. If you ever want to mark a version to go back to later, choose "mark this version" and optionally give it a name. If you ever send this document to someone else, there is a menu here giving a list of times you sent the document to someone else and what it looked like when you sent it. It also has a list of all the times you marked the document.

I am not saying that my system is good, but rather where you might go if you let your imagination go. Files are hard for the average user to understand. I loved how Palm did their thing.

Re:Opera of the phantom

[mr_mischief]

Yes, because the fucking article made it fucking abundantly fucking clear that the OS made the fucking RAM, fucking drive controller, fucking drive spindle, and fucking drive head need no power to write the fucking characters you just fucking typed.

I'll tell you a little story now. There was this computer that wrote blocks to its hard drive only in 512-byte or larger sections. Under some circumstances, it even took 4096 or 8192 bytes to fill the buffer to write. This computer was called the IBM PC series (and compatibles).

Now, if you think writing 512 bytes to disk every time you type a character is reasonable or that the last characters you typed get from memory to disk with no power, you're a fucking moron. No matter how often the fucking snapshot is, no OS can guarantee every last fucking character of a typed document is going to be written to disk in a power fail situation. Not one fucking OS. Get a fucking UPS, idiots.

Re:Opera of the phantom

[Bryansix]

Actually, you can turn the write buffer off. But that's not even required because Hard Drives really should have enough capacitors on them to clear the write buffer before they spin down. That is IF they were not designed by morons.

Re:Opera of the phantom

[mr_mischief]

You're still going to lose what's in the OS's write buffer in memory unless it has absolutely none. Synchronizing on every character typed would be a performance nightmare with most current drive controllers.

If someone forgoes that standard ATA, SATA, SCSI, and SAS controllers and starts selling a flash drive with sectors that are byte-addressable from the OS, then that'd be a different story. You could probably sync the data after every character and maybe lose one or two of the last characters typed if anything. That's not what we have now, though.

Old idea

[pondermaster]

SASOS's have been doing this for decades (AS/400).

Re:Old idea

[wcrowe]

The AS/400 was the first thing that came to my mind too.

Comment removed

[account_deleted]

Comment removed based on user account deletion

IBM already did it

[ebunga]

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

Re:IBM already did it

[sjames]

Also in KeyOS (used in a number of embedded systems). ErosOS as well, but I don't think it's even been used commercially.

Re:IBM already did it

[Anonymous Coward]

Except it wasn't an object as I understood things it was a table. Data within could be accessed through row operations or SQL. Pretty cool, I thought. The best of SQL with the best of the old hierarchical systems.

Re:IBM already did it

[dpilot]

(This is all hearsay, nothing authoritiative, beyond what was published)

Heck, you don't need to stop there. The Romp CPU in the RT-PC and the processor in the RISC-6000 both had "inverted page tables" that make extremely large virtual address space - which is what we're really talking about here, practical. In fact in the early days, non-x86 AIX had a traditional filesystem layered on top of "persistent store". That odd model is part of why memory management on the RS-6000 was such an oddball.

I don't know if any of this stuff survived into the PowerPC, or if they adopted more traditional memory management hardware. (and software layers on top of that)

For that matter, the persistent store concepts predate System/38 by a considerable margin. Google "ibm future system".

Re:IBM already did it

[raftpeople]

Except it wasn't an object as I understood things it was a table. Data within could be accessed through row operations or SQL. Pretty cool, I thought. The best of SQL with the best of the old hierarchical systems.

It was an object based system. Everything was an object with well defined methods that could be called.

It contained an integrated database, every file was automatically relational (not hierarchical, that's the mainframe).

How is a reference different from a file handle

[immakiku]

Article fails to distinguish between a reference and a file handle. Instead of opening a file handle, you can just use the object reference! But wait... how do you GET an object reference? Can anyone elucidate?

Re:How is a reference different from a file handle

[Sique]

A file handle is a special case of a reference to a special case of an object and requires a strict handling of methods. You have to open it first, you have to write to it to create persistance and you have to close it after usage.

The references are just pointers to an object, and it is automatically persistent due to the Phantom OS underneath. So opening, writing and closing are no longer required, but they are done implicitely if necessary.

Re:How is a reference different from a file handle

[RedK]

In case you didn't get what the OP was saying, how is fopen(); fprintf(); fclose(); any different from GetReference(); Reference.addData(); Referance.dealloc();... On the surface, it doesn't seem to simplify a whole lot.

Re:How is a reference different from a file handle

[The End Of Days]

you don't need to worry about allocating and deallocating the references, I would imagine. Just because you hold the reference doesn't mean the object data is loaded into memory. That's handled transparently for you.

So you get the reference by creating the object. Deallocation is like deleting. It's one level higher.

I should note I'm guessing, I didn't read the article. Seems logical, though.

Re:How is a reference different from a file handle

[MozeeToby]

This is how I understand it, but I could be wrong.

Imagine that you have a large sting in your program. You leave your program running for a while and the OS writes this string off the the HDD to save some memory since it isn't being used anyway. When you come back and access the string, the OS automatically pulls the string back into memory and your program can start editing it again.

The same basic idea applies to... well, to everything in this OS (if I'm reading this right). If you want a new file, you create an instance of type TextFile (or whatever) and edit it however you want. It is automatically saved off to the harddrive while the OS isn't busy doing something else.

Two issues I see here are performance and stability. If someone pulls the plug on this OS while it's in the middle of writing something to the HDD that could cause major issues. If persisting data is made a higher priority the whole system will be bogged down waiting for disk IO.

Re:How is a reference different from a file handle

[tinkerghost]

Back when I was doing programming for the Mac (OS 5-8 in Pascal) they had the resource fork & the data fork. The cool bit was it was perfectly legitimate to build an array of records then save it into the resource fork as binary data. Restart the program & it can reload the array without having to rebuild the array.

As to the point, fopen() pulls in a specific file, however you then need to know if that file is read only, write only, read/write capable etc. With GetReference(Obj) you don't need to worry about that. Obj->write will fail if it's tagged as invalid. As will Obj->read.

To drop to bad psuedo code for populating an array from a stored state:
$text = new Array;
$th = fopen('filename','r');
$text = split(fread($th),'\n');
fclose($th);

Becomes:
$text = new GetReference("Document");

The advantage is that I don't need to know that "Document" is an array Object, because the OS/language already does. It's not amazingly useful for things like a text file, but if you're able to reference a complex data structure without having to interpret it you can pull a lot of stunts - including sharing the reference between threads even if the threads are running on different machines in a cluster.

The biggest point of the project is to force you away from the linear process of using a file and towards conceiving of everything as an Object.

Re:How is a reference different from a file handle

[asaz989]

Imagine that you have a large sting in your program. You leave your program running for a while and the OS writes this string off the the HDD to save some memory since it isn't being used anyway. When you come back and access the string, the OS automatically pulls the string back into memory and your program can start editing it again.

Ever heard of virtual memory and swapping to hard disk?

Re:How is a reference different from a file handle

[RedK]

The problem is that you can't just say Image.newReference if you want to reference an existing image. How is it different than fopen();ing a file if you're saying Image.ByName("vacation08.png"); or something ? You have to actually get the reference to the object you want and from there on manipulate it. You know what this reminds of ? Mac OS X bundles. You don't "open" the file, you just fetch it from the bundle. I think these guys are just playing with semantics here.

Re:How is a reference different from a file handle

[immakiku]

I'm still very confused. You're saying these guys have abstracted away the concept of a storage device.
You HAVE to open it first. So you're saying the OS now knows you magically want to work with an image of a cat instead of that other image of a dog you have.
You HAVE to write to it. OS also knows you wanted to flip the cat to the right and give it a cool pirate's hat.
You HAVE to close it after usage. Hmm... So I no longer have to write destructors for my image-manip classes. If there's no difference in the amount of coding required and if there's no difference to the underlying operations performed (abstraction still means the OS has to perform fopen/fprintf/fclose eventually), what's the point?

It know what evil lurks in the hearts of men?

[SputnikPanic]

Oh wait, I think that's The Shadow. When does that OS come out?

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.

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

[Anonymous Coward]

Somehow i have to thing of sonny&cher

Sounds like a Raskin project

[JBMcB]

More specifically, this sounds just like a Canon Cat.

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?

Re:OS vs lib

[Anonymous Coward]

Functionally, very little.

Squeak and other SmallTalks do a lot of what they promise already. So do many Schemes and Lisps (and the GHC extension/framework/REPL/userland I am working on will, soon). Apple has a similar technology to the "NO FILES" thing already -- it is called CoreData, and provides a transparent abstraction layer to a data store, such as "the filesystem" and SQLite.

But this is kind of an unfair question. No matter what, they will have a kernel and libraries. It might be a new kernel or just a set of libraries/interpreter defining a non-x86 virtual machine to target, like Squeak.

Re:OS vs lib

[Nethemas the Great]

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?

The need for the wrapper. Remove the translation and you gain efficiency (in theory).

I wish the the fellow luck. I think it's about time that someone takes all the lessons learned in computer science from the past several decades and try to synthesis them at the OS level. I suppose it's human nature to grumble and nay-say paradigm shifts but of all people I cannot understand why geeks, whose very jobs demand adaptability and resilience to change are taking such strong tones regarding this guy's work.

If one was to take a review of human history you would find that every gain in civilization has come because people have learned to abstract away complexities of a given subject and thus converse with greater efficiency. This should be easily recognizable by folks here. Multiplication is an abstraction of sums. We don't need to add 5 + 5 + 5 + 5 we can simply write 5 * 4. If it weren't for the abstraction of the Calculus modern civilization would have never gotten off the ground. Assembly abstracted away the complexities of dealing with ones and zeros and their meaning under a given context of the hardware. Likewise C abstracted away the complexities of assembly that required you to juggle with registers and very basic mnemonics. Java, Python and any other host of high level language abstracted away the need to deal with the physical representations on the hardware. RDBMS abstracted away the need to perform insanely complex binary searches on flat files.

We've learned a lot in computer science since the fundamentals of *nix and Winblows type OSs were conceived decades ago. It's time to apply another abstraction using what we've learned. We can barely manage the current complexities of modern software using the paradigms developed by those now looking at retirement. How are we to meet the demands of tomorrow if we maintain the status-quo? Take computer viruses for instance. Accept it or not, it was Windows 95/NT 4's abstraction of the computer's hardware that eliminated an entire class of viruses on the PC. How often are we hearing of malware taking advantage of buffer overflows, and other one off addressing exploits? Languages such as Java and C# for which there are no direct data addressing to manage don't have uninitialized pointer bugs, nor a host of other classic memory related issues because the problems were abstracted away.

Our forebears might have done an incredible job all those decades ago but they didn't write the final be all, end all chapter in operating systems let alone computer science. We need to take what we've learned and see what possible.

Re:OS vs lib

[TehZorroness]

Thank you. I loved your argument.

Re:OS vs lib

[psetzer]

The basic difference is like a $400 graphics card versus Mesa. In the strictest sense it would work but the performance penalty is too ridiculous to make it viable. The library alternative wouldn't be able to take advantage of OS resources which any sane implementation would rely on like the page table and would still pay the costs of OS overhead that the design would normally make redundant running on bare iron, like process isolation.

Re: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?

The need for the wrapper. Remove the translation and you gain efficiency (in theory).

I wish the the fellow luck. I think it's about time that someone takes all the lessons learned in computer science from the past several decades and try to synthesis them at the OS level. I suppose it's human nature to grumble and nay-say paradigm shifts but of all people I cannot understand why geeks, whose very jobs demand adaptability and resilience to change are taking such strong tones regarding this guy's work.

Probably because working at the OS layer is the wrong way to approach the problem. Unless you have a way of integrating at least something that exists before, you are creating an island where nothing goes in and nothing comes out. Stuff like this could be done by creating a new implementation of Python interpreter, just to provide one example. Also, object databases like ZODB are here already.

This is clearly a research project, but the research could be targeted better to be of wider interest. Of course it's not up to me to determine what other people will/should do with their freetime.

Re:OS vs lib

[amn108]

Very well formulated argument, and that is what counts.

Re:OS vs lib

[Nethemas the Great]

And I'm sure that's the sentiment at Microsoft and why they aren't treating Singularity with anything more than speculative, would be nice to dream by we have reality to worry about attention. I would argue though that it is our deep concerns with legacy compatibility that are holding back the state of the art for both hardware and software. The fact that we have application servers such as Zope and JBoss speaks volumes about what we'd like to be doing with our software. Perhaps it is time to cut out some of this middleware and support things at the foundation instead.

I too recognize the importance of leveraging the value of existing resources. I also believe however that there are other ways to accommodate this. In any business with even a modest amount of history there will be legacy systems that the development staff must make interoperable with current development efforts. The usual approach to this isn't to develop new systems that resemble the old. You create a bridge that adapts one to the other. Excellent examples of what I'm suggesting as it relates to operating systems would be Apple's Rosetta or perhaps Wine.

Screenshots...

[_Hellfire_]

Or it didn't happen.

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

Re:Screenshots...

[_Hellfire_]

...it's about 90% unimplemented. Someone please tag the article 'vaporware'.

Precisely my point. It sounds like a wishlist for a new OS and I don't think it has any business being a news article. Maybe if there were a solid technical roadmap and proof of concept code available for people to work with it would be worth discussing. As it stands it looks like a bunch of cool ideas that someone has leapt into implementing without thinking through.

Re:Screenshots...

[chris.evans]

4ssh0l3s. expectations of perfection from free market, and mean "free".

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

[SputnikPanic]

Oops. And now all Slashdot knows what typos lurk in my hastily-typing fingers.

(Yes, bad form, I know...)

Soviet Russia

[Anonymous Coward]

Cue the Soviet Russia jokes...

Re:Soviet Russia

[GaryOlson]

In Soviet Russia, Phantom does not save state from harm; only presents good image.

Re:Soviet Russia

[Anonymous Coward]

In Soviet Russia, jokes cue YOU!

Re:Soviet Russia

[Anonymous Coward]

In Soviet Russia, file reads you!

What the hell? How does that get published?

[ThisIsAnonymous]

Umm...this isn't a summary of the article...it's copied directly from the article. I'd prefer a summary that explains what the article is about, why I might be interested in reading it etc. Not just some regurgitated crap...

WinFS all over again?

[Amadodd]

Isn't this what Microsoft wanted to do with WinFS? Bold idea, but little difficult to implement?

Re:WinFS all over again?

[gbjbaanb]

I thought MS wanted to store files in a DB instead of a filesystem. Think of SQLServer as your file store, and instead of opening a file, you'd run a query to find it and operate on the blob of data you get back.

I think this is more like a 64-bit address space where every file actually resides in memory (even though they're mapped to disk storage and probably retrieved on-demand) so to work on a file, you just need to know the pointer to its memory location.

The Extension To Common Lisp With Persistence

[Anonymous Coward]

AP5

Cairo is finally here!

[Old97]

The file system sounds like the one promised for Microsoft's Cairo version of Windows - and XP and Vista.

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.

Re:OMG POINTERS!

[box4831]

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

I would die a happy man if I could see that happen in real life

Re:OMG POINTERS!

[geekoid]

Pointers!

Vaporware?

[malevolentjelly]

Besides the fact that this is vaporware, it simply sounds like a high-end RTOS running on a PC desktop... which isn't really a great place for it.

Call me conservative, but I am a bit skeptical about this.

Re:Vaporware?

[tepples]

it simply sounds like a high-end RTOS running on a PC desktop... which isn't really a great place for it.

Why isn't the PC a great place for a real-time operating system? What about video or video gaming isn't real-time?

Call me conservative

Dittohead :-)

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?

[Sique]

Persisted to a file?

For instance yes. It could also be a blob in a data base. Or just the page of memory the object lives in gets written bit by bit to the hard disk. A file is just a special method to make a sequence of data persistent.

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?

[orclevegam]

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.

If you read TFA that's more or less what it does. Essentially the OS will be one gigantic VM and all the applications will be loaded into one giant address space with no process separation. Apparently he's relying on having no VM instruction for accessing anything you don't already have a object reference for to protect processes from doing dirty things to each other. Presumably the OS itself would auto-inject some basic objects into the processes objects to bootstrap the process, otherwise it's not really useful for a whole hell of a lot.

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

Re:Oh really?

[larry bagina]

Phantom also stores the thread/process (state and local variables) data. If you restart m/cache, the globals are still there, but not the processes.

Re:Oh really?

[CodeBuster]

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.

Which would be a HUGE mistake. As you have already pointed out many developers have written software or components which offer this type of behavior or some variation thereof. IMHO, it is unnecessary to bloat the OS with lots of obvious variations on different types of file access. The Java and .NET Framework class libraries, for example, already include just about all of the abstractions that anyone could ever want with regard to reading and writing streams (which is really what file access amounts to at the highest level of abstraction). The OS should offer the simplest, minimal, and atomic set of operations that could possibly work, perhaps offering separate libraries on top of that ala Java and .NET, to get the job done, but it should not assume anything concrete about how data should be accessed apart from the essential basics. Just my two cents.

Re:Oh really?

[Mawen]

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.

Can you name some examples?

(The rest is more my thoughts than a reply to anyone in particular...)

I have been experimenting how to do this in a generic way with db4o in C# (an object database for Java/.NET), and putting my own notification on top of the objects as well as the database events to enable (as an option) immediate persistance of object changes the way you mention you do with config files. I still had to do work to do this, though -- it's 2009, and this has probably been done in feeble and fantastic ways 100's or 1000's of times, if not more, and where is the reusable wisdom gained? I get upset with the naysayer crowds who want to stick with tried and true methods of doing everything manually over and over, just because they've gotten comfortable with it and don't want to learn or think about anything new.

People mention Squeak/scheme/smalltalk, and I have marveled at how cool it is and wished I could delve into it, but seriously, is it a practial platform ready for mainstream? Being a mainly .NET guy now (apologies to the Java/C++ world), I just googled a .NET bridge but it was talking ActiveX garbage which I don't want to touch, and then another bridge link that looked broken. (I just found Bigloo.net, which looks interesting, although experimental.) (And I don't have any ancient IBM machines from the 80s and their obscure OS, the names of which I have already forgotten, to do this either.)

I did set up and do a bit of coding for Zope (Plone) on Python, and loved some of the advantages of the object database system there (even though it was still hierarchical), for finer-grained objects where it would be annoying to create files everywhere.

Sure, big monolithic files have their place, like OpenOffice documents, but nobody's putting a gun to your head to tell you that you must chop that OOo doc up into 1000 tiny objects... that would be insanity, and to assume someone else is insane just shows close-mindedness and a lack of imagination. (Quote from the FAQ: "And objects can be huge. No limit.")

In general, I like to see common design patterns like this moved lower and pushed as a standard, either into the language or widely-used libraries. I'm glad C# made events and properties first class entities. I'm glad the SOA bandwagon camped around the observer pattern and basically built a sub-industry that pushed standard ways to do MOM and topic based routers with JMS AMQP etc. What do we have for objects that should be persisted? How are we going to make the semantic web with interesting bits of information if nobody bothers to notice that the barrier to entry to bridging semantic web to monolithic file structures is too high?

I think a good programming framework (probably cross-language... I know there are some ODBMSs out there like Objectivity that are more multiplatform than db4o's Java/.NET) would be great, and while I am not the type to venture out and create an entire OS around this concept, it will be interesting to see if someone can create a sound foundation with a suite of desktop-domain apps that establish that there are some useful low-level mechanisms that may be reasonable foundations for (a chunk of) general development. I think all this may have been tried before with WinFS, and quite a few interesting things came of that (hierarchical db structure, big files in the RDBMS, a generalized extensible sync framework). Hopefully this Russian guy knows what he's doing and will do something interesting with this, and maybe take a standardized workable environment further than MS did (or go more mainstream than Squeak / Zope, etc).

Anyway, while I may share some of the skepticism of the scoffers commenting about the near-term viability of

Re:Oh really?

[dzavalishin]

Persisted to the disk. No files. Really. No cheating. Think of Phantom as of Unix with the page space which is reused on the next boot.

Re:Oh really?

[serialdogma]

I was thinking more along the lines of

void doSomething(){
    iMyObject obj = (iMyObject)MyObjectCollection[ObjectThatIWant];
    obj.append("SomethingHasJustBeenDone");
}

No need to explicitly close or to save anything, just dealing with persistent storage as if it were any other object.

It's appropriately named

[halivar]

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

Re:It's appropriately named

[sharkey]

The guy in charge has to kill a dog to have an orgasm?

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?

[smellsofbikes]

I'm not going to argue with you since you probably know 908376 times more about this than I do.
But I'm wondering: why have a directory system in which you store your saved state? If you stored it as, essentially, an image -- this is what's on the screen -- that would get rid of the directory system (and substitute a single monster humongous file: a dubious improvement.)
Likewise, you could communicate data between files either with cut-and-paste or by including some sort of scripting hooks that allowed you to build pipes between applications. The Amiga had something similar to this, using an implementation of the rexx scripting languate, that allowed you to move arbitrary code or data between well-written apps. That, of course, relies on 'well-written' and your various app suppliers' willingness to adhere to your standards.
Essentially I wonder if they're talking about something sufficiently different that many of the problems people are listing are mostly irrelevant to their environment.

Re:How much do you like inventing wheels?

[Anonymous Coward]

What happens if you have objects that are children of other objects and they are all having data changed in them? (by one or more apps?)

Heck imagine one or more objects been changed by one particular process (app), and the another process (app) also holds references to it. Do you get a notification "Has changed outside the app, do you want to reload?". If you say no how does the system square two differing versions of the same object (aka file?)

Expand this from files just on your machine to files on a central server/internet... cool idea, but then chaos reigns supreme!

+Isn't all this just a fancy way of saying on construction of the object de-serialise it from this file, and on destruction serialise back?
(Side note, how do you as a programmer cancel any changes in memory changes from been persisted?)

Nice idea, but a bit to restrictive I feel.

Re:How much do you like inventing wheels?

[Anonymous Coward]

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.

You know all those MVC applications that have "models"? And how there are so-called "persistence frameworks" for the model? And how you only need to query the database directly in exceptional cases (assuming the model and it's performance don't suck)? And how many MVC frameworks will create schematic code for the underlying database based on the model?

Replace "database" by "filesystem". Or not. Apple has already used this approach -- using CoreData to transparently abstract calls to either the file system or SQLite (or any other backend, in principle) -- and it works very well.

Re:How much do you like inventing wheels?

[Citizen of Earth]

I bet it will be all kinds of fun to try to get your data from one application into another, especially competitors applications.

How about from one version of an application to another? What if OO-Office 2009 uses slightly modified classes from OO-Office 2008? How do you access your OO-Office 2008 document persistent objects?

Re:How much do you like inventing wheels?

[jandrese]

To be fair, that's a similar problem to the one we have with files currently, as newer versions often aren't compatible with the older versions.

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.

Re:How much do you like inventing wheels?

[jandrese]

That's just substituting a database for a filesystem, and really a filesystem is a database already, so you're just substituting a different kind of database for the one you had originally.

After you ponder this, try to get MS Word and Keynote to interoperate.

Re:How much do you like inventing wheels?

[LaminatorX]

Not that I think this is a great idea, but I think data passing would be no worse than the current model, perhaps even smoother. Instead of opening app A, choosing exlport, opening app B and choosing import, this model could simply hand the document directly to the other application. You could simply have a document open in a word processor, then switch to the same document open in a page-layout program.

This is like Plan 9 only backwards.

Re:How much do you like inventing wheels?

[Anonymous Coward]

>But I'm wondering: ... get rid of the directory system (and substitute a single monster humongous file: a dubious improvement.)

And in the single monster homongous file, implement a directory system to be able to access things quickly (in O(log n)) ;-)

No really, I think he meant that directories are there for a reason and if you don't have them, that's going to hurt (searching, anyone?)

Likewise, you could communicate data between files either with cut-and-paste or by including some sort of scripting hooks that allowed you to build pipes between applications. The Amiga had something similar to this, using an implementation of the rexx scripting languate, that allowed you to move arbitrary code or data between well-written apps. That, of course, relies on 'well-written' and your various app suppliers' willingness to adhere to your standards.
Essentially I wonder if they're talking about something sufficiently different that many of the problems people are listing are mostly irrelevant to their environment.

Re:How much do you like inventing wheels?

[master_p]

Who says that the objects will not be in directory systems? all the Phantom guy says is that the objects will be automatically persisted. But the objects will be organized in graphs, and the graphs will be stored automatically to disk.

Getting the data from one application to another would be a piece of cake: the other app would simply use the object.

Incremental backup? much easier. Just scan the objects, find their date attribute, copy newest objects into a new store, and voila, incremental backup.

Compressing? very simple: serialize the object into an array (another object), then compress the array.

Emailing? much simpler!!! simply program the following: new email().sendTo("foo@bar.com", data).

In short, you are saying that IBM engineers are stupid. Look here sonny...especially the part that says:

While in Unix-like systems everything is a file, on the System i everything is an object, with built-in persistence and garbage collection. It also offers Unix-like file directories using the Integrated File System. Java compatibility is implemented through a native port of the Java virtual machine.

So, it is not only doable, but the best software engineers have already done it 20 years ago and in one of the most critical sectors of the industry!!!

Re:How much do you like inventing wheels?

[jandrese]

The devil is in the details though. How does an application just "hand over" data? According to TFA they can't just share data spaces, the memory model doesn't allow for it. They have to negotiate some sort of explicit handoff and copy the data over.

IBM already has this sorta..

[tjstork]

In AS/400. Dr. Frank Soltis, you are the original god. The whole OS runs in a virtual layer. That way, they were able to host legacy System/36 stuff up along side more "modern" OS/400. Everything is an object... yep..

Re:IBM already has this sorta..

[clem.dickey]

Yes, everything sounds like AS/400. And System/38 before that. Which was sometimes known as "baby FS," where FS was IBM's Future System project. In order to contains every object in a single address space, FS was to have an 80-bit address space. FS was canceled in 1975 (per Wikipedia). System/38 had a 48 address space (or rather, object space), and AS/400 increased it to 64, or maybe 65. System/38 had two layers of microcode: Horizontal (like other IBM machines) and Vertical (which was the VM interpreter for the instruction set exposed to end users). But few customers used the VM directly. They just programmed in RPG or COBOL, or bought program suites written in RPG or COBOL.

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:Not that much simpler...

[nschubach]

I'm guessing (based on a brief review of both articles) that you'd simply drag your image to the other application and it would accept the binary data if it were in a form readable?

I'm trying to abstract myself form current PCs and ignoring hard drives and files for a second, but I believe you simply open your word processor and select from the documents that the word processor has in it's container. When you want to move one document or part of a document to another application space (like a paint program) you'd simply drag it or cut/paste the data into a clipboard and place it in the other program into a new object maintained by said program.

I think of it like OO programming. You instantiate a new object and populate it with data. When you are done with it, you dispose it or store it in a container tied to that application.

The big issue I have is when the kernel takes a dump... how do you get to your data contained in the state it was when the kernel crapped out on you? How do you replace (or know where to locate) the broken piece that made your computer crash?

Re:Not that much simpler...

[Jezza]

I think they are probably going to treat the drive space like a "pool" (like ZFS does).

Usually a modern OS running out of disk space isn't pretty - I imagine it'd be like that ;-)

I think they expect you to forget your "JPG" you have a "digital picture" and you "just edit it" (send it an "edit" message) you can't "open it in Photoshop" the data and the application are the same thing. In "OO" terms the "Photo of my dog" is an "instance of the digital picture class" - it is BOTH the data and the application (clearly the code for the application is in the class definition of "digital picture" not in the "Photo of my dog".

Technically this seems OK. How the hell I email you the "Photo of my dog" I have no idea - maybe it implements "serialise and send as JPG" but that seems to carry problems in an OS where everything is an object.

It sounds really interesting, but not at all easy to make it work in existing infrastructure (like the Internet).

Re:Not that much simpler...

[Anonymous Coward]

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?

By dragging the photo into Photoshop, presumably. At which point the management app will translate the photo from whatever its native format is and into some format Photoshop understands. At the "ideal" level of integration, of course, you'd be passing around serialized objects instead of RAW or JPEG files. That would dramatically blur the line between applications because they'd actually be working with and sharing each others' data structures. This is the Nirvana that everyone is trying to get to, but though many have tried (OLE, OpenDoc, others), so far no one has succeeded in any general way. I'm tempted to say that the problem is so difficult to solve that it never will be for anything but the simplest data.

Re:Not that much simpler...

[Tubal-Cain]

they are probably going to treat the drive space like a "pool"

Which might be a problem when it comes time to add chlorine.

I think they expect you to forget your "JPG" you have a "digital picture" and you "just edit it" (send it an "edit" message) you can't "open it in Photoshop" the data and the application are the same thing. In "OO" terms the "Photo of my dog" is an "instance of the digital picture class" - it is BOTH the data and the application (clearly the code for the application is in the class definition of "digital picture" not in the "Photo of my dog".

I'm wondering how they are going to allow adjustment of images to suit a user's preferences. People use lossy formats (JPG) for saving space, lossless formats (PNG) for preserving quality, and vector formats (SVG) for scalability. One size most certainly does not fit all.

Re:Not that much simpler...

[Opyros]

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

Wow! Where can I buy one of these eternal discs? I hate losing data when my disc eventually goes bad!

Re:Not that much simpler...

[master_p]

The object will open automatically in two programs, as if you used one Java object from two threads, for example.

Re:Not that much simpler...

[YttriumOxide]

This is also entirely my own guesswork based on the description of the OS - I could be totally wrong.

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?

It seems some people think it should open two object instances, however I'd actually expect some slightly different (and rather cool) behaviour...

• You have a picture. This picture is stored as a stream of bytes on your drive (pretty much exactly like a file).
• You open the picture in an image viewer. It reads through the bytes, interprets them as being a PNG file and shows it on your screen in "human viewable form".
• You now open the same picture in your image editor. It also reads through the exact same bytes and shows them on your screen.
• In your image editor, you change the picture to greyscale. The new greyscale byte stream is different to the bytestream that's currently on the disk, so it writes it back.
• In your image viewer, the image currently appears unchanged, because it never checked for updates to what's on disk. But if you close it and re-open it (or press some kind of "refresh" button, or wait for an auto-refresh that's built in), you now see the greyscale image.

That's the best that I can explain my understanding of it from the perspective of traditional "files", however by having this all "automatic", the behaviour would only really be like this for programs written in a more traditional kind of way. For programs written or modified specifically for this OS, you could possibly even have your image editor updating "live" as you edit in the editor, because they're looking at exactly the same data, and (theoretically) the image editor would only be writing the changes back rather than the complete "file".

I do see several potential problems for this concept of course, including all kinds of nasty race conditions on object access (fun with being REALLY paranoid about semaphores, here we come (unless they're also "built in" for ALL object access?)), but they're not insurmountable problems really - they just require stepping much further away from the normal model of things that most of us are used to.

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.

As far as I can tell, it's not all that different to doing it yourself, but I DO see it as being much simpler. Imagine, I write something like the following C# code:

using System;
using PhantomStuff;

namespace CountProg
{
class Program
{
private long appcounter;

void Main()
{
CallToMagicalSystemThatTellsTheOSThatAParticularVariableIsPersistent(appcounter);
if(appcounter == null)
appcounter = 0;
appcounter++;
Console.WriteLine("You've run this program " + appcounter + " times!");
}
}
}

When I start the program, the magical call with the long name reads back the current state of appcounter. If it never existed before, it's of course null from its creation. When appcounter is assigned a new value, it's written to disk (no special call needed). Each time I re-run this program, appcounter gets incremented. This code WITHOUT the magical call will al

Re:Not that much simpler...

[aussersterne]

That's exactly the problem with OO that doesn't exist in real life; in OO, there is no "application" that gives a list of tasks that can be applied to any object, but rather each object has inherent properties and no others can be applied.

Think of a beach ball. In real life you can beachball.bounce and you ban beachball.inflate and you can beachball.deflate, so these are the sorts of things that an OO programmer would implement. But in real life if you wanted to you could also beachball.boil_in_a_pot or beachball.fold_into_floppy_airplane and beachball.write_note_and_stick_deflated_on_wall.

These last few are things that a programmer would _never_ likely implement for an object called beachball, and because properties are inherent to the object, you'll have a hell of a time trying to turn one object into another, especially (again) if no properties have been coded for doing so.

So your image is a JPG, or it is a PNG, or it is an SVG and that's basically it; you don't switch between because each has its own properties. You certainly don't get to open them as a stream of bytes (as you can do in emacs) and change a single one, or play them out to the audio device and see what JPG data "sounds" like. Though most people probably wouldn't care to do this, in a truly OO system, it's impossible unless someone implements an entire method. You have to _code_ every novel thing you ever want to do. No experimentation or "unusual" operations.

Re:Not that much simpler...

[angel'o'sphere]

  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?

Then you have 2 applications manipulating the same object in memory

angel'o'sphere

Re:Not that much simpler...

[Anonymous Coward]

What if they attach an eternal disc...?

where do I get me one of those?

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

[Anonymous Coward]

Isn't this operating system comparable to using hibernate as a backend instead of plain files? (Objects being referenced, storing is transparent)

Re:Sounds lucrative..

[Jeremi]

The guy must be just another cracked out developer..

Perhaps so, but I'm still glad he's out there. One of these days, somebody is going to get next-generation OS design right, and then we'll all have (at least) a cool new toy to play with, or (at best) a new OS paradigm that blows all existing OS's out of the water.

I certainly don't want to be stuck using only OS designs from the 70's for the rest of my career...

Re:Sounds lucrative..

[Goaway]

And every normal OS "reinvents" filesystems, then?

Re:Sounds lucrative..

[mr_mischief]

So reinventing OS/400 makes it that much newer than reinventing Unix? Do you realize that core memory systems could be turned back on in the middle of a calculation because the magnetic core memory retained its state? Just how new do you think memory persistence is?

Re:Sounds lucrative..

[arminw]

...I certainly don't want to be stuck using only OS designs from the 70's for the rest of my career...

It appears that that will be your lot until all computers are 64 bit or more and come with as much non-volatile main RAM as they do now with disk space. Much of, if not most of present day computers limitations stem from the necessity of needing to manage at least two memory systems, one fast (RAM) and the other much slower disk or the slightly faster, newer SSDs. Both of these are glacial compared to the processors and do not allow instant random access to any data in the system. Consequently, today's computers spend a large fraction of their time shuffling data around.

All OS have to deal with this present limitation. A 2^64 memory space of a single non-volatile RAM storage system will mean that internally, computers will not move data as much, but only pointers to where the data is to be found in the address space. A "file" will be nothing more than an address range. Modifying a few places in a file will not make it necessary to first read the WHOLE file, then modify a few bytes and then write the file back to preserve it in case the power to the computer fails.

When even the most inexpensive computers have 10TB of non-volatile RAM, then some truly new ideas in OS design will be possible. No such computer will ever "boot" but simply get turned off and on like a light bulb. It will always remember its state when turned off and instantly resume when powered back on.

Re:Sounds lucrative..

[goose-incarnated]

Actually, this looks like smalltalk, but without the all the good parts

Re:Sounds lucrative..

[MikeBabcock]

You sure he didn't just have a long hit from the pipe named Next? Some interesting ideas, but only if you're willing to pull an Apple and make your hardware and software and sell it in a big bundle ... otherwise you risk being another BeOS at best.

Re:Sounds lucrative..

[Anonymous Coward]

Your mom calls you stinky?

Re:Sounds lucrative..

[dzavalishin]

It is simple. Phantom is based in bytecode execution engine, and phantasm is a direct access to that engine, the ability to write directly in bytecode. It was created early in the development process to create very first boot code and test bytecode interpreter. It is obsolete now and everything is possible from hi level language. dz

Re:Sounds lucrative..

[dzavalishin]

"Good bye to C and Assembler? Ahhh, they mean goodbye to any low level hardware I/O or custom drivers ..." Funny. Why? PS: Just come and see how tiny AVR microchips are programmed in... BASIC. With all access to VERY low level things like separate chip pins. I hate Basic, but I have my eyes open.

Re:Sounds lucrative..

[angel'o'sphere]

Did you even try to understand what he is doing?

The old Newton from Apple worked exactly in that way. With various different "solid state disks" the trend in computer hardware architecture is going towards "different layers of memory with different latency/speed".

You should forget for a moment the word "serialization" in fact there is no "serialization" objects are created with new live in memory and are persistent, if the user or the program desires they get a name and are referenced via a folder (so they look a bit like a file). But: they are full fledged objects with data and methods! The distinction between data objects and programs gets blurred. You easy can write new programs that access the existing data with out any need of knowing their file format because they are just native objects (including their code ... their libraries)

The only question is how do you architecture a program in such a system, so that the user idea of "saving" still exists. In other words, you start using a program to manipulate the object "my/nice/picture.jpg" ... how to revert the changes without destroying the original object state etc. Basically you could think about some system wide or project or task specific rollback points ...

Anyway, a system Phantom Os certainly will be super cool for mini computers, hand held devices, mobiles etc. and even as a desktop OS I think it has a chance.

angel'o'sphere

Re:Sounds lucrative..

[w1z7ard]

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.

There is an assembler called Phantasm, which would fill the niche you suggest is missing. Of course any alternative to C / assembler is viewed with skepticism due to non plausible coexistence with current systems / hardware.

EROS OS

[Anonymous Coward]

This is an old idea and it has been done before.

http://www.eros-os.org/

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

[Skal Tura]

I would believe the author speaks about the underlying operating system code.

Python is abstracted heavily on the notion of file reads and writes, it still has to go through the regular hoola hoops of system calls, while as phantom as the OS makes sure it's written to HDD, you just manipulate an object.

Which is easier: (Abstracted example)
* Open File
* Write Data
* Close File
or
object->data = dataWeWantToWrite

i question thee

or maybe in question of opening a saved doc:

thisFile = savedDocumentObject

And done :)
Instead of huge bunch of state re-enabling code, in the Phantom way, the saved document already extends somekind of application data format object, in the easiest way of doing things.

Now, would you prefer to work constantly on the code of saving (serializing), and loading (deserializing) states, or would you like to simply instantiate an object? :)

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

[curunir]

From what I read, these "objects" are nothing but a fancy new name for files.

The difference, as I see it, is that these objects can do things when you call methods on them and can also have methods that tell you about the data they contain. Imagine if your .doc file had a countWords() method rather than you having to open the file with Microsoft Word and then choose that option from the appropriate menu.

As I see it, this guy is basically objecting to the notion that OO principles and a rich domain model need to end at the point where programs interact with the OS. And he's trying to build an OS that embodies those principles as well.

The problem, of course, is the "this guy" part. A single individual could have an idea for the greatest OS ever, but if he's not part of a larger effort, the resulting OS will be a concept OS that receives no adoption...and that's the best case scenario. And before anyone brings up Linus, ask yourself the same question RMS has been asking you to ask yourself...where would Linux be without the GNU tools that already existed for the proprietary Unix operating systems? The answer is a concept OS that wouldn't have received any adoption.

Re:It's just a game of names

[The Mighty Buzzard]

If that's a problem, build it into the programing language. Or a standard library.

Abstracting low level operations at the OS level for the convenience of a few tools who get wood over object orientation, at the expense of everyone else, is just plain old asshatery.

Re:It's just a game of names

[Skal Tura]

No, there's lots of benefits, infact, low level access is total burden 99% of the time, the 1% then is mostly bad design.

As said in the faq, all drivers can be done in userland too, which means, you can still have low level access, therefore, if you need to make sure something gets written to disk, and it gets written now, i would see that as VERY trivial task compared to say NVidia vid card drivers, with full OpenGL 3.0 implementation :)

Re:It's just a game of names

[oreaq]

Maybe it's more than that. It partitions the problem of writing an end user application differently than current paradigms. With Python the application pickles the object. In Phantom the OS pickles the object. The kernel programmer has to solve a different -- that is a larger -- problem set, the application programmer has to solver a smaller problem set as he doesn't have to care about persistence anymore which in spite of all the hundreds of different persistence frameworks is still a non trivial task.

As all register articles TFA is very light on any specifics so I am not sure if Phantom can really improve on this. It sure sounds like a performance nightmare.

Re:It's just a game of names

[DarkOx]

You know you could probably write a class in almost any OO language on almost any OS to do that for your right... Wait Wait then you could stick in library and just link it any time you need it in any of your apps.

Re:It's just a game of names

[Anonymous Coward]

you are dumb as a shot goose on a cold morning, mate

Re:It's just a game of names

[dzavalishin]

Say "Java". No, "Ja-a-ava". Hate Java? Say "C#" twice. Hate Java and C#? Time to say goodbye to software and come learn how to grow flowers? No, really, in 1985 I would just beat somebody if he would say C is not the best language in the world. But that was 20 years ago, no? Time to move forward?

Re:It's just a game of names

[icepick72]

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?
The comparison between JavaScript or PHP and Logo is absurd for the purpose of making the OS seem "cute", let alone fully-featured languages and frameworks not included in your list like Java, C#.NET, etc. that are definitely not "cute" like Logo and that are supported.

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.

Re:It's just a game of names

[easyTree]

And before anyone brings up Linus

Damn! *delete* *delete* *delete* *delete* *delete* *delete* *delete*

Re:It's just a game of names

[Jesus_666]

Also, persising objects instead of writing files has the big disadvantage of completely destroying interoperability. In order to read your persisted states any other app will need to be memory-compatible to yours or crawl through your persisted memory dump and parse out the data (probably from another progrmming language so you have to reverse-engineer the data structures). Good luck with that.

There's a good reason why we're moving towards XML-based file formats. Performance isn't everything.

Re:It's just a game of names

[Jesus_666]

Actually, that leads us to another question: If the file equivalent is simply a serialized object dump from one application, how do we load it into another app without the second app knowing about the first one's internal data structures etc? How do I pass something serialized in JavaScript to a Python app? Or something written in a Smalltalk-based IDE to a compiler?

For that matter, do they intend to write their own set of compilers for the platform or will there be an abstraction layer that allows file-oriented apps like the GCC to run on Phantom? At least C++ usually has a very file-heavy build process that would have to be completely revamped to fit natively into the Phantom concept.

Re:It's just a game of names

[dzavalishin]

It is possible to set up and make available some "posix" semantics file-like subsystem. In fact, it is very easy. So - yes, you can wrap GCC to work in Phantom. The question is is it really needed. Hardcore Unix/GCC guys overestimate amount of C/C++ code which is to be picked up. What I REALLY want to pick up is Eclipse/Apache Java codebase. And THAT code doesn't need files too much and will easily jump into the Phantom.

Re:It's just a game of names

[Jesus_666]

With C++ mentioned as a supported language I would say that at least part of the GCC is needed. PHP, which is also explicitly mentioned, is file-oriented as well.

Re:It's just a game of names

[dzavalishin]

No, I have no intention to support C++ or C.

The languages themselves do not need files. That's programs that possibly do.

Re:It's just a game of names

[Jesus_666]

It's true that one can write PHP applications without using file-oriented things like include(), however this is usually frowned upon for everything but trivial scripts as putting everything into one file (or text resource in this case) leads to an unstructured, hard-to-maintain blob of code. As people are hardly going to adopt platform-specific coding styles for a mostly platform-agnostic language like PHP, a transparent file system equivalent will be expected.

Some languages work better without a file system, of course - however, most code still expects one. For example, Java applications that use some kind of logging will most probably reference one or more log files as that's the most useful way of logging things on all current platforms. Again, people are hardly going to put platform-specific code into a Java application (as Java is explicitly perceived as "cmpile once, run everywhere") so again a file system is expected.

Even if traditionally file-oriented languages and compilers are eliminated, especially the languages that mesh best with the Phantom design (Java and other multiplatform OOP languages) are unlikely to use special code just to support one platform. There will have to be something that transparently emulates a traditional file system simply because that's one of the paradigms common to all other platforms, a paradigm that virtually all programming languages (or established practices) depend on. Having it might compromise the conceptual purity of the OS but it not only greatly increases the amount of available software but also makes the platform more attractive for developers.

Of course a thin wrapper that simply takes a path string and uses that to point to a data resource might already do the trick... However, many apps still expect directories so supporting at least an application-specific file tree might be a good idea, as well.


As for C++: Ah. I thought I had read that somewhere on the Phantom site. Nevermind.

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

[Anonymous Coward]

I'm fairly certain what you've written doesn't make any sense. Just saying that that something is a virtual machine doesn't make it have special abilities.

If so, that would mean that JVM (the Java Virtual Machine) already does what you want it.

I also don't understand why this would have any bearing on C/C++. Even if there is a virtual machine, it has underlying byte code to run apps, which means you can create a C/C++ compiler to compile to that specific byte code .. in the same way you can compile C/C++ code for intel, PowerPC, Arm, etc.

More importantly, transport of data is not language specific. It's library specific. Maybe you'll have library specific things, but at the end of the day you'll always be able to make bindings between languages.

As for persistence in data, most languages call it serialization. I don't care what your architecture looks like, you'll need to serial your data to memory, disk, NAS.

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

[dangitman]

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.

So, how do people "expect things to happen" when it comes to computers? The whole statement seems bizarre to me, because people never expected computers to happen in the first place.

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

[CodeBuster]

The never-saving paradigm of the PalmOS was one of its brilliant features.

This can easily be emulated in any normal file system. It all depends upon how the program handles its reads and writes with respect to files. I once built a b-tree mapped record system on top of an NTFS file system that behaved in this way so that even if the service process crashed and had to be restarted no data would ever be lost as long as the disk could be read or written because no data was stored "in memory" waiting for a write. I see no reason to give up the b-tree style file systems currently in use by just about every modern OS, they are simply too useful to abandon.

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

[Thiez]

> I also don't understand why this would have any bearing on C/C++. Even if there is a virtual machine, it has underlying byte code to run apps, which means you can create a C/C++ compiler to compile to that specific byte code .. in the same way you can compile C/C++ code for intel, PowerPC, Arm, etc.

Wether this has or does not have bearing on C/C++ would depend on the VM. For example, it would be a real pain to write a C-to-bytecode compiler for the JVM, because Java doesn't really support C-pointers. It is of course possible to create 'Pointer' objects for huge byte-arrays and transparently use those, but that way you lose the boost in speed you can get by (correctly) using pointers (If you feel bored you can of course write an x86 emulator in Java, I believe its been done before). C code that would be very fast and efficient on an x86 would probably be much slower on the JVM when it uses features that the JVM instruction set does not support directly.

It is possible to write a C/C++ compiler for any Turing-complete instruction set, but the produced code could be aweful even with a very good compiler (imagine a VM that has Brainfuck as instruction set...).

So why is the C/C++ thing important? In some situations it is nice to have the option to sacrifice high-level abstraction to get closer to the metal and gain some more efficiency. On many machines C and C++ are the languages of choice for such a thing (or even assembly, which I personally like a lot, also if I'm honest I've never needed to use it except when I wrote my own bootloader). The point is that on a system where you might want to run Crysis, you want a VM that doesn't have an extremely high-level instruction set that forces you to use that and only that _all_ the time even when less abstraction might speed things up.

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

[mr_mischief]

Ah, but while your TV is off or you're not watching it, it doesn't save a thing other than channel number and volume settings. The in-channel data (actually called a channel in this case) is streaming by and is lost unless you use a DVR, VCR, or VDR to save the parts you want to watch later. That's very well understood by most people.

Re:Read About Face...

[Jeremi]

I could expect my computer to work like a magic elf that makes me snacks, but it wouldn't be realistic. [...] The whole benefit of computers is that they aren't bound to the limitations of mechanical devices.

Wait, the whole benefit of computers is that they don't have limitations, and yet it's not realistic to expect a computer not to lose the user's data when it's turned off? I think you need to make up your mind...

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

[X0563511]

Nobody said you can't have files on top of this system, when you need thiem...

Re:Read About Face...

[cshark]

A long long time ago, at least in tech years; back in the glory days of 2001, some friends and I came up with a very similar idea. We applied an extra layer for clustering; but basically the same idea. The problem we had, as I see it now; in hindsight, was that writing the thing was pretty straight forward. At least for our group; but distributing it would have taken venture capitol. After the OSS fiasco that was Shorthand, we agreed that conventional distribution was the only way to get something like this (what the hell do you even call it?) out to the masses. Out of the hundred or so VC's we approached, we heard the same thing every time. Something like this, they would say, is a conflict of interest for any VC. Why? Because it's too out there. It's too different. Sure it's a good idea. But jesus christ man, you'll get yourself shot with something like that. I believe this guy knows what he's doing; or he's heard about what we were doing. Probably the former. I wish him the best of luck in not getting shot. ;)

Re:Read About Face...

[dangitman]

Wait, the whole benefit of computers is that they don't have limitations,

I never said that. I said they don't have the same limitations as mechanical devices. They obviously have their own limitations.

and yet it's not realistic to expect a computer not to lose the user's data when it's turned off?

When did I ever say that? My computer retains data just fine when I switch it off, because I save it to the hard drive. Why do we need some new metaphor for 'files'?

Re:Read About Face...

[MikeBabcock]

Auto-save really is stupid.

Everything I do should be logged to storage in some format either temporarily or permanently, depending on the type of work.

I should be able to open a word processor, type and print a document and close it. Tomorrow, if I didn't assign it some other intelligent title, I should be able to easily see that I have a recent document I printed that I can edit again if I like.

This doesn't require a complete paradigm shift in desktop development of course, just an underlying change in how applications handle user data.

Re:Read About Face...

[Anonymous Coward]

Actually, its the computer's responsibility to ensure the document is stored in some form unless the user decides to destroy it. Even then there should be safeguards. This is why we have file systems, backups, etc etc.

Plenty of systems are designed to ensure that data is not lost. Loss of data through forgetting to save isn't the user's fault - it is the developers.

Personally I think it is developer *incompetence* that says people should *remember* to save (eg every 5 minutes). Computers shouldn't forget. This is why we spend time and money to build and buy them. Plenty of products exist that have auto-save.

Not providing undo is another indication of idiocy.

Re:Read About Face...

[DamnStupidElf]

One word: versioning. Or maybe two words: versioning and snapshots.

And backups.

Re:Read About Face...

[DamnStupidElf]

This can easily be emulated in any normal file system.

And the point of Phantom is that it doesn't need to be emulated, no matter how the program is written.

I once built a b-tree mapped record system on top of an NTFS file system that behaved in this way so that even if the service process crashed and had to be restarted no data would ever be lost as long as the disk could be read or written because no data was stored "in memory" waiting for a write.

You had to write a queuing system just to get behavior that would be the default in a persistent object operating system.

Re:Read About Face...

[DamnStupidElf]

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.

Heh. When I take pictures with my camera, they magically show up on my computer when I plug it in. Dragging an example of nearly antiquated technology into a debate about the greatness of the status quo is, to say the least, amusing.

Re:Read About Face...

[DamnStupidElf]

If all computers were 64 bit and had at least 500-1000GB of non-volatile fast RAM, computers could do exactly what Grandma wanted.

Oh, like SSD or carbon nanotube non-volatile fast RAM?

Re:Read About Face...

[ToasterMonkey]

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.

Why do you think "Having a computer that never forgets what you've done is" means "Having a computer that always forgets what you had"?
That's foolish to me.

Automatically persisting the current, effective state really is what we expect a computer to do. The only state we want to worry about is the current one it's in... just like, you know, reality. I also think people expect a computer to be able to go back to a prior state - but that's just bonus. People mostly expect a computer to not let us put it in a bad state it cannot go back from - the lowliest of creatures in The Real World do more to preserve their own life than most computer applications. These are not too much to ask. Also, there is no substitute for proper backups, or version control, or change control, etc. They are not incompatible with the above ideals.

Here's the sysadmin mentality the GP was talking about. You assume the computer is inherently incapable of preventing you from letting it enter a bad state, so you have to maintain sometimes multiple states, and control which are in effect. Locally backing up config files, starting/stopping things, etc. Here's something that will blow you away: INPUT VALIDATION. It's all over the intarwebs. It IS the intarweb. It even works on entirely local applications, but keep that to yourself alright? God, if developers knew they could keep users from screwing their applications up by inserting a layer of code between the user and raw configuration data, we'd be out of jobs. I mean, not only could it prevent disasters, but it would HELP the user to configure the application without us. DNS servers would have working reverse lookups, designers would be configuring web servers, our mail servers would be _delivering_ mail, and our directory servers would be overflowing with useful information... shameful!

Re:Read About Face...

[ardor]

Indeed. In fact, I think that cheap non-volatile RAM will be the Next Big Thing, since fundamental paradigma will change. As you said it, no real booting done, data rarely moved etc. To fully exploit this, new operating systems have to be written, since ALL existing ones are based on the assumption that you have to copy data to RAM. "Opening" a file would equal getting a pointer to the memory block. Fragmentation would be an issue, though.

Re:Read About Face...

[Anonymous Coward]

You know COM/DCOM and the whole object mess in Windows... do you know that Word files used to have a sort-of persistence for the COM objects inside (translated into a file and saved), it was basically a dump of the memory. Microsoft tried to move in exactly the direction that Phantom is proposing. It was, and is, a fucking horror show.

That's not to say the idea has no merit, it's just that it has demonstrated a number of massive problems.

Re:Read About Face...

[tkinnun0]

To get those benefits, something has to change. I'd rather have it be the one underlying OS than each and every one of the programs that run on the OS.

Re:Read About Face...

[tkinnun0]

If all computers were 64 bit and had at least 500-1000GB of non-volatile fast RAM, computers could do exactly what Grandma wanted.

Or if all computers had a working hibernate feature.

Re:Read About Face...

[Jesus_666]

Also, how do we handle program updates that change the layout of internal data structures? We can't just deserialize the data from the disk and plug it into the program's memory; that would lead to a crash when reading data from an incompatible version. We also can't have the program update all of its structures on the disk when it's updated as that would break as soon as you have serialized objects that aren't present during the update (for instance because the volume in question isn't there at the time).

So in the end the file-replacing states that get written to disk still need to be scanned at least for which program version they were persisted with before unpersisting them. Granted, the overall overhead might be smaller, but file storage is definitely not fire-and-forget - especially as incompatible or damaged persisted states will most likely crash the entire program when loaded. And the only way to avoid that is to check the state for correctness when loading it, thus making it equivalent to a regular file.

Phantom is a nifty concept but I think a lot of the "so much better than all older OSes" rhethoric fails to see possible pitfalls that would force Phantom to behave very much like those older OSes.

Re:Read About Face...

[Jesus_666]

Everything I do should be logged to storage in some format either temporarily or permanently, depending on the type of work. I should be able to open a word processor, type and print a document and close it. Tomorrow, if I didn't assign it some other intelligent title, I should be able to easily see that I have a recent document I printed that I can edit again if I like.

You do realize that you just described auto-save? Auto-save does not necessarily need to be "all X minutes"; it can as well be "when closing the app".

Re:Read About Face...

[Jesus_666]

Oh, like SSD or carbon nanotube non-volatile fast RAM?

Just like FeRAM, MRAM, racetrack memory or the other half-dozen ultra-fast, ultra-dense nonvolatile memory technologies that were a mere year from market introduction three years ago.

I'll believe nonvolatile main memory when I see two gigs of it in an actual desktop computer. I'll believe SSDs as a RAM replacement when they have access times comparable to DDR SDRAM and/or price-per-megabyte comparable to HDDs.

There's a lot of nice technologies out there but none is really mature enough to displace the HDD/SDRAM ecosystem we have right now.

Re:Read About Face...

[Anonymous Coward]

I would argue the opposite. When a program opens a file it loads it into memory and nothing is committed to the disks until it is saved. By treating all "files" as an object the document can interact with OTHER programs simultanously.

    Imagine if you could switch spellcheckers on the fly, or use a single spellchecker on Word, OpenOffice and firefox simultanously? The concept of proprietary goes out the window if the objects have a set, base interface they need to work with. All a developer would need to enable that functionality would be to implement the interface in their application. OS upgrades would be like Java releases.

Natrually this whole concept would need a very different security model and would need a complete paradigm shift in how we interact with computers.

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

[Anonymous Coward]

Because that's how it works.

and

The whole benefit of computers is that they aren't bound to the limitations of mechanical devices.

contradict.

Re:Read About Face...

[julesh]

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.

"Object-oriented programmers who do not know Smalltalk are doomed to reinvent it poorly?"

Pretty much what I came here to post, anyway. I think the only significant difference between his system and Smalltalk is that Smalltalk does not persist its state automatically, you have to ask it to do so, so if you just switch off a Smalltalk system you lose your most recent updates.

Re:Read About Face...

[The Mighty Buzzard]

You obviously have far more faith than I do in developers. My experience has been that all code has bugs and many of them are quite capable of hosing a system beyond any ability to repair without external bootstrapping.

That's not even considering user error, admin error, or malicious asshats.

Input validation is all fine and good except that it can't be done perfectly. Hell, it can't even be done well. The input validating intarweb you seem so enamored of is only still standing because nobody with the knowledge has ever put a serious effort into breaking it on a fundamental scale and because admins like me make regular backups.

If you don't assume the eventual catastrophic failure of everything you admin as the default, you've got no business speaking in sysadmin discussions; you won't be one for long.

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.

Re:Read About Face...

[Anonymous Coward]

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.

Very practical, but also very shortsighted. "Your grandmother" is not an isolated case; most other real-world devices don't completely undo what you've done so far just because you turned them off (typewriter, camera (digital or otherwise), chainsaw. Even if 'most users now understand the concepts involved', wouldn't user education be simpler with persistent state? Isn't hibernate/sleep much simpler / easier for the user than powering on/off (when it works)? Auto-save is a poor kludge working around a completely broken system.

If the 'save' concept isn't completely broken, why is it that every single program has to prompt you to save files before you exit the program? If you found a program that didn't, wouldn't you consider that program buggy?

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.

You could expect that, and if you had a snack-making peripheral it wouldn't be unrealistic at all. I don't see the point of this comment, nor of burdening my brain with unnecessary data/details/steps/requirements.

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?

I just don't see how you think these are at all parallel.

If saving the file were a necessary part of the utility of the file, then maybe. But it isn't. You may want to print the document, or send it to someone, or keep it around for later, but none of those things explicitly say: "serialize this into an on disk format, making sure to ask for a label for it and location to store it, and absent all of these steps, I wish to lose this work forever."

To address your examples:

When you take a picture with a film camera, yes there may be additional processing and steps required. I don't see that as a feature, and neither does anyone else. That's why the digital cameras that have cut a bunch of steps out of that process are infinitely more popular.

If your grandmother types a letter, she expects it to still be in the typewriter when she gets back to it, not to have vanished into the ether.

The mailing process is another example of an unnecessarily complex process. The user doesn't strictly need to be aware of the envelope and addressing. If we had machines to do those for us very cheaply, they would sell like hotcakes. (Note that large businesses that do bulk mailing to the point where automatic enveloping and addressing is economical do that)

Re:Read About Face...

[Saroset]

The idea is that the text on a letter doesn't disappear if you put in the drawer, envelope or whatever without telling it to not disappear. That is why it's unintuitive.

Re:Read About Face...

[julesh]

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.

Serialization in Java is a library feature, too. You can implement your own serialization code, if you want, and have it work just as well (or even better perhaps) than the standard implementation.

What _is_ a language feature of Java is reflection, which makes implementing serialization a lot easier. But there's no reason to be tied to a VM to get reflection; it's perfectly possible to have reflection in a native compiled language, you just need to stuff a load of metadata into your generated code.

Re:Read About Face...

[julesh]

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.

Which is precisely the kind of system that this OS emulates: it uses a virtual machine that effectively pretends it's running on such a system, and keeps flushing memory changes out to disk so that it can pretend to have NVRAM when you switch it back on again. Of course, it'll be slower than the system you describe, but probably it will still be fast enough to do most things.

Re:Read About Face...

[dangitman]

Dragging an example of nearly antiquated technology into a debate about the greatness of the status quo is, to say the least, amusing.

Uhhh... I was responding to somebody who was using old technology as an example, showing that not all pre-digital technology "automatically saves" like a typewriter does.

Re:Read About Face...

[dangitman]

I'm not seeing any downsides to the "alternatives", either.

Then you aren't looking very hard. It's pretty obvious. If the state of something is always maintained, then what happens when you make a mistake? You accidentally type over some important text - and boom, you've lost your document. OK, so to mitigate this, you have a versioning system, which saves each change to the document. But then you fill up your storage rapidly with multiple copies of the same thing, and it also invites security issues.

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.

And so is Phantom a kludgy evolution. Everything about computers is kludgy. But this idea of "working the way a human expects" is meaningless nonsense. Firstly, because different people expect different things. Secondly because computers were never an expected development, they are relatively new. And finally, because people DO expect computers to work this way now. Nobody except for the rare illiterate newbie expects their documents to be automatically saved.

Computers are not humans, so they will never "work like a human" any more than you hammer works like a human. Do we expect hammers to be more human-like? No, we expect the users of hammers to learn how to use their tools.

Re:Read About Face...

[dangitman]

If the 'save' concept isn't completely broken, why is it that every single program has to prompt you to save files before you exit the program?

How does that mean that 'save' is completely broken? If it were completely broken, it wouldn't work at all. But clearly it does work, as millions of people have no trouble using it every day.

If saving the file were a necessary part of the utility of the file, then maybe. But it isn't.

But it does have utility. That's how you assign a name to the file, and where it goes. Without that concept, how do you organize your data?

You could expect that, and if you had a snack-making peripheral it wouldn't be unrealistic at all.

My point is not the snack-making part, but the magic elf part. If you had a snack-making peripheral, it would not be elf-powered, it would be powered by electricity.

If your grandmother types a letter, she expects it to still be in the typewriter when she gets back to it, not to have vanished into the ether.

Let's put it in its simplest terms. A computer is not a typewriter. So why should we expect it to behave like one? Most grandmothers are smart enough to know that different devices are used in different ways. She knows you have to "save" the milk by putting it in the refrigerator.

Re:Read About Face...

[dangitman]

It would only be unintuitive if a computer was a typewriter, and the storage medium was paper. But it's not. The "letter" is stored in volatile RAM. So, it's perfectly intuitive that when you switch off that volatile RAM, the data is lost. Not hard to understand.

Re:Read About Face...

[Saroset]

You missed the point entirely.

Re:Read About Face...

[Anonymous Coward]

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

i have no doubt about smalltalk being [insert $favourite positive adjective] than java. .st images can get cluttered and hosed as well as the system conceptualised as phantom.

But as so many people use "inferior" languages (think php vs. python), it is not just about if a concept is cooler but also about widespread adoption.
for a normal student/programmer and even n00b java/php may be the languages they use even if smalltalk is way more advanced because they understand them and even have some more support (documentation, code snippets etc.) for the tools they use.
i personally dislike java, but given the amount of usable documentation i believe it is way easier to get started on java compared to smalltalk, unless ones memory is so confined that learning a smaller language starts making sense.

Re:Read About Face...

[Anonymous Coward]

That's why applications where it matters, like word processors, have had an autosave feature for the last decade.

Re:Read About Face...

[Anonymous Coward]

You beat me to saying this. If i had upmod points, i would!

Re:Read About Face...

[arminw]

...Or if all computers had a working hibernate feature...

The sleep function of all modern Macs is very reliable. The only time I've had a Mac not resume properly is when I removed an external storage device while the system was asleep. Simply closing the lid on any Mac Laptop puts it into sleep mode, where RAM is maintained. The wake-up time is what it takes to spin the HD up again. Apple can do this better than other PC makers, because they design and test the OS software together with their own hardware. None of the other manufacturers have that ability. They have to make their hardware work with whatever MS dishes up and MS cannot test every computer made for compatibility.

Re:Read About Face...

[dangitman]

How? I don't believe that computers should "intuitively" copy something they are not. I believe that users should have some understanding with how they work before they start using them. And if you have a basic understanding, it's perfectly intuitive that data stored in RAM is lost when you switch the machine off.

To turn it around, should they design cars to be steered with a mouse rather than a steering wheel, because most people are more familiar with a mouse than a steering wheel by the time they reach driving age?

Re:Read About Face...

[MikeBabcock]

The programs need to be redesigned implicitly, whether the underlying OS changes or not. Software 'understands' save files and static configuration files, and that would have to be re-written.

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.

Re:Solution to the wrong problem...

[fyoder]

Perhaps you would like some Sugar, the original Desktop for the OLPC XO before Negroponte sold out to MS. They shifted from the file/folder model to a model based on activities recorded in a journal. Many grups complained because it didn't conform to their conception of a general purpose operating system, but then the designers of Sugar never intended for it to be a general pupose OS.

Re:Solution to the wrong problem...

[Anonymous Coward]

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?

Thats right, but when your desk gets full you typically put stuff in a filing cabinet. I know I don't have a thousand documents sitting on my desk.

Re:Solution to the wrong problem...

[master_p]

What you say makes a lot of sense.

The user should not see directories. She should perform queries like 'give me all the letters I wrote from 9/10 to today' or 'open the letter I was working on yesterday'.

The user should also not see menu items, buttons, toolbars and other silly stuff...just the object being manipulated. Everything should be context-sensitive.

Re:Solution to the wrong problem...

[onefriedrice]

So what you want is Spotlight, beagle, or some other desktop search software. Yeah, we have that. It also works a lot better than shuffling virtual documents on a virtual desktop or inside virtual folders.

Re:Solution to the wrong problem...

[Anonymous Coward]

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?

an answer: presto
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.63.102

absract exerpt:
Traditional document systems use hierarchical filing structures as the basis for organising, storing and retrieving documents. However, this structure is very limited in comparison with the rich and varied forms of document interaction and category management in everyday document use. Presto is a prototype document management system providing rich interaction with documents through meaningful, user-level document attributes, such as (Word file), (published paper), (shared with Jim), (about Presto) or (currently in progress).

Re:Solution to the wrong problem...

[Anonymous Coward]

In my opinion, this should be categorized as Funny.

The big point is that what these guys are doing is simply to make the STATE of each file an integral part of the file itself. Each file becomes someting vaguely similar to a self-executing-program-thingy.

Re:Solution to the wrong problem...

[Anonymous Coward]

You can already do that in any modern OS to an extent, it's called saving every file to the desktop. It's not a good practice for a good reason.

My real desk at work is insanely cluttered, unless I take out specific time to organize it. Why would I want to have to deal with the same disorganization on my computer?

And as for being able to identify documents based on characteristics, we've been doing that with programs like Beagle for a while...

Re:Solution to the wrong problem...

[Anonymous Coward]

We invented computers because doing it that way is much less efficient.

Smalltalk?

[Midnight Thunder]

This all sounds like what Smalltalk was trying to do. Basically there are no files, just one big VM where everything resides.

Believe me the absence of the file notion is a pain in the butt, since it is not clear where one thing starts and stops, and by the time you have tried making things clear to people, you are probably best representing a file.

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.

Re:Anyone ever hear of Multics?

[CodeBuster]

we make it hard for you to describe bad things to do so we don't have to work hard to prevent you.

Sounds a lot like the Ruby on Rails philosophy today...

Re:Anyone ever hear of Multics?

[AtrN]

As for eliminating languages to prevent bad code, it's been done too

Earlier than Prime. Burroughs.

Re:Anyone ever hear of Multics?

[Guy Harris]

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.

...although there was an operation that took a pathname and explicitly mapped the file with that pathname into your address space (i.e., it wasn't a system where all files existed in a global address space - the address space wasn't big enough for that).

Unix was inspired by Multics.

...but didn't pick up the notion that all access to files took place by mapping the file into your address space (it didn't even pick up the notion that you could map a file into your address space until the mid-'80's or so).

As for eliminating languages to prevent bad code, it's been done too - by Pr1mos, on Pr1me Computers,

They appear to have forgotten to eliminate assembler languate, unless they eliminated it later (note: adding a system implementation language and deprecating assembler in favor of it doesn't qualify as "eliminating").

If you want to talk about eliminating languages, you might want to consider the Burroughs mainframes, whose OS would only execute code generated by programs marked as compilers.

Not an OS of the 21st century

[mangu]

I don't think we will be quite ready for such an advanced OS until the 26th century

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.

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

[sirlatrom]

... Learning information technology is like peeling an onion. I never finish. ...

Onion peeling analogy fail. ;) Or parent never finishes cooking a meal with onions in it.

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

[girlintraining]

Onion peeling analogy fail. ;) Or parent never finishes cooking a meal with onions in it.

I actually like onions and cook with them frequently. But it's the best analogy I could come up with. Besides, it's just slashdot...

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

[Areyoukiddingme]

Rebuttal? Agreement. I categorically refuse to drink the J2EE Kool-aid. C# is two artfully arranged symbols to me, nothing more. I write C and a rather C-ish C++. Why? 'cause I'm talking to hardware. Transistors are not happy slappy "persistent objects." They're silicon that rather mulishly insists on incoming and outgoing electrical power. They're not "JIT". They're little electrical switches that don't take crap from anybody. If you want them to do something, you set the right lines low, take the data from that address and put it in this address, and if you've done everything precisely correctly, your monitor will light up with a useful arrangement of pixels. If you haven't, making three passes with an Agile programming book and pouring Java beans all over it isn't going to do a damn thing.

Yes, it's laudable to attempt to introduce useful abstractions into what is the most complex endeavor embarked on by the human race, or we wouldn't be where we are. Computer programming is monumentally complicated. But never forget your roots. Somewhere, the software meets the real world. We call that hardware. It's not abstract. Abstractions that exist for the sake of selling seminars aren't the least bit helpful. They only generate more noise.

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

[girlintraining]

My god, I love you and want to have your babies. ^_^ There is so much to be said for old school learning these days. Everybody thinks they can do better by making it more complicated. Nobody says "I can make it simple..." Not anymore. Simple is bad, and evil... Because it works, it never breaks, and corporations and management will stop employing us if we build ourselves out of a job. sigh.

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

[maharg]

I have some sympathy with your plight, but, a persistent object does not necessarily equate to a file. For example, a persistent object can be stored in a database table. Equally, a persistent object can be stored as multiple files. A persistent object can be stored in non-volatile memory.

Only a persistent object which is wholly stored as a single entity within a traditional filesystem can possibly be equated to a file. Even then, it's fairly tenuous, as the file representation of the object can be manipulated via the filesystem API, whilst the object itself cannot.

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

[larry bagina]

C is an abstraction. Use assembler you fucking poser.

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

[maharg]

Assembler ! Why aren't you setting the bits with a magnet !

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

[Bryansix]

BAN VOTE. What is this "Just Slashdot" crap you just spewed out of your face. Heresy!

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

[Areyoukiddingme]

Ah, but I do say "I can make it simple." Then management says "Can it do this? And that? And make coffee? And comb my hair? And can it have blue glowey lights and all rounded edges like a melted Apple product?" The answer is always yes. Yes it can. And when they're done, the gadget weighs 72 lbs, requires a 30 amp circuit to power it, and requires built-in wheels. Or the moral equivalent in user interface terms. :)

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

[dangitman]

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.

Don't you have this a little backwards? It wasn't until the Macintosh that we started calling them "folders." Before that, they were "directories."

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

[Anonymous Coward]

Would you mind showing us your accomplishments with that method and laugh about how long that did take you to write in C, rather than a more specialized language/framework?

When you understand that some languages are more suited to some tasks you will become a better programmer.

Take text processing for example. Would you really write that in C/C++? You can't seriously say that this is as effective as programming it in some specialized language. Maybe you would use LEX and YACC for that. Even though they output C code they have their own specialized language.

And I would rather rip my eyes out than writing a GUI with C.

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

[CodeBuster]

I would blame the marketers and the corporate hype machines more than I would blame the computer scientists and software developers for muddying the waters with buzzwords and other meaningless drivel concerning what should be unambiguous technical concepts. There was a time, as I am sure that you will recall, before the marketers really knew what computing was or could do and it was a time when engineers conversed with one another in clear jargon (which made sense to the initiated) that was not altered or added onto unless something really new and important came along and it made sense to do so. Alas, but those days are far behind us now and we have to put up with marketing idiots continually confusing the public about computing so that they can make a fast buck or two.

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

[amn108]

Precise language semantics never hurt, and I do not believe it is all just to confuse people. On the contrary the general tendency (apart when coming from someone that needs to sell stuff) is to improve communication between parties, since this is one of the biggest problems in the programming field. Same things go by different names, and different things by same names. A persistent store is not a file, because it can be something else, and if someone mentions the former, he probably does not want to have it confused with latter. I am sorry you feel like you are constantly covered with terms, but frankly most of these terms keep their meaning since they are invented, and it does not change for the most part. 'Persistent object' is not an exception. A file has some properties of a stream, while an object is nothing like a stream, unless it is a stream object :-)

I do not like to waste my time learning useless crap either, and I do not like to talk geeky with anyone. I would much rather have people use computers intuitively without having to bother why their 'Spreadsheet document' does not open in OpenOffice but opens in Microsoft Word ("What is a 'file format' ?")

And I am sorry you feel like peeling an onion. I personally stopped feeling like that since I have learned the true properties of this field, and they go way back. Computers are our slaves and the only thing they can do essentially is traverse through a precise list of orders. It is truly simple, much like you see it probably, but it does not mean we like to complicate it. Nobody forces you to, but a file and a persistent object are not the same thing, and we need to at least know the meaning of the words that come out of the mouth, and trust that these are not perverted to another meaning at the other end of the conversation, if we ever are able to build something atop our social and communicative skills. To broadly assume 'techies' do this all the time would probably do them more harm than good, and that Dmitry guy, he just has subpar English skills, so he has at least one excuse to mess up the communication, which he does too. But there was a reason he called it a persistent object - it is not a stream of data.

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

[Anonymous Coward]

Speaking of new names for existing concepts, "peace" is a new one to me. I think you meant "piece", but with this ever-changing lexicon, who can be sure?

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

[d'baba]

Because brass gears, levers and pulleys aren't magnetic.

--

Hypertext is not what it's marked up to be.

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

[Anonymous Coward]

You are right, it's a constant redressing of the same old thing.

But I don't think it's a conscious decision, I think that since the abstractions (for example for "file", "directory") are there for such a long time that people stopped remembering what the abstraction actually means and just remember the implementation (which is bound to be less than what was envisioned - it being in the real world and all).

Then they notice that the "files" are "so limited" etcetc and go on invent a entirely new abstraction when what they should have done is fix the implementation (but you can't change the implementation, stuff will be incompatible blahblah yaddayadda).

I remember some people saying "and then we can just collect all of the data files into an archive file and when starting the program up, unpack the archive file". ???. Just put it into a directory and don't archive it in the first place if you are going to need it all the time.

Or the strange aversion of representing network storage are file trees. Guess what, you can mount your IMAP4 mailbox so that it ends up as a normal file tree in your system. Does anyone do that? Nope.

Likewise with "object persistence", just have the fields live in the files in the first place (mmap them if you want). There, implementation problems appear again: mmapping 238242 files at the same time doesn't always work (not even opening them at the same time sometimes). Reaction: implement another darn abstraction instead of fixing the implementation so it DOES work.

In a unix environment, if you use mmaped files for all your data, you'd have RAM speed (it caches, remember) AND automatic storage to the backing store.

What files (and names) are in most systems today is a sad joke as opposed to what they could have been, even opposed to what they really are in Plan9.

That said, being able to link to other files from within one file would be cool. Oh wait, that's possible with a directory.

cheers,
        Danny

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

[Anonymous Coward]

George Carlin called, he wants his skit back...:-D

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

[Anonymous Coward]

> George Carlin called, he wants his skit back...:-D

How'd he do that, by Ouija board or crystal ball?

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

[Anonymous Coward]

Amen brother.

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

[dzavalishin]

You are wrong. Show me how pointer to publicly inavailable "file" can be given from one Unix app to another, and show me this second app calling "file"'s method. Sorry.

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

[ion.simon.c]

/* Ask and ye shall recieve */
#include <sys/stat.h>
#include <stdio.h>
#include <unistd.h>

const char fn[]= "randomFileName.txt";
int main()
{
    pid_t pid;
    FILE * fh;
    fh = fopen(fn, "w");
    fclose(fh);
    chmod(fn, 0600); /* Making file publically inavailable */
    fh = fopen(fn, "w");
    pid = fork();
    if(!pid)
    {
        char data[] = "Writing to publically inavailable file\n";
        fwrite(data, sizeof(char), sizeof(data)/sizeof(char), fh); /* Pointer to file has obviously been passed to other app */
        fclose(fh); /*Calling close method on file */
    }
    else
        while(waitpid(-1, NULL, 0) != -1) ;

    return 0;
}

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

[ion.simon.c]

Take text processing for example. Would you really write that in C/C++?

Why not? With std::string and boost::regex, text processing isn't *that* much of a chore.

And I would rather rip my eyes out than writing a GUI with C.

Have you ever used GLADE?

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

[dzavalishin]

Nope.

1. It is available. To root at least.
2. Now repeat that for unrelated processes and show me the code size.
3. Now call me that file's method.

Sorry, I'm Unix programmer for 20 years now, and you're trying to sell me what I've seen all 20 years ago. I don't buy.

Now for phantom's code doing the same. That's real code from Phantom boot/test sources:

    run = new .ru.dz.phantom.system.thread_test(); // Create runnable object
    boot_object.18(run); // that's lowlevel thread start call
    run.store_boot_reference(boot_object); // give him something to chew

Now lets compare.

1. Mine is shorter 4-5 times.
2. Passed object is really unavailable to all the rest of the world.
3. method of passed object is available to receiver, not just some bytes.
4. class of object is known to receiver and can be used to access it's structure thriugh reflections mechanism.

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

[ion.simon.c]

1. It is available. To root at least.

On an SELinux (or similarly configured) system, that file might only be available to the user who created it. It truly could be unavailable to the public. :)
Anyway, I was under the impression that "Only readable by the user who created the file" was not "publicly available". So, what is the "rest of the world" in your scenario? A single process and those that it deigns to communicate with? If so, how does a process indicate that another process is permitted to have access to its data?

2. Now repeat that for unrelated processes and show me the code size.

Oh. You're moving the goalposts. Thanks. I imagine that I'd use something like DBUS to do what it seems like you are proposing.

3. Now call me that file's method.

What is a file's method? I get the feeling that we're running into a language barrier here. (Don't worry too much about it, though. Your English is far better than any non-English human language that *I* know. :) )

        run = new .ru.dz.phantom.system.thread_test(); // Create runnable object
        boot_object.18(run); // that's lowlevel thread start call
        run.store_boot_reference(boot_object); // give him something to chew

This looks like plain old C++ to me.

3. method of passed object is available to receiver, not just some bytes.
4. class of object is known to receiver and can be used to access it's structure thriugh reflections mechanism

This strongly smells of a wrapper around DBUS or something *very* similar.

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

[dzavalishin]

"What is a file's method?" - the post I replied to was saying that nobody needs objects 'cause files are the same. I was asking in reply to show me a "file method call" to show some difference between file and object.

PS: Phanom's native language is very C++/Java alike, of course. I don't want to create a thing which looks completely alien. :)

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

[ion.simon.c]

the post I replied to was saying that nobody needs objects 'cause files are the same.

Gotcha. Your "file" system is something like JavaBeans or OLE for processing/parsing file formats? If so, then is it required that the application programmer provide the "Print" methods for each new data format that he wants the system to handle?

PS: Phanom's native language is very C++/Java alike, of course. I don't want to create a thing which looks completely alien. :)

Makes sense.

Smalltalk-80, anyone?

[argent]

Smalltalk did this in the '70s, and the idea goes back to APL in the early '60s.

I could speculate about the reasons this never seems to become mainstream, but instead I'll just point that out and let other people do that... :)

DRM?

[Fishbulb]

Sounds like this would be easily adapted so that you can't access a file if you don't have permission due to DRM restrictions (you have paid your monthly access fee!).

Expect to see this on set-top boxes and as a feature of Microsoft Media * (or just Windows generally) as soon as the MPAA/RIAA get wind of it.

These guys'll make a fortune licensing to those asshats.

Re:DRM?

[Anonymous Coward]

Wow there's not a single word in your post that is NOT based on minimal comprehension and maximal trolling. There are HUNDREDS of fundamental objections to this thing, and you pick on DRM and somehow Microsoft? Sounds like you must be an IT asshat type...

Multics had it even earlier

[Anonymous Coward]

Multics had segments - not files. Segments moved between main memory and disk, but they were always just segments.

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

[Pentium100]

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.

IANAP (programmer), but wouldn't that mean that once an app managed to semi-freeze the PC it would always stay like that and a reset wouldn't be an option?

Re:agreed: persistence, not files

[nschubach]

What I understand is that the program could be run in a "stateful sandbox." If the program freezes, you simply tell the host to retrieve that same program from the last state save.

Re:agreed: persistence, not files

[illumin8]

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 can see a huge problem with this. If every object ever instantiated becomes persistent until deleted, what happens when you have a memory leak? Bad code could easily fill your hard drive and destroy your entire computer. How would you delete millions of objects with broken pointers?

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.

Re:agreed: persistence, not files

[horza]

Well Microsoft did try. The concept of a file is not really archaic, it's a good metaphor when used correctly. A lot of storage these days does not map down onto a file system but onto a relational database. Even the config files for a number of applications use sqlite rather than a file.

Going back to parent post, people DO want to be able to save at certain stages. Being able to switch off and not lose data is somewhere that has gone backwards though. Even with a basic text processor, when I used to use vi I could just switch off and when I switched back on it recovered my file. None of the newer text editors seem to do this!

Phillip.

Re:agreed: persistence, not files

[smidget2k4]

Maybe I'm missing something, but from a Userland perspective, this doesn't seem like it would be any different. If a user wanted to open or move an "object" vs a "file", how exactly would it be different? They'd find the "object" or "file" in some sort of sorting interface, and manipulate it as much. Keeping an open instance of an application with each object is quickly leading to bloating trouble. I'm not sure how this would be less confusing for a user.

From a programming perspective, this seems to be a nicety that is largely handled by compilers/operating systems already. It'd save some time not having to worry about file details and just creating an object. Or it'd be really cool to just be able to tell the OS to export this object to disc. But neither of these seem mind blowing or paradigm changing to me, however, like I said, perhaps I am missing something here.

Re:agreed: persistence, not files

[Pentium100]

So, under current system (windows):
1.Some program fails and hangs, while taking some resource (like a TV tuner). No other program can use it, and task manager can't kill it.
2.I save all open files on other programs.
3.I restart my PC.
4.My data is safe (with exception of the freezed program).

Under the "stateful sandbox" system:
1.some program hangs, takes a resource and can't be killed.
Now I have two options:
2a.I restore the system from an earlier state.
3a.I just lost data from other programs.
or
2b.I do nothing.
3b. I saved my data, but the hanged application will remain hanged even after a restart (essentially - forever)

Also, What would happen if a program was accessing some hardware, I turn off the PC, remove the device and turn the PC back on?

Re:agreed: persistence, not files

[vadim_t]

I want to be able to manipulate & transport objects as such, not as files.

How are you going to deal with compatibility issues in this case? What happens when the internal data structures change, new fields are added or removed?

The way I see it, for any amount of complexity you'll have to come up with an on-disk format that's nothing like the in-memory one, and then a couple lines to open/write/close files pale in comparison to the amount of work needed to do that.

Re:agreed: persistence, not files

[Anonymous Coward]

I do not argue with any of your points, which are sage, but one. When a fellow has spent his entire life managing files, his brain is built around it. This user intuitively thinks of files. And at some point every other person in the world will have had the opportunity to have this baked into their brains from an early age in such a way that it is intuitive. Now please, go right ahead and make something more intuitive to NEOPHYTE users, which I'm sure is possible. But to a user that is accustomed to files, there is nothing unintuitive about files.

Re:agreed: persistence, not files

[Anonymous Coward]

The concept of "files" is archaic
Especially that it "files" concept is directly connected to slow magnetic storage media storage - you now DOS stands for "Disk operating system" and the main part of the OS was the storage on the disk. Now when we have much faster and large flash slowly displacing HDD and in the near future probably memristor or similar high-density based system, the concept of RAM as only faster cache of bigger memory system is much more appealing. The concept has lot of merits, we should give the guy some credit - even if the recent implementation might suck.

Re:agreed: persistence, not files

[tepples]

If every object ever instantiated becomes persistent until deleted, what happens when you have a memory leak? Bad code could easily fill your hard drive and destroy your entire computer. How would you delete millions of objects with broken pointers?

What do you mean by a "broken pointer"? I would imagine that once the objects become unreachable, the defragmenter will take care of deleting them.

Re:agreed: persistence, not files

[tepples]

Especially that it "files" concept is directly connected to slow magnetic storage media storage

"File" as you know it is a conflation between persistence of an object in non-volatile storage and persistence of a particular revision of an object. If you have a bunch of objects with definite states stored as values in a dictionary, and this dictionary is persistent, the objects are "files" no matter what kind of physical form the persistent storage takes.

Now when we have much faster and large flash slowly displacing HDD

As of the late 2000s, flash still writes more slowly than platters.

Re:agreed: persistence, not files

[Anonymous Coward]

Also, without files (or equivalent), you can't have standard file formats. This kind of system would then be vendor lock-in heaven.

You'd have to have standardised APIs for IPC, I guess, like ARexx back on the Amiga.

Re:agreed: persistence, not files

[metamatic]

Bad code could easily fill your hard drive and destroy your entire computer.

Just like today, you mean?

How would you delete millions of objects with broken pointers?

Maybe with an automatic memory management system. In fact, maybe one would use a language that doesn't have pointers that can dangle.

Re:agreed: persistence, not files

[DigiWood]

Check out Squeak.

Re:agreed: persistence, not files

[TopSpin]

Linux is, indeed, based on what is now a very old paradigm - approaching half a century. Concepts have advanced since

No, actually, concepts have not advanced. The hardware is larger and faster, but from the perspective of software the design of any modern OS, from PDA to supercomputer, is entirely familiar to anyone that wrote system software for an IBM 360-67 (virtual memory and 32 bit addressing) as early as 1966. With the possible exception of extraordinarily high real concurrency (and some of its consequences such as STM) everything we see today was present and fully exploited by software in those systems.

The fact that it didn't take very long to produce software designs sufficient to fully exploit the hardware doesn't mean the software is designed incorrectly. It just means the problem space isn't that complex. There are many research operating systems for the same reason; they're not hard to make.

A prime example is the notion of "restarting" a computer. Why, these days...

Damage accumulates. Resource leaks, fragmentation, failed subsystems that aren't designed to restart without power cycle, cosmic rays, etc. All of these "concepts" are ancient and unchanged. They won't be changing for the foreseeable future.

Solutions to these problems exist but remain expensive and imply limitations on the resulting product that confines their application to highly vertical and/or costly systems. The general purpose, inexpensive systems on which you expect to run practically any trash you might throw at it do not meet that standard. They could be made to at the cost of becoming unaffordable. You would also find the inflexibility of a rigorously reliable system intolerable for a personal, general purpose use.

You're the reason, in other words.

Is it possible that some new OS design can reduce the costs? I don't know. What I do know is that the ideas behind Phantom OS have been tried before, and you and I are still running 30-40 year old designs to read about the many attempts.

The concept of "files" is archaic

The concept of a named persistent sequence of data is not going away no matter what you call it or how many abstractions you pile on top. If the word "file" is too prosaic feel free to employ the "document" euphemism.

Re:agreed: persistence, not files

[sznupi]

Though I suspect inertia in software will be a deciding factor, kinda like one of the answers for "why Plan 9 didn't take off?" goes...even if me, definatelly non-programmer (webapps/scripting languages don't count...at least in this discussion), can imagine future direction in hardware which would merit new OS approach (memristors/blurring completelly the disctinction between RAM and storage? Or even "processing RAM", kinda like small onchip vram in x360 does fsaa in hardware, but to the level of full cpu - blurring the distinction between ram & cpu)

Hey, perhaps that's what holding back singularity/AI... ;)

Re:agreed: persistence, not files

[nschubach]

Each program... as in if your program freezes, you restore it to a previous state... not your whole system.

Re:agreed: persistence, not files

[the-advanced-lemon]

We already do it like this in python, the only difference being you have to explicitly pickle an object each time you want to save it's state. Now if the OS can do it all for me, and do it well, then I'm all for it. But the problem is, it's obviously going to be using some automatic system which I have no control over. Whereas if I program that system myself, I get to choose when and where it saves! This to me, seems more useful than forcing every program to let the OS manage it. Maybe I am wrong?

I think it's a very good concept that should be explored further. But at the end of the day, people never move on to a better version of something unless there's a good reason to do so. And programmers, to be frank, don't care that they have to save files and such, it's only the users that are bothered about that.

And one other thing that bothers me - some code needs to be fast... And being fast means throwing pointers around very quickly. And sometimes that requires treating them like integers. (say for a fast and simple binary tree where you do some pointer magic to find each node without it being explicitly referenced) This is stated as being impossible - so Phantom OS can preserve security between applications. This means that it will require extra layers in between to basically reimplement some 'virtual pointer' functionality that Phantom OS disposes of with it's 'pointers'. That will make life complicated, and slow down programs that need something along these lines. When I'm raytracing, I want it to build the octrees in seconds, not in days.

Re:agreed: persistence, not files

[julesh]

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.

Google "smalltalk-80". Download an implementation. Play with it. The concepts you're talking about are coming up to 30 years old.

Re:agreed: persistence, not files

[Eli Gottlieb]

Storing/transferring what we call a "file" would be better served by persistence & portability of objects.

Really? I agree on a certain level that we can and should probably leave behind explicit open/close/read/write calls by now in favor of an automatic persistence of some sort of "object", but that leaves a few questions. First, how does the program tell the OS about an object so it can be persisted? Secondly, what kind of naming system and name-space is applied to these objects? After all, I don't want my operating system to classify a document I'm not currently working on as garbage and delete it; I want the system to distinguish between "trash" objects to delete as soon as the last reference goes away and "closed" objects to maintain in some sort of name-space for later use.

On the Infinium PC

[etherlad]

Is this the OS that the Phantom console is coming with?

I can't wait to play Duke Nukem Forever!

Phantom OS, OS of Vaporware authors everywhere

[Hordeking]

Word has it that Duke Nukem Forever is being ported to run on Phantom OS.

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.

Re:Yes, well known idea.

[Zencyde]

Well, to aid in persistent issues, the OS can keep histories of files and you would be able to choose how much you wanted to delete. Honestly, I think this is a step in the right direction. There aren't very many brilliant programmers out there; but, if we can get the brilliant ones to do this, all of the mediocre programmers will become pretty good overnight.

Multics, anyone?

[uid8472]

Smalltalk did this in the '70s, and the idea goes back to APL in the early '60s.

And, perhaps more to the point, Multics, also in the '60s.

Re:Multics, anyone?

[argent]

Multics used a file/disk oriented model, and programs were created and destroyed... it had nothing like Smalltalk or APL's workspaces. The main distinction between Multics and its spiritual successor UNIX is not that the files were objects or elements in a persistent object store, but that files were memory mapped. This turned out to be a bottleneck because the small address space of even mainframes of the time meant they had to use a complex paging scheme to deal with files over 256k.

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.

Re:Rebooting

[Skal Tura]

I would believe this system does not suffer from traditional memory leaks as such, atleast as easily and as likely.

I would also assume that every sane application would havea reset() method, which basicly re-instantiates it, clearing all runtime data :)

Also, i would believe this system will still require like flags for truly persisten data (MP3 files anyone?)

Re:Rebooting

[cbhacking]

There probably will be an actual reset mechanism. However, this really shouldn't be needed. Since the OS manages all the software (no user-space un-managed code allowed), the OS knows what resources a program is using, and if a program is ended, the OS knows exactly what it *was* using and can free it all. To prevent a greedy program from taking everything then dying, reserve enough resources to terminate any given application easily.

Re:Rebooting

[Anonymous Coward]

Don't know about you, but I can't remember when i was searching for a memory leek in a python or a ruby program.

I have done so in C++, C and assembler.

Also as a Ruby programmer, my programs really don't have much contact with files. Everything is stores in JAR files and loaded by the middleware ever time we deploy an updated version, but I can't see why the JAR have to be stored as a file. Everything is in memory at all times anyway.

A little example can show how we fetch the data in an enterprise system using ruby on rails.

Accounts.all(:conditions => "value account
    rapport.send
    rapport.overdraft_repports_sent repport
    rapport.save
end

Accounts is an object that fetches accounting information from the database and return each of them as Account objects. The rapport.save method saves the rapport persistent to the database.

In this example there is a little bug. Rails will send a BEGIN before my first line and a COMMIT right after the last line meaning that something fails there will be a big rollback on the database and if some emails have been send, there will probable send an email to the same accounts again at the next run.

This example was just to illustrate that enterprise application doesn't really need files. They use Object serialized to databases. Sometimes we do have to worry about things like then to commit data to, but usually the framework handles this correctly.

We seldom login to the server. We can't do much from the Bash shell anyway. 'ps -A' only shows a lot of processes called java, why at all install bash or ssh?. Why have all that complexity is a server?

Re:Rebooting

[Simetrical]

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.

You aren't supposed to be able to use C, remember? Memory leaks aren't a serious problem in Java: it's garbage-collected. You'll probably need to be able to somehow reset the program if it gets borked in some other way, though, and I wonder how that would be managed without the clear distinction between persistent state/transient state, disk/RAM.

Noteworthy curiosity

[ztexas]

I commend their bravado in creating an OS from scratch, but can't see what need is addressed by this endeavor. Just how often does a truly novel OS gain a significant foothold in the desktop/server market? It took Linux many years, and its feet were firmly planted in Unix tradition. If nothing else, it's an effective way of generating traffic to their consulting site.

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.

Re:the idea's worked in practice before

[Anonymous Coward]

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.

And [NTFS|FAT|EXT?|*] file systems we use today only store files as contiguous blocks? This is old news.

Re:the idea's worked in practice before

[anaesthetica]

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.

Would this type of operating system make encrypting your hard drive (through steganography or cryptography) easier, since there are no physical files on disk?

Re:the idea's worked in practice before

[plsander]

This lack of physically continuous files on the S/38 continued onto the AS/400 (now iSeries).

There are still files - I can create, open, copy, etc the file object.

For the most part, the file system on the 400 does not expose the physical disk units. The closest analog in the Linux world would be all the devices being added to a very large LVM.

This has advantages -- running out of space, add more drives. There is no need to worry about moving files around to these new drives. The OS balances the data load out on to all the arms.

The data can be unprotected (loose one disk, loose all the data), or the disks can be RAID-5, RAID-6, or Mirrored protection.

But don't get the idea that the iSeries has no files.

Phantom, eh?

[Anonymous Coward]

Does it run on the Phantom Console yet?

Is this just a Ninnle joke in disguise?

[Anonymous Coward]

This Phantom OS is just that. I suspect it's just a Ninnle post taken too far.

He dislikes linux?

[Noxn]

So my system is running a dinosaur?
Sorry, no.

Also, i don't really think this will work good.
Im not an computer expert or anything, but copying everything from RAM to HD could hurt performence and stuff.


I hate how he clearly targets linux here
I think linux is way better then any windows (Thats what I think). Also his stuff is still vaporware and he is talking like he owns the OS market...

I would like this (concept) if it where open source...
Many devs = Succes and a better(?) linux.

Re:He dislikes linux?

[SanityInAnarchy]

So my system is running a dinosaur?

Most likely.

Im not an computer expert or anything, but copying everything from RAM to HD could hurt performence and stuff.

Well, it's clear you're not an expert.

From what I understand, it doesn't copy all RAM, it asks objects to serialize themselves -- which is pretty much how programs would save state now, only it's done automatically.

Even if it was, how do you think hibernation works?

I think linux is way better then any windows

Irrelevant. He's trying to build a system much better than both of them.

Also his stuff is still vaporware

Maybe. It has been done before, though. Look up Smalltalk.

I would like this (concept) if it where open source...

Well, some of those Smalltalk VMs are... I do agree with you there.

Many devs = Succes and a better(?) linux.

Linux != open source.

Re:He dislikes linux?

[Noxn]

I just got burned. *g*
And as far as i know linux is open source. Or most of the distros.

Yeah, hibernation works like that (as far as i know), but doing it often still (could) be a problem (or maybe not.)

Also, why is linux a dinosaur? (Fanboy sense is tingling XD)
Btw, what are you running? A dinosaur or a broken window?


DISCLAIMER: My opinion is MINE, even if im totally wrong :D

Re:He dislikes linux?

[SanityInAnarchy]

And as far as i know linux is open source. Or most of the distros.

Whoops, that'd be better written as:

Open source != Linux.

However, while we're on the subject, most distros now rely on large chunks of proprietary code, even in the kernel.

Also, why is linux a dinosaur? (Fanboy sense is tingling XD)

All modern OSes are based on very old ideas, and few have any kind of clean design. That is essentially what this guy is trying to say, but I'm not convinced his design will ultimately be better.

A trivial example: There is a Unix philosophy that everything is a file. There are a few major problems with the POSIX API for this, which could really only be improved by adding wholly new APIs.

For example: Files do not allow data to be added in the middle. That is, you can append data to the end, and you can overwrite data in the middle, but you can't insert data in the middle. The way around this is either to keep everything in such small files that you never have to do that -- which can get impractical very quickly, with most filesystems -- or to rewrite the entire file (impractical for large files) -- or to instead append that data to the end of the file, and make a file format flexible enough that data can be located in such a haphazard fashion.

What this inevitably leads to is applications re-implementing many of the same things the OS does. You see games packing everything into zipfiles, because if they had to store each texture in a separate file, it would use much more space, as most filesystems will allocate a 4k block even for a 100-byte file. You also see various databases implementing ways to relocate data inside the file, leaving gaps, and to later "vacuum" or "compact" the database to recover them -- in other words, they're completely re-implementing filesystem allocation and defragmentation.

Now, technically, if you had an efficient enough filesystem, you might be able to use the POSIX API to store everything in individual files. But then you have the problem of trying to keep it consistent. For example, if you save a text file in your editor, it's probably reasonable for the editor to flush it to a temporary file, then rename that file on top of the one that's there.

Keep in mind, though, that's flushing to disk, whether or not the data is that critical. It's not difficult to imagine a situation where you'd rather have a transaction -- you don't care if the data makes it to disk immediately, as long as it's all in a consistent state when it gets there. For example, installing a new package from your package manager -- you'd rather either all of the changes make it to disk, or none of them do, but you don't care which parts are written to disk, when, and in what order. In fact, you'd rather the filesystem reorder things, to optimize it -- so long as you can synchronize the whole thing at the end, you're good.

Unfortunately, neither POSIX nor any POSIX filesystem I know of supports transactions -- you have to hack your own, either within one giant file, or by flushing tempfiles to disk. Package managers tend to have a concept of a "half-installed" state -- if the system crashed at that exact moment, the filesystem wouldn't be able to roll back, but the package manager might be able to at least retry the installation.

If you've read this far, great! But keep in mind, all of that is just about the filesystem -- and that's not the end of it; I've got quite a few more complaints which are addressed by ZFS, but not by Linux (yet). I haven't even touched on things like IPC, library usage, or that session concept.

I'm not saying that this idea of using objects instead of files is necessarily better. In fact, I'd rather see it go another direction -- something more like ZFS, where you have a storage engine which just allocates extents for you, and a POSIX filesystem is just one of the applications built on top of that layer. Then, you could build something like that object system,

Constant disk I/O?

[Anonymous Coward]

From the faq:
"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 that, it sounds like it constantly snaps what's in RAM to something like a pagefile?
That's got to affect HD performance if it's basically always writing to the disk.

It's nice for powering down your machine, but honestly I'd rather have a "hibernate" button that makes me wait five seconds than making my machine drag while I'm actively using it.

mmap & VM

[Anonymous Coward]

It is possible to do something like they are saying, by using mmap() to map the whole address space onto disk, with the ability to grow when more objets are created. They could then use COW to ensure that state is not lost during a power failure.

Basially its just a VM (aka: JVM/.NET/python) without the expliit ability to call open()/write().

Just a semantic difference

[KidSock]

Files or "persistent objects", it doesn't make any difference since things are ultimately serialized to streams. In fact, the whole thing sounds pretty clumsy to me.

Seriously, tears freezing?

[emandres]

From TFA:

It's nine degrees Fahrenheit in Moscow right now. That's the kind of cold that makes a man concentrate on his work so he can keep from remembering that the tears the wind blows out of his eyes will freeze on the side of his face before they hit the ground.

I've walked to campus several times at 9 Fahrenheit or lower and have yet to see tears (or spit) freeze before they hit the ground.

Re:Seriously, tears freezing?

[smellsofbikes]

Agreed. I spend time in the Colorado mountains and I can say that it takes at least -10F before you breathe out and the exhaled water freezes on your (scarf|beard.) I've been in -25F a number of times and even then it wasn't cold enough to freeze a droplet of water that was large enough to separate under its own weight (about 1/20 of a ml, if I remember right.) That's for pure water, too; I don't know what the osmolarity of tears is but it's probably high enough to lower the freezing point even further.

Will I be able...

[Chris Mattern]

...to run the Phantom OS on the Phantom console?

great idea!

[speedtux]

I'm sure it will be just as successful as object-oriented databases and database-based operating systems!

I, too, made an OS...

[Anonymous Coward]

It's a virtual machine that runs PHP. It's a kind of a PHP-OS, I call it POS for short.

dream on

[poot_rootbeer]

Persistent data objects require non-volatile persistent data storage, i.e., disk. But access times for disk are dismal; that's why every general-purpose computer and most of the specific-purpose computers since UNIVAC have used some form of volatile, but much faster, form of memory to store working data. This working copy by necessity has to be synchronized with the persistent copy periodically.

The benefit of Phantom OS, the not-yet-developers of Phantom OS argue, is that this synchronization is done for you automatically; the programmer does not need to think about it. I argue the programmer knows (or SHOULD know) the synchronization needs of the data better than the OS ever will.

Say there's an object in Phantom memory representing the textarea control I'm currently typing this comment into in my browser. How often is it going to save the changes I'm making to its contents back to disk? Once per minute? Once per second? After every single character I type? Even though this is just a couple kilobytes of plain text, if the VM has to re-write it to disk 300 times a second, it's going to be painful.

I suppose Phantom programs could give hints to the OS recommending a sync schedule for each object type it uses -- but at that point, why not just make it the program's responsibility to synchronize? And most programs already do just that, whether it takes the form of flushing a data buffer or auto-saving a draft of a word processing document.

misfeature IMO

[Anonymous Coward]

The OS really doesn't (or at least shouldn't need to) know enough about how the application behaves to know what the best strategy is for flushing data to persistent storage. Maybe it needs to be flushed after each line, maybe it should accumulate data until there is idle time, maybe it should wait until some application specific atom of data is received, or maybe it should wait until the user explicitly commits it to disk.

This isn't just a performance concern, its a data integrity concern. If it lacks support for control of how data is written to disk it is a useless OS... but if its required than what is that fat abstraction layer buying you?

Actually, I it can be very good in some cases

[Anonymous Coward]

I have an interest in J2ME programming so I know a little bit about devices that support it and immediately came to think of one thing: Some low-end phones don't have any physical equivalent of RAM but instead only one persistent memory in which both files are stored and which is used as "RAM" (so an app you write might no longer be able to start all of a sudden just because the user added a new mp3 ringing tone but I digress). Now on such a device, it is actually pretty retarded to save data to a file (a RecordStore, to be precise) when you close an app and then read it again when you start it if you could just as well just have it and the app in memory all the time. It wouldn't need any more memory either because you'd only need the running instance of the app in memory and instead of launching and stopping it, you'd simply switch to it when you use it.

So on a device with such a physical implementation, Phantom would probably be the best OS. At least for certain types of apps - the concept of files is fundamental for a word processor but a chart plotter might work better considering what it does with its data (plots trails and updates the chart data whenever possible).

obQuote

[Xunker]

"We have persistent objects, they're called files." -- kt

It's all been done before

[ermintru]

There seems to be a lot of this type of thing around at the moment. But compare with IBM's AS400's single level storage (is it not the same - or so similar as makes no difference). Same with virtual machines - VM on the Mainframe anyone was there years before. Most of the new things seem to be old big iron software working on new chips. As someone who started on microprocessors then went to big iron (360), minis (AS400) back to pc and now back into unix big iron and now visualization is the big thing. It makes me laugh, - but then again as an on the ground techy no one listens and to change from centralized to decentralized and back again works wonders for consultants revenues. Where I work we have huge mainframes but no one thinks of putting "new stuff on them". We also have huge numbers of unix boxes with huge updating problems and so on and so on. What annoys me is so called "old tech" is rejected when it may be the best as what it can do is not understood management, also old tech is stuck to as management are unwilling to change. It's a lose, lose situation for business but a win, win situation for consultants. As most consultants maximize there revenue with partnership deals and generally rely on graduates that do not understand the capabilities of in place systems.

Electric. Razor.

[bluefoxlucid]

Things I like:

• Safety razors with Merkur or Gillette Platinum (sweedish!) blades, and good shaving soap
• Manual transmission
• Cast iron charcoal grill, and natural charcoal
• Electric Toothbrushes
• Dual-core computers

Things I don't like:

• Propane grills
• Electric razors
• 3 or 5 blade razors, for that matter
• Cars that let you drive them without being aware of the car (i.e. traction control/electronic stability control fudging steering/braking to make slick, icy, wet road seem like firm-grip dry road... until you're in an emergency situation and have no idea how to actually control a car, so you hit pedestrians and telephone poles)
• Operating systems that decide "Unix is old" and "Files are old" and thus that the very basic concept is old, not good, and something shiny and new is obviously much better.

People: Technology is not magic; newer is not better; and we have something that works, works well, and makes sense to humans and computers. Relational databases make sense for structured data store; files make sense for abstract data store. A file is an abstract stream of bits, and attempting to replace it with "something else" will lead you to rename the "file name" with something fuzzy and abstract.

Use Revisioning

[markmuetz]

If you think solely in terms of undo histories then yes, getting back to a previous state can be time consuming, take up large amounts of memory and/or cause RSI. But If you think in terms of auto-revisioning then a scheme like this could make more sense.

Cat jumps on your keyboard? No problem, switch to an earlier revision

Accidentally delete the doc? No problem

Go back too far? Just spin forward a couple of revision

Admittedly it could be hard for the average user, and it will remember the almost all of the complete historical state of the document (including any insulting things you've written: why would you do that?!), but I'd consider it quite a benefit to be able to roll back time on all docs, not just the ones in a git/svn/hg repository.

Hmmm, maybe a time machine would be handy?

Re:Use Revisioning

[vadim_t]

Admittedly it could be hard for the average user, and it will remember the almost all of the complete historical state of the document

Stop right there. This is an admission that this theoretical user who is so confused by the need to save isn't going to do well at all dealing with revisions.

If you're talking about a specialized package designed for people who do things like editing newspaper articles or documentation and want to have all changes precisely tracked, then sure, it might be a fine idea. But this puts it completely outside of the scope of making something intuitive for a non-technical user.

Re:Use Revisioning

[markmuetz]

Granted, the average user is going to fall flat on their face if you show them git's history trees or some Journalist's revisioning software. But give people something simple like time machine with a nice slider, and they might do OK, so long as you do a good enough job of hiding the complexity of what's going on.

Re:Use Revisioning

[mr_mischief]

Gee, I think people already have something like Time Machine to roll back to a previous state. I think it's called... Time Machine.

Really, revision control on objects vs. revision control on files is still just an object store vs. file store debate. You can have either an object store or a file store with or without revision control.

What's more is that most of the drawbacks for either files or persistent objects are fixed by revision control. So the big deal should be automatic revision control in the OS and not an object store. Guess what... VMS already had automatic file version tracking years ago.

Distributed?

[nurb432]

If not, i don't see it being 21st century. more like 20th, with a gimmick.

Why on earth build a new OS for this?

[Anonymous Coward]

If their idea has value, they should be able to implement it as a library on an existing OS, or at worst a VFS driver, and demonstrate it.

An OS has absolutely nothing to do with whether you access your files through a POSIX API or not.

Re:Why on earth build a new OS for this?

[amn108]

Very good point, sadly one that not many get.

Obligatory In Soviet Russia...

[jiteo]

System operates YOU!

Re:The Extension To Common Lisp With Persistence

[brilinux]

Yeah, old Lisp Machines were what popped into my head when I read the headline - it would be interesting to see a more modern OS with a lisp core and an advanced CLOS-like interface to everything.

Lack of commit and rollback

[tepples]

The never-saving paradigm of the PalmOS was one of its brilliant features.

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. With a traditional load/save system like that of a PC, on the other hand, I can commit an object to the file system (Ctrl+S) or roll it back to the last commit (Ctrl+W Alt+D) when I know the object is in a known good state.

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

Re:Lack of commit and rollback

[DamnStupidElf]

the deletion became permanent as soon as it passed out of the one-step undo buffer. With a traditional load/save system like that of a PC, on the other hand, I can commit an object to the file system (Ctrl+S) or roll it back to the last commit (Ctrl+W Alt+D) when I know the object is in a known good state.

Yeah, but if you delete a file it's gone. That's one level less of Undo than the Newton had, apparently. What the Newton lacked was just a temporary trash area for things that were deleted, but might need to be recovered. That's even easier to implement in a persistent object based file system; just put a reference to the object in the "trash" and delete the main reference, but the trash will hold on to the original until the reference in the trash is deleted. Much like a hard link in Unix, but with the entire state of the object referenced, not just a set of files. Or in other words, fixing the problem on the Newton is much, much easier. Just make the Undo log a few actions longer by keeping more object references. My guess is that the limitation was due to memory usage.

Re:Lack of commit and rollback

[ckaminski]

Two words: version control

What a joke.

[Anonymous Coward]

If people think that Linux is an obscure operating system that "nobody" uses, certainly less than nobody will use the Phantom pipe dream.

Noble but not without ideological faults

[amn108]

Reading Dmitry's website www.dz.ru left me with mixed taste, and NOT because of his less than desired English skills, but rather because the concepts he is trying to outline and the FAQ do not rest well with my understanding of the problems todays OS's deal with. He just jumps to the other end of the computer science concepts scale, the one that has been collecting dust ever since the concept of computer 'files' has made it as far as Hollywood, and the other end is just as lonely as the one Linux and Windows sit at. Everything-is-objects is an overhead we can live without, because frankly it is debatable if everything is. An 'object' introduces a whole layer of functionality which some pieces of data just might never need or would want to circumvent, and in that sense it will suffer the same fate as everything-is-a-file concept in Unix, which we inherited from stone age of computing. Albeit a file being a simpler construct than an object, the performance issues he will encounter will be substantially higher than with files where files are not applicable. I wish him well, and especially so that he realizes what the true challenges of computer systems are today, which he sort of tries to address. The website is worth a read though, I guess, even though the concepts he tries to explain on his pages appear to be either at planning/infant stage or are just somewhat messily designed.

Commit and rollback

[tepples]

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

On the contrary, a "file" provides a convenient checkpoint for when one wants to roll back recent changes to a document. Do you really want to create a new revision of the document every time you type or delete one character in a text editor, or for every stroke in a paint program? Or what checkpoint method that happens more often than load/save but less often than individual unit changes would you recommend?

And whatever changes you make are immediately persisted. This is what users expect.

So how does the user "unpersist" a mistaken change?

It is a very interesting idea

[n4pcq]

The real problem I ran into when working on a basically the same idea was how to maintain a population of millions of objects (most small, some large) and keep performance at a decent level. Most of the criticisms in the various replies can be answered by bringing more object classes into the mix. Careful algorithm design is required to avoid touching every object in the system unless there is a specific reason to do so. When the total set of objects will fit in memory it isn't much of a problem. When the object population starts swapping to disk, though, and you try to send a message to each one, then performance goes down the tubes. The project seems eminently doable and I encourage them to keep going.

best programmers in the whole wide world

[Anonymous Coward]

Now we know what Putin was talking about when he mentioned "Russia has the best programmers in the world".

What happened with Hurd by the way ?

Distinction without a difference

[tepples]

How about using version control?

And every time you commit a revision to your local object store, that's called a "Save".

Who said there's no "current version of document" operation? It could even be named "Prepare for public consumption", in the File menu.

"Prepare for public consumption" is just "Save As" expressed using big words. So now we're right back to files. Or can you show that your distinction has a noticeable difference?

Re:Distinction without a difference

[Anonymous Coward]

How about using version control?

And every time you commit a revision to your local object store, that's called a "Save".

Or you can realize that a persistent undo history is a primitive form of version control, where "saving" corresponds to tagging a version.

Who said there's no "current version of document" operation? It could even be named "Prepare for public consumption", in the File menu.

"Prepare for public consumption" is just "Save As" expressed using big words. So now we're right back to files. Or can you show that your distinction has a noticeable difference?

Uh, the difference is that the operating system handles managing your discrete data packets/objects/files automatically and smartly. It handles rolling back and forward smartly.

You, as a developer, don't need to know a file's path -- you search the data store by key. "Prepare for public consumption" is more like an "Export" function, serializing the object in a format (which will probably be a bona fide file somewhere) after pre-processing.

Here is an example of a current, working, useful technology: http://developer.apple.com/macosx/coredata.html

Re:Rantware?

[abigor]

Linux, being inspired from the most stable, tried and tested operating system in history - Unix - isn't a bad thing. Hey, it works, right? And it has a GUI too!

"Using Unix is the computing equivalent of listening only to music by David Cassidy."

Rob Pike

where does the stupidity lie?

[FalseModesty]

I should learn to stop being amazed when people say "I don't understand it, so it (not me) must be stupid". Slashdot has really gone down hill in the last few years...

has been tried many times, limited success

[Ancient_Hacker]

There have been breathtaking departures from the ubiquitous file-->I/O-->Object-->variables-->Registers-->CPU juggling act. Some like the IBM 38 said fuck all that, the CPU works on data objects directly, with no registers, variables, or I/O.

Problem is you have to get everybody to drink this Kool-Aid, from the compiler writers, DB implementors, OS designers, programmers, and end users. IBM was a big enough gorilla to try to force this, but in todays world that's not likely to happen.

ANd for the first few generations performance will be an issue. One will always be able to point to some other system that runs faster cause it does not have some of the overhead that the general object system has.

Re:has been tried many times, limited success

[jd]

Sure there have been departures. uMicro's OS was object-based, back in the 1980s. I quite liked it. It could also handle the programming languages that Phantom can't, suggesting a retograde step is being taken.

In many ways, MULTICS was a "departure", although technically it's modern programming practices that departed from the direction MULTICS went in. But, hey, it's all relative.

Plan 9 also had some really neat concepts that are missing from "traditional" OS'. Along with all the other examples I'm giving, C doesn't seem to be a problem.

The Transputer went one step further with Occam. An amazing architecture that was completely uniform from the depths of hardware through to the heights of the primary programming language. Elegant, powerful, massively under-utilized, and not terribly well-supported by Inmos' parent company, Thorn EMI. Again, classical programming methods could be used.

The few programs that utilized the Transputer module for the Amiga (which had a single Transputer in it) used very classical programming methods as it's hard to parallelize across a single core.

AFAICS, Phantom appears to repeat history without learning from it.

Re:has been tried many times, limited success

[Creepy Crawler]

In the spirit of Occam, is Erlang.

There's something beautiful about a language that can open a TCP/IP connection in 3-5 lines of easy to understand code. Then you can push that code to other Erlang processes on your network.. And the graphs showing thread utilization of YAWS vs Apache... wow. All I can say is wow.

It's too bad that the Transputer idea never really caught on. The idea of each CPU combining for one massive resource pool is amazing, and that your terminal (a full computer) is just connecting to the others. Even your programs never exit, as they're moved to other CPUs,

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

Re:Even if they make it work...

[Opyros]

Perl, Python, Ruby? Sure, all will work, but have fun rewriting the interpreters themselves in Java!

This has been done for Python and Ruby. I believe there was an abortive attempt to do the same for Perl a few years back.

Re:Even if they make it work...

[FrankDerKte]

... it'll be a closed ecosystem: Not only an os that cannot run any existing software, additionally it will be a mess to communicate even the simplest things like web pages. Essentially everything in the World Wide Web are strings of 0s and 1s. Last time I checked, files looked the same. It's that simple, actually. And everyone with a bit of networking experience knows the big-endian / little-endian problems. Or the different line endings for text files. The best development in the last years was the spezification of html and xml. Which are files. Without them the whole WWW would be pointless. And what about sockets ? Just imagine what will happen if, for example, microsoft would develop an own object-oriented os. And they want to communicate. Conversion hell all over again. And how would someone represent a media stream as object ? So the only things I can find about Phantom are tons of questions and marketing mambo-jambo on the Homepage. If it were 1999 I would consider buying some stock. But as it is 2008 I will just laugh out loud.

The 80s called, they want their AS/400 back.

[amchugh]

Isn't this the whole point of the AS/400?

April Fools Joke apparently early

[Anonymous Coward]

ie the name Phantom...

geez, don't you people get it, no where to download and look at it... from some obscure company in Russia... gimme a break.

On a different note, I have a car company in Detroit doing quite well, great profits, and for sale, any takers?

Can the fantom evaluate this ?

[Anonymous Coward]

You don't do pointer math or any of that shit.

int myArray[ROWS][COLS]; int buf+len *void; int *ptrInt; int intOffset; { - lpAddrStart = addr - sizeof(DWORD); /* Find block LISP container */ + lpAddrStart = (char*)addr - sizeof(DWORD); /* Find block evaluator */ dwBlockUsed = ((BYTE*)lpAddrStart - (BYTE*)lpMemArea)/dwBlockSize; (if ptrInt[3] (list 1 2 "foo") (list 3 4 "bar")) len = 1> ++ | more > stdio

Files!

[Brandybuck]

There are two ways to store persistent objects, as files or in a database. But the boundaries between the two are starting to blur. Bragging that your OS doesn't have files just doesn't make sense. I bet recovery is a bitch on Phantom OS.

A real virtual os but persisted?????

[trelamenos]

well ok i think i can imagine a big big class with more and more classes in... and all this as an oporating system. this is what we are all talking about, isn't?????????

Not exactly groundbreaking.

[Anonymous Coward]

Besides the parallel to IBM systems, this kind of behaviour is seen in the Oberon Project.

http://www.oberon.ethz.ch/

Object state can be persisted to disk, and the whole system is snapshotted regularly with a journal. Pull the power plug, and you are back ( well almost ) to where you were.

Yesss!!!

[Anonymous Coward]

In Soviet Russia, Phantom files open you!

It's time for O/S technology to move on.

[master_p]

Files, processes, sockets, ports, handles, open, close, double click, save...dinosaur computing systems indeed.

I support this guy's ideas to the fullest. It's hard to do, but it has been done before (see AS/400). It's time we get this technology to consumer level.

Is it April?

[seanmoon]

Oh come on, it's not even April Fool's Day!

Oh, so he wants a Lisp Machine

[Anonymous Coward]

One commonly rediscovered wheel is the idea that the compartments and engineered abstraction layers of modern systems are wasteful and we'd be better off with a single deeply-integrated language runtime where all facilities were on an equal level and could be interactively mungled. This being opposite to a layered system of kernel, services, applications, scripts, etc.

There are terrible engineering quagmires introduced when the entire system is a monolithic hackjob subject to runtime adjustment. You reach a limit of how much complexity one brain can hold, surpass the limit, and end up with an irreproducibly broken system. Rigid interface abstractions and modular decomposition are one of the trusted engineering shortcuts to reduce this complexity.

At present, state management is one of the things that needs to be rigidly simplified to provide reliable systems. We need human-visible transaction boundaries and snapshots like "save file" so that state can be safely exported, recovered, and exchanged. With all of the online presence of the modern web world, no evidence exists to suggest this problem is being solved any better than it was twenty years ago when distributed applications were starting to spread widely.

Sounds a lot like Microsoft's Singularity

[Yossarian45793]

Am I the only one who thinks this sounds a lot like Singularity OS from Microsoft Research?

Sometimes you just want to boot

[BrianMarshall]

There is a good reason for the standard:
User: "Well, my computer seems to.."
Support: "Reboot your computer"

Halfway to there from Linux

[benthurston27]

I was thinking a bit about this, if on Linux you could "suspend" individual programs, it could write the state of the program to disk, and then later on possibly even after a reboot you could reenter that saved state with the application looking just the way it did when you suspended it, it could be like somewhere between exiting the program and just minimizing it. Could be cool.

Single Level Store

[Anonymous Coward]

It's called a 'single level store'. These existed decades ago.

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:That wouldn't work.

[Anonymous Coward]

So you want to rewrite not only the OS but also all of the programs?

Have fun doing this, and notify us when you're done - by that time I'll be retired and will have some spare time to check it out.

Re:That wouldn't work.

[SanityInAnarchy]

So you want to rewrite not only the OS but also all of the programs?

Well, not me, I have plenty of less ambitious things to focus on.

The guy writing it seems to want to have a low barrier to porting existing apps which are written in sufficiently dynamic languages. Chances are your C app won't work.

Put another way, the transition from Mac OS 9 to OS X was handled much the same way, as was DOS to Windows. Sometimes, you do need something radically different, and when that happens, the best you can do for legacy apps is to put them in a virtual machine.

Old stuff, new wrapper

[guruevi]

I have a book here that talks about C++. It says something like this: don't think a file as just a series of data. Think of a file as the variable data in a serialized object that happens to be saved on disk for later retrieval. Basically the book goes (deep) into the algorithms of saving files for your program and what all you have to think of to save a file as an object (the book is from the early 90's with the examples on a 5.14" floppy for DOS). It shows you how to make your program portable to both DOS and Unix and makes it object oriented (to support multiple processes etc.) by basically writing your own database filesystem.

A big hint was given?

[Anonymous Coward]

It's called the Phantom OS for a reason, because it's an OS that doesn't exist. Nothing to see here, move along people.

OMG

[Anonymous Coward]

I am sooo gonna use this when it's better than everything else out there!

nice idea and all

[wzzzzrd]

but the fact that the state of an application is NOT persisted enables you to reboot. what this phantom os can (or will be able to) do we already can do, with every programming language, but in RAM. the "added value" is just that RAM==persistent state. but we actually want RAM!=persistent state. oh, and not only real files are modeled like files, message pipes, io channels and lots more uses the file abstraction. just take a look at the world you are getting your ideas from: the java world for example wouldn't work without clear boundaries (tiers) where you know something is persisted or not.

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 ?

Arrrgg, me buckos! ! Pirates!

[gishzida]

if you plan to pirate anything on this system remember that all you need to do is to overwrite the "intellectual property" with the following string: 09-f9-11-02-9d-74-e3-5b-d8-41-56-c5-63-56-88-c0

Where?

[Runaway1956]

I've scrolled through the comments, and find a lot of meaningful commentary, insightful comments, some trolling, etc. WHAT I WANT TO KNOW IS, where can I download it? I visited the Digital Zone site, but see no links to download. I'll reserve judgement on something new, until I can test drive it......

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.

Re:We've been down this (exciting) road already

[MerlinTheWizard]

You may also mention Bluebottle (Oberon): http://www.oberon.ethz.ch/systems/bluebottlefolder

Re:We've been down this (exciting) road already

[ion.simon.c]

It would seem that the POC for Phantom is speaking with slashdot:

http://slashdot.org/comments.pl?sid=1119163&cid=26762879

Grasshopper OS

[quarrel]

During the first year of my Phd (1996?) I worked on the networking stack of a Persisent Operating System called Grasshopper.

They throw up a lot of interesting problems from a research point of view, but I'm not sure they're ready for prime time... (and yes I realise the intervening years have started to add up!)

Pushing boundaries is good in research of course, and lots of things do end up appearing in real products even if not the in the form originally imagined.

--Q

One more step

[mattr]

It would be even sweeter if every every object can have its own URL (a system-provided one and an optional user-provided one).

Can this be a single OS spanning multiple machines?

Also, I note the FAQ says network connections will die across reboots. This needs to be fixed.

If fixed, this can become a true cross-machine OS where you can store objects on other physical machines across a network and still treat them as part of your OS.

In other words, the OS needs to include RMI and a concept of resources being temporarily unavailable / latency / real time-ness at a deeper level. And its frequent snapshots should be handled by the nearest trusted disk resource.

It is also unclear how a media stream is stored. Presumably it is made of a stream of frames or the like. Considering this with a network spanning architecture, I believe it is likely that copying or publishing could be based on a scheme similar to BitTorrent, in which slices are distributed to maximize efficient resource usage. Since there is no real limit then perhaps 64 bits might not be enough.

FWIW I like it and vote Phantom as the next Parrot target!

Mod parent UP!

[fnj]

implement it as a library on an existing OS.

Bingo. This project's stated goal is as STUPID AS DIRT. A file based OS already supports any damn weirdass thing you want to do with your apps. All we should be talking about here is some off the wall, ill conceived, Messianic development framework.

Legacy

[krischik]

How should I put it? I know: Legacy code.

When you have a new OS most applications will support the new features and only a few ported applications won't.

If you have an old OS with a new lib then most applications have been written before the lib was introduced and therefore just ignore the new functionality.

Need an example? Well extended attributes. How many Linux applications do you know which make good use of then? I know only one SAMBA - but you have to switch support explicitly on as it is off by default. Ahh, and if you are lucky you have an Apache witch supports "user.mime_type".

But how many applications set "user.mime_type" on Linux - as they should do. None, Zero, NIL.

That was different in OS/2 where extended attributes have been build in almost from day 1 and the ".TYPE" and ".ICON" where universally put to good use.

Martin

Many valid criticisms...

[Anonymous Coward]

but... for a tech news site, you guys are a bunch of luddites

One big difference

[SmallFurryCreature]

Linus Torvald NEVER claimed to have created the best thing since sliced bread. He was modest and didn't shout from the roof tops that everything everyone else had been doing was wrong and that this was the next big thing.

Modesty goes a long way into getting people to listen to your ideas because you give them room to adjust their own views without having to get defensive.

Uh... huh

[sentientbrendan]

Here's what it is:
1. A VM based system, doesn't actually execute native code.
2. Has only one address space for some bizarre reason.
3. Persists everything in ram to disk...

So... your programs will run super slow because every memory write is written to disk, it you can't really run it on 32 bit hardware, and it doesn't run programs written in any existing programming languages.

So what is actually good about this operating system? Oh, it's super object oriented *rolls eyes*. As if that were a goal in and of itself.

This looks like another solution in search of a problem. Someone thought "wouldn't it be cool if" but didn't think about why anyone would care.

Re:Uh... huh

[amn108]

What do you care whether your app shares address space with every other one, or whether its address space is 'virtualized' (the way it mostly is these days)? It is not like you engage in pointer arithmetics is it? So whether your pointers are all sequential (and mapped to scattered real pointers) or are spread all over the RAM, means nothing to you as a programmer, unless you have a good reason to expect certain pointer 'demographics'.

Been there, seen that.

[Eunuchswear]

Multics.

Sounds like LINQ for file systems

[Anonymous Coward]

Sounds like what LINQ has done for databases, where the db query is just the business of deserializing objects from persistent storage.

Its not a silver bullet but it could have its uses.

A bit frightening...

[MerlinTheWizard]

In soviet OS, everything is a persistant object.

Kidding aside, I see several major issues with this concept: the increased risk of losing valuable data, the slowness, the very low interoperability (how do you exchange data with other OS's?), the whole span of programming languages that are not supported (I don't want to be coerced into using Java or C#, what's that about?)

Another issue is that I think the "object oriented" paradigms that are in use today are flawed in some aspects, and instead of basing everything computing-related on that, maybe we need to work on the concepts first.

Some more info on the Phantom

[dzavalishin]

Guys, thanx for an interesting comments. I wrote some short doc about Phantom's ideas, here: http://dz.ru/en/documents/dz_phantom_whitepaper_06Feb2009_00.doc Still a brief sketch, but it can narrow the discussion a bit. :)

Re:Some more info on the Phantom

[amn108]

Dmitry,

How much effort (man-hours) has already been put into your project? It appears your whitepaper is hastily drafted, and so my conclusion is everything is pretty much in R&D stage, is it not?

Other then that, thanks for the read, if anything, it was informational. Good luck with the system, but I am sure you are undertaking a far bigger task on yourself than you think you are at present point. Linux is a much simpler (dinosaur, like you put it yourself) and straighter (compiled C code, no magic tricks, just platform and hardware reference programming -old school made for performance) system and you can see for yourself how many years it took for it to get even close to being broadly usable.

I would write a good deal more on the issues of your OS, but let us just wait and see how it all develops. Things have a tendency to change.

Re:Some more info on the Phantom

[dzavalishin]

I can't estimate an effort (it was spread for a very long time in a small parts), but you are right that the system is in a quite early state.

Being a software company owner I have some perception of the amount of work we have to put into the project.

It is really depends on the maturity of the result to be reached, and numbers differ by the order of magnitude. Cost of producing a 'play and try' distribution is affordable, and to produce some real product 10x money will be needed and it is not a budget I can afford.

I know.

But: the only sure way to fail is stop doing.

Newton was even better...

[Anonymous Coward]

Not only did the Newton have persistent objects, but it merged in objects on external cards automatically. Unlike PalmOS, which treated removable memory in an extremely stupid way.

Security based on lack of pointers

[Douglas Goodall]

The description of the OS says that separate memory regions are not necessary because integers cannot be converted into pointers, and if you don't have a pointer, you cannot access memory. This sounds nice enough to start with, but it is actually quite insufficient.

In the Intel world, we had read only code segments. But there were alias selectors used by the OS to load code into read only code segments. I suspect there will be a way eventually to get a rogue pointer when a user program pretends to be a system routine, then it is over. All it takes is one vulnerability and the entire system architecture is compromised.

Also the lack of C is troubling. Java and C# are not enough for me. Maybe this is a good OS for after I am dead.

this is different than a expanded java vm how?

[Anonymous Coward]

it would seem that they have a jvm-like interpreter(bootstrap) with a "OS" object that they serialize to disk at shutdown and de-serialize on startup. no biggie. it's the interpreter that sets permissions and the like, the "OS" is neutered. who needs files when an entire "OS" has containers like arraylists as filesystems and filenames as indexes? they write one HUGE file to disk and load up one HUGE file on startup. if they wrote the interpreter correctly, it performs a neutered IO. this is android that is serialized to disk instead of loading a fresh copy. personally, i love the idea of loading up a fresh OS. clears out whatever errors were formed instead of having them persist like cancer. it can't run c because that would defeat the purpose of objects instantiating objects. it's like trying to compile and run c inside of a java VM.

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.

Re:BeOS

[Khyber]

Did they overcome the RAM issue in BeOS? IIRC BeOS5 (last I tried and I think last version out) didn't see over 1GB of RAM.

ok, here's the arcane mysteries

[Anonymous Coward]

http://en.wikipedia.org/wiki/IBM_System_i#Summary/ "While in Unix-like systems everything is a file, on the System i everything is an object, with built-in persistence and garbage collection." In the 1980's, the IBM System i machines were known as AS/400 machines.

So, being a clone of OS/400, is Phantom OS conceptually a dinosaur?

Of course, unlike Phantom OS, OS/400 does support pretty much every programming language http://en.wikipedia.org/wiki/IBM_System_i#Programming including C.

"in 1993, when IBM looked likely to be split up, Bill Gates commented that the only part of IBM that Microsoft would be interested in was the AS/400 division. (At the time, many of Microsoft's internal systems ran on the AS/400 platform."

This reminds of the Newton OS

[Anonymous Coward]

Hey! I've seen some comments about Alan Cooper's book (which I have not read), about SmallTalk and other stuff.

But I haven't seen any comparison between this Phantom OS idea and the Newton OS.

From TFA, I understand that the notion of files -- from the developer point of view -- would be replaced by the notion of a pool of objects which would represent documents, network connections, peripheral devices and other data.

This seems like the Newton "soup" on steroids, which looks like a good idea for me. No matter what the application is going to read or write, it would be invoking methods in an object that implements a standardized interface. A text document would be accessed in the same way as a network connection, a barcode reader or a printer.

I spent about 15 years on a similar concept...

[flnca]

... and it's still not finished.

My concept goes far beyond Phantom, however. But it's vaporware too ... until it's feature-complete and fully implemented, that is. ;-)

Re:I spent about 15 years on a similar concept...

[amn108]

Do you have anything published? I am doing some heavy research into something perhaps similiar, and unless you are keeping a lid on it, I would be glad to exchange ideas. I am not expecting any practical implementations, even communicated theory would be nice. Take a look at www.tunes.org by the way, those guys are onto something too.

Russians will do better

[Baldrson]

The mathematics of objects are poorly formalized. The mathematics of relations, on the other hand, are inherent in the very idea of formal language, subsuming functional as well as object oriented programming. Object orientation is being brought into philosophical question by advances in Structural Realism. I suspect something like Informational Realism will be a more appropriate approach for a mathematically strong culture like Russia to use for setting up an OS for the 21st century.

Agreed. Phantom is a toasteroven all we hear well.

[Anonymous Coward]

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.

If there ever was such an OS as Phantom, I would prefer that it didn't have programs in the standard sense but the OS is in-fact a virtual optimizing compiler that would reverse-engineer perl scripted-programs into the more easily readable morphological kind of optimized native assembly-language that throttles itself and unsharable to peers; this preserves the wildly sought Digital Rights Management quality without the remote exploits and constant surveilance of an interested or undisclosed 3rd party from interrupting the transparent grant of licenture. What I would love for such a non-POSIX non-Unix-licked operating system to implement a Jack Thompson protocol to combine all streams similar to Unix boxen's "char" and "block" and "FIFO" devices as just a series of visualized pseudocode "tubes" on the desktop to access through an API model system of object classes that a program can interface onto similar to IBM's data visualization and interpretation programs I've known for so long...

What have. I. don...

I remember my earliest thoughts of a file of '90's

[Anonymous Coward]

It was a dark and stormy night while I wrote a journal.
After so many revisions directly etched onto my medium of record, I learned that the pages grew while the meaning and capacity decreased.
In the end, all I had to say was what everyone else did on such a dark and stormy night.
I didn't need to try to write about my interpretation of those dark and stormy events as though I thought I were more special than anyone else in such quarterly or yearly predicaments as this dark and stormy night.
So I decided not to journal the Phantom of my mind in this, and regard the saviour of my writing implement, with wit, and capacity to do for other days to reflect on a journal for a special event to the expanse of man-kind in a science of my collective.
I started anew, disregarded the old journal, and penned forever more:

"It was a dark and stormy night like all others but unique to itself; went to bed until the day waft it away and anew."

But what ist mein!  What hast I wrot in this Slashdot to pfosten mannen all this journal when all I needed was to write as above!  The Phantom hath menaced me, oh tree of knowledge of Good and Evil: nay, cast my soul into the wayfarer of fragmentation o' God of my salvation to beseech mein only to reprove the ill of others to consult such a dead tree in those protocol of folly I hath wrought!  Give me plenty of 'pussy on me way out though :-) thanks. -Kohan

Perfecto OS for Phantom of the Paradise?

[Anonymous Coward]

http://www.youtube.com/watch?v=nw8NcUKTZXY

Oh wow...

[Noxn]

I must admit i didn't understand EVERYTHING...
But i understood enough to say that you have a good point.

BUT, as long (like you said) we don't have anything better, i will stick to Linux.

Also, many Linux users (Damnit, i mean GNU/linux) are happy with it.

But yeah, its aaaalll the same...
But nobody can give you a guarantee that phanton will work great. MAYBE they screw it (or maybe not).

PS:(that-kind-of-advanced-stuff-that-you-said)Pro VS (that-kind-of-advanced-stuff-that-you-said)newbie (-me)

In Soviet Union...

[Anonymous Coward]

In Soviet Union, the system operates YOU.

Slashdot, the cat does not have my tongue. Moron.

[Anonymous Coward]

I am a programmer... the summary makes me collapse in tears of amusement. This wins:

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

Persisted WHERE? In memory. Possibly in virtual memory, which is likely if this Phantom OS keeps everything in memory (if there are no files, that's the only other place to store information). So, once you put something in virtual memory, guess what? It's a file, buried in a file. Why not call the whole thing off and just leave files as files, because you can't get away from disk storage by filling up memory? Some really newbie devs here or what? :P