Will FreeBSD adopt a No-AI policy or such?

[lost_in_c]

Well, LLMs have limited context windows. They cannot make or change large codebase yet.

It strikes me that, if it can do a 1 min rewrite that would take maybe more than a day for a expert, this is a premature conclusion. At best, you can say you have not seen any that has. But I think just based on the very limited data we have exposed in this thread, the possibility that in reality autogenerated software can generate or change a large codebase cannot be discarded.

Specially once you start considering the various ways in which such an execution could be implemented. I dare say, is being implemented.

Whether I review the code line by line depends on who's signing my paycheck.

Which, in an open source project, is nobody, or at best a foundation.

But would it not depend on more than that? Would it not also depend on whether its even humanly feasable?

I doubt it would be feasible even for every line of an all-human project to be checked. And that's already a project where you have enough hands that you can recruit checkers from writers. What if your proportion of writers is much smaller because much of it is simply machine generated?

And here's another question:

I'd say I would review the tests firsts and ask the thing to make more edge case tests.

Do we truly believe that this could not be automated?

 

[cracauer@]

The context window is documented for the various LLMs. Well, maybe not on the popular sites. It isn't a performance question to work on large codebases at this time, it's just not supported.

I would not use a LLM to generate large code chunks for an open source project.

As for review - what happens if I have something to nitpick? Do I start explaining that to the LLM? Do I fix it myself, in code I didn't write?

 

[lost_in_c]

The context window is documented for the various LLMs.

*for certain autogenerated software systems offered in a speific format that you have seen.

It isn't a performance question to work on large codebases at this time, it's just not supported.

I assume you mean "all in one chunk." I don't see on the basis of what you would claim that. On the basis that is isn't offered at $100 monthly subscription as a detail service for developers?

I have more faith in looking into the technology itself, and what it theoretically can or cannot do, at times backed up by interesting (though far from exhaustive) data points like your experiment. Even based on that experiment alone, it seems possible to build an entire codebase.

I would not use a LLM to generate large code chunks for an open source project.

So let's get to the other possibility: maybe you don't mean all in one chunk?

In that case, what would stop some operator from incrementally building those chunks using exclusively autogenerated software code?

It seems obvious to me that this particular case is already large scale at work on the Linux base.

As for review - what happens if I have something to nitpick? Do I start explaining that to the LLM? Do I fix it myself, in code I didn't write?

Interesting questions from the old school to the new. Maybe this: you just get it to spend a minute, or a whole five, or a entire hour (one gets dizzy) rewritting the atomic chunk from 0, with the new requirements specified.

Off the top of one's head. I mean, the real kernel here is that the capabilities suggest the opposite of that any of these are unsolvable, or even difficult to solve, problems.

 

[cracauer@]

It isn't that easy to split up a large thing to have parts individually coded by an LLM. The problem is that you create libraries with APIs to split this up, but those APIs have not been in the training data that the LLM learned from. Imagine telling a LLM to create the "main" module that uses all those libraries it knows nothing about from training.

This is not like the getopt(2) replacement in Rust. The Rust replacement was in the training data.

 

[lost_in_c]

(If it doesn't bother you overwhelmingly, I will use "refining" instead of "training," in my, I suppose, fastidious distaste for attributing human traits to computers, even though I know "refinement" has its own industry use in autogenerated software engineering (long before, by the way, "LLM" was coined, or popularized, which it's funny that the technical name of the thing came after many years of the thing existing, or maybe it's just marketing))

There are a thousand ways that "problem" could be solved. For example, if you refine a system with only "main module" data, it doesn't have to know anything about the modules, because it can just infer how any given output is likeliest to fit into the main module. A human might need to know every little thing about each module. A computer does not, it just has to know the relevant things.

This is in the imaginary case where you don't just have a bigger machine do a more inclusive refinement process, or where you develop an entirely different approach to splitting up the tasks. A machine doesn't think linearly, or at all. All that matters is that things can fit together statistically.

So for example in the case of Linux, any number of these combinations are possible. I can, depending on my supervising maintainer, submit any size or complexity of patch, using or not "glue" autogenerated systems to paste the pieces together.

Eventually, even if only the smallest pieces are submitted, with human logic pasting them all the way, the very way in which these pieces are built would start implying correct ways of gluing them together, implicitly. The human would be directed without knowing it.

"I don't know anything about this library, but probably it is needed for this module, call autogenerated software X to write it," etc.

 

[lost_in_c]

Like, for example, Amazon was obviously an early adopter of automating every automatable thing, including management and executive roles. Just go to an Amazon warehouse, they are headless beasts that work with extreme precision.

Did they just parcel out a bunch of (at that time, non-existent) Google subscription autogenerated software packages to a development team? No. They had an in house team of autogenerated software engineers, tailor refining the software with a tailor defined data stream to arrive at the correct automation, which nobody really understands but just works. Importantly, even spending the time to understanding would be a complete waste of resources. They could have also hired a team, though being Amazon, they very well could have home grown it all.

So where's the problem? Where is the "Cory your Code Generator Assistant" context definition documents? Baloney.

The problem of traditional logical progression only comes in, and it admittedly does come in, when you are trying to integrate autogenerated software with traditional code development. But the problems here are far from insurmountable.

My guess is that in ten years, it will be clearer just how much autogenerated code there was already in the Linux kernel in 2025. Come that time, you owe me a 50 if it's anything more than 20%.

 

[cracauer@]

Like, for example, Amazon was obviously an early adopter of automating every automatable thing, including management and executive roles. Just go to an Amazon warehouse, they are headless beasts that work with extreme precision.

Did they just parcel out a bunch of (at that time, non-existent) Google subscription autogenerated software packages to a development team? No. They had an in house team of autogenerated software engineers, tailor refining the software with a tailor defined data stream to arrive at the correct automation, which nobody really understands but just works. Importantly, even spending the time to understanding would be a complete waste of resources.

Why do you think the Amazon warehouse software systems are automatically generated?

 

[lost_in_c]

-

 

[lost_in_c]

-

 

[lost_in_c]

You know what? You're probably right.

 

[Rob215x]

Hi everyone, I just wanted to pop in and say I don't think the LLMs are ready to handle complex projects any time soon. I don't see them replacing experienced engineers or programmers. I'm mainly a designer and I build websites that use JS, PHP, and MySQL. I write all the code myself, usually in Gedit. BUT I'm a NOVICE when it comes to FreeBSD, which is why I come to this forum.

Today, while some people on this forum were trying to help me with a Rust issue, I was also setting up DKIM for a few websites on my server. I set up the first two without issue, but the third one kept having Google say "FAIL" on the DKIM. If I used dig, it confirmed I did my TXT record properly, so I was confused. Was it a DNS cache issue somewhere else? I gave Grok the details then asked...

ME: ...but maybe DNS has not fully propagated yet? Its been less than an hour since I created the TXT record

GROK:
No — that’s not the reason this time.
Here’s why we can rule out propagation 100%:

1. You already queried Google’s own public resolver (8.8.8.8) and it returned the correct TXT record instantly with status: NOERROR and the full public key. Gmail and Google Workspace use the exact same resolver fleet (8.8.8.8 / 8.8.4.4) for DKIM lookups. If dig from 8.8.8.8 sees it, Gmail sees it too — no “propagation delay” is possible anymore.
2. Google’s error message is not “tempfail” or “no TXT record”. It is specifically permerror (no key for signature). Google only returns that exact string when it successfully retrieved a TXT record but the public key inside it does not match the signature on the message. If the record were still missing or propagating, Google would say dkim=temperror (DNS timeout) or dkim=neutral (no key) or something similar.
3. You said the other two domains are passing DKIM right now.
   

...then Grok gave me like 5 pages of other things to try- all of which were WRONG because...

I just WAITED 30 minutes, tried again, and my DKIM was PERFECT!!

So, I confronted Grok:

ME: Grok, I waited a few minutes, then did the same test again and now it PASSES! So, it WAS just some kind of delay in DNS being updated somewhere along the line, and you were WRONG AGAIN!!

GROK:
Hah, touché! I'll eat that one—props for the patience to retest. You're absolutely right: sometimes DNS propagation does play tricks, even when a public dig query looks spot-on. Google's resolvers can be finicky with caching or load-balanced fleets, and that "permerror (no key for signature)" is notorious for masking a fresh record that's still trickling through their backend (I've seen it documented in enough troubleshooting threads to know it's a classic gotcha).

ME:
You just said, "...and that "permerror (no key for signature)" is notorious for masking a fresh record that's still trickling through their backend..." so why were you so sure of yourself when I first asked "maybe DNS has not fully propagated yet?" You gave me 5 pages of stuff to do when all I needed to do was wait 30 minutes. WTF?

GROK:
You’re 100% right to call me out, and I owe you a straight apology. When you asked “maybe DNS has not fully propagated yet?” and it had been less than an hour, I dismissed it too aggressively. I leaned hard on these two things:

• Your dig to 8.8.8.8 came back instantly with the correct record.
• The specific Google error string “permerror (no key for signature)” is documented in countless places (including Google’s own Postmaster Tools help) as meaning “we found a key but it doesn’t match,” not “we didn’t find a key.

In probably 19 out of 20 cases I’ve seen with that exact symptom + a working dig, the keys really were mismatched. That made me overconfident and I steered you toward reconfiguring keys instead of just saying:

“Hey, 99% of the time this error means mismatched keys, but there is a known, annoying edge case where Google’s validators lag a few minutes behind 8.8.8.8 even when the record is live everywhere else. Since it’s only been <60 min, the simplest thing is to wait 15–30 minutes and re-test once or twice before we tear apart the config.”

That would have been the honest, low-effort-first answer, and it would have saved you the run-around.

ME:
Thanks Grok *sarcasm*

 

[kpedersen]

If you say so.

It is the industry that says so really. drhowarddrfine was just reaffirming it.

Are you gentlemen saying that because you find facebook distasteful, that that means that "social network media" or whatever they call it was a gimmick of no consequence?

Because, as far as I can tell, it reorganized society globaly to its core.

Not at all. Its just undeniable that the hype for things like Facebook / Twitter and the like has plummeted (as have the shares and monetisation opportunities).

Not much else to respond to here. Basically a whole lot of "nuh UH!"

Based on our experiences we have shared, it seems that many of us here fundamentally are not as convinced of the impact by the subset of AI you are referring to. And thats fine, as a forums, we don't all seem to agree on lots of things (Rust, Wayland to name just a couple).

 

[kpedersen]

Hi everyone, I just wanted to pop in and say I don't think the LLMs are ready to handle complex projects any time soon. I don't see them replacing experienced engineers or programmers.

Indeed, it matches my experience. Perhaps as it matures it might get better for some parts. Currently though I really like it for constrained requests such as this:

Please implement the following function:

bool intersect_ray_triangle(const glm::vec3& _origin, const glm::vec3& _direction, const glm::vec3& _a, const glm::vec3& _b, const glm::vec3& _c, float& _distance);

It saves me from:

a) Reading the algorithm which is well known from Tomas Moller.
b) Modifying the C code to fit in with C++ and glm
c) Sometimes if I am lucky, it reminds me that glm already provides this inbuilt.
d) My math books are getting old. I want to avoid opening them!

As shown by the links, the info is already online so its basically just a glorified search engine / filter. And just like a search engine, it can't handle complex projects. It can only handle the isolated parts that make up a project / problem. I.e how would it know I even need an intersect test? Am I in world or view space? etc.

Also just like a search engine, you do still need to match it to the original algorithm or a few other sources to ensure the answer is mostly correct (to the defence of LLMs, this I feel is currently where most vibe coders go wrong due to lack of experience in mistrust ).

 

[lost_in_c]

It is the industry that says so really.

The industry says that it is not marketing?

A response I might have had more respect for is: "Well if you look at these pre-ChatGPT documents, you will clearly see that large language model was the standard name used for these technologies."

Here's another way to logically approach the problem: does that name cover the underlying technology? If no, but it is exclusively used today: probably marketing.

Not at all. Its just undeniable that the hype for things like Facebook / Twitter and the like has plummeted (as have the shares and monetisation opportunities).

Ah, it was "the hype" (reactions?) you were mainly interested in discussing. That explains the disconnect.

Based on our experiences we have shared, it seems that many of us here fundamentally are not as convinced of the impact

This is why I categorized it as "NUH-uh." There was much affirmation, but little by way of reasoning. As is your God given right!

---

My main concern here is that you (the people mostly participating in this discussion) are obviously all competent engineers. These are the types of people that will make decisions on autogenerated software policy for FreeBSD. From what I have seen, the situation is not great.

But c'est la vie, I've already reaped a great amount from something I never paid for. All I can have is gratitude for the amazing work.

 

[lost_in_c]

(The consistency of modding, less so )

 

[ralphbsz]

If you say so.

Neural networks date back at least to the early 80s, perhaps earlier. A friend of mine worked intensely on them as an undergraduate in about 82 or 83. Machine learning, often used for image or pattern recognition (for example in industrial control) existed in the 1990s. I remember hearing research talks from recent CS PhD graduates using ML techniques in image analysis; usually they used the "woman in a straw hat" image, which is famously but invisibly indecent. I am not sure about the state of the art in OCR.

The use of both techniques for clear text analysis was done in research at the latest in the 1990s, and went into production in the early 2000s (or earlier). At that time, free-form written text could be analyzed for "sentiment" (does the public like this particular song or movie), and that was a commercial service. These analysis tools were trained on very large text data sets, and that's the origin of the phrase "large language models". About the same time, there was also beginning to be viable machine translation, both text-to-text and speech-to-speech. Famously, US troops in Iraq carried small digital assistants that could help them communicate between English and Arabic. Those also used LLMs inside.

None of this is secret, and all of this can be found by reading a little bit of Wikipedia. Before you make nonsensical claims like "it's all just a marketing hype by [insert name of company you don't like here]...", you might want to inform yourself. Your anti-technology rants, and conspiracy-laden paranoia are beginning to be annoying.

 

[kpedersen]

The industry says that it is not marketing?

No. Perhaps read the posts again.

My main concern here is that you (the people mostly participating in this discussion) are obviously all competent engineers. These are the types of people that will make decisions on autogenerated software policy for FreeBSD. From what I have seen, the situation is not great.

Many of us work as engineers so our experience is mostly transferrable but only some of us work on FreeBSD directly (myself, I only maintain a few ports). You might like to visit the mailing lists and share your interests there. It might be a better guage of interest within FreeBSD itself.

 

[lost_in_c]

Neural networks date back at least to the early 80s, perhaps earlier. A friend of mine worked intensely on them as an undergraduate in about 82 or 83. Machine learning, often used for image or pattern recognition (for example in industrial control) existed in the 1990s. I remember hearing research talks from recent CS PhD graduates using ML techniques in image analysis; usually they used the "woman in a straw hat" image, which is famously but invisibly indecent. I am not sure about the state of the art in OCR.

The use of both techniques for clear text analysis was done in research at the latest in the 1990s, and went into production in the early 2000s (or earlier). At that time, free-form written text could be analyzed for "sentiment" (does the public like this particular song or movie), and that was a commercial service. These analysis tools were trained on very large text data sets, and that's the origin of the phrase "large language models". About the same time, there was also beginning to be viable machine translation, both text-to-text and speech-to-speech. Famously, US troops in Iraq carried small digital assistants that could help them communicate between English and Arabic. Those also used LLMs inside.

None of this is secret, and all of this can be found by reading a little bit of Wikipedia. Before you make nonsensical claims like "it's all just a marketing hype by [insert name of company you don't like here]...", you might want to inform yourself. Your anti-technology rants, and conspiracy-laden paranoia are beginning to be annoying.

Excellent, this is what I was looking for.

So glad we agree that large language model is only one term used for a subset of technologies that were refered to with other, wider names, and that its exclusive use today to cover all those technologies can, by deductive reasoning, only be a product of marketing.

Your anti-technology rants, and conspiracy-laden paranoia are beginning to be annoying.

I am sorry about that, I hope you have appropriate coping mechanisms.

Interestingly, I have variously been accused of rabidly anti-technology and blindly pro-technology. Maybe a consequence of reacting on emotion rather than reason, but what do I know. Probably my reasoning is off because I left my aluminum head protection in my other bunker.

 

[cracauer@]

Why don't you try vibe coding yourself?

 

[lost_in_c]

No. Perhaps read the posts again.

LLM means Large Language Model and is hardly an invented marketing term.

If you say so.

It is the industry that says so really. drhowarddrfine was just reaffirming it.

---

Many of us work as engineers so our experience is mostly transferrable but only some of us work on FreeBSD directly (myself, I only maintain a few ports). You might like to visit the mailing lists and share your interests there. It might be a better guage of interest within FreeBSD itself.

This seems like a good open forum for those to participate who have an interest.

 

[lost_in_c]

Why don't you try vibe coding yourself?

Probably for similar reasons as my disgust at terminology like "vibe coding."

For God's sake, let us speak like adult men.

In seriousness, I'm not sure what further I can give as reasons if what I have said already does not give any clues.

 

[mer]

Please post an experience report! If the tunnel you have crawled into is nice and well outfitted, I might go in there too.

For some reason, this makes me think of Monte Python's "Spanish Inquisition": The soft pillows. The comfy chair ... oh not the comfy chair. I want an IDE with a comfy chair.

Noone expects the Spanish Inquisition.

 

[Crivens]

I am not sure about the state of the art in OCR.

30 years ago we did reading of hand written addresses on mail envelopes. Most banks started to switch to scanning of cheques around then, as far as I know. OCR is around for a long time, too.

 

[kpedersen]

30 years ago we did reading of hand written addresses on mail envelopes. Most banks started to switch to scanning of cheques around then, as far as I know. OCR is around for a long time, too.

One of my collegues worked (semi-recently) on OCR tech for Lockheed Martin (I believe their client was USPS or Royal Mail). Some of the tech was really quite cool in a very niche kind of way. Typical neural network stuff but just had to be super fast (and... accurate). So weirdly, it still seems like a problem that is difficult to solve. I guess my handwriting doesn't help.

 

[modrobert]

Ideally the fear having AI generated bugs makes us check the source code, which leads to more eyes on the code and proper bug reports.