• ProdigalFrog@slrpnk.net
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 day ago

    I’m not entirely sure if that would be better than just adopting PostmarketOS, since forking AOSP would mean maintaining a fork of that entire ecosystem, and I’m unsure how they would deal with all the phone manufacturers dropping support for phones rather quickly, or using outdated kernels to access GPU and hardware drivers for said phones after the manufacturer drops support.

    Investing in PostmarketOS instead would bring with it much less stuff to fork, along with access to the mainline linux kernel (instead of outdated Android ones) that use open-source GPU drivers that can be effectively maintained, and it can support Android compatibility with a compatibility layer, Waydroid.

    A polished PostmarketOS ecosystem only seems to offer advantages compared to a forked AOSP, so if they’re choosing which to invest in, Postmarket seems like the clear winner.

    • matlag@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      2
      ·
      23 hours ago

      The kernel update issue on Android is going to be exactly the same for PostmarketOS and for the exact same reason: proprietary firmwares and/or drivers.

      There is a huge ecosystem for Android today, including apps for so many EU companies, that they would have to re-develop to port them to Linux, or they’ll just rely on Waydroid, so you still have to follow Google somewhat, and now you need to maintain both a GNU/systemd/Linux AND a compatibility layer with Android. With a fork of AOSP, you need only the last.

      From a security and privacy standpoint, Linux was never designed to handle hostile apps designed to aquire as much data as possible. Android has a sandboxing system: an app cannot go and check what other apps you have. A Linux app can pretty much access everything on your system. GrapheneOS adds on top of that storage and contact scopes: you can define a subset of each per app, and they won’t see anything else.

      In an ideal world, it wouldn’t matter: everything would be opensource and developed in good faith. In the real world, you still have tons of malevolent apps that people will want to use anyway, so better take that in account.

      • ProdigalFrog@slrpnk.net
        link
        fedilink
        English
        arrow-up
        1
        ·
        22 hours ago

        The kernel update issue on Android is going to be exactly the same for PostmarketOS and for the exact same reason: proprietary firmwares and/or drivers.

        That is not the case, as PostmarketOS uses community made open-source drivers, even for the GPU, and all devices that it supports uses the mainline kernel, as all of the drivers they develop are upstreamed to mainline, instead of it being a proprietary driver that is locked to a specific kernel.

        The open-source drivers aren’t currently as polished as the proprietary ones, but as we’ve seen the open-source AMD driver for desktop, it can become the best option with community effort and funding.

        and now you need to maintain both a GNU/systemd/Linux AND a compatibility layer with Android

        The point of adopting Postmarket is that they could then rely on the open-source community to help with maintaining most of of the components, much like how Linux desktop or Linux Server works currently. Waydroid is developed by its own team, so they wouldn’t need to fork that and maintain it to have access to Android apps (though they could help contribute to it if they wanted to).

        From a security and privacy standpoint, Linux was never designed to handle hostile apps designed to aquire as much data as possible. Android has a sandboxing system

        Android is Linux at the core, yet it was able to be hardened, which shows that PostmarketOS could be similarly hardened if such features were adequately funded and developed by the EU. Linux already has Wayland, which is a huge step forward for security, and Flatpak packages already have Android-like permissions built in (though they would need to modify how those work by default to increase security).