zlacker

>>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.

>>SkyMar+Me
Reading the Librem app docs it seems like apps are GNOME programs packaged with an manifest. I can’t find anything about app lifecycle.

To be able to conserve battery apps works differently than programs, apps can be suspended. That is usually the problem with normal programs, they are not developed with battery conservation in mind.

I wonder how Librem have solved this, perhaps in their scheduler, or intends to solve this in the future.

https://developer.puri.sm/Librem5/Apps/Guides/Design/Constra...

>>tored+xA
All programs on the Librem5 appear to be in Debian packages and most of them seem to be identical to the ones in Debian. The document you cited has procedures for getting packages in PureOS independently of Debian, but it seems that most of it will be stock Debian. For my development it seems easier to just upload to Debian and wait for the next Debian release for it to be officially part of PureOS, I'll setup my own apt repository for the things I do and publish the URL for anyone who's interested.

As for apps being suspended, most apps are suspended when there's nothing to do. If a graphical application is minimised so it doesn't have to redraw the screen then it should either be doing nothing or occasionally polling a server if that's it's design.

Web browsers are an interesting corner case as web sites often have JavaScript that wants to run all the time and there's some trade-off between doing what the web site wants and saving CPU/energy. But that's probably not going to be an OS issue for PureOS but an Epiphany browser issue.

>>etbe+Kt3
Don't you need hooks on the application level so the app can handle the lifecycle to avoid polling?

https://developer.apple.com/documentation/uikit/app_and_envi...

https://developer.android.com/guide/components/activities/ac...

I'm not an app expert nor an expert on GNOME development either, but I got a bit sceptical when I read their app example code, python with GNOME, neither is famous for being snappy.