zlacker

[return to "Librem 5: First Impressions"]
1. SkyMar+Me[view] [source] 2022-03-22 01:18:47
>>jstanl+(OP)
> The battery life seems short. I'm pretty sure that I charged it up to 99% when I plugged it in this afternoon. It's now 10pm and I just went to check something in Firefox and found that the battery has died already. And I haven't exactly been using it heavily. It's possible that I misunderstood how much I had charged it, but so far this is a bad sign.

Battery life is an area that may be difficult for smaller phone makers to compete on. I think Apple especially puts a ton of engineering effort and coordination into making iOS and their apps work efficiently with their hardware, reducing complexity, runtime cycles, and power consumption as much as possible, on top of already highly-efficient ARM hardware.

Over years of doing that (kaizen), the result is optimized hardware/software fusion with industry-leading battery life. But it seems like it takes a non-trivial amount of additional engineering time and effort to accomplish this, that will be difficult to match by smaller mobile tech startups.

I hope the open source community around Librem and Pine will be able to replicate that effort, but I'm not sure this kind of consistent incremental upgrade work is attractive enough to volunteer FOSS developers. And being maximally effective at it most certainly requires the parent company to coordinate the effort across hardware, software, internal teams, and external volunteers.

◧◩
2. yeetsf+sf[view] [source] 2022-03-22 01:26:56
>>SkyMar+Me
Maybe. Android works across tons of devices and the difference in battery life doesn't jump out to me compared to the fruit company. Linux on a laptop gets similar battery life to Windows in my experience, and that's without using kernel patches and crazy settings, etc.
◧◩◪
3. izacus+4U[view] [source] 2022-03-22 09:58:54
>>yeetsf+sf
> Maybe. Android works across tons of devices and the difference in battery life doesn't jump out to me compared to the fruit company. Linux on a laptop gets similar battery life to Windows in my experience, and that's without using kernel patches and crazy settings, etc.

Google also invested a lot of time into optimizing battery consumption (which hackers and people like the guy from Commonsware derogatory call "War against background processing"). If you look up through history of Android releases, there isn't a single release where there would't be a pretty major change in how Android puts device to sleep and how it wakes it up again.

That stuff is really hard since a single bad service can drain your battery in matter of hours and needs seriously tight coordination between all software makers on your device to avoid problematic edge cases.

◧◩◪◨
4. blihp+vj1[view] [source] 2022-03-22 13:39:08
>>izacus+4U
It's more often a case of misaligned incentives than being all that difficult. When your business model (both Google's and most 3rd party developers) depends on constantly streaming telemetry from a device to a server you're going to have battery life challenges. Much of Google's effort has gone to providing decent battery life while still providing the telemetry. No doubt that a fair amount of effort has gone into specific use cases like background streaming audio apps (i.e. phone/music/etc) but the hours those take are a drop in the bucket compared to making the whole advertising ecosystem work (efficiently enough) on mobile.
◧◩◪◨⬒
5. etbe+hu3[view] [source] 2022-03-23 02:48:01
>>blihp+vj1
My first Android phone was a Sony Ericsson Xperia x10i. With that phone I could go to sleep while playing music from the SD card and wake up 8 hours later with plenty of battery left. The same phone however would run out faster if doing stuff over Wifi or using GPS. It was mostly a matter of how much power different things took.

One of the things I want to do on my Librem5 is monitor my servers, so that will involve polling things every few minutes. PowerTop says that I can save power by changing the polling for USB, but that changes Wifi ping times from ~1ms to ~350ms. Eventually I'll probably try experimenting with that to get an option with a 10ms ping time that still saves some power.

[go to top]