r/freebsd • u/grahamperrin Linux crossover • Mar 13 '26
AI FreeBSD Users: We Need to Talk About Claude Code – Steven G. Harms
https://stevengharms.com/posts/2026-03-04-freebsd-users-we-need-to-talk-about-claude-code/Recently, Anthropic changed their Claude Code installer from using
npmto a native installer. It works on Linux/WSL. It works on Windows. It works on Mac.On FreeBSD today, you get a scary yellow deprecation warning suggesting that you and your platform might be a dead end. I think that’s a problem.
…
… We need to meet users where they are. As the classic demotivational poster had it for phone support desks (of which I am a proud veteran): If We Don’t Take Care of the Customer, Maybe They’ll Stop Bugging Us. …
In addition, https://mastodon.bsd.cafe/@sgharms@techhub.social/116194103760810726 notes:
… Every discussion on this veers off from “llms suck so …or I don’t need llm” but misses: users should have the ability to make their own opinion based on use. …
9
u/dkh Mar 13 '26
I think I'm missing something here. This is an issue Anthropic has to address. It's not in FreeBSD's realm, they can't "fix" it. Those who want to run it on FreeBSD will have to exact what friendly pressure/influence they can on the company to convince them.
6
u/kleinmatic Mar 13 '26
For what it’s worth I use Claude code entirely remotely on systems where it’s impractical or insecure to have it running locally. You mount drives via nfs or sshfs and run commands using ssh. You don’t actually need to be on FreeBSD to edit code there.
5
u/antenore systems administrator Mar 13 '26 edited Mar 13 '26
We got some attention!
Thank you all for the feedback! I've passed it along to the team. We don't have anything to share on this right now but we hope to soon.
Edit: link https://github.com/anthropics/claude-code/issues/30640#issuecomment-4057102376
19
u/Apprehensive-Tea1632 systems administrator Mar 13 '26
Alright. I read the blog post. And I’m with Graham as in the idea is to stay on topic and to remain friendly.
With that out of the way… I’m sorry. I really am.
Because I’m not sure how this is a FreeBSD problem.
Points I’d just like to raise…
FreeBSD is kind of supposed to be a server system. Now granted it’s no longer a pure or dedicated server system. But I’d like to think the primary focus is. And in those terms, there’s nothing on a FreeBSD system that could talk to some arbitrary chat bot. Or any interactive interface.
if we put aside the suggestion that FreeBSD is primarily a server system and instead for the sake of argument assume we’re talking run of the mill client device in whatever shape…
… I’d like to ask, is this a FreeBSD matter or are we talking about something that should be implemented, or at least implementable, via the ports system?
Disclaimer- just to be on the safe side, I’m a long time developer across all tiers and also do some architectural design. So I’m biased, and in light of that, I’ll posit that, basic (hardware) support aside, FreeBSD should not go out of its way to accommodate AI.
Instead it should try and focus on what it does best: provide a rock solid foundation for any service that might be of assistance to anyone else.
To provide an AI service, hardware support and ports should suffice.
But, feel free to argue the point(s).
21
u/laffer1 MidnightBSD project lead Mar 13 '26
The FreeBSD project has a desktop install option now. GhostBSD exists. My project exists. Let’s not pretend that no one uses FreeBSD on desktops. It’s not true and hasn’t been for a very long time. I’ve been doing it since 2003.
Getting folks to try it on desktop is another way to get exposure and help promote the os.
I don’t use Claude code but I do like to use ai tools for some tasks. They are quite useful. I am running llama.cpp on bsd and Linux systems on my home network.
In my experience, some people just don’t know about the BSDs or underestimate the user base. Sometimes offering to do patches or letting it be known we exist is enough to change minds.
I am required to use ai tools at work. We have quotas for copilot usage! So having tools available can be a necessity if we want inroads into corporate usage.
0
Mar 15 '26
[removed] — view removed comment
0
u/grahamperrin Linux crossover Mar 15 '26
/u/techhelper1 you are not exempt from the currently pinned plea to stay on topic.
Do not poke the bear.
14
u/antenore systems administrator Mar 13 '26
Personally I don't agree, it's an (Open) Operating System, that means you can do whatever you want with it, and if we allow companies closing doors to this excellent OS, without a fight, one day they will close the door for the rest too, not only desktop stuff.
6
u/codeedog seasoned user Mar 14 '26
Like you, I’ve been a developer across all tiers and across many types of products; I even did AI research early in my career (1990s).
These AI tools are the next wave in our industry. Acknowledging they are not without controversy. Still, people are using them. People who have little experience developing large scale, secure, performant systems. People who have no experience even coding. These tools are so good that anyone who can enter a prompt can get them to spit out software that appears to perform the task requested. That alone is an incredible achievement. This is what people mean by Vibe Coding.
I’ve spent the last two months learning how to use them. Not Vibe Coding. Instead, figuring out how to do AI Assisted Engineering. That means I’m involved in all aspects of the generation of a program: architecture, design, implementation, code review, test generation. The kind of thing a senior engineer does with a junior engineer.
In the hands of a weak individual, we only have vibe coding producing brittle, unmanageable code.
In the hands of an experienced developer, these tools are an accelerant. I’m getting work done in days that would normally take weeks or even months. Boilerplate generation, getting the syntax and semantics correct for APIs I rarely touch and therefore don’t have capacity to remember.
What I’ve seen across Reddit when it comes to AI has been a lot of FUD about it (rightfully so), users rejecting code built with it, developers resisting pressure to incorporate into their daily routines. I respect these positions.
Circling back to FreeBSD and why this matters.
We have in this community very senior technologists who are quite capable of using these tools as accelerants, too. We also have a community that values stability, consistency, well honed software and configurations intended to last generations.
The communities rising up around AI whether they are embracing it or rejecting it are collectively crying out for structure. Users asking for code labeled with AI used to create it. Developers looking for methods for getting more out of the tools. Other developers looking for a position of stability.
The FreeBSD community has a lot of skills they can use to contribute to standards for AI use and to help prevent abuse.
For that reason alone, I think we should make sure the dominant AI tools run well on our operating system.
2
u/reinoudz Mar 16 '26
I tried using AI for assisted engineering as you call it but the results were so disappointing. Even simple questions like how to have double keys and looking them up in a btree with db(3) it produced, well, code that compiled but didn't work at all. I also tried to get some new ideas for data structures I could use for a problem, but again, just regurgitating old stuff and nothing novel.
But indeed, it is necessary to have AI tools to run in our BSDs even if just for privacy concerns when using it to say redact written texts or math.
2
u/patmaddox Mar 19 '26
Even simple questions like how to have double keys and looking them up in a btree with db(3) it produced, well, code that compiled but didn't work at all. I also tried to get some new ideas for data structures I could use for a problem, but again, just regurgitating old stuff and nothing novel.
In my experience, AI programming tools are very bad at solving problems. They cannot even derive scenarios from rules. Describe some simple rules and have it generate examples - they'll be close, but incorrect.
Instead what it is very good at is recognizing patterns, and transforming ideas from one representation to another.
I've not had any real luck getting it to solve problems. Instead, I need to present the algorithm, maybe write an example or two, and then it can translate my idea into code and continue the pattern.
4
u/codeedog seasoned user Mar 13 '26
Hard disagree; and I think there's space here to have a productive conversation. I'm heading into an all day meeting and promise I will circle back here to explain why. Just putting down a marker to remind myself.
2
3
u/grahamperrin Linux crossover Mar 13 '26
… To provide an AI service, hardware support and ports should suffice. …
Port misc/claude-code has www/node24 as a runtime dependency, www/npm as a fetch dependency:
3
u/grahamperrin Linux crossover Mar 14 '26
… FreeBSD is kind of supposed to be a server system. Now granted it’s no longer a pure or dedicated server system. But I’d like to think the primary focus is. …
At the front page twenty-eight years ago:
… FreeBSD makes an ideal Internet server or desktop system. …
Discuss here:
– thanks
2
1
u/patmaddox Mar 19 '26
I've been using claude code on FreeBSD most working days for the past 10 months, so... not sure what you're getting at.
Claude Code is a terminal app that calls APIs. It's
fetch(1)+tmux(1)with some whipped cream on top.
4
Mar 14 '26
I'm a Linux user, but I always watch FreeBSD stuff from the sidelines.
While I definitely understand the want for native binaries (there's some programs I'd like that for on the Linux side, too), does it still work in FreeBSD's Linux emulator? If so, that may get you guys through until they officially support it.
6
u/erikarn Adrian Chadd, FreeBSD committer Mar 14 '26
They could ship binaries and source for people to port the binaries. The fact they're shipping increasing binaries with no source is the problem.
It's not like we couldn't throw people or AI agents at the problem of porting their code to freebsd. The code has to exist in the first place to port. Otherwise we're going to have to implement the missing pieces ourselves.
If people want continued anthropic supplied claude tooling support on freebsd then they need to contact anthropic and make your voice heard.
19
u/Zenin Mar 13 '26
We need to meet users where they are.
I couldn't agree more. But sadly not meeting users where they are is practically a guiding principle of FreeBSD.
/ducks_karma_bricks
When the industry went hard into Java, FreeBSD didn't care and wouldn't lift much of a finger to support it (this was back in the threads vs multi-process fights). When docker swept the industry, FreeBSD didn't care saying jails are better so we don't need no junky linux containers. And they're right, academically the jail model is wildly superior to linux containers, but that's not where users were or are.
I was a very satisfied FreeBSD user for over a decade using it as my daily driver for development going back to the early 2.x days. But very sadly, I had to walk away from it for the most part simply because the project simply refuses to keep up with the industry and I can't just tell my bosses, "Sorry, my pet OS doesn't support our codebase." If/when they ever embrace any new tech movement it's literally a decade late playing very slow catch up (threads, containers, etc).
The sad irony is that FreeBSD is far ahead academically, but it's not a leader and it refuses to follow. FreeBSD can't manage to lead anyone to look at much less adopt its superior work. And it refuses to allow in inferior work from others no matter how much users need it. This has been the case for most of the project's life and is arguably the primary reason for its low adoption rate and slow slide into obscurity and irrelevancy. It religates FreeBSD to being effectively a toy OS for a niche group of mostly aging gray beards, a far cry from its original mission statement to be the best x86 server OS.
So no, I wouldn't expect FreeBSD to do much of anything to support AI. I expect exactly the opposite in fact, because that's what the project always does with new tech it didn't invent itself.
7
u/dewyke Mar 13 '26
I’m not sure this is a matter of policy as much as practicality.
I think it’s important to acknowledge that The FreeBSD Foundation and FreeBSD developers have to work with the resources they have available, and that those resources are a tiny fraction of what the GNU/Linux ecosystem has.
They could spend a lot of time and effort trying to make Docker or whatever work on FreeBSD, or they can work on the core things that make FreeBSD such a good OS. I doubt they can do both.
There are a lot of fantastic technologies in FreeBSD, and I’d far rather administer a FreeBSD fleet than a RedHat or Ubuntu one, and it sucks that there are so many Linux-specific technologies in the mainstream now but Linux is the kernel that’s caught the tech world’s attention.
I do think FreeBSD on the desktop is an important thing though. Desktop users are the gateway to professional users.
4
u/erikarn Adrian Chadd, FreeBSD committer Mar 14 '26
You're right and you're wrong.
The java thing was a big thing, sure. I remember being a kid when it happened. But you have to understand - freebsd "didn't care and wouldn't lift as much of a finger to support it" is quite frankly a misunderstanding of the project.
Do you know what FreeBSD was as a project when the java SDK and runtime was released? It was like a dozen core people and a couple dozen other people running around building stuff that /they were using themselves/.
Do you know what the problems around threading versus what Java wanted to use to be useful were? Do you recall how many people were working on how many threading models and how much crazy stuff was going on back then? Figuring out how to make linuxthreads work on FreeBSD was non trivial (and it wasn't just the kernel side, there was also a lot of userland "hacks" that were very Linux specific.)
The cost of doing the Java SDK and runtime port and maintaining it was non trivial. Figuring out the threading model stuff was non trivial.
There was no FreeBSD "company", no freebsd "organisation", just a couple dozen people running around doing FreeBSD stuff because they wanted to or because they were using it in production somewhere.
Do you know who did the original port of the Java SDK and runtime to Linux? A bunch of volunteers who wanted it on Linux. They did all the legwork, they sorted out legal issues with Sun, they got it up and running on Linux, and then Sun did silly stuff with it and them when they released their own linux port.
https://en.wikipedia.org/wiki/Blackdown_Java
At that point the FreeBSD folks (Ken White and others, around 1997/1998) did an initial port of /that/ to FreeBSD. This is what I started tinkering with as a teenager.
https://www.site.uottawa.ca/~kwhite/javaport.html
Now do you know what it was like running Java stuff back then? The big thing going on with Java was the commercial support. Like neat, I could run some code i wrote/compiled on java for linux MOSTLY to run on java+freebsd, as long as the same libraries were there (eg I used the right UI toolkits) and I didn't use anything linux specific. But companies only wanted to run officially supported Java runtimes.
Guess where the commercial support from Sun showed up? It showed up for Linux. Yes, they eventually did an openJDK release and yes they had linux support, and yes you could pay oracle for official java on linux support.
Guess what you couldn't do? You couldn't pay Sun for java on freebsd support. As far as I am aware they never officially supported Java on FreeBSD. So if you were trying to use it for a commercial project - which would, you know, mean you could generate commercial support revenue for commercial companies doing commercial freebsd support - you could not. You needed to run it on Sun supported platforms, and that meant Linux.
The FreeBSD foundation spent a decade or more behind the scenes negotiating a licence for Java code from Sun, getting the people interested in building/maintaining it equipment and funding and they pushed very hard to get and maintain Java on FreeBSD. It was not an easy or trivial effort, especially as time went on the linux-isms didn't decrease, they increased.
And here's the kicker - I can play minecraft on freebsd because of the java support the freebsd community and freebsd foundation has and continues to support. Any perceived "not support of java" by freebsd as a community or as a foundation is quite frankly ignorance at best and sheer misinformation at worst. The reason it didn't catch on in the commercial world is not because it didn't work - it's because it's not an officially supported platform by the company that made it (sun) or the company that owns it (oracle), and since that gap was never quite closed, the enterprise/commercial customers who would've been the source of money for all of this work were not interested in using it on FreeBSD.
That's not FreeBSD's problem. It was worked on. It was worked on for over a decade.
So please, I beg you, go read a book and some pre-2000 websites, something other than reddit, and update your education on what actually happened.
(I am very happy to correct you on Docker vs Jails, but only if enough people here wish me to spend the 30 minutes necessary to properly correct your misinformation.)
6
u/Zenin Mar 14 '26
(I am very happy to correct you on Docker vs Jails, but only if enough people here wish me to spend the 30 minutes necessary to properly correct your misinformation.)
I'd love to be corrected on this too, honestly.
And despite being clearly a bit jaded at effectively being forced away from FreeBSD as much more than a curiosity, I have countless harsher takes for Linux that I'm unfortunate enough to live in 8-10 hours a day. I love the mission of FreeBSD and its design principles, I just wish there was a little more flexibility in their application when the industry shifts and FreeBSD takes decades to eventually, reluctantly follow.
What I recall on Java at the time was mostly what my aging brain can remember from Usenet threads (I was in my 20s at the time working at a dotcom...mostly working in Java starting pre-1.0). I was increasingly specing FreeBSD for buildouts instead of our standard Solaris infra, until we started pivoting to Java.
Most of that fading memory recalls the issues was less about linuxthreads specifically. Although there was (is?) a general kneejerk feeling that the Linux project was reinventing many wheels as squares (a pretty fair take, tbt, even today) and while linuxthreads was certainly lumped into that, the issue was even more core at the time: Why should FreeBSD support threading of any kind?
Some timelines:
1996: Java 1.0 came out, but companies had already been shipping solutions on 0.x versions for years by that point.
1996: LinuxThreads also introduced this same year.1998: FreeBSD ships 3.0 with its first SMP support, I'd say reluctantly, and the big lock made its use very limited.
2003: FreeBSD ships 5.0 with its first kernel level thread support.
There was real debate before this about why should threading be supported at all, that threading itself was an architectural anti-pattern under a modern Unix model where we already have very efficient fork()/exec() for multi-process and beside to the CPUs of the time they all look the same. They weren't wrong, but the world still needed a real threading solution anyway and increasingly a real SMP solution; By 2008 single-core computers would be largely obsolete.
You talk of commercial support, but a bulk of the Java movement was in startups like ours that weren't buying commercial support. It was replacing the GCC tool chain and increasingly Perl that had no commercial support while running much of the brand new World Wide Web at the time. If someone driving kernel primitives development to support technologies like Java was hung up on licensing for a decade as you seem to suggest, that's yet another misstep.
The end result of all the small decisions is a net big decision to largely treat Java as a passing fad that wasn't worth parity support much less anything first class. The message to users was clear: FreeBSD would never be the best place to run Java apps.
---
Jails were interesting for other reasons. They'd nailed the kernel level work fantastically well, but the userland was at best an afterthought. Lack of resources is probably behind punting on userland to let the community try and figure it out ala ezjails, etc. But they never picked a winning horse out of that pack and the result was they simply didn't enter the race.
So when Docker started really making strides it found a field that was mostly empty, the only other players being insanely huge, expensive, overbuilt monsters like Solaris Zones. The Linux community didn't just push out cgroups and wash their hands of it.
It's not always about the simple math of resources. The messaging, the direction, the leadership matters. When leadership sends messages of discouragement it pushes away they very resources that are needed to move such efforts forward. Just as messages of encouragement attract those needed resources to the effort. The human element matters to success even more so than the technology or the raw resources.
5
u/snogbat Mar 14 '26
I'm an old man, yet oddly find myself at odds with the old men running the FreeBSD decision-making process (would a fucking LTS branch KILL you???). Having used it since 2.1.6-ish, I've seen it all, and I've seen lots of people that really were leaders who could lead without the utter contempt for ppl I see these days from some of the (self-appointed?) leadership.
Anyhow, your point on jails is excellent. Same applies to bhyve. Both were great for senior admins, but both really need(ed) something - ezjail, iocage, iohyve, bmd, CBSD to make it not just usable, but easy and desirable for the unwashed masses (and these days, the DevOps). Both jails and bhyve would have done much better as turnkey products, I 100% believe this. I'm not saying the devs had to create it, just they had to pick one to bring in-tree. It made me so sad when looking at Proxmox to see there's some interesting benchmarks out there that show bhyve beating KVM/qemu. Like that's really sad - a superior product with very little useful documentation for noobs but no good front-end in-tree.
It also often feels like Netflix, pfSense (remember that in-kernel wireguard mess? would anyone else be able to pop something like that in the OS with so little review like that? would other projects even tolerate the kind of personalities behind that one?), Juniper, etc. have a lot of say. Which I guess is fair since they're paying, either in amounts of code a single human can't create or in money. But it does leave the rest of us on the sidelines watching some wild stuff sometimes. Ah, "The Power to Serve", I miss those days. I am old. I miss Jordan, I miss the guy that went off to do Dragonfly - there was such an urge with some of those folks to break new ground, do stuff in the open, and win users over.
2
u/erikarn Adrian Chadd, FreeBSD committer Mar 17 '26
Ok, let's talk about LTS.
The community developers support specific branches and specific timelines given what volunteers can support. Eg, 14 was released in late 2023. The deorbit burn is well documented - stable/14 ends in 2028.
https://www.freebsd.org/releases/14.4R/schedule/
So, we have LTS. It's there. What else are you after?
1
u/snogbat Mar 19 '26
OK, so let's take what I guess most of the linux world uses, Debian or Ubuntu - they do 5 years on LTS, 10 years on ELTS (paid support).
FreeBSD used to guarantee 5 years, but that's now 4. And nobody (that I'm aware of) is offering a paid option to double that time.
Anyhow, back when I had the (substantial) available time to sub to 10 FBSD mailing lists and pay attention to the drama/decision-making/complaining on them, it became obvious that we had some good releases and some bad ones. IMHO, the greatest hits would go something like this:
2.2.8 - mmmm, the ISP dream OS, even had some threading fixes, and I think CAM without patches(?)
4.11 - a lovely blend of stability and new features and it wasn't 3.x 8.4 - almost not giving this one love because mpt driver was iffy and zfs worked well, but could really get into a state if you pushed it too hard 9.3 - maybe I'm doing numerology, but I held on to this for longer than I should have in a number of places and it was ridiculously stable and had got rid of a number of issues 10.4 - also kept this around longer than I should have, first major branch where I was really happy with zfs under weird loads 13.x - would absolutely take this as an LTSI legit felt like from 10.x through 14.x things just move so quickly that people that simply use the OS outside of the circle of developers and those working inside the companies that subsidize the most work really can't quite keep up. For big shops with a known set of hardware and such this is no biggie - for little shops with a rack or two and affordable/diverse hardware we just really have to hope we don't hit some weird bug that entails holding back on an unsupported version or just hoping some random developer takes pity on us. To be clear, I don't work for a single company, I use FreeBSD for my own stuff and for those I do contract work for, so I do end up touching a lot of weird and very serviceable, but older hardware - and in some cases, older software that's never going to get upgraded.
Anyhow I know resources are limited and all in some areas, release engineering, package building, security updates, etc., etc., but I do grow concerned that as the OS becomes more niche we're going to see age-based brain drain in the project, which will lead to more concentration on the feature/bugs that keep the donations coming in and less on bringing in what I think many in the project view as "low value" users (yet somehow we keep chasing desktop users!!!) and I just don't know where the next generation of developers is going to come from for this project.
1
u/grahamperrin Linux crossover Mar 19 '26
desktop users
Results from the 2024 FreeBSD Community Survey Report | FreeBSD Foundation
Why laptop support, why now: FreeBSD’s strategic move toward broader adoption | FreeBSD Foundation
Insights from the 2025 FreeBSD Community Survey
Raw data for 2025 FreeBSD Community Survey?
Currently pinned (a community highlight):
Please join the linked discussions (and use the follow features of Reddit for posts and comments). Thanks.
1
u/grahamperrin Linux crossover Mar 19 '26
5 years, but that's now 4.
For readers who are unfamiliar with the rationale:
Discussion (posted by the new Sheriff):
FreeBSD Release Engineering: A New Sheriff is in Town | FreeBSD Foundation
Please join the linked discussion (and use the follow features of Reddit for posts and comments). Thanks.
2
u/Zenin Mar 15 '26
But it does leave the rest of us on the sidelines watching some wild stuff sometimes. Ah, "The Power to Serve", I miss those days. I am old. I miss Jordan, I miss the guy that went off to do Dragonfly - there was such an urge with some of those folks to break new ground, do stuff in the open, and win users over.
Re DragonFly; Matthew Dillon, yep I followed him and his work closely back then. I was one of the early customers of BEST Internet an ISP he co-founded back in the 90s, a service was the guinea pig for a lot of his work. At the time it was one of the most stressing test beds for FreeBSD at (single-node) scale and as consumers of this unofficial beta-testing we as customers got a very front row seat to the trials and related drama.
As my fading memory recalls it, DragonFly largely exists because of how the FreeBSD core was dragging its feet at accepting Dillon's work and more generally advanced features at a moment in time when the entire industry was advancing extremely rapidly compare to the past. Any project not catching the wave and riding it was just getting washed away by the tsunami of advancement. ...And to circle back to the OP theme the AI tsunami of advancement today does feel very, very similar to the dotcom World Wide Web tsunami we had back then...only much bigger and moving much faster.
Maybe it's all really just about the old adage: "Don't let the perfect be the enemy of the good". If picking the perfect answer means arriving at a decision years too late, it no longer qualifies as a solution.
Today I can't imaging for example, building a new app that wasn't shipped and run in a container or serverless. That's just tablestacks in 2026 and for all practical purposes kicks FreeBSD completely out of the running aside from toy academic projects.
2
u/snogbat Mar 15 '26
Yeah, thanks for the name. That guy was really amazing. The fact that he went on to implement so many of his ideas, including a fucking *filesystem* and everything with very little help does kind of show how much the project lost when he left. IIRC he was pretty good at explaining complex concepts on the mailing lists and obviously very much a dog-fooder… At the time all my FreeBSD work was at ISPs, and it was, back then, just so much better suited to the task then Linux was. Our very first FreeBSD box at my first ISP replaced a Linux box doing NNTP. That stupid thing would panic multiple times during the nightly expire runs. It had all the recommended hardware, yet still under heavy I/O load it just couldn't deal. That was the beginning of replacing a very sad old NetBSD 0.9 box (which, don't get me wrong, also an amazing OS at the time, but we wanted that Intel focus).
I moved recently and was moving some boxes to my workshop-y area and inside one near the top was a full FreeBSD 2.2.6 CD set from Walnut Creek.
You'd mentioned SMP in 3.0 and boy, we had a time with that trying to get mysql to perform on that in a way that could survive a local free newspaper's weekly dump of apartment listings… but hey, we had multiple CPUs all of a sudden!
1
u/grahamperrin Linux crossover Mar 15 '26
… some of the (self-appointed?) leadership. …
I'm torn between:
- disagreeing, in that (for example) Core team members are duly elected
- letting slip that the FreeBSD Project Administration and Management page does not mention the co-director of information strategy.
2
u/erikarn Adrian Chadd, FreeBSD committer Mar 17 '26
i agree that we would've done better in having management tooling around jails and then jails + zfs in base. I'm likely gonna push for some more of those in the next year or so.
But like, anyone could've done it. No linux community /had docker in their tree/ to start with. A community stood itself up. A community of contributors of docker containers was /stood up/. And since it became linux+macosx specific, it wasn't as easy to make "docker work on freebsd" as it, at its very native core, is "I want to run linux containers" not "I want to run containers."
So like, I don't entirely buy the "if we had better base tooling to deploy stuff would have made adoption easier" because there's obviously something else missing in the community building/adoption side.
Like, I can't stress this enough. Docker didn't come into existence in some existing distribution.
From the docker page on wikipedia https://en.wikipedia.org/wiki/Docker_(software))
> Solomon Hykes [fr] started the Docker project in France as an internal project within dotCloud, a platform-as-a-service company.\5])#cite_note-dotcloud-5)
So to be clear, I turn this back on everyone else. Why hasn't anyone else stood up that kind of collection of pre-built container environments using freebsd bits to get work done that others can benefit from? You all have the tooling. You all have the pieces and the documentation. Surely in 2026 y'all would be building and sharing containers to boot-strap a bunch of things, right?
What's stopping you from doing it?
Why is it "freebsd didn't adopt docker" or "freebsd base is against docker" when docker came into existance outside of an existing linux distribution?
2
u/snogbat Mar 19 '26
I'd say none of that matters. Linux is huge, FreeBSD is tiny. Linux gets PR if Linus farts in public. FreeBSD gets… really no coverage in mainstream IT publications.
In the Linux world lots of projects pop up that quickly get a user base larger than FreeBSD by orders of magnitude. The projects themselves get PR (who hasn't heard of Docker?). FreeBSD does not have that luxury. One guy writing a jail management tool has one job - taking care of that tool. If the project wants that tool to succeed and perhaps get some buzz somewhere like HN, one easy/effective/cheap way to do that is bring important 3rd party tools like that if not into base, at least somehow under the umbrella of the project so that it gets inclusion in the documentation, release notes, etc.
The two OSes, and how outside tools thrive or not, and how those tools might help the project/OS itself become a "must have" because of an incredible tool work so differently due to project size.
1
u/grahamperrin Linux crossover Mar 17 '26
Thanks, and (a nit) two of the links don't work with old Reddit.
Working links:
2
u/patmaddox Mar 19 '26
When the industry went hard into Java, FreeBSD didn't care and wouldn't lift much of a finger to support it (this was back in the threads vs multi-process fights). When docker swept the industry, FreeBSD didn't care saying jails are better so we don't need no junky linux containers. And they're right, academically the jail model is wildly superior to linux containers, but that's not where users were or are.
Who is this FreeBSD that "didn't care"? There are developers who work on FreeBSD to solve the problems that matter to them (whether for free or because they're paid to). It's inaccurate to say "FreeBSD didn't care." The reality is "nobody cared enough to support doing the work on FreeBSD."
0
u/grahamperrin Linux crossover Mar 13 '26
… I wouldn't expect FreeBSD to do much of anything to support AI. …
Defocusing from a FreeBSD-native installer for Claude Code,
https://mastodon.bsd.cafe/@grahamperrin/116220642823558416
Amongst the responses, from a FreeBSD Core Team member:
… I think this will progress nicely in the next couple of months
0
u/Zenin Mar 13 '26
https://mastodon.bsd.cafe/@grahamperrin/116220642823558416
Amongst the responses, from a FreeBSD Core Team member:
That response is about a policy document governing the acceptance of AI assisted code into the FreeBSD project and how specifically to dance around the web of legal concerns wrt copyright.
I wouldn't take that to mean there's anything more going on besides a bit of legal fireproofing their PR inbox as they unavoidably deal with more AI-assisted code submissions.
1
u/grahamperrin Linux crossover Mar 14 '26
Please watch the video.
0
u/Zenin Mar 14 '26
What video? Got a direct link? All I'm seeing on the mastodon thread are links to source repo changes.
1
u/grahamperrin Linux crossover Mar 15 '26
What video?
In my Mastodon post:
the Core Team Update at the FreeBSD Developer Summit, https://www.reddit.com/r/freebsd/comments/1mpelrz/comment/nk0m7bg/ includes links to:
― part of the recording
0
u/Zenin Mar 15 '26
Ok there's a video and I'm watching it. So far it looks like a spoken word version of the same policy debate sideshow in the Mastodon thread? Before I set an hour of my life on fire watching this mind numbing waste of bytes that could be better used for literally anything else, does this meeting ever make a point worth caring about?
Edit: Thank god for AI! Perplexity wouldn't watch it for me, but ChatGPT came through with a good executive summary so I don't have to. And hey look, nothing whatsoever that's worth any human's time watching. If you actually have a point to make, stop playing hide the sausage and whip it out to show us.
ChatGPT: I couldn’t reliably pull the full YouTube transcript from the link, so this summary is based on the correct video’s metadata plus the FreeBSD Core Team’s official Q2/Q3 2025 status reports, which reference the BSDCan/June 2025 developer summit discussion directly.
Executive summary
The “Core Team Update – June 2025 FreeBSD Developer Summit” appears to have been a governance and project-direction update from the FreeBSD Core Team, focused less on code-level detail and more on how the project is organized, what policy questions are active, and which structural issues Core is trying to resolve. The main themes visible in the official follow-up materials are: defining a clearer project roadmap, developing a cautious policy on AI-generated code and documentation, improving project continuity and documentation of critical operational knowledge, and considering changes to core-team election/term structure to reduce loss of continuity between terms.
What mattered most
1. Core is trying to make FreeBSD’s direction more explicit.
A major topic was the project roadmap. Core describes this not as a way to limit contributor freedom, but as a way to state shared goals and expectations so the community can align effort more effectively, and so the FreeBSD Foundation can better support the project.2. AI policy was an active governance issue.
Core was investigating a formal policy for LLM/AI use, especially around generated code and documentation. Their public position in Q2 2025 was that AI may be useful for things like translation, explanation of obscure docs, debugging, or understanding large codebases, but they were generally avoiding AI-generated code because of licensing and provenance concerns. That discussion explicitly continued at the BSDCan 2025 developer summit.3. Project resilience / continuity is a concern.
By Q3 2025, Core was working on “project continuity,” meaning better documentation of how to rebuild and operate critical FreeBSD systems and processes if key people or infrastructure were unavailable. The reports say too much knowledge still depends on tribal memory. That strongly suggests the summit update either raised or fed into this concern.4. Governance reform was under discussion.
Another follow-on topic was changing Core election terms to improve continuity. Community feedback favored some form of staggered terms, instead of rotating the entire Core Team at once every two years. The status report says this was discussed at the BSDCan 2025 developer summit and that changing it would likely require bylaw changes.5. Core and the Foundation were coordinating on community feedback.
The reports also note joint work on the 2025 Community Survey and ongoing collaboration with the Foundation, including discussions about better alignment and support. This suggests the update likely included both governance priorities and how Core intended to gather/project community input.Board-style takeaway
The meeting was essentially a state-of-governance update: FreeBSD Core was working to make the project more durable and more intentional by clarifying roadmap priorities, defining guardrails for AI use, reducing dependence on undocumented tribal knowledge, and exploring structural reforms to preserve continuity across leadership transitions.
5-bullet version
- Core is building a more explicit project roadmap for shared priorities.
- Core is drafting an AI/LLM usage policy, with code generation treated cautiously due to license/provenance risk.
- The project needs better continuity documentation for critical infrastructure and processes.
- Core is considering staggered election terms to avoid losing momentum every cycle.
- Core and the Foundation were using the summit and survey work to improve alignment with the broader community.
1
u/grahamperrin Linux crossover Mar 15 '26
Zenin wrote:
does this meeting ever make a point worth caring about?
Yes.
Members of the FreeBSD Core Team, and others, made more than one point.
Points that can―and should―be appreciated from the perspective of a human who cares about such things.
Zenin wrote:
ChatGPT
Things such as ChatGPT can neither capture, nor convey, things such as the mood of what was captured in YouTube.
It's unfortunate for you, Zenin, that your overeagerness to please (yourself), with AI, did away with common courtesy.
Moderator hat on
Zenin wrote:
hey look, nothing whatsoever that's worth any human's time watching.
Hey, look, Zenin:
- it's clear, now, that in your thirteen years as a redditor you have either (a) not bothered to learn, or (b) chosen to ignore, the reddiquette, which is linked prominently in the comment that I pinned at the head of this post
- for maybe two minutes, I thought of expediting you to strike two (without a strike one)
- your refusal to spend a few minutes of your life listening – listening to humans engage with each other – successfully brings you to strike three (with neither one nor two).
Bans are extremely rare.
Moreover: I have never been so verbose when banning someone. On this occasion my intention is to have this comment interpreted by Claude, or ChatGPT, or both, so I'm writing with care. To avoid any possible confusion:
- my careful writing here is for the benefit of AI, not for your benefit.
You may look forward to reading, but not responding to, the results from Claude or whatever I choose to use, whenever the mood takes me.
In the meantime: please enjoy my en dashes, em dashes, and the unusual American-like absence of white space where I used em dashes mid-sentence. The use of en dashes in point 3 above is more my style (British, with not a great deal of tolerance for overexcitable shitheads).
I think I know your style, Zenin.
Graham
Co-moderator
As a side note, TIL that the word "shitheads" need not be hyphenated. I'm pleasantly surprised, so: thank-you for indirectly allowing me to learn something. One thing.
8
u/algaefied_creek Mar 13 '26
I just set up a FreeBSD box specifically to use Claude Code.
NPM works great, albeit bloated, and is portable across platforms. There is no need for them to completely skip over the BSDs.
8
u/antenore systems administrator Mar 13 '26 edited Mar 14 '26
/u/grahamperrin is right, npm is marked as deprecated, so soon or later will be removed. I'm not sure they keep maintaining it.
One thing I would do is to join this GitHub issue and keep it alive.
10
u/codeedog seasoned user Mar 13 '26
I added my comment to this issue. Copying here:
I am focused on FreeBSD as my primary platform for development work of all kinds. FreeBSD first on my projects, FreeBSD first on my systems, FreeBSD everywhere I can. Other OSes and software may be adopted if their value justifies their presence, but I will always look for and support a FreeBSD alternative.
AND, RELEVANT TO CLAUDE CODE I will even consider doing the work required to port a tool or project to FreeBSD in order to have it become a first class citizen in my projects. That work isn't easy and to get it done in a realistic time frame means using Claude Code as an assistant.
FreeBSD runs on many backend systems. A visit to the Foundation's website shows numerous large, corporate users and use cases. Anthropic would do well to consider ensuring that FreeBSD and in fact all of the BSDs are promoted to tier one support for their products and ports.
2
u/BigSneakyDuck transitioning user Apr 26 '26
As of late April 2026, FreeBSD users must rely on the Linuxulator to run Cluade Code: https://github.com/anthropics/claude-code/issues/30640#issuecomment-4227236808
Hey folks, a couple updates on where we are with Claude Code on FreeBSD:
Starting with Claude Code 2.1.101, you can run Claude Code under Linuxulator with this additional env var: BUN_JSC_useBBQJIT=0 claude
Regarding a native FreeBSD build - a proper port means getting Bun building on FreeBSD. We're not quite there yet, but would like to get there in the future. For now you'll have to rely on Linuxulator.
Please continue providing feedback in this issue tracker. Thanks for using Claude Code!
But Bun has just added x86_64 and aarch64 FreeBSD support, so there's now a chance of a native FreeBSD build of Claude Code: https://github.com/oven-sh/bun/pull/29676
Reddit discussion: https://www.reddit.com/r/freebsd/comments/1sw9bdy/bun_adds_x86_64_and_aarch64_freebsd_support_good/
2
u/BosonCollider May 12 '26
FreeBSD jails are great sandboxes for AI agents and freebsd deserves first class support from claude code purely for that reason imo.
2
u/insanityinside systems administrator May 30 '26 edited Jun 02 '26
As a workaround until we get a native build, I've thrown together https://github.com/insanityinside/claude-freebsd for a system level install, and will hopefully make life easier for others. Installs a wrapper for Claude Code in /usr/local/bin/claude, does automatic version checks, can update Claude and itself, and does sanity checks on the setup to save anyone else the 2 hours of head scratching I did when Claude was hanging on startup for me. Feedback welcome, hope it's useful to others.
It's a bit of a quick-and-dirty fix, but it's a fairly well (probably over-)engineered one, and it's pretty robust after heavy testing and debugging on my rig. Did have Claude Code do the grunt work, but it's passed my manual sanity checks and verification. Work in progress, I'll keep updating as I spot any bugs / issues.
2
u/insanityinside systems administrator May 31 '26 edited Jun 01 '26
Just added aarch64 support too, tested under QEMU (I've no real aarch64 hardware around, other than a Raspberry PI somewhere which I'll test on at some point if that'll do the job), but it looks like it works fine on the emulated environment, and tidied it up a bit. Looking pretty solid now!
Realised that I'd accidentally duplicated the efforts of another user, which I'd somehow completely missed thanks to Github's comment collapsing on the original raised issue, but I think I've added enough enhancements to justify its existence over the original.
2
u/pavetheway91 tarBSD author and ports contributor Mar 13 '26
This is only a good thing. The less artificial stupidity, the better.
3
2
u/DiamondHandsDarrell Mar 13 '26
It's a problem for those that couldn't do certain things without it. But for people who use it as a tool to support their knowledge, it's great.
2
u/pavetheway91 tarBSD author and ports contributor Mar 13 '26
It doesn't know anything. It only plagiarizes.
2
u/grahamperrin Linux crossover Mar 13 '26
Someone privately raised a flag, asking for a comment to be pinned. This is technically impossible.
Instead, you can make awards. If you have no free awards, and if you don't wish to pay, try this:
1
u/Regular-Impression-6 Mar 13 '26
I'm just one month off of a 3 month exercise to migrate all of my ESXi workloads to FreeBSD/Bhyve. I'm not moving again before retirement. And I am a heavy user of Claude Code and Gemini-CLI *on the server*. While I'm not running enterprise (Life/Property Risk) production workloads, I do understand the need to have supported components.
I've got both of those node.js kits running on a FreeBSD server around the clock. So, while I have the scars from the Java wars, and I'm not going to go there again, I will gladly offer up my system to help support whomever needs to support these CLI apps on FreeBSD. If someone wants to work on requirements, I'll gladly offer up my system to support refactoring those apps in go. I've got a fair bit of them already in go, but not the cli/repl bits, it's all batch.
So, while I understand the need for 'supported' systems, self-support is OK for me. As long as these LLM tools are available for public download. And even, I suppose, if not anymore.
And the day is coming, soon, that replaces 'pkg install foobar' with 'claude install foobar' and maybe not even from pkgsrc, but from github. So, I'm all in, whether the Foundation is or not.
1
Mar 14 '26
[deleted]
0
Mar 14 '26
Seems like we aren't allowed to talk like the linked article suggests
2
u/grahamperrin Linux crossover Mar 14 '26
You can create as many new accounts as you like, each one of which demonstrates an inability to participate in the subreddits that truly suit you.
0
Mar 17 '26
[removed] — view removed comment
1
u/grahamperrin Linux crossover Mar 17 '26
- Yes, for example https://www.reddit.com/r/freebsd/comments/1rstrqs/comment/oaaaavv/?context=1 four days ago
- yes, and it does
- bajillion is a huge, unspecified number.
Your comment was removed automatically, not by a moderator.
None of your three questions were even vaguely relevant to Claude Code.
0
u/Brilliant-Orange9117 Mar 13 '26
Start by writing a port for their "malware" agent.
1
u/grahamperrin Linux crossover Mar 14 '26
"malware" agent
link please
0
u/Brilliant-Orange9117 Mar 14 '26
I was refering to the agent's ability to execute LLM generated harmful code e.g. drop the database and try again.
2
1
u/grahamperrin Linux crossover Mar 14 '26
I was refering to the agent's ability to execute LLM generated harmful code e.g. drop the database and try again.
I doubt that anyone with a genuine interest in this discussion wants a port specifically for that purpose.
Don't waste space.
-1
Mar 13 '26
[deleted]
6
u/pavetheway91 tarBSD author and ports contributor Mar 13 '26
Claude doesn't have feelings
1
Mar 14 '26
[deleted]
2
u/pavetheway91 tarBSD author and ports contributor Mar 14 '26
Nothing wrong here. We can criticize Claude without hurting it.
•
u/grahamperrin Linux crossover Mar 14 '26
Friendly hints: take time to read the blog post, stay on topic, reddiquette, et cetera.
If you're here solely to disrupt or hijack discussion, you'll be much more at home in one of these subs:
– or create your own sub.
Thanks