Interesting, possibly useful as a daily driver.
Also: link for the best pro comment about linux phones I've read on HN: https://news.ycombinator.com/item?id=26080871
Afternoon to 10pm with light use, so around 8 hours. Would be curious to see how long it last with maps and music going.
I don't agree - you may not care about spying much, but you can still want a handy fully hackable GNU/Linux computing device in your pocket as your mobile phone, that belongs to you and not the vendor; in which case, the Librem 5 may be the perfect choice for you as well :)
> Backups (...) "Unable to find supported SSH command"
Hah, sounds like a missing package dependency! Most likely missed because, well, who doesn't install ssh on their phone right away anyway? ;)
> I installed telegram-desktop with apt and it automatically shows up in the app launcher, which is a good sign, although it doesn't work.
Seems like `qtwayland5` package needs to be installed, otherwise Qt apps go through XWayland. I know that people are using telegram-desktop successfully.
> but by this time it was a bit darker, and this was the best I managed to do:
You may be interested in this blog post about how to take the most from Librem 5 camera: https://puri.sm/posts/librem-5-photo-processing-tutorial/
> It's more annoying than struggling with the autofocus on the OnePlus One.
There's an update coming that changes the focus scale in a way that makes it much easier to work with. Still not exactly pleasant, but it's definitely better :)
> I can't find an option to turn off notification sounds short of turning the volume down to 0.
It's in the quick settings accessible from the top bar - a bell icon allows you to toggle notifications between audible, vibration-only or completely silent.
> The browser has no "stop" button.
It's in the hamburger menu.
> the "please take me to the launcher" arrow being mere pixels away from the "please input a space" button
That's being taken care of, as the current implementation was always meant to be temporary - both top and bottom bars are supposed to be operated by swiping: https://social.librem.one/@agx/107220158614198549
Overall, glad to hear that you're happy with the phone :) Thanks for sharing!
“In February 2018 I placed an order for a Librem 5. Today it finally arrived.”
You can set up Anbox on your PC and see how that works. It's the same thing on the phone.
When comparing against something like a Pixel running GrapheneOS, it's honestly a bit more puzzling to me. Granted, I'm definitely not the audience for this, but with G_OS you can do most things that a regular phone can do, without taking several minutes to install Firefox.
As much as I love privacy (going as far as having a semi-random username), this phone is a bit puzzling. I hope someone can throw more light on this.
But I don't know if a full emulator is a good idea on a smartphone.
There's also Waydroid, which works by implementing things like Wayland/PulseAudio clients directly inside Android compositor/sound system, but I haven't ran it on the Librem 5 yet (I know that some people are using it on the PinePhone).
[edit] I've been listening to music via Bluetooth on it for past three hours and it's at 75% right now.
If your distro ships the latest version of Chatty alongside mmsd-tng[0], SMS as well as MMS (both bidirectional) work supremely well, I trialed it as a daily driver for all of last month and didn't drop a single SMS/MMS. MMS attachments (images, didn't try video), group chats, everything was fine.
I still had to configure APN settings manually, but there was no faffing about on the command line, it just worked. All the other points, though, yeah... those are still accurate.
[0] https://gitlab.com/kop316/mmsd
Edit for clarity: this comment (and the link in the parent) references the PinePhone, not the Librem 5, though they're roughly comparable devices
Edit: looks like you're already aware of that :)
I'm not familiar with GrapheneOS but I assume it follows the usual model when repurposing Android devices of taking various closed source blobs (i.e. drivers etc) and rebuilding the open source bits around them? If so, this approach usually locks you into a Linux kernel version to remain compatible with the blobs which limits you on kernel features and fixes as well as who knows what exposure the blobs have to offer, which also will likely never get updates.
Conversely, Pine64 hardware seems to have a pretty dedicated developer community among the various mobile Linux distros, and considering the significantly improved specs of the Pinephone Pro over the original model, I'm wondering how many people will opt for the even-more-expensive Librem 5 in the future after the Pro has been out for a bit and some of the early-adopter kinks have been worked out, considering the issues Purism has had seemed to have with reliably getting inventory out.
[1] https://www.pine64.org/pinephonepro/
[2] https://developer.puri.sm/Librem5/Software_Reference/Environ...
I run Arch Linux on all my devices with no Desktop Environment. The simpler the system the better. Running Android Framework along with a runtime, even though it's all open source, I'd rather as much of it be free software as possible. If I could run my phone like this I absolutely would but the Librem 5 is as good as it gets while still having a device that fits in my pocket that can make calls and text.
I'm just playing the devil's advocate/trying to understand why someone would actually use it. And yes if desktop Linux gets big that'll certainly make this entire comment seem stupid (which would be pretty nice:)
Or "is able to roam across a house with a few AP's or a business with many"
Sticking to an LTS kernel branch for the lifetime of the device isn't due to anything closed source. GrapheneOS only supports devices with proper security support for all the firmware, drivers, etc. and again there are no closed source kernel drivers. We can support pretty much any mobile device with alternate OS support since any serious one will have AOSP support. Most devices have lackluster security and don't meet our requirements. We're working with a hardware vendor to get a non-Pixel phone actually meeting reasonable security requirements.
Librem 5 has a bunch of components where they are not shipping updates. You have things very much backwards on that front. The Librem 5 does not come close to meeting the security requirements to run GrapheneOS. It has a bunch of poorly secured and insecurely configured legacy hardware often without proper updates available, components that are not properly isolated via IOMMU, no secure element or all the stuff that comes along with that (HSM keystore with a nice API used by apps, Weaver to make disk encryption work for users without a high entropy passphrase like 7 diceware words, insider attack resistance, working attestation not depending on hard-wiring hashes and a lot more) and many other things. The OS they use has a near total lack of any systemic overall privacy/security work or privacy/security model and only falls further and further behind. The most exciting feature for securing devices right now is hardware memory tagging support in ARMv9, but there are years and years of tons of important privacy/security work done in a systemic way across hardware/firmware/software which are missing there before worrying about stuff like that.
Marketing something as private/secure and spreading tons of misinformation and outright lies about the mainstream options doesn't make it secure or more secure than those. It's actually pretty funny that they mislead people about the isolation of hardware components like the cellular baseband in other devices when the vast majority of mainstream phones (iPhone, Pixel, Qualcomm SoC devices, Exynos SoC devices) have it done quite well when they don't. Strange that they get away with these games of misrepresenting things, hiding the fact that they still have entirely proprietary hardware and near entirely proprietary firmware for the SoC and other hardware components, etc. Hiding proprietary stuff doesn't make it go away. Not updating it doesn't make it go away and simply ensures a highly insecure device.
> Being able to call and send SMS is secondary.
This is the basic definition of a mobile phone for me [1]. We can all have our opinions on what the "killer app" is. And some may rather want a pocket sized computer. The old grumpy man in me wants to shout "Get off my lawn" - please do not redefine what a "phone" is. How much we all may hate telcos they at least have ensured world wide communications. I accept the fact that many today are willing to trade that away to each their own favourite corporate garden be it Whatsapp, Telegram, Facetime et. al. However it does not a phone make. Sweet sweet E.164 [2].
It might be an unfair interpretation but as I read it calls should even be secondary to games!
So in my mind you argue the focus should be on a tablet [3].
You might be wishing for another device class which is fair. But this kind of redefinition I find troublesome.
[1] https://en.wikipedia.org/wiki/Mobile_phone
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.
What is this 'if' of which you speak? I've been using Linux as my daily driver desktop for over a decade ;-) It's not likely to ever become a mainstream desktop, nor are these Linux phones, but there are a fair number of us who don't care if they do or not. We just want them for ourselves.
Same with Linux/Windows versus Macs. It is only recently that Linux/Windows laptops have begun to approach Macs in terms of battery life, and their battery efficiency is still far behind, especially with Apple Silicon being a thing.
Purism's marketing material is outright deceptive, e.g. they insist that in competing phones the baseband blob has access to system memory, which is a lie. The reality is that the baseband blob in the Librem 5 (which is every bit a giant blob as that in the competition) has access to the USB port of the AP and there is no filtering implemented yet, so the attack surface it is exposed to is every USB driver in the Linux kernel, which is much worse than systems with embedded basebands and proper memory firewalling where the baseband has no more inherent access, but is exposed to a smaller attack surface. That means that you are more vulnerable to giant blobs doing evil things with a Librem 5 than with, say, an Android phone running a free OS build.
Then there's the whole hilarious situation with the RAM initialization blob where Purism went and hid it behind two layers of CPUs (not execution, just handling it), because somehow doing that - which provides absolutely no benefit to the user, it's just a waste of engineering time - made it possible to certify the phone under the FSF's utterly broken and nonsensical "Respects your Freedom" program, even though precisely zero freedom was gained by doing this, since it still running the same blob on the same final CPU with the same access. All the while while reducing security, since the blob is then made no longer part of the normal OS image and is not validated with it, so it could be backdoored as part of a supply chain attack and you would be none the wiser.
The whole thing just stinks the more you look into it, and it is completely evident that the folks behind Purism are a mix of deliberately deceiving people and just clueless about security and modern embedded platforms.
Chatty used to use a libpurple plugin, but the dev realized the issues that came with it (as the old comment outlined), and it was moved into Chatty proper, which also allowed for a much cleaner SMS/MMS implementation too.
> MMS attachments (images, didn't try video), group chats, everything was fine.
MMS on Chatty actually supports arbietrary attachments, so you could send a binary file, a PDF, Video, whatever. Android and iOS will not understand them, but you can send it to another Librem 5 or Pinephone. One neat thing I tried was to use GPG over MMS. It was successful, though very manually intensive. There was thought into making GPG over MMS transparent in Chatty: https://source.puri.sm/Librem5/chatty/-/issues/671
It can't be possibly be attractive enough to compete with the billions of dollars that Apple can spend on this. The company has nearly $200 billion in cash sitting around. FOSS just can't compete with what Apple can invest on hardware development.
That's true and relevant to Purism.
Now, how about something true and relevant to your post wrt FOSS:
> GrapheneOS only supports devices with proper security support for all the firmware, drivers, etc. and again there are no closed source kernel drivers.
Tell me about the license for the source of "all the firmware." And keep in mind you found it important enough to reiterate the point about "no closed source" for the kernel drivers.
I've tried different setups eg. Manjaro/KDE (default), Arch/Mobian Phosh. KDE is more like a phone, Phosh is "more stable" and particularly my interest external display which is buggy.
Regarding battery I have now just started to remove them from the phone rather than putting it in Airplane mode because it still dies too fast.
The squad [0]
I have Mobian/Phosh running on SD card, see the 6 cores and 4 GB of RAM [1]
I use Tmobile for service cheap sms/call only plan
I don't use it as a daily driver yet, like install an email client and things like that. Was more interested in docked computing as a desktop. I know about Samsung Dex but I'm still onboard for a new OS, I'm particularly annoyed with forced bloat/permission issues (some understandable).
I ran AOSP builds for years and that's a half-truth at best. Sure for the kernel proper, you have the source. However, there are a fair number of closed source drivers for the GPU, modem, wifi etc. From the GrapheneOS Wikipedia page[1] it sure looks like they're following this model.
If I am mistaken and there is a miraculous state-of-the-art SoC with completely open source drivers being used by a major handset maker, do tell. You'll be a hero in the open source world for pointing out something everyone else has overlooked.
> Sticking to an LTS kernel branch for the lifetime of the device isn't due to anything closed source.
It has everything to do with things being closed source. Try doing a Linux kernel major version upgrade with binary-only drivers for key components sometime. It sounds like the only reason GrapheneOS works is because they're 'drafting' off of the kernel and driver work done by Google, not that they've cracked that particular nut themselves. Nothing wrong with that, but it does limit the useful life of a device to the first major security issue they can't fix due to a lack of source code.
Regarding the rest of your response, you're assuming that I was speaking to the Librem 5 specifically, I was not. Notice that I was only speaking about the goal of a 'pure' Linux phone since that was what seemed to be being asked about. Personally, I have a PinePhone[2] and wasn't interested in rehashing the various issues with the Librem 5.
[1] https://en.wikipedia.org/wiki/GrapheneOS
[2] which itself is far from perfect, but comes a lot closer to being a 'pure' Linux phone.
Since I am usually either at home or at work, it isn't far away from a charger so battery life isn't a huge deal for me.
Being able to receive and place calls is critical for a phone, but I think for many people it's far from the most common activity performed on one. I don't upgrade my phones to make better phone calls, I upgrade them to get better cameras.
As of March 21, 2022, I have not received my order yet. When given the option, I selected to receive the completed phone, rather than a beta build. Thus, the delay.
Mainly, I did not order this to just have a phone (as I have several older Androids). I wanted to help fund an alternative to the Android / Apple ecosystems.
Hopefully soon.
Although Motorola smartphones have been pretty solid for a while now, so not discounting that there has probably been a lot of R&D effort invested on their end too.
Heh, with how the developers cooperate, you would never know there was competition.
But seriously, if you do want to fund Mobile Linux, buy a Librem 5. Purism funds dedicated GNOME/Phosh/etc. devs to work on making Mobile Linux a polish experience, and many of them also help to make sure it works on the Pinephone/Pinephone Pro. Heck, sometimes I think many of their employees spend more time helping out Mobian users on a Pinephone than they do Librem 5 users.
As much as I like Pine64 (I think making a $150 Linux Phone was an amazing idea!), they exclusively only fund the hardware development. Drew Devault has, IMO, a good overview of criticisms of Pine64: https://drewdevault.com/2022/01/18/Pine64s-weird-priorities....
If Apples battery efficiency is so good they should release a phone with a 5000mah battery /as well as/ said efficiency and market their battery life that beats all their competitors by multiple days, I'm sure a lot of people would buy that in a heartbeat.
Deleted that part of my comment.
There isn't anything remotely misleading about the correction that kernel drivers are not in the same situation as most firmware in that they're entirely open source. Every ARM SoC is a proprietary SoC with proprietary CPU cores, memory controller, GPU, image processor, radios and all the other massive complexity included in them. There's a ton of firmware involved in that proprietary hardware. It exists whether or not it's updated. Not updating the radio, GPU, etc. firmware doesn't mean it doesn't exist. Whether or not it's open or closed source has little relevance to the need for it to be hardened, properly isolated and updated. Open or closed source does not directly provide any privacy or security properties. Other components outside the SoC are almost always closed source too. We don't think the fact that the Pixel 6 has a TEE OS based on the open source Trusty TEE or a RISC-V secure element based on OpenTitan makes it inherently more secure than Qualcomm's offerings. Pixel 6 having a Samsung cellular radio and Broadcom Wi-Fi/Bluetooth radio as 2 separate chips from the SoC instead of being part of the SoC has not made those more isolated or more open, and if anything we consider moving away from the Qualcomm radios to be a security regression with how well Qualcomm hardens them, although the overall improvements make up for it. If we made a device, it would have a Qualcomm Snapdragon 8 Gen 1, and we'd be quite happy with having the most secure radios, hardware memory tagging support and Qualcomm's great security work elsewhere. Would it be nice if we could have more control and insight? Sure. If a theoretical currently non-existent open source RISC-V smartphone SoC existed and it had comparable privacy/security (which would be very difficult), we'd be very interested. It would take massive work beyond simply having a viable SoC in the performance class with the necessary functionality to make anything remotely competitive on a security level.
GrapheneOS is a non-profit open source project and doesn't produce or sell hardware products. We don't do consulting, exclusive deals with companies or anything like that. There is no intention to ever sell any products, but rather we research hardware, report issues upstream and choose the best available hardware as the officially supported targets. We also intend to work with hardware partners on equal footing with nothing exclusive to help them produce better devices, which will benefit them and will benefit us through having more and better devices to support. We could potentially get more reliable donation revenue through devices with GrapheneOS installed, but that's in no way any kind of requirement for us to work with vendors. We have little to no interest in ever selling devices ourselves. We're fine with the fact that over a dozen companies sell devices with GrapheneOS installed mostly without giving anything back to us. Only a couple give us any form of donations/support. This is not a business.
The claim that there are closed source kernel drivers is untrue for most mainstream Android devices and is a misunderstanding of why devices stick to a specific LTS kernel branch. Those branches receive 6 years of support now because of the model that's used for mainstream embedded / mobile devices. They don't want to port their drivers to newer versions and spend a year getting it working robustly again. It would be entirely possible to do it and it's possible it will happen for Tensor but it can be an overall bad thing for security instead of a good one due to all the added attack surface. A great example is how a bunch of recent vulnerabilities such as 'Dirty Pipe' only impacted the Pixel 6 due to it using the 5.10 LTS branch which was the newest at the time. A Qualcomm device wouldn't have been impacted due to having an older kernel branch.
It is baffling to me that Apple still hasn't implemented this feature even on their top end "Pro" iPhones... but this feature by itself isn't enough for me to switch to Android full time.
The downsides of larger batteries are increased weight, volume, and cost. Being more efficient gets the same battery life for less of those three, allowing them to either be reduced or the budget to go to other components.
Our perspective is that this has been made immensely harder by the dozens of 'secure' phone companies providing something far worse than iPhones and Pixels. Most of those aren't presented as being 'open hardware' that's not at all open hardware, but they do share a lot in common. A few of them were so bad that they were actually law enforcement stings from the beginning (https://en.wikipedia.org/wiki/ANOM) or turned into them (https://en.wikipedia.org/wiki/EncroChat) which is amusing.
We'd happily target iPhones but Pixels are the only smartphones providing proper alternate OS support. On Pixels we get to have full verified boot covering all the OS images with downgrade protection, very nicely designed hardware attestation, all the hardware keystore capabilities, the disk encryption key derivation throttling feature with insider attack resistance, A/B updates for the firmware/OS, etc. This is the stuff we expect other vendors to provide us with in order to support their phones. Vendors using a flagship Qualcomm SoC, including the alternate OS verified boot / attestation support and doing a good job with security work themselves come close, but we need more than that. There's a fair bit missing without vendors caring enough to go above and beyond with security and alternate OS support.
When we look at the Librem 5, what we see is rolling back privacy/security massively on the hardware, firmware and software levels with no possible way we could support it. We were actually in contact with them at one point but it became clear that they had zero interest in anything more than an empty partnership where out name would be used for marketing without us being able to use the device at all. That was back before lots of the security improvements in the Android smartphone world where Pixels caught up and even surpassed iPhone security in most areas.
Our expectations used to be far lower, and they get higher as devices like iPhones/Pixels get better. For example, Weaver showed up with the Pixel 2, as did the related secure element insider attack resistance where the main owner user has to authenticate for firmware updates to be applied. Before then, the SEP was way ahead in this area, and continued to be ahead in a lot of others until the Titan M. Weaver provides always enabled aggressive throttling for disk encryption key derivation attempts, with full support for the separate per-user encryption keys. It quickly throttles up to 1 day per attempt after 140 failed attempts. We take it for granted that we get all this stuff including the hardware keystore with physical confirmation support, etc. We expect these features from other vendors. It's not a lot to ask that they implement a feature like Weaver which was introduced with the Pixel 2 via open source AOSP code for the OS integration and open source secure element applets for an off-the-shelf Java smartcard secure element. That got obsoleted by the Titan M, which is actually well on the way to becoming open source with OpenTitan and the Pixel 6 shipping a RISC-V implementation of it based on that. It would be great for that to be fully open sourced and usable by other vendors. That's the kind of thing which is exciting in this area. Pixel 6 using Trusty OS for TrustZone isn't that compelling since TrustZone is terrible and largely obsolete beyond being the component responsible for talking to the actual secure element via authenticated encryption. They're also on the path to getting rid of it now that there's proper virtualization support, which is where the nonsense like Widevine is moving to be properly unprivileged/isolated unlike the mess of TrustZone.
It would be great if other vendors actually cared more and tried to actually compete with iPhone and Pixel security. We found a vendor that's willing to put in the effort, and we're optimistic about that. We're more than happy to work with others. The main thing we need to do is point them at what they need to implemented and the existing open source AOSP code for the OS side of it, etc. We have a lot of experience with this including reporting a bunch of firmware vulnerabilities / bugs in Pixels. There are so many things which could be done better but it starts with any other vendor catching up to where iPhones / Pixels where years ago.
Not months worth of battery saving like an eInk screen maybe but still enough to be insignificant compared to general "screen off" battery consumption.
My Nokia was getting 8 days before I started putting all the apps on it. The more apps I added, the worse it got.
Nowadays I generally restrict apps from running anything in the background/sync'ing etc etc if I can.
I am happy to wait a few seconds for email to sync when I open the app rather than have my phone beep at me for every new email...
Platform Model Life Size Efficiency
iOS Apple iPhone 13 Pro Max 21.7 4352 4.98
iOS Apple iPhone 13 16.8 3227 5.21
iOS Apple iPhone 13 Pro 16.6 3095 5.37
Android ASUS ROG Phone 5 16.6 6000 2.77
Android ASUS ROG Phone III 16.5 6000 2.75
Android ASUS ROG Phone II 16.2 6000 2.7
Android Samsung Galaxy S21 Ultra (S888) 15.9 5000 3.18
iOS Apple iPhone 11 Pro Max 15.6 3969 3.93
At this point, fliphones are very tempting.
I did order a Mycroft Mark II though, so I feel the pain.
It's almost as if they deliberately added this seemingly bad option so people would choose the most expensive option iPhone 13 Pro Max. Because it would seem like the best deal out of three. I mean the Pro Max is just $100 more expensive than Pro, right?
But remove this decoy option, and most people would just buy the iPhone 13.
The point was that it's reasonable to expect the battery life of plasma OS and friends to be comparable to Android, similar to how Linux on a laptop is comparable to Windows.
[1] https://sxmo.org
> On the iPhone 13 series, there’s a few complex behaviours to consider: First off, the iPhone 13 Pro and its LTPO panel noticeable decreases the minimum baseline power consumption of the phone by around a massive 100mW… While 100mW doesn’t sound much, when using the phones at lower screen brightness, this can represent a large percentage of the overall device power consumption, and vastly increase battery life for the new iPhone 13 Pro models.
> Comparing the 13 to the 13 Pro, the phones have quite different curves – while the 13 Pro uses less power to display full white up until 140 nits, the regular 13 becomes more efficient afterwards. We’re also seeing different curve shapes, meaning the phones are driven differently in regards to their PWM and emitter voltages.
The Pro phones are more battery efficient than the regular ones, and probably use the extra space gained with a slightly smaller battery for some other featureful hardware (cameras?).
The trade offs made seem to be reasonable for a Pro that’s between the regular and the Pro Max. It doesn’t seem to me like just a decoy.
The $100 is irrelevant to the target market of the Pro line, it's basically pocket change. You buy the phone that's most comfortable for your hand because that matters way more than the $100.
Sadly I cannot confirm this for my 6+ different laptops I owned. And I tried all the crazy settings, grub, tlp, .. and even compiling the kernel myself.
It is hard to beat loads of dedicated engineers, who are paid regular and well and have access to all the proprietary device information and even manufacturing.
edit: maybe there was one time, when a linux stock install performed maybe equally than a stock windows install. But that was only because of the windows bloat, which linux does not ship. But I can easily remove most of the bloat, but I cannot just write a better gpu driver. But if windows continues its bloat path, it will be soon inferior despite way better drivers.
I remember being able to run Ubuntu in the background on an unrooted Android phone while browsing the Internet. You can’t do that with iPhone.
That said, I rather have battery predictability over features, but I always thought that if Android dropped background apps, they would have the same battery usage as an iPhone.
Android has great battery life, spyware doesn't ;-).
[1] 100% doesn't mean that the battery is fully charged, it means that the detected level is what the charger is prepared to go to. To conserve battery life it is not uncommon to have a 100% indicator when the battery is only 90% charged, and a 10% indicator when the battery is only 20% charged.
Circuits on packets on circuits on packets is a problematic thing, I guess?
I don’t really want SMS, MMS, or raw calls if I can use email, IM, and VoIP.
Even in iOS the VoIP clients are pretty thin on the ground. Bria is still the best one? It feels like “wifi calling” is probably VoIP but it without the ability to change your sip provider. Argh!
I get two days of intensive use from my old Huawei P30 Pro.
I know that, but Librem it's still too rough for me. I hope it will get better in the next iterations and I applaud those who buy it now, knowing they are also funding R&D for better future phones.
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...
In the case if my fairly new laptop battery they said it "adjusts" and gets better after a while. I'm not sure if it's true and how much better it actually gets.
https://forums.digitalspy.com/discussion/2128704/do-new-batt...
It would reduce the complexity and price. I can’t recall the last time I really needed to make or take a “phone” call. That shit’s legacy now.
Just give me all the messaging apps and a good browser. Perhaps a clamshell design with a physical keyboard.
Both of these figures are way better than they were a year ago, back then I managed to get 8 to 9 hours with WiFi off.
There’s work happening to make suspending the phone an option (that’s how the less efficient PinePhone, that’s equipped with a smaller battery manages to deliver better battery life).
Delivering all the messaging apps on a GNU/Linux device seems like a difficult task though, from what I’ve gathered about apps that others and I tested [0].
It would become very easy if they realized that a lot of users who buy a Linux phone would probably be happy to trade thinness for battery life.
I’d even go as far as saying that even with Apple’s efficiency and all, I’d still prefer it if they had bigger batteries.
And those are a lot thicker. Maybe Librem should not try to compete with Android and iOS at all in terms of design and just go for “privacy by default” as their campaign. (If they ever sort out delivery problems)
A nice by-effect will be that whatever tricks come out of the bag will almost equally be viable to boost the battery life on laptops.
But I agree, Librem does look a bit raw to me. I'm ok with 'apt get'ting stuff on my PC. Not on a phone
I worked on an embedded system with an Allwinner chipset. We tried to reduce power consumption, not to save battery since it was a cabled system, but to reduce heat. It turns out nobody, not Allwinner who provided the BSP, not the board designer, nor the final customer who developed the application software cared to optimize the OS much. The CPU had four cores, but only one was occupied most of the time. But all cores were at 100% frequency. Configurable voltages were also all on the upper edge. I enabled frequency scaling, switched to the correct scheduler, and now the board was much cooler and ran with more than twice the performance.
I'm always surprized how many low-hanging fruit there are in these kind of systems.
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.
So the Linux kernel may support the Librem 5 for life, but what’s even the point of all that effort if the phone is just going to irrevocably die on you after a couple of years?
You may want to keep that in mind before you buy one. I ordered a Librem 5 last year but got aware of the issue only recently.
I absolutely love Calyx, and wouldn't move from it. However, the battery life even compared to my old iPhone 6S is pretty bad. I'm not even a heavy phone user, I don't use social media or have many apps sending me notifications (only Signal) and I feel like my phone can't even last two days of light usage. My iPhone I could use similary and I could usually get 3 days of usage.
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.
It's actually the opposite - most modern (especially flagship) phones don't really last more than a day (and here day isn't even 24 hours, but more like 16 hours). It was a massive deal when Apple finally increased the battery life of their iPhones with iPhone 13 series so it can outlast a day of normal use.
There's some difference in mid-range market though - since people buying cheaper phones tend to value battery life, you can get mid-range Android phones with downright massive batteries. Especially in Asia.
Except if Purism opens a store in Europe. And they intend to (not that there is a big progress currently).
GrapheneOS is a secure option as well as ios. But security doesn’t come for free and not a binary thing.
We do exchange "freedom" (whatever vague definition of it) for security and convenience a lot. Even without realizing it.
Unfortunately trusting developers to use those allowances wisely did not pan out.
Yes, they are: https://puri.sm/security and https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque....
Not a major handset maker and not Android, but https://www.crowdsupply.com/sutajio-kosagi/precursor. Also, not state-of-the-art, too.
But basically, it is not secure neither on a hardware front, neither on software. The latter runs everything as the same user so a rouge bash script can encrypt your whole photo gallery, exfiltrate any data, etc.
Security can be many things for different people. Preventing criminals from abusing vulnerabilities in software is one kind of security. Preventing companies from black/grey hack patterns is an other. Making people feel less icky from ubiquitous tracking is one. Stopping advertisements from wasting peoples time and preventing planned e-waste is additional ones.
Maybe we need to invent a new word for security. Something about making people feel safe and preventing actions that would harm them.
Specifically: While iPhones are noticeably more power efficient than Android phones the latter have been sufficient for my usecases especially given that there are typically options with larger batteries.
As for Xiaomi being comically large, I found the mid-range Samsung and Motorola models to have larger bezels and to generally be larger for similar specs when I bought my Xiaomi Redmi Note 7 a couple years ago. The reality is that the majority of phones from Motorola, Xiaomi, LG and Nokia are designed and manufactured by 3 Chinese ODMs (Wingtech, Huaquin and Longcheer), and even 20% of Samsung's phones come from these 3 ODMs. See: https://amosbbatto.wordpress.com/2021/12/10/comparing-l5-and...
This could be the greatest phone ever made, but if it doesn't last a full day, it's worse than every other phone I've owned, or will own.
I own both the PinePhone and Librem 5 USA, and I'm seriously impressed by the amount of work the Purism devs do for PinePhone users (who are the majority of the Phosh users).
I mean...without any metrics (from you or the parent) the statement is pretty hollow and doesn't mean anything.
I would disagree with 'has to be comfortable to use' as that is often at odds with 'secure'. Some of the things I do to secure my system make infrequently done/high risk things quite uncomfortable to use. Not because I wanted to make it uncomfortable, but because that's what it took to get the level of security I desired.
[1] I would also argue that spending too much effort here before addressing other attack vectors first is rather silly. (i.e. web browser, network, minimizing usage of/isolating 3rd party binaries)
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.
I also have an L5 sitting on my desk that I am using full time, and have had it for several months by now.
It sounds like Librem and Pine, if they haven’t already, should do the same and create a battery life optimization team, responsible for coordinating that effort across hardware, software, internal teams, and external volunteers.
In absence of that, even an anecdotal comparison seems more relevant than a statement that only considers one of the two items being compared.
Update: Because I was curious whether my subjective experience was backed by real numbers, I looked up the top few Android and iPhones with the greatest battery life as per the first website I found [1] and calculated their efficiency based on their battery capacity. Various iPhone 13 models used 3.1 to 3.6 mAh per minute whereas the Android phones used 4.0 mAh/min (Moto G9 Power), 4.2 mAh/min (Samsung Galaxy A03s, Realme 9 Pro), 4.3 mAh/min (Nokia G21).
[1] https://www.techrankup.com/en/smartphones-battery-life-ranki...
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.
You're saying that as if the firewall handled the communication with the modem. There's a Linux driver behind the firewall to do the actual communication, except that's probably not a USB driver.
The attack area is probably comparable, except a misconfigured USB driver doesn't automatically give full memory access, while a misconfigured IOMMU (the firewall) does.
The problem is that the Android app ecosystem has a very large number of apps which are based on collecting users' personal information and violating people's privacy, and it is hard for a normal user to avoid all the spyware and malware in Android. In my experience using CyanogenMod/LineageOS and the F-Droid repo since 2015, I inevitably fall back to installing some proprietary apps when using AOSP-derivatives, whereas my PinePhone and Librem 5 USA only have FOSS apps and drivers installed on them. If the goal is to use FOSS as much as possible, you are better off buying a Linux phone in my opinion.
By the way, one of the apps that I helped develop is on F-Droid (https://f-droid.org/en/packages/com.ketanolab.nusimi/ ) and I have given workshops on how to install LineageOS on phones, so I speak as someone who tries to promote the use of FOSS on Android phones, but the phone industry does put up a lot of barriers to make it difficult to install AOSP-derivatives.
> GrapheneOS only supports devices with proper security support for all the firmware, drivers, etc. and again there are no closed source kernel drivers. We can support pretty much any mobile device with alternate OS support since any serious one will have AOSP support. Most devices have lackluster security and don't meet our requirements.
The problem is that Google only sells Pixels in a very limited number of countries. Whereas Purism offers free worldwide shipping for the Librem 5, the Pixel 6 is only being sold in 8 countries (Australia, Canada, France, Germany, Japan, Taiwan, UK, USA), so your security requirements exclude over 90% of the world's population from being able to use GrapheneOS. Plus, many people don't want to financially support a company like Google which is based on Surveillance Capitalism.
> We're working with a hardware vendor to get a non-Pixel phone actually meeting reasonable security requirements.
Good to hear. I look forward to seeing it.
> Librem 5 has a bunch of components where they are not shipping updates.
Not true. Purism has promised to provide updates to the proprietary firmware on the Librem 5, and already provides instructions for how to update the firmware on the WiFi/BT and USB controller. See: https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque...
> It has a bunch of poorly secured and insecurely configured legacy hardware often without proper updates available
What are you talking about? Purism purposely designed the Librem 5 to avoid planned obsolescence, so it looked for component suppliers who support their hardware for a long time. For example, NXP guarantees that that it will provide updates for the i.MX 8M Quad for 15 years (Jan. 2018 - Jan. 2033). See: https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque...
In contrast, Google only promises to provide 3 years of OS updates and security updates for the Pixel 3/4/5, and 3 years of OS updates and 5 years of security updates for the Pixel 6. Qualcomm announced in Dec. 2020 that it will support its Snapdragon processors (which are used in Pixel devices) for 3 years of Android updates and 4 years of security updates.
Linux phones like the Librem 5 and PinePhone use separate components which are supported for many years by the manufacturers, whereas most Android phones (like the Pixels) use integrated mobile system-on-chips which are only manufactured for 1-2 years and only supported for 3-4 years by the manufacturer. Because Linux phones use components with long-term support by the component suppliers, the Librem 5 is the first phone to be sold with the guarantee of lifetime software updates, and PINE64 promised to manufacture the PinePhone for 5 years, which is longer than any other smartphone ever sold.
> components that are not properly isolated via IOMMU,
The Librem 5 doesn't need an IOMMU, because it uses separated components, and it uses serial buses (USB 2.0/3.0, SDIO, I2C and I2S) that don't allow direct memory access, so there is absolute no chance of the WiFi/BT, cellular modem, GNSS and USB controller being able to access the RAM or the SoC's cache. Unlike the Snapdragon processors in Pixels whose hardware is essentially a black box, we can independently verify by looking at the open source schematics that direct memory access is not possible in the Librem 5.
> but there are years and years of tons of important privacy/security work done in a systemic way across hardware/firmware/software which are missing there before worrying about stuff like that.
If you are talking about kernel hardening and running each app in its own sandbox with its own UID, then I would agree that Android/AOSP has more security features than Debian/PureOS, but the problem with your argument is that you are ignoring the fact that a mountain of spyware and malware has been created for the Android platform and users have to be very vigilant to not install any of it. According to AV-TEST, 3.38M pieces of malware and 3.18M potentially unwanted apps (mostly spyware) were created for the Android platform in 2021, whereas it is unlikely that any of that garbage will get into the Debian->PureOS repos to ever effect users of the Librem 5. Linux users rarely install anything from outside their distro's repo, whereas I often find myself installing apps whose code I can't verify when I use AOSP-derivatives because I can't find all the apps that I need in F-Droid.
Yes, Android/AOSP does have a lot more security built into its design than Debian->PureOS, but it is based on a model of letting all sorts of unverifiable and dangerous code run inside it. For more on the Librem 5's security, see: https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque...
> Marketing something as private/secure and spreading tons of misinformation and outright lies about the mainstream options
Care to provide any evidence to prove that Purism or its employees are "spreading tons of misinformation and outright lies about the mainstream options"?
> It's also the only phone with a FLOSS OpenPGP card .
It has no such thing (there is no open source secure element available aside from OpenTitan, although Trezor is working on one too) and it isn't an alternative to a proper secure element used by apps via the standard AOSP hardware keystore API (StrongBox keystore) and integrated into the rest of the hardware/firmware/OS for verified boot, attestation, throttling disk encryption key derivation attempts, insider attack resistance (only allowing signed firmware updates after owner account authentication) and the other features that are provided.
> 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.
They dont say how many they are producing, nor how big their backlog is, nor how long it will be until they catch up, etc.
Pay us now and ONE DAY in the next few years we may deliver... who knows?
I also have to agree with you on the “one can make it secure” part, e.g. android builds on top of pretty standard linux tools to achieve its better security, namely selinux for a larger boundary and the most important: running different processes as different users! It is such a gaping security issue in typical DEs, as otherwise not even the very crude UNIX permission system can do anything meaningful (other than the relevant xckcd comic: the attacker can access all my files, my browser cache, etc, but at least can’t install a video driver)
The Librem 5 doesn't have one driver exposed to the baseband. It has every single USB driver in the kernel exposed to it, because the baseband can present any descriptors it feels like and engage whatever driver it wants, or a combination thereof by presenting itself as a composite USB device, since USB is plug&play. That is a massively larger attack surface. All you have to do is find one exploitable bug in any USB driver in Linux, and you're in.
This can be mitigated with USB descriptor filtering, but the Librem 5 guys haven't implemented that yet, because they don't actually care about security. So while their marketing department is lying about DMA access for the competition (heck, as far as I know no iPhone gas ever given the baseband unchecked DMA access to the system, but Purism claims they all do!), their engineering department can't even bother to lock down the attack surface of the baseband to something smaller than "every single USB driver in the kernel".
Also, for what it's worth, the Librem 5 doesn't even have an IOMMU at all. They can't even use the PCIe ports in their SoC because that would give whatever you plug into them full DMA to the system. This also means that driver bugs that result in bad DMA descriptors for embedded SoC devices will directly escalate to full memory access; there is no safeguard by having to engage the IOMMU subsystem first to map them.
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.
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.
They don't run regular Android though, with Google Play, just the open source version with some Chinese marketplace. I have followed one (now dead) e-ink phone on indiegogo (forgot the name, sorry), and they wrote that Google does not let (black-and-white) e-ink smartphones pass Android certification, because they cannot correctly display the colors in their apps. So they will never run Google Play, and there will never be just e-ink phone with built-in regular Android and Google Play, sadly.
There is a hacky way to get Google Play on the hisense phones, but... ugh. That's too much hackiness for me.
It would be nice to be able to reliably run background apps on Android.
Also as an aside Android doesn't appear to reliably kill background processes, it kills them if it thinks that something else needs the resources. Running the Facebook app is one way of triggering Android to kill a bunch of background apps.
The Purism CSO has been running a Librem 5 as his primary desktop PC for over a year.
When Plasma was first released I was probably running hardware slower than a Librem 5.
Librem 5 does not lock the firmwares in any kind of ROM. Nothing is taken away from the user.
> 200 ppi black and white LCD (336 x 536 resolution), 100% inspectable with standard optical microscope
Can you do it with your so much advertised phones? Oh, you "trust" large manufacturers. Good luck with that.
Where is the secure element? Where is the pointer authentication? Where is the secure boot?
>no proprietary chips
The device uses a Xilinx XC7S50 which is proprietary.
>Oh, you "trust" large manufacturers.
Yes, I do trust large manufacturers. The probability that someone makse you a custom phone to compromise you is practically 0%. The chance they do it via a visible hardware change as opposed to a software change is 0%. If you are that paranoid why not worry about trusting Xilinix in producing a custom bitstream when it sees you trying to synthesize this chip. Fortunately reality is more boring and these companies aren't out to get you.
Since you're doing that yourself, I don't think engaging with you on the topic is productive. I responded here due to the inaccurate attacks on GrapheneOS from people promoting Purism products. Doubling down on spreading their inaccurate marketing / talking points isn't going to deter us from responding and we're more than happy to post a more detailed response on our site and across platforms. I already gave detailed responses and don't intend to repeat much of what I've already said.
> The problem is that the Android app ecosystem has a very large number of apps which are based on collecting users' personal information and violating people's privacy, and it is hard for a normal user to avoid all the spyware and malware in Android. In my experience using CyanogenMod/LineageOS and the F-Droid repo since 2015, I inevitably fall back to installing some proprietary apps when using AOSP-derivatives, whereas my PinePhone and Librem 5 USA only have FOSS apps and drivers installed on them. If the goal is to use FOSS as much as possible, you are better off buying a Linux phone in my opinion.
There's a far larger and better ecosystem of open source apps for Android than there is for the products that you're marketing, and they can be used on secure devices rather than blatantly insecure ones not even meeting basic standards as I've already detailed in my responses.
> The problem is that Google only sells Pixels in a very limited number of countries. Whereas Purism offers free worldwide shipping for the Librem 5, the Pixel 6 is only being sold in 8 countries (Australia, Canada, France, Germany, Japan, Taiwan, UK, USA), so your security requirements exclude over 90% of the world's population from being able to use GrapheneOS. Plus, many people don't want to financially support a company like Google which is based on Surveillance Capitalism.
Pixels can be purchased internationally. They don't need to be bought from Google. Purism is a company based around spreading misinformation and marketing their products dishonestly which I know people in our community don't want to support. We're not going to support thoroughly insecure devices from a company which is unwilling to even admit to the limitations/weaknesses let alone fixing them and producing something we could ever consider supporting. The experience we had with them is that they only want to use the name of projects like ours to promote themselves as partners without doing anything on their part. They engaged in libel/harassment/bullying targeting our developers in response to us not supporting their phone as a target and explaining why within our community. I see what you're doing here as an extension of their dishonest marketing and inaccurate attacks on other platforms/projects/products. If this is going to be something that's happening regularly, we'll add detailed documentation / articles to our site about the topic to reference so we don't need to keep writing up the same things.
> Not true. Purism has promised to provide updates to the proprietary firmware on the Librem 5, and already provides instructions for how to update the firmware on the WiFi/BT and USB controller.
There aren't full firmware security updates for the Librem 5 and what I said is completely accurate. What's even worse is that they do not ship the incomplete updates that could be available and they did things in a way that makes it impossible to even ship all of those as part of an OS. Please don't claim that my completely accurate description of the situation is not true based on something that's not in any way debunking what I said.
> What are you talking about? Purism purposely designed the Librem 5 to avoid planned obsolescence, so it looked for component suppliers who support their hardware for a long time. For example, NXP guarantees that that it will provide updates for the i.MX 8M Quad for 15 years (Jan. 2018 - Jan. 2033).
They're unable to provide full security updates from day one and the device is already end-of-life in terms of what that means for GrapheneOS. It would have to be marked as end-of-life from day one if we added support for it. We would be unable to declare any Android security patch level for the device due to it not meeting the basic security requirements and not having full firmware security updates available. What I've said is true, and you're just claiming otherwise based on their deliberately very incomplete and misleading marketing.
> In contrast, Google only promises to provide 3 years of OS updates and security updates for the Pixel 3/4/5, and 3 years of OS updates and 5 years of security updates for the Pixel 6. Qualcomm announced in Dec. 2020 that it will support its Snapdragon processors (which are used in Pixel devices) for 3 years of Android updates and 4 years of security updates.
Those are minimum guarantees of full security updates, not end-of-life dates and the number of days you get those for the Librem 5 is ZERO. The only recommended devices for GrapheneOS are the Pixel 6 and Pixel 6 Pro, which means that there is at least 5 years of full security updates for the devices we support. You can see from our site that we continue providing extended support releases which we mark as insecure past the end-of-life of devices. A device is end-of-life as soon as any important component no longer provides the proper monthly security updates. How can we support the Librem 5 even aside from all the missing security features which have already been explained elsewhere, when we would be unable to provide anything close to the March 2022 security update, and would be unable to ship all the updates that are available through the OS?
> Linux phones like the Librem 5 and PinePhone use separate components which are supported for many years by the manufacturers, whereas most Android phones (like the Pixels) use integrated mobile system-on-chips which are only manufactured for 1-2 years and only supported for 3-4 years by the manufacturer. Because Linux phones use components with long-term support by the component suppliers, the Librem 5 is the first phone to be sold with the guarantee of lifetime software updates, and PINE64 promised to manufacture the PinePhone for 5 years, which is longer than any other smartphone ever sold.
This is completely inaccurate. They still use an SoC and the components they've chosen do not provide a longer period of support in the sense that Android expects in order to declare the latest security patch level. Several of their component choices including the radios rule that out, as does the way they are integrated. Your claim of lifetime security updates is completely bogus and demonstrates the extreme lengths Purism goes to in order to mislead people and profit from it. They still need firmware support and all the drivers, etc. still need to be maintained. There's really no point of engaging with people lying through their teeth and pushing all their inaccurate talking points so I'm not going to keep engaging with you much further.
Linux doesn't mean systemd, polkit, glibc, GCC, binutils, GNOME, pulseaudio/pipewire, Wayland/X11, etc. It makes no sense to claim these are Linux phones when the vast majority of smartphones run Linux. It's marketing spin. If you want to call it a GNU/Linux phone, go ahead, but what you're doing is a deliberate attempt at misleading people on their part.
> The Librem 5 doesn't need an IOMMU, because it uses separated components, and it uses serial buses (USB 2.0/3.0, SDIO, I2C and I2S) that don't allow direct memory access, so there is absolute no chance of the WiFi/BT, cellular modem, GNSS and USB controller being able to access the RAM or the SoC's cache. Unlike the Snapdragon processors in Pixels whose hardware is essentially a black box, we can independently verify by looking at the open source schematics that direct memory access is not possible in the Librem 5.
This is not accurate. It still has an SoC with a ton of components aside from the SoC despite your inaccurate claim that it doesn't, and those components still need to be isolated with an IOMMU. The other components which you're talking about using USB are dramatically less isolated than the Qualcomm or Samsung baseband on mainstream devices. You're trying to present something dramatically worse as being better in this regard. Are you trying to claim that the Librem 5 doesn't have components like a GPU and other SoC components? The Librem 5 hardware is also just as much of a black box. It's 100% as proprietary. It does not have firmware or hardware that's any more open and this is a blatant lie. Them marketing the hardware as being more open is thoroughly unethically and dishonest. They've done the same with their laptops and other products, which has done immense harm to projects like Talos actually trying to produce open hardware in any actual sense of the word.
Many other people promoting these platforms often talk about the (limited) support for running Android apps. You can choose to use those apps there, just as you can on GrapheneOS, and it does not make sense to claim that availability of apps is a bad thing. GrapheneOS supports nearly every Android app which would run on the stock OS thanks to the sandboxed Google Play compatibility layer feature. Many of our users including make no use of that feature, and it didn't exist before 2021 so our entire userbase before then was happily using it without Play services. There are more users now, but there were still many before, and many are happy using only the open source Android app ecosystem which goes far beyond F-Droid which doesn't even have apps like Signal, Chromium, Brave, Bromite, etc.
You're trying to make this about AOSP vs. a completely insecure software stack but the post is about a phone which is capable of running AOSP and other phones are more than capable of running the desktop Linux stack. It's a red herring, and you're being thoroughly dishonest and manipulative in how you're presenting the app ecosystem considering that there is a far larger open source app ecosystem for AOSP than there is for desktop Linux on mobile... F-Droid has very incomplete coverage of the overall open source app ecosystem and they don't always do a particularly good job maintaining it. F-Droid itself still targets Android 7.1 (API 25).
I'm talking about the fact that this hardware, firmware and software is a decade behind on security and has almost zero systemic privacy/security work across it. You have the privacy and security situation completely backwards. The fact that Purism blatantly lies about many aspects of their hardware, firmware and software also demonstrates that they're a highly untrustworthy vendor. I would trust a company like HTC far more because at least they aren't blatantly lying about the security patch level, openness of the hardware and they aren't covering up security vulnerabilities, weaknesses and the fact that the firmware/hardware is proprietary.
> Yes, Android/AOSP does have a lot more security built into its design than Debian->PureOS, but it is based on a model of letting all sorts of unverifiable and dangerous code run inside it.
I'm not sure why someone would want to place complete trust in thousands of different fragmented projects which have no real isolation and no systemic privacy/security work on the overall OS or across those projects. Many of those projects are unmaintained, and some of them have even shipping malicious changes either unintentionally or intentionally before. You're also trusting the huge amount of packagers for the OS who set up the builds and patches for these projects. There are still closed source apps availability, but open source is not the magical panacea that you present it as and does not infer any inherent privacy/security properties on the software. It doesn't make the developers inherently more trustworthy or ethical either. It's a development approach, which we can both agree is a great approach and enables people to make changes to the software, fork it or attempt to contribute to it upstream.
> Care to provide any evidence to prove that Purism or its employees are "spreading tons of misinformation and outright lies about the mainstream options"?
You've done a great job of doing that yourself by cycling through a whole bunch of inaccurate talking points promoting their products and attacking other projects like GrapheneOS. Most of it comes directly from Purism, and your comment is an extension of their highly underhanded, dishonest and malicious attacks on projects like GrapheneOS to make sure they keep getting their substantial salaries and profit.
At the moment, I'm not currently interested in investing the necessary time into writing such as an article. If you're going to post another lengthy problematic reply, that's the medium I'm going to use for my response rather than writing another comment on this platform which few people are going to see, which is not a good use of my time.
As stated earlier, there are no closed source kernel drivers for AOSP, GrapheneOS or even most mainstream Android devices running the stock OS.
The reason for using an LTS kernel branch with 6 years of support from kernel.org is stability. Porting forward the drivers to each new kernel release is entirely possible and isn't a lot of work when it's done incrementally. Not that many changes are even required. The issue is that there are substantial regressions in each Linux kernel release and it takes at least 4 months or more to get a production quality kernel for a specific hardware target with nothing break, the massive CTS/ITS/VTS passing, etc. Pixel 6 uses the Linux 5.10 kernel branch which was the latest at the time, and those LTS branches have 6 years of support from kernel.org and expanded support with more bug fixes / security enhancements / other improvements via the AOSP common/generic kernel. It's entirely possible to move to a newer LTS branch. There are no closed source kernel drivers. Is it worth the time, when newer LTS branches have substantially more attack surface and tons of regressions that are going to need to be detected/fixed? Bear in mind it would not expand the lifetime of devices at the moment, time several hardware components won't receive more than 6 years of firmware support.
There are already people who have gotten the mainline 5.15 kernel working with the Pixel 6, but from 5.10 to 5.15 there are a lot of regressions, and there's a lot of new attack surface. There's a reason that ONLY the Pixel 6 among the Pixel family has been vulnerable to several serious core Linux kernel vulnerabilities disclosed in the past few months including the branded dirty pipe vulnerability. There are both advantages and disadvantages to using a newer LTS branch. Unfortunately, one of the disadvantages is that there are more bugs overall, including more vulnerabilities overall. Many software projects mature over time and the rate of finding vulnerabilities goes down. That's not the case for the Linux kernel. It's having vulnerabilities introduced at a faster pace than they're fixed. It isn't better from a security perspective to use the 5.15 LTS rather than the 5.10 LTS, especially with the additional changes backported by AOSP including security enhancements like mitigations, not just bug fixes. It may be a good idea to move to the new LTS branch once it has matured for 1-2 years, but definitely not months after release.
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.
(To be fair, I ran LineageOS without Google Play Services installed, which makes a huge difference, so it's not exactly apples to apples.)
Not OP but I did enjoy reading your well-written replies, so I hope they don't get lost with time as only HN comments, and that you're able to carry them forward more effectively to be shared with others.
I'm quite fine knowing the HW well enough to trust it for my purposes, having spent many years with it at quite low levels, thank you.
I was simply following the standard convention of saying "Linux" to mean the entire OS that is found in popular distros like Debian, Arch and Fedora, whereas people generally say "Linux kernel" to refer to just the kernel. Saying "GNU/Linux" is problematic because most distros contain software which isn't part of GNU and isn't approved by the FSF, but I will use that term for lack of a better one.
By the way, it is just as problematic to say that GrapheneOS is "Linux" because GrapheneOS is using a kernel which has been substantially modified by Google, and Qualcomm's drivers for the Snapdragon which GrapheneOS uses are only designed to support an Android kernel, not a mainline Linux kernel. GrapheneOS doesn't use mainline Linux kernels and it usually takes 3-4 years for the mainline kernel to fully support new Snapdragons after they are released, so I don't know why you are even bothering to make this argument.
> There's a far larger and better ecosystem of open source apps for Android than there is for the products that you're marketing...
Just to be clear, I'm simply a customer of Purism and PINE64 who owns the Librem 5 USA and PinePhone, so I don't represent these companies and I'm not marketing their products.
I'm not sure whether there is a larger ecosystem of open source apps for Android rather than the GNU/Linux distros that run on the Librem 5 and PinePhone. If we are talking about apps which are designed to run on mobile phones, then you have a point, since it will take a while to adapt all the desktop software to be mobile-friendly, but Kirigami or libhandy/libadwaita is getting added to a lot GNU/Linux desktop software to make it adaptive. Google purposely does not label software with FOSS licenses in the Play Store, so it is hard to count the number of FOSS apps for Android. I count 4472 apps in F-Droid (https://f-droid.org/repo/index-v1.jar), whereas Debian 11 "bullseye" (which is what PureOS and Mobian are based on) has 59,551 packages. I know that not all FOSS apps make it into the F-Droid repo and the Debian repo includges the entire operating system and many of its applications use multiple packages, so we are comparing apples and oranges, but I don't see much evidence that the Android FOSS ecosystem is "larger and better" than the GNU/Linux ecosystem.
I often find that I need to install proprietary apps when using LineageOS because I can't find what I need in F-Droid, whereas I generally don't install proprietary apps in my GNU/Linux systems, so from that point of view, GNU/LInux is "better". Also a sizeable number of the FOSS apps that I encounter in F-Droid contain some code which was originally written for GNU/Linux, whereas I rarely find code in GNU/Linux which was originally written for Android.
> This is not accurate. It still has an SoC with a ton of components aside from the SoC despite your inaccurate claim that it doesn't, and those components still need to be isolated with an IOMMU.
I stated that "the Librem 5 doesn't need an IOMMU" to isolate the WiFi/BT, cellular modem, GNSS and USB controller, but in case you are worried, the i.MX 8M Quad SoC in the Librem 5 does have a Resource Domain Controller (RDC), Arm TrustZone and On-chip RAM (OCRAM) secure region protection, which does isolate the CPU, GPU and VPU. See section "3.2.2.4 Resource Domain Control and Security Considerations" in the "i.MX 8M Dual/8M QuadLite/8M Quad Applications Processors Reference Manual". (NXP requires registration to download the manual.)
> Those are minimum guarantees of full security updates, not end-of-life dates and the number of days you get those for the Librem 5 is ZERO. The only recommended devices for GrapheneOS are the Pixel 6 and Pixel 6 Pro, which means that there is at least 5 years of full security updates for the devices we support.
The GrapheneOS FAQ lists the Pixel 3a released in May 2019 as a "supported" device, but the Pixel 3 released in October 2018 is listed as "end-of-life" because it no longer gets full security updates, so that tells me that most people are using GrapheneOS on devices that have a 3 year lifespan.
I downloaded the Pixel 3a's "bonito" kernel (https://github.com/GrapheneOS/device_google_bonito-kernel) and I see that it is using kernel version 4.9.292. Mainline Linux 4.9.292 was released on 2021-12-08 and 4.9.0 was released on 2016-12-11. Call me crazy but I prefer to use an up-to-date mainline kernel rather than one that is over 5 years old and takes 3 months to get the latest security patches from kernel.org. (To be fair, I should mention that the Librem 5 issn't yet fully supported in mainline Linux, so you can't run the latest mainline kernel on day one of its release, but the Purism devs say that mainline support is coming.)
> Your claim of lifetime security updates is completely bogus and demonstrates the extreme lengths Purism goes to in order to mislead people and profit from it.
Purism says that it went way over-budget trying to develop the Librem 5 and its software, which is why it has been raising its prices. Considering the roughly 20 companies that lost their shirts in the past when trying to develop mobile Linux, it is unrealistic to think that Purism is doing this for profit. (See: https://amosbbatto.wordpress.com/2020/07/17/mobile-linux-tra...)
Granted that NXP will stop providing firmware updates for the i.MX 8M Quad in 2033, and I expect that the firmware updates will end much sooner than that for the RS9116 WiFi/BT, BM818 cellular modem, Tesio-Liv3 GNSS, etc, but there is no reason to not expect lifetime software updates, because the Librem 5 should soon have mainline Linux support. Purism has worked hard to upstream its code changes to parent projects (Linux, wlroots, geoclue, ModemManager, GTK, GNOME libraries, GNOME applications, etc.), so that future releases of these projects should run on the Librem 5 with minimal work. Phosh was designed as a thin overlay on top of standard GNOME libraries and applications (which have substantial support from IBM/Red Hat, SUSE, Canonical and Google) and roughly 176k of the roughly 250k lines of code that Purism has created for the Librem 5 are now incorporated as official GNOME projects. (see: https://amosbbatto.wordpress.com/2021/12/15/amount-code-libr... ) What this means is that it shouldn't cost Purism much to keep providing future software updates. In addition, postmarketOS and Mobian developers are now participating in the development of Phosh which has become the most popular interface among PinePhone users, so even if Purism dies as a company, it is likely that the community will maintain the interface. For more info, see: https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque...
So then Alpine Linux isn't Linux either? That's not a standard convention at all. It's a way of misleading people, and you're doubling down on it.
> By the way, it is just as problematic to say that GrapheneOS is "Linux" because GrapheneOS is using a kernel which has been substantially modified by Google, and Qualcomm's drivers for the Snapdragon which GrapheneOS uses are only designed to support an Android kernel, not a mainline Linux kernel. GrapheneOS doesn't use mainline Linux kernels and it usually takes 3-4 years for the mainline kernel to fully support new Snapdragons after they are released, so I don't know why you are even bothering to make this argument.
Why are you specifically talking about Snapdragon when the current generation and only recommended devices use the Exynos-based Tensor SoC? Current generation devices are using Generic Kernel Images and DO NOT have substantial modifications to the kernel. It's entirely possible to use the kernel.org LTS releases.
GKIs have a stable ABI for kernel modules, and all of the kernel modules for all the generations of devices were already open source despite inaccurate claims to the contrary here.
> Just to be clear, I'm simply a customer of Purism and PINE64 who owns the Librem 5 USA and PinePhone, so I don't represent these companies and I'm not marketing their products.
You're marketing their products and are heavily involved in spreading misinformation about AOSP and GrapheneOS. We consider you to be malicious and you're now involved in spreading libel about our developers. There will be a response to that if you continue down that path. It's likely that you're financially tied to them.
Please stop contacting our project members and refrain from involvement in our community going forward. It will be considered harassment and will be responded to as such.
> I'm not sure whether there is a larger ecosystem of open source apps for Android rather than the GNU/Linux distros that run on the Librem 5 and PinePhone. If we are talking about apps which are designed to run on mobile phones, then you have a point, since it will take a while to adapt all the desktop software to be mobile-friendly, but Kirigami or libhandy/libadwaita is getting added to a lot GNU/Linux desktop software to make it adaptive. Google purposely does not label software with FOSS licenses in the Play Store, so it is hard to count the number of FOSS apps for Android. I count 4472 apps in F-Droid (https://f-droid.org/repo/index-v1.jar), whereas Debian 11 "bullseye" (which is what PureOS and Mobian are based on) has 59,551 packages. I know that not all FOSS apps make it into the F-Droid repo and the Debian repo includges the entire operating system and many of its applications use multiple packages, so we are comparing apples and oranges, but I don't see much evidence that the Android FOSS ecosystem is "larger and better" than the GNU/Linux ecosystem.
This is another demonstration of how unserious you are about remotely sticking to the truth where you venture off into claims that aren't even remotely plausible. F-Droid is a tiny subset of the overall open source Android app ecosystem. Again, it doesn't even have Signal, Firefox, any Chromium-based browser or MANY other widely used open source apps, let alone non-widely-used ones. I have no clue why you're referring to the total number of packages in Debian as anything to do with the number of mobile applications. It's another completely, thoroughly dishonest misrepresentation of the truth.
> I stated that "the Librem 5 doesn't need an IOMMU" to isolate the WiFi/BT, cellular modem, GNSS and USB controller, but in case you are worried, the i.MX 8M Quad SoC in the Librem 5 does have a Resource Domain Controller (RDC), Arm TrustZone and On-chip RAM (OCRAM) secure region protection, which does isolate the CPU, GPU and VPU. See section "3.2.2.4 Resource Domain Control and Security Considerations" in the "i.MX 8M Dual/8M QuadLite/8M Quad Applications Processors Reference Manual". (NXP requires registration to download the manual.)
It does not isolate either the on-SoC or off-SoC components in a remotely comparable way to Snapdragon, Exynos or Tensor. It's also not configured for production use and security properties which could have been provided are far from all being provided.
> The GrapheneOS FAQ lists the Pixel 3a released in May 2019 as a "supported" device, but the Pixel 3 released in October 2018 is listed as "end-of-life" because it no longer gets full security updates, so that tells me that most people are using GrapheneOS on devices that have a 3 year lifespan.
The current generation devices have a minimum of 5 years of support, as has already been stated. The Pixel 3 still receives GrapheneOS updates. It's considered a legacy device as the Librem 5 would have to be considered a legacy device already due to inability to reach the current Android security patch level for many reasons. This was already stated multiple times, and you're once again doubling down on inaccurate claims.
> I downloaded the Pixel 3a's "bonito" kernel (https://github.com/GrapheneOS/device_google_bonito-kernel) and I see that it is using kernel version 4.9.292. Mainline Linux 4.9.292 was released on 2021-12-08 and 4.9.0 was released on 2016-12-11. Call me crazy but I prefer to use an up-to-date mainline kernel rather than one that is over 5 years old and takes 3 months to get the latest security patches from kernel.org. (To be fair, I should mention that the Librem 5 issn't yet fully supported in mainline Linux, so you can't run the latest mainline kernel on day one of its release, but the Purism devs say that mainline support is coming.)
The Pixel 3a / Pixel 3a XL are on the March 2022 Android security update including for the kernel and have additional patches backported to them. Their kernel is based on the Android Common Kernel, which is only indirectly based on the kernel.org releases. Ubuntu doesn't use the kernel.org releases in general at all and that does not mean their kernels are less secure, just because they do not update to newer kernel.org releases because there are none for their kernel branch, which they maintain themselves. This is how Linux works across distributions. Can you name one distribution directly shipping kernel.org releases without patches? Even Arch Linux doesn't do that.
A subset of the kernel.org changes is shipped by AOSP on a monthly basis with additional backports by GrapheneOS. The kernel.org releases are shipped by AOSP as part of the quarterly updates, they get shipped approximately every 3 months. GrapheneOS is fully capable of shipping the latest kernel.org releases but we found that there are too many regressions including security regressions and we stopped shipping them faster than AOSP for most devices. The current generation devices, which for some reason you feel like ignoring in favor of 3 year old ones use Generic Kernel Images and can be trivially updated to the latest kernel.org LTS without any changes since there are ZERO device-specific changes to the kernel. Maybe you should stop trying to make dishonest and misleading comparisons by comparing the latest generation of one device to 3 generations ago for another device, while adding in your own inaccurate claims to that.
For your information, the Pixel 3a has not been vulnerable to many of the most recent serious recent kernel vulnerabilities unlike the Pixel 6 because it's on the 4.9 branch instead of the 5.10 branch. The 5.10 branch has massively more complexity, attack surface and does not offer substantially improved security. The new mitigations in the Android 5.10 common kernel.
The Librem 5 is incredibly low-end hardware with many corners cut being sold for now 1299 USD. You go across platforms marketing their products with thoroughly dishonest claims and spin. It's highly likely that you have a financial stake in the company's products because nothing else would explain your devotion to so thoroughly misleading people and marketing their products across many platforms.
> Granted that NXP will stop providing firmware updates for the i.MX 8M Quad in 2033, and I expect that the firmware updates will end much sooner than that for the RS9116 WiFi/BT, BM818 cellular modem, Tesio-Liv3 GNSS, etc, but there is no reason to not expect lifetime software updates
It's a completely false and outrageous claim that it will receive 'lifetime' updates but I see now that you're narrowing it down to simply receiving INCOMPLETE support/updates for the software indefinitely which applies to anything where you can install another OS and you're simply admitting to your explicit attempt to mislead people.
Not receiving firmware updates for every component, which is already the case today, means it's end-of-life. The Librem 5 is already end-of-life by the definition implemented by GrapheneOS. It cannot reach the current Android security patch level. There is no Android security patch that it could reach, since even the earliest ones required avoiding security weaknesses which are unavoidable on that hardware. It's a highly insecure device and no amount of your / Purism (likely one and the same) dishonest marketing is going to change that.
Linux kernel updates in no way guarantee security support for all the drivers, etc. which are being used, and there is no such guarantee for any of the device support code in userspace or any of the userspace projects. Security updates are not provided for many Debian packages. Only a subset of the security fixes get backported in the first place to those that are supported. Using Debian in no way implies getting indefinite or even current security support.
Any further contact with the GrapheneOS project or project members on your part or any further attempts to spread misinformation about it will be considered harassment as I already said earlier. We aren't interested in communication with you. If you don't stop contacting us, spreading libel about our project members and misinformation about our project, we'll begin contacting organizations/projects where you're involved about the harassment and malicious behavior across platforms towards an open source project.
Anyone can look at https://news.ycombinator.com/threads?id=amosbatto and see that you're heavily involved in marketing and providing customer support for Purism, which unfortunately involves spreading a lot of misinformation about both Purism's products, the company and about other open source projects which you aim to steer people away from and towards buying their products. We've already requested that Purism avoids contacting us and trying to harm our product. That extends to you too. You need to stop. This is your final warning.
As I already stated earlier, if you continued to spread misinformation, an article will be posted on our site with all the information that I posted here and more. That's going to be happening now. If you continue, then there will be a response directed towards you personally too, because you have made it person with the libel that you and other Purism employees/associates have regularly spread about us across platforms.
There is a major difference between the openness of the Librem 5 (L5) vs Android phones. The L5 is the first phone with free/open source schematics (GPL 3.0) for its circuit boards since the Golden Delicious GTA04A4 which was released in Jan 2012. Purism has only released the STL files for the L5's case and the board schematics in PDF, so it would take some work to recreate the original CAD files, but anybody can legally reproduce the hardware in the L5. To find a phone which released its CAD files, you have to go back to the OpenMoko Neo FreeRunner released in June 2008.
Purism has also released the board view images to show where components are placed on the L5's boards. You may be able to find the board view for a few models (such as iPhones), because they get leaked, but as far as I know, no Android phone manufacturer publicly releases the board views of their circuit boards.
If your argument is that the circuit boards don't matter, because most of the functionality is locked up in proprietary chips, then let's look at the chips that Purism selected and see if there's a difference. Qualcomm, MediaTek, UNISOC and Samsung don't release the documentation for their mobile application processors without an NDA, and Apple and Huawei don't release their documentation on their chips to any outside companies as far as I know. In contrast, NXP released 7000 pages of documentation plus their Android and Linux software for the i.MX 8M Quad to anyone who registers on their website. They restrict the security manual to only certain approved people, but everything else can be obtained and NXP has a public forum where anyone can ask questions about their i.MX processors. Likewise, Thales releases the documentation on the PLS8 cellular modem and provides a public forum.
Android phones commonly have a locked bootloader which prevents the user from changing the OS. All Huawei and Apple phones have the bootloader locked. Most Samsung phone require using an unauthorized crack. Motorola and Xiaomi require applying for an unlock code code and waiting up to two weeks for it and using it voids the hardware's warranty. Sony makes it easy but voids the warranty. Google also makes it easy, but won't honor the warranty unless the Pixel is reflashed to the original OS and relocked. In contrast, the Librem 5 has such restrictions.
Another issue is the drivers and kernels. Qualcomm has the best track record of the major mobile SoC manufacturers since it provides public access and the commit record to its kernel source code at Code Aurora, but the community has to take that code and adapt it to work in mainline Linux and it often takes 3 or 4 years to fully support Snapdragons. Samsung has done better in recent years, but MediaTek, UNISOC, Huawei and Apple are horrible. However, NXP is far better than all these since it commits directly to mainline Linux and is willing to work with the community to support its chips.
Purism develops its code in public and encourages its developers to interact with the community. All the firmware in the L5 is proprietary, but it is worth mentioning that Purism is planning on using FOSS firmware in its secondary Cortex processor to control the smartcard reader. Also the OpenPGP specification is open, so anyone can study it.
I would argue that all of these things add up to make the Librem 5 the most open phone that can be bought today (with the PinePhone a close second). I have a problem with some of Purism's marketing, like the "100% made in the USA electronics" slogan for the Librem 5 USA, but you have to look at this in the context of the actual mobile industry and what is possible in the real world. Sure it would be great to have a phone with open hardware chips, but you are talking about hundreds of millions of dollars to develop those chips and paying hundreds of millions more to license the necessary IP, which is totally unrealistic.
For the moment the Librem 5 seems to be using apps designed to work on PC desktops but at lower resolutions.
Let me state for the record that I have no financial stake in Purism, and I do not represent the company. I am simply a customer of the company who tries to correct the misinformation that I see being posted about the Librem 5 on public forums like this one, because I think that Purism is doing important development work for mobile Linux. I am using my real name "Amos Batto", and anyone who does a simple internet search can find my personal blog, my github page, my facebook page, etc. and verify who I am.
> If you don't stop contacting us, spreading libel about our project members and misinformation about our project, we'll begin contacting organizations/projects where you're involved about the harassment and malicious behavior across platforms towards an open source project.
This is ludicrous. You posted information which I consider to be incorrect about the Librem 5 on this forum and at r/Purism. When I responded to correct the record, you accused me of engaging in "harassment and malicious behavior across platforms towards an open source project".
Everyone can see your behavior and it fits a consistent pattern. You go out of your way to criticize other open source projects on public forums. Then, when people try to respond on the technical points, you accuse people of harassing you and trying to harm your project, which is simply not true. Responding to the technical points that you raised on a public forum is not an attempt to "contact" you or members of your project and it certainly is not "harassment" as you term it.