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
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!
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
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...
> 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
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
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.
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....
Deleted that part of my comment.
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.
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
[1] https://sxmo.org
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...
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].
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)
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.
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...
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).
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...
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.
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.
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.
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.
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 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.