This week in NextBSD July 10 2026 edition - Gershwin integration focus

[pkgdemon]

In June's GNUstep monthly meeting I started talking for a bit about the re-imagined take on NextBSD that I had been working on. It resulted in some attention on reddit, and other avenues. I thought it might be worthwhile to consider doing a series of status reports here until the roadmap is more formally updated for those interested.

The feedback produced by the awareness also did motivate me to fix certain things sooner. Originally I had planned to port Darwin's system_cmds, network_cmds, advanced_cmds and other things to replace more FreeBSD userland. The previous approach created a whackamole situation with compiling all the right libraries, and getting all the essential tools in place for daily driving. I decided to back this away for now and produce a full freebsd world instead with certain components removed that this project replaces instead. This has proven to be a much better approach while the focus is a superset of things like IOKit, launchd, configd, IPConfiguration, MDNSResponder, and things like that anyway.

As the next GNUstep meeting starts tomorrow I wanted to get Gershwin and up and going on top of NextBSD so I showcase that. While I did achieve the ability to install and make gershwin-on-nextbsd images this month that can also be installed, I discovered some last minute blockers to setting up a system to fully screenshare with audio, as well as some other issues related to linker items conflicting when Gershwin is installed. I am therefore not sure how much I will be able to share by tomorrow if it any as I may need to use another device for audio, etc. Hopefully @probonpd will be be able to join to show off the really amazing things he has added on the Gershwin Desktop side of things better than I will be able too given the state of my daily driving devices, and other issues I have to focus on.

Today I am working on nextbsd-userland repo to fix CI. There were some notable real failure points with notifyd, syslog that required fixes to the HAVE_MACH version of libdispatch included in the same repo. One of the next things to address is to make these libdispatch soname's unique so that they do not get picked up by Gershwin itself, or other applications that cannot use the MACH path. This will fix the issue I was seeing where sourcing GNUstep.sh breaks launchctl list, broken libxpc, sshd, notifyd when Gershwin is installed on top.

Before getting to the soname fixes. One thing I encountered recently while adding manages for nextbsd-userland was that I broke the packages that nextbsd-pkg produced. It produced packages that conflicted with each other. So it's on my mind to also add CI for this that installs the packages before publishing the packages that ISO builds, or pkg upgrade on an existing installation would ingest.

I've also noticed that certain packages like claude-code require rocky linux base fail to install because the pkg install scripts require linux kmods to be loaded and NextBSD produces kexts only at the moment. This is something after I fix Gershwin integration, after I figure out why my sound doesn't work I intend to look at, and consider the right fix for. It might be that a dual existance of kid's will be required for certain things, or that further linux support can be baked into kernel. This is definitely something that will have to be a next week focus type of thing.

Likely chasing that will be bumping drm-kmod to 6.12 and adding nvidia kernel extensions so I can daily drive on more of my hardware. I have two systems up and running now but I am hoping to have 4 systems up and running by then. So my immediate focuses aside from Gershwin are really centered around daily driving abilities as well as maintaining a functional preview by having CI at all stages. After this I am not sure which way the wind will blow but here are some various ideas since I can only do so much each month.

• Extending the implementation to support Wifi and bluetooth
• DirectoryServces from Darwin vs Gershwin decision and implementation for user accounts (leaning towards porting Darwins and adding my innovations on top for the 4 domain network computing model concept)
• Custom package repo for ports
• ARM64 ISO focused on fully supporting UTM on macOS
• Local building

All of these continue to extend my ability to daily drive and iterate. I am thinking the next logical step after at least these things minimum would be developer focused documentation, and then user focused documentation to co-incide after. I think this is more or less where the core implementation starts to freeze enough that I can do those things. I am expecting to get somewhere each month, but maybe more realistically 3 months gets things to a more consumable place.