Personally, Hibernate works great, doesn’t require any battery life to sustain it, and always comes back with state intact, so it’s my go to.
Seconded. All of these modern "smart sleep" solutions are uniformly worse than just giving me a got-danged hibernate option.
Extremely false: hibernate is way slower. Sleep happens within a second and awakes within a second. Hibernate requires writing all your memory to disk; if you have, say, 15GB of memory in use and a disk that can read and write at 1 GB/sec (far from the fastest, but also extremely far from the slowest), that’s fifteen seconds. For many (probably most) people’s realistic situations, hibernate will take over a minute.
(Heh, my own laptop takes 4–8 minutes to hibernate if its CPU is slowed to 400 MHz to minimise power consumption, which incidentally happens automatically when it’s almost down to 0% battery power, shortly after which it triggers a suspend-then-hibernate, and the extra time that makes it take it brings it perilously close to running out of power before it finishes. Not certain why limiting the CPU has such a massive effect, but I’ve compared it when manually inducing similar circumstances by giving the CPU an impossibly low power envelope with `ryzenadj --stapm-limit 100 --fast-limit 100 --slow-limit 100`, which limits all cores to 400 MHz, and yeah, that makes hibernate slow.)
It's been a while too, I'm remember that being a plus of Apple devices since 10+ years.
According to this thread we might never get AMD pstate driver working.
https://forums.lenovo.com/t5/Other-Linux-Discussions/amd-pst...
https://github.com/pimeys/nixos/commit/17e8a9e2ce4b0f34ef6cf...
It should also be used together with the `shedutil` governor for the best results.
If you see the thread linked in previous comment, Lenovo has been advised not to enable the feature :/
> cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
amd-pstate
[1] https://forums.lenovo.com/t5/Other-Linux-Discussions/amd-pst...
without raid it's not too hard, just bothersome and finding the right information can be annoying
the main gotcha is that lockdown mode is incompatible with hibernation (no matter if it's encrypted or not) and some distros enable it by default when secure boot is used, which is most times the case with a full disk encryption setup
Thats an understatement. I never made suspend-then-hibernate work reliable on linux and I tried it over the years on different systems. So I just had developed the habit of always entering hibernation, if I intend to close the lid for longer.
On windows suspend-then-hibernate never failed so far.
Drivers are just the crux with linux in too many cases. Not much you can do about it, except reverse engeneering drivers as a side project.
Once hibernation is setup just set systemd [Login]HandleLidSwitch=suspend-then-hibernate and maybe configure the delay with [Sleep]HibernateDelaySec=5min.
Hibernation most times works nice too (even with Full Disk Encryption (FDE)) there is just one gotcha, lockdown mode is currently fundamentally incompatible with hibernation (even through it's docs seem to imply something else, they refer to a not yet existing feature). And some distros enable lockdown mode by default if you use a proper FDE setup. Leading to a lot of confusion about hibernation suposedly not working anymore in linux or being incompatible with FDE.
It cannot even boot for an about an hour while it charges to a minimum level.
I have a Macbook Air, M1, which I don't use regularly but turn off after every use. When I go to turn it back on again, the battery's completely dead. I haven't had that from any non-apple laptop for a long time, and I sometimes go +6 months without turning them on
The trackpad though I'm in agreement with. I never understood why people use an external trackpad with their imacs until I used it on the macbook