[3 of 5]
> It won’t be an easy task, because each time Google releases a new version of AOSP, these volunteers will have to rip out the anti-user features in the latest version and replace that code with user-empowerment features. Because Google makes substantial changes to Android every year, the user-empowerment code will likely need to be refactored every year to work in each new AOSP release.
Would be nice if you would be able to give examples of those anti-user features and examples of desired user-empowerment features. New Android versions and SDK levels often bring security and privacy improvements. The permission model has evolved a lot over time and has only evolved to give the user more control over their applications.
> Google is actively rewriting its Android code in Rust to eliminate memory safety vulnerabilities and speed up its software development.
Sounds amazing. What is the issue with this? Do they need to go slow on making the system more secure in order to make it easier for external contributors? Do you think that it would be a net-positive to deliberately slow down taking up Rust?
> The important point is that Phosh is already a very solid interface and the tweaks that it needs are minor compared to the significant dev work that AOSP will require to make it an operating system that respects and empowers users. Even in the case of Plasma Mobile, the dev work that it requires is far less than AOSP would require. The work to improve the Phosh and Plasma Mobile interfaces is a one-time cost, whereas the code churn in AOSP will make it a constant struggle to keep reapplying changes with each new version that gets released by Google.
AOSP respects and empowers users much more than traditional Linux due to the proper security and privacy model, as I mentioned before. Trying to add something similar to Linux would be a very resource-heavy task and will break compatibility with a lot of apps because those are written with the expectation of having wide access to your system. So, you would also have to rewrite those apps, which would make it even more resource-heavy.
> As more and more Android apps become incompatible with the community’s AOSP fork, fewer people will be willing to use it.
If this hypothetical scenario that you've been painting in your blog post would happen then it's likely that the large FOSS ecosystem of Android apps will target the community AOSP fork instead of the hypothetical closed source Google Android. There are lot of FOSS Android apps, which can compete with the traditional Linux app ecosystem and even outcompete it for various app categories.
> Linux users are less likely to install rogue apps, because they can’t just find any random Linux software package on the internet and install it, like they can with random APK files found on the internet.
Many people use the AUR. An app being available in a package manager or on FlatHub doesn't mean it's well written or well maintained. And, nobody forces you to grab APKs from random sources, you can stick to reputable app stores or to the official websites and repositories of developers you decide to trust.
> However, Linux phones will need to be able to install Android apps if they are going to appeal to the mass market.
This seems to undermine most of the point you are trying to make.
> It won’t be an easy task, because each time Google releases a new version of AOSP, these volunteers will have to rip out the anti-user features in the latest version and replace that code with user-empowerment features. Because Google makes substantial changes to Android every year, the user-empowerment code will likely need to be refactored every year to work in each new AOSP release.
Would be nice if you would be able to give examples of those anti-user features and examples of desired user-empowerment features. New Android versions and SDK levels often bring security and privacy improvements. The permission model has evolved a lot over time and has only evolved to give the user more control over their applications.
> Google is actively rewriting its Android code in Rust to eliminate memory safety vulnerabilities and speed up its software development.
Sounds amazing. What is the issue with this? Do they need to go slow on making the system more secure in order to make it easier for external contributors? Do you think that it would be a net-positive to deliberately slow down taking up Rust?
> The important point is that Phosh is already a very solid interface and the tweaks that it needs are minor compared to the significant dev work that AOSP will require to make it an operating system that respects and empowers users. Even in the case of Plasma Mobile, the dev work that it requires is far less than AOSP would require. The work to improve the Phosh and Plasma Mobile interfaces is a one-time cost, whereas the code churn in AOSP will make it a constant struggle to keep reapplying changes with each new version that gets released by Google.
AOSP respects and empowers users much more than traditional Linux due to the proper security and privacy model, as I mentioned before. Trying to add something similar to Linux would be a very resource-heavy task and will break compatibility with a lot of apps because those are written with the expectation of having wide access to your system. So, you would also have to rewrite those apps, which would make it even more resource-heavy.
> As more and more Android apps become incompatible with the community’s AOSP fork, fewer people will be willing to use it.
If this hypothetical scenario that you've been painting in your blog post would happen then it's likely that the large FOSS ecosystem of Android apps will target the community AOSP fork instead of the hypothetical closed source Google Android. There are lot of FOSS Android apps, which can compete with the traditional Linux app ecosystem and even outcompete it for various app categories.
> Linux users are less likely to install rogue apps, because they can’t just find any random Linux software package on the internet and install it, like they can with random APK files found on the internet.
Many people use the AUR. An app being available in a package manager or on FlatHub doesn't mean it's well written or well maintained. And, nobody forces you to grab APKs from random sources, you can stick to reputable app stores or to the official websites and repositories of developers you decide to trust.
> However, Linux phones will need to be able to install Android apps if they are going to appeal to the mass market.
This seems to undermine most of the point you are trying to make.