[seba_dos1]

That's a massively inaccurate comment.

> This renders the firmware unupdateable without shorting a connection.

That's incorrect, the firmware can be updated by the user without having to modify the hardware.

> the firmware cannot be updated without physically dismantling the phone

Not true.

> Firmware initialization is also no longer under the control of the host operating system because the initialization is carried out from outside the OS: changing or updating software on the host will not address these design defects.

The OS can choose to not use the firmware stored on flash and load it directly from rootfs instead. postmarketOS does that already for WiFi firmware, for instance. Compiling u-boot that doesn't use the SPI flash for DDR blob is trivial as well. The point of having the flash is for the OS to not have to touch it, but nothing prevents the user from touching it if they really want, not even "having to short a connection".

> Current releases of the Librem 5 have been plagued by thermal throttling issues and poor battery life which in some cases has clocked in at less than 1 hour at idle.

That "current" means "fixed more than a year ago with software updates".

> The Librem 5 does not even support software encryption and no progress has been made toward adding even LUKS encryption.

Not true, LUKS works fine with PureOS Byzantium for months now.

> The Librem 5 lacks a secure element for any hardware binding on the encryption and so would be entirely dependent on software-only encryption.

There's a GPG smart card reader next to the battery compartment.

> which may be mildly out of date

...as seen above.

Don't trust any information about the Librem 5 coming from GrapheneOS developers, their reaction to pointing out their mistakes is to block the person that corrects them ;)

[kop316]

Is this person a Graphene OS dev?

I couldn't confirm that (from a cursory search), but if so, this massively undermines my confidence in using it on my Pixel.

[seba_dos1]

The person who wrote the comment I replied to? I don't think so, they just copy'n'pasted and linked to a page written by a GrapheneOS dev. However, I have some history of communication with GOS devs on Twitter trying to correct their mistakes and they always confidently repeat their misconceptions despite of clearly not knowing what they're talking about and it ends up with "I'm not lying, you're lying" and me getting blocked, so...

(granted, I'm probably not the best in non-violent communication, but they could at least try to do some research anyway ;))

[kop316]

Gotcha.

> (granted, I'm probably not the best in non-violent communication, but they could at least try to do some research anyway ;))

Considering how badly incorrect the dev's page is, I agree. I gave them some credit since it was over a year old, but if they behave like that, it sounds like I need to reinstall LineageOS.

[atat7024]

LineageOS breaks the AOSP security model.

I wouldn't recommend this to anyone as a first choice.

[kop316]

You make this comment: https://news.ycombinator.com/item?id=26775235

Which is riddled with errors. Make a well cited annotation of the errors.

You say you addressed my comments "elsewhere" https://news.ycombinator.com/item?id=26783664

I ask you where.

Your response is a deflection: https://news.ycombinator.com/item?id=26784172

My interaction with you has only undermined my confidence in GrapheneOS (especially considering seba_dos1's perspective, and he is a person I have worked with and I trust his judgement). I have no idea why you think I would listen to you about LineageOS.

[atat7024]

Not a dev, just a somewhat active community member — would be interested which dev you spoke to, and on what inaccuracy!

[seba_dos1]

First time was with someone behind the official GrapheneOS twitter account, and second time was with Daniel Micay, both times about the hardware supposedly preventing the ability to update the firmware even when running alternative software.

In reality, the only thing that prevents the firmware from being upgraded is the default software not implementing such features (because PureOS does not and will not distribute non-free software or firmware). A user who wants to do that can reflash everything without modifying the hardware in any way or even opening the case. Both WiFi flash and the M4 core-based solution described in https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd... can be bypassed completely to load the firmware from rootfs just by using a different kernel and bootloader, and disabling SPI flash read-only protection is a single line of code change in the device tree.

[atat7024]

> just by

[seba_dos1]

If you install an alternative distro on the Librem 5, you're already using a different kernel and bootloader; exactly like on a PC. This is not some locked down Android device where that could be considered rocket science.