This blog post is already quite long, so it will omit changes merged for Plasma 6.5 (releasing in October, to be announced in a future post).

With the Plasma 6.2 release, we moved Plasma Dialer and Spacebar to the Plasma release cycle, allowing us to have consistent releases of the two apps. This completes our year long move to having all Plasma Mobile related projects released as part of wider KDE releases, streamlining the work for distributions and taking a load off us on having to maintain a separate release cycle!

In other news, a Fedora spin for Plasma Mobile was released! It will only be targeting devices that can currently boot Fedora (i.e. not ARM phones), but is very exciting nonetheless!

  • balsoft@lemmy.ml
    link
    fedilink
    arrow-up
    12
    arrow-down
    1
    ·
    edit-2
    15 hours ago

    I’ve built and run Mobile NixOS on my OnePlus 6 (without modem, fingerprint or GPU accel support but meh) before it became officially supported (this was relatively easy, compared to most other vendors, but did require a bunch of hacking to get the Linux fork OnePlus provides to work with the Nix kernel compilation machinery and the NixOS userspace).

    I have also implemented initial support for running NixOS proper on Librem 5, packaged/fixed some stuff 1 2 3 (and more which didn’t make it to nixpkgs) to make it semi-daily-usable with Plasma Mobile, and daily-used it for a couple of weeks and then on and off for a couple of months.

    I know how mobile Linux works, from the bootloader to the kernel to the userspace to the DE to apps that run on it. I also have a cursory understanding of how Android works, enough to know that it’s not feasible to build “a base that replaces AOSP”, let alone make it work with vendor-provided driver blobs and proprietary Android apps (which is what you’re proposing?). What manufacturers actually do is take AOSP, patch it to fit their needs/work with their shitty drivers, and ship it on the device as a bunch of blobs because it’s Apache-licensed.

    • just_another_person@lemmy.world
      link
      fedilink
      arrow-up
      1
      arrow-down
      9
      ·
      14 hours ago

      You hacked out a bare running Nix config for a phone…cool. I wouldn’t call it an implementation of anything because all you did was hammer out configs, but good for you. Now you have a phone where half the hardware doesn’t work, but Nix runs, so super awesome for you. Must be a great user experience.

      Even in your comments on your link, you’re proving my point. Without a solid BASE, and a DRIVER LAYER, you won’t have a successful project to push a UI of anything, because packaging themall together doesn’t make sense. All the major phone vendors know this, and have moved in that direction for awhile.

      Why you came in here with your links to something that is literally saying the same thing as I am as if you are proving a point to somebody, I have no idea.

      • balsoft@lemmy.ml
        link
        fedilink
        arrow-up
        8
        arrow-down
        1
        ·
        edit-2
        13 hours ago

        all you did was hammer out configs

        Yeah, that’s my point, all the software is there already, with a little bit of persuasion and glue it runs fairly well together. I’m not claiming I wrote actual drivers or whatever. What I did was figured out how to adapt the existing software to work on NixOS, so you can just take your desktop NixOS config, add a couple lines to it, and run it on the phone.

        Now you have a phone where half the hardware doesn’t work

        All hardware on Librem 5 worked with NixOS as I expected. The reason I’m not dailying it anymore is because the hardware kinda sucks, it’s outdated and slow. If I could get the same software stack running on more modern hardware I’d gladly use it. Perhaps the battery life could be improved if the power management was better, but that’s about my only complaint software-wise.

        Without a solid BASE, and a DRIVER LAYER, you won’t have a successful project to push a UI of anything

        I’m not sure what you mean by “solid BASE”. Do you want to rewrite all of the existing software that implements the “desktop Linux” userspace? Who would be doing this and why, when existing stuff mostly works?

        “DRIVER LAYER” in the FOSS world is just Linux. Drivers can live in the Linux tree or as small patches on top of it, with common open interfaces allowing compatibility between software and hardware. Just like they have been doing on the desktop for the past 30 years. The problem is plain: there are no open-source drivers or documentation for most phone hardware. Vendors don’t have this issue because they have access to private documentation and the sources of proprietary drivers. Writing FOSS drivers requires reverse-engineering the proprietary drivers, which is very resource-intensive. The proprietary drivers that are there lock you into a particular Linux version (usually a very particular Linux version, and there’s no way to solve this with any driver layer, at least without sacrificing performance and resource usage) and sometimes have proprietary interfaces with the userspace as well, which aren’t easy to write a compat layer for (if that’s what you’re proposing). And in any case, if you are fine with proprietary stuff running in EL1, why not just run Android?

        All this is completely orthogonal to making a DE on top of open standards, which is the point of open standards. For hardware that works with (mostly) mainline Linux, desktop userspace with plasma-mobile/phosh on top work well enough already. For hardware that doesn’t, adding support is a lot of work, not because of any issues with the DE or userspace, but because hardware manufacturers don’t publish the driver sources.