Hacker News Reader

Comment by kstenerud | Hacker News Reader

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.

View on HN

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

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.

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.

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

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

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.

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?

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.

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

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.

The FAQ calls this out as a way to recover from a bad state. It seems to already be implemented in the OS.

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.

Sounds like Qubes OS with disposable VMs.

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.

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

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.

Save code in a code archive.

Create a working image from a clean image + code archive.

Sanity prevails.

Snapshotting is another solution.

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.

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

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.

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.

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.

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.

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

Reply on news.ycombinator.com