amosbatto

Roughly 80% of the total energy consumption of a PC with a 3 yr lifespan is in the fabrication. Creating electronics is very resource intensive. Unlike other products, where the majority of energy and pollution lies in the usage, the majority of the impact of electronics lies in the fabrication.

I would rather switch to Rust than try to learn modern C++. It feels like a totally new language to me, so I might as well switch languages and get all the advantages of using modern language.

> Also, what makes you think that apps that demand too much will never exist on other OSes? You seem to be blaming AOSP for app developers' behavior.\

Linux distros and repos with AppArmor, SELinux, SNAP and Flatpak often decide what permissions the app has. It usually isn't the decision of the creator of the app. Of course, this can be done in the AOSP world, but I don't think F-Droid changes the permissions that apps ask for, and Google Play Store certainly doesn't change them in my experience.

Most Linux phones only run proprietary apps inside an LXC container (Waydroid, AppSupport, Andromeda or Lepton), which has its own security configuration that can be set the distro.

> Members of the GrapheneOS project (myself included) call these projects out because they're misleading their users.

It is fine to publicly criticize the security/privacy of other FOSS projects, because criticism often fuels improvement in the long term.

In my case, however, I had two public debates with Daniel Micay (first on a Hacker News thread, then later on a Reddit thread) about the security of Linux vs AOSP, in which he publicly accusing me of organizing raids against the GrapheneOS community, which was a total fabrication on his part. My interaction with Micay is mentioned in Techlore's 45 minute video, where he documents his own conflict with Micay.

I'm actually impressed by GrapheneOS's work on the Android kernel, so this isn't a comment on GrapheneOS per se, but I decided to never use GrapheneOS and to stay far away from the project based on that negative experience.

> Would be nice if you would be able to give examples of those anti-user features and examples of desired user-empowerment features.

Off the top of my head, here are some of the anti-user features in AOSP/Android that I would change:

* Remote attestation. If someone wants this, they can turn it one, but the OS and apps shouldn't be able to impose this requirement on the user.

* Making it hard for people to root their phones. I can understand having root access turned off by default, but it should be an easy and documented process to turn on root access on your phone, but it should also require setting a root password, which the user has to enter when doing an administrative action in the system. After rooting the phone, the GUI will ask for the root password when doing certain administrative tasks and the terminal will ask for it when using `su`. However, I would enable non-root users to access more than they currently can (see below).

* Apps should not be able to decide that they won't execute based on rooted status, Play Integrity checks, SELinux enforcing, bootloader unlocked status, etc. It should be up to the user, not the app creator, whether an app is allowed to execute. The OS should inform the user about potential security problems, but not encourage app creators to put these restrictions on their apps. I realize, however, that an AOSP fork wouldn't have the power to stop app creators from doing this stuff, so I would include a clean Android work profile and make it so those problematic apps can't detect what has been done to the rest of the system.

* The Activity Manager (`am` command) needs to be designed or eliminated to stop restricting the user. It is very annoying that users can't just execute graphical apps from the terminal like in Linux, and the way `am` does it is designed to make users not use a terminal. Instead of `am start -n org.videolan.vlc/org.videolan.vlc.gui.video.VideoPlayerActivity -a android.intent.action.VIEW -d file:////storage/emulated/0/VideoToPlay.mp4`, it should just be `vlc ~/VideoToPlay.mp4` like in normal Linux. Forcing apps to name the activity with the `-a` option, and to pass their parameters with the `-d` and `-es` options is designed to stop users from using options. Most Android apps have no command line options because Android makes it so painful to use them, and that is by design. Why does Android force users to refer to apps by reverse domain name order like "org.videolan.vlc" which is impossible to remember and so hard to type? Using the full reverse domain name for an app should only be necessary if there are two apps with the same name, and it should be possible to create an alias for apps so they can have short names. If a user (i.e. the person using the phone) initiates an app, then that person should be able to kill the app from the command line with a short command like `pkill app-name`. Currently, AOSP only allows `am force-stop com.example.myapp` if the phone has been rooted or if issuing through ADB (`adb shell am force-stop com.example.myapp`), which is an anti-user restriction that needs to be eliminated. I wouldn't require the `am` command at all for starting and stopping apps, but if AOSP/Android is going to use the `am` command, make everything easy to type and very short. It should be possible to set variables when executing apps just like in normal Linux (e.g. `MY_VAR=value myapp`) Instead, AOSP forces people to either root their phone or use adb, just to set variables when executing an app: `adb shell setprop wrap.com.example.myapp "env MY_VAR=value"`

* AOSP requires a rooted device or adb in order to use many commands, including `setprop`, the package manager (`pm`), most networking commands (`ip`, `ss`, `netstat`, etc.), use of wrap.com.example.appname or debug.com.example.appname, etc. It is really annoying that you have to root the device just to see the list of the installed packages with `pm list packages`, see the current battery state with `dumpsys battery` or even see the IP address with `ip a`.

* AOSP requires a rooted device or adb in order to view most of the directory structure on the device. In standard Linux, an ordinary user gets read-only access to `/`, `/dev`, `/sys`, etc., which makes it much easier to figure out how the system works and diagnose problems, but the device is basically a black box for the ordinary android user. I can understand forcing normal apps to access the hardware through the Android HAL and not be able to read the / directory, but terminal apps should have permissions, so the normal user can have read-only access to `/`, `/dev`, `/sys`, etc. Forcing users to execute some custom command like `termux-setup-storage` just to get permission to access the microSD card is bizarre and another anti-user feature.

* Forcing users to create an app just to execute a custom script from the launcher is another anti-user feature. Let’s say that you want tapping on an icon on your screen in order to run a custom script. In a standard Linux system, you just create the script, and then you add a launcher in the graphical interface to execute it or you add a `.desktop file` to the `~/.local/share/applications` to add it to the graphical interface. In AOSP/Android, you need to create your own app in Android Studio that has a `AndroidManifest.xml` file with this code: ``` <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.HOME" /> <category android:name="android.intent.category.DEFAULT" /> </intent-filter> ``` And you need to have application code that has Java or Kotlin code like this: `Runtime.getRuntime().exec("/storage/emulated/0/your_script")` Then you need to create the apk file and sign it and install it. There are workarounds, like installing Termux and Termux:Widget, but those workarounds shouldn't be necessary. AOSP should make it as easy as standard Linux.

* The way permissions work in AOSP/Android is simply a hassle and requires too much cognitive load for the average user. When you first install a new app, you have no idea how the app works or what permissions it really needs. There are 324 different permissions in Android 17, and it is overwhelming for most people to install a messaging app and be asked for a dozen different permissions, such as Notifications, Identity, Contacts, SMS, Phone, Photos/Media, Storage, Camera, Microphone, Wi-Fi, Calendar and Location, which is why so many users simply grant all the permissions that are requested, so the permission system doesn't really work as intended.

It would be much better for the distro package manager to configure the app to grant just the permissions that most users of the distro would want, and then let the user set the permissions that she always wants to be asked about, but not be bothered with the rest. For example, Calendar and Location shouldn't be necessary for most users of a messaging app, so they wouldn't be granted by default, and the OS would ask for those permissions if the user tries to use a feature that requires those permissions. In a distro focused on security, the defaults would be different from a normal distro. The list of permissions granted by default should be shown to the user when installing, and users who want to pick and choose can open a dialog box to select the permissions. They can also set the permissions across all apps that they want to be asked about.

In my opinion, the user should only be asked about each permission only if an app comes from outside the default repository. Of course, this assumes that the default repository is only contains open source code, and the package manager is separate from the app creator and is reviewing the code in the interest of the AOSP distro's users.

* Each app has a different user assigned to it by AOSP/Android, and you can't change the name of that user, which is very inconvenient, because AOSP/Android creates random usernames that are very hard to remember. For example, every time I want to ssh to my AOSP phone, I have to open Termux and use the `whoami` command, because I can never remember that my Termux user is named u0_a281.

> Despite that, their operating systems (AOSP, ChromiumOS) and their browser project (Chromium) offer a lot of user control over who they hand their personal information to. They offer a fine-grained run-time permission model.

The problem with Android's "fine-grained run-time permission model" is that most users learn very quickly that if they don't grant Android apps all the permissions that they ask for, they won't have the app's full functionality. I have played this game many times with Android apps, where I only grant them the permissions that I think are strictly necessary. However, after I start using the app, I constantly discover that I keep needing to grant them more and more permissions. In the end, it becomes such a hassle to keep being asked for permissions, that I almost always end up giving every app all the permissions that it asks for.

It is far better for most users to have their apps preconfigured to only grant the permissions that they need by distros and companies who care about protecting users and keeping their data private. As a user, I don't want to have to scrutinize every app that I install and check whether the business model of the app creator is based on surveillance capitalism or malware. Since I use the PureOS and Mobian distros (which are Debian derivatives) on my Linux phones, I can have a lot more confidence that I'm not installing anything that will harm me or spy on me. Yes, I know that Firefox is paid to set Google as the default search engine and Canonical tried a few schemes in the past like its Amazon Shopping Lens in 2012-16, but those are anomalies in the Linux world, whereas they are the norm in the Android world.

> Nothing stops Android apps from being open source and also properly vetting contributors. This isn't a technical limitation of AOSP-based OSes at all.

Yes, there are companies making AOSP derivatives which have good business models that respect and protect the user, such as Murena, iodé and Volla, and I know that the F-Droid community did a good job of reviewing the code that I submitted to them. I have a personal beef with how Daniel Micay treats other FOSS projects, but GrapheneOS does a good job of protecting its users. However, I know from personal experience that I always end up installing apps based on surveillance capitalism on my AOSP phones, because I always end up needing some Android app. In 27 years of using Linux, I haven't installed any malware or spyware that I know of (beyond Firefox's Google search), and that is the common experience of most Linux users. (See below for further argument.)

> This is absent on the alternatives you propose. Flatpak doesn't use a proper run-time model, isn't as fine-grained and has numerous sandbox escape possibilities (notably via dbus or access to config files like .bashrc).

If you are arguing that mobile Linux needs to improve its userspace security model, then I agree. I'm not saying that Flatpak is perfect. My argument is that it is much easier to improve mobile Linux's security model than to fork AOSP or even just replace the user anti-features in each new release of AOSP.

> The vetting system on Linux is imperfect as I said above, it still relies on trust. And as I said before, there are more security problems than simply code written with malicious intent.

True, there have been instances, such as OpenSSH's CVE-2026-35414, where they didn't catch the problem for 15 years, and you mentioned the xz backdoor, where someone (probably the Israeli government) was deliberately introducing security holes. In general, the Linux distros have been lulled into a sense of complacency since they haven't had major security issues like Windows and Android have had in the past. I think the real issue is the fact that the major Linux companies (IBM/Red Hat, SUSE, Canonical and Google) are mainly focused on servers, where userspace security isn't an important factor. If your argument is that mobile Linux won't be able to implement a better userspace security model without the help of the big Linux companies, then you may have a point. However, the example of Qubes demonstrates that it isn't impossible for a single distro to implement major changes.

Before we start this debate, let me state from the outset that I have been installing AOSP derivatives on my own phones since 2015, and I don't want to disparage all the hard work being done by the volunteers at LineageOS, GrapheneOS, and the other custom ROMs.

However, if the long-term goal is digital freedom and user empowerment, dependence on Google puts us in a very precarious position, and I suspect that Google and the phone brands will keep turning the screws and making it harder and harder for the AOSP-derivatives to keep operating, because the business model of the mobile industry is changing from planned obsolescence to surveillance capitalism and the monetizing of people's personal data. The tech giants are in a fierce race to collect as much of our personal data as possible in order to train their LLMs. Although the current AI bubble will pop, just like the Internet bubble popped in 2001-2, that didn't stop the Internet from becoming the predominant paradigm for the tech industry, and AI will probably follow a similar trajectory, so I don't think the financial incentives to collect our personal data for targeted advertising and AI training will stop.

As I explained in my previous article on Linux phones, the smartphone brands that permit unlocking of the bootloader have dropped from 42.5% to 7% of the market in recent years. The brands which allow their bootloaders to be unlocked (without major restrictions like Xiaomi) only sold about 87 million phones in 2025, including Lenovo/Motorola (60M), Google (12M), OnePlus (11.6M), Nothing (2M), GigaSet (>1M), Sony (400k), Fairphone (145k), SHIFT (10k), Teracube, Volla and Brax. The number of new phones sold in 2025 that have official LineageOS ports and aren't locked by carriers is probably around 20 million phones or 2% of the global smartphone market, and that number will probably drop to 10 million per year as Motorola keeps switching more of its phones away from Snapdragon processors, OnePlus is pulling out of Europe and North America and Nothing is cutting staff and will probably pull out of many markets. In other words, our ability to install custom ROMs will keep being restricted. For people living in Iran and most of Africa, there is not a single new phone on the market that has an official LineageOS port. In some African countries (Kenya, South Africa, Nigeria, Ghana and Eygpt), most of Latin America (except Mexico) and most of Asia (except Japan, Taiwan, Singapore, India and Malaysia), they only have one new phone on the market with an official LineageOS port, which is the Motorola Moto G15 that was released in December 2024.

We are becoming increasingly dependent on Google for both the software and hardware to run AOSP phones. For most of the world, Motorola is the only option to install an AOSP derivative, which means waiting 3 to 14 days just to unlock the bootloader, or buying a used Xiaomi and dealing with Xiaomi's insane policies to get an unlock code.

We need to support the Linux phone companies, because we have no idea how much longer Google will continue to release AOSP, and we are totally screwed if Motorola or Google change their bootloader unlock policies. None of your arguments convince me that the community can maintain an AOSP fork with 309 million lines of code, whereas we know that the Phosh and Plasma Mobile interfaces and the existing mobile Linux distros like SailfishOS, Ubuntu Touch, Nura, Mobian, DanctNIX, Droidian, etc. can be maintained by the community.

OK, let me try to address some of your specific points in subsequent comments below.

Not only do I appreciate Purism's upstream-first policy when developing its software, I also appreciate the fact that its developers take the time to answer people's questions. Purism charges high prices, but I think the company is worth supporting.

Purism's public reputation was blackened by its decision to stop repaying the refunds to people who canceled their Librem 5 pre-orders after Feb. 2020. I think that decision allowed the company to finish developing the Librem 5 phone and start shipping it in Nov. 2020, but you will find a lot of negative comments online about the company (see Reddit's r/Purism). I often point out the positive aspects about the company, because the company gave a lot to the community by developing libadwaita and Phosh, but some people don't see it that way.

I received several dozen comments to my previous article, "Will Linux phones become a viable alternative to the Android/iOS duopoly?" (https://news.ycombinator.com/item?id=50051530), asking why bother developing mobile Linux when we already have a mobile Linux operating system available with the Android Open Source Project (AOSP). They argued that there is no reason to develop another mobile Linux OS, when we already can use the most popular one available, and it gives us access to millions of apps.

In this blog article, I go through the reasons why the community would struggle to fork AOSP or even add changes to each new AOSP release from Google that empowers users and maintains their freedom like mobile Linux. Here is the central argument:

> Given how Maemo Leste and UBports have struggled to maintain the large codebases developed by Nokia and Canonical, respectively, it is not realistic to expect that the community can fork an enormous project like AOSP with 309 million lines of code. Even if the AOSP fork can be rebased every year on each new AOSP release by Google, it will still be a huge amount of work to keep refactoring the code each year so the AOSP fork respects and empowers the user like mobile Linux does. If Google ever stops releasing AOSP, there is virtually no way that the community will be able to replicate all the code changes that Google is making with each new version of Android, so the community fork will diverge over time from Google’s version. As more and more Android apps become incompatible with the community’s AOSP fork, fewer people will be willing to use it.

After I posted my previous article, "Will Linux phones become a viable alternative to the Android/iOS duopoly?," quite a few people commented that it made no sense to develop mobile Linux, when we already have AOSP, which is a Linux distro. I wrote this article in response.

Yes, as the owner of a Librem 5, I can attest that getting the Qualcomm modem in the BroadMobi BM818 has been one of the pain points, and it is very hard to diagnose the problems.

If that is the case, the PINE64 wiki really needs to be updated. I never bought the PineTab2 and PPP due to what is listed on the wiki.

I also added a postscript note at the bottom of the article thanking you for pointing out that you had submitted more upstream to mainline Linux than I thought, and linked back to this conversation.

Have you looked at the FuriLabs FLX1s+? You can also buy a used Volla phone on ebay and install Ubuntu Touch. Jolla has says that it is considering selling its Jolla Phone (2026) in the U.S.

I changed the text from:

Purism chose to upstream their changes to mainline Linux, whereas the volunteers working on the PinePhone's kernel generally didn't.

To:

Purism generally chose to upstream its changes to mainline Linux, whereas the volunteers working on the PinePhone's kernel were less consistent about upstreaming their changes.

"There were several pinephone HW revisions that fixed HW issues based on direct developer feedback... So communication to get HW changes was possible, and was usually via TL Lim, not via HW devs."

That's great, but that wasn't my experience as an ordinary buyer of the PinePhone who wasn't on the special developers list and had no way to communicate with TL Lim. PINE64 provides no way for an ordinary user to register a bug report about the hardware in the PinePhone.

When I added the "PinePhone component list" page to the PINE64 wiki (https://wiki.pine64.org/wiki/PinePhone_component_list), I noticed several errors in the schematics. See: https://amosbbatto.wordpress.com/2021/12/10/comparing-l5-and...

Since PINE64 didn't provide a way for me to register a bug report about it, I listed those errors on the wiki page. Instead of fixing the schematics, every mention of errors in the schematics was deleted from the wiki by user "Kx" on 2023-12-24. My questions on the PINE64 forum about how to get the schematics fixed were never answered. I don't blame PINE64 for the wiki edits, since I assume "Kx" was just someone in the community who didn't like seeing that there were errors in the schematics. However, the fact that PINE64 doesn't have a public bug tracker for its hardware issues is frankly an indication of problems with the way the company was run in my opinion.

"Accurate statement is that some perhaps critical work stayed out-of-tree, partly by choice and partly due to upstream rejections or dependencies, and not that "the volunteers generally didn't upstream." The claim is overstated to the point of being misleading."

I did some web searches and see that there were more commits to mainline Linux than I thought. I will edit that part. However, there was a marked difference between Purism and PINE64 in this respect.

"The article says PPP "still had major software problems when its sales were cancelled in August 2025.". Yeah, no. Pinephone Pro has almost full kernel support, multiple bootloaders, even graphics/touch support for U-Boot, etc. There are no SW kernel issues that I'm aware off that were not solved years ago."

I don't own a PPP, so I was going off what is listed on the PPP PINE64 wiki, which lists: Bootloader (critical bugs), Stability (WIP), Suspend (Experimental), Updates (WIP), Phone (WIP), MMS (WIP), LCD (WIP), Rear camera (WIP), front camera (WIP), camera flash (critical issues), Bluetooth (WIP), GNSS (WIP), Sensors (WIP), Keyboard add-on (WIP), Qi Wireless (WIP), LoRa (not implemented), Fingerprint reader (not implemented).

Is the wiki wrong? I held off on buying the PPP for years waiting for those issues to be resolved, and I saw little progress on getting those problems solved since many of the high profile volunteers left in 2022.

"As for the company: Pine64 promissed 10 years of original Pinephone."

The PP FAQ says: "he PinePhone (and parts for them) will be produced and sold for at least 5 years." https://pine64.org/documentation/PinePhone/FAQ/

"Sooo. what HW support is lacking on Pinephone, Pinephone Pro or PineTab2 or Pinebook Pro, or other consumer products, if you take some downstream maintained kernel and use it? You'll find that very little of consequence is missing."

The PineTab2 wiki says that Bluetooth doesn't work, WiFi can't be reset, so device needs to be power cycled. The camera drivers need to be ported, The Rockchip CSI/ISP driver needs to be extended to handle 2 lanes. Suspend does not currently work reliably, so suspend has been disabled.

"Performance is not really relevant to "level of SW support"."

In the case of the A64 in the PinePhone, its GPU for hardware acceleration is pretty weak, and there is no ISP and aDSP, and the VPU's hardware encoder only includes H.264 video, so I don't think SW support was really holding back the performance of the cameras and the speed of the interface. There are other SoC's where proper SW support is a more relevant issue holding back performance.

Hi Megous, I'm the author of the article. Before we get started here, just let me say from the outset, thank you for all your hard work on the PINE64 hardware.

I will correct the things that I got wrong in the article, if I can verify my errors.

I have the PinePhone 1.2b (Beta Convergence Package), that was shipped to me on April 5, 2021. It is currently running Mobian Weekly with kernel 6.18.32.1, which I downloaded about three weeks ago.

I see the flicker on my PinePhone's screen. I usually see it for a minute or two after I turn on the phone or resume from a suspend, but I sometimes see it at other times. I see the flicker both when the screen brightness is set to a minimum or to a maximum. I have seen this problem the whole time I have owned the PinePhone.

I assumed it was caused by this issue: https://wiki.pine64.org/wiki/PinePhone_v1.2#Backlight However, rereading it, my case doesn't fit, because the screen flicker exists at both minimum and maximum brightness. Can you explain this?

Maybe my screen flicker problem is special, but was the problem listed on the wiki ("When backlight brightness is very low and the CTP controller actively communicates on the I2C bus the backlight blinks heavily.") ever resolved by PINE64?

I didn't go into that in this article, but given the number of comments here and on Reddit, I think I should write a second article that explains my thoughts on why I think Linux phones are better strategically than AOSP phones. I'm not opposed to AOSP phones--I use my two AOSP phones more than my two Linux phones. Most people aren't going to use the current Linux phones. Even I as someone who has using Linux since 1999 find that the functionality of the current Linux phones doesn't match AOSP phones. However, I think using AOSP helps lock us into the Android ecosystem, whereas using Linux helps build an alternative ecosystem which is what we need for long-term independence and freedom.

Yes, I probably should have addressed that in my article, but my primary focus was on whether Linux phones can grow from being a miniscule niche for nerds like me to being a real alternative for normal people to Android and iOS phones. I would guesstimate that around 10,000 Linux phones were sold in 2025, which represented 0.0008% of the global smartphone market that year. The question I was asking is whether we can get to 0.1% or even 1% of the market. Rereading the article, I see that I wasn't very good about explaining the focus of the article. There was so much technical stuff to cover, and I got a little lost in all that.

If you look through the list of recommended devices for Nura (formerly postmarketOS), the only one that has full software support for all the hardware is the Librem 5, and the second best supported phone is the PinePhone.

The rest of the phones are dated Android devices which all have significant functions that don't work correctly. The processor with the best support is the Snapdragon 845 from 2018 in the OnePlus 6/6T, POCO F1 and SHIFT6mq, and all of those devices have issues that a geek like me can accept (like downloading code from github and manually compiling to get a partially functional camera), but it isn’t really an option for ordinary people.

Purism suffered a distributed-denial-of-service (DDoS) attack on July 29, 2023, which took down their site, as they explained on their Matrix channel and forum (when the site came back online). See: https://forums.puri.sm/t/sites-down-no-comms/21000/3

It is likely that someone who owns a botnet saw Rossmann's criticism of Purism and decided to that the company deserved to be attacked, which is a really rotten thing to do, because then people assume that Purism is hiding something.

I agree that Purism should have refunded the cancelled orders, but calling the company a "scam" is way over the top, considering the huge amount of dev work that Purism has done on mobile Linux and the Phosh interface. I own both the Librem 5 and Librem 5 USA and the company is definitely not a "scam".

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

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.

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

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.

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

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

> More developers are familiar with Android than the desktop Linux software stack. More work goes into it. Far more apps are written for it, and that includes a very active open source app ecosystem.

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"?

@anw, According to the Purism forum, the shipping queue for the Librem 5 has reached people who pre-ordered on October 20-25, 2017, so you should have gotten your phone by now. You should contact Purism support to ask about your order. See: https://forums.puri.sm/t/estimate-your-librem-5-shipping/112...

It depends on your goals. If you donate to the GNOME Foundation, your donation won't help develop Phosh (which is the leading mobile Linux interface according to 3 different PinePhone user surveys) and it probably won't be used to make GTK/GNOME ecosystem become adaptive and mobile-friendly. If your goal is to advance mobile Linux on the GTK/GNOME/Phosh platform, then ordering the Librem 5 is the best way to get funds to the 10 software devs working on it at Purism. See: https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque...

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

Xiaomi is the number one brand in Europe and India, and was the number 3 brand worldwide by unit sales in the year 2021. Xiaomi actually does the worst in its home market. It was the 4th largest brand inside China in Q3 2021, and it fell to 5th place in Q4 2021. See: https://www.gsmarena.com/strategy_analytics_xiaomi_is_the_to... https://www.gartner.com/en/newsroom/press-releases/2022-03-0...

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

> Looking up the Librem 5 devicetree in the upstream kernel, it seems it was submitted on Aug 21 2020. Aspen shipped in September 2019, so it took them about a year from shipping to upstreaming bring-up, and that's not considering internal prototypes and that the SoC was announced in mid 2018, so they had plenty of time to work on things internally. I submitted upstream bring-up for the M1 Mac Mini with the device tree on Feb 4 2021, just 4 months after it was announced in Nov 2020.

Before anything else, let me say thank you for your work on the M1, because it is essential that we have Linux support for processors even when the device maker is opposed. Considering how many millions of people have bought Apple's M1 devices, Asahi's work is critical because it provides a path for people to discover a freer system when they get disgusted with Apple's bad practices and the restrictions of its "walled garden."

Having said that, I don't think that your criticism of Purism's kernel work is very fair. Purism made its first commit to mainline Linux for the Librem 5 in July 2018 (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...). Purism submitted the device tree for the Librem 5 DevKit to mainline Linux on June 17, 2019 (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...), which was 7 months after it started shipping the DevKits in mid-December 2018 (https://puri.sm/posts/2018-devkits-are-shipping/). I can find emails from Purism trying to submit the device tree for the Librem 5 since May 25, 2020 (http://lkml.iu.edu/hypermail/linux/kernel/2005.3/00715.html), which was 7 months after it started shipping on Nov 17, 2019. Since Linux version 4.20, Purism has made roughly 150 commits to mainline Linux to support the Librem 5, whereas System76 has made 13 commits to the Linux kernel (https://blog.system76.com/post/667593198841069568/open-up-co...) and TUXEDO Computers has made one commit (https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n...), and I can find commits for the rest of Purism’s competitors (PINE64, Juno Computers, Slimbook, ThinkPenguin, F(x)tec, Planet Computers, Hallo Welte, etc.)

You are comparing the work of a company with two kernel developers (Angus Ainslie and Martin Kepplinger) to an entire community working on Linux support for the M1. Purism has only shipped 2600 Librem 5's so far, whereas Apple is shipping roughly 7 million M1 Mac PCs and 15 million M1 iPads every quarter. If you are going to brag about getting M1 support into mainline Linux within 4 months of the release of the M1, consider the fact that the first commits to mainline Linux for the i.MX 8M processors were submitted just 8 days after NXP announced that it had started volume shipping of the processors (https://www.pengutronix.de/en/blog/2018-01-17-first-mx8m-mai...). This was possible because NXP shipped early versions of the processor to many companies and has released 7000 pages of documentation on the processor, plus NXP pays several of its own employees to work on getting the i.MX 8M supported in mainline Linux. It does make a huge difference whether a company decides to collaborate with the Linux community or not.

You also have to keep in mind that Apple has shipped 2 billion devices with A-series processors that never got mainline Linux support, so we got really lucky that 1) Corellium managed to figure out how to run Linux on the M1 and 2) Apple decided to not block the use of custom kernels with the M1. Corellium (which currently has 20 employees) has been working on figuring out how Apple processors work since 2017 (https://craft.co/corellium) and company's blog makes clear that it was its previous work on the A-series (boot sequence, PCIe and USB controller) which helped it get Linux support working so fast on the M1 (https://www.corellium.com/blog/linux-m1), so Corellium wasn't starting from scratch in figuring out how the M.1 works.

By the way, it's worth pointing out that most of Purism's dev work hasn't focused on the kernel, but has instead focused on creating the Phosh mobile environment on top of GTK/GNOME, and Purism has created about a quarter million lines of new code so far (https://amosbbatto.wordpress.com/2021/12/15/amount-code-libr...), and 169.4k of that code (libhandy, libadwaita, Chats and Calls) has been incorporated as official GNOME projects. Purism purposely designed the L5's software to work as a thin overlay on top of an existing desktop Linux stack, so PureOS/Phosh has done a better job than Meego, Sailfish OS, Firefox OS, Ubuntu Touch and WebOS at making a version of mobile Linux which is compatible with the larger Linux ecosystem. Purism commits upstream as much as possible to projects like Linux, wlroots, ModemManager, Geoclue, GTK, GNOME and about 20 different GTK/GNOME apps (Nautilus, gEdit, GNOME Calendar, CNOME Contacts, GNOME Clock, etc.) so that the L5 will be easier to maintain and be able to run on other Linux distros (postmarketOS, Mobian, Ubuntu Touch, etc.).

> To my knowledge, the L5 does not support any kind of secure boot (at least it is not implemented yet; the SoC itself might)

The i.MX 8M does have a secure boot option, but Purism isn't going to use it because it isn't controllable by the user. Purism's Kyle Rankin commented that they are discussing how to implement a user-verifiable boot procedure, like they have with PureBoot + Librem Key on their laptops, but Purism has a lot of other stuff on its plate (like suspend to RAM, camera auto-focus, encryption with keys from the OpenPGP card, etc.) which is higher priority, so I doubt that it will be implemented soon. The Ubuntu Touch port should have secure boot, but UBports has put their porting of the L5 on hold to focus on the PinePhone and PineTab, so I assume that will also take a while.