Hacker News Reader

Comment by mabbo | Hacker News Reader

Without any intent to take away from how cool this is (seriously, it's awesome) I do wonder what kinds of applications need this sort of capability.

Surviving a reboot is a very specific capability. With no hyperbole intended, who needs it?

View on HN

Back in late '80's out of St Andrews and Glasgow, there was a bunch of research into persistent object environments. Here's a paper:

https://archive.cs.st-andrews.ac.uk/papers/download/MBC+88.p...

In short imagine Java or C++ objects, but they can live in a soup in a persistent database.

Imagine if your programming assignments at school, were "open this database then write a client to talk to the object retrieved." That's what we actually had in PS-Algol in 86. Super cool!

> In short imagine Java or C++ objects, but they can live in a soup in a persistent database.

AllegroCache still exists today. So at least Lisp people don't have to imagine that. I wonder if that is one of the reasons why CL people in the 1980s came up with UPDATE-INSTANCE-FOR-REDEFINED-CLASS.

Yeah, you could supposedly upgrade all the software on a lisp systems without having to restart anything (assuming the developers implemented the various redefinition protocols correctly.)

Ahh, how is StumpWM doing? The tiling window manager written in Common Lisp. You could hack it while it was running. I never got around to try. :(

You can definitely do that in an image-based Smalltalk system, it is necessary to support the code browsers. I imagine the lispm devs had the same reason.

What I had in mind was that this is also necessary to support an on-disk object database.

That can be trickier, but Gemstone/S did it transactionally.

Imagine the user experience of closing the lid on your laptop and reopening it a few hours or a few days later, without using any battery life in between.

You can also imagine it being useful in extremely low power solutions where battery life is critical. Space craft, etc

> Imagine the user experience of closing the lid on your laptop and reopening it a few hours or a few days later, without using any battery life in between.

MacBooks and probably other laptops (?) already do this. You might lose a couple percent over a few days.

Surprisingly, while my Intel-based MBP does that (and can remain sleeping unplugged for several months), my M1-based one doesn't (after a few weeks, there's barely any battery left).

Interesting. Maybe there is something in M1 that draws power anyway.

Funnily enough I have the opposite experience! My M1 can stay closed for weeks without losing more than a few percent, while my Intel-based tends to drain about 10%-20% a day.

Lenovo S3 sleep state already does this. I have been using this for like 5 years atlesst. systemctl hibernate

With what OS? My T14s running Windows 10 is unable to survive commanded sleep, much less just putting the lid down.

> systemctl hibernate

Linux most likely

I'm a bit confused. Thhe hibernate function has been available in Windows (and also Linux) for years. In Windows 10 you might need to enable it in Power Options in the Control Panel. I'm using it all the time. It's very useful for long travels for example.

Yep, and sometimes it even works. Now imagine hibernate not even being a feature to fiddle with. It just, is. Close the lid, 0 power draw, open the lid, instant resumption of where you were previously. No wake on sleep (and the quirks that come with it), etc.

Classic example of “but you can already do this by configuring X in this settings menu and then making sure to enable it before you leave and there’s just this other one trade off and yea it can be slow and clunky sometimes” vs a solution so native to the platform that it’s not even a thought in the user’s mind.

Aka the “Dropbox is just rsync” argument.

Fiddle with? Simply select what action closing the lid performs. It works every time. I have gone months without shutting down and just relying on this.

To be clear: hibernate works without any fiddling, but in Windows 10 this setting is not enabled default, you need to explicitly turn it on in the Central Panel, and then it works.

I don't know why Microsoft decided not to enable it by default. Maybe they thought the difference between sleep and hibernate is too much to grasp for common users. And sleep works a bit faster (although with modern NVME drivers I don't see as much difference as in the past when you had to write 8 or 16 GB of memory to HDD).

Running a tiny embeddable computer in a highly contingent environment. Off the top of my head I know someone running such computers to measure biodiversity through audio recordings. They fail all the time due to extreme weather and in one instance a bear pissing on it. I imagine the security could be useful in such an instance

As to who would need the OS state surviving reboot, what comes to my mind is things like Mars rovers and other autonomous exploratory vehicles. Currently these use cases are filled by VxWorks[0] among others but a fresh approach might yield some advantages.

[0] https://en.m.wikipedia.org/wiki/VxWorks#Aerospace_and_defens...

Anywhere in regular danger of power failure would certainly benefit from it.

battery or ups solves that

I would flip it around and ask "Who wouldn't need this?" Think of it this way, operating systems like Windows have tons of vulnerabilities, which need to be patched, and applying those patches takes a reboot. But people push off those reboots so long because they mean closing all applications and interrupting work, to the point where the entire computing ecosystem is more vulnerable and less updated as a result. Microsoft started scheduling updates in the middle of the night just to find a time that was amenable to users, but that doesn't help when the machine is turned off! So I think that feature, if it were deployed everywhere, would be a net win for everyone, not specific at all.

But if your application is just restored to its previous state, it is still using the buggy code that was patched on disk. If you page in new code from patched files, the program will not necessarily know that foo() now lives at a different address.

Save/restore across shutdowns is much simpler when the code doesn’t change. When the code changes, you need some form of live patching (ala ksplice) in the mix as well.

There are also concerns when the system interacts with external systems. Suppose the system state was saved just before the million dollar transfer was performed, the transfer was performed, then the cat tripped over the power cord without that being persisted. When the system starts back up, the app may make another million dollar transfer thinking it was the first one.

Sure, those are all complications, but I don't think it impacts the utility of the idea.

Windows happily applies updates during the night on laptops even when the lid is closed. Then the next day, you open the lid and bam, nothing of what you left open the previous day is there anymore!

I basically leave my MacBook on sleep all the time so that it is ready to pick up where I was.

With this I could do the same with a desktop computer without having to lose power.

macOS does something kinda like it. For when your battery dies you just have to boot the machine and all running apps will sort of start in their previous state.

That really depends on how well the app manages its own state and specifically handles restarts. No mainstream OS can restart without running apps even knowing it.

It’s possible with virtualization and containers. In those cases, to be fair, there applications are running in an environment that may not be aware it was restarted.

What if we're a simulation unknowingly getting a restart every time Johhny the alien closes and opens his laptop?

A planned restart is just hibernation to disk, which is implemented in many OS's.

If you got a Mac without a battery you can try to write something in pages and just yoink the power cable. Upon the next boot pages should open with your document and not lost anything.

Isn’t this exactly what hibernation is?

How is that any different from hibernation?

Memory isn’t snapshotted and dumped, then restored by the OS in a way that user space is largely unaware.

macOS/iOS has adopted a model of giving apps an opportunity to persist their own state before being terminated (which may be eagerly to reduce memory pressure or power consumption, for example) and then have the application restore its own state in whatever way is appropriate.

Outside of containers, hibernation almost needs to be a system-wide operation, which makes it inappropriate for OS updates, restoring from crashes (which, I suppose is what Phantom OS is trying to resolve), or hardware changes.

Note that "containers" is basically kernel-implemented namespaces, which is why a containerized app can be checkpointed and restored independently: they can preserve the semantics of kernel resources across runs. You could have just about any arbitrary app running in a "container" with it being none-the-wiser about it: it doesn't necessarily impact userspace support.

Because persistent storage is about as fast as ram. (Not yet but eventually)

Reply on news.ycombinator.com