PostmarketOS in 2026-02: generic kernels, bans use of generative AI(postmarketos.org) |
PostmarketOS in 2026-02: generic kernels, bans use of generative AI(postmarketos.org) |
Coding agents greatly reduce the barrier to contributing something that at least looks okay at the surface, so reviewing contributions will quickly become even more of a bottleneck. Manual contributions used to filter away most low effort attempts, or at least they could easily be identified and rejected.
That dynamic is now different and the maintainers risk being swarmed with low effort contributions, that will take a lot of time to review and respond to. Some AI contributions might be reviewed and revised and overall be of acceptable quality, but how can the maintainers know which without reviewing everything, good and bad alike.
I think we will see multiple attempts like this to shift things back to the old dynamic, by rejecting things that can be identified as AI generated a glance, but I suspect over time it will be difficult to do so, so my prediction is that we will soon see more open source repos stop accepting outside contributions entirely.
Even if LLMs one day will be good enough to quickly produce code that is on par with humans (which I strongly doubt), why would the contributors have any incentive to have someone else do that (the easy part), rather than just doing it themselves?
I remember when people were crying about how much power a google search uses. This is the same thing all over again and it is as pointless now as it was back then.
https://arstechnica.com/ai/2025/08/google-says-it-dropped-th...
> Google says it dropped the energy cost of AI queries by 33x in one year. The company claims that a text query now burns the equivalent of 9 seconds of TV.
That's like calling a person going for seconds a conservative (in the USA political sense).
Some people enjoy the outcome, others enjoy the process.
I find the criticism interesting. It's like one restaurant saying they'll use only electric stoves for the climate, then chefs all over the world calling them stupid naive for it.
It's like ethical arguments rationalizing local behavior are automatically interpreted as a global attack that has to be rejected.
Fun while it lasted, huh?
So, autocomplete done by deterministic algorithms in IDEs are okay but autocomplete done by LLM algorithms - no, that's banned? Ok, surely everybody agrees with that, it's policy after all.
How it is possible to distinguish between the two in the vast majority of cases where the hand written code and autocompleted code is byte-by-byte identical?
Are we supposed to record video of us coding to show that we did type letters one by one?
> 2. Recommending generative AI tools to other community members for solving problems in the postmarketOS space.
Is searching for pieces of code considered parts of solving problems?
Then how do we distinguish between finding a a required function by grepping code or by asking LLM to search for it?
Can we ask LLM questions about postmarketOS? Like, "what is the proper way to query kernel for X given Z"?
If a community members asks this question and I already know the answer via LLM, then am I now banned from giving the correct answer?
--
Don't get me wrong. I am sick and tired of the vomit-inducing AI bullshit (as opposed to the tremendous help that LLMs provide to experienced devs).
I fail to see how a policy like this is even enforceable let alone productive and sane.
On the other hand, I absolutely see where is this policy coming from. It seems that projects are having a hard time navigating the issue and looking for ways to eliminate the insurmountable amount of incoming slop.
I think we still haven't found a right way to do it.
AI use should be able to accelerate the development of ports on currently unsupported or undersupported devices which would directly support the project
I guess I wouldn't worry about the policy, they will probably naturally switch it if / when AI becomes more useful in practice
that ship has sailed with codex 5.3 in 90% SWE jobs, unfortunately. I expect the next 9% won't survive the following 12 months and the last 1% is done within 5 years.
it isn't even about principles - projects not using gen AI will become basically irrelevant, the pace of gen AI allowed competitors will be too great.
Because autocomplete still requires heavy user input and a SWE at the top of the decision making tree. You could argue that using Claude or Codex enables you to do the same thing, but there's no guarantee someone isn't vibecoding and then not testing adequately to ensure, firstly, that everything can be debugged, and secondly, that it fits in with the broader codebase before they try to merge or PR.
Plenty of people use Claude like an autocomplete or to bounce ideas off of, which I think is a great use case. But besides that, using a tool like that in more extreme ways is becoming increasingly normalized and probably not something you want in your codebase if you care about code quality and avoiding pointless bugs.
Every time I see a post on HN about some miracle work Claude did it's always been very underwhelming. Wow, it coded a kernel driver for out of date hardware! That doesn't do anything except turn a display on... great. Claude could probably help you write a driver in less time, but it'll only really work well, again, if you're at the top of the hierarchy of decision making and are manually reviewing code. No guarantees of that in the FOSS world because we don't have keyloggers installed on everybody's machine.
But again: how do we distinguish between manual code input and sophisticated autocomplete?
Not really. If AI is just copying someone else's code, it's not really designing it is it. If you want it to truly design something, it needs to be designing it using the same constraints that the human engineers would face, which means it doesn't get the luxury of copying from others, it has to design things like device drivers with the same level of information that human engineers get (e.g. device specifications and information gathered through trial and error).
No, I'm suggesting in order for it to be a fair test, you need to impose the same restrictions that a human engineer would face.
For example, consider the work done by the Nouveau team in building a set of open source GPU drivers for NVIDIA GPUs. When they started out the specs were not so widely available. They could look at how GPU drivers were developed for other GPUs, but that is not going to be a substitute for exploratory work. Let's see how well AI does at that exploratory work. I think you'll find it's a lot harder than common uses for AI today.
Writing device drivers from incomplete specs is much harder than "writing a whole application" where the specs are clearly defined and there's a lot more example code to reference. If you believe in AI so much, and believe that it's unreasonable for postmarketOS to not want to use it, put it to the test, prove the doubters wrong, what have you got to lose?
What does a developer who writes a driver from incomplete specs do? Writes some values in some registers, sees how the device behaves, updates the spec. Rinse and repeat. Sounds exactly the kind of stuff coding agents thrive at - a verifiable loop. And they can do it 24x7 until done.
Sure you do, you can prove those that doubt your views wrong.
> Sounds exactly the kind of stuff coding agents thrive at - a verifiable loop. And they can do it 24x7 until done.
Go for it then, you're not putting in any work into it other than giving it a task to do.
They do go on to address code quality but it is more of an after thought with 0 references, less words and appears lower down the page.
The timing is also suspicious, shortly after publication of this report: https://www.reuters.com/business/media-telecom/smartphone-ma... which forecasts declining smartphone sales meaning less devices for this OS to run on.
Why would declining sales of new smartphones have anything to do with PostMarketOS, which only supports phones more than half a decade old?
What I struggle to believe - what I don't believe - is that there any sort of connection between the report about likely declining sales and PMOS' announcement.
> These are the most supported devices, maintained by at least 2 people and have the functions you expect from the device running its normal OS, such as calling on a phone, working audio, and a functional UI.
> Besides QEMU devices, this is currently empty. The ports we had here earlier weren't as reliable as we would have liked. We plan to add new devices here with a higher standard.
The most recent smartphone in the Community section of that page is the Fairphone 4, released half a decade ago, in 2021. Pixel devices can trivially be bootloader unlocked, but that doesn't make the work that goes into supporting them much easier: the latest device in Testing is the 6a/6 Pro, from 2022, and its device page lists all the features but the most basic (touchscreen, flash, internal storage) as "Untested".
If you don't like the policies they set, just leave.
I'm willing to bet that every single person on here complaining has zero contributions to PostmarketOS.
Perhaps the reality is that you know AI needs more hand-holding than this, and the tools aren't up to the task you're thinking of setting them.
You are also strangely fixated on today's capabilities, completely missing the exponential we are on.
In a few months will have posts here from device driver writers explaining how they hooked up a phone to an Arduino and a video camera and how the AI is automatically writing device drivers.
It's moral values, virtue signaling and rage. Extremely engaging.
I am talking about today's capabilities because this comment thread started with the suggestion that the benefits of AI for coding was no longer avoidable after the launch of Codex 5.3.
> In a few months will have posts here from device driver writers explaining how they hooked up a phone to an Arduino and a video camera and how the AI is automatically writing device drivers.
A few months? Almost zero chance. If it happens in the next 5 years I'd be less surprised, but I suspect it'll take longer.