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.
HarmonyOS (especially meaning Huawei phones) is pretty much dead outside Europe, 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
- 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.
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?
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.
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.
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 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.
> 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.
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.
“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.
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 :-).
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.
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.
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
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.
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.
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.
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.
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 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 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.
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)
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.
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 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.
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.
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.
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
gojek too
go travel a bit
- 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.
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.
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.
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 *~~
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.
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.
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.
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.
Apple doesn't sell Linux powered devices, nor do I want that from them.
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.
Must be why Desktop Linux has great usability right? Oh wait
It's better than Windows 11 at least - though we probably can't credit that to improvements to the Linux DE
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.
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.
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.
- 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 :-).
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 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.
So a new phone means just moving the VM. The only unique thing my Android layer has to do is route the internet..
Every player in this space currently has this incentive imho.
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?
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.
Spoiler: I have :-)
https://unifiedpush.org/
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.
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.
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.
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 :(
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.
This one of the most understated reasons.
Of course it's more complicated than that, but it's not impossible, since the foundation is already there.
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.
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.
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)
Android is Linux.
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
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.