News: 1756900870

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

FreeBSD Project isn't ready to let AI commit code just yet

(2025/09/03)


The latest status report from the FreeBSD Project says no thanks to code generated by LLM-based assistants.

The FreeBSD Project's [1]Status Report for the second quarter of 2025 contains updates from various sub-teams that are working on improving the FreeBSD OS, including separate sub-projects such as enabling FreeBSD apps to run on Linux, Chinese translation efforts, support for Solaris-style Extended Attributes, and for Apple's legacy HFS+ file system.

The thing that stood out to us, though, was that the core team is working on what it terms a "Policy on generative AI created code and documentation." The relevant paragraph says:

Core is investigating setting up a policy for LLM/AI usage (including but not limited to generating code). The result will be added to the Contributors Guide in the doc repository. AI can be useful for translations (which seems faster than doing the work manually), explaining long/obscure documents, tracking down bugs, or helping to understand large code bases. We currently tend to not use it to generate code because of license concerns. The discussion continues at the core session at [2]BSDCan 2025 developer summit , and core is still collecting feedback and working on the policy.

In other words, there is no formal policy yet, but the team is working on one and will add it to the [3]Contributors Guide [4]documentation repository .

We suspect that some readers may feel like it's a little late, but if you'll forgive us for reminding you, the current generative AI boom is not yet three years old. At the start of December 2022, The Register mentioned the launch of ChatGPT, calling it [5]another AI to fill the world with kinda-true stuff . The boom really [6]got going in 2023 .

[7]

Historically, the BSDs are relatively slow-moving projects compared to the rolling corporate-sponsored frenzy of Linux development. FreeBSD 14.0 only appeared [8]about a year after ChatGPT . FreeBSD 15.0 is [9]scheduled for later this year .

[10]

[11]

This move looks to align with the [12]NetBSD guidelines – FreeBSD's roughly six-month-older sibling – and also those of [13]Gentoo Linux , as we [14]reported in May 2024 . At the time, we went into some depth about the problems and issues around LLM assistants.

Our current position on this can be represented by the phrase "memento mori" – "remember, you will die too." AI [15]winter is coming .

[16]

There's lots of other good news in the status report, although none of it headline. Support for [17]faster Wi-Fi standards is coming . So is [18]improved graphics, sound, and power management support .

[19]GhostBSD 25.02 adds 'Gershwin' desktop for a Mac-like twist

[20]FreeBSD 15 installer to offer minimal KDE desktop

[21]From PlayStation to routers, you've probably been using FreeBSD without knowing it

[22]FreeBSD 14.2 wants to woo Docker fans, but still struggles with Wi-Fi

The [23]pkgbase effort is continuing. Until now, the FreeBSD base system was installed in the form of several package sets using a tool called [24]bsdinstall , and subsequently updated using the [25]freebsd-update command. Additional software is handled in discrete packages, in a way familiar to most Linux folks, but they're layered on top and installed and updated with the separate [26]pkg command. Now an effort is underway to restructure the bulk of the OS into packages that can be handled by pkg . This is causing consternation to some people used to the old way – for instance, this [27]anguished message from well-known FreeBSD blogger (and occasional [28]Reg commenter ) [29]Vermaden .

Other projects mentioned in the report include Solaris-style extended file system attributes, support for Apple's HFS+ file system, a Proxmox-style web-based GUI for Bhyve virtualization called [30]Sylve , and [31]BSD-USER 4 LINUX , a tool that lets Linux users run FreeBSD binaries via QEMU, without needing root permissions. The [32]geomman effort aims to bring a GParted-style dynamic disk management GUI to FreeBSD. Other ongoing efforts involve community outreach in China, including improving the Chinese FreeBSD documentation – which we note includes a translation of the classic [33]UNIX-HATERS Handbook [PDF], which The Reg FOSS desk highly recommends reading.

The sentence "Netcraft confirms it: BSD is dying" is one of the longest-standing jokes in the BSD world. It was already old in 2011 when @jedisct1 [34]tweeted it and we suspect it's about as old as the 31-year-old Netcraft itself. (The gag back then being that FreeBSD had just [35]topped Netcraft's reliability chart .) It wasn't then and it isn't now. If you are sick of systemd, it's more worthy of a look than ever. ®

Get our [36]Tech Resources



[1] https://www.freebsd.org/status/report-2025-04-2025-06/

[2] https://www.bsdcan.org/2025/

[3] https://docs.freebsd.org/en/articles/contributing/

[4] https://cgit.freebsd.org/doc/about/

[5] https://www.theregister.com/2022/12/03/in_brief_ai/

[6] https://theweek.com/tech/2023-ai-boom

[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aLhmFd1TEqysJS9x_evpTAAAAJA&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0

[8] https://www.theregister.com/2023/10/24/freebsd_14_rc2/

[9] https://www.freebsd.org/releases/15.0R/schedule/

[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aLhmFd1TEqysJS9x_evpTAAAAJA&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[11] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aLhmFd1TEqysJS9x_evpTAAAAJA&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0

[12] https://www.netbsd.org/developers/commit-guidelines.html

[13] https://wiki.gentoo.org/wiki/Project:Council/AI_policy

[14] https://www.theregister.com/2024/05/18/distros_ai_code/

[15] https://www.researchgate.net/publication/385649183_The_Cycles_of_AI_Winters_A_Historical_Analysis_and_Modern_Perspective

[16] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aLhmFd1TEqysJS9x_evpTAAAAJA&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[17] https://freebsdfoundation.org/blog/the-road-to-better-wi-fi-on-freebsd/

[18] https://freebsdfoundation.org/blog/april-2025-laptop-support-and-usability-project-update/

[19] https://www.theregister.com/2025/08/27/ghostbsd_2502/

[20] https://www.theregister.com/2025/07/25/freebsd_15_installer_offers_kde/

[21] https://www.theregister.com/2025/04/28/freebsd_foundation_25/

[22] https://www.theregister.com/2024/12/05/freebsd_142/

[23] https://wiki.freebsd.org/action/show/pkgbase?action=show&redirect=PkgBase

[24] https://man.freebsd.org/cgi/man.cgi?query=bsdinstall&sektion=8&manpath=freebsd-release

[25] https://man.freebsd.org/cgi/man.cgi?query=freebsd-update&sektion=8&manpath=freebsd-release

[26] https://man.freebsd.org/cgi/man.cgi?pkg

[27] https://lists.freebsd.org/archives/freebsd-pkgbase/2025-July/000590.html

[28] https://forums.theregister.com/user/101583/

[29] https://vermaden.wordpress.com/

[30] https://github.com/AlchemillaHQ/Sylve

[31] https://github.com/sobomax/qemu-bsd-user-l4b

[32] https://wiki.freebsd.org/SummerOfCode2025Projects/FullDiskAdministrationToolForFreeBSD

[33] https://web.mit.edu/~simsong/www/ugh.pdf

[34] https://x.com/jedisct1/status/115107247239086080

[35] https://web.archive.org/web/20111006193316/http://news.netcraft.com/archives/2011/09/05/most-reliable-hosting-company-sites-in-august-2011.html

[36] https://whitepapers.theregister.com/



All submissions should be signed off by a real person /recognised expert - Not difficult really.

Roland6

Until we have certified "AI" (ie. it has been independently assessed and achieved a level of competence), all output should be treated as suspect and thus get signed off by one or more certified human developers and testers.

Re: All submissions should be signed off by a real person /recognised expert - Not difficult really.

a_foley

I hate to say it but I don’t think we will have “certified” “AI” ever. Period.

Well, excluding ones that would’ve been claimed to be, by marketing gnomes from companies à la OpenAI.

Re: All submissions should be signed off by a real person /recognised expert - Not difficult really.

Liam Proven

> Until we have certified "AI"

A delivery is due any minute, it says on the tracking site here... wrapped in the finest quality unicorn hair and delivered by flying pigs.

Re: All submissions should be signed off by a real person /recognised expert - Not difficult really.

Helcat

But is it rainbow hued tail hair from the Unicorn?

If so...

(Rainbow farting Unicorns confirmed!)

Translation

DarkwavePunk

Translation seems like a reasonable use of LLMS. I've seen decent results recently. Everything else makes me twitch in spasms of horror.

Re: Translation

alain williams

But there are still license concerns: who owns the copyright of a document that has been translated by a LLM ? The original/input might have been under a BSD license but what about the output ?

There is an obvious/reasonable/sane answer: but we are dealing with the law here - where sanity does not always apply.

Re: Translation, and copyright

Anonymous Coward

I think that the actual answer is: wait until it comes before a court and a precedent is set, as with most legal questions.

For human-made translations, I think the current law is that if the original is in copyright, then the original owner has rights over the translation too. The translator may also have rights over their work, since there is a creative element to translating to the new language. Since this is usually done for-hire, then as part of the contract they sign this over to the original author/publisher.

There is currently a principle around the world that machines can't own IP (see past El Reg articles on attempts to get this changed...), so a machine-made translation would not have any additional copyright. Therefore the original author would have copyright. If it's in the public domain (copyright-expired, or released into the public domain by the author) then there would be no copyright over the original or the translation. But, as I said, this will probably need a legal case to set the precedent.

Seems too good to be true!

a_foley

The fact that they have a policy against this is very promising, and is in line with the project’s good steps it has taken recently. I’ll just let it mature for a few years and I believe I can subsequently daily drive it!

Honestly, this might upset some penguinistas, but personally I believe that FreeBSD will be the new GNU/Linux!

Re: Seems too good to be true!

m4r35n357

Yep, we are hanging on your every word!

Anyhow, "X is the new Y" is lame & lazy.

Honestly(!), well played for attempting to antagonize people who basically agree with you.

Re: Seems too good to be true!

a_foley

You’re right that I echo what most other El Reg readers already think. However, I believe it should be loudly stated that what they (FreeBSD) are doing is great. Especially since other FOSS projects have catched diseases such as AI-creep (Firefox) or just plain ol’ feature creep (systemd, KDE).

And yes, you caught me; I was indeed doing some trolling with the latter part of my comment :) (I forgot the icon though)

Re: Seems too good to be true!

Liam Proven

> Anyhow, "X is the new Y" is lame & lazy.

It is one of the original and oldest snowclones:

https://en.wikipedia.org/wiki/Snowclone

A big mistake, this

VoiceOfTruth

>> Now an effort is underway to restructure the bulk of the OS into packages that can be handled by pkg.

Packaging up the base system doesn't do anything useful that cannot already be done with the freebsd-update patch level system. Instead of 'what patch level of FreeBSD are you running?' - a one line answer, the question is now 'which package versions are you using?' - could be dozens of things which interact with each other.

Indeed, from the discussions, the 'solution' is to mark certain packages as 'vital' or some such thing. Which then requires pkg to be modified to recognise 'vital' packages. It's just creating more work and complexity. And for what?

I wish 'they' would just leave this part of FreeBSD alone.

Re: A big mistake, this

Peter Gathercole

If what happened to AIX is anything to go by (and I know AIX is proprietary, and little to do with FreeBSD), what happens is that you package things up into convenient sets of files for each component package, allow them all to be installed separately, and then discover that there are dependencies between packages that require you to update all related packages at the same time by setting the packages up as pre- or co- requisites for the package you're updating.

And it then goes even further. Suddenly, all of these requirements, and their requirements et. al. become so complex that it often means that you have to update almost everything on the system to put even the smallest update on. So you invent level-sets of patches, and hey presto, you're effectively doing complete OS refreshes for even simple updates, even though you're tracking all of the files and packages separately.

The next step is to invent a mechanism to just patch files outside of your package manager to allow you to fix specific issues without a full OS update, and you re-visit whether you can package things using the package manager to be more independent again. And so it goes on.

IBM has gone around this loop at least twice in the Power version of AIX since AIX 3.1, and I suspect that with the re-packaging of lpps in AIX 7.2 and later, they're embarking on the loop again.

I like the sound of the OS Core package and any optional ones on top managed by a package manager. Moving away from that looks to me to be a step in the wrong direction.

Re: A big mistake, this

Jamie Jones

I agree.

However, in a way, it's been "packaged" for a while: When you build from source, you can specify whole sections to skipped, and dependency issues are worked through there. - The current binaries are simply "everything installed". [ [1]https://man-pages.freebsd.catflap.org/src.conf.5.html ]

I do fear that the more fundamental packaging proposed will lead to the problems you cite.

Also, Vandermaan's comment is valid. Why not have a different command (e.g. "pkgbase") to keep the base / ports distinction?

[1] https://man-pages.freebsd.catflap.org/src.conf.5.html

BSD is dying

IvyKing

That joke was common on Slashdot circa 2000.

A plumber is needed, the network drain is clogged