Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Despite Android's success the rest of the consumer Linux distributions chose to ignore it and continue on with what they were already doing. Trying to have them coordinate around what is succeeding is seemingly impossible.

I'm not sure I understand you here. What do you think other Linux distros should have done?



>What do you think other Linux distros should have done?

Collectively contributing to getting AOSP running on desktops, and then also working on backwards compatibility to be able to package their preexisting apps into Android apps. This would allow for there to be a common app platform for developers to target Linux with.


> Collectively contributing to getting AOSP running on desktops, and then also working on backwards compatibility to be able to package their preexisting apps into Android apps. This would allow for there to be a common app platform for developers to target Linux with.

As a common target, AOSP isn't a very good one.

AOSP ran on desktops. (Maybe it still does, haven't tried it in a while.) It was still a mobile OS, though, so it wasn't good on the desktop, but it ran.

It also uses very old kernels.

Other than the kernel, the Android UI is completely different from conventional Linux. Any Gnome or Qt app would have to be completely rewritten to support it, and would probably have to run in the JVM.

Basically, if the Linux community followed your plan, they would have to commit a huge effort to port everything to what is essentially a completely different, incompatible OS in every respect except the kernel, and their reward would be to live in subservience to the whims of Google in supporting their product which Google themselves never had enough faith in to make it a proper desktop OS. It seems that the benefit does not justify the investment.


>so it wasn't good on the desktop, but it ran.

Which is why it would benefit from people who are trying to optimize it, and extend it to offer a good desktop experience.

>It also uses very old kernels.

It's based off the latest LTS release of the kernel.

>Any Gnome or Qt app would have to be completely rewritten to support it

Which is why my comment said that distros would work on backwards compatibility to avoid such expensive work of requiring a complete rewrite amd try to make it as seamless as possible.

>and would probably have to run in the JVM

Android does not use the JVM. It has ART, the Android Runtime, but you can still use native code.

>and their reward would be to live in subservience to the whims of Google in supporting their product which Google themselves never had enough faith in to make it a proper desktop OS

The benefit is being able to reap the fruits of the billions of dollars Google's is investing into the OS. Along with compatibility with a large amount of apps. As a bonus staple Linux applications may be able to installed to some of the billion existing Android devices today. Google may not have seen the benefit of supporting the desktop, but that's where smaller players can come in to play a role in trying to focus on more niche markets where there is less possible return.


I don't think Android is a good platform for desktop usage. First the windowing system, and the IPC mechanism. They are very limited. And one of the nice aspects of desktop computing is the ability to alter it for your own purposes (something that MacOS is running away from). Meaning you extend it for some other domain, think music production, video production,... Where you want to hook it to some hardware and have the software to talk directly to the latter. Which means having access to all the ports and coding bespoke protocols. I don't think current android API allows for that.


>They are very limited.

Sure the windowing is limited, but it could be extended. I disagree that the IPC is limited though.

>Which means having access to all the ports and coding bespoke protocols. I don't think current android API allows for that.

It's still all open source. The distros could add new APIs to expose new capabilities.


> The distros could add new APIs could be added to expose new capabilities.

Those exist already. With Debian, Alpine, Fedora,... you can put anything on top of the kernel in the userland. Android goes with a restricted version.

It's the same with MacOS. It's Unix, but with proprietary add-ons and systems. And lately, with more restrictions.


How does those existing make Android not a good platform? I don't fully understand the point you are trying to make.

By restrictions do you mean having proper capability based security instead of letting all apps have access to everything? These restrictions are a good thing.


Limited userland and limited access to it. Sandboxing may be good, but the user may need some software that needs to escape it. Fedora Silverblue is a promising direction, but interacting with the base system is currently a pain.


90% of the problems Linux has had in the last 10 years are due to trying to unify desktop UI with mobile. This is fundamentally a mistake and it is critical to avoid it.


> 90% of the problems Linux has had in the last 10 years are due to trying to unify desktop UI with mobile.

To be fair, Apple and Microsoft have also failed to try to unify desktop UI with mobile.


Yeah, but they have enough other failures that this one alone can't reach 90%.

Linux has had other major dramas but not failures.


A lot of effort went into Android x86.

As far as I know Google has never accepted patches into Android, so everything has to be maintained outside the project in parallel, which helped kill it.

Google is not your friend, and they will not work with you. Android has diverged several times, and they break everyone else without caring.


Long before Android existed, they could’ve all agreed to have the same single desktop environment, UI toolkit, app packaging and distribution method, etc. And also agreed to ship drivers, even if proprietary.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: