1323
Hey, at least it's only a duopoly! (thelemmy.club)
submitted 6 days ago by to c/linuxphones@lemmy.ca
165 comments fedilink hide all child comments
 

after 15 years, iOS has finally caught up with all the main android features, such as

  • very mid ui design
  • kinda floaty feeling
  • unpolished vibe android itself has progressed little, although it is rapidly achieving feature parity with iOS on "locked down user hostility". overall both ecosystems look very appealing, energetic, and healthy, for shareholders

Source: https://mastodon.social/@jk/117314678878602994

A screenshot of a toot on Mastodon. I have copied and pasted the text by the Mastodon user in the body of this Lemmy post.
you are viewing a single comment's thread
view the rest of the comments
[–] 1 point 5 days ago (5 children)

https://docs.postmarketos.org/policies-and-processes/development/ai-policy.html

postmarketOS bans contributions written either entirely or in part by LLMs, so your contributions would be disqualified under those policies.

The Linux kernel, as far as I'm aware, does not have these same policies, so if your changes were to be mainlined, then the Linux kernel changes would then trickle down to pmOS, but your userspace programs/services would still not be able to be accepted upstream, nor would any of the non-mainlined kernel changes.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 0 points 5 days ago* (4 children)

    I know, which is why i'm not sending any to pmos.

    We are talking about the kernel here, and i am mainlining all my kernel changes, and many have already been mainlined.

    https://lore.kernel.org/all/?q=jorijnvdgraaf%40catcrafts.net

    I was asking why would the already accepted kernel patches need to be rewritten?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 3 points 5 days ago (3 children)

    The already mainlined kernel patches wouldn't need to be rewritten since they're already in the mainline kernel. I didn't see where you specified that before.

    But not all HWE is in the kernel. For example, your userspace VoLTE daemon is extremely useful for those who need VoLTE, but would not be able to be packaged in pmOS so other devices can benefit from it, since pmOS is the de facto mainline Linux distro for mobile (there are others, but pmOS is the largest and where most development is done). Same goes for your fingerprint daemon.

    There is, of course, also the ethical matter of using AI, as the pmOS page mentions, but balancing issues of pragmatism and principles have been a challenge in the FOSS community since the beginning (ex: "free software" vs "open source").

    On the last point about understanding the code, I feel you've shown that you are able to understand the code that you commit, or at least I hope that you do. I'm willing to take you at your word when it comes to that.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 5 days ago* (2 children)

    I agree with the points pmos makes but banning AI seems shortsighted imo, i know my userspace stuff won't make it into pmos. I see that as the choice of pmos and i will respect that, if someone wants to rewrite it fully by hand by all means do so its GPL but i won't do it as i don't see much point into it.

    I host an APK registry that people can point at, so other devices can make use of it if imsd supports them, which in theory yes any qualcomm modem should be supported but i haven't tested it either.

    I understand the code in the sense that i can read C and know what the problems and solutions are, but not in the full architectural sense, i am fully admitting that i must understand it better and that AI undermines this understanding.

    I will soon make a post about it.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 4 points 5 days ago (1 child)

    If you agree with the points, then how is the ban shortsighted? It's not like the ban can't be revisited in the future.

    While you do host a repo, pmOS device packages can't depend on imsd/fingerprintd/etc. since they're not in pmOS's main repo, so it adds extra steps for the end-user. I'm unsure if pmbootstrap supports building images with external APKs either, and if not, it would have to be done post-install.

    There is another problem that I haven't mentioned, and that is since your packages already exist, that demotivates other people from working on LLM-free code that performs the same task, even if it doesn't eliminate it entirely.

    If you do not fully understand the code you're working on in a deep, architectural sense, is that something you are willing to improve upon over time to the point where you will no longer need to use LLMs to code?

    I await your post about it, as I'm curious about your viewpoint, especially going more in-depth.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 5 days ago*

    Why i believe a hard ban is shortsighted is that it prevents real features like mine from being upstreamed.

    I agree its inconvenient that they are on my own repo, but either i rewrite it fully manually which i might do someday but i really don't have the time for now or pmos changes their rules.

    Willing? absolutely, but as i will say in my post, understanding a single subsystem of the kernel at a deep level is going to take a very long time, and i am working across all of them, one thing i understand on a deep architectural level is graphics programming, it has taken around i believe 5 years of making my own engine to truly understand it an expert level and even them im sure there is plenty of vulkan stuff i still don't know.

    Truly understanding the kernel at a expert level will take an equal amount of time.

    I have taken the decision that having an fully working capable linux phone with AI now is better then one done manually over 5 years.

  • permalink
  • fedilink
  • source
  • parent