zlacker

[parent] [thread] 6 comments
1. Hackbr+(OP)[view] [source] 2022-03-22 09:04:40
I don’t think they’re going to be able to improve battery life for much. Not even with lots of FOSS developers throwing hours at it.

I’ve read somewhere recently that in order to keep the phone mostly free of proprietary firmware, Purism had no choice but pick lots of discrete components. That would be in contrast to most other smartphone designs with more closely integrated chipsets, they wrote.

That discrete-ness, according to the author, is likely to be an upper bound for battery lifetime on the Librem 5. After all, all those chips have to be powered at least part of the time, and that allegedly consumes more energy than a single package would.

In other words: the Librem 5 may never gain a decent battery lifetime. As drivers mature, battery usage may improve a little. But not much. Buyers may want to keep their hopes realistic.

replies(3): >>fsflov+H5 >>blihp+Is >>rollca+rG
2. fsflov+H5[view] [source] 2022-03-22 10:06:26
>>Hackbr+(OP)
You are right about the lots of discrete components, but you are wrong about the battery life. Currently, Librem 5 works for ~10 hours and it has no suspend at all. One could probably expect 24 hours when suspend is fully implemented. More details: https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque....
3. blihp+Is[view] [source] 2022-03-22 13:31:00
>>Hackbr+(OP)
You underestimate how much other low hanging fruit there is. Yes, at some point using less integrated hardware (due to driver issues) will dominate but we are pretty far from that being the limiting factor.
4. rollca+rG[view] [source] 2022-03-22 14:44:28
>>Hackbr+(OP)
> I’ve read somewhere recently that in order to keep the phone mostly free of proprietary firmware, Purism had no choice but pick lots of discrete components.

This is only a half the story. The Purism still runs on proprietary firmware. The discrete components in question are an actual full auxiliary CPU core, its only purpose being to load the hard-coded blob to properly boot the primary SoC. This was done because under FSF's definition, if the end user cannot update the firmware blob, then the firmware is considered one with the hardware, and the hardware as a whole is "free enough".

So they took away the user's ability to update the firmware, fused it in a ROM with every possible bug and inefficiency frozen in place for the rest of eternity, wasted silicon and engineering time to do so, only to grant themselves an arbitrary, honorary badge.

This isn't even radicalism anymore, this is hypocrisy. As a power-user who values freedom, and a long-time Free Software sympathiser, I am personally offended, and won't give my money to either party until they reverse course on their user-hostility.

replies(1): >>seba_d+1c1
◧◩
5. seba_d+1c1[view] [source] [discussion] 2022-03-22 17:03:34
>>rollca+rG
> So they took away the user's ability to update the firmware, fused it in a ROM

That's simply not true. Users can upgrade those firmwares if they want (and absolutely no weird tricks like disassembling or soldering are necessary for that). PureOS doesn't distribute any non-free updates, but if you want, you absolutely can reflash these blobs.

replies(1): >>rollca+RT1
◧◩◪
6. rollca+RT1[view] [source] [discussion] 2022-03-22 20:50:44
>>seba_d+1c1
From TFA: https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd...

> The RYF has a “secondary processor” exclusion that can be granted on a case by case basis. We will leverage this exclusion to load and train the DDR PHY on the i.MX 8. We will use a secondary processor to keep binary blobs out of u-boot and the kernel.

replies(1): >>seba_d+rS2
◧◩◪◨
7. seba_d+rS2[view] [source] [discussion] 2022-03-23 04:58:46
>>rollca+RT1
So what? How exactly would that "take away the user's ability to update the firmware"?

Librem 5 does not lock the firmwares in any kind of ROM. Nothing is taken away from the user.

[go to top]