There are already 100 million HarmonyOS devices in China, so you could say it's now a three-way rivalry. The apps I use every day basically all have native HarmonyOS versions, including even foreign apps like Tesla and Sam's Club.
I've actually been using HarmonyOS for half a year now, and it feels pretty good — the notifications and system smoothness are on par with iOS. The reason I don't use an iPhone is that I need NFC access control, which iOS doesn't support.
Huawei has invested a large amount of manpower to station people in major companies to help develop HarmonyOS. I think they have already broken the vicious cycle of "no users -> no apps -> even fewer users."
Moreover, in the current AI era, it has become easier for Chinese developers to port software to HarmonyOS. For example, Moonlight, the streaming software I often use, has several natively customized and optimized versions available in the HarmonyOS app store.
“From 2019 to 2024, versions 1 to 4.3 (4.5 TV) of the operating system were built by integrating the Android Open Source Project (AOSP) with OpenHarmony, allowing it to support both HarmonyOS and Android apps. The current iteration of HarmonyOS became known as HarmonyOS NEXT (later it was renamed HarmonyOS 5 in launched of Pura X). HarmonyOS NEXT was announced on August 4, 2023, and officially launched on October 22, 2024. It also replaced the OpenHarmony multi-kernel system with its own HongMeng Kernel at its core and removed all Android code. Since version 5, HarmonyOS only supports apps in its native "App" format.
HarmonyOS 5.x+ both discards the common Unix-like Linux kernel and replaces the previous multiple-kernel, kernel agnostic system from OpenHarmony with its own bespoke HarmonyOS microkernel as a single framework.”
⇒ this shows it’s possible to create a new stack. It’s not Linux, though, and I think a large reason for this succeeding is that it started in the Chinese market after the US sanctioned Huawei.
> this shows it’s possible to create a new stack. It’s not Linux, though, and I think a large reason for this succeeding is that it started in the Chinese market after the US sanctioned Huawei.
Even so, I think it's helpful in that it weakens the duopoly. If app builders are getting used to building apps for other platforms than Android/iOS, it hopefully also becomes easier for others to gain some foothold.
Especially given the heavy commissions and other developer-hostile behaviour of these two. They've been essentially treating devs like shit and IMO a reckoning has been coming for a while now. Of course, you do have to meet the users where they are, at least up to a point.
Further fragmenting the user base into a third closed ecosystem is good because app builders have to build 3 versions so...now they'll be more willing to build a fourth version?
That logic doesn't follow. This is bad in all meaningful ways for open source.
> The Chinese government literally pushed companies to develop app for HarmonyOS [0].
Like the U.S. government is not pushing and investing its own companies, providing incentives, funding etc. etc. It's what sovereign governments are supposed to do.
> Have fun finding out what happens if you don't.
What is that even supposed to mean? You're going to a camp if you don't have a HarmonyOS app? That is just something that propagandists append to every post about China as if it means something. Get better propaganda, this is old and tired. I can stay random shit like the US is about to livestream an execution by a firing squad too, see?
> Like the U.S. government is not pushing and investing its own companies, providing incentives, funding etc. etc. It's what sovereign governments are supposed to do.
What's your point? My comment is not in contradiction to that.
> That is just something that propagandists append
You can do name calling all day long but that's not meaningful and will get you banned.
I strongly suggest that you reply with content with more substance in it, or just not reply at all.
> The White House considers anyone that uses the term, “Artificial Intelligence,” as opposed to the highly accepted new and more accurate term, “Super Intelligence,” THE ENEMY! President DONALD J. TRUMP
OP is asking about Linux phones. HarmonyOS doesn't even run Linux kernel at all.
HarmonyOS 5.x+ both discards the common Unix-like Linux kernel and replaces the previous multiple-kernel, kernel agnostic system from OpenHarmony with its own bespoke HarmonyOS microkernel as a single framework.
Huawei has a Google Mobile Services (GMS) equivalent called HMS, which acts as a compatibility layer and prevents Apps from throwing errors when running on their Android APK-support layer.
However, as I understood, in China HarmonyOS next has no Anroid-emulation layer (which is probably a wise decision if you want to drive domestic app-developers to support your platform...)
If it's distributed primarily in China, I'm not sure either of those matter.
Google Maps in China used to be reportedly unusable, and I'm sure there's local maps that have better data even if Google figured out how to manage the coordinate issues.
WhatsApp is blocked by the great firewall (or at least I haven't heard that that stopped) and has strong domestic competitors.
Does Huawei provide an Android virtual machine with Google frameworks built in? When I was traveling in Japan, I used Google Maps, and for daily use, Chrome and 1Password all worked fine.
In my daily use, only three apps run in the virtual machine: 1Password, Steam, and Chrome. They all run normally, but they're a bit laggy.
While I prefer Apple's design language partly because it's rooted from Sony and I love how Sony does this since eternity, I strongly support having multiple top-notch designers and builders from different countries.
This is what genuine competition is and drives things forward.
Looking at their website, most of their headphones look like knock-offs of Apple/Beats. They have a watch that looks like an Apple Watch knock-off as well.
I can’t give a company credit for good design when it looks like they are ripping off another company’s designs and design language on a regular basis.
That's what the Chinese do with everything. That's why Apple is so secretive about its plans. They day their new offerings arrive in the stores the Chinese makers buy them and start copying the design warts and all.
So far it has worked nicely since you can buy stuff that looks the part but costs a tenth the original's price.
They start getting the plans on how to clone them before they even hit the stores. That's why we saw the Xiaomi 18 Fold launch with the exact same dimensions as the iPhone Duo... before the Duo. Xiaomi got the inside scoop on the parts they were sourcing, and maybe even from the factories prepping. They even named in the "18" assuming, Apple would use the iPhone 18 branding across the whole line up. They can't even make up their own names in China.
As long as Apple is manufacturing phones in China, the only thing they can surprise people with is the software. They really need to push harder on getting some manufacturing back in the US if they want any hope of keeping things a secret and not having knock-offs already on the market before launch day.
I have a Mate 80 RS Ultimate Design and I think it looks beautiful in person, but as you know, Chinese and Western design preferences are very different, just look at their EV's (and how western brands are copying their designs)
Design was important enough to you to post your own comment talking about it and your own preferences, and how important it is to competition, so why are you questioning it's importance to someone else?
Because I see design as a proxy to build quality and ergonomics. I'm not shopping for looks while getting my electronic devices, I'm shopping for quality and longevity of the thing in question.
If it's built well, dependable, ergonomic and delivers on the promise it's written on the box, I'm perfectly happy with what I got.
Yes, I have my tastes, like everybody else, but I don't satisfy my taste first and try to fill the specs to that taste. On the contrary, I start with the features and quality level I want, and go from there.
> Because I see design as a proxy to build quality and ergonomics
It isn't a good proxy. Couple examples: Apple sold laptops with wonky keyboards for years and still sells a mouse that charges from the bottom when the battery dies.
While I never owned these Macs with butterfly keyboards, I have used them, and yes. Apple botched bad on that keyboard. They made it right later, though.
While I also understand that Apple Magic Mouse looks atrocious with that port on the bottom, just charging it for two minutes gives you 8 hours of runtime. Why can’t people plug it in while going to get a coffee and unplug and finish the day with that quick charge? Then you can leave it charging for the night.
If you really want some bad examples, look at some popular cars. Many of them don’t care about your finger, and happily chop it off if you put it the wrong place at the wrong time.
> Design was important enough to you to post your own comment talking about it and your own preferences, and how important it is to competition, so why are you questioning it's importance to someone else?
I think you might be conflating design and cosmetics.
Design is objective, cosmetics is subjective. I like good design even if I don't care much for cosmetics.
Read "The Design of Everyday Things" , Donald E. Norman. This book is routinely recommended here, with good reason.
Did you read the comment I was replying to? The commenter claimed Huawei had the lead in design. I begged to differ. I'd accept the design of the 90 Pro Max on a $300 phone, but a $2,000 phone? lol
That's your personal opinion on a piece of hardware. If that's so important for you, you can look to other alternatives.
...and in my comment, I kindly disagreed with you. I have used many things with great enjoyment which were called ugly by many people.
It's OK and natural to have different opinions and priorities, and hardware design is not a first priority as long as it's uncomfortable on my checklist.
As a side note, apparently, you can add an extra camera module with a 1" sensor to that "lock" you seem to dislike. Considering the best camera is the one you have, having an additional camera with better sensor for people who are inclined to dabble into photography is a great thing.
...and I'm contemplating on how can I take my mirrorless with me during flights in a compact way even if I have an iPhone.
There's also https://en.wikipedia.org/wiki/KaiOS that developed from FirefoxOS and powers something like 100 million feature phones in the developing world.
Have they support copy paste between apps? Since WhatsApp abandoned the platform I figured it is in life support. Almost no one use SMS in developing worlds, it's WhatsApp all the way.
Oh, I didn't know WhatsApp had dropped it. You're right, that's probably end of the line for it, but maybe the OS will be resurrected in some new form.
HarmonyOS (especially meaning Huawei phones) is pretty much dead outside China, that's like saying WeChat is relevant messaging app outside China
if you can't run all your favorite bank apps in your phone any phone is dead nowadays, no matter whether it is Linux or HarmonyOS
and seems EU is fine with keeping Apple/Google duopoly in app verification, so although you can use European bank and pay with QR codes without MC/Visa, you still need US company verifying your phone so you can use European bank app, sad state of current things
> if you can't run all your favorite bank apps in your phone any phone is dead nowadays
I guess I've been running dead phones for ::checks notes:: a quarter century now? I actually don't even know if my primary banking institution (a regional credit union) has an app to begin with. It's never occurred to me to need it.
I like the confidence with which you through around "99%" when there is ample research suggesting that the percentage of smart phone users (at least in the US) who use their phone for banking is much closer to half.
I'm not offended at the idea that someone might want to bank from their phone, just, a lot of us don't have that need. Having my ability to run the software I want on my phone taken away, just to support corporations insisting that they be able to control my device for a function I don't need, however, is offensive.
"banking apps" is just simplification for apps requiring GMS or Google verification, (this whole thread is about HarmonyOS and Huawei devices which are not supporting GMS) you can ask Android users in Europe if they would be willing to buy/use phone without GMS and explain to them what does it mean and I can guarantee you percentage unwilling to buy phone without GMS will be much closer to 99% than 50% you claim
btw. ~60% users in Czechia pay with phone already (though like 95% with bank card at same time), I am not one of them, but I won't deny the reality
go travel a bit, there's an entire world out there that isn't waiting around
when i go to the mall here, i counted 6 korean copycat shops lol
asia is living a completely different lifestyle than us, and its popular even with us, especially with women, and its actually good, and we're still here saying asian shit is irrelevant
I've lived in various Asian countries for the last 10 years, but I've never seen Wechat used except for communication and payments with people from mainland China.
Same with Gojek. They tried launching in other countries, but it never caught on outside of Indonesia, where yes it's huge and awesome.
Grab, on the other hand, has been very successful internationally.
The reality is that The Western Civilization, or however you frame and name your own personal lifestyle, is not as huge and dominant as it might seem to you. Every countries have own sets of apps and webs. __1984 is a work of fiction__; there is no united Oceania, Eurasia or Eastasia in real life.
And millions of Chinese bash it everyday. Shit storage efficiency, stagnated UX experience, very closed ecosystem and external link blocking, I could go on.
> go travel a bit, there's an entire world out there that isn't waiting around
> asia is living a completely different lifestyle than us, and its popular even with us, especially with women, and its actually good, and we're still here saying asian shit is irrelevant
I lived in China 5+ years and spent plenty of time in other Asian countries travelling, so how to say it politely - stop talking about "us" and preaching me about lifestyle in Asia if you are completely clueless.
WeChat is shit app pushed down the Chinese throats (I remember when QQ was still the king), because it doesn't have competition in China and you can't really exist in China without it, closed sourced with no E2E encryption for starters, there is reason why pretty much nobody outside China/Chinese community uses this actively spying app.
So yes, if by Asian shit, you mean HarmonyOS and WeChat, then yes, Asian shit is irrelevant, because pretty much nobody outside Asia uses it for good reasons (HarmonyOS because it is unusable if you wanna use normal banking apps and most of the other apps relying on GMS besides those very very few ported apps or using some virtual machine workarounds, personally I don't need banking apps and used smartphones without gapps for the last 10 years, but I am realist realizing I may be among like <0.5% Android users in Europe, completely irelevant negligible number).
My phone can't run any of my bank's apps, is it dead too?
I appreciate your intended point was probably more specific, perhaps 'will not be a mass market success in the west', but there is a great diversity of people in the world and many of them have different requirements of a phone
for 99.5% potential buyers yes, it is, if it can't run bank apps (or other apps requiring GMS), personally I don't use banking apps on phone but I realize I am extreme negligible minority, which is why I said "pretty much dead", that "pretty much" covers that <0.5% users
Isn't HarmoniousOS just a blatant Android OS clone, with serial numbers and licenses filed off? I remember ArsTechnica reported on that waaaay back when it was released.
It would have to be somewhat more global than only in China though. After all Google's spyphones also operates globally, more or less, even if Google is a ruthless US tool for abuse of other markets. IMO we need to get rid of all companies though. That's not realistic, but it really should happen. I just do not trust any of these private entities anymore; verifiable open source and open hardware at all times should become the new standard. Is anyone really using Win11? Ever since the recall-spy feature I knew I could not commit to it; whether I can disable it or not is not a useful distinction since there is no more trust in that private blob, now supported via AI slop.
- Worse compatibility with the millions of Android apps already out there.
- Hardware vendors (outside Apple) all target Android.
- The usability of Android/iOS is far better than non-Android Linux phones.
- The security of non-Android Linux phones is in a bad state (e.g. lacking proper app sandboxing). Heck, even the Android emulation layers that some of these phones have, throw the strong Android sandbox model out of the window.
The answer is very obvious and it is AOSP. Even though Google is trying to close AOSP more (e.g. by not pushing source continuously to the AOSP Git repos and keeping QPR1/3 for themselves), it is still an open source system. Play Services can either be run sandboxed or emulated with microG. AOSP allows alternative systems to hit the ground running, you get great app compatibility, a tested security model, great usability, and support from hardware vendors, including vendors that are alternative friendly (used to be Pixel, now Motorola, Fairphone, etc.). If ever needed, AOSP could be forked and it would still be leagues ahead of non-Android Linux phones.
All the downsides that apply to AOSP-based systems (like things getting blocked by Play Integrity, unlockable bootloaders) also apply to non-Android Linux systems.
The lack of polish is a function of the inability to use the hardware. The hardware is tightly gatekept so competition _cannot_ exist. Regulators are the only ones who can force vendors to distribute documentation for and unlock their hardware.
Once we can actually target the hardware, open source alternatives will be much better than first party options.
You can already see the potential in the open source world.
Linux has Waydroid so Android apps can be run on Linux at full speed without emulation. That means, if you had a Linux phone, you have the entire Android library - the only thing lacking is the launcher. How hard is a launcher to program? It's just Steam's big picture mode.
Other examples of the nice things we can't have; FEX lets you run Steam games on phone hardware. Open source drivers can unlock displayport over USBC. Instantly your phone becomes a thin client / laptop replacement that can play PC games (poorly, but 1080p games are possible).
We are _not allowed_ to do these things. I love OS development and, if I was allowed, I'd make iOS look like janky trash.
So, where are the super-polished Linux systems for the Fairphone? I know they use proprietary firmware blobs and that the hardware support is Android-oriented. But they publish device trees, driver sources, and firmware. Most AOSP-based projects support Fairphone, as well as PostmarketOS and ubports.
The problem is not only hardware support, the problem is also that the stack on top of it is very immature compared to AOSP and not something you could give to a daily phone user.
It’s funny that you mention Waydroid. It throws most of Android’s strong security model out of the window.
> So, where are the super-polished Linux systems for the Fairphone?
It still has tiny market reach. Very few people are going to invest the time needed to build a quality user experience for like 1000 users.
Just imagine what would happen if Linux could be installed on the iPhone. There would be SteamOS distributions within an hour of the announcement.
> It’s funny that you mention Waydroid. It throws most of Android’s strong security model out of the window.
Haha yea, it's more an example of capabilities that could be rolled into highly polished user experiences. Again, if Linux could be installed on the iPhone - I'm certain Waydroid maintainers would shut the project down from PRs.
> It still has tiny market reach. Very few people are going to invest the time needed to build a quality user experience for like 1000 users.
That doesn't make sense. Whenever someone wants to build something, they start with 0 users. They don't say "huh, I have 0 users, I'm not going to build a good product".
People who build things recognize that they won't get more users if they don't make their product better. If you have 1,000 users and you want 1,000,000 users, you work more, not less.
The lack of polish is a function of the inability to use the hardware. The hardware is tightly gatekept so competition _cannot_ exist. [...] Once we can actually target the hardware, open source alternatives will be much better than first party options.
So, it's not the hardware gatekeeping that is the issue, it's that nobody is polishing the experience for hardware that already exists and qualifies. The hardware can also be purchased very easily in some regions (e.g. Europe). I can literally hop on a bike right now and pick up a Fairphone in ten minutes. I know that it's different in e.g. the US, but Murena has been selling them in the US for years now.
I think you may be glossing over a bit how annoying / messy / complicated it can be to work with the binary blobs and their quirks, especially when dealing with complex things like camera(s) and the image processing stack. Doubly so for community developers who may have limited or no access to documentation and resources that the device manufacturers get from the more low-level hardware vendors.
If Fairphone wanted, I'm relatively sure that they could form a cooperation with Jolla, Librem, KDE or other entities in the space and get Plasma Mobile, Sailfish or whatever working on their phones and/or design the next-gen Fairphone with hardware that has as few quirks as possible and is as "easy" to get to work with Linux as possible.
I'm also relatively sure that so far, that would not have made economic sense for them. However, there seems to be a bit of a surge in people wanting alternatives. The recent Jolla phone has way more orders and pre-orders than were anticipated, for example. And SailfishOS is certainly "polished" enough that the circle of people who can use it well (or at least live with it) has expanded beyond the developer / hacker / activist crowd.
> dealing with complex things like camera(s) and the image processing stack
It would be wonderful if we could create an abstraction layer on top, so all the trillions of phones already existing that simply can't open source their drivers due to licensing and whatnot could be usable.
> If what you care about is protecting device and application providers' interests from their users, then I guess it does.
That clearly isn't what they care about, or intended with their comment. Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize.
Now, if we had support for say, a pixel, that would probably change things. Incidentally, there seems to be initial support for the tensor G5 (pixel 10 onwards)
How many years did it take to make a well-polished DE on desktop Linux? How large was the community doing that and how many devices did they have access to?
About 5 years, Mandrake and SuSE with KDE around 1996 were already quite good.
Since then the problem has always been the same, rebooting the DE experience for the sake of it, desktop environment wars, rebooting the development stack from GNOME and KDE, and the problem that despite all OEMs have Linux running on their data centers, the community has to reverse engineer the hardware from the same OEMs.
Yeah, I think people are underestimating how good and competitive the Linux desktop was in the past. Around ~2000 there was a lot of excitement around the Linux desktop, the Linux desktop was pretty mature, especially compared to the tire fire that Windows 9x was at the time (that changed when the NT branch moved to the consumer with XP). There were very user-friendly installers like Caldera OpenLinux (best feature was that you could play Tetris during the install) and Corel Linux. Also a lot of large vendors were making Linux desktop apps, e.g. Corel Wordperfect and Borland Kylix (which was Delphi for Linux). Heck, even Microsoft Office ran almost perfectly with CrossOver.
But yeah, then there was the constant forking, preferring rebooting development over iterative improvement (e.g. GNOME 2 -> 3 was really a hard cut for a lot of people, resulting in forks that exist till this day), hostility towards closed-source applications (you can hate them as much as you want, but people are not abandoning Photoshop/Illustrator for GIMP/Inkscape on a whim), etc.
Hopefully something changes with all the government-driven sovereignty desktops that are popping up, the resulting influx of money, and KDE EV et al. becoming very mature organizations.
By such measure, GNU/Linux phones are already quite good. I use Librem 5 with Phosh as a daily driver, and it is really just fine. Except the battery life, app compatibility and smoothness of the UI.
The difference is that there is already a great open source smartphone OS that works today, it’s AOSP.
The most effective path would be for the FLOSS ecosystem to pour their resources into making AOSP independent from Google. But instead people will just fork N half- or non-working solutions for reasons.
This comes up every time, I just don't understand the argument. You can fork AOSP when that happens. It will still be far less work than bootstrapping a viable open source alternative from scratch. Also maintaining a forked AOSP would be less work than getting the Linux desktop stack on the same level as AOSP.
Given that Android apps target old API levels, it would also stay compatible for years and nothing would hold you from implementing APIs from the docs.
To be honest, I don't think AOSP will fully close up, since Google probably fears the regulatory pressure and the fallout from vendors. The larger risk is Play Integrity, but that applies equally to other Linux systems if you want to tap into the large Android app ecosystem. But the solution for that is not technical, the EU and other regulatory bodies should make forbid it in its current form due to anti-competitiveness.
> This comes up every time, I just don't understand the argument. You can fork AOSP when that happens
Hacking on the Linux stack is several orders of magnitude more practical than AOSP though. AOSP's build system is massively unwieldy for individual contributors to work on. You can't easily work on any of the system components without dedicating >100 GiB of storage for a build, for example. Everything is scattered across hundreds of repositories tied together with a bespoke repository management tool.
This all works for a company equipped with entire build infrastructure teams, not for a grassroots project trying to keep up maintenance with (at best) limited funding. It's why Nura (fka postmarketOS) is a thing whereas the various AOSP forks barely ever modify the core experience.
It's a whole operating system complete with accessibility, hardware abstraction, a bunch of core apps etc. I think it's a false equivalence that you can hack on a replacement system without similar "investmen"
In any case, were google turn malicious, it wouldn't only be in the interest of individuals to maintain a fork, plenty of companies are invested in the health of the platform that will help out.
Android's market share is far larger than even Windows'. It's not just in the interest of a small community, there is plenty of financial interest as well to keep it healthy.
Also, it's a false equivalence - it's also easier to buy a walkie talkie, but that's also not replacing Android smartphones. "Gnu/Linux" userspace is simply not even close.
There is the pinephone, have fun writing software for that thing.
But it's a pretty fruitless job when there is an open source OS built on the same good kernel, but actually had hundreds of thousands of dev time spent on it to make it the most popular OS out there.
This perspective I can't wrap my head around. Like I get that you wouldn't use it, and that's fine - but if Linux was available and we made it incredible, that would push Apple (and Google) to do better. So you'd get a better MacOS / iOS by proxy.
Like, don't we want competition? What motivates people to desire an unchallenged status quo?
I have a genuine, but maybe stupid/trivial sounding question. Does anyone successfully run cloud instances of Waydroid so that their physical phone is a dumb client?
I've been thinking about it for a long time, but it seems like such a privacy risk even when self-hosted. The massive upside is that the phone is just a VM. The idea makes the entire phone debate irrelevant since you can access your "phone" from any other computer that has internet access. If the connection is lost, the local device can always sync later or at least provide basic call/text functionality.
What's the viability of regulators requiring such documentation out of vendors? Feel free to extend the scope out to up to 5 years if it does not look viable right now.
Introducing initiatives that encourage competition is bad for business so I empathise with megacorporations for not doing it without regulation. The annoying part is they are also the largest lobby groups, so it's unlikely the US will be the leader of change here.
If I would draft policy that could make it I'd suggest;
- Scoped to companies above a "number of units sold globally" threshold.
- Documentation must be supplied 3, maybe 5 years after hardware release (similar to "generic drugs").
This means small hardware startups are not burdened by the overhead in creating docs, and megacorps retain the ability to extract profit during the period of maximum profitability for the product. The eventual expiry would encourage companies to innovate (I think malicious compliance is unlikely).
With the recent push to decouple dependance on US technology companies, I see this as possible (though still unlikely) in the EU, perhaps Canada.
I am often finding things I prefer about one of the OSs (or Desktop Environments in the case of Linux) that the others don't have. I can usually see how people prefer any particular one over the other.
The usual suspects are the keyboard support in Windows (enabling the extended keyboard navigation in MacOS made some apps act very strangely), and most of the look and feel of MacOS. There have even been things I really liked in ChromeOS.
Obviously there are many nice touches in the big Linux DEs, and I would rather be in KDE Plasma than anywhere else. Because of this, I'm generally not surprised when I encounter something that is done better than Windows or MacOS.
However...!
Yesterday I was editing filenames in the file browser, and accidentally navigated down to the next file in the folder - still in filename editing mode! It was a feature I didn't even know I wanted. Suddenly, I could edit a whole list of files, just as if it were rows in a text file. Now it's Monday, and I'm back in Windows. I am unlikely to need to use that feature, but still wish I didn't know what I was missing.
> Yesterday I was editing filenames in the file browser, and accidentally navigated down to the next file in the folder - still in filename editing mode! It was a feature I didn't even know I wanted. Suddenly, I could edit a whole list of files, just as if it were rows in a text file. Now it's Monday, and I'm back in Windows. I am unlikely to need to use that feature, but still wish I didn't know what I was missing.
In case you do ever need it - you can do this in Windows with the tab key.
That is quite nice! I don't think I ever knew that. It doesn't feel quite as nice as using the down arrow in a list/details view, but it's plenty good enough.
Anyone have the equivalent for MacOS? :) I don't have any MacOS devices handy.
> Play Services can either be run sandboxed or emulated with microG.
Play Services is absolutely not needed for a usable Android experience. I am running GrapheneOS without any Google crap and you could not pay me to do so.
Many bank apps, and apps to interact with official state services, usually depend on Play Services. Sometimes it is all banks in one's country, so no, one can't just "switch to another bank" as US Americans on HN often assume.
Can't speak for all countries ofc, but the happy path isn't just the US. I've heard positive reports in Europe where banking apps work without Play services more often than not, and if it doesn't some banks will actually change implemented policy once a customer complains.
İ think this is the case in a small number of European countries and really it should change. İn two asian countries İ do business in, and one middle eastern one, the bank apps now provide a third harmonyOS alternative. The American banks I've used don't require an app, and HK banks will provide a digital token generator which is actually my preferred way.
İ think that if it's the case you are tied to one foreign third party company to do banking it should be really something you protest about strongly and change it.
I was saying this just to be ahead of all the comments that usually come up with "yeah, but Google has increasingly put new APIs in Play Services, so AOSP is worthless".
I used to do this, but an increasing number of apps fail to work without play services. Luckily Google still lets you create accounts on android phones, so you can create a fresh account with a random name for every phone, and take care you don't give it access to something identifiable.
I know it is entirely possible for Google to uniquely identify me for each account, but I choose to believe they don't go out of their way to use EVERY possible information about you to track you and only use things that you "accept" via their EULAs, like syncing contacts or logging in to the same service with both accounts, etc.
I would love to use GrapheneOS but Google Pay is a requirement for me. Platform is a moat, and I think the above comments about Harmony solidify that if your country has the will to create a home grown platform, it can happen. I don't think any other country would be able to make that work (maybe AI changes things dunno)
I disagree. Working on AOSP with Google having so much control of it is just a waste of time. You have no guarantees what you are working for, in the future.
I'd go full Linux, the effort is worth it and will pay out in the future. Google has the AOSP project by the balls and it's a very high risk investing anything into it, as a developer.
With today's LLM tech might as well do something nice with Linux.
So fork AOSP today. You actually have a working stack, working systems (Lineage, GrapheneOS, /e/OS), and it's far less work than bringing mobile Linux up to the level of AOSP.
But no, let's reinvent the wheel and start the complete ecosystem from scratch. Of course, looking at the history of Linux, this is not surprising at all. Even something immature as mobile Linux already has multiple projects + stacks (Sailfish, ubports, Plasma Mobile, PureOS, etc.) trying to achieve the same. I say this as a long time Linux user (since 1994), the Linux desktop community manages to shoot itself in the foot over and over again.
I don't think you understand the reason people want mobile linux. I want to be able to run arbitrary binaries and get access to graphics primitives on my phone, AOSP does none of this. I honestly don't even get the point of AOSP, the way you don't for mobile linux.
You can absolutely run arbitrary binaries. The binary format for Android is an APK, but if you really meant a random arm binary you can run that as well just fine, android even natively has a terminal now.
And what do you mean "graphics primitives"? You have an abstraction layer, the same as you do on Linux. Like you ain't writing directly against a particular video card either , unless you write a kernel driver.
An APK is an installer, not a binary. You have to be an "app" to do anything in Android. Which includes writing to the framebuffer. I don't know enough about Android so I'd love to be proven wrong. Give me an `xclock` equivalent that I can just run.
A png image is a binary. A zip file, which apks are are just binaries.
If you mean executable formats, they're their own different things, it's just machine code wrapped OS-specially. I don't see how they are fundamentally different "from an app" - you also have a bunch of metadata in there and an entry point. Just because it's an XML file in Android's case which can just as well jump to machine code (you can have Android apps written in CPP/Rust whatnot), it's all just an implementation detail.
Well, do you mean xclock to draw over different windows/activities? Because that's just a different similarly to how Wayland is different from X -- it's generally frowned upon to not have a central entity manage who can draw where.
Otherwise, you can trivially do whatever you want, including drawing manually similarly to X's API, or using OpenGL or similar hardware accelerated apis.
I want to be able to run arbitrary binaries and get access to graphics primitives on my phone, AOSP does none of this.
People use a phone for their most private information, including banking credentials, credit card credentials, car keys, etc. The banks, etc. are never going to permit running their apps on devices that can run arbitrary binaries. Most are already blocking rooted Android devices and Android devices with an unlocked bootloader. The fact that this is still possible on desktops (though not everywhere anymore, e.g. my bank requires you to use a phone app for authentication) is for historical reasons.
Also, you are an extremely small niche. If you are sufficiently motivated, you can live like that (run Linux phones, work around banks, etc.), but this will never be mainstream and this was implied in the question of the post (Will Linux phones become a viable alternative to the Android/iOS duopoly?).
If there will be a viable alternative to the Android/iOS duopoly, it will look a lot like Android/iOS. The best chance is an AOSP-based system like GrapheneOS.
You can still run traditional Linux desktop apps in a VM on such phones.
>but this will never be mainstream and this was implied in the question of the post (Will Linux phones become a viable alternative to the Android/iOS duopoly?)
The post goes into detail about the reason for the current duopoly is the difficulty in procuring modern SOCs with linux support, nothing to do with how said phones will be used.
And I don't really care about being able to bank on my phone, I would gladly buy a cheap android device for it if they stop you from being able to bank on desktop devices, I just need linux on phones because of how much android sucks for daily use and how annoying it is to do anything on it. If we do get the ability to run android on modern hardware, it stops being necessary to have a separate desktop/laptop as well, I could just use a dock, or just a keyboard and mouse instead, especially since the Macbook Neo has shown current mobile hardware is more than enough for "casual" desktop use.
> The fact that this is still possible on desktops (though not everywhere anymore, e.g. my bank requires you to use a phone app for authentication) is for historical reasons.
And you think that this is fine? I will fight for my rights for one.
Actually, with the recent advances in LLMs - they could. If people start to reverse their phones and upstream to Linux, we would not need the hardware vendors to support their own hardware even.
> If ever needed, AOSP could be forked and it would still be leagues ahead of non-Android Linux phones.
I agree and thus donate to independent AOSP development (such as GrapheneOS).
It would probably be a great idea to replace many android components with components from the linux userspace ecosystem so that more code sharing between desktop linux distros and this is possible
I really enjoy having a phone that gives me full root control, and that is very similar to the Fedora (GNOME) distribution that I have on my desktop and laptop.
Buying a Linux phone from a pure Linux hardware vendor like Purism helps sustaining the mobile Linux ecosystem.
Yes, the Librem 5 is a bit older phone with some rough edges, but for me it is a really good phone. It gives freedom in the free software sense, and consistency with my Linux computers. I gladly accept some minor inconvenience to have a phone that respects my freedom and privacy.
I cannot foresee the future, but for me the experience on a Linux phone that I control is far more superior than any phone that spies on me and takes away my freedom, like Android or iOS, basically any phone from any manufacturer that disrespects me.
I don't see what I couldn't do on a pixel phone with graphene. It would just have much better performance and battery life (given equivalent hardware, let alone the actual hardware differences).
Like I have tailscale, I ssh into my devices, I can write my own apps, sideload whatever I want. It even has a full Wayland graphical environment where I can play a video inside desktop chrome if I wanted to.
I am the administrator of the system on my phone. It's the same OS as what I've been using on my PCs for decades, so it's very familiar. It's fully scriptable in whatever language I wish to use, so I can easily adjust its behavior. I can use sandboxes when I need them and ignore them when I don't. Its software components are replaceable and patchable - if something bothers me, I can write a patch, compile a patched package, install it and even send a merge request upstream right on the phone itself without using any other device - regardless of whether it's about desktop environment behavior, cellular middleware or a kernel driver. I can freely modify the system to my liking without being punished for it. I never have to wrestle with the system whenever I want to keep something running in the background.
It just feels like my little personal computer. No Android device ever felt this way to me. I don't want to feel like a guest confined to a sandbox within a computing device I'm supposed to own.
If you have selinux then you may not be "absolute God either", and arguably it's never necessary to have that much control. I would much prefer to have sane security boundaries so something blowing up won't bring everything down with it.
And there are quite a few devices with unlockable bootloaders so you can feel to hack whatever you want with AOSPs.
I had to build a patched Android image in the past, so no thanks, it's definitely not something I would want to do in my spare time just to tinker. It's a system that's designed to be user-hostile; you can fight it if you want, but why would I do that if I can just keep using GNU/Linux instead?
Unless regulators enforce (at the very least) that hardware documentation sufficient to produce open source firmware/drivers must be supplied with that hardware, no - probably not.
Drivers and firmware are the biggest hurdle outside of locked bootloaders for competition in the operating system space.
Examples; Anything Apple (MacBook, iPhone), anything Samsung, anything Google, the list goes on.
There _is_ open hardware, but it has poor performance / battery / build quality and the vast majority of users will not accept that.
IMO "the right to repair software" is essential and this duopoly is a function of explicit monopolistic practices.
Maybe LLMs can help open the "reverse engineering" Pandora's box - but we have yet to see that realised - at least for drivers / firmware
That's one way to look at it. I applaud Apple and co for what they have created, but even drugs have patent expiries, eventually becoming generics.
I'd be fine with that model - let them make money for 5 years recouping their R&D costs, then they must offer documentation so the community can repair / maintain the hardware themselves.
I personally see it as falling under "the right to repair" and selfishly, I know we can do more with the hardware than they are demonstrating. It's endlessly frustrating that we are not allowed to and then the devices just disappear forever.
>I applaud Apple and co for what they have created, but even drugs have patent expiries, eventually becoming generics.
In the US, all patents have 20 year terms (from initial patent filing). Of course, patents don’t tell you how to make something, so it’s not sufficient for something like smartphones or medicine.
Patents that don't tell you how to make something should not be enforceable, this kind of knowledge transfer is the whole premise of patent protections.
I'm always surprised when I read articles about Linux phones that don't mention VoLTE support. Without it, phone calls will drop constantly as we tear down old cell infrastructure. In my experience I've only been able to find one phone that supports VoLTE in America. I get the impression that there's much more interest in Linux phones in Europe where VoLTE (or whatever it is over there) support seems much easier to achieve.
The Furi guys put an insane amount of work into getting their phone working on every network in America. They have a Telegram channel where you can talk with the developers themselves. They will SSH into YOUR phone and poke around if they can't figure out what's going on on their end. These people work like crazy to make the experience seamless.
Phone specs, UI, security support, etc are important but if I can't make calls on the thing I'll never even consider it.
I'm pretty sure both Librem 5 and PinePhone can use VoLTE in the US. The former you can even buy together with a MVNO service that's just guaranteed to work.
I forgot about the Librem. I originally used the PinePhone 5 years ago and had to switch to a OP6 because the PinePhone was unbearably slow. It looks like Mobian and PostmarketOS both support VoLTE on the PinePhone now which is good.
BTW, isn't VoLTE on devices like OP6 pretty much a solved thing by now as well? These devices with no discrete modem had to configure all the IMS services manually over undocumented QMI interfaces (as opposed to a documented AT command than then makes the discrete modem do the same thing internally), but I believe that has been figured out some time ago already.
When I ran the OP6 5 years ago on PostmarketOS it wasn't working. I had a PR open with the devs and we tried to figure it out but lost steam. It looks like someone on Reddit got it working two years ago:
So yeah, 5 years ago it wasn't so critical to have it yet, and by the time it became critical it also became supported. Perhaps that's why you keep reading articles that don't mention it :)
Agreed. I assume aftermarket Linux support for Android devices with out-of-the-box unlockable bootloaders (including the OP6/6T) is the most likely path to viable daily-driver "Linux phones" in the future, and it's strange how the linked article doesn't seem to mention this at all.
Yes, I probably should have addressed that in my article, but my primary focus was on whether Linux phones can grow from being a miniscule niche for nerds like me to being a real alternative for normal people to Android and iOS phones. I would guesstimate that around 10,000 Linux phones were sold in 2025, which represented 0.0008% of the global smartphone market that year. The question I was asking is whether we can get to 0.1% or even 1% of the market. Rereading the article, I see that I wasn't very good about explaining the focus of the article. There was so much technical stuff to cover, and I got a little lost in all that.
If you look through the list of recommended devices for Nura (formerly postmarketOS), the only one that has full software support for all the hardware is the Librem 5, and the second best supported phone is the PinePhone.
The rest of the phones are dated Android devices which all have significant functions that don't work correctly. The processor with the best support is the Snapdragon 845 from 2018 in the OnePlus 6/6T, POCO F1 and SHIFT6mq, and all of those devices have issues that a geek like me can accept (like downloading code from github and manually compiling to get a partially functional camera), but it isn’t really an option for ordinary people.
I think that it is very important that there are native Linux phone manufacturers, totally independent on Google, and thus also independent on Android and Android Open Source Project (AOSP), or Android kernels in any way.
A cash flow is essential to sustain a Linux mobile ecosystem. And in the Linux world the sell goes often once. Just when selling the device itself. But software has to be maintained, and people have to be paid. Therefore, I highly recommend to buy a native Linux hardware device, independent on Android, if you want to support mobile Linux, and have the financial means.
There are options to donate to different mobile Linux projects as well though. Only a small donation can already make a difference, especially if many people are providing such support.
It is hopeful to see how different Linux phone software projects, and Linux phone competitors in a way are all working together to further a truly free operating system. The phone market is large enough for native Linux phones to exist next to each other. So not Linux as an aftermarket, but Linux native phones that support the whole mobile Linux world. And yes, also there is place for aftermarket Linux support, but I doubt if this would be enough in the long run.
Let's make a thought experiment: let's think about designing a new Linux distro from scratch. Obviously starting with Linux-the-kernel, and then thinking about what we need to be a modern smartphone OS.
- We'll probably want the security model, with the nice sandboxing and I would argue the verified boot.
- We'll want the battery optimisation.
- We'll want access to the firmwares of the components running in the phone.
- ...
From the very first step "start from Linux-the-kernel", every single question I ask myself goes towards the Android design and away from the classical Linux distro design.
In other words, the open source Linux distribution that is the closest to a modern mobile system is... Android :-).
The best battery life I ever got on a smartphone was on a HTC One X back in 2013 or so. It had a custom ROM (Paranoid Android IIRC) where I stripped out all the google services, blocked all wakelocks and so on. It had an nvidia Tegra3 CPU, which had 4 normal ARM cores and a 5th tiny core that ran at 100Mhz or so max (with powersave governor). On that setup, when I was not using it, it drained like 2% battery a day (50 day runtime).
Since then we went from 40nm to 3nm, 2000mAh to 5000mAh, I'm doing the same things on my phone and yet, due to bloat and spyware the battery life is worse and worse. I went through HTC One m8, HTC 10, OnePlus 7Pro, and a Samsung Fold7 and each had worse efficiency than that 2011 CPU on the OneX (And a Nexus7-2012 until it died due to low quality NAND)
I mean, it was still connected to a cell network, so it was fully usable except maybe notifications. (Obviously the battery drained faster during active use)
Ah, except ONLY notifications? Wow, really not important for a smartphone. Not to mention other background operations that most people want to rely on.
See back to my point about terminal dudes with broken laptops thinking that's good enough.
Even more so, it is the closest to Inferno's design, which was the evolution the UNIX founders went through.
Like they created UNIX, they declared it done, created Plan 9, followed by Inferno, most as a reaction to JavaOS, but still, the creators of UNIX moved on.
Whereas the FOSS community seems to be stuck in recreating Bell Labs in the 1970's.
Most of the FOSS community is hostile to even creating basic sandboxing. The Flatpak project gets panned all the time. Not for having a weak sandbox (which would be a fair criticism), but for having a sandbox at all and not using 90s-style package management.
A lot of people from the FOSS community seem to believe that (at least from recurring discussions) that Linux is secure because the software is open source and you can trust the maintainers. The idea that even trusted software can have vulnerabilities and that the 80s/90s security model of the standard Linux desktop means that you are only one Mastodon/e-mail/RSS/whatever client vulnerability away from exfiltration of your whole home directory does not even occur to them. All the while all these applications use (XML/image/...) parsers from the 90/00s written in C.
The only reason we don't see mass-exfiltration of data is because the Linux desktop marketshare is effectively meaningless. Though we see some results of the desktop security disaster (also to some extend of macOS) through leaked credentials obtained by compromised NPM, PyPI, etc. packages.
> Most of the FOSS community is hostile to even creating basic sandboxing.
> 90s-style package management
> 80s/90s security model
> parsers from the 90/00s
Perhaps the crux of the issue, and the reason these new systems get pushback, is because people, myself included, don't like being told that they have to stop using the tools that served them well for arbitrary reasons (usually age). Similarly, you can't expect everyone to trade user control, convenience, usability, and more for security, or sometimes perceived security.
We can debate about the 90s style package management, but old C-based file parsers and DAC access control were certainly not designed for modern attack vectors. Defending a device now requires layered security using a combination of among other things:
- Memory-safe languages where possible.
- Sandboxing of applications, parsers, etc., along with a strong permission model.
- Mitigation like secure app spawning, zeroing out pages, etc.
- Modern mitigation hardware-assisted mitigation like MTE and PAC.
- Storing secrets in a separate secure enclave (not ~/.config or ~/.ssh).
- Read-only and fully verified system partitions (anti-persistence).
from Apple's MIE docs [1] shows where modern systems like iOS and Android are. An attacker often needs a long exploit chain to compromise a device and it becomes increasingly difficult with various mitigation techniques. On the standard Linux desktop it's often as easy as exploiting an image parser in a client. Old parsers in C have a history of bad vulnerabilities, exploiting one often gives you privileges of the process calling the function, since Linux applications mostly don't separate/sandbox parsers and from there you have direct access to all data of the user, since Linux applications are typically not sandboxed.
Lets not forget that the motivations for Alef, and Limbo, from the C authors themselves, were also to improve language safety.
In Inferno, only the kernel, DisVM (+ JIT), and a few drivers are still C, everything else in userspace is Limbo.
> Limbo is the application programming language for the Inferno operating system. Although Limbo looks syntactically like C, it has a number of features that make it easier to use, safer, and more suited to the heterogeneous, networked Inferno environment: a rich set of basic types, strong typing, garbage collection, concurrency, communications, and modules. Limbo may be interpreted or compiled ‘just in time’ for efficient, portable execution.
Another angle on this is general reliability and what that does to the experience. I'm reminded of Linus having a moan about poor availability of ECC in consumer RAM and how many errors that get blamed on software are actually down to something happening to hardware but it isn't specifically identified. Plus when you're talking billions of devices even small proportions are significant. Firefox built a memory tester into their bug reporter tool as that 'noise' became a large enough problem for them.
Which is of course after having met those requirements IOS is basically android with a different name and closed source and we only need one player that isn't even properly foss.
Or why ChomeOS invalidates the need to keep working on kde/gnome/etc
Or that isn't the case and this is all just a silly comparison.
He’s saying the examples given were so generic that every OS that cares about battery life and security would just be Android. Battery life optimizations and sandboxing don’t make Android inevitable or the only option.
WebOS was a 3rd option until HP sold it off. Microsoft also had a go at it. They were both very different than Android, but would have those features (if not then, they’d have them by now if the projects were still going).
Well then he is missing my point. Which may mean I was unclear, or course.
My point was that "Linux on Mobile" seems to be mentioned a lot when talking about an alternative to evil BigTech. The thing is, if you want to fork something and make it a modern mobile OS, you may as well just fork Android and go from there. Because Android is open source and already has billions of apps.
Microsoft didn't make an open source system, I think? I had never heard of WebOS, so I'd be open to it, but the fact is that the "Linux on Mobile" crowd is more into Alpine or Debian running on a mobile. Which is far from a modern mobile OS.
I totally respect the Linux on Mobile projects, they do a lot of cool stuff. But I don't see that being a serious alternative to modern mobile OSes anytime soon.
I didn't go into that in this article, but given the number of comments here and on Reddit, I think I should write a second article that explains my thoughts on why I think Linux phones are better strategically than AOSP phones. I'm not opposed to AOSP phones--I use my two AOSP phones more than my two Linux phones. Most people aren't going to use the current Linux phones. Even I as someone who has using Linux since 1999 find that the functionality of the current Linux phones doesn't match AOSP phones. However, I think using AOSP helps lock us into the Android ecosystem, whereas using Linux helps build an alternative ecosystem which is what we need for long-term independence and freedom.
> which is what we need for long-term independence and freedom
Sources are required here. I think that Android being open source is great, and I actually run a fork of Android (GrapheneOS) which is great.
Again I am not against the Linux on Mobile initiatives. I have been trying them, and following since 2020. I stopped following a bit in the last couple years, but really, what I see is many Linux on Mobile projects that seem to focus on "having a nice UI" and supporting waydroid and being able to use the phone like a normal phone (that is, being able to call someone). And a ton of work mainlining mobile hardware, which I do respect a lot. However, I haven't seen much (or anything at all, really) around the security model.
In other words, the Linux on Mobile philosophy is really "bring a traditional Linux distro to the mobile phone". And the traditional Linux distro doesn't have a security model that works for a modern mobile phone, period.
I would argue that if you rethink the traditional Linux distro to have a modern security model for mobile phones, then it stops counting as a traditional Linux distro and it becomes a new mobile system. Which would be very hard (again, resources against Android), but seems out of topic because this is not what Linux on Mobile is.
This is what their Unity Desktop was for as well. A desktop environment that had a consistent design language from desktop to mobile.
The remnants of all of this are still kicking around, I think the community still maintains the phone OS, but without the weight of Canonical really pushing it, and a phone shipping with the OS pre-installed, it won’t get as far.
Android's security model isn't the only inevitable option. It was an absolute mess when it launched, to the point where I didn't feel comfortable using any apps from the Play Store and gave up even trying the use the platform. They've since copied a lot of the security controls from Apple, from what I understand, but last I looked, I still like how Apple handles things better.
So even in the world we live, there are 2 platforms that handle security in 2 different ways. Those ways have evolved over time. Ubuntu Touch was made 13 years ago. What did security look like on Android 13 years ago? It's a bit unfair to judge it by today's standards. We can only assume an actively developed OS, being used by normal people (not just hobbyists), would evolve and grow to meet the needs of the platform in the market.
I also assume one of the reasons people want a Linux phone is to have more control, having root without needing to jump through hoops, side loading apps, building from source, etc. They don't want to be locked in a sandbox. I think there is also an assumption that people will play better in a classic Linux environment where there aren't so many financial incentives, and anyone who tries to implement the kind of data collection we see on most modern platforms would be booted from the ecosystem until they can play nice. It would be nice if the current duopoly would do some of this, but most people don't care, and pulling apps from the app stores for breaking the rules is incredibly unpopular.
> Android's security model isn't the only inevitable option
I never said it was. I said "we need a modern security model in a modern mobile OS, and Linux on Mobile doesn't remotely have that".
> Ubuntu Touch was made 13 years ago. What did security look like on Android 13 years ago?
That's a bit my point. If Linux on Mobile is 13 years late, against modern mobile systems that get the resources they get (that is, orders of magnitude more than Linux on Mobile), you're not really catching up. And if you had enough resources to maintain such a project, maybe it would be interesting to fork AOSP instead of spending a decade catching up?
> We can only assume [...] would evolve and grow to meet the needs of the platform in the market.
Is that the only assumption we are allowed to make? When countless alternatives from Microsoft, Samsung and others failed?
> I also assume one of the reasons people want a Linux phone is to have more control, having root without needing to jump through hoops, side loading apps, building from source, etc.
Totally, this is what many of them say. Though side loading, building from sources and the "etc" I can imagine totally work with AOSP. I can easily have root on AOSP, I don't know what "jumping through hoops" means here (other than "I want it enabled by default on official builds").
> I think there is also an assumption that people will play better in a classic Linux environment
I believe that GrapheneOS plays nice and makes a nice system. As for the apps, I barely use tens of apps (realistically I mostly use what... ten of them?), so it's not completely crazy to ask me to select 10 good apps from the billions available. And those that are proprietary (e.g. for public transport) I wouldn't have a choice on Linux (probably they wouldn't exist there).
> but most people don't care
I do care. I run GrapheneOS. Because I disagree with you does not mean I do not care.
iOS and Android have an incredible amount of engineering to make them RAM and battery efficient that desktop Linux simply doesn't have.
And its not a case of simply implementing some feature, since all apps have to written with this stuff in mind: apps can be suspended/killed at any time and should be able to restart gracefully, notifications go through a side channel, etc etc
Looking at the amount of RAM phones have nowadays I don't know if this is an issue, desktop Linux runs fine with those amounts. Also Android is not really memory efficient so they needed this workaround.
I currently have 35 apps "open" on my iPhone, most of which are probably React Native or similar.
Other times I'm sure I've hit 60-70.
Because of iOS's app management feature, most of the apps are actually dead, but if I go back and open any of them, they will open and load on the screen on which I left them.
Android does this too.
Desktop Linux cannot.
Can I open 60-70 or even 35 Electron apps simultaneously on 8GB of RAM on Linux?
And no, I do not want to to back to closing apps, that is simply an inferior experience.
> they will open and load on the screen on which I left them.
You can't be serious. Browsers can't even remember the most trivial of things - a tiny html page, retaining reading position, forcing a reload.
Of course many apps are no better (though some do try, just like on the desktop)
And it's especially worse with user input that just gets lost
> And no, I do not w to to back to closing apps, that is simply an inferior experience.
Ctrl+Q to close and a shortcut to open or is a faster and more convenient than swiping around. As is typing an app's name on a real keyboard. Tapping "desktop" icon is arguably better, though, that a mouse click
Of course some apps implement this better or worse, but for an app that doesn't implement this, booting me to the home page (which is just one tap away from where I was) is still miles better than hogging ram.
I don't want to close apps, I don't want to manage my computer's resources.
> It should just work and it should just work well.
That's just magical thinking (thought I totally agree with the sentiment, it should, and Linux should also be better), it doesn't, you're still doing the management, just using a different set of gestures.
For example, knowing about this poor "incredible engineering" I sometimes have to reopen the app in the middle of using another app not to lose my input/position there, especially when I need some basic cooperative behavior like copy paste in multiple steps, where I need to make sure no steps are lost. The primitive iOS system can't guarantee that! And in some instances I'd take the overall sluggishness due to RAM waste over this because then I'd still manage to complete the task, albeit slower, instead of having to redo the work (and in some old apps I could even save intermediate progress to those ancient things called files that Apple despises)
> which is just one tap away from where I was
Except it isn't. If you've scrolled to X% of the document, there is no 1 tap to get back there! And if it took you 5 taps to open that sub-page sub-group it the app setting, then getting from the hope page will take the same 5 taps + some time wasted remembering where you want to go to. And if you lose your input in the input field, same thing, 1 tap won't magically recover it.
And if you're temporarily in a place without (good) network conneciton, you might never get there in any number of taps becaus the page won't load.
Btw, if it's fine to lose user data, than Linux can OOM your apps for you just fine without any extra management on your side. Sure, its current state of app management is not as good as on mobile, it does lack some "engineering" in this regard, though not sure what's so magical about more careful killing of apps
> it's fine to lose user data, than Linux can OOM your apps for you just fine
That's the point. Android and iOS have cooperative applications by design. They implement an interface and apps will save their state on command and restore it on next run quickly.
You can't get it back properly without the apps being cooperative to a degree
Again, what I've started with - this is simply false. App Store, the first party gateway to all apps, doesn't. It loses the app page you're in all the time and can't even remember your search query. Safari doesn't
> On Linux no app CAN implement this because the protocols do not exist.
What do you mean, what stops an app from saving position and restoring it in the absence of some magical protocol? How have some apps done in since before the phones existed?
Huh? I just tested it now and the App Store reopened on the same page I was on and Safari also opened on this page and it remembered what I had written into the text box.
More generally apps can store whatever info they want when they're going away to be retrieved when coming back transparently.
On the other hand semantics on the Linux desktop are such that the operating system cannot inform an app that it is going away transparently.
An app that is SIGKILL'd cannot save anything (unless it is proactively saving all the time which is terrible for battery life), an app which is SIGSTOP'd must save it's entire memory space and cannot relinquish locks or GPU resources, and an app that is SIGTERM'd can ask the user to save their work etc. (which is not what a transparently closed app should do).
No wonder you've been oblivious to this issue with 40 apps. Test better, I suppose? Maybe give it more time for the system to fully offload the app, maybe run a few intensive games if you want it faster or just wait longer?
Have you tried other tabs in Safari? Turned off the internet to see whether it's redownloading a page. (by the way, Safari uses 1G of cache, that's enough to store all my 40 tabs basic htmls, yet it doesn't, it finds other less relevant data more important)
And just for this I've tested two more native apps: opened settings/filters in Magnifier, and started editing a password in Passwords app. I was glad that both of these seem to remember the state, and their app switcher screenshot reflected it (well, except for passwords, which is hidden), but then after a longer time reopened them, and position was gone and I was back on the main page - exactly the experience I came to rely upon with trivial bits of state simply gone.
> is SIGTERM'd can ask the user to save their work etc. (which is not what a transparently closed app should do).
Why can't it save the state without asking??? Have you used text editors with hot reload? They just quit with "unsaved" (but not "lost") files.
And GPU buffers? And in-flight network requests? And notification handling? And D-Bus presence? And watchdogs? And other held resources like pids and fds?
If you want to checkpoint/resume applications arbitrarily, as AOSP does, you have to virtualize all of those resources anyway. Check out the CRIU patchset (since merged to mainline) which can even resume applications seamlessly across hosts, without any VM being involved.
This gets brought up several times in this discussion. Hardware with drivers, firmware and device trees exist, see e.g. Fairphone. It even works with open source camera apps (e.g. done in /e/OS). The problem is not (only) the hardware, it is that the Linux desktop stack is wholly unoptimized for phones. And the fact that Meego/Maemo/etc. are now almost two decades ago shows that it is not 'would be easy to solve'. Heck, Linux laptops, which have been available since forever still have far worse battery life than Windows or macOS.
You need a stack that is designed from first principles for phones. Luckily we have one that is open source (AOSP).
Depending on the phone they'd struggle to go in a low power state when the screen is off or can't access other power saving features because the manufacturers keep everything under wraps.
this. years ago i was working with Intel and Samsung to enable Tizen on x86 phones. energy management was the biggest problem they had. RISC won. moreover, 8 years later Apple was moving away from x86_64 to ARM, so one could say ARM won because of better energy management, either through lower usage or other types of energy saving techniques.
Google Pixel (ARM) had similar issues with battery life, or better yet battery drain during idle times.
People underestimate battery saving techniques. As in all software engineering, when the focus is enablement, optimizations take a second stage.
All this "engineering" really is, is basically just reducing CPU use (trading it for doing things on HW accelerators/offloads if present) and lowering the voltage/frequency to what's needed and suspend/resume. There's no special sauce in there.
App can be easily stopped in linux via SIGSTOP/SIGCONT. It will consume 0 power then. :)
Even original Pinephone has all what's needed for efficient use of energy for smartphone use cases.
And if you stop thinking of "apps" as processes and design architecture differently, you can have millisecond scale reactions to all user input on the entire phone even on original pinephone. Apps opening in a blink of an eye right after boot, etc. :)
Linux phones trying to reproduce Android architecture are kinda pointless. What would be the point, when you have the freedom to implement any other architecture, actually suited for the user centered model, where you don't have to ballance the needs of untrusted app providers.
And it doesn't actually work reliably, at least on Android. My wife and I frequently don't get notifications from specific apps, only once we open them. My impression is that the platform just changes too frequently with regards of what you have to do to work well even when you're killed. Also, especially for push notifications, your now at the mercy of Googles service to delvier them to your app (not sure how the open source variants do it)
There is also the problem, that some OEMs add their own "battery optimizations". If you simply don't run anything its indeed very battery efficient...
Forcing push notifications through some central service has minimal benefits at best. Open source variants are forced to publish annoying persistent notifications and ask the user to flip some "battery optimization" toggle deep inside the settings to not get killed, of course this often enough changes with Android versions.
You're talking about the standard battery optimizations where the end user needs to approve apps repeatedly waking up the app from sleep and running continuously while awake. OEMs have been required to stop doing most of the non-standard things they were doing in relation to this and it's not hard for app developers to deal with anymore unless they care about it on end-of-life Android versions.
The persistent notification for foreground services is mandatory for apps to implement but entirely optional for users. The notification channel can simply be toggled off to hide it. Apps are required to make a notification for each foreground service to provide transparency. It gives apps a way to explain why they're doing it to end users and the notification be toggled off if the user doesn't want it. It can also be kept enabled but collapsed at the bottom with no lockscreen or status bar display. Apps are required to use at least low importance themselves so the user needs to opt in to collapsing and hiding it or turning it off.
Fully open source apps can use UnifiedPush as the Molly fork of Signal does instead of their own push connection. Similarly to FCM, UnifiedPush providers can provide reliable and efficient push messaging including push notifications. Unlike FCM, users can choose the local implementation and the service providing it including the option to self-host it. There are multiple options available as an existing service. There are a growing number of apps supporting UnifiedPush.
Signal's own fallback push messaging for push notifications when FCM isn't present is very inefficient. It substantially reduces battery life even if it's the only app doing push with another mechanism. Molly's UnifiedPush support works much better.
Using a single push messaging connection or at least only a couple (FCM and UnifiedPush) is definitely far more efficient than using dozens. Using many push messaging connections will drain a lot of power due to each needing to be maintained with regular checks which will typically not align well. Having many causes a drastically higher number of wakes from sleep and non-idle time. That's especially true if the push messaging connections aren't implemented very efficiently. Even a single inefficient one can drain a lot of power.
Signal's fallback isn't as bad as it used to be but it's not efficient. They should support UnifiedPush as Molly does for a better non-FCM push experience. Signal's fallback push is a common way people ruin battery life on GrapheneOS.
Push notifications work reliably on GrapheneOS via both Google's Firebase Cloud Messaging (via sandboxed Google Play) and UnifiedPush. Your later replies indicate you aren't using either of those but rather app-specific fallbacks. WhatsApp doesn't implement a reliable fallback. Signal's fallback should work fine but is very inefficient compared to using either FCM or the Molly fork with UnifiedPush. Both FCM and UnifiedPush do work reliably.
Some don't work at all, bc they must be GSF-only I guess (installed via Aurora store).
Others like Whatsapp or Signal sort of work but sometimes the app seems to not be running (even though I set up the no battery optimization). And I get multiple unread messages at once when manually starting the app.
If you aren't using sandboxed Google Play then you're not going to have push notifications in apps solely implementing those via FCM. That's your decision and not an issue with push notifications on GrapheneOS. You're using the fallback push notification systems in WhatsApp and Signal rather than FCM. Neither app cares much about those fallbacks. If you want reliable push notifications without FCM for Signal then you need the Molly fork of Signal with a UnifiedPush provider. There are hosted UnifiedPush and MollySocket services so you don't need to host it up yourself.
That's a very important bit of news to me. As someone that's considering GrapheneOS is there guidance on these decisions either in device or a new users key concepts article I need to read?
Thanks for the tips.
To be clear I absolutely wasn't criticizing GrapheneOS in any way. I know things are this way (and my choice) and I'm perfectly fine with it.
In any case, many thanks for your work. GrapheneOS is a breath of fresh air in the consumer electronics nightmare.
I use sandboxed Google Play Services, Signal has been fine... I cannot say it's always immediate (I'm not always on my phone :-) ), but I have never been frustrated for "missing" a notification. Like when I check my phone, the Signal messages are there, they don't appear 3 days later.
Oh, they certainly don't appear days later. But sometimes they do between ~1-30 minutes. This is a well-known issue, you can find many topic about it. When you open the app, everything comes in all at onec.
It is sometimes annoying to me. I cycle a lot and sometimes my wife or somebody else sends a message when I'm on the go (like picking up some extra groceries) and then I miss it.
There is a longer discussion with various people here:
I wonder if they installed something like "adblockers" in their devices on networks that constantly kills keep-alive connection to Google servers which actually delivers the message.
Or somehow broke the device-side wakeup for that keepalive.
Linux on phones have been around since the late 00s (e.g. through Nokia's efforts). Why would this suddenly change? Heck, even after decades, the battery life of most laptops running Linux is still much worse than Windows, let alone macOS.
I have had several generations of ThinkPads and to this day, battery life is typically ~50-60% of that of Windows, even with all battery optimizations applied. And Windows is terrible compared to Mac or Android/iOS phones.
And I say this as a long-time Linux user (used Linux in some form since 1994). It's just a very hard nut to crack if you miss a certain amount of vertical of integration and coordination across the ecosystem.
We are _not allowed_ to make it good. Without hardware documentation, you're looking at decades of reverse engineering effort just to get somewhere half as far as an engineer with hardware documentation can get in a weekend.
Look at Asahi. Almost a decade in and we can use the GPU at like 30% of its ability on 6 year old hardware.
That a project with major interest. No one cares about spending a decade reverse engineering the hardware on a Google Pixel or Samsung Galaxy.
If they gave us proper full hardware documentation, we could create high quality alternatives. Again, we can't so you don't see it.
Competition is good. We should always advocate for things that enable competition.
> Without hardware documentation, you're looking at decades of reverse engineering effort just to get somewhere half as far as an engineer with hardware documentation can get in a weekend.
I'm not sure this is true anymore and it is becoming less true with each new LLM release.
> No one cares about spending a decade reverse engineering the hardware on a Google Pixel or Samsung Galaxy.
Actually, this might a cool idea - just get a few super cheap smartphones, connect them all to a PC, give LLM access and tell it "make linux gud like android pls" and just give it a weekend.
Even if you have the binary driver and you decompile it with the help of a LLM, it does not provide most of the information from the documentation.
You may see that the driver writes some hundreds of magic constants in some hardware registers, but you do not know what they mean. You may be able to do exactly what the binary driver, does, but you will not be able to improve it, e.g. to enable features that happen to be not enabled in that driver.
So a LLM can speed up the initial part of reverse engineering if you have the files with binary drivers, which may be difficult to extract from certain phones, but a lot of work remains to discover all that the hardware can do.
The first is that google is currently rugpulling via various means and _really_ playing those anticompetetiveness-cards. That wasn't the case previously. So there wasn't much motivation to care, because android was "open enough".
The second is that the world is getting less geopolitically stable. So the whole ecosystem lockdowns are not just a personal preference thing but might be actually vital.
The third is that LLMs are kinda good at these optimization loops if you hand them a framework in which they can sample good data.
I also had a fourth thought but it left my mind :(
Android is still open enough. Worst case, AOSP can be forked and it will still be leagues ahead of non-Android Linux phones. That also applies to the sovereignty point. I see especially GrapheneOS and /e/OS grow because of this in local communities.
LLM-driven optimization is a good point. However, Linux desktop communities tend to be quite aggressively anti-LLM. E.g. GrapheneOS has been heavily attacked by these people for only using an LLM for security auditing. But maybe these projects will fork into LLM-accepted forks who will then rapidly out-innovate.
If you look at ARM, SBC and MiniPC market, Linux can be very frugal when it comes to power management and RAM use. Just because a bog standard Ubuntu or Debian is not tuned towards it doesn't mean it can't.
It's a problem at the Wayland/Wayland protocols/XDG level.
There is simply not enough rich app activity information for the session manager to do smart management.
Compare it to what iOS and Android apps report about themseleves and the conditions they are forced to run in (such as being arbitrarily killed and restarted).
Obviously the Linux kernel is perfectly able to sit in a stack like this (see: Android), it's the XDG standards which are not well suited for this.
I don't want to add yet another standard because the best part of the standards is there is too much to choose from.
It's a matter of signaling, though, and if we improve the signaling, we can build upon it.
Again, it's not a simple task (I dug into GNOME's compositor for two weeks just to find a note saying "Errm, we didn't implement this to X11 specs and it does funny things on touchscreens. If somebody can do this all over, we'd be glad. KTHXBYE"), and we were developing something for touch screens, albeit huge ones.
It’s not only a matter of tuning. Everything in the stack needs to be developed to go idle and not do things in the background by themselves. The Linux desktop and all its apps are made for a model where apps can continually get CPU time.
I know, but that's a set of libraries. Nothing which can't be done, because the foundation is there. In most basic terms, you need to be able to freeze apps and be able to tell when they have nothing to do, so they can be scheduled with minimal time slices to run a single, lightweight function to check whether they need to do anything at all.
Of course it's more complicated than that, but it's not impossible, since the foundation is already there.
The hard part isn't having a few people design something powersaving, it's having the whole set of distro software working together for power savings.
That's the incredibly hard part - not having some random package run a cron job every 10 seconds because it was easier for the developer to do it.
And Linux developers get incredibly angry - keeping grudges for decades - if you try to add systems that enforce power saving behavior necessary for devices to last a whole day.
This is where the difference between Android/iOS and Linux distros lies in practice. And people are still - even on HN - incredibly angry at Android for not letting them destroy the battery anymore.
It's just closed source drivers stored in private Linux forks (or Apple's code dungeon).
There's nothing inherently special about their optimisations, but hardware is incredibly complex and without documentation, open source drivers cannot be written that are anywhere close to what engineers with hardware docs can build.
Asahi Linux is a great example. It's an unbelievable project but still far from first party Apple drivers.
Once the hardware can actually be used, competition in the OS space will follow.
They have no incentive to offer documentation and competition is bad - so they won't allow that. Regulators must step in here.
the manufacturer of the gsm and cellular hardware do not what their products to be commodities that users can interchange easily. They want their commercial supplier contracts to be between negotiated cartels, which allows each producer to eat a certain horizontal slice of the pie.
Every player in this space currently has this incentive imho.
While everyone that was doing vertical integration in the last century, had the whole product to sell, the OEMs selling IBM PC clones were all alike, so they always had something to differentiate, being the shovelware that was offered alongside the PC, pre-installed, painted cases, whatever.
What a fantastic article. As someone who has contributed to Phosh and Nura (prev. postmarketOS), I was always sad that Linux phones didn't take off. This article describes very well how difficult the firmware/hardware side is, which as a software guy I hadn't quite understood.
The software side (Phosh, KDE, etc) is now improving fast (both IMO because the obscure frameworks they're written in are easier to contribute to with AI, but also just thanks to time and maturity).
And if the firmware/hardware side can graduate the treadmill of endless bring-up and instead work on performance and fun stuff, that would be fantastic. We need our Raspberry Pi moment. First the Librem and Pinephone were our hope, then the OnePlus 6, but they all stayed 80% usable. Currently it was the Fairphone, but now tbd which the savior device will be. Exciting!
I wish the Ubuntu Phone kept going. Damn shame. I liked Ubuntus storage offering, it felt like Ubuntu was trying to compete harder with Windows in a nicer way, sadly they abandoned a lot of those initiatives, what could the world look like if Ubuntu found the right hardware partner to get Ubuntu devices into most mainstream computer stores? We wont ever know I guess.
I think that given the current capabilities of LLMs, it should be possible to deploy a completely non-Linux-based system on any smartphone—even one with entirely different control algorithms for the CPU and memory.
If i will not able to get in control of the device, at least as much as macos level, and still able to make contactless payments, approve online payements, breaking the duopoly will not matter much for me.
Maybe i should aim for a second smallest possible android phone just for banking to set my mobile computing free. (İ was already tried using unihertz jelly star as my daily driver for a while)
Before the talks of alternative platforms, there should be legislation in place for services to expose http endpoints for all services rendered. I.e., a legitimate user should be able to point their web browser at it--behind whatever authentication and bot-detection shenanigans they want--and avail the services. No apps, no crap, no bloat.
In other words, the 'app culture', and the attendant normalisation of data stealing, must end. This effectively takes "app-" and platform-dependency out of the picture. Services are no more burdened with supporting n number of platforms; nor do they have an incentive to push people to start using their apps. Services can still offer an app, and users still have a choice to use one. But, the baseline client should be a browser. And there shouldn't be any discrimination between mobile vs. desktop browsers, either.
Sailfish OS is, IMO, good enough for daily use. I do use their (Android) App Support for a few apps out of convenience because, for example, I just like Symfonium music and audiobook player. However, if I would approach it more strictly, I could comfortably live without Android on the device at all. Do take that with a grain of salt, though - I don't use mobile banking apps and NFC payment, for example.
edit: The hardware supply chain is an issue, though. It's all Android hardware under the hood because that's the only thing you can buy. So there are crutches necessary to translate between Android drivers with their hardware abstraction layer and "proper" Linux. Libhybris does that in case of Sailfish OS / Jolla (the company behind the OS) and it works well but I wouldn't call it elegant, necessarily.
“Jolla has sold 15,000 units of its phone as of August 2026 just by taking pre-orders for production batches from its web site”
In comparison, Apple easily sells 15,000 phones each hour of the year.
So, the best hope for such a Linux phone would be to have something installable on hardware of a third party that normally ships Android. I don’t see that happen because such hardware gets locked down more and more to defend against cybercrime.
I don't think it is fair comparing Jolla agains half of the current Smartphone monopolists.
Also you need to build an ecosystem so that users and developers can get involved & open hardware fully supported by Sailfish OS is a good start.
Also a lot of mainstream mobile hardware is locked down on purpose to effectively enforce planned obsolescence, which makes it harder to port a sane OS on it.
No, Linux phones won't become a viable alternative to Android or iOS phones.
The average phone user couldn't give a damn about the underlying OS - they buy on price and features - not the "hackability", or whatever drives the good readers of Hacker news to buy phones.
I wonder whether Android/iOS will ever become a viable alternative to GNU/Linux phones. They failed to make me switch for nearly two decades now and only seem to be getting worse.
I can't speak from personal experience, but nearly everyone else in this thread is arguing the opposite: Linux phones are slower and buggier than Android.
What metrics/specific reasons drive your contrary POV?
My personal experience. I've been using GNU/Linux on my daily driver phones for nearly two decades now. Started just before the first Android phone appeared on the market and went through a bunch of devices since. Android never appeared to me as a viable alternative during that whole time (it was in fact closer to being one in the past than it is now) and iOS has just never been something I'd like to use.
I have listed several reasons why I think so in other threads here already, but the main thing is that what I longed for in 2008 when I was getting my first smartphone was a connected personal computer that I can put into my pocket and carry around through a day, and that's what I was always getting with GNU/Linux phones, so I never really got used to the idea of smartphones as these limited, mostly vendor-controlled devices that effectively serve as a trusted runtime environment for adversarial software (and by "trusted" I mean trusted by apps, of course). Instead, I see my phone like I always saw my GNU/Linux PCs - as a tiny box full of useful tools that are there to serve and empower me to reach my goals and which I can put together and modify any way I like to. May not have the sleekest design out there, may not be a speed demon, may have a quirk or two to tolerate and may require me to scratch some itches by myself, but it does what I tell it to regardless of whether it's aligned with some corporation's interests or not and it's well worth the effort spent to configure it to my liking. It's also generally a wonderful thing to tinker with (though this mattered much more when I was still a teenager :))
Inevitable given that a lot of dev entrepreneurs are moving from high level CRUD to low level software, CAD and hardware now with AI. But it might move beyond Linux once AIs come up with their own programming languages.
I’m working on a personal OS, a personal website that runs on my computer and I access on my phone thru Tailscale.
Then I got thinking, could I not just make a phone and messages mini apps for my personal OS that tap into iMessage and FaceTime on my Mac? Even if those don’t have APIs, you could use computer use and accessibility. A 3rd OS should simply be the web and a thin client that connects to your MacBook thru Tailscale.
I've already tried linux mobile oses on a few devices but they all have issues with calls and sms working. I have no idea why devs don't focus on the basics of a phone working as a phone and instead j*k off over the ui (which is still slow and buggy) or other apps. Because why would I need a fitness app, a step counter, some fancy notification animations etc if the phone doesn't work AS a phone?
Consumers are not developers.
Let's think about why Windows have dominated commercial desktop OS market over Linux.
If there is no market(users), there would be no apps to use.
Have you looked at the FuriLabs FLX1s+? You can also buy a used Volla phone on ebay and install Ubuntu Touch. Jolla has says that it is considering selling its Jolla Phone (2026) in the U.S.
Betteridge's law of headlines is an adage that states: "Any headline that ends in a question mark can be answered by the word no." It is based on the assumption that if the publishers were confident that the answer was yes, they would have presented it as an assertion; by presenting it as a question, they are not accountable for whether it is correct or not.
I have been using Sailfish OS from Jolla since 2013 on my main phone. They are even selling a new phone with Sailfish OS preinstalled now: https://commerce.jolla.com/
Uhmmm...no. Developing an operating system like Android requires hundreds if not thousands of engineers and hundreds of millions of dollars a year. I don't see a couple of smelly haggards in a basement attaining the same level of quality and depth anytime soon.
I mean, it took Linux more than 30 years to come somewhat close to the desktop experience Windows has been given us.
Any mobile operating system would need, in addition, something extra to compete with iOS and Android. Like a real-time microkernel operating system to enhance security.
I wish. sadly, no. even the year of the linux desktop may very well never come to pass. I've always felt there's always been a fundamental disconnect between what linux users/devs THINK general audiences want, and what they ACTUALLY want. I applaud them for all their hard effort, they've really come a long way, and they never even got a dime for it (W foss, L microslop), but man the ux has always been a nightmare lol.
I absolutely love my laptop running mint, its running better than it ever did with windows, but I could never recommend something even this 'simple' to someone who isn't a hobbyist, or has a lot of spare time to configure and maintain it, or cares about their privacy, etc. I understand also there's many other factors at play here that are completely out of the hands of the dev/community, like the fact its almost never natively supported by just about every app, and I dont mean to put that on them either. they're just more factors holding it back from mainstream adoption.
so if that's been the case on desktop, smartphones are just so far out of the picture. i dont see how the year of the linux smartphone could ever come before the year of the linux desktop.
I really hope I'm wrong. thanks for reading my meh-ly informed 2¢.
> I absolutely love my laptop running mint, its running better than it ever did with windows, but I could never recommend something even this 'simple' to someone who isn't a hobbyist, or has a lot of spare time to configure and maintain it, or cares about their privacy, etc.
My non-technical relatives run Debian just fine. I don't understand what you are talking about. It has unattendend upgrades and doesn't have to be configured or tinkered with after install.
Degoogle Android, Actually quite easy to bring back google service. I'm using the Chinese-version vivo x200p, the most troublesome is having to put app in enery-intense mode if you want them to run in background, or else the OS will kill them if they are unused for a while.
Huawei's HarmonyOS is quite good. As for other brands like OPPO and Xiaomi, I've used them before too. You can use Google Play and a whole range of Google apps, but the localization adaptation is much better.
I have a hot take on this: I don't think iOS and Android have long for this world. In five years, phones will just be an AI device. Local compute when possible, cloud compute when required. The OS will be whatever the AI dynamically creates for the user's tastes and requirements. People won't buy apps anymore. They'll create them on the fly as needed. In rare cases where an app purchase happens (such as a YouTube subscription), the AI will facilitate the purchase with Google's AI.
This makes me tremendously excited someday to take a hammer to my current phone until it is reduced to fine dust, replace it with a perfectly dumb landline, and never give the matter a second thought.
I've just written another post somewhere in this thread about discovering a nice feature in KDE Plasma, and remembered my recent search for a way to output HDMI from my old iPhone without ridiculous compression, and all this Linux phone talk stated to make me have crazy thoughts about how much I want Plasma Mobile. I was all set to write "just give me Plasma Mobile on something the size of an iPhone 13 Mini, and I don't care how much doesn't work". I used a 1st Gen iPhone SE, years past where it was sensible. I can suffer.
I started to list my few, basic must-haves - aware that everyone has a different list - but my own short list got embarrassingly long, very quickly. I thought I had simple requirements!
Obvious basics which surely aren't too much to ask: email, calendar, reminder and note syncing, password manager with TOTP generator, instant messaging (willingly to compromise and have only Signal or WhatsApp), route navigation, basic browsing, half-decent camera, ...
Phone calls - so I probably need 4G and 5G...
Oh - plus uncountable other small apps or utilities that hardly seem worth mentioning: calculator, file browser, compass, voice memos, ...
And then I thought about the ever-growing list of big, ugly Apps that I could live without, but really do make my life easier. Banking apps (sigh - I hate how many of these virtually require an app), the app to unlock my apartment block door, Outlook, Teams, ...
And then I started having sensible, disappointing thoughts. Maybe I'd rather just keep the iPhone 13 Mini. I just got a new battery (and bonus screen) installed by Apple on the weekend...
But seriously, when that starts to be unusable... if I have to carry something obnoxiously large, it better run mainstream Linux and turn into a desktop when I plug a USB-C dock into it!
- Lack of ACPI support means you need to spend time to customize every ROM using whatever device trees and proprietary blobs for every phone
- Most phones have locked bootloaders
- Most importantly, Android apps are built for Android. They can run in things like Waydroid, but certain interactions will be broken and app developers probably won't support it. People want phones that work well out of the box.
So, no. Maybe an actually-open Android fork will gain popularity, but mass adoption of a GNU/Linux mobile OS won't happen.
Imo they already are.. They're actual non-hobbled computers you can do what you want with. Think of all the things you can do on Linux.. Now you can do that on your pocket sized computer.
Sure all the conventional mobile ecosystem stuff wont work. But that's entirely a giant ball of cancer anyway. Only a fool would want to deal with that filth.
So much Pine64-bashing and quite a lot of factual errors.
There were several pinephone HW revisions that fixed HW issues based on direct developer feedback. Yeah, there was no direct communication with HW engineers, but at least the critically important feedback was applied (otherwise modem would not be able to wake up Pinephone SoC from sleep and Alt-D over USB-C would not work at all, and probably bunch of other things I barely remember). I or someone else in #pinedev could tell TL Lim, and if change was reasonable it would be made. There was quite lively discussion around HW issues in #pinedev early on. And company did not seem to lack effort, eg. for Pinephone keyboard there were like 5 revisions, including doing an X-Ray analysis of burned down keyboard MCU and subsequent citcuit improvement. So communication to get HW changes was possible, and was usually via TL Lim, not via HW devs.
"The volunteers working on the PinePhone's kernel generally didn't [upstream]" is factually completely wrong.
PinePhone DT was mainlined for Linux 5.7 by me. smaeul rewrote the sun8i-codec driver and did lot of stability and other work, anarsoul upstreamed Bluetooth and maintained Lima, and many many many more small upstream contributions by different people (git log is your friend), just on the kernel side. People created entire new upstream projects like Crust and p-boot and levinboot, etc.
Yes, there's some long residual stack of patches, but so what? Accurate statement is that some perhaps critical work stayed out-of-tree, partly by choice and partly due to upstream rejections or dependencies, and not that "the volunteers generally didn't upstream." The claim is overstated to the point of being misleading.
And another thing is that even if there was lack of upstreaming, almost no Anroid phone is fully upstream in Linux and it doesn't prevent it from gaining marketshare. Downstream kernels suffice for it.
Latest version of supported downstream kernel for pinephones with good HW support has been available for years. Almost no Android phone can even claim that for their downstream kernel.
Then there's over-estimation in the article of how upstreaming to kernel is important. You can easily say that having full HW support quickly in some downstream kernel is kinda preferable, because it allowed people to actually use the phone sooner, and allowed userspace development to progress. If every change would have to go to upstream, with its long iteration times, etc., people would not be able to use the phone at all for 4 years or so. How many would even stay around? :) I ceratinly prefered making the HW work and work well, over upstreaming. I understand upstream kernel is a distro maintainer wish. People are free to have wishes. :D
Pushing upstream changes coordination of work and to some extent simplifies maintenance for some, while making it way harder for others in the community.
The article says PPP "still had major software problems when its sales were cancelled in August 2025.". Yeah, no. Pinephone Pro has almost full kernel support, multiple bootloaders, even graphics/touch support for U-Boot, etc. There are no SW kernel issues that I'm aware off that were not solved years ago. Yes, again, you need a downstream kernel, but it's been maintained for every release for years since the beginning, just like PP. It's very similar situation to Raspberry Pi, which also sucks without downstream kernel, but did not prevent it from reaching marketshare, or whatever. Commercial cancellation is more lack of interest/commercial viability, rather than anything pointing to lack of SW support.
The article opens by promising to "examine what held back mobile Linux." Well, it consistently assigns blame to companies/vendors while treating the enormous volunteer engineering as background and blameless. Well it's not.
As for the company: Pine64 promissed 10 years of original Pinephone. It's so far delivering what? 8th year? At the same/similar pricing to 8 years ago, across all that happened in the HW industry in the meantime? Covid? Ramocalypse? I'd call that a massive success on promissed claim. The company also never promissed fully working OS/HW android experience. It promissed cheap accessible long-term stable HW product to jumpstart the ecosystem (paraphrasing from memory). And I thoroughly enjoyed developing and supporting Pinephone on the kernel side for 8 years release after release, building well designed (as far as UX goes) bootloaders, and interacting with TL Lim and wider community, etc.
"Once the best volunteers abandoned PINE64, the company hasn’t been able to complete the development of the PinePhone Pro, PineNote, PineTab2 and many of its other projects, so the people who ordered these devices are unlikely to ever be able to use them as fully functional devices."
Sooo. what HW support is lacking on Pinephone, Pinephone Pro or PineTab2 or Pinebook Pro, or other consumer products, if you take some downstream maintained kernel and use it? You'll find that very little of consequence is missing. I know of one: HW accelerated video encoding on original Pinephone. The only claim I see other than performance, is lack of "HW accelerated video encoding". But who would want to record videos with webcam level sensor that uses CAF for auto-focus? Has anyone even tried to imagine what it means practically when you get CAF full range sweep in the middle of the vide? :)
Performance is not really relevant to "level of SW support".
You can also say that perhaps people drifted off after the work was mostly done, because there was nothing more exiting to do, other than absolutely unsatisfying gruntwork that even paid engineers at most android shops don't bother to do.
"but instead PINE64 dismissed the screen flicker" is also incorrect, IIRC. I remember suggesting removal of some resistor to avoid leakage of power into PL port power rail, that caused variation in backlight PWM control voltage, since PL rail served as a voltage reference for backlight PWM. And it was resolved.
Hi Megous, I'm the author of the article. Before we get started here, just let me say from the outset, thank you for all your hard work on the PINE64 hardware.
I will correct the things that I got wrong in the article, if I can verify my errors.
I have the PinePhone 1.2b (Beta Convergence Package), that was shipped to me on April 5, 2021. It is currently running Mobian Weekly with kernel 6.18.32.1, which I downloaded about three weeks ago.
I see the flicker on my PinePhone's screen. I usually see it for a minute or two after I turn on the phone or resume from a suspend, but I sometimes see it at other times. I see the flicker both when the screen brightness is set to a minimum or to a maximum. I have seen this problem the whole time I have owned the PinePhone.
I assumed it was caused by this issue: https://wiki.pine64.org/wiki/PinePhone_v1.2#Backlight
However, rereading it, my case doesn't fit, because the screen flicker exists at both minimum and maximum brightness. Can you explain this?
Maybe my screen flicker problem is special, but was the problem listed on the wiki ("When backlight brightness is very low and the CTP controller actively communicates on the I2C bus the backlight blinks heavily.") ever resolved by PINE64?
There are several possible causes of screen flicker.
One cause of screen flicker is if display is not properly turned off and driver does not wait the required 120ms after turning it off before cutting the power to it. Then on the next display power on, it may very visibly flicker for extended period of time, depending on time between last power off and next power on of the display. I believe mainline kernel driver does not wait. This was my bane when I worked on p-boot bootloader. :-D
Things in mainline get regularly broken by unrelated work, so maybe this got broken by the unrelated kernel change in 2024 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... that caused the clock that feeds the timing controller for the panel to not be able to set required 432 MHz to achieve the specified 60 Hz, so if you run mainline kernel change made for Olimex laptop caused Pinephone panel to be driven by 16% faster clock and refresh rate is almost 70Hz, which is out of spec. It can only be fixed by revert, without breaking anything else like eg. convergence functionality. Probably not the source of the flicker, but who knows how borderline panels behave. Eg. the mentioned commit says that pinephone SoC MIPI-PLL is unstable at 432 MHz, yet it does not acknowledge what that driving the panel at 16% faster clock may result into at all, from 16% higher power drain due to every userspace app having to render at 70 Hz, to stutter of video playback or UI stutter in systems that don't derive all timing from the display (eg. if input is read at 60Hz and output is done at 70Hz this can really mess up the UI feel) to behavior on borderline panels.
Panel clocked at higher than expected frequency may not complete the required LCD dicharge process correctly/completely due to compressed time (and this error may accumulate over several power on/off cycles), because it works with different than expected timings to complete a fixed physical process. (partly speculating here - what I know for sure is that this issue that causes flickering accumulates over several power on/off cycles if poweroff is done wrongly)
In any case, for my kernel I prefer 60Hz and underlocked PLL (works on all my 5 pinephones) so I revert that 500 MHz PLL limit in my kernel and run the panel at specified frequency. I don't see any flicker issues on my devices other than during development/hard poweroffs, etc..
"There were several pinephone HW revisions that fixed HW issues based on direct developer feedback... So communication to get HW changes was possible, and was usually via TL Lim, not via HW devs."
That's great, but that wasn't my experience as an ordinary buyer of the PinePhone who wasn't on the special developers list and had no way to communicate with TL Lim. PINE64 provides no way for an ordinary user to register a bug report about the hardware in the PinePhone.
Since PINE64 didn't provide a way for me to register a bug report about it, I listed those errors on the wiki page. Instead of fixing the schematics, every mention of errors in the schematics was deleted from the wiki by user "Kx" on 2023-12-24. My questions on the PINE64 forum about how to get the schematics fixed were never answered. I don't blame PINE64 for the wiki edits, since I assume "Kx" was just someone in the community who didn't like seeing that there were errors in the schematics. However, the fact that PINE64 doesn't have a public bug tracker for its hardware issues is frankly an indication of problems with the way the company was run in my opinion.
"Accurate statement is that some perhaps critical work stayed out-of-tree, partly by choice and partly due to upstream rejections or dependencies, and not that "the volunteers generally didn't upstream." The claim is overstated to the point of being misleading."
I did some web searches and see that there were more commits to mainline Linux than I thought. I will edit that part. However, there was a marked difference between Purism and PINE64 in this respect.
"The article says PPP "still had major software problems when its sales were cancelled in August 2025.". Yeah, no. Pinephone Pro has almost full kernel support, multiple bootloaders, even graphics/touch support for U-Boot, etc. There are no SW kernel issues that I'm aware off that were not solved years ago."
I don't own a PPP, so I was going off what is listed on the PPP PINE64 wiki, which lists:
Bootloader (critical bugs), Stability (WIP), Suspend (Experimental), Updates (WIP), Phone (WIP), MMS (WIP), LCD (WIP), Rear camera (WIP), front camera (WIP), camera flash (critical issues), Bluetooth (WIP), GNSS (WIP), Sensors (WIP), Keyboard add-on (WIP), Qi Wireless (WIP), LoRa (not implemented), Fingerprint reader (not implemented).
Is the wiki wrong? I held off on buying the PPP for years waiting for those issues to be resolved, and I saw little progress on getting those problems solved since many of the high profile volunteers left in 2022.
"As for the company: Pine64 promissed 10 years of original Pinephone."
"Sooo. what HW support is lacking on Pinephone, Pinephone Pro or PineTab2 or Pinebook Pro, or other consumer products, if you take some downstream maintained kernel and use it? You'll find that very little of consequence is missing."
The PineTab2 wiki says that Bluetooth doesn't work, WiFi can't be reset, so device needs to be power cycled. The camera drivers need to be ported, The Rockchip CSI/ISP driver needs to be extended to handle 2 lanes. Suspend does not currently work reliably, so suspend has been disabled.
"Performance is not really relevant to "level of SW support"."
In the case of the A64 in the PinePhone, its GPU for hardware acceleration is pretty weak, and there is no ISP and aDSP, and the VPU's hardware encoder only includes H.264 video, so I don't think SW support was really holding back the performance of the cameras and the speed of the interface. There are other SoC's where proper SW support is a more relevant issue holding back performance.
Purism chose to upstream their changes to mainline Linux, whereas the volunteers working on the PinePhone's kernel generally didn't.
To:
Purism generally chose to upstream its changes to mainline Linux, whereas the volunteers working on the PinePhone's kernel were less consistent about upstreaming their changes.
I also added a postscript note at the bottom of the article thanking you for pointing out that you had submitted more upstream to mainline Linux than I thought, and linked back to this conversation.
Yes, the feedback that would tend to get addressed was always related to actual HW issues, and the issues listed in your blog article seem to all be failry superficial without any effect in practice. Eg. eMMC and DRAM is a commodity, various phones batches likely got different components based on what was available. I know for sure that my pinephones have different eMMC chips from different vendors that have different real speeds, so got to 78 MiB/s at DDR52 some just to 50-60 MiB/s, etc. DRAM will probably be a similar case just based on the fact that some phones got 2GiB and some 3GiB on the same PCB.
"I don't own a PPP"
Yes, wiki is not uptodate. There are several bootloaders available, from levinboot https://xnux.eu/log/103.html to u-boot with display support and graphical menu, there are small tools like rk2aw that fix the HW issue with charging from discharged battery (bootloaders fix it too to some extent), etc. Suspend is not experimental, never really was. It was working from the beginning, because it was implemented by Rockchip for google RK3399 chromebooks or whatever. LCD works. Cameras work and ISP is fully supported since like 1 year after release, and 0 days after release for ISP. Camera flash works, but should not be used for extended period of time, due to overdriving the LED. Dunno what bluetooth issue would be about, it's part of WiFi chip and supported mainline. GNSS fully works just like on Pinephone, since it's the completely identical thing part of EG25-G modem. Sensors fully work. Keyboard add-on is supported mainline, with out of tree policy manager for managing dual battery power if you like. Qi/LoRa are I know nothing about, and are just back-covers unrelated to PPP in particular. Convergence works well, including HDMI audio. Fingerprint reader was a user backcover project, that got some help from Pine 64 IIRC, and would be an insecure toy anyway. There's basically nothing missing on the kernel/low-level side of things that would be a show-stopper for anything I can imagine doing, except for video encoding acceleration. But that's just a lack of upstream consensus how to even create a kernel api for it. It's not really pinephone pro specific issue. There's no lack of upstreaming attempts for this over the years. There will be no encoder drivers upstream for any stateless encoder HW accelerators, until there will be consensus. Downstream kernel can have encoder in a few days if someone wants it.
Pinetab2 wiki is not accurate either. You'd be better off looking at pages of distros you'd like to use that support the device. Support level is always determined by the distro anyway.
As for GPU acceleration. SW support is absolutely key, especially on older GPUs. If you optimize for those you can have very snappy UI for pretty much any imaginable smartphone functionality with imperceptible latency even on original Pinephone with maybe one exception, and that is web browsers. Those are just so bloated these days it's ridiculous.
Normal distros and Android have extremely bloated architecture, so things get slow and heavily dependent on storage load times. I know for sure that original Pinephone GPU is fully capable moving those few UI pixels typical mobile UI has at 60 FPS with barely any dips even at reduced CPU/GPU/DRAM frequency to save power without any sweat. Things need to be done differently though.
Central support status matrix pages are futile for Pine64 devices. You can have perfect kernel/bootloader support and any chosen distro can still be unusable, because of lacking userspace integration. And there are maaany distros. And some pick and choose kernel patches, and fix/break various things. Some distros also disown bootloader support, so whether something will work or break depends on what bootloader user runs, etc. etc.
There's plenty of outdated info everywhere. Users should just ignore anything status related that's apparently old. And that wiki page was last updated 3 years ago or so.
that't not challenger to Visa/MC at all, it doesn't issue any cards, it is just different name for existing instant wire transfers which you can do also through QR code through whatever banking app you use, nothing to do with some "European Network for Payments (ENP)"
that's like saying I have new solution to wheel, which will be called European circle, it will be the same wheel we already have, but under the new fancy EU name!
I still have a drawer full of OpenMoko. A couple Creative Labs Zii Eggs. Some OpenPandora, and even a hacked up FairPhone, donated to my parts bin, non-working.
I sure wish the Zii Egg had made it out of prototype stages. It showed the most promise - a bare-metal Linux OS, multiple cores, very, very easy to write apps for it - just plain C/C++ really.
Linux phones never happened because the distro's constructed for them were overly complicated, unnecessarily encumbered with 'smart features', and just generally (imho), sabotaged by the cult of collective development. Its the sort of project that requires a BDFL pushing things forward - none of the failed Linux phones ever had that.
These days, I'd rather see someone produce an ESP32 phone with LoRA and maybe SDR, and leave it at that.
But, there is another issue. The modems. It is always the modems. Until someone courageously open sources the modem chip and its firmware, there is no hope.
Yes, as the owner of a Librem 5, I can attest that getting the Qualcomm modem in the BroadMobi BM818 has been one of the pain points, and it is very hard to diagnose the problems.
Funny how this entire comment section is full of people who have never used anything but ios or android. Not sure if it's just all bots, or if even HN is just full of NPCs nowadays.
Glad to see the fanboys are finally agreeing on something though! >_<
Only the userland is some java based abomination... well was a long time ago, maybe after all those years, the android userland has a minimal set of simple binary interfaces and simple file formats, which I could even code reasonably code directly in assembly (this is the benchmark).
Something is wispering to my hears: "nooo! there is no such things as minimal system interfaces and file formats on android linux". Wrong?
If the only parts the user can access are highly qualified, restricted portions of the OS, a/o a non-Unixlike UI, does it really matter that Unix technically underlies Android?
I am not sure but the less power Google has, the better. I am getting tired of those Trump milking machinery leeching off of others - we already see how Trump treats Ukrainians. The ultimate agent Krasnov, just as Yuri predicted in the 1980s already: https://www.youtube.com/watch?v=5It1zarINv0
Now with people decompiling and recompiling apps for different platforms and how fast coding has gotten with AI, spinning up a Linux phone platform is much more achievable now. That wasn't true a year ago.
There are already 100 million HarmonyOS devices in China, so you could say it's now a three-way rivalry. The apps I use every day basically all have native HarmonyOS versions, including even foreign apps like Tesla and Sam's Club.
I've actually been using HarmonyOS for half a year now, and it feels pretty good — the notifications and system smoothness are on par with iOS. The reason I don't use an iPhone is that I need NFC access control, which iOS doesn't support.
Huawei has invested a large amount of manpower to station people in major companies to help develop HarmonyOS. I think they have already broken the vicious cycle of "no users -> no apps -> even fewer users."
Moreover, in the current AI era, it has become easier for Chinese developers to port software to HarmonyOS. For example, Moonlight, the streaming software I often use, has several natively customized and optimized versions available in the HarmonyOS app store.
It’s interesting to see how they got there. https://en.wikipedia.org/wiki/HarmonyOS:
“From 2019 to 2024, versions 1 to 4.3 (4.5 TV) of the operating system were built by integrating the Android Open Source Project (AOSP) with OpenHarmony, allowing it to support both HarmonyOS and Android apps. The current iteration of HarmonyOS became known as HarmonyOS NEXT (later it was renamed HarmonyOS 5 in launched of Pura X). HarmonyOS NEXT was announced on August 4, 2023, and officially launched on October 22, 2024. It also replaced the OpenHarmony multi-kernel system with its own HongMeng Kernel at its core and removed all Android code. Since version 5, HarmonyOS only supports apps in its native "App" format.
HarmonyOS 5.x+ both discards the common Unix-like Linux kernel and replaces the previous multiple-kernel, kernel agnostic system from OpenHarmony with its own bespoke HarmonyOS microkernel as a single framework.”
⇒ this shows it’s possible to create a new stack. It’s not Linux, though, and I think a large reason for this succeeding is that it started in the Chinese market after the US sanctioned Huawei.
> this shows it’s possible to create a new stack. It’s not Linux, though, and I think a large reason for this succeeding is that it started in the Chinese market after the US sanctioned Huawei.
Even so, I think it's helpful in that it weakens the duopoly. If app builders are getting used to building apps for other platforms than Android/iOS, it hopefully also becomes easier for others to gain some foothold.
Especially given the heavy commissions and other developer-hostile behaviour of these two. They've been essentially treating devs like shit and IMO a reckoning has been coming for a while now. Of course, you do have to meet the users where they are, at least up to a point.
Further fragmenting the user base into a third closed ecosystem is good because app builders have to build 3 versions so...now they'll be more willing to build a fourth version?
That logic doesn't follow. This is bad in all meaningful ways for open source.
Or, perhaps, developers would not require you to use an app when a website would perfectly suffice.
...by being even less open than Android. It's not an improvement
And it also has new programming languages ArkTS (Typescript inspired) and now in the process of having Canjie, as their own "Swift".
> HongMeng Kernel
Wait do they mean this Hong Meng?
https://en.wikipedia.org/wiki/Hong_Meng
If so, this is one of the funniest parts of Zhuangzhi.
The Chinese government literally pushed companies to develop app for HarmonyOS [0]. Have fun finding out what happens if you don't.
I can't tell you whether this is a good idea, but I am sure this will never happen outside China, which is supposedly what the question is about.
Also bear in mind that Huawei is likely worth more than a trillion dollars. There aren't many companies at that scale.
[0] https://www.sz.gov.cn/en_szgov/news/latest/content/post_1117...
> The Chinese government literally pushed companies to develop app for HarmonyOS [0].
Like the U.S. government is not pushing and investing its own companies, providing incentives, funding etc. etc. It's what sovereign governments are supposed to do.
> Have fun finding out what happens if you don't.
What is that even supposed to mean? You're going to a camp if you don't have a HarmonyOS app? That is just something that propagandists append to every post about China as if it means something. Get better propaganda, this is old and tired. I can stay random shit like the US is about to livestream an execution by a firing squad too, see?
> Like the U.S. government is not pushing and investing its own companies, providing incentives, funding etc. etc. It's what sovereign governments are supposed to do.
What's your point? My comment is not in contradiction to that.
> That is just something that propagandists append
You can do name calling all day long but that's not meaningful and will get you banned.
I strongly suggest that you reply with content with more substance in it, or just not reply at all.
Microsoft and Intel have been pushed for years and still are in the US.
So? How is that related to this topic which is mobile OS?
> The White House considers anyone that uses the term, “Artificial Intelligence,” as opposed to the highly accepted new and more accurate term, “Super Intelligence,” THE ENEMY! President DONALD J. TRUMP
https://truthsocial.com/@realDonaldTrump/posts/1174061766043...
OP is asking about Linux phones. HarmonyOS doesn't even run Linux kernel at all.
HarmonyOS 5.x+ both discards the common Unix-like Linux kernel and replaces the previous multiple-kernel, kernel agnostic system from OpenHarmony with its own bespoke HarmonyOS microkernel as a single framework.
https://en.wikipedia.org/wiki/HarmonyOS#:~:text=HarmonyOS%20...
So there's already a viable alternative to the duopoly, but it's not necessarily Linux?
Another walled garden is not a viable alternative to the duopoly. Especially from a totalitarian government.
How well do Google Maps and WhatsApp work on the latest versions of HarmonyOS?
I assume it requires some mind of Android compatibility layer that won't pass Play Integrity checks..
Huawei has a Google Mobile Services (GMS) equivalent called HMS, which acts as a compatibility layer and prevents Apps from throwing errors when running on their Android APK-support layer.
However, as I understood, in China HarmonyOS next has no Anroid-emulation layer (which is probably a wise decision if you want to drive domestic app-developers to support your platform...)
If it's distributed primarily in China, I'm not sure either of those matter.
Google Maps in China used to be reportedly unusable, and I'm sure there's local maps that have better data even if Google figured out how to manage the coordinate issues.
WhatsApp is blocked by the great firewall (or at least I haven't heard that that stopped) and has strong domestic competitors.
Does Huawei provide an Android virtual machine with Google frameworks built in? When I was traveling in Japan, I used Google Maps, and for daily use, Chrome and 1Password all worked fine.
In my daily use, only three apps run in the virtual machine: 1Password, Steam, and Chrome. They all run normally, but they're a bit laggy.
I bought a Huawei phone because of the hardware. I'm using the Pura X foldable phone.
The 16:10 screen makes it very convenient for watching videos and reading e-books.
The chip is the Kirin 9020. Although it's only equivalent to Android flagship chips from a few years ago, it doesn't feel laggy in daily use.
More importantly, Huawei products eclipsed Apple in design in 2026
While I prefer Apple's design language partly because it's rooted from Sony and I love how Sony does this since eternity, I strongly support having multiple top-notch designers and builders from different countries.
This is what genuine competition is and drives things forward.
Could you provide some examples? I’m genuinely curious.
watch and airpods, personal experience
Looking at their website, most of their headphones look like knock-offs of Apple/Beats. They have a watch that looks like an Apple Watch knock-off as well.
I can’t give a company credit for good design when it looks like they are ripping off another company’s designs and design language on a regular basis.
That's what the Chinese do with everything. That's why Apple is so secretive about its plans. They day their new offerings arrive in the stores the Chinese makers buy them and start copying the design warts and all.
So far it has worked nicely since you can buy stuff that looks the part but costs a tenth the original's price.
They start getting the plans on how to clone them before they even hit the stores. That's why we saw the Xiaomi 18 Fold launch with the exact same dimensions as the iPhone Duo... before the Duo. Xiaomi got the inside scoop on the parts they were sourcing, and maybe even from the factories prepping. They even named in the "18" assuming, Apple would use the iPhone 18 branding across the whole line up. They can't even make up their own names in China.
As long as Apple is manufacturing phones in China, the only thing they can surprise people with is the software. They really need to push harder on getting some manufacturing back in the US if they want any hope of keeping things a secret and not having knock-offs already on the market before launch day.
lmao weak troll attempt. From the rear, the Huawei Mate 90 Pro Max looks like a a lock on a hotel room door. Google it and see what I mean
I have a Mate 80 RS Ultimate Design and I think it looks beautiful in person, but as you know, Chinese and Western design preferences are very different, just look at their EV's (and how western brands are copying their designs)
Is looks that important to you?
I just looked it and while it looks different, that's not bad. As long as it works, I'm fine with what I have.
Design was important enough to you to post your own comment talking about it and your own preferences, and how important it is to competition, so why are you questioning it's importance to someone else?
Because I see design as a proxy to build quality and ergonomics. I'm not shopping for looks while getting my electronic devices, I'm shopping for quality and longevity of the thing in question.
If it's built well, dependable, ergonomic and delivers on the promise it's written on the box, I'm perfectly happy with what I got.
Yes, I have my tastes, like everybody else, but I don't satisfy my taste first and try to fill the specs to that taste. On the contrary, I start with the features and quality level I want, and go from there.
> Because I see design as a proxy to build quality and ergonomics
It isn't a good proxy. Couple examples: Apple sold laptops with wonky keyboards for years and still sells a mouse that charges from the bottom when the battery dies.
While I never owned these Macs with butterfly keyboards, I have used them, and yes. Apple botched bad on that keyboard. They made it right later, though.
While I also understand that Apple Magic Mouse looks atrocious with that port on the bottom, just charging it for two minutes gives you 8 hours of runtime. Why can’t people plug it in while going to get a coffee and unplug and finish the day with that quick charge? Then you can leave it charging for the night.
If you really want some bad examples, look at some popular cars. Many of them don’t care about your finger, and happily chop it off if you put it the wrong place at the wrong time.
> Design was important enough to you to post your own comment talking about it and your own preferences, and how important it is to competition, so why are you questioning it's importance to someone else?
I think you might be conflating design and cosmetics.
Design is objective, cosmetics is subjective. I like good design even if I don't care much for cosmetics.
Read "The Design of Everyday Things" , Donald E. Norman. This book is routinely recommended here, with good reason.
Did you read the comment I was replying to? The commenter claimed Huawei had the lead in design. I begged to differ. I'd accept the design of the 90 Pro Max on a $300 phone, but a $2,000 phone? lol
That's your personal opinion on a piece of hardware. If that's so important for you, you can look to other alternatives.
...and in my comment, I kindly disagreed with you. I have used many things with great enjoyment which were called ugly by many people.
It's OK and natural to have different opinions and priorities, and hardware design is not a first priority as long as it's uncomfortable on my checklist.
As a side note, apparently, you can add an extra camera module with a 1" sensor to that "lock" you seem to dislike. Considering the best camera is the one you have, having an additional camera with better sensor for people who are inclined to dabble into photography is a great thing.
...and I'm contemplating on how can I take my mirrorless with me during flights in a compact way even if I have an iPhone.
I don't know what you mean, looks more like camera lens from front
sounds like heresy up in here california echo chamber
There's also https://en.wikipedia.org/wiki/KaiOS that developed from FirefoxOS and powers something like 100 million feature phones in the developing world.
Have they support copy paste between apps? Since WhatsApp abandoned the platform I figured it is in life support. Almost no one use SMS in developing worlds, it's WhatsApp all the way.
Oh, I didn't know WhatsApp had dropped it. You're right, that's probably end of the line for it, but maybe the OS will be resurrected in some new form.
HarmonyOS (especially meaning Huawei phones) is pretty much dead outside China, that's like saying WeChat is relevant messaging app outside China
if you can't run all your favorite bank apps in your phone any phone is dead nowadays, no matter whether it is Linux or HarmonyOS
and seems EU is fine with keeping Apple/Google duopoly in app verification, so although you can use European bank and pay with QR codes without MC/Visa, you still need US company verifying your phone so you can use European bank app, sad state of current things
> if you can't run all your favorite bank apps in your phone any phone is dead nowadays
I guess I've been running dead phones for ::checks notes:: a quarter century now? I actually don't even know if my primary banking institution (a regional credit union) has an app to begin with. It's never occurred to me to need it.
You don't represent 99% of users.
I like the confidence with which you through around "99%" when there is ample research suggesting that the percentage of smart phone users (at least in the US) who use their phone for banking is much closer to half.
I'm not offended at the idea that someone might want to bank from their phone, just, a lot of us don't have that need. Having my ability to run the software I want on my phone taken away, just to support corporations insisting that they be able to control my device for a function I don't need, however, is offensive.
"banking apps" is just simplification for apps requiring GMS or Google verification, (this whole thread is about HarmonyOS and Huawei devices which are not supporting GMS) you can ask Android users in Europe if they would be willing to buy/use phone without GMS and explain to them what does it mean and I can guarantee you percentage unwilling to buy phone without GMS will be much closer to 99% than 50% you claim
btw. ~60% users in Czechia pay with phone already (though like 95% with bank card at same time), I am not one of them, but I won't deny the reality
Reddit is that way ->
wechat is a pretty good app
gojek too
singapore also has some pretty great ideas
go travel a bit, there's an entire world out there that isn't waiting around
when i go to the mall here, i counted 6 korean copycat shops lol
asia is living a completely different lifestyle than us, and its popular even with us, especially with women, and its actually good, and we're still here saying asian shit is irrelevant
I've lived in various Asian countries for the last 10 years, but I've never seen Wechat used except for communication and payments with people from mainland China.
Same with Gojek. They tried launching in other countries, but it never caught on outside of Indonesia, where yes it's huge and awesome.
Grab, on the other hand, has been very successful internationally.
The reality is that The Western Civilization, or however you frame and name your own personal lifestyle, is not as huge and dominant as it might seem to you. Every countries have own sets of apps and webs. __1984 is a work of fiction__; there is no united Oceania, Eurasia or Eastasia in real life.
> wechat is a pretty good app
And millions of Chinese bash it everyday. Shit storage efficiency, stagnated UX experience, very closed ecosystem and external link blocking, I could go on.
always one of the fattest apps on my phone
hey apple, when are we getting expanded memory, maybe better battery? oh we're still stuck under 4000mAh, cool cool cool
that's how you know it's good. bad apps have rather smaller daily user-bashing numbers
Not if it is shoveled down to your throat.
> go travel a bit, there's an entire world out there that isn't waiting around
> asia is living a completely different lifestyle than us, and its popular even with us, especially with women, and its actually good, and we're still here saying asian shit is irrelevant
I lived in China 5+ years and spent plenty of time in other Asian countries travelling, so how to say it politely - stop talking about "us" and preaching me about lifestyle in Asia if you are completely clueless.
WeChat is shit app pushed down the Chinese throats (I remember when QQ was still the king), because it doesn't have competition in China and you can't really exist in China without it, closed sourced with no E2E encryption for starters, there is reason why pretty much nobody outside China/Chinese community uses this actively spying app.
So yes, if by Asian shit, you mean HarmonyOS and WeChat, then yes, Asian shit is irrelevant, because pretty much nobody outside Asia uses it for good reasons (HarmonyOS because it is unusable if you wanna use normal banking apps and most of the other apps relying on GMS besides those very very few ported apps or using some virtual machine workarounds, personally I don't need banking apps and used smartphones without gapps for the last 10 years, but I am realist realizing I may be among like <0.5% Android users in Europe, completely irelevant negligible number).
My phone can't run any of my bank's apps, is it dead too?
I appreciate your intended point was probably more specific, perhaps 'will not be a mass market success in the west', but there is a great diversity of people in the world and many of them have different requirements of a phone
for 99.5% potential buyers yes, it is, if it can't run bank apps (or other apps requiring GMS), personally I don't use banking apps on phone but I realize I am extreme negligible minority, which is why I said "pretty much dead", that "pretty much" covers that <0.5% users
we're quickly getting into "we're sorry, you can't access the site unless you verify with android/iphone" so yes, that would be essentially dead
Isn't HarmoniousOS just a blatant Android OS clone, with serial numbers and licenses filed off? I remember ArsTechnica reported on that waaaay back when it was released.
HarmonyOS NEXT released 2024 is a fully original kernel, the first version was off label android
Except that HarmonyOS is not Linux based or on Android [0]
In fact, it is a competitor against both iOS, Android and Linux-based devices.
[0] https://en.wikipedia.org/wiki/HarmonyOS
It would have to be somewhat more global than only in China though. After all Google's spyphones also operates globally, more or less, even if Google is a ruthless US tool for abuse of other markets. IMO we need to get rid of all companies though. That's not realistic, but it really should happen. I just do not trust any of these private entities anymore; verifiable open source and open hardware at all times should become the new standard. Is anyone really using Win11? Ever since the recall-spy feature I knew I could not commit to it; whether I can disable it or not is not a useful distinction since there is no more trust in that private blob, now supported via AI slop.
No, they won't become a viable alternative:
- Worse compatibility with the millions of Android apps already out there.
- Hardware vendors (outside Apple) all target Android.
- The usability of Android/iOS is far better than non-Android Linux phones.
- The security of non-Android Linux phones is in a bad state (e.g. lacking proper app sandboxing). Heck, even the Android emulation layers that some of these phones have, throw the strong Android sandbox model out of the window.
The answer is very obvious and it is AOSP. Even though Google is trying to close AOSP more (e.g. by not pushing source continuously to the AOSP Git repos and keeping QPR1/3 for themselves), it is still an open source system. Play Services can either be run sandboxed or emulated with microG. AOSP allows alternative systems to hit the ground running, you get great app compatibility, a tested security model, great usability, and support from hardware vendors, including vendors that are alternative friendly (used to be Pixel, now Motorola, Fairphone, etc.). If ever needed, AOSP could be forked and it would still be leagues ahead of non-Android Linux phones.
All the downsides that apply to AOSP-based systems (like things getting blocked by Play Integrity, unlockable bootloaders) also apply to non-Android Linux systems.
The lack of polish is a function of the inability to use the hardware. The hardware is tightly gatekept so competition _cannot_ exist. Regulators are the only ones who can force vendors to distribute documentation for and unlock their hardware.
Once we can actually target the hardware, open source alternatives will be much better than first party options.
You can already see the potential in the open source world.
Linux has Waydroid so Android apps can be run on Linux at full speed without emulation. That means, if you had a Linux phone, you have the entire Android library - the only thing lacking is the launcher. How hard is a launcher to program? It's just Steam's big picture mode.
Other examples of the nice things we can't have; FEX lets you run Steam games on phone hardware. Open source drivers can unlock displayport over USBC. Instantly your phone becomes a thin client / laptop replacement that can play PC games (poorly, but 1080p games are possible).
We are _not allowed_ to do these things. I love OS development and, if I was allowed, I'd make iOS look like janky trash.
So, where are the super-polished Linux systems for the Fairphone? I know they use proprietary firmware blobs and that the hardware support is Android-oriented. But they publish device trees, driver sources, and firmware. Most AOSP-based projects support Fairphone, as well as PostmarketOS and ubports.
The problem is not only hardware support, the problem is also that the stack on top of it is very immature compared to AOSP and not something you could give to a daily phone user.
It’s funny that you mention Waydroid. It throws most of Android’s strong security model out of the window.
> So, where are the super-polished Linux systems for the Fairphone?
It still has tiny market reach. Very few people are going to invest the time needed to build a quality user experience for like 1000 users.
Just imagine what would happen if Linux could be installed on the iPhone. There would be SteamOS distributions within an hour of the announcement.
> It’s funny that you mention Waydroid. It throws most of Android’s strong security model out of the window.
Haha yea, it's more an example of capabilities that could be rolled into highly polished user experiences. Again, if Linux could be installed on the iPhone - I'm certain Waydroid maintainers would shut the project down from PRs.
~~* competition *~~
> It still has tiny market reach. Very few people are going to invest the time needed to build a quality user experience for like 1000 users.
That doesn't make sense. Whenever someone wants to build something, they start with 0 users. They don't say "huh, I have 0 users, I'm not going to build a good product".
People who build things recognize that they won't get more users if they don't make their product better. If you have 1,000 users and you want 1,000,000 users, you work more, not less.
Potential addressable market matters a lot
It still has tiny market reach.
You are moving the goalposts, you said:
The lack of polish is a function of the inability to use the hardware. The hardware is tightly gatekept so competition _cannot_ exist. [...] Once we can actually target the hardware, open source alternatives will be much better than first party options.
So, it's not the hardware gatekeeping that is the issue, it's that nobody is polishing the experience for hardware that already exists and qualifies. The hardware can also be purchased very easily in some regions (e.g. Europe). I can literally hop on a bike right now and pick up a Fairphone in ten minutes. I know that it's different in e.g. the US, but Murena has been selling them in the US for years now.
I think you may be glossing over a bit how annoying / messy / complicated it can be to work with the binary blobs and their quirks, especially when dealing with complex things like camera(s) and the image processing stack. Doubly so for community developers who may have limited or no access to documentation and resources that the device manufacturers get from the more low-level hardware vendors.
If Fairphone wanted, I'm relatively sure that they could form a cooperation with Jolla, Librem, KDE or other entities in the space and get Plasma Mobile, Sailfish or whatever working on their phones and/or design the next-gen Fairphone with hardware that has as few quirks as possible and is as "easy" to get to work with Linux as possible. I'm also relatively sure that so far, that would not have made economic sense for them. However, there seems to be a bit of a surge in people wanting alternatives. The recent Jolla phone has way more orders and pre-orders than were anticipated, for example. And SailfishOS is certainly "polished" enough that the circle of people who can use it well (or at least live with it) has expanded beyond the developer / hacker / activist crowd.
> dealing with complex things like camera(s) and the image processing stack
It would be wonderful if we could create an abstraction layer on top, so all the trillions of phones already existing that simply can't open source their drivers due to licensing and whatnot could be usable.
We could call it HAL for hardware abstraction layer. https://source.android.com/docs/core/architecture/hal
Or we could call it libcamera, https://puri.sm/posts/cameras-its-complicated/
> It throws most of Android’s strong security model out of the window.
If what you care about is protecting device and application providers' interests from their users, then I guess it does.
> If what you care about is protecting device and application providers' interests from their users, then I guess it does.
That clearly isn't what they care about, or intended with their comment. Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize.
who exactly owns a fairphone?
Now, if we had support for say, a pixel, that would probably change things. Incidentally, there seems to be initial support for the tensor G5 (pixel 10 onwards)
How many years did it take to make a well-polished DE on desktop Linux? How large was the community doing that and how many devices did they have access to?
About 5 years, Mandrake and SuSE with KDE around 1996 were already quite good.
Since then the problem has always been the same, rebooting the DE experience for the sake of it, desktop environment wars, rebooting the development stack from GNOME and KDE, and the problem that despite all OEMs have Linux running on their data centers, the community has to reverse engineer the hardware from the same OEMs.
Yeah, I think people are underestimating how good and competitive the Linux desktop was in the past. Around ~2000 there was a lot of excitement around the Linux desktop, the Linux desktop was pretty mature, especially compared to the tire fire that Windows 9x was at the time (that changed when the NT branch moved to the consumer with XP). There were very user-friendly installers like Caldera OpenLinux (best feature was that you could play Tetris during the install) and Corel Linux. Also a lot of large vendors were making Linux desktop apps, e.g. Corel Wordperfect and Borland Kylix (which was Delphi for Linux). Heck, even Microsoft Office ran almost perfectly with CrossOver.
But yeah, then there was the constant forking, preferring rebooting development over iterative improvement (e.g. GNOME 2 -> 3 was really a hard cut for a lot of people, resulting in forks that exist till this day), hostility towards closed-source applications (you can hate them as much as you want, but people are not abandoning Photoshop/Illustrator for GIMP/Inkscape on a whim), etc.
Hopefully something changes with all the government-driven sovereignty desktops that are popping up, the resulting influx of money, and KDE EV et al. becoming very mature organizations.
By such measure, GNU/Linux phones are already quite good. I use Librem 5 with Phosh as a daily driver, and it is really just fine. Except the battery life, app compatibility and smoothness of the UI.
"It's fine, except for all the stuff that matters."
These are basically the same problems that Linux desktop had around 2000, aren't they? People still used it and it was fine.
The difference is that there is already a great open source smartphone OS that works today, it’s AOSP.
The most effective path would be for the FLOSS ecosystem to pour their resources into making AOSP independent from Google. But instead people will just fork N half- or non-working solutions for reasons.
>OS that works today, it’s AOSP.
But you have no guarantee what happens tomorrow with it, depending on what Google feels like. You just have to eat whatever Google decides.
With Linux there's no such centralized control. So the time and effort will pay out later on down the road. Let Google have its AOSP.
This comes up every time, I just don't understand the argument. You can fork AOSP when that happens. It will still be far less work than bootstrapping a viable open source alternative from scratch. Also maintaining a forked AOSP would be less work than getting the Linux desktop stack on the same level as AOSP.
Given that Android apps target old API levels, it would also stay compatible for years and nothing would hold you from implementing APIs from the docs.
To be honest, I don't think AOSP will fully close up, since Google probably fears the regulatory pressure and the fallout from vendors. The larger risk is Play Integrity, but that applies equally to other Linux systems if you want to tap into the large Android app ecosystem. But the solution for that is not technical, the EU and other regulatory bodies should make forbid it in its current form due to anti-competitiveness.
> This comes up every time, I just don't understand the argument. You can fork AOSP when that happens
Hacking on the Linux stack is several orders of magnitude more practical than AOSP though. AOSP's build system is massively unwieldy for individual contributors to work on. You can't easily work on any of the system components without dedicating >100 GiB of storage for a build, for example. Everything is scattered across hundreds of repositories tied together with a bespoke repository management tool.
This all works for a company equipped with entire build infrastructure teams, not for a grassroots project trying to keep up maintenance with (at best) limited funding. It's why Nura (fka postmarketOS) is a thing whereas the various AOSP forks barely ever modify the core experience.
It's a whole operating system complete with accessibility, hardware abstraction, a bunch of core apps etc. I think it's a false equivalence that you can hack on a replacement system without similar "investmen"
In any case, were google turn malicious, it wouldn't only be in the interest of individuals to maintain a fork, plenty of companies are invested in the health of the platform that will help out.
Maintaining a fork of AOSP is hardly viable for the FLOSS community. We already have Linux; adjusting it to phones is much easier.
Android's market share is far larger than even Windows'. It's not just in the interest of a small community, there is plenty of financial interest as well to keep it healthy.
Also, it's a false equivalence - it's also easier to buy a walkie talkie, but that's also not replacing Android smartphones. "Gnu/Linux" userspace is simply not even close.
Like what can google do with it?
At worst you take the last available version that is half a years old and do a hard fork and start worrying about the issue then.
> Like what can google do with it?
Define standards beneficial to them like hardware attestation, passkeys. Like they do with Chrome and Manifest-v3.
> do a hard fork
https://news.ycombinator.com/item?id=50061384
>> do a hard fork
> https://news.ycombinator.com/item?id=50061384
How does citing your own prior comment, one which itself offered no justification for its claim, add value of any kind to your response?
"I am become, Source? I Made It Up, destroyer of discourse."
There is the pinephone, have fun writing software for that thing.
But it's a pretty fruitless job when there is an open source OS built on the same good kernel, but actually had hundreds of thousands of dev time spent on it to make it the most popular OS out there.
Especially that it can run basically everything, see: https://github.com/Droid-Deck/DroidDeck for an example of what you want
One could do just like everyone else and buy the specs from OEMs, instead of trying to reverse engineer.
Yes it won't be pure religious FOSS with 100% open, so what.
Also this is the future for laptops as well, for those that keep repeating the mantra of ARM/RISC-V replacing x86/x64 architectures.
Do you get that on the Apple App Store?
No, and why should I?
Apple doesn't sell Linux powered devices, nor do I want that from them.
> nor do I want that from them.
This perspective I can't wrap my head around. Like I get that you wouldn't use it, and that's fine - but if Linux was available and we made it incredible, that would push Apple (and Google) to do better. So you'd get a better MacOS / iOS by proxy.
Like, don't we want competition? What motivates people to desire an unchallenged status quo?
Those that want to sell Linux powered phones should make their own stores, and folks like yourself should support them, when they do open such stores.
I have a genuine, but maybe stupid/trivial sounding question. Does anyone successfully run cloud instances of Waydroid so that their physical phone is a dumb client?
I've been thinking about it for a long time, but it seems like such a privacy risk even when self-hosted. The massive upside is that the phone is just a VM. The idea makes the entire phone debate irrelevant since you can access your "phone" from any other computer that has internet access. If the connection is lost, the local device can always sync later or at least provide basic call/text functionality.
What's the viability of regulators requiring such documentation out of vendors? Feel free to extend the scope out to up to 5 years if it does not look viable right now.
Introducing initiatives that encourage competition is bad for business so I empathise with megacorporations for not doing it without regulation. The annoying part is they are also the largest lobby groups, so it's unlikely the US will be the leader of change here.
If I would draft policy that could make it I'd suggest;
- Scoped to companies above a "number of units sold globally" threshold.
- Documentation must be supplied 3, maybe 5 years after hardware release (similar to "generic drugs").
This means small hardware startups are not burdened by the overhead in creating docs, and megacorps retain the ability to extract profit during the period of maximum profitability for the product. The eventual expiry would encourage companies to innovate (I think malicious compliance is unlikely).
With the recent push to decouple dependance on US technology companies, I see this as possible (though still unlikely) in the EU, perhaps Canada.
> The lack of polish is a function of the inability to use the hardware
Must be why Desktop Linux has great usability right? Oh wait
Haha, shots fired.
It's better than Windows 11 at least - though we probably can't credit that to improvements to the Linux DE
I am often finding things I prefer about one of the OSs (or Desktop Environments in the case of Linux) that the others don't have. I can usually see how people prefer any particular one over the other.
The usual suspects are the keyboard support in Windows (enabling the extended keyboard navigation in MacOS made some apps act very strangely), and most of the look and feel of MacOS. There have even been things I really liked in ChromeOS.
Obviously there are many nice touches in the big Linux DEs, and I would rather be in KDE Plasma than anywhere else. Because of this, I'm generally not surprised when I encounter something that is done better than Windows or MacOS.
However...!
Yesterday I was editing filenames in the file browser, and accidentally navigated down to the next file in the folder - still in filename editing mode! It was a feature I didn't even know I wanted. Suddenly, I could edit a whole list of files, just as if it were rows in a text file. Now it's Monday, and I'm back in Windows. I am unlikely to need to use that feature, but still wish I didn't know what I was missing.
> Yesterday I was editing filenames in the file browser, and accidentally navigated down to the next file in the folder - still in filename editing mode! It was a feature I didn't even know I wanted. Suddenly, I could edit a whole list of files, just as if it were rows in a text file. Now it's Monday, and I'm back in Windows. I am unlikely to need to use that feature, but still wish I didn't know what I was missing.
In case you do ever need it - you can do this in Windows with the tab key.
That is quite nice! I don't think I ever knew that. It doesn't feel quite as nice as using the down arrow in a list/details view, but it's plenty good enough.
Anyone have the equivalent for MacOS? :) I don't have any MacOS devices handy.
This tells me you haven't tried it in the past 20 years
it really does though
> Play Services can either be run sandboxed or emulated with microG.
Play Services is absolutely not needed for a usable Android experience. I am running GrapheneOS without any Google crap and you could not pay me to do so.
Many bank apps, and apps to interact with official state services, usually depend on Play Services. Sometimes it is all banks in one's country, so no, one can't just "switch to another bank" as US Americans on HN often assume.
Can't speak for all countries ofc, but the happy path isn't just the US. I've heard positive reports in Europe where banking apps work without Play services more often than not, and if it doesn't some banks will actually change implemented policy once a customer complains.
İ think this is the case in a small number of European countries and really it should change. İn two asian countries İ do business in, and one middle eastern one, the bank apps now provide a third harmonyOS alternative. The American banks I've used don't require an app, and HK banks will provide a digital token generator which is actually my preferred way. İ think that if it's the case you are tied to one foreign third party company to do banking it should be really something you protest about strongly and change it.
You can always just have a burner android phone in a drawer somewhere and operate it via remote desktop from a device you actually control
Many bank apps disable such remote access features in the name of security.
So switch the bank. Worked for me.
I know replying to these threads is your idée fixe, but you should at least read them fully before replying.
I was saying this just to be ahead of all the comments that usually come up with "yeah, but Google has increasingly put new APIs in Play Services, so AOSP is worthless".
It works for you, but I doubt your experience and needs are typical of a normal smartphone user.
I also run LineageOS with no Play Services (and have for years), but it is missing some pretty noteworthy stuff: Google Maps, Google Pay, etc.
OsmAnd and a credit card are basically perfect substitutes for Google Maps and Google Pay.
> Google Maps, Google Pay
That's not the Android experience, that's the Google experience.
I used to do this, but an increasing number of apps fail to work without play services. Luckily Google still lets you create accounts on android phones, so you can create a fresh account with a random name for every phone, and take care you don't give it access to something identifiable.
> and take care you don't give it access to something identifiable.
Like IP address and location?
I know it is entirely possible for Google to uniquely identify me for each account, but I choose to believe they don't go out of their way to use EVERY possible information about you to track you and only use things that you "accept" via their EULAs, like syncing contacts or logging in to the same service with both accounts, etc.
I would love to use GrapheneOS but Google Pay is a requirement for me. Platform is a moat, and I think the above comments about Harmony solidify that if your country has the will to create a home grown platform, it can happen. I don't think any other country would be able to make that work (maybe AI changes things dunno)
>The answer is very obvious and it is AOSP
I disagree. Working on AOSP with Google having so much control of it is just a waste of time. You have no guarantees what you are working for, in the future.
I'd go full Linux, the effort is worth it and will pay out in the future. Google has the AOSP project by the balls and it's a very high risk investing anything into it, as a developer.
With today's LLM tech might as well do something nice with Linux.
So fork AOSP today. You actually have a working stack, working systems (Lineage, GrapheneOS, /e/OS), and it's far less work than bringing mobile Linux up to the level of AOSP.
But no, let's reinvent the wheel and start the complete ecosystem from scratch. Of course, looking at the history of Linux, this is not surprising at all. Even something immature as mobile Linux already has multiple projects + stacks (Sailfish, ubports, Plasma Mobile, PureOS, etc.) trying to achieve the same. I say this as a long time Linux user (since 1994), the Linux desktop community manages to shoot itself in the foot over and over again.
I don't think you understand the reason people want mobile linux. I want to be able to run arbitrary binaries and get access to graphics primitives on my phone, AOSP does none of this. I honestly don't even get the point of AOSP, the way you don't for mobile linux.
You can absolutely run arbitrary binaries. The binary format for Android is an APK, but if you really meant a random arm binary you can run that as well just fine, android even natively has a terminal now.
And what do you mean "graphics primitives"? You have an abstraction layer, the same as you do on Linux. Like you ain't writing directly against a particular video card either , unless you write a kernel driver.
An APK is an installer, not a binary. You have to be an "app" to do anything in Android. Which includes writing to the framebuffer. I don't know enough about Android so I'd love to be proven wrong. Give me an `xclock` equivalent that I can just run.
A png image is a binary. A zip file, which apks are are just binaries.
If you mean executable formats, they're their own different things, it's just machine code wrapped OS-specially. I don't see how they are fundamentally different "from an app" - you also have a bunch of metadata in there and an entry point. Just because it's an XML file in Android's case which can just as well jump to machine code (you can have Android apps written in CPP/Rust whatnot), it's all just an implementation detail.
Well, do you mean xclock to draw over different windows/activities? Because that's just a different similarly to how Wayland is different from X -- it's generally frowned upon to not have a central entity manage who can draw where.
Otherwise, you can trivially do whatever you want, including drawing manually similarly to X's API, or using OpenGL or similar hardware accelerated apis.
I want to be able to run arbitrary binaries and get access to graphics primitives on my phone, AOSP does none of this.
People use a phone for their most private information, including banking credentials, credit card credentials, car keys, etc. The banks, etc. are never going to permit running their apps on devices that can run arbitrary binaries. Most are already blocking rooted Android devices and Android devices with an unlocked bootloader. The fact that this is still possible on desktops (though not everywhere anymore, e.g. my bank requires you to use a phone app for authentication) is for historical reasons.
Also, you are an extremely small niche. If you are sufficiently motivated, you can live like that (run Linux phones, work around banks, etc.), but this will never be mainstream and this was implied in the question of the post (Will Linux phones become a viable alternative to the Android/iOS duopoly?).
If there will be a viable alternative to the Android/iOS duopoly, it will look a lot like Android/iOS. The best chance is an AOSP-based system like GrapheneOS.
You can still run traditional Linux desktop apps in a VM on such phones.
>but this will never be mainstream and this was implied in the question of the post (Will Linux phones become a viable alternative to the Android/iOS duopoly?)
The post goes into detail about the reason for the current duopoly is the difficulty in procuring modern SOCs with linux support, nothing to do with how said phones will be used.
And I don't really care about being able to bank on my phone, I would gladly buy a cheap android device for it if they stop you from being able to bank on desktop devices, I just need linux on phones because of how much android sucks for daily use and how annoying it is to do anything on it. If we do get the ability to run android on modern hardware, it stops being necessary to have a separate desktop/laptop as well, I could just use a dock, or just a keyboard and mouse instead, especially since the Macbook Neo has shown current mobile hardware is more than enough for "casual" desktop use.
> The fact that this is still possible on desktops (though not everywhere anymore, e.g. my bank requires you to use a phone app for authentication) is for historical reasons.
And you think that this is fine? I will fight for my rights for one.
AOSP is effectively just a linux distro and can be forked just like desktop linux distros
> Worse compatibility with the millions of Android apps already out there.
Most of the apps on Android and iOS aren't necessarily useful.
Actually, with the recent advances in LLMs - they could. If people start to reverse their phones and upstream to Linux, we would not need the hardware vendors to support their own hardware even.
Do any Linux phones or even GrapheneOS phones have a secure enclave/TEE?
GrapheneOS requires it.
> StrongBox keystore provided by secure element
https://grapheneos.org/faq#future-devices
Librem 5 has a smart card reader.
Apps may just well go away with llms and agents.
only if tokens are 100% free 1000tps prefill and generation
> If ever needed, AOSP could be forked and it would still be leagues ahead of non-Android Linux phones.
I agree and thus donate to independent AOSP development (such as GrapheneOS).
It would probably be a great idea to replace many android components with components from the linux userspace ecosystem so that more code sharing between desktop linux distros and this is possible
I have been using the Librem 5 as my daily phone since 1 May 2022 (https://janvlug.org/blog/one-week-librem-5-field-trial-day-1...). And the Librem 5 is getting better and better, and its PureOS Linux operating system is actively maintained, and patches are still upstreamed (https://puri.sm/posts/tag/pureos/).
I really enjoy having a phone that gives me full root control, and that is very similar to the Fedora (GNOME) distribution that I have on my desktop and laptop.
Buying a Linux phone from a pure Linux hardware vendor like Purism helps sustaining the mobile Linux ecosystem.
Yes, the Librem 5 is a bit older phone with some rough edges, but for me it is a really good phone. It gives freedom in the free software sense, and consistency with my Linux computers. I gladly accept some minor inconvenience to have a phone that respects my freedom and privacy.
I cannot foresee the future, but for me the experience on a Linux phone that I control is far more superior than any phone that spies on me and takes away my freedom, like Android or iOS, basically any phone from any manufacturer that disrespects me.
I don't see what I couldn't do on a pixel phone with graphene. It would just have much better performance and battery life (given equivalent hardware, let alone the actual hardware differences).
Like I have tailscale, I ssh into my devices, I can write my own apps, sideload whatever I want. It even has a full Wayland graphical environment where I can play a video inside desktop chrome if I wanted to.
I am the administrator of the system on my phone. It's the same OS as what I've been using on my PCs for decades, so it's very familiar. It's fully scriptable in whatever language I wish to use, so I can easily adjust its behavior. I can use sandboxes when I need them and ignore them when I don't. Its software components are replaceable and patchable - if something bothers me, I can write a patch, compile a patched package, install it and even send a merge request upstream right on the phone itself without using any other device - regardless of whether it's about desktop environment behavior, cellular middleware or a kernel driver. I can freely modify the system to my liking without being punished for it. I never have to wrestle with the system whenever I want to keep something running in the background.
It just feels like my little personal computer. No Android device ever felt this way to me. I don't want to feel like a guest confined to a sandbox within a computing device I'm supposed to own.
If you have selinux then you may not be "absolute God either", and arguably it's never necessary to have that much control. I would much prefer to have sane security boundaries so something blowing up won't bring everything down with it.
And there are quite a few devices with unlockable bootloaders so you can feel to hack whatever you want with AOSPs.
I had to build a patched Android image in the past, so no thanks, it's definitely not something I would want to do in my spare time just to tinker. It's a system that's designed to be user-hostile; you can fight it if you want, but why would I do that if I can just keep using GNU/Linux instead?
Is it user hostile, or more complex as in a car is also more complex than a bicycle for obvious benefits?
It is more complex, but mostly for reasons that serve someone else than me.
Unless regulators enforce (at the very least) that hardware documentation sufficient to produce open source firmware/drivers must be supplied with that hardware, no - probably not.
Drivers and firmware are the biggest hurdle outside of locked bootloaders for competition in the operating system space.
Examples; Anything Apple (MacBook, iPhone), anything Samsung, anything Google, the list goes on.
There _is_ open hardware, but it has poor performance / battery / build quality and the vast majority of users will not accept that.
IMO "the right to repair software" is essential and this duopoly is a function of explicit monopolistic practices.
Maybe LLMs can help open the "reverse engineering" Pandora's box - but we have yet to see that realised - at least for drivers / firmware
I'd consider that solved with LLMs (the capability is already there and will only improve). The only remaining hurdle I'd say is hardware attestation.
I hope so. We haven't yet seen LLM-led reverse engineered firmware, but here's hoping!
so that's basically we don't know how to make the good hardware, let's force those who know give it to us.
That's one way to look at it. I applaud Apple and co for what they have created, but even drugs have patent expiries, eventually becoming generics.
I'd be fine with that model - let them make money for 5 years recouping their R&D costs, then they must offer documentation so the community can repair / maintain the hardware themselves.
I personally see it as falling under "the right to repair" and selfishly, I know we can do more with the hardware than they are demonstrating. It's endlessly frustrating that we are not allowed to and then the devices just disappear forever.
>I applaud Apple and co for what they have created, but even drugs have patent expiries, eventually becoming generics.
In the US, all patents have 20 year terms (from initial patent filing). Of course, patents don’t tell you how to make something, so it’s not sufficient for something like smartphones or medicine.
Patents that don't tell you how to make something should not be enforceable, this kind of knowledge transfer is the whole premise of patent protections.
I'm always surprised when I read articles about Linux phones that don't mention VoLTE support. Without it, phone calls will drop constantly as we tear down old cell infrastructure. In my experience I've only been able to find one phone that supports VoLTE in America. I get the impression that there's much more interest in Linux phones in Europe where VoLTE (or whatever it is over there) support seems much easier to achieve.
The Furi guys put an insane amount of work into getting their phone working on every network in America. They have a Telegram channel where you can talk with the developers themselves. They will SSH into YOUR phone and poke around if they can't figure out what's going on on their end. These people work like crazy to make the experience seamless.
Phone specs, UI, security support, etc are important but if I can't make calls on the thing I'll never even consider it.
I'm pretty sure both Librem 5 and PinePhone can use VoLTE in the US. The former you can even buy together with a MVNO service that's just guaranteed to work.
I forgot about the Librem. I originally used the PinePhone 5 years ago and had to switch to a OP6 because the PinePhone was unbearably slow. It looks like Mobian and PostmarketOS both support VoLTE on the PinePhone now which is good.
BTW, isn't VoLTE on devices like OP6 pretty much a solved thing by now as well? These devices with no discrete modem had to configure all the IMS services manually over undocumented QMI interfaces (as opposed to a documented AT command than then makes the discrete modem do the same thing internally), but I believe that has been figured out some time ago already.
When I ran the OP6 5 years ago on PostmarketOS it wasn't working. I had a PR open with the devs and we tried to figure it out but lost steam. It looks like someone on Reddit got it working two years ago:
https://www.reddit.com/r/linux/comments/1e05mlr
So yeah, 5 years ago it wasn't so critical to have it yet, and by the time it became critical it also became supported. Perhaps that's why you keep reading articles that don't mention it :)
Agreed. I assume aftermarket Linux support for Android devices with out-of-the-box unlockable bootloaders (including the OP6/6T) is the most likely path to viable daily-driver "Linux phones" in the future, and it's strange how the linked article doesn't seem to mention this at all.
Yes, I probably should have addressed that in my article, but my primary focus was on whether Linux phones can grow from being a miniscule niche for nerds like me to being a real alternative for normal people to Android and iOS phones. I would guesstimate that around 10,000 Linux phones were sold in 2025, which represented 0.0008% of the global smartphone market that year. The question I was asking is whether we can get to 0.1% or even 1% of the market. Rereading the article, I see that I wasn't very good about explaining the focus of the article. There was so much technical stuff to cover, and I got a little lost in all that.
If you look through the list of recommended devices for Nura (formerly postmarketOS), the only one that has full software support for all the hardware is the Librem 5, and the second best supported phone is the PinePhone.
The rest of the phones are dated Android devices which all have significant functions that don't work correctly. The processor with the best support is the Snapdragon 845 from 2018 in the OnePlus 6/6T, POCO F1 and SHIFT6mq, and all of those devices have issues that a geek like me can accept (like downloading code from github and manually compiling to get a partially functional camera), but it isn’t really an option for ordinary people.
I think that it is very important that there are native Linux phone manufacturers, totally independent on Google, and thus also independent on Android and Android Open Source Project (AOSP), or Android kernels in any way.
A cash flow is essential to sustain a Linux mobile ecosystem. And in the Linux world the sell goes often once. Just when selling the device itself. But software has to be maintained, and people have to be paid. Therefore, I highly recommend to buy a native Linux hardware device, independent on Android, if you want to support mobile Linux, and have the financial means.
There are options to donate to different mobile Linux projects as well though. Only a small donation can already make a difference, especially if many people are providing such support.
It is hopeful to see how different Linux phone software projects, and Linux phone competitors in a way are all working together to further a truly free operating system. The phone market is large enough for native Linux phones to exist next to each other. So not Linux as an aftermarket, but Linux native phones that support the whole mobile Linux world. And yes, also there is place for aftermarket Linux support, but I doubt if this would be enough in the long run.
Let's make a thought experiment: let's think about designing a new Linux distro from scratch. Obviously starting with Linux-the-kernel, and then thinking about what we need to be a modern smartphone OS.
- We'll probably want the security model, with the nice sandboxing and I would argue the verified boot.
- We'll want the battery optimisation.
- We'll want access to the firmwares of the components running in the phone.
- ...
From the very first step "start from Linux-the-kernel", every single question I ask myself goes towards the Android design and away from the classical Linux distro design.
In other words, the open source Linux distribution that is the closest to a modern mobile system is... Android :-).
The best battery life I ever got on a smartphone was on a HTC One X back in 2013 or so. It had a custom ROM (Paranoid Android IIRC) where I stripped out all the google services, blocked all wakelocks and so on. It had an nvidia Tegra3 CPU, which had 4 normal ARM cores and a 5th tiny core that ran at 100Mhz or so max (with powersave governor). On that setup, when I was not using it, it drained like 2% battery a day (50 day runtime). Since then we went from 40nm to 3nm, 2000mAh to 5000mAh, I'm doing the same things on my phone and yet, due to bloat and spyware the battery life is worse and worse. I went through HTC One m8, HTC 10, OnePlus 7Pro, and a Samsung Fold7 and each had worse efficiency than that 2011 CPU on the OneX (And a Nexus7-2012 until it died due to low quality NAND)
"I had a phone where I disabled most of its smartphone features and broke them" is not really how you get a useable OS.
Reminds me of those dudes who think a terminal console with broken bluetooth is sufficient to make a macOS Linux distro competitor.
I mean, it was still connected to a cell network, so it was fully usable except maybe notifications. (Obviously the battery drained faster during active use)
Ah, except ONLY notifications? Wow, really not important for a smartphone. Not to mention other background operations that most people want to rely on.
See back to my point about terminal dudes with broken laptops thinking that's good enough.
Even more so, it is the closest to Inferno's design, which was the evolution the UNIX founders went through.
Like they created UNIX, they declared it done, created Plan 9, followed by Inferno, most as a reaction to JavaOS, but still, the creators of UNIX moved on.
Whereas the FOSS community seems to be stuck in recreating Bell Labs in the 1970's.
Most of the FOSS community is hostile to even creating basic sandboxing. The Flatpak project gets panned all the time. Not for having a weak sandbox (which would be a fair criticism), but for having a sandbox at all and not using 90s-style package management.
A lot of people from the FOSS community seem to believe that (at least from recurring discussions) that Linux is secure because the software is open source and you can trust the maintainers. The idea that even trusted software can have vulnerabilities and that the 80s/90s security model of the standard Linux desktop means that you are only one Mastodon/e-mail/RSS/whatever client vulnerability away from exfiltration of your whole home directory does not even occur to them. All the while all these applications use (XML/image/...) parsers from the 90/00s written in C.
The only reason we don't see mass-exfiltration of data is because the Linux desktop marketshare is effectively meaningless. Though we see some results of the desktop security disaster (also to some extend of macOS) through leaked credentials obtained by compromised NPM, PyPI, etc. packages.
> Most of the FOSS community is hostile to even creating basic sandboxing.
> 90s-style package management
> 80s/90s security model
> parsers from the 90/00s
Perhaps the crux of the issue, and the reason these new systems get pushback, is because people, myself included, don't like being told that they have to stop using the tools that served them well for arbitrary reasons (usually age). Similarly, you can't expect everyone to trade user control, convenience, usability, and more for security, or sometimes perceived security.
We can debate about the 90s style package management, but old C-based file parsers and DAC access control were certainly not designed for modern attack vectors. Defending a device now requires layered security using a combination of among other things:
- Memory-safe languages where possible.
- Sandboxing of applications, parsers, etc., along with a strong permission model.
- Mitigation like secure app spawning, zeroing out pages, etc.
- Modern mitigation hardware-assisted mitigation like MTE and PAC.
- Storing secrets in a separate secure enclave (not ~/.config or ~/.ssh).
- Read-only and fully verified system partitions (anti-persistence).
This graph:
https://security.apple.com/assets/image/generated/xlarge_adv...
from Apple's MIE docs [1] shows where modern systems like iOS and Android are. An attacker often needs a long exploit chain to compromise a device and it becomes increasingly difficult with various mitigation techniques. On the standard Linux desktop it's often as easy as exploiting an image parser in a client. Old parsers in C have a history of bad vulnerabilities, exploiting one often gives you privileges of the process calling the function, since Linux applications mostly don't separate/sandbox parsers and from there you have direct access to all data of the user, since Linux applications are typically not sandboxed.
[1] https://security.apple.com/blog/memory-integrity-enforcement...
Lets not forget that the motivations for Alef, and Limbo, from the C authors themselves, were also to improve language safety.
In Inferno, only the kernel, DisVM (+ JIT), and a few drivers are still C, everything else in userspace is Limbo.
> Limbo is the application programming language for the Inferno operating system. Although Limbo looks syntactically like C, it has a number of features that make it easier to use, safer, and more suited to the heterogeneous, networked Inferno environment: a rich set of basic types, strong typing, garbage collection, concurrency, communications, and modules. Limbo may be interpreted or compiled ‘just in time’ for efficient, portable execution.
https://doc.cat-v.org/inferno/4th_edition/inferno_OS
And even if the design isn't the best in the world, it was then followed by Go, it was not what Google is doing in C++ should be redone in C.
https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
Another angle on this is general reliability and what that does to the experience. I'm reminded of Linus having a moan about poor availability of ECC in consumer RAM and how many errors that get blamed on software are actually down to something happening to hardware but it isn't specifically identified. Plus when you're talking billions of devices even small proportions are significant. Firefox built a memory tester into their bug reporter tool as that 'noise' became a large enough problem for them.
Yeah, pretty much so.
Which is of course after having met those requirements IOS is basically android with a different name and closed source and we only need one player that isn't even properly foss. Or why ChomeOS invalidates the need to keep working on kde/gnome/etc
Or that isn't the case and this is all just a silly comparison.
Sorry I don't understand. Would you mind rephrasing that?
He’s saying the examples given were so generic that every OS that cares about battery life and security would just be Android. Battery life optimizations and sandboxing don’t make Android inevitable or the only option.
WebOS was a 3rd option until HP sold it off. Microsoft also had a go at it. They were both very different than Android, but would have those features (if not then, they’d have them by now if the projects were still going).
Well then he is missing my point. Which may mean I was unclear, or course.
My point was that "Linux on Mobile" seems to be mentioned a lot when talking about an alternative to evil BigTech. The thing is, if you want to fork something and make it a modern mobile OS, you may as well just fork Android and go from there. Because Android is open source and already has billions of apps.
Microsoft didn't make an open source system, I think? I had never heard of WebOS, so I'd be open to it, but the fact is that the "Linux on Mobile" crowd is more into Alpine or Debian running on a mobile. Which is far from a modern mobile OS.
I totally respect the Linux on Mobile projects, they do a lot of cool stuff. But I don't see that being a serious alternative to modern mobile OSes anytime soon.
I didn't go into that in this article, but given the number of comments here and on Reddit, I think I should write a second article that explains my thoughts on why I think Linux phones are better strategically than AOSP phones. I'm not opposed to AOSP phones--I use my two AOSP phones more than my two Linux phones. Most people aren't going to use the current Linux phones. Even I as someone who has using Linux since 1999 find that the functionality of the current Linux phones doesn't match AOSP phones. However, I think using AOSP helps lock us into the Android ecosystem, whereas using Linux helps build an alternative ecosystem which is what we need for long-term independence and freedom.
> which is what we need for long-term independence and freedom
Sources are required here. I think that Android being open source is great, and I actually run a fork of Android (GrapheneOS) which is great.
Again I am not against the Linux on Mobile initiatives. I have been trying them, and following since 2020. I stopped following a bit in the last couple years, but really, what I see is many Linux on Mobile projects that seem to focus on "having a nice UI" and supporting waydroid and being able to use the phone like a normal phone (that is, being able to call someone). And a ton of work mainlining mobile hardware, which I do respect a lot. However, I haven't seen much (or anything at all, really) around the security model.
In other words, the Linux on Mobile philosophy is really "bring a traditional Linux distro to the mobile phone". And the traditional Linux distro doesn't have a security model that works for a modern mobile phone, period.
I would argue that if you rethink the traditional Linux distro to have a modern security model for mobile phones, then it stops counting as a traditional Linux distro and it becomes a new mobile system. Which would be very hard (again, resources against Android), but seems out of topic because this is not what Linux on Mobile is.
It’s just a question of funding. Ubuntu made a push for mobile years ago. They put up a phone on Indiegogo, but it didn’t hit its funding goal.
https://en.wikipedia.org/wiki/Ubuntu_Edge
This is what their Unity Desktop was for as well. A desktop environment that had a consistent design language from desktop to mobile.
The remnants of all of this are still kicking around, I think the community still maintains the phone OS, but without the weight of Canonical really pushing it, and a phone shipping with the OS pre-installed, it won’t get as far.
And did UbuntuOS have an actual security model?
I never looked into it, but I would assume it handles security the same way Ubuntu does.
Which makes it less secure than a modern mobile OS, right? That was my point above.
Android's security model isn't the only inevitable option. It was an absolute mess when it launched, to the point where I didn't feel comfortable using any apps from the Play Store and gave up even trying the use the platform. They've since copied a lot of the security controls from Apple, from what I understand, but last I looked, I still like how Apple handles things better.
So even in the world we live, there are 2 platforms that handle security in 2 different ways. Those ways have evolved over time. Ubuntu Touch was made 13 years ago. What did security look like on Android 13 years ago? It's a bit unfair to judge it by today's standards. We can only assume an actively developed OS, being used by normal people (not just hobbyists), would evolve and grow to meet the needs of the platform in the market.
I also assume one of the reasons people want a Linux phone is to have more control, having root without needing to jump through hoops, side loading apps, building from source, etc. They don't want to be locked in a sandbox. I think there is also an assumption that people will play better in a classic Linux environment where there aren't so many financial incentives, and anyone who tries to implement the kind of data collection we see on most modern platforms would be booted from the ecosystem until they can play nice. It would be nice if the current duopoly would do some of this, but most people don't care, and pulling apps from the app stores for breaking the rules is incredibly unpopular.
> Android's security model isn't the only inevitable option
I never said it was. I said "we need a modern security model in a modern mobile OS, and Linux on Mobile doesn't remotely have that".
> Ubuntu Touch was made 13 years ago. What did security look like on Android 13 years ago?
That's a bit my point. If Linux on Mobile is 13 years late, against modern mobile systems that get the resources they get (that is, orders of magnitude more than Linux on Mobile), you're not really catching up. And if you had enough resources to maintain such a project, maybe it would be interesting to fork AOSP instead of spending a decade catching up?
> We can only assume [...] would evolve and grow to meet the needs of the platform in the market.
Is that the only assumption we are allowed to make? When countless alternatives from Microsoft, Samsung and others failed?
> I also assume one of the reasons people want a Linux phone is to have more control, having root without needing to jump through hoops, side loading apps, building from source, etc.
Totally, this is what many of them say. Though side loading, building from sources and the "etc" I can imagine totally work with AOSP. I can easily have root on AOSP, I don't know what "jumping through hoops" means here (other than "I want it enabled by default on official builds").
> I think there is also an assumption that people will play better in a classic Linux environment
I believe that GrapheneOS plays nice and makes a nice system. As for the apps, I barely use tens of apps (realistically I mostly use what... ten of them?), so it's not completely crazy to ask me to select 10 good apps from the billions available. And those that are proprietary (e.g. for public transport) I wouldn't have a choice on Linux (probably they wouldn't exist there).
> but most people don't care
I do care. I run GrapheneOS. Because I disagree with you does not mean I do not care.
iOS and Android have an incredible amount of engineering to make them RAM and battery efficient that desktop Linux simply doesn't have.
And its not a case of simply implementing some feature, since all apps have to written with this stuff in mind: apps can be suspended/killed at any time and should be able to restart gracefully, notifications go through a side channel, etc etc
Do these phones have any of this?
Looking at the amount of RAM phones have nowadays I don't know if this is an issue, desktop Linux runs fine with those amounts. Also Android is not really memory efficient so they needed this workaround.
I currently have 35 apps "open" on my iPhone, most of which are probably React Native or similar.
Other times I'm sure I've hit 60-70.
Because of iOS's app management feature, most of the apps are actually dead, but if I go back and open any of them, they will open and load on the screen on which I left them.
Android does this too.
Desktop Linux cannot.
Can I open 60-70 or even 35 Electron apps simultaneously on 8GB of RAM on Linux?
And no, I do not want to to back to closing apps, that is simply an inferior experience.
> they will open and load on the screen on which I left them.
You can't be serious. Browsers can't even remember the most trivial of things - a tiny html page, retaining reading position, forcing a reload. Of course many apps are no better (though some do try, just like on the desktop) And it's especially worse with user input that just gets lost
> And no, I do not w to to back to closing apps, that is simply an inferior experience.
Ctrl+Q to close and a shortcut to open or is a faster and more convenient than swiping around. As is typing an app's name on a real keyboard. Tapping "desktop" icon is arguably better, though, that a mouse click
Of course some apps implement this better or worse, but for an app that doesn't implement this, booting me to the home page (which is just one tap away from where I was) is still miles better than hogging ram.
I don't want to close apps, I don't want to manage my computer's resources.
It should just work and it should just work well.
> It should just work and it should just work well.
That's just magical thinking (thought I totally agree with the sentiment, it should, and Linux should also be better), it doesn't, you're still doing the management, just using a different set of gestures.
For example, knowing about this poor "incredible engineering" I sometimes have to reopen the app in the middle of using another app not to lose my input/position there, especially when I need some basic cooperative behavior like copy paste in multiple steps, where I need to make sure no steps are lost. The primitive iOS system can't guarantee that! And in some instances I'd take the overall sluggishness due to RAM waste over this because then I'd still manage to complete the task, albeit slower, instead of having to redo the work (and in some old apps I could even save intermediate progress to those ancient things called files that Apple despises)
> which is just one tap away from where I was
Except it isn't. If you've scrolled to X% of the document, there is no 1 tap to get back there! And if it took you 5 taps to open that sub-page sub-group it the app setting, then getting from the hope page will take the same 5 taps + some time wasted remembering where you want to go to. And if you lose your input in the input field, same thing, 1 tap won't magically recover it.
And if you're temporarily in a place without (good) network conneciton, you might never get there in any number of taps becaus the page won't load.
Btw, if it's fine to lose user data, than Linux can OOM your apps for you just fine without any extra management on your side. Sure, its current state of app management is not as good as on mobile, it does lack some "engineering" in this regard, though not sure what's so magical about more careful killing of apps
> it's fine to lose user data, than Linux can OOM your apps for you just fine
That's the point. Android and iOS have cooperative applications by design. They implement an interface and apps will save their state on command and restore it on next run quickly.
You can't get it back properly without the apps being cooperative to a degree
> apps will save their state on command and restore it on next run quickly.
Except they don't, including apps created by the OS owners! Only some apps do, just like some desktop apps autosave.
> You can't get it back properly without the apps being cooperative to a degree
Exactly! Just like on any desktop OS!
Okay, so what's the signal for a Linux desktop app to save its state issued by the OS, after it will shortly be stopped and killed?
Ok, but this is just a case of some apps not implementing this properly.
For example Adobe Acrobat does remember exact position in the document, so do first party Apple apps and many others.
Some apps don't.
On Linux no app CAN implement this because the protocols do not exist.
> so do first party Apple apps
Again, what I've started with - this is simply false. App Store, the first party gateway to all apps, doesn't. It loses the app page you're in all the time and can't even remember your search query. Safari doesn't
> On Linux no app CAN implement this because the protocols do not exist.
What do you mean, what stops an app from saving position and restoring it in the absence of some magical protocol? How have some apps done in since before the phones existed?
Huh? I just tested it now and the App Store reopened on the same page I was on and Safari also opened on this page and it remembered what I had written into the text box.
More generally apps can store whatever info they want when they're going away to be retrieved when coming back transparently.
On the other hand semantics on the Linux desktop are such that the operating system cannot inform an app that it is going away transparently.
An app that is SIGKILL'd cannot save anything (unless it is proactively saving all the time which is terrible for battery life), an app which is SIGSTOP'd must save it's entire memory space and cannot relinquish locks or GPU resources, and an app that is SIGTERM'd can ask the user to save their work etc. (which is not what a transparently closed app should do).
No wonder you've been oblivious to this issue with 40 apps. Test better, I suppose? Maybe give it more time for the system to fully offload the app, maybe run a few intensive games if you want it faster or just wait longer?
Have you tried other tabs in Safari? Turned off the internet to see whether it's redownloading a page. (by the way, Safari uses 1G of cache, that's enough to store all my 40 tabs basic htmls, yet it doesn't, it finds other less relevant data more important)
And just for this I've tested two more native apps: opened settings/filters in Magnifier, and started editing a password in Passwords app. I was glad that both of these seem to remember the state, and their app switcher screenshot reflected it (well, except for passwords, which is hidden), but then after a longer time reopened them, and position was gone and I was back on the main page - exactly the experience I came to rely upon with trivial bits of state simply gone.
> is SIGTERM'd can ask the user to save their work etc. (which is not what a transparently closed app should do).
Why can't it save the state without asking??? Have you used text editors with hot reload? They just quit with "unsaved" (but not "lost") files.
It's in unix. SIGSTOP and SIGCONT + swap.
And GPU buffers? And in-flight network requests? And notification handling? And D-Bus presence? And watchdogs? And other held resources like pids and fds?
If you want to checkpoint/resume applications arbitrarily, as AOSP does, you have to virtualize all of those resources anyway. Check out the CRIU patchset (since merged to mainline) which can even resume applications seamlessly across hosts, without any VM being involved.
These are things that would be easy to solve in Linux.
What is difficult is e.g. supporting the undocumented photo/video camera and other essential parts of the hardware that lack documentation.
This gets brought up several times in this discussion. Hardware with drivers, firmware and device trees exist, see e.g. Fairphone. It even works with open source camera apps (e.g. done in /e/OS). The problem is not (only) the hardware, it is that the Linux desktop stack is wholly unoptimized for phones. And the fact that Meego/Maemo/etc. are now almost two decades ago shows that it is not 'would be easy to solve'. Heck, Linux laptops, which have been available since forever still have far worse battery life than Windows or macOS.
You need a stack that is designed from first principles for phones. Luckily we have one that is open source (AOSP).
Yeah it's solved. It's called android + a normal userspace that can tell apps to suspend and apps are cooperative and do so before getting stopped.
It's not a technical problem, it's a social one (for the apps/programs)
You haven't tried to run a Linux on Mobile distro on your phone and compared the battery life to Android, have you?
Spoiler: I have :-)
Depending on the phone they'd struggle to go in a low power state when the screen is off or can't access other power saving features because the manufacturers keep everything under wraps.
this. years ago i was working with Intel and Samsung to enable Tizen on x86 phones. energy management was the biggest problem they had. RISC won. moreover, 8 years later Apple was moving away from x86_64 to ARM, so one could say ARM won because of better energy management, either through lower usage or other types of energy saving techniques. Google Pixel (ARM) had similar issues with battery life, or better yet battery drain during idle times. People underestimate battery saving techniques. As in all software engineering, when the focus is enablement, optimizations take a second stage.
All this "engineering" really is, is basically just reducing CPU use (trading it for doing things on HW accelerators/offloads if present) and lowering the voltage/frequency to what's needed and suspend/resume. There's no special sauce in there.
App can be easily stopped in linux via SIGSTOP/SIGCONT. It will consume 0 power then. :)
Even original Pinephone has all what's needed for efficient use of energy for smartphone use cases.
And if you stop thinking of "apps" as processes and design architecture differently, you can have millisecond scale reactions to all user input on the entire phone even on original pinephone. Apps opening in a blink of an eye right after boot, etc. :)
Linux phones trying to reproduce Android architecture are kinda pointless. What would be the point, when you have the freedom to implement any other architecture, actually suited for the user centered model, where you don't have to ballance the needs of untrusted app providers.
And it doesn't actually work reliably, at least on Android. My wife and I frequently don't get notifications from specific apps, only once we open them. My impression is that the platform just changes too frequently with regards of what you have to do to work well even when you're killed. Also, especially for push notifications, your now at the mercy of Googles service to delvier them to your app (not sure how the open source variants do it)
There is also the problem, that some OEMs add their own "battery optimizations". If you simply don't run anything its indeed very battery efficient... Forcing push notifications through some central service has minimal benefits at best. Open source variants are forced to publish annoying persistent notifications and ask the user to flip some "battery optimization" toggle deep inside the settings to not get killed, of course this often enough changes with Android versions.
You're talking about the standard battery optimizations where the end user needs to approve apps repeatedly waking up the app from sleep and running continuously while awake. OEMs have been required to stop doing most of the non-standard things they were doing in relation to this and it's not hard for app developers to deal with anymore unless they care about it on end-of-life Android versions.
The persistent notification for foreground services is mandatory for apps to implement but entirely optional for users. The notification channel can simply be toggled off to hide it. Apps are required to make a notification for each foreground service to provide transparency. It gives apps a way to explain why they're doing it to end users and the notification be toggled off if the user doesn't want it. It can also be kept enabled but collapsed at the bottom with no lockscreen or status bar display. Apps are required to use at least low importance themselves so the user needs to opt in to collapsing and hiding it or turning it off.
Fully open source apps can use UnifiedPush as the Molly fork of Signal does instead of their own push connection. Similarly to FCM, UnifiedPush providers can provide reliable and efficient push messaging including push notifications. Unlike FCM, users can choose the local implementation and the service providing it including the option to self-host it. There are multiple options available as an existing service. There are a growing number of apps supporting UnifiedPush.
Signal's own fallback push messaging for push notifications when FCM isn't present is very inefficient. It substantially reduces battery life even if it's the only app doing push with another mechanism. Molly's UnifiedPush support works much better.
Using a single push messaging connection or at least only a couple (FCM and UnifiedPush) is definitely far more efficient than using dozens. Using many push messaging connections will drain a lot of power due to each needing to be maintained with regular checks which will typically not align well. Having many causes a drastically higher number of wakes from sleep and non-idle time. That's especially true if the push messaging connections aren't implemented very efficiently. Even a single inefficient one can drain a lot of power.
Signal's fallback isn't as bad as it used to be but it's not efficient. They should support UnifiedPush as Molly does for a better non-FCM push experience. Signal's fallback push is a common way people ruin battery life on GrapheneOS.
UnifiedPush is an open source solution for push notifications that isn't tied to a particular service provider. A handful of apps support it.
https://unifiedpush.org/
Same for us on our Grapheneos Pixels. Notification are a bit of a lottery. But we take that as a feature. People can call if there's an emergency.
Push notifications work reliably on GrapheneOS via both Google's Firebase Cloud Messaging (via sandboxed Google Play) and UnifiedPush. Your later replies indicate you aren't using either of those but rather app-specific fallbacks. WhatsApp doesn't implement a reliable fallback. Signal's fallback should work fine but is very inefficient compared to using either FCM or the Molly fork with UnifiedPush. Both FCM and UnifiedPush do work reliably.
On all apps? I have never had issues with notifications...
Some don't work at all, bc they must be GSF-only I guess (installed via Aurora store). Others like Whatsapp or Signal sort of work but sometimes the app seems to not be running (even though I set up the no battery optimization). And I get multiple unread messages at once when manually starting the app.
If you aren't using sandboxed Google Play then you're not going to have push notifications in apps solely implementing those via FCM. That's your decision and not an issue with push notifications on GrapheneOS. You're using the fallback push notification systems in WhatsApp and Signal rather than FCM. Neither app cares much about those fallbacks. If you want reliable push notifications without FCM for Signal then you need the Molly fork of Signal with a UnifiedPush provider. There are hosted UnifiedPush and MollySocket services so you don't need to host it up yourself.
That's a very important bit of news to me. As someone that's considering GrapheneOS is there guidance on these decisions either in device or a new users key concepts article I need to read?
There are a few ways to address that. I run Molly in the Owner profile without Play Services and it's been solid.
You may want to peruse the various sections of their site before switching to see if you think it'll work for you: https://grapheneos.org/features
Thanks for the tips. To be clear I absolutely wasn't criticizing GrapheneOS in any way. I know things are this way (and my choice) and I'm perfectly fine with it.
In any case, many thanks for your work. GrapheneOS is a breath of fresh air in the consumer electronics nightmare.
Same, they work fine and are immediate. The only exception has been Signal. Must be that I'm using sandboxed Google Play Services?
I use sandboxed Google Play Services, Signal has been fine... I cannot say it's always immediate (I'm not always on my phone :-) ), but I have never been frustrated for "missing" a notification. Like when I check my phone, the Signal messages are there, they don't appear 3 days later.
Oh, they certainly don't appear days later. But sometimes they do between ~1-30 minutes. This is a well-known issue, you can find many topic about it. When you open the app, everything comes in all at onec.
It is sometimes annoying to me. I cycle a lot and sometimes my wife or somebody else sends a message when I'm on the go (like picking up some extra groceries) and then I miss it.
There is a longer discussion with various people here:
https://github.com/signalapp/Signal-Android/issues/14166
I see, I don't know. 1-30min could totally go under my radar :-). When it's urgent I ask people to call me.
So yeah, I can totally accept that this may be a thing.
I wonder if they installed something like "adblockers" in their devices on networks that constantly kills keep-alive connection to Google servers which actually delivers the message.
Or somehow broke the device-side wakeup for that keepalive.
Yet
Linux on phones have been around since the late 00s (e.g. through Nokia's efforts). Why would this suddenly change? Heck, even after decades, the battery life of most laptops running Linux is still much worse than Windows, let alone macOS.
I have had several generations of ThinkPads and to this day, battery life is typically ~50-60% of that of Windows, even with all battery optimizations applied. And Windows is terrible compared to Mac or Android/iOS phones.
And I say this as a long-time Linux user (used Linux in some form since 1994). It's just a very hard nut to crack if you miss a certain amount of vertical of integration and coordination across the ecosystem.
We are _not allowed_ to make it good. Without hardware documentation, you're looking at decades of reverse engineering effort just to get somewhere half as far as an engineer with hardware documentation can get in a weekend.
Look at Asahi. Almost a decade in and we can use the GPU at like 30% of its ability on 6 year old hardware.
That a project with major interest. No one cares about spending a decade reverse engineering the hardware on a Google Pixel or Samsung Galaxy.
If they gave us proper full hardware documentation, we could create high quality alternatives. Again, we can't so you don't see it.
Competition is good. We should always advocate for things that enable competition.
> Without hardware documentation, you're looking at decades of reverse engineering effort just to get somewhere half as far as an engineer with hardware documentation can get in a weekend.
I'm not sure this is true anymore and it is becoming less true with each new LLM release.
> No one cares about spending a decade reverse engineering the hardware on a Google Pixel or Samsung Galaxy.
Actually, this might a cool idea - just get a few super cheap smartphones, connect them all to a PC, give LLM access and tell it "make linux gud like android pls" and just give it a weekend.
Even if you have the binary driver and you decompile it with the help of a LLM, it does not provide most of the information from the documentation.
You may see that the driver writes some hundreds of magic constants in some hardware registers, but you do not know what they mean. You may be able to do exactly what the binary driver, does, but you will not be able to improve it, e.g. to enable features that happen to be not enabled in that driver.
So a LLM can speed up the initial part of reverse engineering if you have the files with binary drivers, which may be difficult to extract from certain phones, but a lot of work remains to discover all that the hardware can do.
> Look at Asahi. Almost a decade in and we can use the GPU at like 30% of its ability on 6 year old hardware.
Wasn't M1 GPU actually supposed to perform better on Linux than on macOS?
> Why would this suddenly change?
I see three aspects there.
The first is that google is currently rugpulling via various means and _really_ playing those anticompetetiveness-cards. That wasn't the case previously. So there wasn't much motivation to care, because android was "open enough".
The second is that the world is getting less geopolitically stable. So the whole ecosystem lockdowns are not just a personal preference thing but might be actually vital.
The third is that LLMs are kinda good at these optimization loops if you hand them a framework in which they can sample good data.
I also had a fourth thought but it left my mind :(
Android is still open enough. Worst case, AOSP can be forked and it will still be leagues ahead of non-Android Linux phones. That also applies to the sovereignty point. I see especially GrapheneOS and /e/OS grow because of this in local communities.
LLM-driven optimization is a good point. However, Linux desktop communities tend to be quite aggressively anti-LLM. E.g. GrapheneOS has been heavily attacked by these people for only using an LLM for security auditing. But maybe these projects will fork into LLM-accepted forks who will then rapidly out-innovate.
> iOS and Android have an incredible amount of engineering to make them RAM and battery efficient that desktop Linux simply doesn't have
This one of the most understated reasons.
If you look at ARM, SBC and MiniPC market, Linux can be very frugal when it comes to power management and RAM use. Just because a bog standard Ubuntu or Debian is not tuned towards it doesn't mean it can't.
It's a problem at the Wayland/Wayland protocols/XDG level.
There is simply not enough rich app activity information for the session manager to do smart management.
Compare it to what iOS and Android apps report about themseleves and the conditions they are forced to run in (such as being arbitrarily killed and restarted).
Obviously the Linux kernel is perfectly able to sit in a stack like this (see: Android), it's the XDG standards which are not well suited for this.
We can extend the standard, no?
I don't want to add yet another standard because the best part of the standards is there is too much to choose from.
It's a matter of signaling, though, and if we improve the signaling, we can build upon it.
Again, it's not a simple task (I dug into GNOME's compositor for two weeks just to find a note saying "Errm, we didn't implement this to X11 specs and it does funny things on touchscreens. If somebody can do this all over, we'd be glad. KTHXBYE"), and we were developing something for touch screens, albeit huge ones.
Well, I won't go into details today, maybe later.
It’s not only a matter of tuning. Everything in the stack needs to be developed to go idle and not do things in the background by themselves. The Linux desktop and all its apps are made for a model where apps can continually get CPU time.
I know, but that's a set of libraries. Nothing which can't be done, because the foundation is there. In most basic terms, you need to be able to freeze apps and be able to tell when they have nothing to do, so they can be scheduled with minimal time slices to run a single, lightweight function to check whether they need to do anything at all.
Of course it's more complicated than that, but it's not impossible, since the foundation is already there.
It's a social problem not a technical. Apps themselves have to support that kind of cooperative life.
The hard part isn't having a few people design something powersaving, it's having the whole set of distro software working together for power savings.
That's the incredibly hard part - not having some random package run a cron job every 10 seconds because it was easier for the developer to do it.
And Linux developers get incredibly angry - keeping grudges for decades - if you try to add systems that enforce power saving behavior necessary for devices to last a whole day.
This is where the difference between Android/iOS and Linux distros lies in practice. And people are still - even on HN - incredibly angry at Android for not letting them destroy the battery anymore.
It's just closed source drivers stored in private Linux forks (or Apple's code dungeon).
There's nothing inherently special about their optimisations, but hardware is incredibly complex and without documentation, open source drivers cannot be written that are anywhere close to what engineers with hardware docs can build.
Asahi Linux is a great example. It's an unbelievable project but still far from first party Apple drivers.
Once the hardware can actually be used, competition in the OS space will follow.
They have no incentive to offer documentation and competition is bad - so they won't allow that. Regulators must step in here.
I just want a virtual phone on my Android device. Why is this so hard?
So a new phone means just moving the VM. The only unique thing my Android layer has to do is route the internet..
the manufacturer of the gsm and cellular hardware do not what their products to be commodities that users can interchange easily. They want their commercial supplier contracts to be between negotiated cartels, which allows each producer to eat a certain horizontal slice of the pie.
Every player in this space currently has this incentive imho.
They always had.
While everyone that was doing vertical integration in the last century, had the whole product to sell, the OEMs selling IBM PC clones were all alike, so they always had something to differentiate, being the shovelware that was offered alongside the PC, pre-installed, painted cases, whatever.
That's a very simplistic idea of what it would entail.
What a fantastic article. As someone who has contributed to Phosh and Nura (prev. postmarketOS), I was always sad that Linux phones didn't take off. This article describes very well how difficult the firmware/hardware side is, which as a software guy I hadn't quite understood.
The software side (Phosh, KDE, etc) is now improving fast (both IMO because the obscure frameworks they're written in are easier to contribute to with AI, but also just thanks to time and maturity).
And if the firmware/hardware side can graduate the treadmill of endless bring-up and instead work on performance and fun stuff, that would be fantastic. We need our Raspberry Pi moment. First the Librem and Pinephone were our hope, then the OnePlus 6, but they all stayed 80% usable. Currently it was the Fairphone, but now tbd which the savior device will be. Exciting!
I wish the Ubuntu Phone kept going. Damn shame. I liked Ubuntus storage offering, it felt like Ubuntu was trying to compete harder with Windows in a nicer way, sadly they abandoned a lot of those initiatives, what could the world look like if Ubuntu found the right hardware partner to get Ubuntu devices into most mainstream computer stores? We wont ever know I guess.
Yes. And I would argue that in the form of the Sailfish OS devices.from Jolla, they already are a viable alternative.
I think that given the current capabilities of LLMs, it should be possible to deploy a completely non-Linux-based system on any smartphone—even one with entirely different control algorithms for the CPU and memory.
If i will not able to get in control of the device, at least as much as macos level, and still able to make contactless payments, approve online payements, breaking the duopoly will not matter much for me.
Maybe i should aim for a second smallest possible android phone just for banking to set my mobile computing free. (İ was already tried using unihertz jelly star as my daily driver for a while)
Before the talks of alternative platforms, there should be legislation in place for services to expose http endpoints for all services rendered. I.e., a legitimate user should be able to point their web browser at it--behind whatever authentication and bot-detection shenanigans they want--and avail the services. No apps, no crap, no bloat.
In other words, the 'app culture', and the attendant normalisation of data stealing, must end. This effectively takes "app-" and platform-dependency out of the picture. Services are no more burdened with supporting n number of platforms; nor do they have an incentive to push people to start using their apps. Services can still offer an app, and users still have a choice to use one. But, the baseline client should be a browser. And there shouldn't be any discrimination between mobile vs. desktop browsers, either.
Sailfish OS is, IMO, good enough for daily use. I do use their (Android) App Support for a few apps out of convenience because, for example, I just like Symfonium music and audiobook player. However, if I would approach it more strictly, I could comfortably live without Android on the device at all. Do take that with a grain of salt, though - I don't use mobile banking apps and NFC payment, for example.
edit: The hardware supply chain is an issue, though. It's all Android hardware under the hood because that's the only thing you can buy. So there are crutches necessary to translate between Android drivers with their hardware abstraction layer and "proper" Linux. Libhybris does that in case of Sailfish OS / Jolla (the company behind the OS) and it works well but I wouldn't call it elegant, necessarily.
I think there will never be mass-market “Linux phones” in the sense of “runs a Linux kernel and you can tinker with all their parts”.
Demand simply is too low. FTA: (https://amosbbatto.wordpress.com/2026/10/05/linux-phones-alt...):
“Jolla has sold 15,000 units of its phone as of August 2026 just by taking pre-orders for production batches from its web site”
In comparison, Apple easily sells 15,000 phones each hour of the year.
So, the best hope for such a Linux phone would be to have something installable on hardware of a third party that normally ships Android. I don’t see that happen because such hardware gets locked down more and more to defend against cybercrime.
I don't think it is fair comparing Jolla agains half of the current Smartphone monopolists.
Also you need to build an ecosystem so that users and developers can get involved & open hardware fully supported by Sailfish OS is a good start.
Also a lot of mainstream mobile hardware is locked down on purpose to effectively enforce planned obsolescence, which makes it harder to port a sane OS on it.
I have been reading this since OpenMoko.
No they want, unless they cater to normies, instead of trying to be X Windows and UNIX CLI on a tiny phone.
And for better or worse, actually make deals with OEMs, instead of trying to reverse engineer them, phones aren't like IBM PC compatibles.
No, Linux phones won't become a viable alternative to Android or iOS phones.
The average phone user couldn't give a damn about the underlying OS - they buy on price and features - not the "hackability", or whatever drives the good readers of Hacker news to buy phones.
I wonder whether Android/iOS will ever become a viable alternative to GNU/Linux phones. They failed to make me switch for nearly two decades now and only seem to be getting worse.
I can't speak from personal experience, but nearly everyone else in this thread is arguing the opposite: Linux phones are slower and buggier than Android.
What metrics/specific reasons drive your contrary POV?
My personal experience. I've been using GNU/Linux on my daily driver phones for nearly two decades now. Started just before the first Android phone appeared on the market and went through a bunch of devices since. Android never appeared to me as a viable alternative during that whole time (it was in fact closer to being one in the past than it is now) and iOS has just never been something I'd like to use.
I have listed several reasons why I think so in other threads here already, but the main thing is that what I longed for in 2008 when I was getting my first smartphone was a connected personal computer that I can put into my pocket and carry around through a day, and that's what I was always getting with GNU/Linux phones, so I never really got used to the idea of smartphones as these limited, mostly vendor-controlled devices that effectively serve as a trusted runtime environment for adversarial software (and by "trusted" I mean trusted by apps, of course). Instead, I see my phone like I always saw my GNU/Linux PCs - as a tiny box full of useful tools that are there to serve and empower me to reach my goals and which I can put together and modify any way I like to. May not have the sleekest design out there, may not be a speed demon, may have a quirk or two to tolerate and may require me to scratch some itches by myself, but it does what I tell it to regardless of whether it's aligned with some corporation's interests or not and it's well worth the effort spent to configure it to my liking. It's also generally a wonderful thing to tinker with (though this mattered much more when I was still a teenager :))
Inevitable given that a lot of dev entrepreneurs are moving from high level CRUD to low level software, CAD and hardware now with AI. But it might move beyond Linux once AIs come up with their own programming languages.
I’m working on a personal OS, a personal website that runs on my computer and I access on my phone thru Tailscale.
Then I got thinking, could I not just make a phone and messages mini apps for my personal OS that tap into iMessage and FaceTime on my Mac? Even if those don’t have APIs, you could use computer use and accessibility. A 3rd OS should simply be the web and a thin client that connects to your MacBook thru Tailscale.
The year of the Linux desktop still hasn't arrived with the hardware much much more open, strange to hope phones have a chance
I've already tried linux mobile oses on a few devices but they all have issues with calls and sms working. I have no idea why devs don't focus on the basics of a phone working as a phone and instead j*k off over the ui (which is still slow and buggy) or other apps. Because why would I need a fitness app, a step counter, some fancy notification animations etc if the phone doesn't work AS a phone?
Which phones did you try? My Librem 5 has no problems with calls and texts.
Consumers are not developers. Let's think about why Windows have dominated commercial desktop OS market over Linux. If there is no market(users), there would be no apps to use.
Not a single Linux OS phone I can buy today in US with all the basic features working.
Have you looked at the FuriLabs FLX1s+? You can also buy a used Volla phone on ebay and install Ubuntu Touch. Jolla has says that it is considering selling its Jolla Phone (2026) in the U.S.
Mentioned in the beginning of TFA: https://en.wikipedia.org/wiki/Librem_5
I should have phrased it differently. I can’t find a decent spec phone priced appropriately that I can add to cart and order it.
Sure, in the year of the linux desktop.
Betteridge's law of headlines is an adage that states: "Any headline that ends in a question mark can be answered by the word no." It is based on the assumption that if the publishers were confident that the answer was yes, they would have presented it as an assertion; by presenting it as a question, they are not accountable for whether it is correct or not.
Linux phones sounds like so much to miss if not having one! I wonder why its not already out?
I have been using Sailfish OS from Jolla since 2013 on my main phone. They are even selling a new phone with Sailfish OS preinstalled now: https://commerce.jolla.com/
https://en.wikipedia.org/wiki/Librem_5, my daily driver.
I'm not sure about KaiOS current state...
Linux need a "Wine for Android" moment to be viable.
There is an Android Translation Layer now, and there were different attempts earlier.
Yeah, it is impressive how well it works now on devices like the Steam Frame and elsewhere.
https://en.wikipedia.org/wiki/Waydroid
I hope so, if I could get plasma mobile and have all my devices unified, that would be the bee knees.
I'm already running a Linux phone that's not Android–GrapheneOS.
Uhmmm...no. Developing an operating system like Android requires hundreds if not thousands of engineers and hundreds of millions of dollars a year. I don't see a couple of smelly haggards in a basement attaining the same level of quality and depth anytime soon.
I mean, it took Linux more than 30 years to come somewhat close to the desktop experience Windows has been given us.
Any mobile operating system would need, in addition, something extra to compete with iOS and Android. Like a real-time microkernel operating system to enhance security.
> I mean, it took Linux more than 30 years to come somewhat close to the desktop experience Windows has been given us.
LOL. Linux has been superior since about y2k.
But sure, enjoy your banners.
The problem is that a lot of important apps have Google Play Security lock in.
The way things are going, these will become the only viable option for an independent device.
I wish. sadly, no. even the year of the linux desktop may very well never come to pass. I've always felt there's always been a fundamental disconnect between what linux users/devs THINK general audiences want, and what they ACTUALLY want. I applaud them for all their hard effort, they've really come a long way, and they never even got a dime for it (W foss, L microslop), but man the ux has always been a nightmare lol. I absolutely love my laptop running mint, its running better than it ever did with windows, but I could never recommend something even this 'simple' to someone who isn't a hobbyist, or has a lot of spare time to configure and maintain it, or cares about their privacy, etc. I understand also there's many other factors at play here that are completely out of the hands of the dev/community, like the fact its almost never natively supported by just about every app, and I dont mean to put that on them either. they're just more factors holding it back from mainstream adoption.
so if that's been the case on desktop, smartphones are just so far out of the picture. i dont see how the year of the linux smartphone could ever come before the year of the linux desktop.
I really hope I'm wrong. thanks for reading my meh-ly informed 2¢.
> I absolutely love my laptop running mint, its running better than it ever did with windows, but I could never recommend something even this 'simple' to someone who isn't a hobbyist, or has a lot of spare time to configure and maintain it, or cares about their privacy, etc.
My non-technical relatives run Debian just fine. I don't understand what you are talking about. It has unattendend upgrades and doesn't have to be configured or tinkered with after install.
What are smartphones in China running? Presumably not something Google controls.
Degoogle Android, Actually quite easy to bring back google service. I'm using the Chinese-version vivo x200p, the most troublesome is having to put app in enery-intense mode if you want them to run in background, or else the OS will kill them if they are unused for a while.
HarmonyOS NEXT, which is the only serious viable alternative to ios or android
Which is a microkernel based OS, with a userspace based on ArkTS, C, C++ and eventually Cangjie.
Quite interesting for us OS nerds, less so for those that only care about UNIX on their phone.
Mostly just de-googled android
Huawei's HarmonyOS is quite good. As for other brands like OPPO and Xiaomi, I've used them before too. You can use Google Play and a whole range of Google apps, but the localization adaptation is much better.
HarmonyOS and HarmonyOS NEXT, are they own thing.
I have a hot take on this: I don't think iOS and Android have long for this world. In five years, phones will just be an AI device. Local compute when possible, cloud compute when required. The OS will be whatever the AI dynamically creates for the user's tastes and requirements. People won't buy apps anymore. They'll create them on the fly as needed. In rare cases where an app purchase happens (such as a YouTube subscription), the AI will facilitate the purchase with Google's AI.
This makes me tremendously excited someday to take a hammer to my current phone until it is reduced to fine dust, replace it with a perfectly dumb landline, and never give the matter a second thought.
I can't wait for any IS different from android/iOS to do so
I've just written another post somewhere in this thread about discovering a nice feature in KDE Plasma, and remembered my recent search for a way to output HDMI from my old iPhone without ridiculous compression, and all this Linux phone talk stated to make me have crazy thoughts about how much I want Plasma Mobile. I was all set to write "just give me Plasma Mobile on something the size of an iPhone 13 Mini, and I don't care how much doesn't work". I used a 1st Gen iPhone SE, years past where it was sensible. I can suffer.
I started to list my few, basic must-haves - aware that everyone has a different list - but my own short list got embarrassingly long, very quickly. I thought I had simple requirements!
Obvious basics which surely aren't too much to ask: email, calendar, reminder and note syncing, password manager with TOTP generator, instant messaging (willingly to compromise and have only Signal or WhatsApp), route navigation, basic browsing, half-decent camera, ...
Phone calls - so I probably need 4G and 5G...
Oh - plus uncountable other small apps or utilities that hardly seem worth mentioning: calculator, file browser, compass, voice memos, ...
And then I thought about the ever-growing list of big, ugly Apps that I could live without, but really do make my life easier. Banking apps (sigh - I hate how many of these virtually require an app), the app to unlock my apartment block door, Outlook, Teams, ...
And then I started having sensible, disappointing thoughts. Maybe I'd rather just keep the iPhone 13 Mini. I just got a new battery (and bonus screen) installed by Apple on the weekend...
But seriously, when that starts to be unusable... if I have to carry something obnoxiously large, it better run mainstream Linux and turn into a desktop when I plug a USB-C dock into it!
2050 the future of Linux in the pocket!
Kinda had them with jailbroken iphones.
what about sailfish os which comes from MeeGo?
Bettridge's Law of Headlines: "No."
yes but with the catch of waydroid working
Waydroid has been working fine there for years.
https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
The biggest obstacles are 3 things:
- Lack of ACPI support means you need to spend time to customize every ROM using whatever device trees and proprietary blobs for every phone - Most phones have locked bootloaders - Most importantly, Android apps are built for Android. They can run in things like Waydroid, but certain interactions will be broken and app developers probably won't support it. People want phones that work well out of the box.
So, no. Maybe an actually-open Android fork will gain popularity, but mass adoption of a GNU/Linux mobile OS won't happen.
Sometimes I think semantics matters.
Will [other Linux distributions] become viable alternatives to the Android/iOS duopoly?
Imo they already are.. They're actual non-hobbled computers you can do what you want with. Think of all the things you can do on Linux.. Now you can do that on your pocket sized computer.
Sure all the conventional mobile ecosystem stuff wont work. But that's entirely a giant ball of cancer anyway. Only a fool would want to deal with that filth.
So much Pine64-bashing and quite a lot of factual errors.
There were several pinephone HW revisions that fixed HW issues based on direct developer feedback. Yeah, there was no direct communication with HW engineers, but at least the critically important feedback was applied (otherwise modem would not be able to wake up Pinephone SoC from sleep and Alt-D over USB-C would not work at all, and probably bunch of other things I barely remember). I or someone else in #pinedev could tell TL Lim, and if change was reasonable it would be made. There was quite lively discussion around HW issues in #pinedev early on. And company did not seem to lack effort, eg. for Pinephone keyboard there were like 5 revisions, including doing an X-Ray analysis of burned down keyboard MCU and subsequent citcuit improvement. So communication to get HW changes was possible, and was usually via TL Lim, not via HW devs.
"The volunteers working on the PinePhone's kernel generally didn't [upstream]" is factually completely wrong.
PinePhone DT was mainlined for Linux 5.7 by me. smaeul rewrote the sun8i-codec driver and did lot of stability and other work, anarsoul upstreamed Bluetooth and maintained Lima, and many many many more small upstream contributions by different people (git log is your friend), just on the kernel side. People created entire new upstream projects like Crust and p-boot and levinboot, etc.
Yes, there's some long residual stack of patches, but so what? Accurate statement is that some perhaps critical work stayed out-of-tree, partly by choice and partly due to upstream rejections or dependencies, and not that "the volunteers generally didn't upstream." The claim is overstated to the point of being misleading.
And another thing is that even if there was lack of upstreaming, almost no Anroid phone is fully upstream in Linux and it doesn't prevent it from gaining marketshare. Downstream kernels suffice for it.
Latest version of supported downstream kernel for pinephones with good HW support has been available for years. Almost no Android phone can even claim that for their downstream kernel.
Then there's over-estimation in the article of how upstreaming to kernel is important. You can easily say that having full HW support quickly in some downstream kernel is kinda preferable, because it allowed people to actually use the phone sooner, and allowed userspace development to progress. If every change would have to go to upstream, with its long iteration times, etc., people would not be able to use the phone at all for 4 years or so. How many would even stay around? :) I ceratinly prefered making the HW work and work well, over upstreaming. I understand upstream kernel is a distro maintainer wish. People are free to have wishes. :D
Pushing upstream changes coordination of work and to some extent simplifies maintenance for some, while making it way harder for others in the community.
The article says PPP "still had major software problems when its sales were cancelled in August 2025.". Yeah, no. Pinephone Pro has almost full kernel support, multiple bootloaders, even graphics/touch support for U-Boot, etc. There are no SW kernel issues that I'm aware off that were not solved years ago. Yes, again, you need a downstream kernel, but it's been maintained for every release for years since the beginning, just like PP. It's very similar situation to Raspberry Pi, which also sucks without downstream kernel, but did not prevent it from reaching marketshare, or whatever. Commercial cancellation is more lack of interest/commercial viability, rather than anything pointing to lack of SW support.
The article opens by promising to "examine what held back mobile Linux." Well, it consistently assigns blame to companies/vendors while treating the enormous volunteer engineering as background and blameless. Well it's not.
As for the company: Pine64 promissed 10 years of original Pinephone. It's so far delivering what? 8th year? At the same/similar pricing to 8 years ago, across all that happened in the HW industry in the meantime? Covid? Ramocalypse? I'd call that a massive success on promissed claim. The company also never promissed fully working OS/HW android experience. It promissed cheap accessible long-term stable HW product to jumpstart the ecosystem (paraphrasing from memory). And I thoroughly enjoyed developing and supporting Pinephone on the kernel side for 8 years release after release, building well designed (as far as UX goes) bootloaders, and interacting with TL Lim and wider community, etc.
"Once the best volunteers abandoned PINE64, the company hasn’t been able to complete the development of the PinePhone Pro, PineNote, PineTab2 and many of its other projects, so the people who ordered these devices are unlikely to ever be able to use them as fully functional devices."
Sooo. what HW support is lacking on Pinephone, Pinephone Pro or PineTab2 or Pinebook Pro, or other consumer products, if you take some downstream maintained kernel and use it? You'll find that very little of consequence is missing. I know of one: HW accelerated video encoding on original Pinephone. The only claim I see other than performance, is lack of "HW accelerated video encoding". But who would want to record videos with webcam level sensor that uses CAF for auto-focus? Has anyone even tried to imagine what it means practically when you get CAF full range sweep in the middle of the vide? :)
Performance is not really relevant to "level of SW support".
You can also say that perhaps people drifted off after the work was mostly done, because there was nothing more exiting to do, other than absolutely unsatisfying gruntwork that even paid engineers at most android shops don't bother to do.
"but instead PINE64 dismissed the screen flicker" is also incorrect, IIRC. I remember suggesting removal of some resistor to avoid leakage of power into PL port power rail, that caused variation in backlight PWM control voltage, since PL rail served as a voltage reference for backlight PWM. And it was resolved.
There was also flicker due to low PWM frequency: https://xnux.eu/log/079.html
Unless this is some other flicker issue, the flicker issues got attention.
Hi Megous, I'm the author of the article. Before we get started here, just let me say from the outset, thank you for all your hard work on the PINE64 hardware.
I will correct the things that I got wrong in the article, if I can verify my errors.
I have the PinePhone 1.2b (Beta Convergence Package), that was shipped to me on April 5, 2021. It is currently running Mobian Weekly with kernel 6.18.32.1, which I downloaded about three weeks ago.
I see the flicker on my PinePhone's screen. I usually see it for a minute or two after I turn on the phone or resume from a suspend, but I sometimes see it at other times. I see the flicker both when the screen brightness is set to a minimum or to a maximum. I have seen this problem the whole time I have owned the PinePhone.
I assumed it was caused by this issue: https://wiki.pine64.org/wiki/PinePhone_v1.2#Backlight However, rereading it, my case doesn't fit, because the screen flicker exists at both minimum and maximum brightness. Can you explain this?
Maybe my screen flicker problem is special, but was the problem listed on the wiki ("When backlight brightness is very low and the CTP controller actively communicates on the I2C bus the backlight blinks heavily.") ever resolved by PINE64?
There are several possible causes of screen flicker.
One cause of screen flicker is if display is not properly turned off and driver does not wait the required 120ms after turning it off before cutting the power to it. Then on the next display power on, it may very visibly flicker for extended period of time, depending on time between last power off and next power on of the display. I believe mainline kernel driver does not wait. This was my bane when I worked on p-boot bootloader. :-D
It was fixed in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Things in mainline get regularly broken by unrelated work, so maybe this got broken by the unrelated kernel change in 2024 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... that caused the clock that feeds the timing controller for the panel to not be able to set required 432 MHz to achieve the specified 60 Hz, so if you run mainline kernel change made for Olimex laptop caused Pinephone panel to be driven by 16% faster clock and refresh rate is almost 70Hz, which is out of spec. It can only be fixed by revert, without breaking anything else like eg. convergence functionality. Probably not the source of the flicker, but who knows how borderline panels behave. Eg. the mentioned commit says that pinephone SoC MIPI-PLL is unstable at 432 MHz, yet it does not acknowledge what that driving the panel at 16% faster clock may result into at all, from 16% higher power drain due to every userspace app having to render at 70 Hz, to stutter of video playback or UI stutter in systems that don't derive all timing from the display (eg. if input is read at 60Hz and output is done at 70Hz this can really mess up the UI feel) to behavior on borderline panels.
Panel clocked at higher than expected frequency may not complete the required LCD dicharge process correctly/completely due to compressed time (and this error may accumulate over several power on/off cycles), because it works with different than expected timings to complete a fixed physical process. (partly speculating here - what I know for sure is that this issue that causes flickering accumulates over several power on/off cycles if poweroff is done wrongly)
In any case, for my kernel I prefer 60Hz and underlocked PLL (works on all my 5 pinephones) so I revert that 500 MHz PLL limit in my kernel and run the panel at specified frequency. I don't see any flicker issues on my devices other than during development/hard poweroffs, etc..
"There were several pinephone HW revisions that fixed HW issues based on direct developer feedback... So communication to get HW changes was possible, and was usually via TL Lim, not via HW devs."
That's great, but that wasn't my experience as an ordinary buyer of the PinePhone who wasn't on the special developers list and had no way to communicate with TL Lim. PINE64 provides no way for an ordinary user to register a bug report about the hardware in the PinePhone.
When I added the "PinePhone component list" page to the PINE64 wiki (https://wiki.pine64.org/wiki/PinePhone_component_list), I noticed several errors in the schematics. See: https://amosbbatto.wordpress.com/2021/12/10/comparing-l5-and...
Since PINE64 didn't provide a way for me to register a bug report about it, I listed those errors on the wiki page. Instead of fixing the schematics, every mention of errors in the schematics was deleted from the wiki by user "Kx" on 2023-12-24. My questions on the PINE64 forum about how to get the schematics fixed were never answered. I don't blame PINE64 for the wiki edits, since I assume "Kx" was just someone in the community who didn't like seeing that there were errors in the schematics. However, the fact that PINE64 doesn't have a public bug tracker for its hardware issues is frankly an indication of problems with the way the company was run in my opinion.
"Accurate statement is that some perhaps critical work stayed out-of-tree, partly by choice and partly due to upstream rejections or dependencies, and not that "the volunteers generally didn't upstream." The claim is overstated to the point of being misleading."
I did some web searches and see that there were more commits to mainline Linux than I thought. I will edit that part. However, there was a marked difference between Purism and PINE64 in this respect.
"The article says PPP "still had major software problems when its sales were cancelled in August 2025.". Yeah, no. Pinephone Pro has almost full kernel support, multiple bootloaders, even graphics/touch support for U-Boot, etc. There are no SW kernel issues that I'm aware off that were not solved years ago."
I don't own a PPP, so I was going off what is listed on the PPP PINE64 wiki, which lists: Bootloader (critical bugs), Stability (WIP), Suspend (Experimental), Updates (WIP), Phone (WIP), MMS (WIP), LCD (WIP), Rear camera (WIP), front camera (WIP), camera flash (critical issues), Bluetooth (WIP), GNSS (WIP), Sensors (WIP), Keyboard add-on (WIP), Qi Wireless (WIP), LoRa (not implemented), Fingerprint reader (not implemented).
Is the wiki wrong? I held off on buying the PPP for years waiting for those issues to be resolved, and I saw little progress on getting those problems solved since many of the high profile volunteers left in 2022.
"As for the company: Pine64 promissed 10 years of original Pinephone."
The PP FAQ says: "he PinePhone (and parts for them) will be produced and sold for at least 5 years." https://pine64.org/documentation/PinePhone/FAQ/
"Sooo. what HW support is lacking on Pinephone, Pinephone Pro or PineTab2 or Pinebook Pro, or other consumer products, if you take some downstream maintained kernel and use it? You'll find that very little of consequence is missing."
The PineTab2 wiki says that Bluetooth doesn't work, WiFi can't be reset, so device needs to be power cycled. The camera drivers need to be ported, The Rockchip CSI/ISP driver needs to be extended to handle 2 lanes. Suspend does not currently work reliably, so suspend has been disabled.
"Performance is not really relevant to "level of SW support"."
In the case of the A64 in the PinePhone, its GPU for hardware acceleration is pretty weak, and there is no ISP and aDSP, and the VPU's hardware encoder only includes H.264 video, so I don't think SW support was really holding back the performance of the cameras and the speed of the interface. There are other SoC's where proper SW support is a more relevant issue holding back performance.
I changed the text from:
Purism chose to upstream their changes to mainline Linux, whereas the volunteers working on the PinePhone's kernel generally didn't.
To:
Purism generally chose to upstream its changes to mainline Linux, whereas the volunteers working on the PinePhone's kernel were less consistent about upstreaming their changes.
I also added a postscript note at the bottom of the article thanking you for pointing out that you had submitted more upstream to mainline Linux than I thought, and linked back to this conversation.
Yes, the feedback that would tend to get addressed was always related to actual HW issues, and the issues listed in your blog article seem to all be failry superficial without any effect in practice. Eg. eMMC and DRAM is a commodity, various phones batches likely got different components based on what was available. I know for sure that my pinephones have different eMMC chips from different vendors that have different real speeds, so got to 78 MiB/s at DDR52 some just to 50-60 MiB/s, etc. DRAM will probably be a similar case just based on the fact that some phones got 2GiB and some 3GiB on the same PCB.
"I don't own a PPP"
Yes, wiki is not uptodate. There are several bootloaders available, from levinboot https://xnux.eu/log/103.html to u-boot with display support and graphical menu, there are small tools like rk2aw that fix the HW issue with charging from discharged battery (bootloaders fix it too to some extent), etc. Suspend is not experimental, never really was. It was working from the beginning, because it was implemented by Rockchip for google RK3399 chromebooks or whatever. LCD works. Cameras work and ISP is fully supported since like 1 year after release, and 0 days after release for ISP. Camera flash works, but should not be used for extended period of time, due to overdriving the LED. Dunno what bluetooth issue would be about, it's part of WiFi chip and supported mainline. GNSS fully works just like on Pinephone, since it's the completely identical thing part of EG25-G modem. Sensors fully work. Keyboard add-on is supported mainline, with out of tree policy manager for managing dual battery power if you like. Qi/LoRa are I know nothing about, and are just back-covers unrelated to PPP in particular. Convergence works well, including HDMI audio. Fingerprint reader was a user backcover project, that got some help from Pine 64 IIRC, and would be an insecure toy anyway. There's basically nothing missing on the kernel/low-level side of things that would be a show-stopper for anything I can imagine doing, except for video encoding acceleration. But that's just a lack of upstream consensus how to even create a kernel api for it. It's not really pinephone pro specific issue. There's no lack of upstreaming attempts for this over the years. There will be no encoder drivers upstream for any stateless encoder HW accelerators, until there will be consensus. Downstream kernel can have encoder in a few days if someone wants it.
Pinetab2 wiki is not accurate either. You'd be better off looking at pages of distros you'd like to use that support the device. Support level is always determined by the distro anyway.
As for GPU acceleration. SW support is absolutely key, especially on older GPUs. If you optimize for those you can have very snappy UI for pretty much any imaginable smartphone functionality with imperceptible latency even on original Pinephone with maybe one exception, and that is web browsers. Those are just so bloated these days it's ridiculous.
Normal distros and Android have extremely bloated architecture, so things get slow and heavily dependent on storage load times. I know for sure that original Pinephone GPU is fully capable moving those few UI pixels typical mobile UI has at 60 FPS with barely any dips even at reduced CPU/GPU/DRAM frequency to save power without any sweat. Things need to be done differently though.
If that is the case, the PINE64 wiki really needs to be updated. I never bought the PineTab2 and PPP due to what is listed on the wiki.
Central support status matrix pages are futile for Pine64 devices. You can have perfect kernel/bootloader support and any chosen distro can still be unusable, because of lacking userspace integration. And there are maaany distros. And some pick and choose kernel patches, and fix/break various things. Some distros also disown bootloader support, so whether something will work or break depends on what bootloader user runs, etc. etc.
There's plenty of outdated info everywhere. Users should just ignore anything status related that's apparently old. And that wiki page was last updated 3 years ago or so.
if European governments/banks keep relying on safety verification supplied by American Google and Apple then no, they don't stand a chance
you can stop using US Visa/MC cards, but it's kinda pointless if you EU bank app still requires verification from US Google/Apple for app to run
I wish European govs would stop requiring Google Play services in Android phone and provided their own solution
The European Network for Payments (ENP) was announced last month as a challenger to the Visa/Mastercard duopoly. Time will tell, I guess...
that't not challenger to Visa/MC at all, it doesn't issue any cards, it is just different name for existing instant wire transfers which you can do also through QR code through whatever banking app you use, nothing to do with some "European Network for Payments (ENP)"
that's like saying I have new solution to wheel, which will be called European circle, it will be the same wheel we already have, but under the new fancy EU name!
I still have a drawer full of OpenMoko. A couple Creative Labs Zii Eggs. Some OpenPandora, and even a hacked up FairPhone, donated to my parts bin, non-working.
I sure wish the Zii Egg had made it out of prototype stages. It showed the most promise - a bare-metal Linux OS, multiple cores, very, very easy to write apps for it - just plain C/C++ really.
Linux phones never happened because the distro's constructed for them were overly complicated, unnecessarily encumbered with 'smart features', and just generally (imho), sabotaged by the cult of collective development. Its the sort of project that requires a BDFL pushing things forward - none of the failed Linux phones ever had that.
These days, I'd rather see someone produce an ESP32 phone with LoRA and maybe SDR, and leave it at that.
But, there is another issue. The modems. It is always the modems. Until someone courageously open sources the modem chip and its firmware, there is no hope.
Yes, as the owner of a Librem 5, I can attest that getting the Qualcomm modem in the BroadMobi BM818 has been one of the pain points, and it is very hard to diagnose the problems.
Funny how this entire comment section is full of people who have never used anything but ios or android. Not sure if it's just all bots, or if even HN is just full of NPCs nowadays. Glad to see the fanboys are finally agreeing on something though! >_<
there is Jolla.
https://jolla.com/
No
Android is linux.
Only the userland is some java based abomination... well was a long time ago, maybe after all those years, the android userland has a minimal set of simple binary interfaces and simple file formats, which I could even code reasonably code directly in assembly (this is the benchmark).
Something is wispering to my hears: "nooo! there is no such things as minimal system interfaces and file formats on android linux". Wrong?
If the only parts the user can access are highly qualified, restricted portions of the OS, a/o a non-Unixlike UI, does it really matter that Unix technically underlies Android?
The level of this answer left me with no other choice:
Are you an AI chat bot?
A glance at my history would disprove that theory.
No
I am not sure but the less power Google has, the better. I am getting tired of those Trump milking machinery leeching off of others - we already see how Trump treats Ukrainians. The ultimate agent Krasnov, just as Yuri predicted in the 1980s already: https://www.youtube.com/watch?v=5It1zarINv0
Now with people decompiling and recompiling apps for different platforms and how fast coding has gotten with AI, spinning up a Linux phone platform is much more achievable now. That wasn't true a year ago.
No.
Android is Linux
Google already put in the resources to make a Linux phone viable and they released a lot of that work via AOSP.
Android is Linux.