i think i used a laptop for a few hours in my life before I decided to simply disable all autosleep features.

computer is on, it's on. lid close, screen is off. done.

That's fine. In fact you're right that laptop and desktop power management is generally best done manually by expert users. That how I have things set up too, more often than not.

The use case for wakelocks (a longtime Android feature from which this is conceptually derived) is phones, though. Send a quick snap, throw it in your pocket, and expect (1) you get the notification for the reply when it arrives and (2) the device lasts until it gets back to the charger at bedtime.

That's highly non-trivial and absolutely not amenable to manual power management. Is systemd the right answer? Maybe not, but that's clearly where the feature is aimed.

▲

skydhash 3 days ago | parent | next [-]

That’s a very specific use case and solved with a combination of hardware and software (solved badly with s2idle from Microsoft). With computers, you don’t expect notifications from sleep state. It’s either active (even idling) or on standby (you don’t expect it to wait). There’s no standard for active threads in deep sleep mode (restricted API, short TTL) that phone OS boast)

▲

ajross 3 days ago | parent [-]

Right, but the software side of the stack needs a way for subsystems to say "I'm important, don't suspend", and that's what this systemd feature is for. The fact that it's based on top of an S3 suspend to RAM means that the laptop can't do it well, not that it isn't a useful feature.

(Also I have to quibble with the "very specific use case" idea: it's the standard use case. Laptops are the weird and rare edge cases these days.)

	▲	skydhash 3 days ago \| parent [-]
		But on a laptop, I do want this case to be manual. Even on a phone, I would like to have more control over stuff like Notification and the likes (I think ios have background process or something).

▲

4 days ago | parent | prev [-]

[deleted]