this post was submitted on 22 Sep 2026
1293 points (98.8% liked)
Linux Phones
3928 readers
479 users here now
The Discussion on Linux-based Phones.
Benefits:
- Hardware freedom.
- Perfect operating-system competition.
- Full utilization of specs.
- Phone lifespan raises to 10+ years.
- Less e-waste.
Linux Mobile Distros:
- Sailfish🇫🇮
- Ubuntu Touch🇩🇪
- Postmarket OS🇨🇭
- Mobian
- Pure OS🇺🇸
- FuriOS🇺🇸
- Plasma Mobile🇩🇪
- LuneOS
- openSUSE Mobile🇩🇪
- Nemomobile
- Droidian
- Mobile NixOS
- ExpidusOS
- Maemo Leste
- Manjaro Arm
- Tizen
- WebOS
Linux Mobile Hardware:
- Fairphone 6🇳🇱
- Jolla Phone🇫🇮
- Volla Phone🇩🇪
- Shift Phone🇩🇪
- FLX1🇺🇸
- Librem 5🇺🇸
⚙️Contribute
🧼Go Clean From the Duopoly:
💻Related Communities:
📰News:
💬Messager:
⌚️Watch:
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
The Fairphone 6 and 6+ is something to keep an eye on, specifically with TheMightyCat's build of postmarketOS. It's almost fully functional with a close-to-mainline kernel, unlike Jolla phones and UBPorts, which both rely on Android kernels which will eventually stop being supported.
https://ani.social/u/TheMightyCat
For those interested.
Thanks!
It seems like TheMightyCat just generates code, which cannot be upstreamed to pmOS due to the policy on generated code.
Their generated code has been criticised by some kernel developers because of lack of quality. I think some sensors were accessed without using hexagonrpcd, which means battery usage will be unnecessarily high, which is an improper way of doing it.
Also, mainline kernel support is actively being worked on by Fairphone employees, which know the hardware best. All remaining features will be added in due time.
This is such an oversimplification and shows you don't understand how much work goes into this.
Again, any source for this argument with the hexagon processor? My patches has been plenty criticized by kernel developers, but so are fully manually written patches, which is the entire point of the kernel review process. Unless you seriously are saying that everyone on the list who has sent a v2 is a bad quality programmer.
When we were talking in DMs i again asked you for your source, reason, or any info for this so i can look at it and fix it if needed, but again you just result to throwing insults like you did in DM.
They are being added, by me, by nondescriptpointer, by Luca, by the people at Qualcomm. I have good contact with them for this. I don't understand your grudge against me.
I know how much work goes into it, I'm doing mainlining work myself. It's really a lot of work.
Also, I have NOT had any conversation with you via DM.
I doubt I would start a DM conversation with you now that you are publishing lies about this. 🙄
So far I had nothing against you as a person, but you are starting to change that rapidly.
Well i wrongly believed i was continuing a conversation then, if that isn't the case my apolgies.
If you understand how much work it is then how can you say "just generates code"?
For openness this is the conversation i am referring to:
As they are the same instance and the same conversation i believe lenni and erebion are the same person.
This paragraph is anchored in the part where once again instead of any source or info on their argument and all they respond with is
You know, an instance can have multiple users.
Sometimes people have the same opinion, I am also a sceptic when it comes to generated code, like many others.
I will notify my user that you are publishing a conversation with him. That conversation was not meant to be published, otherwise it would have beeb posted publicly.
There is no personal identifying information there. Just a disagreement.
Its not just the same opinion, its the combination that makes it read like a continuation of the same conversation with the same person: the exact same point, no source, and same instance. That made me suspicious enough to conclude im talking to the same person.
I have published the conversation for transparency reasons, no personal info was shared.
Not to mention DMs on lemmy aren't even private anyways.
Posting a conversation you had with someone — that did not expect it to be published — is NOT okay.
If there was no reason to post it i would agree, but here its important context.
If a person attacks me publicly while referring to points made in a DM where no private info was shared that is important context then i think its better to be transparent about this then hide this.
You said i was posting lies earlier, this is direct proof against your claim as this conversation did happen. Which there would not have been if i hadn't posted it.
Some people are just here to ruin the fun.
That's a shame to hear. I wonder how many of the ideas will be able to be rewritten by actual human developers and how much of it will have to be scrapped.
Why would it need to be rewritten or scrapped?
LLM assisted code is accepted in the kernel, and i am by far not the only user of it, and erebion hasn't shown ANYTHING why the patches i submit are bad outside of just saying it is.
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.
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?
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.
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.
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.
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.
It might take longer to find out why something is working-ish than to just get it working.