Over the past few months, I have found myself under the spotlight on kernel mailing lists. What started as targeted discussions quickly turned into advocating for the kernel community to respect the mostly silent crowd of developers and maintainers who do not want to fully embrace AI usage. It appears this didn't go unnoticed, as shown by Jon Corbet's talk at Kernel Recipes. (1/5)

#Linux #kernel #AI

Despite having a thick skin, the whole experience felt very lonely. I received less support than I would have hoped for. What surprised me the most, though, was something else. Multiple people contacted me privately. They didn't just express their support, but also told they didn't dare speaking out in public. This included at least one kernel maintainer. I can't help feeling this is a sign that something is going wrong in the kernel community or the industry at large. Or probably both. (2/5)

With my "How we can resist generative AI" BoF proposal for OSS Europe rejected, I've been thinking about other ways to give a voice to the underrepresented part of the community. There will be plenty of hallway space in Prague to meet for an "unconference" BoF. If you are interested in attending, please leave a reply or contact me by e-mail (laurent.pinchart@ideasonboard.com) with your availability. Wednesday is a candidate to benefit from the overlap between LPC and OSS. (3/5)

Plot twist: it turns out that if you're not careful about what you say on mailing lists, you risk getting invited to the Linux Kernel Maintainer Summit. While the invitation didn't provide any reason, I chose to believe it indicates that the kernel community cares. I'll dismiss my fears of being summoned as a human sacrifice on the altar of AI gods, and will try my best to represent the community members who don't feel they can speak out in public. (4/5)

I'm calling the community for help. If you would like your voice heard at the Maintainer Summit, please contact me by e-mail (laurent.pinchart@ideasonboard.com) to share your opinions on AI usage in the Linux kernel. Unless you explicitly request to be named, I will strictly respect your privacy and anonymize all the feedback I receive before sharing it with kernel maintainers. Please don't wait until the last minute as the week leading to the summit will be very busy. (5/5)

@pinchartl congrats!

I did my best speaking out but I think the powers that be REALLY don't want to hear from me :)

At least you can give some push back in the other direction

@pinchartl Thank you for this post! I'm interested in!

@pinchartl im also quite against AI. But with me being a student and time being sparse and not to sure what to do in the kernel most time it is just one more point to just do other things and not actively search for something to do in the kernel

@pinchartl I think they stopped human sacrifices in 2017. Too many unintended consequences.

@pinchartl I'm not a kernel developer, only a userspace developer. But if there's one thing I've learned over the past decades, it's that no FOSS project, no matter how big or important it seems, is eternal, and the only thing that ensures its existence is its community. Not its devs, not its users, but its community.

A move such as forcibly embracing AI despite the opinion of the community is the worst thing a project can make. People will not accept this. As far as Linux goes, they are already looking for alternative solutions.

Linux will lose significant support over this. It probably will not feel it harshly yet, but it will be weakened, its community fractured, less vibrant, and, face it, less competent. When, one day in the future, Linux dies, historians will point to this decision as the start of the decline.

I am sad.

@pinchartl I'm interested, will ping you on IRC tomorrow for contact details. Shout if I forget.

@ska @pinchartl several events during the 7.0 release cycle in march were also significant and relatively unmistakable signs that the project was not safe to depend on

@ska
God damnit, Alpine. Why? Why‽

When are you making s6os forked from Alpine? Semi-kidding.

@Brett_E_Carlock I am never making a distribution. I know all too well how much time, specialized skill, and dedication this takes, and that's not the kind of project I am fit for leading. My energy is best employed writing software, not integrating it.

However, I am willing to support and help any distribution willing to take a stance against slop, and I am all the more available to them if they want to use s6.

@ska @pinchartl Unix was 22 years old when Linux 0.0.1 came out and 25 when 1.0 shipped. Linux is 35 years old now.

@landley @pinchartl It had a good run, and it's not dead yet. But if it keeps going the way it is now, at some point something else is going to take its place.

@pinchartl (for better or worse,) I'm thankful to you for having that conversation with Linus. It made me realise what the state of things are and reinforced my belief that worshipping, following, and blindly citing authority figures is never a good thing.

@pinchartl
Where I think LLMs are good is in the static analysis department. Where I think they are demonstrably bad is in the generative case.
It was better when the generative code didn't compile now, we find that it compiles and can even look plausible. If you switch off your brain, you can find yourself blindly following one bad bit of advice after the other.
I think LLMs should be allowed to Review and Suggest but not author.
Ultimately a human needs to be responsible @ the SoB.

@0xB0D @pinchartl Reviewing can easily become authoring with extra steps if suggestions are followed uncritically.

@pinchartl I have made several threads about how Sashiko is driving me mad and I've corroborated similar stories from other small-time HID contributors. I can try and dig some of those up.

@pinchartl This post has a quick summary, and it's really just scratching the surface. I feel like these tools are waterboarding me, and I don't get to opt out. https://social.treehouse.systems/@endrift/117154802758493056

@pinchartl what particularly sucks is that Sashiko does reliably find issues...but only some of the issues are real. And sorting out the real ones from the hallucinated ones sucks for people who aren't super familiar with all the subsystems in question. It undoubtedly scares away smaller devs who don't have a vested interest in trying to upstream things.

@endrift @pinchartl The prospect of being required to interact with that thing means I won't be posting the patches I've been working on lately.

@ska @pinchartl

please in a year or so, provide a followup eg
some data on loss of devs, loss of support, number actually moving to BSD or some other platform

my guess, there won't be much change, but I'm often wrong

@failedLyndonLaRouchite Yeah, I am certainly going to spend the next year tracking all these metrics, because that is my only job and I have no life beside it, and it is totally reasonable to expect that amount of work from anyone expressing an opinion and making a vague prediction on the Internet.

(Edit: typo)

@mansr @pinchartl

Agreed. The tendency to switch off and ask "what next" is always there. A type of infantalisation.
Do I really need an LLM to tell me how to make a for() loop ?
If you ask the machine everything, that's exactly what will happen.
Trivial questions and trivial answers with the human saying to themselves "I knew that"
Vibe Coding is that brainless tendency raised to some sort of backwards virtue
"Bro I just give it specs"
OMG "Bro" you're an idiot...

@pinchartl Is this largely targeted at people who contribute to the kernel, or is this invitation inclusive of those of us who use Linux for whatever reason? (Personal computing, web hosting, development, etc)

I am more and more concerned about the harm AI is introducing, the political agendas the Slop boosters are embracing and pushing, and I do not have the spoons to migrate to something else like I think it’s NetBSD that’s pledged to be slop free? Is my taking time to write you an email helpful here as just an end user?

@deathkitten The invitation is open to anyone who would like to voice opinions relevant to the maintainer summit. There will be discussions about LLM usage in the Linux kernel, and my goal is to give all the community members who are traditionally not represented there a chance to get their voice heard. I will be grateful if you have time to send me an e-mail.

@pinchartl I will try to find the spoons to put somethig coherent together and send it. Can you confirm when I need to get it to you by to make sure it’s helpful? I just looked over the thread again, and didn’t see a specific date mentioned, and I’m not directly familiar with the event you’re looking to share this feedback at.

@deathkitten The maintainer summit will take place on Thursday. If you can, please share your opinions by Wednesday mid afternoon.

@endrift LLMs are in essence auto-complete machines trained on a corpus of text to find the most probable next words. Due to this nature, the errors they make sound very plausible to humans, even to the careful readers. It may not be a design goal, but it is at least a property of those systems that make reading AI-generated reviews or patches particularly unpleasant and time-consuming.

@ska @pinchartl fwiw this is what i'm referring to (an explicit crypto backdoor) https://circumstances.run/@hipsterelectron/116289908719559861

I will try to organize multiple "hallway BoFs" to give as many people as possible a chance to join. If you are in Prague and would like to participate in the first one, look for me during the Monday morning break at 11:30 in the foyer in front of the Club A room. Please keep an eye on the LPC Hallway Track matrix room, I will post updates there in case of last minute changes.

@pinchartl Fuck AI.

I'm watching another developer on here basically revive debian/kfreebsd using netbsd as the base and my next reinstall (when devuan excalibur goes EOL) I'll probably follow their lead.

Linus said if you don't like AI fork the kernel, but I'm more a "switch projects" guy.

@pinchartl I also note I'm unlikely to use a newer kernel than 7.0 in mkroot. I don't trust the slop, don't see the POINT of all the rust, and they're throwing architectures overboard like a sinking ship dumping ballast.

@landley @pinchartl The Rust (language with a mere descriptive specification playing catch-up) is a maladaptive response to the lack of a properly bootstrappable Ada compiler (the current one requires a blob).

Such a compiler should've been made two decades ago and Linux's C progressively replaced.

@lispi314 @pinchartl The navy language?

I'm assuming you're joking.

@landley @pinchartl I'm completely serious.

Name another standardized (or properly specified) language suitable for low-level/embedded work with acceptable safety/reliability properties.

SML doesn't count (it is very safe, but fails to account for a lot of that kind of environment's needs).

@lispi314 @pinchartl @landley I was looking at Ada for these reasons at one point when I found an AGENTS.md in one of the Adacore repos. I was already hesitant, but that put me off it entirely. 🫤

Forking Ada might be the way. I'm playing with Idris just now, since they have spoken against LLMs in the past and I have a preference for pure functional languages with rich type systems and totality checking, but it is not nearly mature enough yet IMO.

@lykso @lispi314 @pinchartl @landley Adacore is not the Ada language. Real languages (unlike Rust) have independent specification and implementations.

@lispi314 @pinchartl @landley Linux's problem is not C but running everything in a single privilege domain and not enforcing memory/resource access controls on its own accesses.

You wouldn't make the logic bugs handling page permissions go away just by writing that logic in Rust or Ada.

@dalias @pinchartl @landley Linux is a monolithic low-isolation kernel with widespread ambient authority.

That is not a design that compensates for C's flaws, it is not adequate to write it in C.

seL4 demonstrates an adequate design for use with C, and adequate use of external formal verification tooling.

You wouldn't make the logic bugs handling page permissions go away just by writing that logic in Rust or Ada.

Bare Ada? No. SPARK? Possibly, actually. Depends on what you use around it (model checking is nice) and how you use it.

@lispi314 @pinchartl @landley I don't think you *can* compensate for the flaw of being "low-isolation with widespread ambient authority". Beyond a certain level of complexity, there will be mistakes, and the abstractions needed to even try to make it work involve more complexity.