Krzysztof Kozlowski
Posts
343Following
43Followers
315#standwithukraine 🇵🇱 🇪🇺 🇺🇦 🇨🇭
IRC: krzk
Kernel work related account. Other accounts of mine: @krzk@mastodon.social
GitHub: https://github.com/krzk/
Traveling Instagram / Wanderquak: https://www.instagram.com/wanderquak/
Home brewery: https://brewalot.ch
Our gardening (and worm farm!): https://growalot.ch
Krzysztof Kozlowski
repeated
repeated
Embedded Recipes
embeddedrecipes@fosstodon.org
Embedded Recipes 2026 has officially kicked off!
It's fantastic to see so many talented engineers and developers gathered in one place to share knowledge, exchange ideas, and push the boundaries of embedded systems. Looking forward to two days of insightful talks and meaningful connections.
0
9
1
Krzysztof Kozlowski
krzk
@jann @kernellogger @ffmancera @vbabka Considering how poor developers are at expressing WHY they are doing that change/commit, I don't have big hopes on them being able to express that something is a fix.
0
0
2
Krzysztof Kozlowski
krzk
@jann There are maintainers who don't fully get Git basics, e.g. rebasing effects or branches (that merging a branch does not rebase anything), so if I was Linus T., I would not give them access to my tree...
Proficiency in Git is as needed as proficiency in English and programming language. And many of us are not proficient in these... which is fine, btw.
Proficiency in Git is as needed as proficiency in English and programming language. And many of us are not proficient in these... which is fine, btw.
0
0
4
@trini Being always suspicious is not necessarily good, don't take grumpy me as an example :), but in principle I agree that AI slop world is difficult for open source maintainers.
And in that particular case, sending a patch with a bunch of AI-generated assembly is moderately easy, but reviewing it by a human is consuming much more effort. That disproportion sucks.
And in that particular case, sending a patch with a bunch of AI-generated assembly is moderately easy, but reviewing it by a human is consuming much more effort. That disproportion sucks.
0
1
3
Krzysztof Kozlowski
krzk
[ANNOUNCEMENT / CFP] LPC 2026 Devicetree MC CFP
There will be a dedicated Devicetree Microconference on Linux Plumbers
2026 in October in Prague. Call For Papers is currently open.
https://lpc.events/event/20/contributions/2317/
Topics suggested for discussion are mentioned in "Ongoing problems" in
session description (link above), but of course are not limited to
these. Topics should obviously follow standard Microconference
expectation, that is to be discussion oriented.
Allocated time per slot will be between 15 to 30 minutes (20 minutes
last year).
Proposals can be submitted here:
https://lpc.events/event/20/abstracts/
Please remember to choose "Devicetree MC" as the track.
There will be a dedicated Devicetree Microconference on Linux Plumbers
2026 in October in Prague. Call For Papers is currently open.
https://lpc.events/event/20/contributions/2317/
Topics suggested for discussion are mentioned in "Ongoing problems" in
session description (link above), but of course are not limited to
these. Topics should obviously follow standard Microconference
expectation, that is to be discussion oriented.
Allocated time per slot will be between 15 to 30 minutes (20 minutes
last year).
Proposals can be submitted here:
https://lpc.events/event/20/abstracts/
Please remember to choose "Devicetree MC" as the track.
1
4
3
Krzysztof Kozlowski
krzk
@geert It is, looks exactly like that. Also AI agrees with that, quoting one LLM analysis:
"Several characteristics are consistent with LLM-generated technical email:
- Repetitive structure and over-explanation:...
- Highly polished corporate tone:...
- Excessive explicit enumeration:...
- Defensive balancing language:
- Commit message rewrite is unusually verbose:..."
Native speakers don't write like that. Non-native even less.
But to be fair, LLM judged that it looks still like technically valid answer, not AI slop:
"That combination often means one of:
- Written by a knowledgeable engineer using AI for drafting/polishing.
- AI-generated from detailed technical notes.
- Human-written but heavily edited with AI assistance."
"Several characteristics are consistent with LLM-generated technical email:
- Repetitive structure and over-explanation:...
- Highly polished corporate tone:...
- Excessive explicit enumeration:...
- Defensive balancing language:
- Commit message rewrite is unusually verbose:..."
Native speakers don't write like that. Non-native even less.
But to be fair, LLM judged that it looks still like technically valid answer, not AI slop:
"That combination often means one of:
- Written by a knowledgeable engineer using AI for drafting/polishing.
- AI-generated from detailed technical notes.
- Human-written but heavily edited with AI assistance."
0
0
1
@geert For example (but that is not the only one) look at this reply:
https://lore.kernel.org/all/56f5e73b-5f40-4bfb-9796-dadfcb4f9085@oss.qualcomm.com/
which is too long LLM junk "you are right".
And also consider this:
https://lore.kernel.org/all/01578e6a-d10a-46df-bb32-fd45ecb365d7@oss.qualcomm.com/
which is not even touching the subject and not answering my actual comments. It's a perfect LLM answer which is not solving anything, just wasting my time and ticking a box "I need to answer whatever to the reviewer".
https://lore.kernel.org/all/56f5e73b-5f40-4bfb-9796-dadfcb4f9085@oss.qualcomm.com/
which is too long LLM junk "you are right".
And also consider this:
https://lore.kernel.org/all/01578e6a-d10a-46df-bb32-fd45ecb365d7@oss.qualcomm.com/
which is not even touching the subject and not answering my actual comments. It's a perfect LLM answer which is not solving anything, just wasting my time and ticking a box "I need to answer whatever to the reviewer".
1
0
1
Krzysztof Kozlowski
krzk
Edited 12 days ago
AI slop in Open Source is not only about receiving poor quality LLM generated junk patches. It is also about receiving replies generated by LLM to reviewer's comments. Such replies are overly long, overly polite, unnecessarily "You are right, <here goes very long explanation>".
Reading an LLM generated answer to my review comment on the mailing list is a waste of my time.
If you are a contributor to an open source project, understand that maintainer has absolutely ZERO interest in talking to your LLM through you.
Reading an LLM generated answer to my review comment on the mailing list is a waste of my time.
If you are a contributor to an open source project, understand that maintainer has absolutely ZERO interest in talking to your LLM through you.
1
11
24
Krzysztof Kozlowski
krzk
@monsieuricon It's: you wash by hands and the washing machine acts as part of scrap-botnet scrapping git.kernel.org and other resources through your residential internet.
1
0
1
Krzysztof Kozlowski
krzk
@uecker It's easy to make statements, when you do not want to back them with any sort of argument. Just make a statement and put final stop. Product Foo is insecure. Some car manufactured by Baz is not reliable. This argument is unconvincing. I can express that as well...
1
0
0
@gregkh @uecker @Viss @icing @joshbressers @wdormann Heh, that's @uecker style of raising FUD, without actual arguments why it supposed to be unconvincing.
Here https://social.kernel.org/notice/B5gj02TzcQaDMcTpc8 supposedly individual (hobbyist) contributors have somehow obstacles from contributing just because some big companies are implementing changes matching their needs.
No facts or arguments why it would be more difficult for the hobbyist just statement "makes it more costly for others to contribute".
No facts why inability to create such list is unconvincing. It is just "unconvincing".
It's easy to discuss like that - object to anything, even to actual arguments, but without providing anything backing up one's statement.
Here https://social.kernel.org/notice/B5gj02TzcQaDMcTpc8 supposedly individual (hobbyist) contributors have somehow obstacles from contributing just because some big companies are implementing changes matching their needs.
No facts or arguments why it would be more difficult for the hobbyist just statement "makes it more costly for others to contribute".
No facts why inability to create such list is unconvincing. It is just "unconvincing".
It's easy to discuss like that - object to anything, even to actual arguments, but without providing anything backing up one's statement.
1
0
0
@ASI No cóż, ciągle nie wiem gdzie te slajdy wrzucić, więc udostępniam tutaj:
https://github.com/krzk/docs/blob/main/speeches-and-conferences/2026/Peculiarities%20of%20Linux%20Kernel%20Development%20-%20Krzysztof%20Kozlowski%2C%20Qualcomm%20-%20Sesja%20Linuksowa%202026.pdf
https://github.com/krzk/docs/blob/main/speeches-and-conferences/2026/Peculiarities%20of%20Linux%20Kernel%20Development%20-%20Krzysztof%20Kozlowski%2C%20Qualcomm%20-%20Sesja%20Linuksowa%202026.pdf
1
0
0
I could not find a place on the conference website to share the slides and that's a bit pity, because I understood that all my references and links won't be useful.
I am sharing then the slides via Github repo:
https://github.com/krzk/docs/blob/main/speeches-and-conferences/2026/Peculiarities%20of%20Linux%20Kernel%20Development%20-%20Krzysztof%20Kozlowski%2C%20Qualcomm%20-%20Sesja%20Linuksowa%202026.pdf
Recording of the individual session will be available later, so currently only stream is there:
https://www.youtube.com/live/ZeS7QtMYXyw?si=6vJBG2eploh85KdF&t=3957
I am sharing then the slides via Github repo:
https://github.com/krzk/docs/blob/main/speeches-and-conferences/2026/Peculiarities%20of%20Linux%20Kernel%20Development%20-%20Krzysztof%20Kozlowski%2C%20Qualcomm%20-%20Sesja%20Linuksowa%202026.pdf
Recording of the individual session will be available later, so currently only stream is there:
https://www.youtube.com/live/ZeS7QtMYXyw?si=6vJBG2eploh85KdF&t=3957
0
0
1
@uecker so we made circle... You repeated earlier thought. There's no shaping by American tech interests in this matter. Just American tech does not pay for these drivers and no one else paid, either. Paid as with money or their time. It's not the American interests who decided to drop these drivers.
And it's really not that difficult to maintain all of removed stuff. One doesn't have to be even skilled... I was doing it, e.g. NFC. It requires only one, the most scarce resource: time.
And it's really not that difficult to maintain all of removed stuff. One doesn't have to be even skilled... I was doing it, e.g. NFC. It requires only one, the most scarce resource: time.
1
0
0
Krzysztof Kozlowski
krzk
@uecker @kernellogger @klausman There was no such question when concerns of removal of the drivers were raised. Complains about dropped drivers did not come with "I wanted to devote my time, but I was rejected". No one was rejected, because no one volunteered to handle all this.
2
0
1
Krzysztof Kozlowski
krzk
@uecker @kernellogger @klausman There are no barriers to contribute, no payments needed, except one's time. Plenty of guides, plenty of resources, one just have to devote their time.
The entire and only point is here that simple: no one wanted to pay to maintain these drivers and no one wanted to devote enough of their own time to do that (except of course of netdev maintainers who have enough on their plate).
The entire and only point is here that simple: no one wanted to pay to maintain these drivers and no one wanted to devote enough of their own time to do that (except of course of netdev maintainers who have enough on their plate).
1
0
0
@kernellogger @klausman @uecker And the license governing Linux kernel kind of emphasizes this:
“This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.”
Which also means without warranty of support. We only HOPE it will be useful.
0
0
1
@uecker @kernellogger @klausman Each of these people having "genuine" needs of removed drivers could step up and help. Still can, like it happened with NFC which I left and was about to be removed, if I did not poke David. If these users do not step up, they have no rights to complain, because one cannot expect someone else doing work for free.
2
0
1