
Phantom – forward-thinking concept of OS that's not Linux-derived - shalabhc
http://phantomos.org/
======
theamk
This is very interesting, but I have a lot of questions about how "keeping
documents as in-memory object" works in practice -- because files gives us
lots of features we depend on, without even realizing it.

\- Upgrade software: right now, my "txt" files are independent from
"/usr/bin/emacs". I can upgrade emacs to the later version, and use it to re-
open the same documents. This does not seem possible if by file is "text
window + object pointer + editor code".

\- Move/copy files between machines -- I can copy most of the files, but not
objects. I can also save older versions, send them by email or messengers, and
so on.

\- Recover from bad software -- the other day, my computer decided it wants to
have a full-screen uncloseable window. A reboot fixed this right up. Good
thing it was not persistent.

\- Recover from crashes. What do you do if you write a presentation, and a
programming error causes program to stop responding if you ever draw a green
circle of certain size? In regular OS, you restart your software, load the
latest savefile, and avoid green circles in the future. In PhantomOS, looks
like you will be screwed.

The only thing that Phantom seems to offer is snapshots, but they are pretty
extreme (the whole system is reverted), and even then, it only helps with some
classes of bugs, the ones which are obvious enough that you notice them right
away.

~~~
dzavalishin
Actually things in Phantom are not SO different from usual world.

\- You can install new version of class code. Of course, app code have to do
migration by hand, but that's the case in nowadays world - if you change data
file format, you have to convert.

\- There's no problem to migrate object tree over the net. Even storing it to
a file is not a problem.

\- Persistence does not _forbid_ to restart things.

It just does not restart 'em on reboot. Eggs in your fridge are (more or less)
persistent :), but you still can throw 'em away and put in fresh ones.

We're living in a persistent world and do not suffer too much from it, right?
Non-persistence of software world is just innatural.

We're very used to it, and that's all.

~~~
theamk
Thanks for the answers, I am glad to hear from the author!

\- What do you mean "app code have to do migration by hand"? I'd say that most
of the existing file formats need no migration -- images, videos, music
basically don't change; and even very complex file formats like Microsoft doc
only change with major versions, not with the minor ones -- MS word had tens
of thousands code updates (service packs, localization, etc..) but only a
dozen or so file formats.

\- What do you mean by "restart" in "Persistence does not _forbid_ to restart
things."?

if by "restart", you mean "kill all the threads related to object", then I
don't think it will help in most cases. If you have a bug in "Draw()"
function, this bug will still be there after thread restart.

If by "restart", you mean "wipe all the state, and start from the clean
slate", then won't this destroy all the documents user made?

\---

We live in persistent world, and we do suffer a lot from it, we are just very
used to it. I have to wash my dishes every day, buy new clothes, and repair my
car. I would love to be able to "save" the make, model, and license plate # of
my car, then "restart" it to get a brand-new car with the same properties.

Default persistence of everything is annoying, and moving it to software is
just unnatural :)

~~~
dzavalishin
Well, you just can't imagine non-persistent world. :) I'll try to illustrate.

In non-persistent world you have to disassemble and store to special boxes all
the objects in a room before getting out of that room. Or else it all will
just vanish. :)

On migration: if you change code in Phantom in a way that does not change
object representation, you can just use new code with old data. New
paintDocumentPart() can be called for same document object as long as
interface is the same.

The problem is with objects with running threads in them. You can't change
implementation which is currently running.

Hopefully, it would not be a usual case. As far as I see, Phantom applications
won't need forever running threads at all.

os ->(repaint)->window->(get state of)->document

or

doc->(update state trigger)->window->(repaint)->canvas

In either case it's just an event. Update and finish.

Actually, Phantom was a huge mind game of mine for years (first ideas started
to form some 25 years ago) and one of the reasons to start actual
implementation was that I can't imagine all of the potential problems and
solutions for such an environment.

But - I don't want Phantom to be just a test bed for new ideas. I hope it will
find its place as practical tool.

~~~
theamk
I can certainly imagine a non-persistent world -- why do you keep saying that
I cannot? It is called "restaurant". You come in and get a clean, fresh table.
You sit on it and eat, and if you have leftovers, you put them in special
boxes. When you leave, everything on the table that you did not put in a box
disappears. Very nice and handy!

=====

So what happens in case of errors?

os ->(repaint)->window->(get state of)->document->(EXCEPTION: LIST INDEX OUT
OF RANGE)

Does this result in losing the document forever?

~~~
dzavalishin
Word->Open file->Error reading file: LIST INDEX OUT OF RANGE

Does this?

Your point is obvious, but not specific to persistent environment. Things are
getting broken sometimes.

Actually, back in 2009 when first message about Phantom appeared, I've got a
message from team in Stanford. THey did an experiment about things we discuss.

Relatively big Java program was stopped in the middle of work, serialized to
(I believe) XML and some objects were removed from that XML. After that
program state was de-serialized and program continued to run.

Experiments shown that modern code degrades quite gracefully in such cases.
Most of time problems were not global and affected just parts of program's
abilities.

But again, it is not a persistent world specific problem.

If your code is wrong, no matter where index lies - in persistent memory
object or in file. Index will be wrong.

The question is how system must be built, what kinds of services it must
provide to limit app ability to shoot itself in a foot. That is one of the
goals of this project.

~~~
theamk
In Word (especially when save-in-place disabled), old file disappears only
when the new file is complete. And since file writing naturally walks over all
the structures, any exceptions usually happen during _save_ and _display_
time. If the file ended up on disk, it is usually OK.

And even if you are unlucky, you can still restore it from your backup (time
machine, dropbox folder, restore point, etc..)

If you have explicit "save" action, all of those things happen automatically
-- there is no need for programmer to do any sort of action here, other than
to make sure saves are atomic.

Only persistent environments have this problem, because once your persistent-
word crashes, you cannot do anything to roll back the change -- other than
revert entire OS to previous snapshot, but this will roll back all other apps,
too.

(Practically, I've had MS Word crash on me hundreds of times. I've only got
corrupted save file once or twice. So at least from my anecdotal evidence
switching to "persistent world" would make data loss much more frequent.)

------
MisterTea
I immediatly started singing the Spam song in my head but replaced Spam with
State. Lovely State! Wonderful State!

I actually prefer the old days: turn the thing off and walk away. Screw state.

~~~
mavdi
State is the root of all evil.

------
lioeters
The source:
[https://github.com/dzavalishin/phantomuserland](https://github.com/dzavalishin/phantomuserland)

Previous discussion (6 months ago):
[https://news.ycombinator.com/item?id=19672610](https://news.ycombinator.com/item?id=19672610)

------
dzavalishin
Hi everybody. As the author of original Phantom OS idea I'd like to thank you
for the discussion.

I am here to answer any question, please ask.

If you have some collaboration or experiment with Phantom in mind, I'll be
happy to discuss. I'm looking for practical but simple use case for Phantom
OS.

~~~
dzavalishin
Being on the vacations I decided to write some Phantom OS internals book, and
if you're interested, here it is:

[https://phantomdox.readthedocs.io/en/latest/](https://phantomdox.readthedocs.io/en/latest/)

------
qwerty456127
> Your program will survive OS reboot. All variables are now.. like files?

Sounds like we will have to format the hard drive and re-install everything
every week or even more often.

~~~
m463
It might just be that programs will have to be written slightly differently.

Sort of how drivers that have to deal with sleep/wake have to be tweaked.

Whem machines got sleep/wake it was a definite step forward for usability (and
other things like machine efficiency)

------
pjmlp
Some ideas seem similar to Taos:

[https://news.ycombinator.com/item?id=9806607](https://news.ycombinator.com/item?id=9806607)

------
droobles
A nitpick, in your FAQ's it should be "in the 1960's" not "the 1960th" if I'm
reading the year correctly.

~~~
alttag
A nitpick: don't use the apostrophe in the phrase "in the 1960s". It's not a
possessive in that sentence.

See, e.g.,
[https://www.thepunctuationguide.com/apostrophe.html](https://www.thepunctuationguide.com/apostrophe.html)

~~~
seawlf
This is not a hard-and-fast rule. There's hardly agreement in style guides on
this note. Don't be a jerk and nitpick style on the internet; it does not add
to the conversation. [https://english.stackexchange.com/questions/13631/is-an-
apos...](https://english.stackexchange.com/questions/13631/is-an-apostrophe-
with-a-decade-e-g-1920-s-generally-considered-incorrect)

------
ocdtrekkie
Probably the thing that concerns me the most here: If it is as described...
turning it off and then back on again probably won't fix whatever it's doing
wrong. :/

I'm very curious what troubleshooting a system like this would look like.

~~~
dzavalishin
Yes. But, really, turning off and on fixes not quite everything. I've seen
Word files that can't be open and crash Word completely.

Application state can be unrecoverably wrong with any kind of storage, be it
files or persistent object tree.

~~~
theamk
But only files offer fully automated backups which do not need any sort of
support from application at all.

------
Angeo34
>that's not Linux derived I get that it's supposed to be a strength but it
will also be the reason it will be absolutely useless. Even BSDs implemented
the Linux glue because everything is made for Linux.

~~~
farisjarrah
Even if this is absolutely useless, there is an intrinsic value to the author
to create this, to learn, and an extrinsic value to this: It may inspire some
linux or BSD kernel dev to fix a long standing bug or add increased
functionality.

~~~
Koshkin
So... you are saying that it is not absolutely useless even if it is
absolutely useless.

~~~
klyrs
No. It's not absolutely useless, even if it is _practically_ useless.

Do professional musicians play scales? Yes. Even if nobody would pay to hear
it

------
gumby
I'm intrigued by the comments suggesting that rebooting a machine is a good
way to fix problems. I certainly know that it can work but really it's a
regrettable last resort to solve a problem.

It would be good to have an OS that brings back the idea of persistent state.
Plenty of programs have to run without stopping so require thinking of long
term behavior (power plants, various spacecraft, medical implants, etc).
People without stopping and in fact halting them is greatly discouraged.

~~~
theamk
Especially those highly critical apps absolutely depend on the the ability to
recover via reboot at any moment. There could be random hardware glitches, or
software crashes -- and the fix is to discard the RAM, very carefully verify
the stored persistent data, and re-create the state from it.

Famously, during the moon landing, the computer had an error and crashed,
multiple times [1]. The landing was still a success because while the
navigation state was explicitly saved, everything other state was reset. Good
thing the designers did not use persistent memory!

[1] [https://www.wired.com/story/apollo-11-mission-out-of-
control...](https://www.wired.com/story/apollo-11-mission-out-of-control/)

~~~
dzavalishin
Religions are very different around the world. Though my gods do not forbid
anybody to 'very carefully verify the stored persistent data, and re-create
the state from it' even if persistent data is stored in... persistent memory.

Well, just kidding, I'm agnostic, there's no such thing as my gods. ;)

Key point is code that 'very carefully verifies'. Forced RAM nullification on
reboot does not help per se.

And there's no need to reboot in any case. If you feel you're busted, in
persistent env you still can clear all state and recreate it from some other
state.

It's just very traditional to think of files, not RAM as storage.

Memory mapped files, btw, are quarter a step to Phantom.

~~~
gumby
Back in the days of core memory I remember restarting a machine after the
power had gone out. No need to reboot (unless power had gone out while the
monitory ("kernel") was running) -- only the running process, with its
semiconductor registers, would die. Everything else was persistent.

The original Multics design did not make a distinction between memory pages on
disk and in RAM. Files were just a way to describe a collection of memory
pages, wherever they might be.

------
0xdead
A "forward-thinking" project shouldn't have been written in C. They should've
used Rust.

~~~
dzavalishin
You're quite right, Rust would be better tool. But first Phantom code was
written some 15 years ago and now it's too late to switch. :)

