GNUstepOfficial meeting minutes

[Rhetorica]

On Saturday, Gregory Casamento posted a recording of a two-hour meeting from a group of GNUstep developers. Since the video is rather tedious to watch I thought I'd summarize some of the highlights in a post here. (And maybe this can be a recurring thing...)

(Note: the meetings are official. These meeting minutes are not.)

GNUstep AppImages

Though they are often miserably bulky, self-standing software containers like docker, flatpak, etc. enable portability across Linux distributions. Hitherto this has not been attempted for GNUstep applications, and some work was required to make it possible. An AppImage of (drumroll) PicoPixel has been completed as a proof-of-concept, which includes everything down to ld-linux.so and glibc, so it should run on just about any Linux distro, and possibly even some BSDs with the right support framework on the host side. The GNUstep AppImage overhead is around 45 MB, which is not nothing, but is pretty good compared to some other packaging systems.

Needless to say, allowing end-users to bypass the tricky step of installing an entire platform ecosystem will be very valuable in increasing adoption—and these efforts might dovetail nicely with the recent port of Ladybird to GNUstep, which compiles much faster than the official (Qt-based) Linux port... but more on Ladybird later!

Theoretically these AppImages might even run under Windows via WSL2, but there have been some headaches since Microsoft made Wayland the default for WSL2. There was a fair bit of concern in the meeting about working on GNUstep's Wayland support, and the general problem of how Wayland's design decisions are somewhat at odds with features GNUstep and other desktop environments require.

The next AppImage that Twilight Edge plans on creating is probably GMines.app.

[Rhetorica]

Gershwin

The Gershwin project, mentioned here, is an initiative by some of the GNUstep maintainers to build an OS X-like desktop environment. The main project currently is developing the theme, "Eau" (like Aqua, but French), which aims to implement as much of the OS X look-and-feel as possible, including behavioural things like menu functionality, while minimizing the amount of work necessary for developers to bring existing GNUstep programs into the Gershwin fold.

Gershwin-related notes from this meeting include:

• Choosing a set of fonts and where to store them.
• The /System, /Local, /Network directory layout is back in a big way.
• a (no-doubt not-coincidental) concern about ensuring window resize handles are easy to see and grab,
• usage of the XCBKit-based uroswm window manager (which means Gershwin is still X11-based for the time being)—this will hopefully be theme-agnostic eventually, plans for compositor support and (secure) X11 namespaces. Window decorations are native GNUstep objects instead of the chimerical thing that WindowMaker offers.
• The global screen-top menu bar implementation is confirmed working with Chromium, GIMP, VSCode, and more; currently uses DBus but they hope to get rid of this dependency later.
• The standard modifier key for menu hotkeys is Command rather than Control as in stock GNUstep.
• Menu search is implemented (and very convenient) but still needs interface work.
• What happens when you double-click an ELF binary with no executable bit? Most desktops will just try to open it in a text editor or something; Gershwin will offer to set the executable bit and run it.
• If no console window or interface is created for an executable that the user launched, but it outputs stuff to stderr, then Gershwin will show the results (including the exit code) in a dialog when the process terminates. (Conversation around making sure this text is easy to copy and send to a developer. Classic bikeshedding stuff.)
• Basic System Preferences implemented for dev system (Raspberry Pi 500+ running Debian), including sound, network, wifi, printers (CUPS), keyboard layout (including a checkbox for reorganizing Alt and Command if you're on a Mac), global shortcuts, and more.
• Division between Applications and Utilities. Utilities include Screenshot (a far cry from Grab.app, but hey, it's good to see one at all), NetworkBrowser (Bonjour), RemoteDesktop (client for VNC with untested RDP support).
• GWorkspace fork: just called Workspace. Can't be upstreamed since it deviates substantially. It can mount archives and disk images, and the trash icon turns into an ⏏ Eject symbol when media is dragged over it.
• Dock: respectfully handles non-GNUstep X11 applications with a minimal .app bundle wrapper (appwrap tool for creating these). Bounce animation very much enabled until the first window appears.
• Network integration: services discovered via zeroconf. Easily mount sftp, WebDAV (untested), and (in the future) afs. Also manually connect via URLs.
• Support for "show in file browser" functionality common in Browsers; requires DBus.
• Spatial mode: one window per directory. (Not an OS X thing, but certainly very Mac-y.) Icons and windows remember their locations correctly, using reverse-engineered .DS_Store files. (For real!) — this also comes with background images in .DMGs etc.
• Windows close automatically when the volume containing them is ejected! (This comes up around 1:11:40)
• Other dev QoL: plistupdate tool, GUI testing framework ("like Selenium", currently built into Workspace)

Although Gershwin is far from done, the developers are now dogfooding it and using it for its own development, so it may be worth trying out in a VM. It genuinely sounds like a better experience than most smaller Linux desktops, and the developers assert they're trying to keep it OS/hardware agnostic by switching platforms regularly. Live ISOs exist (of the Debian on Raspberry Pi 5/500 stack), available on request for people who are committed to participating in testing; they're not for general consumption. There's an Arch-on-Intel ISO build also, but it was broken at the time of the meeting.

For pursuing involvement, #gershwin on irc.libera.chat:6697 (TLS) is the way to go.

[Rhetorica]

Ladybird on GNUstep

Here it is!



(Note the extremely placeholdery titlebar and tab strip.) The port is described as having been "surprisingly easy." The APIs are around 80% the same, and the Ladybird team is responding positively to upstreaming the GNUstep port into the official repo.

Lars (I think this is Lars Sonchocky-Helldorf) was self-described as "speechless" after the Ladybird reveal, comparing Gershwin to how past GNUstep desktop projects had failed long before reaching this stage of maturity.

The final half hour of the meeting was spent discussing minutiae of aesthetics and desktop paradigms for Gershwin, such as the spatial metaphor and how to make it unambiguous when enabling or disabling it. The goal of making something approachable to Mac users without being beholden to copying specifics was reiterated, e.g. avoiding the custom of hiding menu bars behind hamburger menus or sacrificing usability in the name of shiny chrome. It was noted that open source projects, fortunately, do not need to impress investors or customers with visual novelty and can emphasize doing the right thing over the popular thing. One person (the individual responsible for the AppImage bundling) mentioned scrutinizing vintage OS X Kaleidoscope themes for inspiration.

[ZombiePhysicist]

Super cool project! I hope it gains traction (and tear off menus 🙃)!

[Rhetorica]

Another GNUstepOfficial meeting was posted today. Here are some highlights:

Gregory Casamento is working on NSDiffableDatasource still. This is a performant cache for table views that triggers updates when its dependencies change. They were mentioned last meeting offhandedly as a WIP.

He also finished a working implementation of NSDataLink, which is the dumbed down OpenStep version of the ObjectLinks that Steve Jobs showed off in this NS3.0 preview video. Transport mechanisms like this are notoriously tricky to keep functional in heterogeneous networked environments, and sadly they were removed entirely in Cocoa. Microsoft's DDE was primarily used for similar functions, but was much less comprehensive in what it could do. Today features like this only exist in a handful of commercial applications in very narrow contexts, like Photoshop's Smart Objects—a clear-cut example of 90s tech being superior to the modern day. The file AppKit/Draw/Links.rtf from OS4.2's NextDeveloper documentation relates that full ObjectLink support was still tentatively planned for OpenStep at some point but never got finished, and warns that the code in the Draw example may not compile by the time it ships because the code refers to unfinished APIs that might have been renamed.

Gregory also reports that he has encountered disappointments when asking LLMs to generate Objective-C code. This isn't terribly surprising since there's a lot less Objective-C out there than other languages, and it is no longer the primary language for Mac or iOS application development. (Moreover, it seems likely that one will get a mixture of different API versions when trying to generate code—possibly this is what he encountered, though he doesn't elaborate.) Lars feels that the new Kimi Code model does a decent job at porting C to Obj-C, however, and suggests Gregory try it.

While explaining the purpose of the GNUstep project (which is now defined as "making Cocoa applications portable") Gregory incidentally noted that he used to work for Keysight (formerly Eggplant), on the same product, Keysight Eggplant Test, where Doug Simon of HyperSense fame ended up. Small world, huh? (Their Windows version uses GNUstep.)

From the Gershwin team, an MCP server was implemented, allowing for AI agents to remotely control the Linux desktop, including GNUstep applications. The demonstration did not go too well (somehow the AI selected a work-in-progress port of TextEdit from later Intel-era 10.x Apple sources instead of a standard build, and didn't get much further) but we can assume that this is something the Gershwin folks intend to get working in the future. They also fiddled with their directory layout (trying to get it right) and have undertaken an initiative to upstream as many changes as possible, undoing some of their libraries that were previously forked. However, they are retaining a forked libdispatch since they've been able to get its CPU usage very low (1-2% on a Core 2 Duo), though they might be able to push that upstream.

probono also reports that Gershwin now builds on a fairly small Raspberry Pi system (4 GB of RAM) in around 10 minutes on FreeBSD. It also runs on half a gig of RAM at a usable speed, though he notes that it's probably not ideal for web browsing in that configuration!

[Rhetorica]

...and it turns out that video was rather short because it is only Part 1. Part 2 is much longer.

Around this point the conversation turns to web browsers; there is a bit of discussion about how the world ended up being dominated by forks of the rendering engine from Konqueror, the throw-away KDE browser that not even KDE uses anymore.

The question is posed as to how hard it would be to repackage Ladybird's renderer into a reusable WebKit framework—Joe thinks it shouldn't be too hard, since Ladybird has a good, modular design already. There is an ongoing issue on the Ladybird GitHub repo for officially merging GNUstep support into Ladybird; no objections have been yet made to the notion.

Adrian Gjonca remarks he has implemented a version of Conway's Game of Life in GNUstep and is interested in making it a screen saver but needs a framework for doing so. Gregory suggests a module for his InnerSpace implementation (think GNUstep BackSpace—I've never gotten it to work personally) which is similar to the Screen Saver framework from OS X 10.0+.

Gregory talks a bit about Gorm (GNUstep Interface Builder) and how Apple's switch from self-serializing classes to Xcode doing the serialization itself has opened the door to Gorm doing the same, meaning AppKit and Gorm no longer have to be updated in lockstep. He is currently working on XIB support in Gorm, though it is still very unstable.

probono starts a Gershwin demo at 35:25. 

[post to be continued]

[Rhetorica]

The Gershwin demo reports that Chromium now sends its menus to Gershwin using DBus, native apps now use GNUstep objects to send menus (more efficient), and an app menu now exists:

Also in this screenshot, file icons depict the associated application.

Next, a quick ItemFlow demo. This is super slick, animates smoothly, and will be immediately comforting to iTunes and iMovie users:


It is implemented using OpenGL and fully accelerated.

As you may notice in the above two images, they also switched away from OS X's 'traffic light' titlebar widget paradigm to an organization that (counterintuitively) is a compromise between classic Mac and CUA/Motif/OS2/Win≤3: top-left close, top right minimize and maximize (contrary to NeXT and classic Mac, which put minimize/roll-up rightmost.) Windows also snap to the edge of the desktop!

They also added this mighty slick alt-tab switcher. Very pragmatic and no-nonsense, reminiscent of the traditional Windows 9x switcher:



Theming is a bit hard-coded at present; Gershwin's WM can't yet swap them on the fly, as button positions may need to be recalculated. But that's something they'll still work on.

probono next mentions that .iso and other disk images can now be written to storage volumes like USB sticks directly in the UI, which helps when iterating on new bootable live media. No more fooling around with dd—just drag the .iso icon onto the disk icon.

A bare-bones processes manager window:


A drawer pops out with details when a process is selected, and a very helpful Force Quit button:

(At that point, the Gershwin demo machine fell over, and probono had to spend a little bit restarting everything.)

[to be continued...]

[Rhetorica]

The back half of the Valentine's Day meeting was mostly housekeeping. GhostBSD has a Gershwin spin, and a developer from the GhostBSD team, Brian (probably brianthehughs) showed up in text to spectate, and will likely participate more fully in the next meeting.

Fred Kiefer popped in to admonish Gregory for committing an experiment with an LLM (a commit on NSDiffableDatasource that evidently functioned but had horrible code) to the GitHub project. This was not pleasant code to review. They resolved to be much more reserved about playing with AI coding in the future, particularly considering the general weakness around Objective-C specifically. Gregory noted a number of systematic errors.

More generally, Greg proposed restricting commits to the master branch in favor of a pure PR model; Fred felt it was perhaps excessive; Lars and Joe were on the fence. (It seems only Gregory understood what it actually entails—it's definitely a good idea. Hopefully they come around to it eventually.)

Afterward the conversation moved to a recent merge that changed menu behavior—it removed the ability to open a menu by simply clicking it (requiring the button to be held down), which is a pretty annoying thing on a trackpad. Fred mentioned that edit wars (people repeatedly submitting "fixes" to make the OS behave the way they wanted) were a real concern back in GNUstep's early days, and acknowledged that PRs would be a good way to fix it. Since the committer has been hard to reach, they're thinking of just reverting it for now—possibly quarantining it in its own branch—and dealing with it if the person responsible resurfaces. This annoying tweak has been in GNUstep for about a year, but Gershwin's devs had been insulated from it because they were using forks of the libraries in question. (It's probably in the latest versions of @wmlive, to be honest...)

There wasn't much else beyond that—just miscellaneous housekeeping and something mysterious about menus being shifted upward by 1 pixel under the Windows skin. Until next time!

[Rhetorica]

Saturday's meeting was posted yesterday. (Part 1, Part 2.) Here are some highlights:

- Greg has been working on an updated port of MusicKit; he's nostalgic for some NeXT DSP demos and wants to hear them play under GNUstep.
- He's also continuing to work on more NSDiffableDataSource stuff; view cells and working refresh.
- Joe has submitted updated Gershwin for the next GhostBSD community spin, which will be based on FreeBSD 15.0. The current GhostBSD Gershwin ISO is fairly outdated and missing the innovations from the past two meetings. (Not out yet at time of this writing.) The maintainer of GhostBSD is considering deprecating the status of MATE as the default GhostBSD desktop due to its stagnant nature, which would leave Xfce and Gershwin as the main contenders to replace it. Discussion went on for some time about what Gershwin and GNUstep work would be required to earn this position, including sore spots in stability, reliability when switching between GNUstep and non-GNUstep applications, missing interface features, and printing.
- This led into a conversation regarding deficiencies in GNUstep printing; Gregory noted that visual themes can often adversely affect GNUstep printing output (and wants to do some tests to figure out what macOS and Mac apps currently do to sanitize PostScript when generating printable versions of documents) and that there are problems with pagination. They agree there is a lot of investigation to be done to get familiar with the code involved and wonder just how important printing really is as a priority for a modern desktop OS—aside from converting documents to PDF, anyway, which is still definitely desirable. Still, there's nothing like a dead tree in your hands for reading documentation...
- Lars reports he's been working with Riccardo Mottola on a new document-based (presumably NSDocument-based) help viewer application; they've added search functionality to it. It uses XML files that it parses into rich text, which can be bundled with images for an experience similar to an early webpage—you know the sort. It also supports translations. The UI is shown here, with a snazzy resizable Miller column view, a bit like how documentation was embedded in OpenStep and Rhapsody versions of Project Builder.
- Lars also reports some weird behavior around font size changes. Evidently the height of the line before a word-wrapped line gets affected by larger text size immediately after, which, due to the way images are embedded in rich text, as substituted characters, affects lines of text preceding them. Riccardo has been banging his head against this code for months, which is a goto-infested morass. In Part 2, Riccardo arrives, and the second half of the meeting is totally dominated by discussion around this problem, and other matters relating to the HelpViewer project.
- Twilight Edge has been working on a Debian script to automatically wrap GNUstep apps into containerized AppImages that can run without GNUstep installed. (Work on this was teased two months ago.) It can now handle most of the apps in the GNUstep Application Project. The script is here if anyone wants to try it out, providing packages of GMines for both aarch64 and x86_64 as demonstrations. (Insert joke about Electronic AppWrapper here.)
- Oolite gets a few shout-outs. This is an Obj-C based space trader game (oolite being both a kind of rock and a contraction of Object-Oriented Elite.) It is notable for being free, being portable, running on GNUstep, and having cutting-edge 3D graphics—by which I mean Quake III graphics. Greg notes there's an OpenGL racing game that runs on GNUstep, CoreBreach, which is a Wipeout-like game.

In all, this meeting was fairly quiet (by Greg's assessment), perhaps due in part to the DST switchover. They hope the next month's meeting will be more eventful.

[ZombiePhysicist]

Thank you so much for all these updates and links. It is super cool and appreciated as I dont have the time to sit through the full videos, wish I did. It's great to see peeks at how the sausage is made!

[Rhetorica]

Notes from GNUstepOfficial 2026-06-13

EDIT: It seems probono made his own notes on this meeting here: https://gist.github.com/probonopd/c62396d17b0405102151dc4fb3f6f89f — so you can compare my notes with those. This appears to be the only session he's made notes for.

I probably won't cover every meeting (they're exhausting to listen to due to highly mixed microphone quality) but this one seemed worth covering.

https://www.youtube.com/watch?v=618e0qHJZV8

All the projects discussed this week used some amount of AI work. The topic of AI adoption continues to be a major subject for the attendees (today it's just Gregory Casamento, Joe Maloney, and Lars Sonchocky-Helldorf.)

The general attitude among the members in the call is a keenness to use AI whenever necessary to improve productivity; Maloney mentions how some major open source projects have banned it outright, but Casamento theorizes that GNUstep likely fell behind in levels of adoption due to lack of contributors; he is highly worried about "missing the boat." Casamento also posits that "real engineers use whatever technology is available to get the job done." Maloney mentions their recent experience with a bad push leaving Fred (not present) with serious concerns about the use of AI, and all three affirm their belief that human review of output by a knowledgeable programmer is key to making AI use palatable.

This conversation topic keeps coming up throughout the meeting; at one point it is jokingly referred to as the theme of the month. Much later in the conversation Greg notes that the time saved from AI coding on real engineering projects is not as much as it might appear at first, since ultimately there is a lot of work required to do proper review and testing.

- Gregory Casamento: working MusicKit ScorePlayer demo successfully playing some .score files under GNUstep; https://github.com/gcasa/MusicKit, https://github.com/gcasa/ScorePlayer, and https://github.com/gcasa/apps-scoremaker
- Gregory Casamento: working Markdown reader/editor; can't display images under GNUstep but works fully on Mac: https://github.com/gcasa/stepdown
- Gregory Casamento: also briefly shows https://github.com/gcasa/Billiards
- Joe Maloney: reports that he picked up the work on NextBSD (a ~2015 project to port mach and launchd to FreeBSD); this evolved into RavynOS but they recently switched to xnu (Darwin), abandoning the FreeBSD underpinnings; https://nextbsd.org/ - there is obviously a LOT to say about this but it doesn't get covered beyond these remarks until much later in the meeting (see below).
- Gregory Casamento: shows off a basic UIKit app with a .xib running under GNUstep. UIKit is an iOS framework; where possible he thunked analogous AppKit classes. Related repo: https://github.com/gcasa/libs-mobile
- Gregory Casamento: shows off a web browser UI called 'NetStep' built using CEF (Chromium Embedded Framework); from what I can see the UI is very barebones but it appears to be fully responsive--it's worth noting that GSDE ships something similar already; not sure what the advantages of Casamento's project are by comparison, though it at least uses GNUstep menus, which is a lot better than Firefox under WMlive. Joe is really interested in this project as either a basis or template for getting a lightweight browser into the Gershwin installation media.
- Joe Maloney reports that probono (not present) is merging a Gershwin fix that will make the displayed menus change  more or less instantly when switching between applications; previously they could take several seconds to update. The month in general for Gershwin has been largely about performance fixes.
- Gregory Casamento is considering working on Swift integration; Joe notes UIKit is a prerequisite for it. Greg was previously hesitant to adopt it since Swift syntax could be volatile, but the Swift world has become more stable, and Apple seems to be moving toward more components with pure Swift foundations. (He has a bit of a rant about the syntax and its motivations.) The general feeling is that Swift support may become an unpleasant necessity, even if they'd rather stick with GNUstep being a purely Objective-C ecosystem. Greg has a relevant repo here: https://github.com/gcasa/tools-swift
- Gregory shows off a new font preview feature in a font browser demo.
- Joe expresses interest in rolling a new display server someday for Gershwin, simply to get away from the instability and bugs of X11 and Wayland as they are currently; this does not mean dropping compatibility with these platforms, so much as running X apps through something akin to XQuartz. They talk about Display PostScript and Display GhostScript a little, the pros and cons thereof. NeXT machines were evidently easy to hack by targeting vulnerabilities in DPS.
- Relatedly, Greg shows off a toy PostScript renderer using GNUstep's PostScript code; it's about a year and a half old. Notably useful for print previews and possibly could be built into a PDF renderer someday.
- Greg briefly reports on the status of some GNUstep build scripts for macOS and there is a consensus that maintaining build scripts for X-based Darwin is probably not worth it.

After this there is a protracted discussion around 1:30 about engagement and attendance numbers; Joe draws comparisons to the FreeBSD meetings; Greg speculates about time conflicts; it is theorized that participation is higher in the winter months; some stats about the YouTube channel's performance (and the merits of thumbnails) are bandied about. Notably this recording was posted with an attention-grabbing thumbnail, and a title containing three (three!) whole exclamation marks.

- Greg reports fixing a long-standing issue in NSTableView pertaining to cleaning up after View-based cells; the class was not redoing layout properly after resize. He moved the layout implementation into a separate method so it could be called conditionally where appropriate.
- Greg also reports fixes to a number of Gorm issues: it wasn't updating properly in some cases when editing tables; several other minor issues; he says he 'tightened up Gorm quite a bit,' including .xib format handling problems that cropped up in both creation and parsing. He's considering moving .xib generation into a separate library rather than including it inside the .xib-handling plugin within Gorm; much of Gorm has already been refactored similarly into separate libraries. The major use case for such a library would be a converter for interface layouts from totally unrelated programming environments; he gives Glade (GNOME) as an example.
- This leads into a general discussion about libxcode and the possibility of building a whole IDE around ProjectCenter; Greg has a slightly defunct project called Ycode in the same space that was designed to open Xcode projects. They discuss the annoyance of internal competition and the potential of developing a VScode plugin for GNUstep... but agree that they all prefer a "Mac-as-fuck" native development stack, as it ensures bugs in the components used by the development environment get spotted immediately. The general upshot of this is a renewed interest in developing Ycode as a one-stop-shop IDE (Joe's keen on it), but some advantages of the split Gorm+ProjectCenter (IB+PB) architecture are noted, e.g. how Xcode lost support for palettes over time, which has essentially killed commercial third-party interface widgets. (At least one Gorm palette exists for database views; it requires Postgres...)
- Somewhat off-topic (but interesting to this forum!), Greg mentions that there has recently been a project to build an Apple Lisa inside an FPGA (https://tinkerdifferent.com/threads/the-apple-lisa-inside-an-fpga.5292/) and that he is working on an FPGA implementation of a NeXTcube. This is very much a toy project and is purely vibe-coded: https://github.com/gcasa/NeXT_FPGA - but he's learning VATL in the process. (Listen in around the 2:00 mark if you want to hear Greg's origin story as a UMaryland student discovering "the most beautiful computers of all time" (his words); evidently Steve Jobs gave them a huge gift of some 500 NeXT machines.) A discussion at length about the Lisa and revival PCBs follows this.
- Joe likewise fantasizes about new Gershwin cube hardware...
- Talking about NextBSD: Joe bought the domain mentioned above (and overpaid for it). The Mach extensions already work: https://github.com/nextbsd-redux/nextbsd/releases/tag/continuous - the live image can run X, Gershwin, packages, etc. already. He did some black magic in the kernel so the live image can actually "pivot" its root filesystem, so all "the general utilities like EFI Boot Manager don't have the problem of thinking they're in a chroot," which is reportedly a problem for BSDs.

NextBSD uses IOKit and a kernel registry to load .kexts; he converted FreeBSD kernel modules into kernel extensions, and used OS X Leopard's kextd to run them. FreeBSD's hardware driver loading is, obviously, not microkernel-y and nowhere near as flexible or adaptable. By contrast IOKit loads the correct graphics driver for different Intel and AMD model IDs reliably, and Joe is working on converting NVidia drivers into .kexts similarly; this is night and day above FreeBSD, where packages for different generations of GPU driver from the same family cannot coexist in one install. (Greg gushes over every detail, and I do not blame him even slightly.) More detail about this in the last 4-5 minutes of the meeting; Joe lists some of the tools that other FreeBSD downstreams have added in order to ease the pains of graphics driver management, but they're a far cry from what he's got working.

There is a demo of NextBSD booting in VirtualBox at 2:16:25, showing a litany of familiar Apple services (e.g. mDNSResponder) running in place of FreeBSD services; Joe also shows that SSHing into the system works and demonstrates installing packages from the FreeBSD package repo. However it is a big win that swapping packages is not required to activate drivers; the IOKit framework means they can all just be provided in a big cache of kernel extensions, and selected at runtime. Wifi is not yet supported beyond device probing, but Joe plans on fully automating it; he already has ethernet autoconfiguring when the cable is plugged in, unlike vanilla FreeBSD. (A lot of this work *was* already done or partly done in the old NextBSD project, but he's taken it further, carefully structuring Claude's work to have it do research on the NextBSD and ravynOS codebases rather than just letting it slop itself down the path of least resistance.) He's also built an easily-maintained workflow that leverages GitHub actions to minimize manual labor on his part, which is rather essential for a single-person effort taking on such a vast project. He's got kernel cross-compilation down to 3 minutes or so using an Ubuntu runner.

Around 2:32 the conversation topic turns briefly to funding; Joe is spending $100/month on a Claude Max subscription and speculates about strategies for fundraising. Greg notes he previously considered setting up a foundation for GNUstep also.

Joe estimates he'll be able to produce some sort of Gershwin ISO on NextBSD in a month or so.

Reflecting on upgrade mechanisms, Greg wonders about a package manager (in the old Installer.app sense) for NextBSD; Joe notes that retaining compatibility with FreeBSD packages, which is at least the short-term plan, requires that things being placed in the standard places. (Sadly none of them think of the correct compromise solution, which is a giant tree of shadow symlinks in /private.) Updating will definitely require some new mechanism to be implemented, however, since simply untarring a new distro for upgrades will clobber user configurations.