So… I know Windows people call it “hibernation” but what if Haiku didn’t need a sleep mode? Tbh, sleep on Linux, even today, isn’t always the smoothest thing like where a network connection won’t resume right. So idc if Haiku has sleep mode or not but it would be cool if Haiku had a way to resume stuff.
That said, instead of my wilder ideas (like the recent BeIA mockups) I thought I’d propose a simpler one The first idea would be tiny: a simple “Nap” link… which literally would take nothing to code; in the distro I failed at a few years ago, I’d added a link to a script, which in turn ran the Blank/Blackness screen saver and that was ‘Nap’. It wasn’t (and wouldn’t) be a true sleep mode of course, but it’d at least allow the screen to blank while away.
Hypersleep
But the real idea here is this: hypersleep It would basically be shutting down like normal, but the difference would be that (maybe just to start with) applications are remembered just like recent apps are, so when the system enters hypersleep, it’ll try to auto-quit everything running and then bring everything back up on the next restart. This would be useful if the battery ran out and Haiku needed to power down (or someone needed to shut their computer off).
Of course, in the future (maybe like in R2) what’d be way cooler is if Haiku could have persistence for real and freeze application states:
And I’d imagine if these were added in R1, R2, or whatever that the menu would probably look like this:
And anyways, those are my ideas for energy features; hope you guys like the mockups
Hypersleep should prolly be under Shutdown too, since it also involves actually shutting down the computer.
As for Nap, perhaps this could be implemented when multi-user is exposed in the UI. It would lock the system and turn off the display; when the computer is woken up from Napping, a lock screen appears asking for a password. While this could be done without multi-user being exposed in the UI by implementing it as just a lock password, IMO it would be better served using the user’s actual password.
“Nap” is already there through using the hot corners options in Screensaver preferences. Just move your mouse to a corner of the screen to lock things. You can have a password on wakeup too (again, despite what UNIX wants you to think, multiuser and security are not this strongly related).
“Hypersleep” is… also already implemented. Have you noticed how Tracker remembers and restores tis windows? We’re now waiting for other apps to also implement this.
Yes, but I think it’s a bad idea. What they do is write the whole RAM to disk. This needs a huge swap partition (in Linux) or a huge file on disk (hiberfil.sys on Windows) especially today with huge RAM sizes. I don’t think that this is a wise use of disk space.
For example my Haiku install is on a 2GB partition. I would have to make it 10GB just to have space for storing my 8GB of RAM. And imagine someone who has 32GB of RAM. Why do this when all you need is save a few files which would take kilobytes or maybe at worst megabytes of space?
Having it done per-application opens a few other interesting options. For example you could store your application snapshot on an USB disk and load it into another Haiku system. You could send a whole application to a colleague or friend over the network. You could have multiple sessions with all their running apps stored, and load and save them as you switch between different tasks and projects.
It is also a lot easier. The way Linux/Windows does it is a bit tricky because you have to restore everything exactly as it was, with the same memory mapped in the same place. This means it has impact on drivers (everything that does DMA) so we can be sure to reallocate physical memory with exactly the same layout, and so on. All of this to just get the suspend-to-disk working, with none of the other cool features that would be possible by doing it at the application level.
Would it be possible to make it the default when creating apps? I imagine that there will be app devs who aren’t aware of this feature. If it is possible, then giving the option to opt-out instead of opt-in may be better as more applications are likely to support it.
On another note, are there any programs besides Tracker that do have the functionality?
Note that windows already does something like this. When you shut down it is not doing a full shutdown, for that you have to go into a console and run shutdown -q, IIRC. It actually caches quite a lot of state for all running applications and loads them every boot.
May not be a big deal for most applications, but sometimes there’s going to be external state that (at best) only the application can restore. Connections to stateful network services for example.
Back in the good old days, the procedure for turning off my Amiga was to push a button that just disconnected the power. Sometimes the simple ways are best.
An implementation of what, exactly? Tracker already does this, other applications would have to implement it themselves.
Actually most Qt applications written on Linux probably already support “session resumption”, as it’s used extensively there. That could be leveraged already.
I see now, there is a time slider on the password lock. This should be set to zero if one movs to a hot corner to activate the screensaver as this is how one would lock the computer to walk away for a few minutes.
This, actually, is one of, if not the, main reason that I find Haiku the only OS that’s a pleasure to use! Starting from scratch every time I boot Linux is a pain. (Don’t know about what Munchausen mentions regarding Windows – haven’t touched it in 15 years…)
What would it take for an app to save-on-shutdown and restore-on-boot? Most apps seem to forget everything when you shut them down. The only one I can think of that doesn’t is Media Player. Is there a defined protocol for doing this sort of thing?
When handling QuitRequested(), you can look at the B_QUIT_REQUESTED message using CurrentMessage(). It contains a boolean indicating if the cause of quitting is a system shutdown
In that case, you would normally ask the user to save unsaved files or destroy them. But instead you just save your application state (probably by implementing BArchivable and archiving yourself)
There is one missing bit in Haiku side, which is restoring such apps on the next boot. Tracker is autostarted, of course. Probably, apps should agree on where to save their state so the OS can look there and see what to restore
The app can then be unarchived from there. It probably needs some changes to the main() function of the app to parse the command line arguments, detect that it’s launched in unarchive mode, and call the appropriate BApplication constructor (with the archived message as an argument)
It needs more changes to the app than a more low-level system would, sure. But I think overall it is a bit simpler still.
How to avoid global IDs (area_id, sem_id, image_id etc.) collision problem? When restoring process image, some ID may be already used by another running application.
That’s why I think it should be done by the application itself using BArchivable rather than a system-handled thing. If we were doing Java or something like that there would be a way, but in a compiled language like C++, that’s not going to work at system level.
Parsing command line arguments is not needed, it can be done by handling first BApplication message that is sent by BRoster::Launch and detected by IsLaunching(). For example B_RESTORE_APP_STATE with entry_ref pointing to archivable file can be sent. Also corresponding B_SAVE_APP_STATE can be sent before shutdown.
The first idea would be tiny: a simple “Nap” link… which literally would take nothing to code; in the distro I failed at a few years ago, I’d added a link to a script, which in turn ran the Blank/Blackness screen saver and that was ‘Nap’. It wasn’t (and wouldn’t) be a true sleep mode of course, but it’d at least allow the screen to blank while away.
It would basically be shutting down like normal, but the difference would be that (maybe just to start with) applications are remembered just like recent apps are, so when the system enters hypersleep, it’ll try to auto-quit everything running and then bring everything back up on the next restart. This would be useful if the battery ran out and Haiku needed to power down (or someone needed to shut their computer off).
