@jawsh its super variable. android has fancy features to restrict background activity which we don't, but we do have fairly good suspend.

if you turn on airplane mode and but the same op6 to sleep running pmos and android, you'll get a few days in pmos but a few weeks in android (we don't reach the lowest levels of power consumption in upstream linux).

if you're using the phone actively, you'll notice a big difference based on if you close apps before putting it in your pocket. On mobile data, if you enter suspend with any tcp connections open and the server sends you data the device will wake up, android has filtering rules in place to limit this behaviour to only the push notification server.

so basically, if you use it like an android phone the battery life is noticeably worse, but if you adapt your usage patterns you can easily get a day or maybe 2 if you're very light, but the idle power consumption is a little higher.

@dalias @jawsh yeah it works ok but not super reliable. freezing at a cgroup level (e.g. systemd slices) is very consistent though. then you just need to integrate with pipewire and other bits to avoid doing this to apps that you actually do want in the background, provide some API to let apps ask to keep running and you're more or less good to go?

just don't make the same mistake android did in giving apps too much control and then spending a decade fighting to get it back without breaking them.

@dalias @bart @cas @jawsh I'm not convinced by Push Notif. servers. Self-host is out of question for regular users. So someone has to host, pay for it and then there is privacy/trust issues.

Is it really the end of the world battery-wise if instead of polling 1 server, we poll a few of them (signal, email, etc.) ?

The various apps could subscribe to a OS-deamon that pools on their behalf and wakes the app up when needed. This deamon would be sort of a local on-device push server

@woxom98179 @dalias @bart @jawsh

the point is not to poll, you maintain a persistent TCP connection and configure hardware (specialised co-processors and/or WoWLAN capable wifi) to drop all packets except ones from the push server telling you there's a notif (and maybe you buffer it unless the priority is high enough)

idk if it's reasonable to ask signal to offer to serve thousands (more!!) persistent tcp connections, and the actual tooling to keepalive and service them.

this needs to be a dedicated service, and i think it's honestly a bit dumb to have privacy concerns. The way signal handles push anyway is that it only sends a ping that there is a message so that the phone will wake up and actually retrieve it (since messages are encrypted!), same for matrix and others. At that point it's only metadata, which can also be further anonymised.

if you're in the position where you don't trust a service hosted by the people who make your OS, you're using the wrong OS my friend. They could just as easily insert malicious software on your device itself.