the BSDs in the AI Age

[Craig MacGregor]

"Claude, remind me how to configure Thunderbird so I don't top-post... 
it's been a while since I posted to the NYCBUG list"

>> - How well do LLMs answer questions about BSD specific technology?  Or how
>> exact are they when answering questions that could also be for Linux
>> systems?  This one might be enraging, as in "check your systemd settings to
>> tune your ZFS pools..." or some such.

This January, cleaning out some old junk from my mom's basement, since 
I'm funemployed at the moment... I found an old DLT tape drive and some 
tapes I probably picked up at thrift store in the early 2000s... got a 
SCSI PCI card working in my oldest 64-bit machine, and was able to read 
the tapes. The only interesting one is a tape backup of an ISP's admin 
server circa 1996. I extracted everything, tried to run an ancient 
BSD/386 installer on QEMU, but gave up pretty quickly, and just left it 
unfinished.

To be clear, I was a bona fide AI hater; I still don't think that LLMs 
will ever achieve "AGI", and other than (and often including) code, most 
of what they create is "slop"... but I'll save that for the "AI 
apocalypse" thread. But, I bit the bullet and finally tried Claude at 
the urging of a college friend, during the blizzard in February. When I 
pointed it at the tape dumps and restored fs, within like an hour, I had 
a modern NetBSD QEMU guest running, a custom kernel with EXEC_AOUT and 
COMPAT_NOMID enabled, and I am able to chroot into the vintage system, 
and run most binaries.

Could I have figured this out on my own? Sure, but it is unlikely I 
would have. I haven't been working on any other BSD-specific projects 
lately, and I really wasn't working on much at all before I got bit by 
the Claude bug, but since mid-Feb:
- a Linux kernel driver for an old USB modem/skype adapter, so that I 
can use an old phone as headset
- a bluetooth app which presents the linux->usb->phone setup as a 
bluetooth headset, so that I can pick up the receiver, hear a dial tone, 
and use it like a landline
- various crazy TTF font projects (trying to get old timey win2k 
non-anti-aliased fonts working 100% in modern Linux, and particularly 
Chrome/Firefox)
- a tongue-in-cheek "National Food Days" notifier for Slack
- various Arduino/RPi hacking, as well as rooting a cheap wireless 
carplay adapter
- installing/configuring old routers as openwrt devices
- porting the old SGI "fsn" 3d file system viewer (famous from Jurassic 
Park) from just the binaries (work in progress)
- asynchronous socket multiplexer using pipes for single threaded 
scripts (a project for which I wrote a perl proof-of-concept over a 
decade ago)

As for Claude confusing Linux/BSD... it gets confused on Linux with 
itself all the time, so I doubt it is any different.

>>> * How should the BSD projects themselves be using LLMs? Integration in
>>> the shell (oh, please no...)? Porting of APIs for big tech LLMs?
>>> Utilizing LLMs to discover bad code, CVEs, undiscovered vulnerabilities?

Yeah, even the big companies seem to be backing off on "AI in every 
button" already, this stuff is great when 90% right is good enough; 
iterative code development in particular. But I'm not letting it drive 
*anything* other than dev/testing (including a car, heh).

>>> * How should individual developers and users consider LLMs as tools for
>>> contributing to the BSDs and other open-source projects? I happily used
>>> a big tech LLM to deal with an rc file for some very Linuxey software
>>> wrapped up in systemd clutter.

Do I feel like I wrote all this code? Yes and no, some of these projects 
I audit every line, others I read none... the line between "toy" and 
"real development" is pretty much the same as it always was, do you 
understand the code, or are you just plugging in what works? So even 
though I had it write a Linux kernel module, the usb->phone adapter is 
decidedly a "toy", and I've tested it to that extent... and for old 
hardware, I think that is enough to release it (not in the kernel 
itself, of course). If you work with Claude like a fellow engineer, and 
force it to consider the how, and not just the what, review what its 
doing, and constantly test, you can get some truly amazing results.

-craig