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 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/
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
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 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.
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.
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.
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.
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).
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.
> 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.
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 milisecond 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. :)
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
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)
- 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.
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.
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.
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)
> 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.
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 and you can access your "phone" from any other computer that has internet access.
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.
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.
> 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.
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".
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 don't see any problem with my reply. My idée fixe is not replying but freedom, and whenever people suffer from lack of it and it's possible to fight back, I suggest something.
If you just look at the whole thread, you'll see a higher-level comment noting that in some countries, all banks require the same proprietary Android, and so no, "switching banks" is not a solution. Your suggestion was tone-deaf as it so often is.
You are probably right, although a number of Europeans on HN confirmed that it's possible to fix this by switching banks. Thanks for the remark. It would be helpful if you could name the country, so I (or somebody else) could verify or disprove your claim.
Really? I have yet to see an app that doesn't work with adb/scrcpy, even the ones with google attestation. Worst case, I suppose it's time for a camera pointed at the screen and a plotter with a stylus. (Until they start watching the front camera lol)
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 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.
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.
> 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.
>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.
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.
> 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 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 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.
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.
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.
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)
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.
“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.
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
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 payment 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.
> 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).
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.
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
> 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.
"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
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.
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.
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.
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.
> 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 does 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
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.
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.
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.
that't not challenger to Visa/MC at all, at 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!
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 :-).
Even more so, it is the closest to Inferno's design, which was the evolution the UNIX founders went through.
Like they created UNIX, that 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.
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.
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.
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 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.
277 comments
[ 0.26 ms ] story [ 37.3 ms ] threadAnd 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?
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.
This one of the most understated reasons.
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.
Well, I won't go into details today, maybe later.
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.
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.
What is difficult is e.g. supporting the undocumented photo/video camera and other essential parts of the hardware that lack documentation.
You need a stack that is designed from first principles for phones. Luckily we have one that is open source (AOSP).
It's not a technical problem, it's a social one (for the apps/programs)
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
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
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
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!
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.
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?
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).
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.
Spoiler: I have :-)
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 milisecond 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. :)
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
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)
- 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.
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 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.
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)
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.
Must be why Desktop Linux has great usability right? Oh wait
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.
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 and you can access your "phone" from any other computer that has internet access.
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
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.
Like IP address and location?
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.
That's not the Android experience, that's the Google experience.
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.
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.
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.
And you think that this is fine? I will fight for my rights for one.
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.
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.
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 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
Most of the apps on Android and iOS aren't necessarily useful.
> StrongBox keystore provided by secure element
https://grapheneos.org/faq#future-devices
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.
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.
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.
This is what genuine competition is and drives things forward.
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.
“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.
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.
That logic doesn't follow. This is bad in all meaningful ways for open source.
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.
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
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
And millions of Chinese bash it everyday.
hey apple, when are we getting expanded memory, maybe better battery? oh we're still stuck under 4000mAh, cool cool cool
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.
> 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).
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
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.
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
In fact, it is a competitor against both iOS, Android and Linux-based devices.
[0] https://en.wikipedia.org/wiki/HarmonyOS
I assume it requires some mind of Android compatibility layer that won't pass Play Integrity checks..
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.
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...)
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.
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...
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 does 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?
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.
https://truthsocial.com/@realDonaldTrump/posts/1174061766043...
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...
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.
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
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!
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.
- 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 :-).
Like they created UNIX, that 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.
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.
> 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.
- 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...
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...
Or that isn't the case and this is all just a silly comparison.
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).
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.
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.
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.
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.
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.
Reminds me of those dudes who think a terminal console with broken bluetooth is sufficient to make a macOS Linux distro competitor.
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.