6 ms·

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 for

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 inherent complexity around (which eventually requires users to do a bunch of work-arounds) rather than eliminating it (because inherent complexity can't be eliminated; only needless complications can be eliminated). In theory, this sort of setup would be nice in a perfect world, but in the real world of buggy software and faulty hardware and cosmic rays and failing network connections, it's a disaster waiting to happen.

stormking 5y ago
Rebooting does not fix any bugs, it just resets the state. I'm not sure this is really the better solution because many bugs never get fixed because "Have you tried turning it off and on, again?"
- kstenerud 5y ago
  It is the better solution because it delineates the difference between important data that must be preserved, and not important data that can be thrown out and regenerated (turning it off and on again). Systems that eliminate this difference massively increase the damage surface of your data by forcing both kinds to be treated equally and even intermix. And since software will always have bugs, your fallout damage increases exponentially. It's a lot like naive state saving code that just dumps an in-memory struct to disk: The moment that struct changes (adding/removing/changing a type or size), your load code breaks.
- thatjoeoverthr 5y ago
  Resetting the state is a necessary step when the state is corrupted. You can’t work around this with “don’t corrupt the state”. So many developers are running the other way: isolate state; reduce dependence on state; eliminate side effects; crash only software; etc. The state doesn’t need to be preserved because it simply isn’t that valuable.
- theamk 5y ago
  Rebooting (or "restarting the process" in a more limited case) does not fix the bugs, but is as a very effective workaround in a lot of cases. Yes, a lot of bugs are never going to be fixed, and we'll have to restart the machine occasionally... but Phantom's alternative is forcing machine reformat on any bug. You can do this today: just add a crash handler that will erase your entire hard disk. Do you think this will make software less buggy?
joshuajomiller 5y ago
Couldn't there be a middle ground that allows you to restart/reset a single application?
- kstenerud 5y ago
  That's likely already baked in, but then you end up with an infrequently run bootstrap code path, and "resetting" an app basically means nuking all of its data (some of which might be important to you). This is why we have a clear delineation between persistent and ephemeral state.
- fsflover 5y ago
  Sounds like Qubes OS with disposable VMs.
- PretzelPirate 5y ago
  The FAQ calls this out as a way to recover from a bad state. It seems to already be implemented in the OS.
  - theamk 5y ago
    But without explicit serialization/de-serialization code, restarting an app will lose all the related data. So if your text processor crashes, your documents go bye-bye.
checker659 5y ago
Snapshotting is another solution.
- kstenerud 5y ago
  But now since there's no boundary between persistent and ephemeral state, reverting to a snapshot will damage all of your other processes and lose data in unpredictable ways due to the halting problem. The cure could end up worse than the disease.
  - jonathanstrange 5y ago
    The distinction between persistent and ephemeral state may be too coarse-grained. In many applications like preference systems and object persistence more fine-grained distinctions are needed. As a typical example, miscellaneous data like window positions, sizes, and settings can and should be reset under certain conditions in desktop applications, but they still need to be persistent. There is a need for systems of default values & conditions that regulate when resets from corrupted states are allowed and when resets are executed for certain types of data (but not for others). I've never seen a framework or OS-support such fine-grained persistence and failure management. It's strange because almost every application needs something like this, and if it's just to reset a faulty preferences file. I've always thought that these kind of features should be provided by the OS, together with indexing and better guarantees for file integrity (e.g. ACID-compliant atomic file operations).
formerly_proven 5y ago
Similar issues when using object databases (not to be confused with document stores, though they have somewhat similar problems to a lesser degree)
encryptluks2 5y ago
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.
- rowanG077 5y ago
  Now find out when your problem was introduced. Your very, very lucky if that was 30 minutes ago. But there will also be hidden issues that can lie dormant for weeks or months. Good lucky using rollback for those.
- theamk 5y ago
  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.
  - emteycz 5y ago
    The system could offer functionality to make restore-points of specific program memory spaces. Programs could use API to trigger restore-point creation.
sebastianconcpt 5y ago
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?
- orbifold 5y ago
  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 why reproduction is a thing (pristine copy of genome in new cell).
  - monocasa 5y ago
    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.
ajuc 5y ago
You could base such system on software transactional memory and persistent data structures (like in Clojure) and in case of a bug just revert the state to any particular point in time by changing one pointer. Your app crashed? No problem - Rewind 5 minutes earlier and don't do the thing that crashed it. There's whole unexplored universe of possibilities when we do away with traditional OS design. I'm especially interested in how it would work with Intel Optane.
- garaetjjte 5y ago
  State can be silently corrupted and only cause problems much later, even many years later.
tomaskafka 5y ago
This is what happened to my iOS install. Due to some problem (is it an exploit hidden somewhere among incoming messages?) my Messages app opens for 5+ seconds every time, and there is absolutely nothing I can do, except setting up a whole new iPhone from scratch (and hoping the problematic message win't get synced from iCloud anyway). On rooted Android I could clear corrupted app data.
- gizmo686 5y ago
  Does Android even need to be rooted? The settings app on my stock Samsung has a clear data button for every app.
resters 5y ago
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.
daitangio 5y ago
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.
- igouy 5y ago
  Save code in a code archive. Create a working image from a clean image + code archive. Sanity prevails.

stormking 5y ago

Rebooting does not fix any bugs, it just resets the state. I'm not sure this is really the better solution because many bugs never get fixed because "Have you tried turning it off and on, again?"

kstenerud 5y ago
It is the better solution because it delineates the difference between important data that must be preserved, and not important data that can be thrown out and regenerated (turning it off and on again). Systems that eliminate this difference massively increase the damage surface of your data by forcing both kinds to be treated equally and even intermix. And since software will always have bugs, your fallout damage increases exponentially. It's a lot like naive state saving code that just dumps an in-memory struct to disk: The moment that struct changes (adding/removing/changing a type or size), your load code breaks.
thatjoeoverthr 5y ago
Resetting the state is a necessary step when the state is corrupted. You can’t work around this with “don’t corrupt the state”. So many developers are running the other way: isolate state; reduce dependence on state; eliminate side effects; crash only software; etc. The state doesn’t need to be preserved because it simply isn’t that valuable.
theamk 5y ago
Rebooting (or "restarting the process" in a more limited case) does not fix the bugs, but is as a very effective workaround in a lot of cases. Yes, a lot of bugs are never going to be fixed, and we'll have to restart the machine occasionally... but Phantom's alternative is forcing machine reformat on any bug. You can do this today: just add a crash handler that will erase your entire hard disk. Do you think this will make software less buggy?

joshuajomiller 5y ago

Couldn't there be a middle ground that allows you to restart/reset a single application?

kstenerud 5y ago
That's likely already baked in, but then you end up with an infrequently run bootstrap code path, and "resetting" an app basically means nuking all of its data (some of which might be important to you). This is why we have a clear delineation between persistent and ephemeral state.
fsflover 5y ago
Sounds like Qubes OS with disposable VMs.
PretzelPirate 5y ago
The FAQ calls this out as a way to recover from a bad state. It seems to already be implemented in the OS.
- theamk 5y ago
  But without explicit serialization/de-serialization code, restarting an app will lose all the related data. So if your text processor crashes, your documents go bye-bye.

checker659 5y ago

Snapshotting is another solution.

kstenerud 5y ago
But now since there's no boundary between persistent and ephemeral state, reverting to a snapshot will damage all of your other processes and lose data in unpredictable ways due to the halting problem. The cure could end up worse than the disease.
- jonathanstrange 5y ago
  The distinction between persistent and ephemeral state may be too coarse-grained. In many applications like preference systems and object persistence more fine-grained distinctions are needed. As a typical example, miscellaneous data like window positions, sizes, and settings can and should be reset under certain conditions in desktop applications, but they still need to be persistent. There is a need for systems of default values & conditions that regulate when resets from corrupted states are allowed and when resets are executed for certain types of data (but not for others). I've never seen a framework or OS-support such fine-grained persistence and failure management. It's strange because almost every application needs something like this, and if it's just to reset a faulty preferences file. I've always thought that these kind of features should be provided by the OS, together with indexing and better guarantees for file integrity (e.g. ACID-compliant atomic file operations).

formerly_proven 5y ago

Similar issues when using object databases (not to be confused with document stores, though they have somewhat similar problems to a lesser degree)

encryptluks2 5y ago

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.

rowanG077 5y ago
Now find out when your problem was introduced. Your very, very lucky if that was 30 minutes ago. But there will also be hidden issues that can lie dormant for weeks or months. Good lucky using rollback for those.
theamk 5y ago
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.
- emteycz 5y ago
  The system could offer functionality to make restore-points of specific program memory spaces. Programs could use API to trigger restore-point creation.

sebastianconcpt 5y ago

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?

orbifold 5y ago
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 why reproduction is a thing (pristine copy of genome in new cell).
- monocasa 5y ago
  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.

ajuc 5y ago

You could base such system on software transactional memory and persistent data structures (like in Clojure) and in case of a bug just revert the state to any particular point in time by changing one pointer. Your app crashed? No problem - Rewind 5 minutes earlier and don't do the thing that crashed it. There's whole unexplored universe of possibilities when we do away with traditional OS design. I'm especially interested in how it would work with Intel Optane.

garaetjjte 5y ago
State can be silently corrupted and only cause problems much later, even many years later.

tomaskafka 5y ago

This is what happened to my iOS install. Due to some problem (is it an exploit hidden somewhere among incoming messages?) my Messages app opens for 5+ seconds every time, and there is absolutely nothing I can do, except setting up a whole new iPhone from scratch (and hoping the problematic message win't get synced from iCloud anyway). On rooted Android I could clear corrupted app data.

gizmo686 5y ago
Does Android even need to be rooted? The settings app on my stock Samsung has a clear data button for every app.

resters 5y ago

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.

daitangio 5y ago

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.

igouy 5y ago
Save code in a code archive. Create a working image from a clean image + code archive. Sanity prevails.