Will FreeBSD adopt a No-AI policy or such?

[MG]

The source code is open and the license too. They could've done that already.

If it's open, then why still require a company?

 

[Zare]

The train of saying plain "no" to LLMs has left the station some time ago.

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.

 

[rbranco]

If it's open, then why still require a company?

I meant the FreeBSD code & license.

 

[LibreQuest]

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.

 

[cracauer@]

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.

Last I head NetBSD has a strict "no" on LLM generated code. Dunno about reviews, documentation etc.

 

[cracauer@]

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

Correct. Regardless of the method of contributing, the contributor has to understand the code in question. This doesn't change with LLMs.

 

[rbranco]

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.

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.

 

[LibreQuest]

Last I head NetBSD has a strict "no" on LLM generated code. Dunno about reviews, documentation etc.

NextBSD, not NetBSD.

 

[T-Aoki]

NextBSD, not NetBSD.

You maybe mean this.

 

[Zare]

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.

 

[cracauer@]

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.

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.

 

[Zare]

Yes. Neither is suboptimal automatic code generation.

For FreeBSD I have no worries. Generally I have no worries for open source.

 

[akil]

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.

Findings bugs is a joke... honestly the worst thing they do.

 

[rbranco]

Findings bugs is a joke... honestly the worst thing they do.

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.

 

[LibreQuest]

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.

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.

 

[cracauer@]

Findings bugs is a joke... honestly the worst thing they do.

No.

 

[itstotallyme]

LLM naysayers are entitled to their opinion.

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/

 

[rbranco]

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/

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.

 

[msplsh]

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!

 

[rbranco]

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!

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.

 

[itstotallyme]

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.

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.

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.

 

[rbranco]

I don't think the Linux kernel has any other place for bringing up such things. Or does it?

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.