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