Pine64 Februrary Update: Show and Tell
pine64.org
pine64.org
Android is written with deep and casual connections to Google's systems all throughout the codebase. It's like a cockroach infestation. There's no concept of anyone potentially not wanting to connect to their services regardless of how trivial the "value add". It will take dozens of patches to cut these out, often breaking functionality. To be fair, I haven't looked at /e/ sources to see if they've done all this, but I would be surprised if they got all of them. Then of course, the patches need to be maintained and new ones written as Google continues to relentlessly add more integration points with their servers in subsequent Android updates.
Just to name a few: SUPL, WebRTC probing, automatic previews of YouTube in the Messenger, Google maps lookups in Dialer and in Photos, myriad connectivity checks, etc. And this doesn't even consider the unending whack-a-mole that gets played for Chromium privacy by projects like Bromite and un-Googled Chromium.
After going down this rabbit hole, it became clear to me the only way to win is to not play. If the Pine64 ecosystem gets to the point of working as well as the Linux desktop (been daily driving some KDE on top of GNU/Linux for 10+ years, with only one major issue due to buggy drivers), it will be one of the very few ways to ensure your phone is not making unwanted data transfers to Apple and Google's servers.
Sure, some features will break, but it won't be any worse than being disconnected from the internet.
One thing is internet connections that are initiated by user, or in the background from the apps that user voluntarily installed and wants to provide them a specific services.
Another thing is when a phone has a bunch of add-on adware (in some cases spyware) ,built-in into the phone, without user's knowledge, without user's consent and most of the time even ability to choose. Adware chosen by the manufacturer or provider, that is serving their purposes.
That is a clear existing distinction. It has nothing to do with being a smartphone or having an internet connection in general, or using a smartphone for internet-related tasks.
I'm all for de-googling (and de-OEMing) our devices, but giving up all online functionality is not a viable alternative.
Also, is this list of ~10 hostnames readily available somewhere?
GrapheneOS doesn't use NTP at all, where are you getting your information?
Home Assistant is great and open source, but they refuse to publish to F-Droid over a name dispute from years ago (someone had an unofficial app and had refused to relinquish the name and F-Droid let the unofficial app keep it). Which means if you want the home assistant app to control your lights... Play store.
However. My ubports pinephone which is running Arch is missing a few key features. Performance is one. And I can't get the replacement mainboard that has the extra RAM because it's been out of stock for the past few months. And the other is Wi-Fi calling. I live in an area with poor reception and need wifi calling.I just flashed my android phone back from LineageOS because lineage wifi calling wasnt working.
I really really really want pinephones and librem 5s to work out. I acknowledge it is hard "lord's work" they are doing. but it's still not quite there yet. We're getting close enough that within a few years, I'll be using linux as my daily driver, even if I don't feel comfortable recommending it to my grandma.
> We have no interest in maintaining a branch of the app that doesn't depend on any proprietary services.
Developers explain why they wouldn't (naming issues, and "the point of the android app vs just using a browser is to have the location tracking, which requires google services") and then the thread was closed. And then I stopped following the issue and begrudgingly installed from Play store (I'm not de-googled, because like the GP mentioned, it's very hard to do even if you think you have done it, so in some cases I don't even try).
There are a LOT of locked threads in their github issues on the same topic. The F-Droid version appears to be a build of the appropriate repo, and the description says "This is the minimal flavor that does not have location tracking or notifications" (so the 2 things mentioned previously, location and push notifications are hard to do without Google).
https://github.com/home-assistant/android/pull/682 here is the PR that adds in a "minimal" flavor without the Google features. I stand corrected. A bunch of neat things have happened since I stopped paying attention, and I'm pretty proud of the HA team for getting around to resolving this amicably, even if they were a bit rough about it in the beginning.
edit: ... I just realized I installed Home Assistant from F-Droid when I just re-imaged my phone this weekend. Without even realizing it.
There is some HA cloud paid service IIRC - I can't speak to whether an app would be needed for that. But for my purposes the mobile web is more than sufficient.
Definitely a thing I could live with if web browsing was snappy enough (which for me on pinephone, it isnt). I could survive without a HA app, if it meant the rest of the device was usable... but that's not the state it's in for me, so for now, I use the app (from F-Droid)
So you know, that is because of a proprietary library that is included in Android. It isn't included in the AOSP build, which is why it was not wokring for a while (it is wokring now).
I am curious how WiFi calling works though. VoLTE is essentially VoIP (so data), I imagine that SMS on LTE is very similar, and I know MMS is over data too. My intuition would be that somehow, some sort of VPN is being established?
In comparison I saw some pine videos and every one seemed to be laggy and stuttery right at the main screen
I'm uncertain the root cause of this.
It could be hardware performance, but I would guess that's not all of it. It might be performance tuning.
I think apple does really good tuning on their hardware. The reason everyone senses apple is good/solid is because they've tuned the UI to be very responsive. It doesn't mean apple stuff will execute an app faster, it means that the touchscreen input and graphical output are highly linked/tuned. I think it's designed in.
I think that's probably the key to all of this. Put the touchscreen and the graphics in the same library, and dispatch to the app while preventing it from impacting the feedback loop. Then it won't matter that you have a slower phone or that your app is a script instead of compiled.
At least when it comes to comparison between these two devices, the answer is simple: it's the hardware spec. It's not like the Librem 5 uses some specialised kind of secret software - it's all FLOSS and it's being reused by various PinePhone distros a lot.
Configure the kernel properly - ensure you use the correct devices. There might be a specific driver for the device you're using and an emulated or software driver that takes over if it's not loaded. It could be that opengl is accelerated on one phone, but not the other. etc...
It is sad and amazing that not many more software developers, both big companies and indie devs realize how important that is. There is nothing lacking in modern generation of devices to have 100% fluent interface. The only problem is that the software in many cases doesn't optimize for it...
Personally I'm not that afraid of Google nor what they are up to. I think they strike a decent balance. I tire of the polemics against them.
What I see as critically important, as absolutely key to a vital, alive civilization is progress & exploration. Android is on version 11, and at this point, the mold has set. This world where you buy a phone, run the same OS you've always run, and wait 3 years until you have to throw it out (because it's running an antique kernel & security updates are ending) is an unexciting one, it is less than what human potential has available.
PinePhone is one of the forebearers of a better future. Which future? Any of them, all of them. The future that is coming that doesn't look exactly like today that doesn't look exactly like 5 years ago. The future where hardware is supported for more than 3 years. The future where there are multiple different interfaces & operating systems available for devices.
The future where people other than giant companies have a chance to build cool hardware. This one is a nod too to Quartz, their new/upcoming very-competent, expandable mid-range option, which they explicitly target as a featureful development kit to make cool hardware on. Battery charging, 12V, ePaper, camera, display, USB, PCIe,... just a lot of good robust well built features. On an open source board.
The fact that everyone is so up in arms against Google disguises what a boring, out-of-our-hands, staid, unchanging future we've been lead in to. Google is not the focus. The actual agents that we should be looking at, attending to, are ourselves. We've still spinning endless stories & selling fear of some other, but it is our own slumbering, our own lack of control & competency & creative freedom that defines the last decade of communicative capitalism taking over. PinePhone & Pine64 just want the individual human spirit to have a chance again. (And to band together as they may with other spirited journeyers.)
Excited as well by their last bit in the update, embracing LoRaWAN. Not just opening the door to innovation in cellular phones, but blowing open decentralized, user-empowering new means of communication.
Agreed.
I don't like to live in the country of giants because their sheer scale means they end up crushing the delicate innovation that sprouts up around them, usually more out of indifference than actual malice.
Depending on your predilections you can pledge fealty or fight them but it's also reasonable to find the niches where the giants don't fit and new ecosystems are able to flourish.
Your claims seem to contradict the FAQ (e.g. you mention connectivity checks which are mentioned explicitly). Have you reported any of these issues (e.g. [1])? What was the response? Can you point to any specifically problematic code?
I'm not involved with GrapheneOS in any way but these seem like easily-verifiable claims if true.
A couple years ago I rooted Android (Planet Gemini), installed my own root CA, forced all network through USB-C —> ethernet, connected the ethernet to a physical network tap, and decrypted almost all the traffic. With only a handful of common apps installed the (idle state, no UI interaction) phone-home traffic and telemetry was non-stop. A majority of it was to Google, blocking it made the phone basically non-functional.
There were also inexplicable calls to strange Chinese IP addresses that would only emerge every one or two weeks that I couldn’t hunt down the source of and Planet said they didn’t recognize.
I want network activity to be 100% correlated with my UI interactions including updates. I feel power users should be given that right and option. Windows and macOS (and sadly Firefox) are also miles away from this but Android was ridiculous. I haven’t tested iOS but I assume it’s about the same.
I'm looking at my abortive patchset against GrapheneOS from last year, which I never bothered to finish up to post, and will just pick a couple of random samples:
packages/apps/Gallery/src/com/android/camera/MenuHelper.java (calls maps.google.com)
packages/apps/Settings/src/com/android/RadioInfo.java (multiple connectivity checks pinging Google servers)
external/webrtc/webrtc/p2p/stunprober/main.cc (uses a Google STUN server)
packages/apps/Nfc/src/com/android/nfc/P2pLinkManager.java (calls to the play store)
I'm not saying any of these is malicious, my point is there are tons of these kinds of things littering the code. It will be extremely time-consuming to find and cut this stuff out of the base applications and libraries underlying installed applications.
And BTW again, this says nothing about SUPL, which is still tracked as an issue about which there isn't a lot of clarity: https://github.com/GrapheneOS/os_issue_tracker/issues/96
You can also see in that issue thread that the project lead does not see the project as focusing on de-Googling which is, in fact, what many of us want, and are wrongly projecting as a GrapheneOS project goal.
There are some legacy sample apps such as QuickSearchBox (a barebones search app using Google search) which we have listed in our issue tracker as things we need to replace with other apps. Those aren't part of the base OS and exist for testing the OS rather than real world usage. They need to be replaced rather than removed because the functionality will need to be included for compatibility. None of those apps make connections to Google simply by existing or from the user opening them, etc.
Using grep to search for Google domains and URLs across a huge source tree with more purposes than building the OS is not a viable way to identify connections that are made by the OS. A huge portion of that code is not used for the OS. A substantial portion consists of tests, sample code and code for other things like the SDK. A major portion is vendored external code (external/) where a small subset that's relevant is being used. For portions that are included, just because it implements functionality does not mean we are including the functionality or enabling it in the build configuration.
Intentional user connections, connected to user actions are one thing. Phone constantly sending pings to various addresses and services for no good reason - is very different.
I'd just go for his own words [0] since they're so easily available.
> Based on his strong personality, I did not think it likely any patches I wrote would be accepted by him.
I think it's best to give him a chance rather than assume. From my interactions with him, he seems fairly open to contributions since as you've pointed out, he also seems overworked.
> packages/apps/Gallery/src/com/android/camera/MenuHelper.java (calls maps.google.com)
I think you're talking about [1], which only happens upon explicit user interaction (the user clicking a button to show on a map).
> packages/apps/Settings/src/com/android/RadioInfo.java (multiple connectivity checks pinging Google servers)
This code seems to be here [2] now and is only called as part of an on-click handler [3], so again, requires explicit user interaction. As far as I know, there isn't even a way to access the screen that triggers this. I did it manually (adb shell am start -n com.android.settings/.wifi.WifiStatusTest) and the UI makes it clear that clicking the button will cause network traffic to go to "www.google.com", as that hostname is listed explicitly in the UI.
> external/webrtc/webrtc/p2p/stunprober/main.cc
I think you're talking about [4], which is example code. When I was searching for it, I stubmled across Google's search tool [5], which I used to search for other references to those hostnames. There don't appear to be any outside of example code and unit tests.
> packages/apps/Nfc/src/com/android/nfc/P2pLinkManager.java (calls to the play store)
If you follow the code further, it appears that no network traffic is sent to the Play Store. The code just creates a Play Store URL for an app package, presumably when you try to share an app with someone over NFC.
> You can rationalize away each of these individually, but I was at 41 patches when I stopped (including changes that address Google connections that GrapheneOS acknowledges). The cockroach infestation analogy is pretty apt. They are everywhere, and if you try to follow the code to assess for severity, it will be hugely time-consuming, so unless you have a team developing the patches, the safest thing is to pre-emptively patch out.
But what exactly is everywhere? It'd be nice to get rid of the code you've mentioned but there are no connections to Google going out without user interaction. I'm not convinced that there's a problem here to be fixed.
[0]: https://github.com/GrapheneOS/os_issue_tracker/issues/96#iss...
[1]: https://android.googlesource.com/platform/packages/apps/Gall...
[2]: https://github.com/GrapheneOS/platform_packages_apps_Setting...
[3]: https://github.com/GrapheneOS/platform_packages_apps_Setting...
[4]: https://chromium.googlesource.com/external/webrtc/+/HEAD/exa...
[5]: https://cs.android.com/search?q=%22stun.l.google.com%22&ss=a...
You're misrepresenting what I think and the goals / approach of the project.
> He doesn't necessarily view connections to Google servers that take place without explicit user intention/confirmation as problematic.
That's not accurate at all. Those connections also aren't being made by the OS.
> Based on his strong personality, I did not think it likely any patches I wrote would be accepted by him. Indeed, he thinks it best to "blend in" with other Android traffic. He is also, in my opinion, overworked.
I'm not sure why you got the impression that useful patches fitting the goals of the project would not be accepted. You say that you aren't criticizing me but at the same time appear to be trying to attack my character and misrepresent my views. Quite strange. It's also interesting that you have a bunch of past comments on this site doing the same, including making personal attacks on me and misrepresenting my views and GrapheneOS.
I do not think that what you're saying adds up.
> I'm looking at my abortive patchset against GrapheneOS from last year, which I never bothered to finish up to post, and will just pick a couple of random samples
Grepping through the source code for Google URLs does not provide a list of connections to Google.
The source tree contains far more than the sources used to build the OS, and not all of the code for the OS is used. It's also configured via build configuration. You could also grep around for Google URLs in a large codebase like the Linux kernel and claim that it makes a ton of undocumented connections to Google but that's not how it works.
> including changes that address Google connections that GrapheneOS acknowledges
There are no default connections to Google servers. I recommend reading https://grapheneos.org/faq#default-connections. Your implication that we are hiding something or unaware of some dark secret doesn't have a basis.
> I'm not saying any of these is malicious, my point is there are tons of these kinds of things littering the code. It will be extremely time-consuming to find and cut this stuff out of the base applications and libraries underlying installed applications.
That's not accurate. Reviewing a large amount of code is certainly time consuming, but there aren't actually there common changes to be made that you're claiming. You grepped around for Google URLs / domains in the code and then assumed that anywhere those were included must be a connection to Google that's used in the OS. That's really not how it works. Not every Google domain or URL referenced in the code is actually used (especially since large portions of the code are not used for an OS build from the source tree), and very few are used by default.
> And BTW again, this says nothing about SUPL, which is still tracked as an issue about which there isn't a lot of clarity: https://github.com/GrapheneOS/os_issue_tracker/issues/96
SUPL is carrier-specific. The server used is determined by the carrier. It's enabled when location services are active and you're connected to a mobile network if configured that way by the carrier. There has to be a fallback configuration. It's required by law. It has to be possible for SUPL to work for emergency calls even when not connected to a carrier. There is an open issue because we need to do research into it and figure out the best approach to it. We need to choose the best fallback provider, which could very well be Google is there isn't one with a better privacy policy. Hosting it ourselves as we do the time server and connectivity check server isn't necessarily realistic. It's not enough to just use some public cell id database.
> You can also see in that issue thread that the project lead does not see the project as focusing on de-Googling which is, in fact, what many of us want, and are wrongly projecting as a GrapheneOS project goal.
The goal of the project is offering great privacy and security. The focus of the project is implementing a bunch of technical improvements to achieve that goal. When we switched to the GrapheneOS connectivity check server, we made sure that we provided a way to opt-in to using the standard URLs in order to blend in with other devices as explained in https://grapheneos.org/faq#default-connections. Similarly, as explained there, we added a way to fully disable network time updates to avoid standing out as a GrapheneOS device based on using our HTTPS-based time update approach. Most devices do not make network time update requests since they get it from the mobile network, so blending in for that is easy.
It is not a "de-Googling" project because that would not give us any substantial work to do. AOSP does not have Google apps and services. It uses Google servers as a placeholder / default for certain things where a provider has to be chosen like the connectivity (captive portal) checks and time update server.
You claim elsewhere that Google DNS is used which isn't even true for AOSP. It uses the network-provided DNS servers. GrapheneOS also changes the fallback servers, so that claim is so far from reality. Again, I strongly recommend reading https://grapheneos.org/faq#default-connections and using more than grep and unverified assumptions to find things that need to be changed. You actually have to check if the code is used and if that value is actually used. For example, why reference the WebRTC reference implementation? The repositories in external/ are externally developed projects often included to use a small part of them or a tool they provide. A Google URL in source code that's part of the overall source tree does not mean there is a connection to Google being made by the OS.
It would certainly help if people like yourself were not prolifically spreading misinformation and false claims about the project and myself. Luckily, I am not writing most of the GrapheneOS code at this time.
> packages/apps/Gallery/src/com/android/camera/MenuHelper.java (calls maps.google.com)
Not used.
> packages/apps/Settings/src/com/android/RadioInfo.java (multiple connectivity checks pinging Google servers)
This is a developer / debugging UI with ping buttons doing what they say on the tin.
> external/webrtc/webrtc/p2p/stunprober/main.cc (uses a Google STUN server)
Code is not included in the OS.
> packages/apps/Nfc/src/com/android/nfc/P2pLinkManager.java
The code is not used, and it doesn't do what you say. It's code for creating and sending a link to an app on the Play Store. It isn't code for accessing it.
> And BTW again, this says nothing about SUPL, which is still tracked as an issue about which there isn't a lot of clarity: https://github.com/GrapheneOS/os_issue_tracker/issues/96
It is clear to us and I've explained it here.
There is nothing that needs to be rationalized away but rather you grepped through the code and your confirmation bias + lack of research led you to make bad assumptions.
You didn't submit issue reports, patches or even make an attempt to talk about this. If you had, it could have been explained that you were making mistakes. Perhaps you could have done something useful instead of wasting your time. Perhaps you could have informed yourself instead of leading yourself astray with your confirmation bias and assumptions. It doesn't really matter now. Please stop spreading misinformation about GrapheneOS and myself though. Leave us out of it.
I think it says a lot that your post was the highest voted and that spreading misinformation and making false claims is how you folks choose to operate. You do not do useful work, but rather try to hurt projects that do, in order to promote something else. Maybe you should promote it based on the merits instead of with false claims about us. I'm not sure why you're comparing our privacy and security hardening work with a hardware project which it could be used on in the first place.
If a 'strong personality' means an intolerance for dishonesty then that's certainly the case. Unfortunately, certain companies focused entirely on marketing / branding take the approach of spreading misinformation about others because they do not have any substance themselves. Producing an incredibly insecure product but branding it as secure and attacking others is par for the course. That's pretty much the whole privacy and security industry.
GrapheneOS is a non-profit open source project and we'll continue doing our work regardless of these kinds of continued attempts to spread misinformation about it and cause harm to us. Companies and products will come and go. We'll still be working on genuine privacy and security improvements across the software and hardware world in one way or another. We are not trying to sell a product and we don't have this motivation to tear down others with misinformation. If it's bad, then we'll say so. Our documentation is very honest about what we provide and what we don't provide in the various projects we work on. It is very open about the trade-offs of the design choices, etc. We're confident that the project will succeed on the merits without needing to make up a lot of BS about it and about others. We intend to work with hardware partners and others with the same kinds of goals and approach: providing a high level of privacy and security alongside usability, with an approach that's open and honest.
We won't attach our name to a device that did not meet a high level of privacy and security by shipping a modern, properly configured SoC for production use with proper support for firmware, etc. for years and all the standard hardware security features (verified boot, HSM-based attestation, HSM-based keystore, strong hardware encryption / key derivation support, proper IOMMUs, modern exploit mitigations, and all the other stuff we expect). We'll happily include minor bonuses like a Sensors Off kill switch that truly works as a mitigation for a device compromise based on a clear threat model for that (i.e. if it's meant to do something like stopping audio recording, then the speakers and all the sensors usable for that have to be dealt with too). We're 100% open to working with a vendor sharing those kinds of goals.
Note that we do not provide an exhaustive list of these kinds of connections for the Vanadium browser once a user opens it and begins using it at this point. It's in an earlier stage of development than GrapheneOS itself. On the other hand, the Vanadium WebView will not make any connections that have not been requested by the apps using it. A normal Chromium WebView would fetch variations.
Separately from the default connections by the OS, if you use a carrier choosing to use Google servers for RCS, etc. then you'll also end up with connections to those without disabling the features. That's true outside the Android Open Source Project too. Some carriers host their own services on Google's cloud. There's not much that the OS can do about carriers using their services.
Carrier configuration also determines how features like SUPL which provides supplementary location information when location services are enabled.
Modern carrier-based calls and texts are data-based which means the OS has to connect to the servers configured by the carrier. That traffic is visible as OS traffic.
We plan to add a separate section documenting stuff about carriers but it's beyond the scope of the default connections made by the OS, since it's what happens when you've set it up with a carrier. Our focus in this area right now is on implementing an eSIM activation app to support eSIM in GrapheneOS. It has OS support from AOSP but it doesn't have an activation app since AOSP doesn't include the Google apps and services.
Par for the course in embedded development. Tuere are plenty of bad things to be said about AOSP, but it's still way better than any of its Linux-based forerunners. Remember the OpenMoko?
(Of course, this is not to say that further improvement is not possible! So, I might well agree with the gist of your comment from that POV.)
It may be, but I don't don't see why it must be that way any more than it must be that way on the desktop. At least give me full exposed control over whether and what connections it makes even if the defaults are what they are now!* I can live with that, if there is graceful degradation. Android is not written with the idea that anyone should have that kind of control over their own device.
*I get that Google doesn't owe this to anybody, which leads back to the need for a privacy-first/RYF type of phone HW and SW.
"If the Pine64 ecosystem gets to the point of working as well as the Linux desktop , it will be one of the very few ways to ensure your phone is not making unwanted data transfers to Apple and Google's servers."
There's a value add in not connecting to their services.
Who pays the cost of those Google-initiated data transfers to their servers.
As an end user, I do not wish to donate the use of my internet subscription and network to a company with billions in cash on hand.
The default connections made by GrapheneOS are entirely documented at https://grapheneos.org/faq#default-connections. No connections to Google are made by default. This is not the result of purging connections from the source code. It's very close to the default state of the Android Open Source Project. Google services are implemented as part of Google Play services.
The only way that you would get the impression that there are many connections to Google in the source code is if you look at the test cases, sample code and unused functionality that's not enabled by default.
Once you've inserted a SIM card and started using a carrier, there will also be connections for supporting the carriers. Some of those carriers use Google services themselves regardless of which device or OS you choose to run.
> Just to name a few: SUPL, WebRTC probing, automatic previews of YouTube in the Messenger, Google maps lookups in Dialer and in Photos, myriad connectivity checks, etc.
No SUPL connections are made by GrapheneOS on the supported devices. SUPL is carrier-dependent. The connections are made by the radio based on the carrier configuration. Using Google's service is one of the options. This is part of location services and isn't enabled by default. It's required by regulations to have support for it when making emergency calls, but not beyond that. The configuration is fully in our control. We haven't chosen how we want to approach carriers without their own setup for it. It does have to use something in that case, just like the fallback DNS servers, particularly since this needs to work for emergency calls. Which implementation would you prefer to have as the fallback?
The connectivity checks use our servers by default. It is opt-in to use the standard servers to blend in with other devices. That is needed to avoid being trivially identified as a GrapheneOS user to the network, which is why we offer it as an option and document it in https://grapheneos.org/faq#default-connections.
The rest of this is inaccurate too. You're mixing talking about the Android Open Source Project with Google apps and Play services which are not included in it. You're also referring to test cases, sample code and unused code including in AOSP sample apps and the substantial amounts of the source tree that are present for development or opt-in inclusion. Only a fraction of the source tree is actually used to build the OS. The source tree is also used for the SDK and a bunch of SDK packages among other things. You cannot simply search for a URL in the source code and make the assumption that it implies there is a connection to Google in the OS. That's not how it works.
> After going down this rabbit hole, it became clear to me the only way to win is to not play. If the Pine64 ecosystem gets to the point of working as well as the Linux desktop (been daily driving some KDE on top of GNU/Linux for 10+ years, with only one major issue due to buggy drivers), it will be one of the very few ways to ensure your phone is not making unwanted data transfers to Apple and Google's servers.
Pine64 is a hardware company. You can run an Android Open Source Project derivative just as you can run an OS not based on the Android Open Source Project on another device.
As a final note, I would like to point that the user ThenAsNow has a clear history of spreading misinformation and dishonest claims about GrapheneOS on this website. They have made false claims about the focus and goals of the project, along with presenting many objectively untrue facts about it. They've made attacks on the developers. I'm quite curious what their username is elsewhere because this kind of duplicitous behavior and attempt to undermine the project with misinformation is definitely not acceptable for someone supposedly participating in our community. They have repeatedly made these false and baseless claims on multiple occasions. They claim to have done research and worked on it but at most they've glanced around at the source code and made incorrect assumptions about it.
https://wiki.postmarketos.org/wiki/PINE64_PinePhone_(pine64-...
(My older, pre-Phosh notes: https://www.neilvandyke.org/postmarketos/ )
If I end up moving to pmOS+Phosh for a daily driver phone, I'll have to see what the Librem 5 pricing and availability is at that time. I'd like to support Purism, and their hardware might turn out to be more trustworthy, but it's pricier, so it'd have to be a daily driver that I need.
One backup/stopgap option (besides my iPhone and collection of a few developer devices) is Replicant (FSF-blessed Android fork), and I have a couple of i9300 phones for that. Practically, it's Android that's been gravely crippled, for better or worse. pmOS+Phosh seems a more desirable ultimate destination, than Replicant trying to maintain a fork of someone else's massive codebase that's developed with philosophical differences and vastly more resources. But Replicant does have more mobile polish right now that's expensive to recreate, plus some nice open source Android apps like K-9 Mail.
As a form of advertising, these posts are spectacular. I find myself just buying everything they make. It feels so genuine.
The marketers on this forum can learn from these guys. Frequent, jargon-free technically inspiring posts make me spend money.
And, y'know, actually selling stuff that people want. For me, at least, it's the specific combination of "blog post talking about this neat new thing that I want to buy". Which, granted, is true of nearly everything that Pine sells:)
That means we can dream with proprietary blob-free phones in the not too distant future?
The ADSP firmware is the firmware that does all of the heavy lifting for physical communications.
[1] https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd...
That's also why it's feasible to re-create userspace from scratch.
Anyway, it's gonna be nice having a lot of space to do interesting stuff in the modem's SoC.
True though, most of them don't do anything interesting, or only one interesting thing for the thousand that could do in a typical scenario
I applaud your enthusiasm but there's no planet on which Pine64 replaces Google or Apple. Unless they somehow convince the likes of someone like Samsung to make the switch, their market share will be measured in basis points.
The average consumer doesn't care at all how Google and Apple treat developers. And the average developer is going to go to the place they make money, even if it's more painful to do business with those giants.
I don't even think Samsung can get away from android. They are trying with tizen but the ecosystem is hard to escape.
rewrite your windows mobile 5/6 apps for windows phone 7? ok, its a brand new platform, i get it.
rewrite wp 7 for windows phone 8? ok... (there may have been wp7 mango that needed tweaks but my memory is too fuzzy)
rewrite windows phone 8 for 8.1 ? cmon now
rewrite windows phone 8.1 for wm 10? no
1) about the phone not shipping with malware
2) about the phone not working after 2 years
3) apps no longer working because the only OS vendor for your phone disagrees about something with the developer
As for what developers care about: commercial devs will avoid the pinephone and IMO that's a good thing.
Given the number of people who have no issues installing Zoom or TikTok, I'm not sure I buy that.
>2) about the phone not working after 2 years
The average consumer has to have the latest and greatest every 2 years whether the old phone still works or not.
>3) apps no longer working because the only OS vendor for your phone disagrees about something with the developer
The number of parler users willing to give up their iPhone for parler isn't even a blip on the radar. They won't even switch to android for it, why do you think they'd switch to Pine?
My experience is that my older relatives get new phones frequently because they get their old ones so malware laden that they no longer function correctly.
That and apps grind to a halt because the developers use top of the line hardware and don't notice how wasteful of resources they are being.
a) the bank app to install
b) the whatsapp or whatever "everyone my age uses that" they are using to install
c) candycrush or whatever is the trendy game of the moment to install
d) Netflix/Disney+/... app to install
I really doubt these will ever be ported to PinePhone. And then, if they were, I am sure malware would also be ported, so back to square one.
Reports on the PinePhone forum suggest it'll be 4–5 years before the next PinePhone with a better chip comes along (and by then, even that chip may seem old), so don’t expect this situation to change anytime soon.
Vanilla Linux on the PinePhone is also missing numerous battery optimizations found on Android that would give people the battery life they expect today.
Anyway, I feel like an ortholinear keyboard woukd be better, maybe with an enter key in the middle to space hands more, like I wrote in the past: https://forum.pine64.org/showthread.php?tid=10885&pid=86112#...
I might try to print an alternate case and PCB. A forum post mentions joycons, joycon grooves could be a fun addition :P
It seems like there is only the one brand, but probably there are generations of EDP ports or flavors relating to maximum size, color/gray-scale Levels, etc?
I hope it is very similar to the situation with HDMI, where the interface doesn't vary, but alternatively, it could be a matter of proprietary things not being discussed clearly because of NDAs, etc.
I had a lot of fun when after clearing the display and writing new image to it, the old image also faded in again into existence, which is apparently something that may happen if not everything is aligned correctly. There's a lot of hidden proprietary woodoo that you'll have to uncover to drive these displays correctly. There are some displays that hide this inside some controller and give you a nice SPI interface, but for maaany displays you'll just get a raw interface to the gate/source drivers + access to 5-6 different "high" voltage sinks and similar number of clocking/control signals that you have to drive precisely too (voltage/timing-wise at low 100's of ns level of precision), and the rest is up to you.
Source: (doing a lot of reverse engineering to put mainline Linux and write a driver for some broken display PocketBooks I bought from auction site and repaired with replacement displays from China) https://linux-sunxi.org/PocketBook_Touch_Lux_3
Fun fact: vast majority of PocketBooks out there drive eInk displays by DMA driven bitbanging from a generic LCD controller, without any specialized eInk controller.
Good luck for your project, I have yet to dig into e-ink devices, but that's something on my radar. It's a shame the firmware of these devices is not open, I bet the community could improve it a whole lot.
Also thank you again for your work on the Pinephone ;)
OTOH, if you don't mind full refresh (shaking the ink into uniform white by making the whole display black/white/black/white repeatedly a few times) between updates, these displays seem to be quite forgiving, in my limited experience. So it's not all doom and gloom. :)
As a plus, this is likely the most portable way of driving these, voltage levels notwithstanding. I guess you also have "smart" and "dumb" screens, some that include temperature sensors, etc?
* support for openbsd or freebsd (I forget which pfsense uses) and in particular an image for pfsense that supports the hardware
* if you need two NICs, you will have to use the rockpro64 with a PCIe card or maybe a USB3 based adapter
some of the other screenshots look like gnome, but that one has miraculously not giant widgets/windowbars.
also, does anyone know what those earbuds are?
Since almost almost every country have their own rules & compliance regarding tele-communication/radio hardware Pine64 products with them are plagued with shipping issues if not straight away ban on them. Resellers have the means to get them resolved.
I don't think selling their products only through their website is doing justice for their goals albeit better markup on relatively inexpensive devices. Raspberry Pi Foundation's ability to ship products to over 50 countries through their resellers on the day of announcement is underrated.