I'm switching my phone from Android to Linux
runarcn.no
runarcn.no
I think the real problem is Google Play Services. It's far, far too tightly integrated in a way that it just seems like Android was designed to be unusable without. It's installed as a location manager internally, which gives it a shitload of permissions by default that you never grant it. There's absolutely no reason everything (notifications, the app store, some location services) has to be packaged together into one thing instead of each having its own module that can be removed at will. Play integrity just plain shouldn't exist and as far as I'm concerned is purely there to ensure no one creates a real play services alternative or another mobile OS with Android compatibility.
The ideal outcome for me would be keeping Android but effectively dissolving Play Services and instead having the concept of a core services, where instead of apps choosing to use Firebase for notifications, they instead bind to the system notifications service, and as the user I choose which implementation I want, preferably with it not installed as a system app. I'm well aware that's not going to happen, but it seems like the most practical way to break up the Google/Apple monopoly to me, Android's great but Google's services aren't.
This is somehow by intention. In the ramp-up of Android adoption, Vendors and carriers started to fork Android and deviate too much from the core. Google needed a leverage to tie them to stay compatible to the ecosystem, Google Mobile Services (GMS) was the tool to do so. "Pass the compatibility test suite and you qualify to preload GMS".
Then, at some point, Google implemented API's in the OS which call Google's cloud infrastructure (e.g. Location services), which they didn't want to commit to the Android source for the risk of them being forked and modified, so they started to implement them in a precompiled "Google Play Services" module.
Over time, it seems Google Play Services became the preferred vehicle for Google to rollout any kind of API-changes to have them applied on all devices immediately, without waiting for the vendor to do an OS-Upgrade.
The result is that Google now promotes Google Play Service API's as the way for the most widely compatible implementation of an app. Which is...not wrong, but in the larger picture also the reason why Android is not considered "real" open-source (anymore).
> The ideal outcome for me would be keeping Android but effectively dissolving Play Services
Agree. There is still a very good OS in there, clearly written by considerate SW-Engineers.
I wonder if further developing microg or similar would be a better use of resources than Postmarket, Ubuntu touch etc? Would that be a faster path to wider adoption and therefore better chance of challenging the Android/iOS duopoly?
Not really. That's a different thing viz. Android Pony Express: https://source.android.com/docs/core/ota/apex
Yeah, it wasn't even totally the wrong thing when it happened. It was something I liked because you had both the manufacturers and the carriers getting in the way of OS updates.
For example, I bought a new Samsung Galaxy 4 years ago from Tmobile. Tmobile NEVER updated the phone past the initial release, even though samsung did the next android version (I forget which exactly, 9, 10?). But even samsung had dropped support for the phone basically after that single update.
The google move to pull things out of the OS and push them into the play store was welcome because it meant you were less likely to have unfixed bugs and problems due to vendor laziness.
But of course greed has taken over and now google is trying to change Android from an open source OS to a closed source one. Increasingly making it hard for the likes of GrapheneOS to exist.
First came Project Treble, where Android was refactored to actually have a stable ABI for drivers, by pretending Linux is a microkernel, all drivers run in userspace, use Android IPC to talk with the kernel, and are implemented in a mix of C++, Java and more recently Rust.
Since Android 8, traditional Linux kernel drivers are considered legacy.
https://source.android.com/docs/core/architecture/hal
However adoption by OEMs was still not enforced, because "our partners freedom" kind of thing,
So Project Mainline come to be, where Android was further modularised and userspace components could be updated via PlayStore.
https://source.android.com/docs/core/ota/modular-system
With, as already mentioned by others, APEX as delivery format,
https://source.android.com/docs/core/ota/apex
Naturally all of this only works via PlayStore services, and is related to the "Google Play System Update", or similar, that you can find in the settings section.
GKI (Generic Kernel Image) support did result in significant kernel driver changes by requiring them to use a far smaller subset of the kernel API and work with a GKI image for testing. Certified devices don't need to use a GKI in production and mostly don't but do need to work with it for testing. That's supposed to make it possible to much more easily update the kernel in a similar way as Treble did for the OS. This has forced writing drivers in a way that's much easier to port to new kernel versions which encourages updating the kernel to new LTS branches. It has the downside of making Android itself upgrading the AOSP kernel trees to new LTS revisions within a branch much harder since there's supposed to be a stable ABI. It would be much more purely beneficial if they dropped the stable ABI while keeping the restriction on the subset of the ABI usable by modules.
Implementing drivers largely in userspace is entirely a choice for the companies writing the drivers. It's much better for security and robustness to have most of the code in sandboxed userspace processes than the kernel. There's no requirement from Android or Google certification to do this. It's simply regarded as a good engineering practice by most. The reason the Linux kernel puts so much into the kernel is because it doesn't control the userspace. They're largely putting code into highly privileged kernel space for organizational reasons. If they had a way to write large portions of the drivers in userspace, then many upstream Linux drivers would likely be written that way. It's a huge problem that there isn't a standard and accepted way to do that rather than a good thing. Many out-of-tree drivers for Android devices largely being in isolated userspace processes is a major security benefit which shouldn't exist because upstream drivers should be able to be written as sandboxed processes too.
The APEX modules used as part of the device independent base OS are open source parts of the Android Open Source Project. Google Play mainline updates are Play Store shipped builds of the code for those for Google Mobile Services devices. It didn't result in anything being removed from AOSP.
In GrapheneOS, we have our own app implementing both. We host geocoding via Nominatim. We currently use Apple's location service as an opt-in feature via either direct usage or our own proxy but we plan to provide our own database instead of only a proxy.
Google Play services is nearly entirely for using Google services rather than functionality independent of Google services. Certain functionality such as security key support was put into Play services to make it available on all devices despite not shipping with it. In the case of security keys, AOSP now has a standard API for it with apps able to provide it. There are multiple apps providing security key support as a supplementary credential manager which can be used alongside a main password manager.
It is true that Play services sometimes ships new functionality unrelated to Google services, but they didn't move functionality from AOSP to it. It's new functionality which wasn't previously in AOSP. Our main issue with it was what they did with security keys but they promised us it would be resolved and years later it was resolved. It took a lot longer than it should have and it's wrong that it happened the way that it did but it's not an issue anymore.
The main issue are the licensing terms for Google Mobile Services and the Play Integrity API device and strong integrity levels enforcing licensing it. That's how Google locks out competition and locks in OEMs with them. It's the massive problem which needs to be addressed by regulators, not any of the things they focus on instead.
Android gained market share through being an open platform with open source code. Google should be forced to stop degrading that and locking out competition. If they want to implement fancy things in Play services tied to their services, that's fine. People can compete with them. On the other hand, what they're doing with the Play Integrity API and beyond it is not fair and prevents competition.
Unfortunately, regulators largely don't understand how Google harms competition and solves the wrong problems. The remedies for their anti-competitive behavior consistently don't address the core issues and allow it to continue getting worse.
Wasn't the point of Play services to enable keeping OS "updated" regardless of the manufacturer schedule? Which is to say: they are tightly integrated because they were designed to be part of an operating system that Google can keep updated through Play Store even if the device OEM is slacking on porting upstream updates to the users.
I'm old enough and was very pro-android in the early days when it first released. I absolutely remember the frustrations around having vendors just REFUSE to update the OS on devices. Even things that were brand spanking new often got left to rot, and the OS updates in those days were genuinely meaningful software updates - Lots of new capabilities.
So I was actually ok with Google going down the route of moving critical software into an installable package that they controlled, that would provide a way to get new capabilities onto devices that manufacturers didn't give a shit about anymore.
---
But the problem is that "Google" today sure as hell isn't the google that I liked back then (and even that google was starting to shift tone).
And now this package is a backdoor that they can use like a beat-stick to force vendors to stay on their version of Android, and it functions to make "Android" (the distro that users actually use) functionally closed-source and non-permissive.
---
I still strongly believe that the appropriate regulation for this situation (across both iOS and Android) is that the company that makes the OS should be prohibited from running any sort of app store, and app stores must be selectable at device initialization (ex - the Internet Explorer ruling, but for app stores).
WebOS is anyway only relevant for TVs, and any PWA will do.
Google may think it's important to keep WebView always up to date with Play services. I couldn't care less. I still have to buy a new phone to get all updates.
Just no. I developed for android for a long time and I have seldomly seen a worse and more confusing SDK and code base. I can give you many examples but the core layouting algorithm having quadratic complexity with the number of widgets and the single base-view class having 60.000 lines of code are just the tip of the iceberg.
When was that?
My gripe with android is that I think it wastes a lot of resources by being very inefficient in software. Just enable the debug mode to see what portion of your screen refreshes and repaints and stand back in awe while nothing changes and you still get hundreds of repaints.
And you are positive that this hasn't change in almost a decade?
> My gripe with android is that I think it wastes a lot of resources by being very inefficient in software.
As opposed to what? This thread is about Linux on Mobile. Are you saying that Linux on Mobile is a lot more efficient than Android? Like do you get more battery life with Linux on Mobile for the same usage?
No, it is a guess.
> As opposed to what? This thread is about Linux on Mobile. Are you saying that Linux on Mobile is a lot more efficient than Android?
Opposed to iOS. Android is largely Linux, I think Linux is great and highly performant, just the Android SDK isn‘t.
So you say that "[Android] wastes a lot of resources by being very inefficient in software as opposed to iOS". How do you measure that? In my experience, people who have smartphone need to charge them every one or two days, and the battery gets worse over time but it usually stays usable for a few years.
If Android was "a lot less efficient", I would expect to see a difference in battery life. Do you?
> Android is largely Linux
Android (the OS) is largely NOT Linux (the OS). And if you compare Android to Linux on mobile, in terms of battery life, it is extremely different. It's pretty much what makes Linux on mobile a no-go for pretty much everyone (in good approximation).
You are allowed to not like Android or the Android codebase, but it is incorrect to say that Android is inefficient.
Permission model of Andorid is hostile to the user and is designed to the benefit of the manufacturer. It undermines the users' ability to take advantage of their computer but allows the manufacturer / whoever installed the system to have undue and unwarranted access to the device.
My experience of using Android is very similar to using a corporate laptop configured by the least competent IT department of a large US bank: you are not allowed to do the basic and useful things, you are required to jump through a lot of hoops to have the remaining absolutely necessary things done, you cannot eliminate hostile functionality, you cannot be sure your personal stuff will remain personal (if it ever was...), it's a system that will automatically do things to you that you don't want done...
Basically, using Android sends me back to the early 2000s when this kind of setup was typical for MS Windows computers given to employees in large US companies.
Applications can specify that they can't be backed up, and you as a user have no way of overriding that. Highlights on my smartphone are Fennec (Firefox), Termux, Cromite, Element, Syncthing, various videogames and other utilities.
I absolutely want these backed up, and on any sensible system I'd just point restic to their storage locations and be done. On Android I need an arcane mess of Titanium Backup and TWRP, and god help me if I ever have to recover from a backup.
What is even their motivation to not be backed up?
I have spent the past 2 years off and on modifying AOSP (for "reasons") and I am constantly amazed the poor quality of the code base and badly architected the overall system is.
It's a bunch of re-inventions of the wheel (start-up daemon manager, IPC, HAL, GUI, etc) with the "upper layers" written in Java with a mix of C/C++. Mixing the metaphor of a Java "run time environment" with a Linux-based kernel results in a hodepodge of pieces and having seen it up close it makes sense why "Android" user experience varies so much device to device.
Did Android need it's own bastardized libc for example (bionic)? Did Android need to have it's own start-up daemon manager? A "HAL" in C++ (wrapping Linux kernel capability) with a bunch of bridges to Java via JNI?
Writing an application for Android is also a byztantine mess of NDK, SDKs, Java build systems (Maven, Gradle, etc), XML files, Java, Kotlin, etc. Why can't icons just be SVGs, why do these have to be in some XML-formatted resource? The list goes on.
Yes, it has a few warts, still much better than fitting UNIX with X Windows on a phone, with a C SDK, like FOSS keeps trying since Open Moko.
Same kudos goes to Apple by pushing Objective-C and Swift, no matter what.
Microsoft unfortunately no longer seems to know what Windows is supposed to be.
And what do you think iOS / macOS is based on? UNIX userland from the BSDs with the Mach kernel, Mach IPC, etc. Fun note: It's easier to cross-compile standard UNIX utilities and programs for iOS/macOS than it is Android since Android effectively has its own user-land.
macOS and by extention iOS are, by comprarison to Android, actually pretty well architected. The choice of kernel (Mach, Linux) is really not the limiting factor, it's how you plumb together the layers above the kernel and that's what Android has done badly.
Lastly, just because OpenMoko may or may not have done something ideally (~20 years ago?) doesn't mean the current efforts (postmarketOS, Plasma, PHOSH, Sailfish) have done it badly. Actually most of these efforts are leveraging the fairly refined parts of a modern Linux environment and are MUCH easier to work with at the lower levels than Android.
Android is great dragging devs screaming into modern computing, from Xerox PARC ideas.
Apparently you missed the part that Apple has already deprecated POSIX APIs like the usage of sockets for new networking capabilities.
Or the plethora of ways classic UNIX doesn't work, which is what happens to everyone that buys Apple as shinny Linux.
However the point was about mobile OSes, try to ship apps on the store using only UNIX APIs to see how far you would get on the approval process.
You could not design a worse system than Android, even if you tried to design the worst system possible
It starts with an upstream GrapheneOS build and modify the system image (super) in place, signed with the published userdebug keys.
Web will be locked down too, via secureboot stack browser integration (not -s, it's already actually monopolised to chrome only, as FF lives on full life support from Google).
Very sad how it was allowed to happen so easily.
Imagine traveling somewhere, and run through the things you'll need to work without tinkering. Camera, eSIM, GPS/maps, more "exotic" messaging apps that for some reason people use instead of Whatsapp.
It seems like most Linux phones are barely suitable for someone that just goes home to work 99.999% of the time.
I really hate modern Google.
There isn't even an option to say "I know what I am doing and if a hacker takes all my money I won't cry to the bank". Probably the banks prefer that no emulators can snoop and see how exploitable their apps are.
Also, you can use the bank's website for most tasks.
I think most non-techies could happily do this.
I've read somewhere that some banks will let you use their SMS 2FA as long as you haven't already used their mobile app.
Like, because of a disability, or because you don't have a smartphone? In the latter case, would it work to just go to the bank with a dumb phone?
They also have a different "Talk Device" that is specifically meant for people with disabilities and such, which is supposedly free to get once (80€ for replacements), but the page doesn't specify who can order it.
I used their App previously, and can just switch back to using the website, after authenticating via both sms and e-mail.
For example my phone provider has really overpriced international fees ($10 / day) so instead I use an eSIM which usually only comes with data. That means I lose the ability to use text messages or phone calls for any form of verification. A number of banks and other sites also block Google Voice / VoIP numbers.
I feel the same way about ISP modems (not routers). As long as I get an Ethernet port and the modem isn't doing anything untoward, I don't see any problem with letting the ISP's network termination equipment exist inside my house. Some people think there should be a right to hand off the connection as DSL or fiber and buy your own modem, and I think you should be allowed to do that at your own risk, but I don't think the ISP should have to support it. Particularly with PON fiber or CATV, it's actually a bit dangerous to let the customer use random modems as it's a shared medium with half your street and you wouldn't want to jam them.
Well, I fear that loophole is quickly closing with little fanfare.
Pixels (barelly) running a binary-blob-heavy port of android is far from what is being discussed here. In fact, that is intended as a misdirection and you fell for it by bringing it in here.
The companies selling you the devices make 1/3 (appl) to 3/4 (alphabet) of their entire revenue on Advertising.
Owning the indentity layer ensures they get fully addressable ads, which is the difference of $12 per impression instead of $.0001 per thousand impressions. But nobody is ready for this conversation.
That is how a free market works, however it doesn't really cover the "I need to function in society and there are no good options for this device type that have the features I care about" problem.
When your choice is between the NutPuncher 9000 and the BallCrusher 17, it's something of a false choice.
I’m not ok with it being the only option.
A great deal of people don't even understand the concept of installing software if it's not via the App Store, nor do they understand what's involved in the process. Explaining the issues of having a central authority is one degree further.
says everyone, using chrome. sigh.
It's unfortunate that democracies foster a system of corporate corruption here.
I notice this often when I try to, say, use firefox and my bank says, sort of "nah, use chrome only". And they only ever assume people to use either OSX or windows; Linux is kind of forbidden in the sense of "won't support it". But often it does not need any support, those browser or OS checks are wrong to begin with.
Instead, call them. Insist to talk to a human. Corporate really doesn't like call center calls, and they usually have monitoring set up to track why people are calling.
If I insisted on not using my phone, perhaps, I could... mmmm... hire a lawyer? to get the bank's attention... otherwise I'm completely at their mercy.
At my non-existent bank branch?
Any bank I'd actually want to associate with? No.
- OEMs have poured an enormous amount of resources into the camera software, Linux cameras are years behind from what I understand. - Android/iOS have thoroughly optimized the UX in all sorts of subtle ways, the big one being their keyboards. I literally can't type a single correct sentence on any of the mobile linux keyboards that I've tried because there's so much proprietary magic needed under the hood to figure out what the user is trying to say (autocorrect mostly, but I recall something about how apple also virtually adjusted the sizes of the keys to make it easier to type) - GPS, banking, and now keys for your house and car all need to work.
This will become an assailable salient soon and by 2036 we should have dozens of competing phone operating systems and vendors.
We're going to do the same for robotics and everything that gets shipped to us.
What have people done with it? Some mediocre support in libcamera? :) I don't think lack of handholding is an issue here.
Some devices "work" without having real support by having some binary blob or third party code which is written against a specific kernel version. The code has to be updated when the kernel changes, which is why it's supposed to be in the kernel tree, but because it isn't the kernel developers don't know anything about it and aren't maintaining it. So then instead of working indefinitely it works until whenever third party stops updating it for current versions of the kernel. Which is why all the drivers should be in the kernel tree.
Of course, Apple isn't really that interested in supporting Linux since it's a direct competitor to macOS rather than a way to reduce their dependency on Microsoft/Google, so their hardware is more likely than most to be stuck using some reverse engineered alpha driver or proprietary blob extricated from the macOS one.
Not saying pushing mainline is bad. But assumption there's any kind of "support" is wrong. Code is there. That's all. You have to support it if you want it to work.
(This is very particular to HW/drivers support, Linux core is supported well, I guess.)
Also RK3399 is not just pinephone pro, it's way more prominent in other things - notebooks, SBCs, ... whatever. Same ISP is in i.MX SoC, which covers another whole range of devices.
Not sure what 100's of millions shipped units to disinterrested audience achieved?
And all software is replicable.
keyboard text prediction is no more complex than some of free/open AIs that we already see in the wild.
If google doesn't shut things down, then just continue to use AOSP, which is a fine open source OS for most people's use cases.
That's the thing that allows them to catch up for the mainstream. Some nerds can use it and tolerate the rough edges, so they do. But the rough edges are still rough, so as more people use it, the small percentage of people willing to actually do something about it becomes a larger absolute number of people, and then more of them get shaved off. Which causes more people to use it.
The point when the devices are usable comes long before the point that they're what the majority of mainstream consumers are buying. Desktop Linux has been there for more than a decade and year after year its market share slowly goes up.
There isn't going to be a single year when its market share goes directly from 3% to 97%. There is going to be a year that its market share gets into the double digits and then continues slowly going up.
Because of Proton, Microsoft gave up its effort to block Steam and move all Steam games to the Microsoft Store.
In practice, I've failed to ever get it running on several attempts so far.
Are you all seriously arguing/considering that the barrier is something like "innovation" or "UX" or "hard work at improving the OS?"
Like seriously?
Come on. By now we should know what actually happens. The entrenched carriers will fight tooth and nail to prevent this. That's the real threat. It will look like the above, but like e.g. Google lying about why it got rid of Google Reader, the real story will be "monopolies gonna monopolize."
Gaming, it is mostly Windows games via Proton, hardly any different from using MAME, FS-UAE, Amiberry,...
Graphics, most of the well known commercial packages for VFX, 3D modeling, visualisation, lack a Linux version.
Laptops, just two years ago I failed to make UEFI work with the myriad of distributions I tried out, unless booting from external USB drive, and even then there was the whole termal configuration.
I daily drive SailfishOS on Jolla to see if it can be enough.
The only issue I've had is the new rust desktop from pop os, but I just pop back into gnome and everything is golden. I hope they get their issues solved soon but it was just released 6 months ago or so. I can understand there's some bugs to work out.
Google opted against putting the physical components needed for USB-C DP out until the Pixel 8.
Now they are locking it all down.
And it seems to be that Google is increasingly regretting that decision and closing things down bit by bit, from Play store policy, all the Play services BS, to how they ship security patches, and now all the developer verification. Google discovers that it's easier to make money if they just control everything.
As everything else, especially anything with a GPL license, has been removed already, with exception of the Linux kernel.
Linux.com refers to the kernel itself as an OS though, I think to relate to people who have only heard of OSes like Windows. And calls Android a platform based on the Linux OS :S
What diminished the day-to-day difficulty for you? Is it because the ecosystem became more mature, or did you "crack the code" for how to interface with everything you needed from your phone? Is your use-case for a phone wildly different from that of a typical user?
It's really cool to hear that someone is successfully daily driving it and making this ecosystem work for them!
Neither! I just got accustomed to doing without stuff. That’s an effect I wildly underestimated.
Many things are still difficult (looking at you, CloudFlare [0] and DataDome [1]!) but I think I’ll manage.
> Is your use-case for a phone wildly different from that of a typical user?
Not really, I guess.
I could probably go on and on. It feels like my little personal pocket computer rather than an appliance that someone lets me play with on their terms.
BTW. Funny how it can go from "it can't possibly replace Android/iOS" to "how is that different from Android/iOS?" :)
In the past I have used a Neo Freerunner (with Om2007.2 and later SHR) and then a Nokia N900 (with Maemo 5). The former demanded plenty of your attention but could be made to work well enough, while the latter was a really nice yet exceptionally hackable consumer device. Before I switched to a Librem 5 I had carried a second phone with Android for about 3 years as the N900 was already too old for comfortable web browsing and there was nothing else on the market that I'd consider worth switching to for a while - but that was the only such exception.
In the past I used Bluetooth for keyboard and mouse when I connected the phone to a monitor. (I no longer do because the USB port on my L5 has broken down so badly that it can no longer maintain a DisplayPort Alt mode connection.)
I’ve never used Bluetooth for music or similar, it keeps stuttering horribly on my L5. No idea why it does that!
I’ve never used multimedia SMS either. Almost no one uses SMS or MMS in Germany. Signal barely works via the Electron app (and signal-cli), so that’s what I use for messaging. WhatsApp doesn’t work because I have no iOS or Android to tether it to.
I can’t use public transport apps, which is a shame because I live in a city center where I depend on public transport. I download my public transport ticket from a private API once a month via curl.
For file transfer, I mostly use rsync, Git, or Unison.
Banking only works thanks to a dedicated bank card reader. [1]
The quality of taken photos is fine (as long as you keep the lens clean :)), it's the quality of raw data to JPEG pipeline that's underwhelming. The default pipeline has been significantly improved recently, but it's still very basic, which really shows in low light. There's a huge room for software improvement there. You can always open the DNG file in something like Darktable or RawTherapee and develop it better, with proper denoising etc.
I've been shooting lots of photos and videos on my L5: https://social.librem.one/@dos/tagged/shotonlibrem5
> I’ve never used Bluetooth for music or similar, it keeps stuttering horribly
I've experienced that when using 2.4 GHz Wi-Fi together with Bluetooth, but never when connected to a 5 GHz AP.
Was using Sailfish OS on Sonys phone but drove me nuts for two reasons:
- had to reverse banking up to kick out the checks each time when new version came out and I became quite proficient at it (decompiled into git and each new version over it, then git diff, and fix the checks, committed the changes)
- worse part was that there was no bluetooth to android bridge and local bus company required it for contactless paying
There was nothing I missed from the phone, even reversing banking app was not really an issue, but bluetooth was just needed.
I defected to GrapheneOS after two years, now I am moving back, I hope for good. The fixed the bluetooth while for hardware I dont care.
I have solved the banking app issues by changing the bank and getting cheap old pixel just for banking app. It doesnt even have SIM, only wifi and used Automatize to turn on airplane mode on lock screen and turning it off for unlock.
I dont care about NFC payment or any other android junk, for photos I have EOS and phone just doesnt cut it, while camera is good enough for taking shots at everyday things like shopping list.
I really hope I wont need to see android ever again.
AFAIK, Camera (V4L) is also broken on main repo, to anyone else wondering.
/*
The AppSupport Bluetooth Bridge shares the phone’s Bluetooth controller between Sailfish OS and AppSupport. It acts as a router, so each Bluetooth device can be handled by either Sailfish OS or AppSupport without handing the whole controller over.
For most devices this is controlled through pairing. BLE devices are more complicated, and that is one of the areas where broader testing will be useful.
For now, you should reboot after installing. The Bluetooth settings page now has an extra option to route incoming pairing requests to AppSupport. Devices found during scanning also have a long-press context menu option to pair them with AppSupport. You can see devices paired with AppSupport on the same page, and you should also unpair them from there when needed. Turning Bluetooth on and off in Sailfish also turns it on and off in AppSupport. You should not try to turn it on or off from Android apps.
Android apps that are designed to pair with devices internally should be able to do so.
If you have previously handed Bluetooth completely over to AppSupport as described elsewhere on the forum, revert those changes first. Otherwise things are likely to break."
*/
I hope it helps.
If you're outside of the US, the availability of useable mobile OS's outside of Android and iOS is pretty abundant compared to the situation here in the US.
Not saying that's what you're doing, but I hear it often enough.
That's why I don't mind carrying around plastic cards, they just go in my wallet with my ID and a small amount of cash anyway.
Even if I was willing to use GPay, I don't like the possibility of my phone dying locking me out of my apartment and preventing me from paying for things.
Moving to GrapheneOS and not having virtual cards for contactless payment has been struggle, not going go lie.
In the UK we have Curve and, I believe, plenty of European banks have apps that work natively too.
> Preparedness is having several thousand euros in cash.
totally agree. not that I, much like any average Ukrainian, have more than €400 behind my name, but I agree, and by that definition only the wealthiest ~10% are truly prepared
I bought mobile devices that I could root over the ones that I couldn't. I favor companies that are less shitty. I preferred Linux over Windows as main OS even when Linux was harder to use (now I think in fact might be easier). But life is made of trade-offs and I did not see particularly good arguments of why Android is "that bad". You can root some devices and one can even avoid lots of services if you don't like Google (maps, mail, etc.) - which I also do.
So for me Android manages to stay in a unstable equilibrium : good for what I need, trustful enough for some stuff (money), not more spying that others (GSM towers), some levels of customization if you really want. Could it go "evil"? Sure, but considering what happens in the world, I am more worried my neighbors would have idiotic ideas than the fact that Google will be so evil.
You stopped using cash? It is one of the most insane things I ever heard.
You transactions are tracked, I assume? The rule in the eu (PSD2) is that a dozen private/public/hybrid/other databases, of unclear substantial identity, will record your transactions.
And what if you had a an infrastructural shortage? No transactions then?
How can people think of "cashless society" as something outside a dystopia?
That is in fact a highly naïve, direly naïve society: (*) the data is not contained into national boundaries by law already, and (*) you cannot know what will happen to the country and society in n years time.
Some didn't before 2020, but during 2020 the trend accelerated, and many shops stopped taking cash. Aside from hygiene, it's also easier to deal with safety for the store (i.e.: nobody can steal the cash register).
The supermarket in my neighbourhood has ~30 self-checkout machines. Only one of them takes cash. The human-checkout also takes cash, but is usually closed.
There is a possibility that such practice violates EU legislation in the terms of "paper" Euro being legal tender on the territory.
then it's all your own fault, isn't it?
A non problem imho.
I guarantee the government is not forcing 95-year-old Betsy in bumfuck nowhere with no cell coverage to learn how to use a phone. They have some solution, they're just not making it obvious.
I just called the solicitor, said "my Dad hates the app", they immediately presented an alternative.
And generally, 99% of stuff exists in browser. My phone is for messaging, photos, and reading, very little else.
It's difficult to just do things. Even windows feels more "free." Phone OSes are built like prisons.
Ideally Android would let you drop into a real shell, without having to deal with android sandboxing.
Regardless, I use termux and tasker to get my automations done.
And also malware.
That blast radius coupled with (non-Android) Linux's atrocious security is a far worse option
AUR isn't a traditional repository but more functions like a paste bin for package build scripts you have to go out of your way to enable and use at your own risk. It is not how actual Linux repositories work which are way more safe than google or even apple app store.
Probably because of how people submit directly to the commercial app stores and the app store staff are expected to accept them as long as no malware or other problems are detected. Such problems are generally explicitly listed on Terms of Service and app submitters may be able to dispute rejections. Meaning problems generally need to be concrete and justifiable. Also, because of the sheer number, problems are likely scanned for, rather than each app being personally considered by a developer.
FOSS distro package repo maintainers generally don't have any such pressures. They get their absolute pick of what to include from the wild, only taking as much as they're able to handle.
Also, distro repo maintainers handle the building from the source code themselves, while app store apps are closed source to the app stores. Their ability to inspect apps is very limited.
It's a pretty big sandbox in my experience.
How easy it is to do an equivalent thing on Android?
The neat thing about non-Android phones with respect to what you mention is that you can do those things just like how you would on any other computer, without having to worry about Android workarounds that may one day stop working via an update.
PinePhone specs on table are old. They're currently 3GB RAM and 32GB eMMC at 200 USD for package including hub.
Also, PinePhone is so much slower than Librem 5, which in practice feels closer to the (now discontinued) PinePhone Pro. Their specs only seem similar on paper, and only if you don't dig into the details. Though of course, Librem 5 being a 2019 design isn't a speed demon these days either - but I'm still using one and it's manageable.
They're the same specs. Pinephone Pro has more cores, ram, and storage.
> Their specs only seem similar on paper, and only if you don't dig into the details.
What do you mean?
https://xff.cz/dl/tmp/photo-20260806-013112002.mkv (I guess I try hard enough, perfectly servicable with a single core at 648 MHz, barely scratching it at 10-20% CPU time used)
It would be a bit ridiculous if it was not, given what UIs/games people run on 50MHz 486 if like 40-80x faster phone could not move some pixels around smoothly at 60fps.
> run a desktop Linux distribution (or Windows for that matter) that supports mobile features (calling, SMS, and data)?
The above use ARM SoCs. Palm-sized x86 with cell modem? Doubt it.
I may be able to tolerate the speed because of how I used my netbook many years ago. Windows XP was completely useless because of how laggy the GUI was. Archlinux with i3 and a focus on using the shell (e.g. hardly ever touched a file manager) with a very light terminal (urxvt; others like gnome-terminal were too heavy) and other very light apps made it very responsive. I've kept that habit of a core set of light programs even on desktop computers. On the PPP, SXMO with sway WM/composer, foot terminal, and wvkbd as a keyboard is very responsive, too. The only gripe I have speed-wise is that makepkg (an archlinux script) is weirdly slow to start up.
Maybe GUIs that have animations are too laggy to be useful; I haven't tried. The eMMC is likely faster than your microSD if the disk is the problem, though I'm on a microSD without issue.
They deliver beyond that too, with support for Alt-DP over USB-C for instance, open schematics, parts obtainable from independent distributors of electronic components, available detailed datasheets, and external batteries that can be hot-swappable (at least on PPP, haven't checked the others).
I respectfully disagree. Pine's MO was basically "create hardware and hope people create software for it". A bit tongue in cheek, but that's it. Which is fine as long as they're up front about it, which they are.
But in order for this to work, a community needs to form around the device. Pine doesn't have to be the ones to manage it, and some would say it's better if they don't, but they're surely a big part of it if for no other reason than they're the makers of the hardware. The infant PP community was doing quite fine until they announced the PPP and confused the hell out of everything. Couple that with some seriously brain dead choices (IMHO) around booting and charging, led to them not only torpedoing the pro but sinking the original PP as well. Probably in no small part because they split what little community had formed.
The pro was obviously rushed. I personally think they saw an easy way to grab some quick cash and took it.
The strategy, "create hardware and hope people create software for it," is valid too.
I think both sides maybe overestimate the other. People state the above like a complaint that they don't make themselves responsible for the code, but maybe that's their limit of what they can do. People tend to think of companies like things that can do anything with unlimited resources, but just like people they can have limits. In general, the posture, "I don't like this company for X reason, so I'll find another," is valid and good, but when you only have 2 suppliers... maybe a little more tolerance is needed to get your goal, the product.
They may have overestimated the abilities of the market too. It's tiny and part of the appeal is being able to treat your phone the same as your computer. A good part of the market is likely going to be people whose programming experience may be limited to computers with a BIOS, native compiles, etc. I took a bit to understand the boot process in detail (how it differs from a computer). Crucial details are spread across websites and blogs. There are unique tedious challenges too like needing a virtual keyboard in initramfs. Needing to cross-compile can involve a lot of details. On and off, I was/is looking at the battery driver to add hot-swapping support. That also involves learning a lot of things on multiple levels. You want to pull people that can quickly write camera drivers from this. Also not many people have all that much free time outside of work. A lot of patience is needed here, too.
Megous was talking about there being no lack of hand-holding. I'm sure everyone appreciates it (I appreciate it), but the gap can be wide.
A lot of momentum was being lost before LLMs even came into the picture, improved, and gained momentum for coding agents, etc. If the PPP had been released e.g. this year, things would likely be different.
> The pro was obviously rushed. I personally think they saw an easy way to grab some quick cash and took it.
Yeah, I've noticed details on the PPP. In their defense, it's supposed to be the explorer edition, not the final product. Also, as I understand, the PP and PPP are subsidized by Pine64, so I wouldn't see it as greediness, but rather desperation.
The Librem 5 even goes way beyond that - ECAD and MCAD designs are available on a free license as well: https://source.puri.sm/Librem5/hw/l5-schematic & https://source.puri.sm/Librem5/hw/3D_designs
I haven't heard much bad about Purism. I was always more on the Pine side.
A quick search online didn't find anything. Can you give me a quick breakdown or link?
That's surprising. They burned through a ton of goodwill by holding many people's money for many years, while being non-responsive to depositors, refusing refunds if they did respond, and so on. A lot of ink and footage has been spilled over it. Their laptop effort seems to have evolved into something almost reasonably non-scummy, but the Librem 5 put a lot of people off.
Current complaints, from what is (by all appearances) a tiny user base, about the state of the device and its lack of usefulness are also common enough, e.g.:
https://old.reddit.com/r/Purism/comments/1foblyu/daily_drivi...?
https://forums.puri.sm/t/im-giving-up-on-the-librem-5/18399/...
The more-viable alternatives are not without their own tradeoffs, but they are at least actually viable for normal people. I can't see putting family members on a Librem 5 or a PinePhone (much less a PinePhone Pro) without it being an absolute train wreck of a time for anyone but the most extremely basic and patient user.
Even their most prolific and downright stubborn true believer of a booster on HN admits he has to disable JS to load a number of web pages, given how anemic the SoC is. As others have pointed out it would have been a midrange Android chipset well over a decade ago. How exactly that works when one needs to use a site requiring JS to function has me feeling like I'm daily driving Nokia N-series tablets in the late 2000s again, except Nokia tablets were somehow a more polished experience two decades ago than one gets today out of either the Librem 5 of PinePhone due to the lack of real manufacturer and community support.
We need a viable Linux slab with a radio, and I want one to exist. It'd be nice if it was fully free of proprietary device blobs and was reasonably power efficient, but that's currently a fantasy completely out of touch with the state of available radios. I would carry my Linux ThinkPad with a built-in cellular radio or an external hotspot everywhere before it would make sense for me to try to pretend the PinePhone or Librem 5 meet even a basline level of utility value.
For someone who wants to check simple IMAP email, send and receive SMS messages and load basic websites, and are satisfied with poor camera performance, size, weight, battery life, and durability, while feeling good about the hardware they run (even if its hardware and software security is poor), then they may be quite happy with it.
The PinePhone (Pro) is there. They work as a laptop replacement. Their problem is more on working as a phone. There's even a repo out there to turn the touchscreen into a touchpad. With a bluetooth keyboard, it's basically a laptop.
> Even their most prolific and downright stubborn true believer of a booster on HN admits he has to disable JS to load a number of web pages
YouTube works on the PPP. If YouTube works, likely any JS works. Google Maps on Firefox also works.
You: We're there. It's a bad phone. This thing works as a laptop replacement. You'll even be able to use it as a trackpad some day!
This reads like satire. You guys are so out of touch with consumer expectations that you can't even string together a coherent argument in favor of these devices you so love.
Even if it was a viable phone, are we really calling mid-tier 2016 performance, from a device which was discontinued due to being under-supported by its manufacturer and dev community, as being "there"?
We are most certainly not "there".
On the JS, a strident supporter is saying he has to disable JS. Convince him his experience isn't real, not me.
You:
>> I would genuinely carry my Linux ThinkPad with a cellular radio everywhere before [..] PinePhone or Librem 5
If you're thinking of M.2 modems, they generally can't do calls AFAIK. A ThinkPad isn't really going to serve you as a phone...
But you're making my point for me: that's how bad they are as phones.
A laptop with an iffy phone situation would at least be a highly useful laptop, if nothing else.
A PinePhone or Librem 5 is just kind of meh-to-bad at almost everything.
Of course I knew that the Librem5 existed, but at the time I was thrown off by the price and the smell of "impending shitstorm" the device reeked of. Afterwards, I was too deep into the Pine side of things to pay attention to what was going on over at the Librem side.
It's sad that these two devices have derailed open phones so much. Obviously there's a ton of things to figure out, radio chief among them. But I fear that the corporations have learned from what happened during the "PC compatible" era of computing and openness will be a thing of the past.
I hope I'm wrong about that.
Agreed. Those two have made such a mess of things that I think if something interesting does sprout up, it'll come from somewhere else.
I think one issue is that the hard-liners who are willing to make the compromises necessary to daily drive one of these things as an actual phone aren't interested in any solution unless it's fully open, and certified as such. Which I get, but desktop Linux more or less evolved on hardware containing significant proprietary blobs and closed code, and at many levels. It wasn't perfect, but the OS had room to mature on genuinely good and useful hardware.
Instead, these two companies are trying to push molasses up a sandy hill. Virtuous though it may be, it seems kind of doomed to failure, and this doesn't feel like one of those situations where the glory is in the trying.
Eschewing genuinely excellent hardware because it's imperfect, all while running a hot mess of an operating system, also strikes me as a losing strategy.
Give me a modern SoC with modern radios, strong contemporary security features, all running a well-supported distro, and I'd be there in a heartbeat, despite whatever misgivings I held about the non-FSF-approved nature of the hardware, because that's exactly my current desktop, laptop, and server computing situation (modern security features aside). If I saw a viable open phone hardware project happening I would be happy to support it, but for some people there's a real "you are either with us, or against us" mentality about it, and if someone's going to make me choose...
> I fear that the corporations have learned from what happened during the "PC compatible" era of computing and openness will be a thing of the past.
We both hope you're wrong, but some things certainly seem to be trending that way, and quickly.
M.2 modems generally can't do calls nor SMS, though. It's just data, AFAIK.
At that point I think I might get one of those and use them as an everyday computing device (with Waydroid for Android apps) plus a small light Android phone for calling, tethering and locked down apps that do not work otherwise.
As daily driving Linux desktop/laptops, I mostly find that android(at least samsung galaxy-flavored) is next gen of Microsoft Windows, in bad ways. At least you can "hack" the Windows to customize something by your own, android does not. Performance also questionable nowadays, not for gaming but browsing purpose for me, may drain more battery than expected. Also MS acknowledges the issues and made statements to fix while I haven't seen samsung's.
Anyway, My opinion is, If you are nerd like me, I would buy one phone that 1) can unlock the bootloader 2) can root 3) at least kernel source available, some companies do not disclose until legal? actions 4) optional, linux port-able (via community) 5) optional, officially supporting linux(not aosp)
and then buy second phone, that has great security support, e.g Apple iPhone or Google Pixel, and use it like a wallet(banking/cam/gps/... I would not like to support other vendors, what if they abandon security patches, and then phone being vulnerable). I believe more android application will be more restrictive than before in the future.
For linux, you own the hardware. Because it's open source, you can audit and harden the every aspects, e.g You might able to use proprietary bluetooth codecs, which vendor disables in android ROM. When AI era, you may able to investigate and mod stuffs which you don't fully understand. This take risks, and we have right to take the risks instead banning it.
Rooting is important so I can mock provide fake data for: location, other sensor data, contacts, files, etc that’s what’s a a truly owned device. He does what I say.
Not what the app wants. If apps says you can work only in location X my phone takes the app side instead of mine. That’s not mine.
I can’t copy this text or take screenshot because restrictions: fucking stupid. I’ll just take a photo with my second device (or output to usbc device that can record screen) and parse the text. My phone just made me waste my time. I still can do what I want, just extra hops. Because, again, is not truly my phone. Is an adversary to my daily use.
Anyway it’s a lost cause. The only hope is for ai to bypass their security and allow owners to truly own a device.
That's a bit of an oversimplification that makes this sound more concerning than it is. Not that it's 100% un-concerning, but I suggest that anyone concerned about this read the linked docs. It really was designed to be quite privacy preserving, though it's obviously a difficult challenge in this context.
Keeping the name out of that data does a lot for privacy. With a name in there, you could use the data to find my name and figure out my address. Without the name in there, you don't know which point I even am without knowing some of my locations from another source.
The contact tracing APIs very deliberately avoided GPS for exactly the reason you mention.
The face alone that if you spend 10 minutes within someone's proximity will get flagged is 100% concerning. Of course they keys will only be handed to government health officials, but we all know what that means.
You will need to turn off your Bluetooth if you want to stop advertising a rotating random number.
The only difference with the contact tracing is that a key, on the device, can correlate the ciphertext. I have it off because the utility was never demonstrated.
Make something novel? RTOS like response like blackberry, secure, fully opensource and such? With the era of LLM accelerated developement (don't crucify me), this wouldn't be such unreachable goal.
We would have to sacrifice bank apps but imho still worth it.
But app is not the hardest challenge compared to supporting all the hardware, camera, screens and the many core protocols
Unfortunately, I suspect things like RiscV are just going to accelerate this as it means anyone can make any spec they want so long as the application code compiles to it.
Next one will probably take a while, but be a relative hit.
But not exhaustively no, because why would I? it’s just the first google result for ”openstick”.
It’s a pretty cool project with a cult following. If you’re interested you could spend years working with the same devices and then verify the information yourself.
What I would like is to take my existing iPhone 13 Pro and install a real Linux on it so I could guarantee decent hardware. You know, like we could do with pretty much any computer before smartphones.
I don't remember all the details but I had a Mac G3 around the same time I started using Linux: I don't remember the story about installing Linux no Mac hardware as being a particularly easy one.
Now I'm not saying that years after the fact, Linux wouldn't run fine on Intel Macs. But if I recall correctly it always has been a bit of a bumpy road.
On modern Macs, it's pretty easy to install Linux with Avahi.
To be clear, I don't necessarily need it to be easy to put another OS on there. I just want it to be possible. As far as I'm aware, there's no way (officially or unofficially) to install another OS on any recent iPhones. Someone might eventually figure out how to break the bootloader on the iPhone 13, but I personally think it should be something that the owner of the phone is allowed to opt into.
I'm sure that the Pine folks have very good reasons for not having 5G support, but those reasons don't really matter to the end user.
I mean, if they can force Microsoft to support other browsers than IE6, then why can't they force banks?
*(or BB, webOS, Windows Phone 7 Phone OS Phone Microsoft, Symbian, etc. if old enough)
Why wait for Brussels beaurocrats we all have this much and not have the most important tech country in the world make this law?
Open/individually accessible APIs would have to have be a movement, like the one with open formats for interacting with eGov.
An old smartphone or tablet can do that job and stay in a drawer at home 99% of the time.
As for Uber and messaging, you are moving the goalpost.
uber still worked from the webpage last time I checked.
There are messaging apps available on linux.
Apparently, they produce the phones in batches, not sure when the next one is due?
(And the Jolla's "hardware privacy switch" feels like a bad joke: yes, the switch is hardware. What it does (if anything) is fully handled in software.)
Unfortunately, that's not an option for most people, the only choice is to complain - but not like there's any other option on the market that behaves better. Or there's some other drawback, or different UI to learn...
https://xdaforums.com/t/rom-16-official-lineageos-23-for-mi-...
FWIW one can also do that on stock Android or its GrapheneOS variant pretty conveniently, including storage access, am, boot background processes, etc. It is not as complete as being root on Linux proper but still.
> While the AOSP isn't exactly dead (yet), it kind of feels like it's just a question of time.
Basically I'm suggesting that we might need a whole new OS on top of the Linux kernel.
Wrt/ torvie's narcissistic snarks linked above, the most important task for a kernel is still to facilitate fast IPC. The only viable forms of IPC in Linux are UDS and Binder. The former is slow and clunky. The latter is not a valid choice for DBus. So DBus devs have to manage slow, clunky, ill-suited legacy IPC. When a kernel can't be bothered to accommodate one of the most important operating systems built upon it, that seems really bad.
AOSP does not include nor depend on Play Services.
>locking down of device trees to hinder custom ROM development
Most manufacturers do not distribute these either. The user doesn't even have a pixel so it is not relevant.
>all the AI stuff being put into the system
The AI stuff is not part of AOSP.
>or most recently (and perhaps worst), removing the ability of installing apps per your own wishing - it's become sort of like a "death by a thousand papercuts" situation.
Again that is not a feature of AOSP, but one bolted in on top of it.
I think the author would benefit much more by using a different distribution of AOSP.
Realistically nobody is developing apps for linux phones, so the options are android or no apps at all.
Don't tell me about grapheneos, I have a pixel phone and did run it for a few months with/without play services.
At the end, you're always going to absolutely need that one app that won't run without Gplay.
Then you can install GMS into its own user profile with that GMS-dependent app, and when not using it you can log out of that user and put it fully at rest.
AOSP doesn't even include a functional keyboard nor a proper call manager nowadays
Boards:
M.2 Modem Module China, inquire for USA/EU options
M.2 WiFi/BT Module India, inquire for more options
It's not going to win the market, but I applaud anyone providing more choices.
People can spend their money however they choose, but I wouldn’t spend $1800 on a phone like that if you want to actually use it as a phone. And before buying it as underpowered “portable” Linux computer (the battery life is not good even though I hear suspend mostly works now), this is still outrageously overpriced even by current hardware pricing.
https://forums.puri.sm/t/each-update-makes-my-librem5-worse/...
The promise of, 'it's FOSS and these issues will be addressed,' sure didn't pan out with the PinePhone Pro, and it isn't panning out for the Librem 5. And that's setting aside hardware specs that would have been challenging over a decade ago.
It turns out that when the basic user experience is terrible, adoption rates are almost non-existent, and therefore nobody develops for it. The companies themselves have also done a seriously insufficient job of supporting their devices.
Some owners apparently disagree with you that the Librem 5 still usable. One, who shills for it tirelessly, states the need to disable JS to render some modern sites, a tradeoff he's happy to make, and that's his right, but to recommend something with such a heavy caveat as the solution to nearly every problem is inane. If you're looking for exaggeration, there it is.
There are valid reasons very few people use them. The situation won't get better by pretending the device is something it isn't. We need an open modern device, and the Librem 5 just isn't it, despite the loud assertions of a few to the contrary.
Some owners disagree, others agree. For what it's worth, I don't disable JavaScript on my phone's browser.
Of course, I don't expect a low-volume crowdfunded niche Linux phone to hit a major OEM's price/performance targets. Nobody should.
What I don't see a good way around is framing it as anything other than low-to-midrange performance chipset even in its day (whenever that actually was). Which is fine, tradeoffs were made, but tradeoffs they were. Something can still be viable for a small subset of people, while ultimately quite long in the tooth for the broader market.
I'm glad you're happy with it as a device. Thanks for posting your photos.
You hatred towards Librem 5 spread all over HN prevents you from correctly reading my statements. The correct statement is "I disable JS for more security and for unreasonably JS-heavy websites. I do have it on when I want."
It's low-effort, endless and often misleading shilling I object to.
Thinking back, the last time I had to disable JS to load JS-heavy websites on my phone was probably around 2011, maybe 2012. My more recent experience with JS blocking on desktop operating systems tells me that many JS-heavy websites tend to break pretty badly without it. A few content sites get significantly better without JS, but dependencies like banking and utilities sites mostly no longer work without it. I'm sure everyone's experiences will vary based on their particular needs.
Nearly all phone users have JS enabled by default, and therefore without necessarily realizing it probably expect it to just work.
I don't think it's reasonable to promote, in threads about almost every other phone (no matter how off-topic), an $800 device without at least mentioning that it may require them to make very basic and fundamental compromises to use it.
'Have you considered a GNU/Linux phone? Sent from my Librem 5" is just empty and repetitious shilling at this point. Anyone who's ever seen almost any of your comments here has now heard of it due to your promotion of it.
To elevate discourse above shallow shilling, please consider mentioning any of the compromises somebody may need to address, and then explain why said compromises are worth it in your particular case, and how you got around its limitations (and every device has them). When people say it's not viable for them, consider that they may actually be right about that. Nobody would bother to call you out if you did that.
It's entirely possible for people to find your way of promoting it tiring, without hating you or the device.
A good comment teaches us something. The above is one way to actually do so, while still promoting that which you apparently must. Call this a personal attack if you like, but it isn't: it's an attack on endless and banal promotion of what I maintain would be an expensive disappointment for many, maybe even most, buyers.
Edit: There's a lot of very reasoned pro-Librem-5 thinking in this thread worth noting: https://forums.puri.sm/t/each-update-makes-my-librem5-worse/... Notice how they acknowledge complexity, and their comments don't sound like they could mostly be replaced by a few clipboard presets.
There are just too many very useful services that only work with Android/iOS. Take taxi apps for example. I've used over a dozen in the past few years, many of them local to a specific country or region that made getting around much much easier.
realistically, this device would need to tiny to justify the extra weight, device-to-keep-charged, etc.
one idea: make it wifi-only and tether from your primary mobile device. This skips all the carrier nonsense, to focus entirely on the core use case(s).
As soon as we get to a point that Linux on the phone works at all, I'm happy to switch completely.
Here, "it works" literally just means it works. Not "GPS doesn't work," "camera only half works," "interop with Android/iOS apps that you're forced to use doesn't work." That doesn't mean "it works." And of course "only works for 2-3 years and then the device gets abandoned" doesn't mean "it works" either.
I've a wish list of one, though: make the Web the primary GUI front end. Essentially, apps are a specialised browser window. That way, I can program (both the front- and back-end) in plain text, just using regular Linux tools and a text editor -- no bloatware and gargantuan IDEs mandated.
That being said, I consciously chose an iPhone b/c I want my phone to "just work". I had a Blackberry Storm for a year and it was buggy, had to be restarted everyday just for it operate etc etc.
The iPhone has always been great. It just does what I need it to do b/c clearly someone cared about making sure the end user experience was phenomenal. While Linux has gotten better over the years, it just doesn't feel the same.
In addition, I recently started using a MacBook and the fact that the phone sync WITH THE LAPTOP makes the iPhone an even bigger plus. For example, if I set keyboard shortcuts on my phone they also work on the laptop. Photo sharing is a breeze and even integrated iMessage "just works".
Now, I don't fault people for wanting Linux phones. It's just not right for me.`
I figure supporting this effort is my little way to make a change in the world and help bring freedom back to our devices, which I now have :)
I've been using HarmonyOS for almost a year now (not the AOSP fork, but the actual Hongmeng microkernel flavour)... and this idea of having a iOS-like system with an Android VM running at near native performance works pretty well. Unfortunately is really focused on the chinese market but it feels really polished and promising.
Flop-Elon was the worst guy at the worst time in the worst position. It was 110% obvious windows mobile would flop. Everyone knew it, it was just a panic decision.
That said, what's there already is enough for me to have plenty of fun with the camera anyway.
I had an iPhone 11 Pro Max in 2019 and its camera quality was miles ahead of the linked photos, even if you assume raw output and post-processing. (The video, as you note, is even worse.) The link provided are shill posts of photos shot mostly under highly favorable conditions, with massive amounts of post-processing happening with much newer tech. I'm looking at casual photos straight out out of my 2019 device and they're vastly better than these.
Linux phones aren't going to get better by pretending the experience is something it isn't, and telling people not to believe their lying eyes. If everyone's cameras were suddenly replaced with the Librem 5's, the number of camera quality complaints would explode.
It's not good enough for anything beyond novelty use.
They're fun photos and some of them are of pretty decent technical quality considering the device used, but switching from iOS/Android to Linux phone of the Librem 5 or PinePhone (/Pro) variety is a bag of hurt for anyone who isn't so committed they're willing to craft their personality around it with an almost religious-like zeal.
That's what's up with me here. Still, I appreciate your photos.
Edit: Check the comments. You've got a guy saying the PinePhone Pro is "there." Except, it's bad as a phone. Minor detail.
I stated the camera isn't up to snuff for me, your photos are the best counterexample anyone's posted, and they still aren't up to snuff for me. Also, decent video isn't optional in 2026. I remember upgrading a BlackBerry to finally get decent video. The whole thing is so fundamentally constrained that it will never be more than a niche novelty, barring new hardware and massively better supported.
But that doesn't stop the shilling. It's bizarre.
Of course we need better phones. Librem 5, the one I personally still consider the best out there right now, is now 6-7 years old! It wasn't a low-end device back then, but it wasn't high-end either, and time flies. Yet at the same time I keep seeing people going "I wish we had XYZ" when XYZ was something I was enjoying all these years already. And you know, these better phones won't come out of the Santa Claus' bag. If all the people complaining about the need of better Linux phone had actually bought one, we would already have their successors in our hands.
There's still a lot of work to do, but the usual reaction when people are playing with my phone is being surprised at how usable it appears ("this is a Linux phone? it looks like a normal one!"), so I do think we need to put more effort into informing people of what's already there, even if it won't satisfy everyone's needs.
Purism was a case study in how not to handle delays, and faulting consumers for being overly picky or not supporting the product financially ignores the broader context.
Some people may also object to buying a phone that struggled for years to...make phone calls. (And by some contemporary accounts still does.) It takes potato quality videos. It was an absolute mess as of 2025: https://forums.puri.sm/t/it-is-normal-for-the-librem-5-to-ha...
Its existence does not obligate anyone wanting a genuinely good device to exist to contribute to that project, and it's naive to think a lack of sales is what's prevented Purism from shipping a better device.
Original backers got it in 2020-2021. It took until 2023 to catch up with preorders made already after the original campaign ended.
> Purism was a case study in how not to handle delays
Agreed.
> faulting consumers
I haven't faulted anyone. I just made a "if I had a dollar for each time..."-style remark.
> It was an absolute mess as of 2025
You linked to a post about a faulty unit and about how another unit with exact same software didn't have the listed problems...
> it's naive to think a lack of sales is what's prevented Purism from shipping a better device
It's exactly what prevented Purism from shipping the successor so far. It's also what prevented it from keeping a whole team of developers hired that worked not just on the specific device, but on the entire software platform and whose work is now being used across various devices. The Librem 5 project was a massive cost sink that left its fingerprints all over the place across the GNU/Linux stack, and more sales was exactly what would be needed to let it continue at that pace. The reasons why it didn't sell well enough can be argued, but the inarguable fact is that more sales would bring more progress.
Edited to add: The people saying, actually, my device also reboots fairly often, do not inspire confidence.
The reason some of them are grainy is that there's no denoising applied to them at all. The current GPU-based pipeline only does debayering, lens shading correction, highlight clipping, color matrix application, tone mapping and barrel distortion correction so far. You get the raws though, so you can apply whatever you want post-factum. Patches are welcome too.
If you didn't know, you could have asked.
The tram photo is arguably the best output of the lot and it's got a ton of problems by contemporary standards. Fun photo, if you didn't buy the phone for the camera and you want to hot rod it to get the best you can out of it, great.
Send that to any of the typical phone reviewers and the camera's going to get panned, probably universally unless someone wants to stake out a contrarian position for publicity.
"It's not bad for a Linux phone" isn't the expectation, we need a genuinely reasonably good device with good components.
No shit Sherlock. A processing pipeline written in a few weeks by someone who was just learning what color actually is while writing it, with lots of TODOs left around, can't compete with the state of the art? Who would have thought?
The post that started this subthread simply asked "Is this a good enough camera for you?", which is a valid question. For some (like me), the answer will be yes; for others, no. That's fine. I appreciate this link being posted because there's lots of really bad photos circulating out there coming from misconfigured software stacks that don't even do the most basic things you're supposed to do with pixels to get a viable picture, giving a much worse impression of hardware than deserved simply because of poor software. It was you who then suddenly showed up with your false "massive amounts of post-processing" claims and iPhone comparisons, as if anyone was claiming that it was comparable to iPhones. Take a short break and re-read what you wrote and what you've been replying to.
You're supporting my point. A device which first shipped seven years ago still requiring someone to properly configure a post-processing software stack to get viable pictures out of it (with no path to viable video) kind of makes my point for me. That the hardware can perform significantly better with post-processing is more of an indictment of the overall device than it is an endorsement of the camera hardware itself.
For me, from a camera standpoint (among others) the device isn't good enough to be a viable alternative to switch from Android (the post's topic), or from iOS (likely the most commonly used device family by HN readers). Even with your stack. As I said, your photos are the most convincing I've seen, at least the ones in the most forgiving circumstances. It's not personal.
As switcher targets go, the Librem 5 is a poor one. Ask any normal person to do what you call basic to get them looking like a midrange camera from a decade prior. And yet, when switching comes up, the same few suggest it as if it's a genuinely good option for anything but very niche cases.
No break needed. That's it.
Except it doesn't. The photos I showed are as they come by default out-of-the-box on the default OS the device ships with. You're just making things up again.
If it was actually strong at everything else, it may well have a shot as a second device, but the Librem 5 doesn't come close there.
Given fair phone exists, it should now be able to get all kind of apps anyone wants.
Why not just use an Android AOSP distribution? SailfishOS is proprietary. It will be a lot more "locked down" than LineageOS/GrapheneOS.
I have a PinePhone. That was just a toy gadget and nothing of value as a daily driver. Another e-waste device.
I have a FuriLabs FLX1S. It is a complete pack that is mostly plug and play. The latest update improves a lot. Wayland layer works great for when you need to run an application that has no Linux equivalent, such as Kore. It still rough around the edges.
1) Chatty, SMS application, needs more features to better incorporate modern SMS communication protocols.
2) The phone dialer takes too long to start up.
3) The microSD path is hard-code so it does not play nice when being encrypted drive were /run path is used.
4) Gnome Files works better the the Index file manager but there is no proper tie-in for password management. This means you must enter your encrypted microSD password every time after a reboot.
5) Convergence station cannot handle an ultra-wide, 3440x1440, screen monitor.
6) Firefox has a buggy user experience were there is no way to hide the tabs listing or options popup from with-in the application. One must swipe out of the application into the desktop and go back to Firefox.
7) Some of the UI time out settings are too short. Such as watching a video in full screen mode. Press to show the controls and by the time you start engaging with them the controls auto-hide again.
8) Don't know of a way to export SMS history from Android and import to Linux.
Once it is a little more polished the FLXS1 will become my daily driver. It has become my Bluetooth music player. I also use it more than my actual phone daily.
I'm surprised WhatsApp works on his non-Android OS?!
FTA:
> The no waydroid means that I can't access some apps that I need be it for online verification for logging onto bank and government services in Norway
Example, across the whole of my 2.8 million people city, parking is app-to-pay. No meter, no ticket box - just a sign announcing to pay by app and a QR code.
QR code points at a webpage announcing which very limited selection of apps you have for iOS and android and the backup option to ring a number.
Ringing that number means you talk to a person, make an account for only one of the apps over the phone, then use the phone menu system each time you need to park.
If you have a dumb phone(can't scan a QR code) or no phone... you're fucked. No way to pay for parking. Expect your fine and go through the bullshit processes.
The world should NOT think it is great to be so dependant on two US companies, but here we are.
Linux simply isn't up to the task despite there being some touch-enabled user interfaces available for it. There's so much more people expect from their mobile these days.
The best option would be to use /e/OS or GrapheneOS to limit your exposure to Google's incessant spying and tracking.
I agree, it feels like trying to write a new browser from scratch.
> The best option would be to use /e/OS or GrapheneOS
I would highly recommend GrapheneOS (disclaimer: I used both for years).
I'm afraid there will be too many corners cut. The most important being the lack of available software. I'm of the notion that a computer without software is nothing more than a box of wires.
https://forums.puri.sm/t/nine-months-librem-5-as-my-only-pho...
https://forums.puri.sm/t/librem-5-phone-review/21085
Concerning the software, I can run most Linux apps and most Android apps with Waydroid. See also: https://linuxphoneapps.org/
Also, good luck finding a bank in the UK that can support that (without messing around with desktop web instead on mobile instead of the app).
The have an unlocked bootloader and are the only phones supported by GrapheneOS [1].
If you don't want to go to GrapheneOS, any Android phone should be able to use F-Droid.
In my specific case, I couldn't use Pixels because the terrible PWM on the screen was painful to me. Bought a cheap Motorola G Power 2024 with an IPS screen. Never logged into Google. Used Obtanium and FDroid for most things. Used Aurora for the one Play-only app that I needed. Running Netguard (a non-root firewall) with a whitelist so almost nothing phones home. Deleted or disabled almost all the non-essential built-in apps.
I like the Moto but wouldn't recommend it due to the lack of OS updates. But this setup could be easily duplicated on almost any Android without needing root or roms.
FairPhone 4 is a pretty ancient cpu. I guess it's benching a bit above the OnePlus 6/6t that has been a go-to for a good fraction of a decade now. https://browser.geekbench.com/v7/cpu/84602 https://browser.geekbench.com/v7/cpu/5200
Motorola at least seems to be moving to unlock bootloaders. ARM gpus have some ok drivers now (thanks collabora & many others), which, a decade ago seemed like way way way more than the universe was ever going to allow.
I still think Samsung, with their new mountains of market cap, should try to do better. Exynos is right there, with an RDNA GPU just begging for the world's best drivers to take advantage of the hardware you already ship. You could make a stunner! Why not try?
Some things are still funny to me, though. As Google transitions towards full Evilness, people less frequently advertise a "I was employed at Google, what a wonderful place". Google totally changed things here, to the worse - that's fascinating. Meanwhile the google graveyard is growing almost daily:
If you're a technical guy and you feel like the android and ios are both pretty much destroyed by corporate overlords, then I sincerely invite you to try UBports or SailfishOS (from my research I find these two the most beginner friendly). The experience most certainly will hurt (at the beginning), but the sooner more people start using it, the sooner more people will start contributing to linux on phone and make our systems better. I was nervous that I would not survive without android and its entire app catalog and maps, or that a moment would come at work or in some critical situation that I would need android for some dumb reason and wouldn't be able to do something and spaghetti would fall out of my pockets, but for the last 4 years nothing like that happened. The most painful thing for me are probably the maps, but when I need long distance GPS with live traffic, I'll most certainly be driving with someone, so I just ask the passenger to navigate :) for less important voyages the unav is completely fine, there's also puremaps which I haven't tested.
ngl, that is the most charming darn thing to hear in 2026-- and it lowers the bar considerably here. like if all you need to have is a computer, sky's the limit on how you want to run this.
sooo with a little help from Claude I have a xmpp server running from home base+jmp for calling / sms, a portable router and a cute construction grade wp836 grandstream phone (annoyingly I can't seem to route SMS to it yet, but they route fine through xmpp on a terminal).
if you're voiping, you really don't need a voip phone though.
i have zero compunction so my computer of choice is a macbook neo... which acts as a dumb terminal for aforementioned xmpp server / wasteful videogame computer / claude butler (open the floodgates ladies and gentlemen); if i wanted cred sometimes i carry the old thinkpad around instead.
i can't say that it's any more secure than Android (using claude == i don't know what I'm doing), but it's fun? expensive fun though. JMP is a subscription, proton (for MFA and everything else) is a subscription, you need a domain for your xmpp server, ...this 'homelabbing' thing is expensive, using a map is awful (so wife is navigator...with her phone). There are many failure points, me included. but god, so fun!
i usually leave the actual cell phone at home. i do still have one. that's a hard thing to drop... but not impossible! the only holdover is learning how to use a proper camera and setting up the media server.
Temporary. The age of LLM aided development is current.
2. For every phone people in this thread switch from Android to "Linux", I'm going to switch 3 from "Linux" to Android. I have a budget of $14, $11 is earmarked for Chipotle. I should have plenty left.
"The mobile linux space isn't exactly looking good right now, but it holds some promise. Ubuntu Touch managed to survive being abandoned by Canonical, and postmarket is still seeing good development even if not having great hardware adapation at the moment."
Oh, you linked to Fairphone 4, let's see:
- battery: partial
- audio: partial
- camera: partial
- fingerprint: broken
postmarketOS device support is a joke, they couldn't even get ONE vendor to support the OS..
Mainlining is very hard though so the results are expected
I highly recommend keeping an eye on postmarketOS blog. [1] It's a fun reading, and development's been really rapid lately.
What stopped me from full migration to pmOS the last time I tried it about a year ago was poor support of Magisk and Xposed in Waydroid, two things I can't imagine using Android apps without.
But! With some tricks you can get pmOS dualboot on OP6. [2] Haven't tried it, but looks amazing.
I think with the current direction and velocity, pmOS is going to get really close to Android in usability on supported hardware in the next couple of years. Except for power saving parity that never gonna happen.
[1] https://postmarketos.org/blog/
[2] https://wiki.postmarketos.org/wiki/OnePlus_6_(oneplus-enchil...
But it's not like OnePlus or Qualcomm officially supports that, right? They didn't have any deal with any OEM where there would be someone employed to support the OS.. (even though they receive donations)
Like, all this is.. not serious.. the closest alternative to Android/iOS is GrapheneOS, because there are full-time employees AND they have a partnership with Motorola, so they won't have to rely on any hacks.. well obviously that's unaffordable but it's a different story.
I guess you have not seen any of actual Qualcomm code yet to say that, Qualcomm code is really what you would define as a pile hacks. Made by hardware engineers with no regards for code quality, maintainability or mainlinability.
OnePlus 6 comparatively is almost mainlined properly from start to finish, with a level of quality that you have nowhere in the mobile world.
Sure this smartphone a bit older but remember the Nokia N900 is still supported and it went out in 2009.
Mainlining mobile devices is very hard, but that's not hacks, that's how it's supposed to be done.
I'd say the waterline of mobile Linux "seriousness" is whether a device has a bootable mainline kernel build. Once SoC support lands in the kernel, it becomes a problem for a lot of people on high salaries (including some at Qualcomm). And hardware support doesn't get dropped from the kernel overnight. For everything above, in userspace, you don't need a deal with OEMs or their blessing to make things work. It's a pretty generic stack: Alpine, systemd, familiar WMs/DEs.
But yeah, I hope to see more deals like the recent Motorola-GrapheneOS announcement in the future.
Amazed to see Linux booting natively on a palm sized device with full hardware support and computer capabilities was out of the world!
Given the fact that the device is more than a decade old, it still runs the mainline 6.x Linux kernel and the UI is good! (desktop manager which I've installed it is based on POSH Shell).
Looks cool and since calls, SMS, Wi-Fi and data works fine to a good extent, the only gripe was that camera is unusable in it's current form. Have not tried the android subsystem yet I don't think it'll work due to device limitations.
Have installed Tailscale and primarily using it for remote SSH administration of all my devices through Tailscale. The device build is still solid (which I don't see in the newer devices! due to planned obsolescence) and browser based netbanking access works fine.
Caveats of a small device, keyboard and user experience matters though I'm not complaining because I can pretty much see what happens on the device and I'm not feeding any unwanted signals to anyone.
Constantly on the lookout for pure Linux based devices. Unfortunately, yet to my hands on Librem based device or on a Fairphone!
I hope the world moves towards a Linux based device (being a Linux user for close to 3+ decades (since the early Sco Unix times with core systems programming, I always dream of it! BTW, being a hardcore C programmer who has worked across almost all OSes and CPU architectures!) and such wish and dream will fully be fulfilled only on Linux or on *nix with firm belief!
Hope someone takes a serious move...