Live data from Hacker News

Phantom OS: Persistent Operating System

github.com

11–20 of 69 posts

Re: Phantom OS: Persistent Operating System

#11
I'm not sure this actually solves the real problem that people have. Sure, reboots are annoying and pretty much all current OSes could be improved in this regard. Back in the 90s, it's interesting that SunOS supported live kernel upgrades, so at the same time the kernel on disk was updated, the running system was also patched so it would act the same way as-if rebooted, but without any disruption to the live system.

However, in the current days where rebooting is seen as normal for an OS upgrade, but most of the time people just put their computer to sleep, the main problem is that all the network interfaces are effectively useless when the system wakes up because most connections will have long since timed out due to lack of connection acknowledgement packets. In such a case, systems will have to tear-down and re-create a lot of state anyway.

The actual issue this seems to solve, that of saving memory state and restoring again, is already solved for most use cases except OS upgrades by using sleep mode. But the hard case about network connections is still unsolved for this system, and by solving the problems it does solve with yet another VM-based environment it'll probably be doomed to obscurity unless common existing applications and virtual machines can easily be made to run on-top of it.

Re: Phantom OS: Persistent Operating System

#12

> Its primary goal is to provide environment for programs thatsurvive OS reboot. Such an environment greatly simplifies software development Simplifies? I can't even imagine such a program. To me a program is something that starts and ends and can also re-start with a fresh state in case something goes wrong.

What about some middle ground? I’d like my IDE to remain constant between reboots, my browser to some degree is already (if it crashes, it reopens all current tabs on start, which is effectively the same). I would have thought some clever hacks on an existing kernel would be reliable enough rather than an entirely new OS just for one feature, though.

That does sound great, but realistically any application needs to be able to recover from a crash anyway - so even with this support from the OS, you just have a new code path to support. Might be nice for users, but it certainly doesn’t simplify anything for developers.

Re: Phantom OS: Persistent Operating System

#13

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…

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.

Re: Phantom OS: Persistent Operating System

#14

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…

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.

Re: Phantom OS: Persistent Operating System

#15

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…

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

Re: Phantom OS: Persistent Operating System

#16

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…

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.

Re: Phantom OS: Persistent Operating System

#17
I wonder how much wear on the system disk is caused unnecessarily by taking continuous snapshots.

I think that you would like to limit the actual data to persist to the data that needs to be be persisted — that which can't be recreated quickly, purely from other objects.

Re: Phantom OS: Persistent Operating System

#19

I'm not sure this actually solves the real problem that people have. Sure, reboots are annoying and pretty much all current OSes could be improved in this regard. Back in the 90s, it's interesting that SunOS supported live kernel upgrades, so at the same time the kernel on disk was updated, the running system was also patched so it would act the same way as-if rebooted, but without any disruption to the live system.…

> all the network interfaces are effectively useless when the system wakes up

This is - and probably always will be a problem with networked software. You should program as if TCP connections could drop at any time, for any reason. Browser tabs get backgrounded. Laptops go to sleep. Cell phones roam, and go into tunnels. Servers have temporary net splits.

Most high level tasks can be retried safely. Nonces and things can be used to safely retry almost anything else.

I miss the simplicity of IRC, the way slack and discord smoothly transition between online and offline states is graceful and intuitive. That is how almost all software should behave.

Re: Phantom OS: Persistent Operating System

#20
Ooh interesting, probably unrelated but I was thinking a GAI would use one of these at its core eg. "it can't die". For the self/state aspect.

Also a criteria is code that modify itself without recompiling.

This also considers a power source like a nuclear battery or something that will last a long time or alternate in the low power state/ambient or whatever energy.

Post reply on HN