Remix.run Logo
▲ microtonal 4 hours ago

No, they won't become a viable alternative:

- Worse compatibility with the millions of Android apps already out there.

- Hardware vendors (outside Apple) all target Android.

- The usability of Android/iOS is far better than non-Android Linux phones.

- The security of non-Android Linux phones is in a bad state (e.g. lacking proper app sandboxing). Heck, even the Android emulation layers that some of these phones have, throw the strong Android sandbox model out of the window.

The answer is very obvious and it is AOSP. Even though Google is trying to close AOSP more (e.g. by not pushing source continuously to the AOSP Git repos and keeping QPR1/3 for themselves), it is still an open source system. Play Services can either be run sandboxed or emulated with microG. AOSP allows alternative systems to hit the ground running, you get great app compatibility, a tested security model, great usability, and support from hardware vendors, including vendors that are alternative friendly (used to be Pixel, now Motorola, Fairphone, etc.). If ever needed, AOSP could be forked and it would still be leagues ahead of non-Android Linux phones.

All the downsides that apply to AOSP-based systems (like things getting blocked by Play Integrity, unlockable bootloaders) also apply to non-Android Linux systems.

▲apatheticonion 4 hours ago | parent | next [-]

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.

▲microtonal 3 hours ago | parent | next [-]

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.

▲apatheticonion 3 hours ago | parent | next [-]

> So, where are the super-polished Linux systems for the Fairphone?

It still has tiny market reach. Very few people are going to invest the time needed to build a quality user experience for like 1000 users.

Just imagine what would happen if Linux could be installed on the iPhone. There would be SteamOS distributions within an hour of the announcement.

> It’s funny that you mention Waydroid. It throws most of Android’s strong security model out of the window.

Haha yea, it's more an example of capabilities that could be rolled into highly polished user experiences. Again, if Linux could be installed on the iPhone - I'm certain Waydroid maintainers would shut the project down from PRs.

~~* competition *~~

▲microtonal 3 hours ago | parent [-]

It still has tiny market reach.

You are moving the goalposts, you said:

The lack of polish is a function of the inability to use the hardware. The hardware is tightly gatekept so competition _cannot_ exist. [...] Once we can actually target the hardware, open source alternatives will be much better than first party options.

So, it's not the hardware gatekeeping that is the issue, it's that nobody is polishing the experience for hardware that already exists and qualifies. The hardware can also be purchased very easily in some regions (e.g. Europe). I can literally hop on a bike right now and pick up a Fairphone in ten minutes. I know that it's different in e.g. the US, but Murena has been selling them in the US for years now.

▲monegator 2 hours ago | parent | prev | next [-]

who exactly owns a fairphone?

Now, if we had support for say, a pixel, that would probably change things. Incidentally, there seems to be initial support for the tensor G5 (pixel 10 onwards)

▲fsflover 3 hours ago | parent | prev [-]

How many years did it take to make a well-polished DE on desktop Linux? How large was the community doing that and how many devices did they have access to?

▲microtonal 3 hours ago | parent | next [-]

The difference is that there is already a great open source smartphone OS that works today, it’s AOSP.

The most effective path would be for the FLOSS ecosystem to pour their resources into making AOSP independent from Google. But instead people will just fork N half- or non-working solutions for reasons.

▲Quartzium 3 hours ago | parent [-]

>OS that works today, it’s AOSP.

But you have no guarantee what happens tomorrow with it, depending on what Google feels like. You just have to eat whatever Google decides.

With Linux there's no such centralized control. So the time and effort will pay out later on down the road. Let Google have its AOSP.

▲microtonal 2 hours ago | parent [-]

This comes up every time, I just don't understand the argument. You can fork AOSP when that happens. It will still be far less work than bootstrapping a viable open source alternative from scratch. Also maintaining a forked AOSP would be less work than getting the Linux desktop stack on the same level as AOSP.

Given that Android apps target old API levels, it would also stay compatible for years and nothing would hold you from implementing APIs from the docs.

To be honest, I don't think AOSP will fully close up, since Google probably fears the regulatory pressure and the fallout from vendors. The larger risk is Play Integrity, but that applies equally to other Linux systems if you want to tap into the large Android app ecosystem. But the solution for that is not technical, the EU and other regulatory bodies should make forbid it in its current form due to anti-competitiveness.

▲neobrain 38 minutes ago | parent [-]

> This comes up every time, I just don't understand the argument. You can fork AOSP when that happens

Hacking on the Linux stack is several orders of magnitude more practical than AOSP though. AOSP's build system is massively unwieldy for individual contributors to work on. You can't easily work on any of the system components without dedicating >100 GiB of storage for a build, for example. Everything is scattered across hundreds of repositories tied together with a bespoke repository management tool.

This all works for a company equipped with entire build infrastructure teams, not for a grassroots project trying to keep up maintenance with (at best) limited funding. It's why Nura (fka postmarketOS) is a thing whereas the various AOSP forks barely ever modify the core experience.

▲pjmlp 3 hours ago | parent | prev [-]

About 5 years, Mandrake and SuSE with KDE around 1996 were already quite good.

Since then the problem has always been the same, rebooting the DE experience for the sake of it, desktop environment wars, rebooting the development stack from GNOME and KDE, and the problem that despite all OEMs have Linux running on their data centers, the community has to reverse engineer the hardware from the same OEMs.

▲microtonal 2 hours ago | parent [-]

Yeah, I think people are underestimating how good and competitive the Linux desktop was in the past. Around ~2000 there was a lot of excitement around the Linux desktop, the Linux desktop was pretty mature, especially compared to the tire fire that Windows 9x was at the time (that changed when the NT branch moved to the consumer with XP). There were very user-friendly installers like Caldera OpenLinux (best feature was that you could play Tetris during the install) and Corel Linux. Also a lot of large vendors were making Linux desktop apps, e.g. Corel Wordperfect and Borland Kylix (which was Delphi for Linux). Heck, even Microsoft Office ran almost perfectly with CrossOver.

But yeah, then there was the constant forking, preferring rebooting development over iterative improvement (e.g. GNOME 2 -> 3 was really a hard cut for a lot of people, resulting in forks that exist till this day), hostility towards closed-source applications (you can hate them as much as you want, but people are not abandoning Photoshop/Illustrator for GIMP/Inkscape on a whim), etc.

Hopefully something changes with all the government-driven sovereignty desktops that are popping up, the resulting influx of money, and KDE EV et al. becoming very mature organizations.

▲fsflover 2 hours ago | parent [-]

By such measure, GNU/Linux phones are already quite good. I use Librem 5 with Phosh as a daily driver, and it is really just fine. Except the battery life, app compatibility and smoothness of the UI.

▲johnnyanmac 4 hours ago | parent | prev | next [-]

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.

▲apatheticonion 3 hours ago | parent [-]

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.

▲pjmlp 3 hours ago | parent | prev | next [-]

One could do just like everyone else and buy the specs from OEMs, instead of trying to reverse engineer.

Yes it won't be pure religious FOSS with 100% open, so what.

Also this is the future for laptops as well, for those that keep repeating the mantra of ARM/RISC-V replacing x86/x64 architectures.

▲apatheticonion 3 hours ago | parent [-]

Do you get that on the Apple App Store?

▲pjmlp 3 hours ago | parent [-]

No, and why should I?

Apple doesn't sell Linux powered devices, nor do I want that from them.

▲apatheticonion 3 hours ago | parent [-]

> nor do I want that from them.

This perspective I can't wrap my head around. Like I get that you wouldn't use it, and that's fine - but if Linux was available and we made it incredible, that would push Apple (and Google) to do better. So you'd get a better MacOS / iOS by proxy.

Like, don't we want competition? What motivates people to desire an unchallenged status quo?

▲pjmlp 3 hours ago | parent [-]

Those that want to sell Linux powered phones should make their own stores, and folks like yourself should support them, when they do open such stores.

▲sublinear 2 hours ago | parent | prev | next [-]

I have a genuine, but maybe stupid/trivial sounding question. Does anyone successfully run cloud instances of Waydroid so that their physical phone is a dumb client?

I've been thinking about it for a long time, but it seems like such a privacy risk even when self-hosted. The massive upside is that the phone is just a VM. The idea makes the entire phone debate irrelevant since you can access your "phone" from any other computer that has internet access. If the connection is lost, the local device can always sync later or at least provide basic call/text functionality.

▲raverbashing 3 hours ago | parent | prev [-]

> The lack of polish is a function of the inability to use the hardware

Must be why Desktop Linux has great usability right? Oh wait

▲monegator 14 minutes ago | parent | next [-]

it really does though

▲apatheticonion 3 hours ago | parent | prev | next [-]

Haha, shots fired.

It's better than Windows 11 at least - though we probably can't credit that to improvements to the Linux DE

▲red369 3 hours ago | parent [-]

I am often finding things I prefer about one of the OSs (or Desktop Environments in the case of Linux) that the others don't have. I can usually see how people prefer any particular one over the other.

The usual suspects are the keyboard support in Windows (enabling the extended keyboard navigation in MacOS made some apps act very strangely), and most of the look and feel of MacOS. There have even been things I really liked in ChromeOS.

Obviously there are many nice touches in the big Linux DEs, and I would rather be in KDE Plasma than anywhere else. Because of this, I'm generally not surprised when I encounter something that is done better than Windows or MacOS.

However...!

Yesterday I was editing filenames in the file browser, and accidentally navigated down to the next file in the folder - still in filename editing mode! It was a feature I didn't even know I wanted. Suddenly, I could edit a whole list of files, just as if it were rows in a text file. Now it's Monday, and I'm back in Windows. I am unlikely to need to use that feature, but still wish I didn't know what I was missing.

▲WindyMiller an hour ago | parent [-]

> Yesterday I was editing filenames in the file browser, and accidentally navigated down to the next file in the folder - still in filename editing mode! It was a feature I didn't even know I wanted. Suddenly, I could edit a whole list of files, just as if it were rows in a text file. Now it's Monday, and I'm back in Windows. I am unlikely to need to use that feature, but still wish I didn't know what I was missing.

In case you do ever need it - you can do this in Windows with the tab key.

▲LtWorf 2 hours ago | parent | prev [-]

This tells me you haven't tried it in the past 20 years

▲drnick1 3 hours ago | parent | prev | next [-]

> 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.

▲arcanemachiner 11 minutes ago | parent | next [-]

It works for you, but I doubt your experience and needs are typical of a normal smartphone user.

I also run LineageOS with no Play Services (and have for years), but it is missing some pretty noteworthy stuff: Google Maps, Google Pay, etc.

▲TFNA an hour ago | parent | prev | next [-]

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.

▲neobrain 33 minutes ago | parent [-]

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.

▲microtonal 2 hours ago | parent | prev | next [-]

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".

▲ta8903 an hour ago | parent | prev [-]

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.

▲norman784 an hour ago | parent | prev | next [-]

> Worse compatibility with the millions of Android apps already out there.

Most of the apps on Android and iOS aren't necessarily useful.

▲opengears 3 hours ago | parent | prev | next [-]

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.

▲commandersaki an hour ago | parent | prev | next [-]

Do any Linux phones or even GrapheneOS phones have a secure enclave/TEE?

▲Telaneo 7 minutes ago | parent [-]

GrapheneOS requires it.

> StrongBox keystore provided by secure element

https://grapheneos.org/faq#future-devices

▲pilooch 3 hours ago | parent | prev | next [-]

Apps may just well go away with llms and agents.

▲NamlchakKhandro 3 hours ago | parent [-]

only if tokens are 100% free 1000tps prefill and generation

▲preisschild 2 hours ago | parent | prev | next [-]

> 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

▲Quartzium 3 hours ago | parent | prev [-]

>The answer is very obvious and it is AOSP

I disagree. Working on AOSP with Google having so much control of it is just a waste of time. You have no guarantees what you are working for, in the future.

I'd go full Linux, the effort is worth it and will pay out in the future. Google has the AOSP project by the balls and it's a very high risk investing anything into it, as a developer.

With today's LLM tech might as well do something nice with Linux.

▲microtonal 2 hours ago | parent | next [-]

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.

▲ta8903 an hour ago | parent [-]

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.

▲preisschild 2 hours ago | parent | prev [-]

AOSP is effectively just a linux distro and can be forked just like desktop linux distros