Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Phantom OS: Persistent Operating System

github.com

Post reply on HN
Print view View original

51–60 of 69 posts

Re: Phantom OS: Persistent Operating System

#51

Post by theamk »

encryptluks2 wrote: post #23
kstenerud wrote: post #8

This kind of system will suffer from the ratchet problem. A single bug that negatively impacts state is no longer fixable by rebooting. Instead, you have to format/reinstall. Unintended state becomes permanent, and upgrade paths constrained to the point where you must do intentional damage. I'd also be leery of fragmentation. The project is falling into the "simplification trap", where all it's doing is moving inhere…

Isn't that what snapshots are for? If rebooting breaks then rollback to a previous snapshot of the kernel or core components but keep all the users data intact.

In traditional OS, where data is separate from code, yes.

The whole point of Phantom OS though is that there is no separation between them. Instead of having files, you just keep the data in your program's memory, and rely on automatic system-wide persistence to keep it safe. So the only thing you can roll back is entire system.

Re: Phantom OS: Persistent Operating System

#52

Post by elteto »

garaetjjte wrote: post #44
elteto wrote: post #43

Not related to Phantom OS, but the OS running the Apollo 11 guidance computers had this same feature. In fact, the famous 1202 program alarms right before landing are related: a low priority task was overwhelming the system and the OS restarted to get a clean slate, continuing the high priority tasks where they left off: “The software rebooted and reinitialized the computer, and then restarted selected programs at a…

Did it? It seems more like that guidance application was saving checkpoint data, rather than OS feature. Though distinction between OS and applications might be muddy here. In fact persistent OS design would be catastrophic, as restoring all jobs would just cause resource exhaustion again. (more details on Apollo 11 problem: https://www.doneyles.com/LM/Tales.html )

Well, that's what happened: "On Apollo 11, each time a 1201 or 1202 alarm appeared, the computer rebooted, restarted the important stuff, like steering the descent engine and running the DSKY to let the crew know what was going on, but did not restart all the erroneously-scheduled rendezvous radar jobs."

Resource exhaustion was not immediate after reboot because the faulted tasks were low priority and did not get started after reboot right away. I can't even imagine what would have happened if one of the high priority tasks had been the problematic one.

Re: Phantom OS: Persistent Operating System

#53

Post by emteycz »

theamk wrote: post #51
encryptluks2 wrote: post #23

Earlier quoted context omitted.

Isn't that what snapshots are for? If rebooting breaks then rollback to a previous snapshot of the kernel or core components but keep all the users data intact.

In traditional OS, where data is separate from code, yes. The whole point of Phantom OS though is that there is no separation between them. Instead of having files, you just keep the data in your program's memory, and rely on automatic system-wide persistence to keep it safe. So the only thing you can roll back is entire system.

The system could offer functionality to make restore-points of specific program memory spaces. Programs could use API to trigger restore-point creation.

Re: Phantom OS: Persistent Operating System

#54

Post by garaetjjte »

elteto wrote: post #52
garaetjjte wrote: post #44

Earlier quoted context omitted.

Did it? It seems more like that guidance application was saving checkpoint data, rather than OS feature. Though distinction between OS and applications might be muddy here. In fact persistent OS design would be catastrophic, as restoring all jobs would just cause resource exhaustion again. (more details on Apollo 11 problem: https://www.doneyles.com/LM/Tales.html )

Well, that's what happened: "On Apollo 11, each time a 1201 or 1202 alarm appeared, the computer rebooted, restarted the important stuff, like steering the descent engine and running the DSKY to let the crew know what was going on, but did not restart all the erroneously-scheduled rendezvous radar jobs." Resource exhaustion was not immediate after reboot because the faulted tasks were low priority and did not get sta…

>but did not restart all the erroneously-scheduled rendezvous radar jobs

That's wrong. Excess CPU time was stolen by radar counter hardware, not by any software (counters worked by stopping CPU and using its ALU). Problem arised because main guidance routine (SERVICER job) was scheduled always every 2 seconds (by READACCS task/interrupt), and with excess stolen time it didn't finish in time, leading to scheduling of another SERVICER before previous instance finished. This repeated until memory ran out for stacking another SERVICER job. There was no "erroneously-scheduled rendezvous radar jobs", job that needed shedding was multiple stacked instances of SERVICER itself.

Re: Phantom OS: Persistent Operating System

#55

Post by monocasa »

orbifold wrote: post #33
sebastianconcpt wrote: post #32

Earlier quoted context omitted.

Well said, first thing I've though when I saw this project was: sounds like cache-invalidation hell. Now a second and genuine follow up and wildly generalized question: What if, given that information isn't lost (no-hiding theorem), death in the biological platforms is a reset for consciousness to continue its evolution after a renewal of any state pollution?

These conservation laws apply to open systems (which biological platforms are). All ready at the cell level the primary concern is how to "efficiently" do energy cascades which sometimes have unintended (irreversible) side-effects. So cells get "garbage collected", there are other more system level irreversible changes, some intended (memory) and unintended, which I guess are indeed ultimately unsalvageable, which is…

Even in the case of reproduction, you don't end up with a pristine copy in a new cell.

The study of epigenetics is the realization that cells don't have exec(), only fork(). Most state transfers to the child cells and isn't wiped during reproduction.

Re: Phantom OS: Persistent Operating System

#56

Post by resters »

kstenerud wrote: post #8

This kind of system will suffer from the ratchet problem. A single bug that negatively impacts state is no longer fixable by rebooting. Instead, you have to format/reinstall. Unintended state becomes permanent, and upgrade paths constrained to the point where you must do intentional damage. I'd also be leery of fragmentation. The project is falling into the "simplification trap", where all it's doing is moving inhere…

I think the idealism lies in the ability to reset/reboot. How much system behavior is undefined? From a security perspective, it's nearly impossible to tell exactly what malware did when so much data is ephemeral.

Re: Phantom OS: Persistent Operating System

#57

Post by webmaven »

strlen wrote: post #47

Question, how does this compare/contrast to “image based persistence” as used by e.g., most Smalltalk and certain Lisp based VMs?

It is equivalent, as are the pre-XML MS Office file formats which were essentially dumps of the document in memory.

Re: Phantom OS: Persistent Operating System

#59

Post by daitangio »

kstenerud wrote: post #8

This kind of system will suffer from the ratchet problem. A single bug that negatively impacts state is no longer fixable by rebooting. Instead, you have to format/reinstall. Unintended state becomes permanent, and upgrade paths constrained to the point where you must do intentional damage. I'd also be leery of fragmentation. The project is falling into the "simplification trap", where all it's doing is moving inhere…

Yes, I have a similar feeling in SmallTalk (i.e. Squeak or Cincom) A corrupted image is difficult to fix, and you end up saving the code on a "parcel"/package and reload it on a clean image.

Static image is indeed a nice feature I like.

Post reply on HN