Windows definitely has lot of sleep issues. But yes Linux seems to be as bad or maybe a bit worse. I once shut down my Linux laptop and left it connected to power on my vehicle. When I returned, my vehicle was completely dead ๐ฎโ๐จ
Linux
A community for everything relating to the GNU/Linux operating system (except the memes!)
Also, check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
I recommend using hibernate (suspend to disk): your computer will "sleep" for 10 years without draining. The only cost is about 7 seconds to boot on modern hardware. For short interruptions with instant wakeup, you can still use light sleep states.
It combines perfectly with LUKS-encrypted root and swap partitions: your data is safe even if someone steals your computer and swakes it up.
Hibernate doesn't work with secure boot/kernel lockdown for $REASONS, a lot of folks can't even use it. Supposedly if Linux can determine you're resuming from an encrypted partition it will work, but I was never able to get it to work with a swap file on BTRFS on LUKS
There's only so much that can be done on the hardware/ firmware side, but his for me is the real gap that Linux can improve upon. Hibernate, disk encryption and secure boot/tpm unlock together have just worked for a long time on Mac and Windows.
The kernel decisions seem hostile and hard code a big assumption that it's always unsecure to restore from hibernate automatically. What's more insecure is having to disable disk encryption entirely. Secure boot is often misunderstood, but for all its flaws it is better than nothing, and your average user does not want to manually enter a decryption key on top of their user login all the time.
Because of this I feel a lot of software is not written and tested with hibernate in mind, so you also roll the dice on what works and what doesn't when restoring today.
Sleep for 1 hour and then auto hibernate after, in a working setup, meant this problem was solved - always enough battery to resume doing work, no user decision required, quick wake up if resuming a recent session.
I'd love to see multi-user switch selectively suspending user processes and writing them to disk, so you can quickly restore state between users, and if one user left a browser or game running it's not draining the battery on what are now known background tasks. No OS does this one well today.
I've found full shutdown and subsequent boot up on my current Bazzite setup takes less time then hibernate used to in Windows 10 on the same PC. Haven't even felt the need to look into setting up swap (Bazzite uses zram by default).
full shutdown and subsequent boot up on my current Bazzite setup takes less time than hibernate
maybe, but a full shutdown and reboot does not restore all your apps, open documents, terminals etc exactly as they were.
I rarely put my linux to sleep because I had this experience in the past, but yesterday I've had my minisforum v3 laptop in sleep for 3 hours and it stayed fully charged at 100% battery. It made me think the battery percentage readout was broken, but no, it strarted draining after using it for a while.
No clue if it's something I did back then during install (arch linux btw) or whether it was like this out of the box, but it really surprised me. And I'm gonna try using it more in the future.
Please preach us the forbidden knowledge you hold
No rest for the wicked?
Too much screentime before bed?
Debian has worked fine on my old laptop, probably only a few days for me but the battery is a decade old or so.
Windows has same problems. Its hot bag syndrome. Issue lies at hardware and firmware level. FYI my T480 configured for deep sleep looses only 1% per day sleeping.
I didn't configure hybernation though.
My previous laptop was fine - it lost a few percent per day. Now with s0ix, it's more like 10 or 20% per day. Is just turn it off if it weren't fit the fact that it also takes ages to boot for some reason. Sigh. And hibernate doesn't work with an encrypted disk.
Hibernate can work with an encrypted disk afaik
There's some combination of circumstances which prevents it. I think specifically it's encrypted swap, a kernel setting and maybe something else... I can't remember, except that when I looked at it I couldn't be fucked trying to get it sorted.