It's not a good analogy. Something is still on in suspend. Good you can control Linux kernel, but what about all other chips which may be an attack vector?
There will always be more suspend/resume bugs to work through. It varies a lot per device. I feel it's necessary to paint the picture for people who are curious what it means for it to be a crapshoot, so indulge me while I share my experiences.
For work I have a ThinkPad T16 Gen 4 with the newer AMD gfx1151 iGPU. Works great. I have yet to witness any issues with suspend/resume. I suspect this is the case because it is running Ubuntu with Lenovo's own support package. Theoretically, from firmware to kernel, this is all tested and validated by Lenovo, like what certainly happens with every Windows laptop and all of the components that go into them.
I also have a gen 1 Framework 16. I have seen it crash on suspend, but it is pretty rare, so I've just shrugged it off for now. It would be hard to debug, I don't see it every month despite using the thing every day.
All of my desktops currently have perfectly reliable suspend resume, you can slam it all day and all night. The last time I ran into issues was a use-after-free issue in AMDGPU. Pretty alarming, although to be clear it never hit any LTS or vendor kernels that I am aware of. I hit it because I prefer to run the latest kernel on my personal machines.
I have certainly owned laptops where suspend basically didn't work, or it would not stay suspended. I think this mainly went away when I started specifically picking laptops for Linux support.
For Intel iGPUs and dGPUs, the track record has been flawless for me. I have a few of the new Battlemage cards that default to the xe kernel driver and those have been working very well as expected. So that's nice.
I don't think this situation will be fixed until more hardware vendors are taking part in validating their stuff on desktop Linux and keeping track of the kernels. The current Linux model seems to be just dealing with whatever the vendors crap out for Windows, often full of weird ACPI behaviors and buggy firmware. It's not to say that the fault of the problems don't often lie with code in the Linux kernel, but they do not seem to wish to be bug-compatible with Windows and I think that is perfectly reasonable, so for problems that come from essentially broken firmware, it simply is going to need vendors to actually fix their shit.
(And that includes AMD. The drivers are good in some regards, but it's hard to ignore AMD's stability issues even still. At this rate, more of the long outstanding AMD driver issues will get resolved by Claude than AMD engineers... Like with Panel Self Refresh on 7040 iGPU, apparently.)
Suspend to (encrypted) swap might be a good middle ground between you and grandparent. Suspend to memory will (at best) protect your LUKS volume key, but other sensitive data remains.
A couple of years ago, three security researchers from the TU Munich implemented a prototype for also encrypting (most) parts of the memory just before suspend, to address this limitation; but as far as I know, it was not upstreamed or developed further: https://www.sec.in.tum.de/i20/publications/fridgelock-preven...
There is no universal support for restoring state between the apps. For example, Terminal won't run the scripts that were running, the browser will not automatically restore the pages etc, some apps might not launch or launch with wrong state.
Gnome desktop environment cannot even remember the position and size of console windows, you are expecting too much.
And I don't use GUIs, but it doesn't mean I have to be a jerk to people who are happy when their GUI gets better :-).
Suggesting I'm an exotic animal for being budget and environmentally friendly is being a jerk too.
> That's a you problem. I shutdown my machine when I'm not using it.
"We designed the antennas correctly, you're holding the phone the wrong way."
It's not a good analogy. Something is still on in suspend. Good you can control Linux kernel, but what about all other chips which may be an attack vector?
Except shutting down and hibernate are two actions the user can literally select from the same menu.
I shutdown mine too but only because suspend is still a crapshoot on linux
There will always be more suspend/resume bugs to work through. It varies a lot per device. I feel it's necessary to paint the picture for people who are curious what it means for it to be a crapshoot, so indulge me while I share my experiences.
For work I have a ThinkPad T16 Gen 4 with the newer AMD gfx1151 iGPU. Works great. I have yet to witness any issues with suspend/resume. I suspect this is the case because it is running Ubuntu with Lenovo's own support package. Theoretically, from firmware to kernel, this is all tested and validated by Lenovo, like what certainly happens with every Windows laptop and all of the components that go into them.
I also have a gen 1 Framework 16. I have seen it crash on suspend, but it is pretty rare, so I've just shrugged it off for now. It would be hard to debug, I don't see it every month despite using the thing every day.
All of my desktops currently have perfectly reliable suspend resume, you can slam it all day and all night. The last time I ran into issues was a use-after-free issue in AMDGPU. Pretty alarming, although to be clear it never hit any LTS or vendor kernels that I am aware of. I hit it because I prefer to run the latest kernel on my personal machines.
I have certainly owned laptops where suspend basically didn't work, or it would not stay suspended. I think this mainly went away when I started specifically picking laptops for Linux support.
For Intel iGPUs and dGPUs, the track record has been flawless for me. I have a few of the new Battlemage cards that default to the xe kernel driver and those have been working very well as expected. So that's nice.
I don't think this situation will be fixed until more hardware vendors are taking part in validating their stuff on desktop Linux and keeping track of the kernels. The current Linux model seems to be just dealing with whatever the vendors crap out for Windows, often full of weird ACPI behaviors and buggy firmware. It's not to say that the fault of the problems don't often lie with code in the Linux kernel, but they do not seem to wish to be bug-compatible with Windows and I think that is perfectly reasonable, so for problems that come from essentially broken firmware, it simply is going to need vendors to actually fix their shit.
(And that includes AMD. The drivers are good in some regards, but it's hard to ignore AMD's stability issues even still. At this rate, more of the long outstanding AMD driver issues will get resolved by Claude than AMD engineers... Like with Panel Self Refresh on 7040 iGPU, apparently.)
I am too lazy for that, and I hate that after boot you need to launch everything again.
Suspend to (encrypted) swap might be a good middle ground between you and grandparent. Suspend to memory will (at best) protect your LUKS volume key, but other sensitive data remains.
A couple of years ago, three security researchers from the TU Munich implemented a prototype for also encrypting (most) parts of the memory just before suspend, to address this limitation; but as far as I know, it was not upstreamed or developed further: https://www.sec.in.tum.de/i20/publications/fridgelock-preven...
You can usually change that in the settings of the Desktop environment.
There is no universal support for restoring state between the apps. For example, Terminal won't run the scripts that were running, the browser will not automatically restore the pages etc, some apps might not launch or launch with wrong state.
Gnome desktop environment cannot even remember the position and size of console windows, you are expecting too much.