Will FreeBSD adopt a No-AI policy or such?

cracauer@ said:
The train of saying plain "no" to LLMs has left the station some time ago.
Click to expand...

This means little.
What people want to fight against is "vibe coded" software or PRs. LLMs still have a ton of great usages around programming.

What people also want to fight against is taking the humanity out. This is not feudalism, we're not picking up a quota of crops to survive, programming and software engineering are both intellectual and artistry, for some projects, especially open source ones, the "output", the "velocity" or whatever norm is, is totally irrelevant. People need to have a good time with it. If I can't take a week to ponder and daydream about how to tackle a technical problem because some asshat with OpenAI premium acc is going to spam my project my vibe coded feature, I don't want to do it.

It is akin to the recent thing with live debates and google. You couldn't one-two in a debate prior to someone just picking up their cell from pocket with a wiseguy face. I just raise my voice and say put that shit down, do not google it. I don't care if we argue for one hour, the point is to argue.
 
There is a vibe coded BSD. Perhaps vibe coded efforts can go towards NextBSD given that it is a BSD that has already been assimilated into the collective. It will be the Brundle Fly of the BSDs.
 
LibreQuest said:
There is a vibe coded BSD. Perhaps vibe coded efforts can go towards NextBSD given that it is a BSD that has already been assimilated into the collective. It will be the Brundle Fly of the BSDs.
Click to expand...

Last I head NetBSD has a strict "no" on LLM generated code. Dunno about reviews, documentation etc.
 
Zare said:
This means little.
What people want to fight against is "vibe coded" software or PRs. LLMs still have a ton of great usages around programming.

What people also want to fight against is taking the humanity out. This is not feudalism, we're not picking up a quota of crops to survive, programming and software engineering are both intellectual and artistry, for some projects, especially open source ones, the "output", the "velocity" or whatever norm is, is totally irrelevant. People need to have a good time with it. If I can't take a week to ponder and daydream about how to tackle a technical problem because some asshat with OpenAI premium acc is going to spam my project my vibe coded feature, I don't want to do it.
Click to expand...

LLMs are really good at:
- Discussing ideas.
- Generating skeleton code.
- Creating unit tests.
- Documentation.
- Review.
- Finding bugs.

It's like having a second opinion, even a third. It's up to you if you want to also delegate the fun. We can throw the tedious parts to clankers.

LLM naysayers are entitled to their opinion. I don't buy the hype either. But an informed opinion involves trying the tech first, and the truth will always be somewhere in between.
 
rbranco and cracauer I generally agree but there is improvement to be done, some models are really docile and you can spin them around like a fiddle, so I've had hit and miss with the "conversation partner" and idea bounce sort of stuff.

LLMs can be a great tool to automate all the chores but it seems to me more than 50% of "developers" in this world think sitting down and typing code is a chore. Which it should not be - it is like a blacksmith saying hammering on the anvil is boring and stupid, while not being aware that person who operates the blast furnace is not a blacksmith but furnace operator. In (IRL) conversations with capable seniors around other companies, ones that are doing vibe coding, are saying the process is high quality and the code is OK, but not perfect and still leaves technical debt which will accumulate over time if mgmt persists with "no manual programming" dogma.

If anyone is not aware, vibe coding by proper people and companies looks like a completely formalized, persisted, stored set of discussions against LLM that also have a great benefit to double as ADRs (architecture decision records). A dev doesn't commit the code, but the session, the LLM does the code. This pattern was never introduced by devs but by mgmt that aimed to orchestrate the "AI" themselves, like telling it what to do via Slack bot or something.

There is an initial period where devs need to implement AI workflows inside the company and through this period the devs themselves start using the vibe workflow and cut down the standard programming. At a point near full transition, somebody from those managers will ask a senior or architect to guide them through implementing a feature, where they will witness first hand, they're useless as a developer, and everything they thought AI is is wrong. This will fly off silently, no bells no whistles because the AI investment is still alive as the developers are still being productive.

However debt is being accomulated on every project and the answer I get from people is "we don't care, its all on mgmt". Indeed they aim for a point of time when the tech debt starts crippling the project to negotiate higher pay to sort things out.
 
Zare said:
However debt is being accomulated on every project and the answer I get from people is "we don't care, its all on mgmt". Indeed they aim for a point of time when the tech debt starts crippling the project to negotiate higher pay to sort things out.
Click to expand...

To be fair, that line of thinking is not new with LLMs.

In FreeBSD you need to get your code, no matter how you came up with it, past a couple of reviewers. That won't be easy for debt code.
 
Yes. Neither is suboptimal automatic code generation.

For FreeBSD I have no worries. Generally I have no worries for open source.
 
rbranco said:
LLMs are really good at:
- Discussing ideas.
- Generating skeleton code.
- Creating unit tests.
- Documentation.
- Review.
- Finding bugs.

It's like having a second opinion, even a third. It's up to you if you want to also delegate the fun. We can throw the tedious parts to clankers.

LLM naysayers are entitled to their opinion. I don't buy the hype either. But an informed opinion involves trying the tech first, and the truth will always be somewhere in between.
Click to expand...
Findings bugs is a joke... honestly the worst thing they do.
 
akil said:
Findings bugs is a joke... honestly the worst thing they do.
Click to expand...

Colin Percival & Linus Torvalds disagree. They have found bugs that were decades old and pieced together exploits in novel ways.

There's a huge asymmetric disadvantage for defensive security right now. It's irresponsible not to use LLMs to level the playing field.
 
rbranco said:
Colin Percival & Linus Torvalds disagree. They have found bugs that were decades old and pieced together exploits in novel ways.

There's a huge asymmetric disadvantage for defensive security right now. It's irresponsible not to use LLMs to level the playing field.
Click to expand...
LLMs should not be used for security. If the training is not specific to the project. They will create a lot of false positives. Which just makes them pretty useless. But, a great option if they're are trained on specific sets of data to the project. The technology of LLM/AI is solid, the application of the technology absurd.
 
rbranco said:
LLM naysayers are entitled to their opinion.
Click to expand...
For what it's worth, this seems to discount some concerns that were brought up when advocating for an LLM output submission ban. More than half of the uses you listed don't require allowing submitting actual LLM output into the code, and for the other uses I think it's fair for some of us to ask if that alone is worth the significant issues that come with LLM output polluting the code base. (Moral, ethical, potentially legal, ...)

Also see for example here, I found this one interesting: https://lore.kernel.org/lkml/fd7dcb35-037c-4e0a-9dfb-5e3d444749d6@horse64.org/
 
itstotallyme said:
For what it's worth, this seems to discount some concerns that were brought up when advocating for an LLM output submission ban. More than half of the uses you listed don't require allowing submitting actual LLM output into the code, and for the other uses I think it's fair for some of us to ask if that alone is worth the significant issues that come with LLM output polluting the code base. (Moral, ethical, potentially legal, ...)

Also see for example here, I found this one interesting: https://lore.kernel.org/lkml/fd7dcb35-037c-4e0a-9dfb-5e3d444749d6@horse64.org/
Click to expand...
Technical lists are not the best place for philosophical & ethical discussions that by their very nature are endless, and this is considered a feature and not a bug. There's no single outcome that will satisfy everyone and I think that Linus' verdict is the right one because it will benefit the majority.

Wrt the legal implications, I guess we'll cross that bridge when we come to it. We'll only know when it's tested in court and the only way it's tested it's by actually getting our hands dirty.
 
TBH, Linus throwing a fit about this is like the BitKeeper fiasco except he can't code his way out of this one, so it's just foot stomping.

WRT FAFO the legal implications: That always works out well!
 
msplsh said:
TBH, Linus throwing a fit about this is like the BitKeeper fiasco except he can't code his way out of this one, so it's just foot stomping.

WRT FAFO the legal implications: That always works out well!
Click to expand...
The Linux Foundation has the Open Invention Network with lots of companies pledged not to sue for patents. They must have the same protection wrt licenses that only apply to original code anyway. It's not like Linus suddenly allowed vibe-coding in the kernel.

Google also provides legal protection in case of litigation to their corporate clients. The legal aspect is a nothing-burger, TBH.
 
rbranco said:
Technical lists are not the best place for philosophical & ethical discussions that by their very nature are endless, and this is considered a feature and not a bug.
Click to expand...
I don't think the Linux kernel has any other place for bringing up such things. Or does it?

The legal aspect is a nothing-burger, TBH.
Click to expand...
Is it, though?
https://github.com/mastodon/mastodon/issues/38072#issuecomment-4105681567 https://www.twobirds.com/en/insight...-(gema-v-openai)-on-copyright-and-ai-training Not that I would know, but especially in the EU things look way more muddy.
 
itstotallyme said:
I don't think the Linux kernel has any other place for bringing up such things. Or does it?
Click to expand...
It has plenty of spaces like LWN. It also had Groklaw in the past when they had the water in the neck. And in the worst case scenario it wouldn't be hard to fix.

We geeks should discuss geek stuff and leave lawyer stuff to lawyers.
 
Here is a new Linux take on it, specifically for the kernel area of drivers/experimental:


Code: 
[TABLE width="100%"]
[TR]
[td][TABLE width="100%"]
[TR]
[td]Date[/td][td]Mon, 3 Aug 2026 15:13:48 +0200[/td]
[/TR]
[TR]
[td]From[/td][td]Greg KH <>[/td]
[/TR]
[TR]
[td]Subject[/td][td]LLM policy for drivers/staging/ going forward[/td]
[/TR]
[/TABLE][/td]
[td][/td]
[/TR]
[/TABLE]

Hi all,

Given the recent "onslaught" of LLM-generated kernel patches for the
drivers/staging/ subsystem, I'd like to clarify my position going forward with
regards to taking patches made with these tools.

First off, drivers/staging/ exists PRIMARILY as a place for new kernel
developers to learn how to get involved in kernel development.  It contains
loads of "low hanging fruit" with regards to code cleanups and api changes,
perfect for new developers to learn the process in a safe and friendly way,
with no pressure as no one _should_ be relying on the code in these directories
(as proof of the TAINT_CRAP flag that gets set if you ever actually load any of
this code into your kernel tree.)

We don't just take "fix all the coding style issues in this file!" type of
patches that are generated by tools, as that would defeat the whole purpose of
drivers/staging in the first place.  We could do that tomorrow if we actually
_cared_ about the code in here, but rather, we live with the issues just
because this is where people can start out and learn and grow from.

So this mean that anyone attempting to use a LLM to cleanup or "fix" any code
in drivers/staging/ is EXPLICITLY defeating the whole purpose of it existing in
the first place.  Because of this, going forward I am going to automatically
reject any patches generated with a LLM for the drivers/staging/ subsystem,
with one exception noted below.

And yes, it is VERY obvious when people submit LLM-generated patches, so don't
think that just not disclosing the use of them will allow you to "get away"
with anything here.  The goal is for people to be able to learn, not to try to
"trick" a maintainer.  If anyone is determined to have deliberately "tricked"
us, well, consider this your warning ahead of time...

Note, LLMs are very good at finding suspect "security issues" in kernel code
these days.  But even with the best of the current and next generation tools,
at least 1/3 of the results they generate are flat out wrong or harmful.  So,
if you think your LLM-found/fixed issue in a drivers/staging/ file is really
valid, it's fine to submit it BUT you must have first tested it on the actual
hardware for the driver, and described how you have done so, in order for us to
be willing to take the change.  This testing process should _hopefully_ weed
out the 1/3 wrong reports, but that isn't always the case, so you MUST be
willing to defend your submission and prove that it really is correct in fixing
a bug that a user can actually hit.

In other words, drivers/staging/ here is a "gym" that is here to learn and grow
your skills with.  A LLM is turning into a reasonable tool to do "heavy
lifting" for some things but that should only be done by those that have
already properly trained their skills to know what type of lifting can be done,
and in what way.  See this great essay by Bruce Schneier for where he explains
this in much better detail:
 https://www.schneier.com/blog/archives/2026/07/should-you-use-ai-for-a-task-heres-a-simple-way-to-decide.html


thanks,

greg k-h
 
You must log in or register to reply here.
Back
Top