- Welcome to NeXTcommunity.
News:
NetSurf: the first new browser for OPENSTEP in decades!
Recent posts
#31
Off Topic / Re: Interview with the creator...
Last post by Rhetorica - Jun 18, 2026, 04:36 PMQuote from: ZombiePhysicist on Jun 18, 2026, 02:50 PMSo cool! He likes weird historic machines. Maybe one of us should contact him and put next on his radarSee the link under the video—Gregory Casamento of GNUstep is already working on an FPGA Cube
#32
Off Topic / Re: Interview with the creator...
Last post by don_apple - Jun 18, 2026, 03:10 PMIf somebody wants to play a round with an Apple Lisa, there is also a pretty good emulator out there: https://github.com/arcanebyte/lisaem
It works on macOS, so maybe somebody can port that to NeXTStep/OpenStep ...
It works on macOS, so maybe somebody can port that to NeXTStep/OpenStep ...
#33
Off Topic / Re: Interview with the creator...
Last post by ZombiePhysicist - Jun 18, 2026, 02:50 PMSo cool! He likes weird historic machines. Maybe one of us should contact him and put next on his radar
#34
Off Topic / Interview with the creator of ...
Last post by Rhetorica - Jun 17, 2026, 08:33 PMRecently, an engineer named Alex Anderson–McLeod built an Apple Lisa in an FPGA, bringing this ancient but crucial machine into a modern era of reproducibility. Here's an interview with him about his inspiration, process, and future plans:
This has already inspired other projects, like this one, which you should absolutely check out if you're reading this.
Alex's story lends some insight into how and why retrocomputing will stay alive: he developed a special interest in the Apple Lisa at age 11, and set his heart on building a reproduction because the original hardware was beyond his means to acquire. This is a spectacularly pristine example of how young people continue to discover and get invested in old technology—and quite contrary to the narrative put forward by most nostalgists, who generally expect their retro hobbies to die with them.
As the graybeards gather, to surrender their beloved retro tech into the ground, the young are already waiting behind them with shovels, ready to exhume it...
This has already inspired other projects, like this one, which you should absolutely check out if you're reading this.
Alex's story lends some insight into how and why retrocomputing will stay alive: he developed a special interest in the Apple Lisa at age 11, and set his heart on building a reproduction because the original hardware was beyond his means to acquire. This is a spectacularly pristine example of how young people continue to discover and get invested in old technology—and quite contrary to the narrative put forward by most nostalgists, who generally expect their retro hobbies to die with them.
As the graybeards gather, to surrender their beloved retro tech into the ground, the young are already waiting behind them with shovels, ready to exhume it...
#35
Off Topic / Re: The steady demise of x86
Last post by jeffburg - Jun 17, 2026, 04:32 AMIt has been interesting to watch from the outside as the PC world has somehow not had to change their processor architecture in 40+ years.. like actually incredible when you think about it. Like if you imagine that your modern day 64 bit AMD thread ripper with 64 cores and 132 threads, when it boots, for a moment, acts and behaves exactly as a 16bit 8086 with only 64k of ram.... its totally mind-blowing. Like how the hell does that work.
On the other hand, for us in the Apple world, this transition thing has become sort of normal. I was there for PPC->intel and I am still here for Intel->ARM... it's always pretty smooth. One thing I was surprised by was that Apple was really determined to do the FULL transition. With PPC it was obvious why, PPC had no future in Personal Computers. But with Intel, it was a bit of a mystery to me. Why not just continue to support both??? Intel Xeon for the most powerful workstations and Apple Silicon for laptops and stuff? I was surprised they went so hard.
Anyway, this post goes a long way to not say anything about what @Rhetorica posted. But I only wanted to add that I think it seems like the PC side of the world and x86 versions of Windows and Intel will never go away. But I agree with the general sentiment that I think we will see a lot larger market for ARM PC hardware going into the future. Its just so far the support has been very bad for non x86 CPU's in the PC world... but its quickly getting better.
The thing I do miss about no longer having easy access to Intel hardware in the Mac world is that virtualization was SOOOOOOOO great when you had an intel CPU. VirtualBox, VMWare Fusion, QEMU, etc... such amazing tools when you have a matching CPU type... and sooooo limited when you have to emulate the underlying architecture.
On the other hand, for us in the Apple world, this transition thing has become sort of normal. I was there for PPC->intel and I am still here for Intel->ARM... it's always pretty smooth. One thing I was surprised by was that Apple was really determined to do the FULL transition. With PPC it was obvious why, PPC had no future in Personal Computers. But with Intel, it was a bit of a mystery to me. Why not just continue to support both??? Intel Xeon for the most powerful workstations and Apple Silicon for laptops and stuff? I was surprised they went so hard.
Anyway, this post goes a long way to not say anything about what @Rhetorica posted. But I only wanted to add that I think it seems like the PC side of the world and x86 versions of Windows and Intel will never go away. But I agree with the general sentiment that I think we will see a lot larger market for ARM PC hardware going into the future. Its just so far the support has been very bad for non x86 CPU's in the PC world... but its quickly getting better.
The thing I do miss about no longer having easy access to Intel hardware in the Mac world is that virtualization was SOOOOOOOO great when you had an intel CPU. VirtualBox, VMWare Fusion, QEMU, etc... such amazing tools when you have a matching CPU type... and sooooo limited when you have to emulate the underlying architecture.
#36
Virtualization / Re: Starter Kit for OPENSTEP 4...
Last post by jeffburg - Jun 17, 2026, 04:09 AMI am going to write this here as a reminder for myself to add a guide to this post. But I also configured my VirtualBox install of OpenStep 4.2 to have 2 NIC's, one for connecting to the internet and one for connecting to the host machine. Why did I do this? Normally, if your host computer is at home on your home network, its not needed because you can just set the NIC to use "Shared" (I think that's what its called) and it joins your home network as its own computer and has full access to the internet and any computer on your network.
BUT if you have VirtualBox on your laptop... and you are jumping between networks, this won't work because OpenStep doesn't do DHCP... even if you install the DHCP add on software, it requires a reboot to DHCP. So in this scenario you want the NAT option so OpenStep connects to a NAT created by VirtualBox. This means the network settings from OpenStep's perspective are always the same. But this has the side effect of not allowing OpenStep to connect to any other computers or the host.
So you need to add a second NIC with "host-only adapter" and then jump through some hoops in both VirtualBox and OpenStep... but then you have the benefit that OpenStep can reach the internet no matter what network your host machine is connected to AND can connect to the host to do file sharing through NFS or whatever.
Its a really neat setup.
BUT if you have VirtualBox on your laptop... and you are jumping between networks, this won't work because OpenStep doesn't do DHCP... even if you install the DHCP add on software, it requires a reboot to DHCP. So in this scenario you want the NAT option so OpenStep connects to a NAT created by VirtualBox. This means the network settings from OpenStep's perspective are always the same. But this has the side effect of not allowing OpenStep to connect to any other computers or the host.
So you need to add a second NIC with "host-only adapter" and then jump through some hoops in both VirtualBox and OpenStep... but then you have the benefit that OpenStep can reach the internet no matter what network your host machine is connected to AND can connect to the host to do file sharing through NFS or whatever.
Its a really neat setup.
#37
Software / Re: Rolling Community Distros ...
Last post by Rhetorica - Jun 15, 2026, 09:01 PMContinuing this series, here's Capricorn. It is built on top of Betelgeuse and includes Turbolent's packages except for NetSurf and Quake 2. It also has Y. Hayakawa's VBoxMouse driver, which totally overrides mouse input settings and just passes info in directly from the host (@jeffburg may consider this the culmination of some of his dreams...), though I wasn't able to get the Pasteboard interop working (it appears to require some 3.3J-specific stuff.) This is a really good and robust starting point for anyone doing modern NeXT development, as it includes gcc 3.3, OpenSSH, and Python 3.11.
The next VM, Diadem, will provide more user applications and configure settings to be geared toward productivity. The VM after that, Electra, will go all-out with tweaking and customization.
- http://archive.nextcommunity.net/VMs/OS42_i386_Dev_Capricorn.vbox.7z
- http://archive.nextcommunity.net/VMs/OS42_i386_Dev_Capricorn.vbox.7z.txt (make sure you review this as some details have changed, e.g. default root password and IP address)
The next VM, Diadem, will provide more user applications and configure settings to be geared toward productivity. The VM after that, Electra, will go all-out with tweaking and customization.
#38
Software / Re: List of NeXT-related repos...
Last post by Rhetorica - Jun 15, 2026, 07:42 PMAnother from Asmodai (aka Verdraith):
https://github.com/Asmodai/NeXT-UnixKit - Various Unix things for NeXT platforms.
Rather critically this has a correctly-compiled sudo; the kb7sqi version doesn't actually allow password input. Evidently this was still a problem in early 10.x releases; relevant thread. Turbolent's packages supersede this, but I think the vim and sudo versions from here are still the best we have so far. (Admittedly, actually building them was beyond me...)
https://github.com/Asmodai/NeXT-UnixKit - Various Unix things for NeXT platforms.
Rather critically this has a correctly-compiled sudo; the kb7sqi version doesn't actually allow password input. Evidently this was still a problem in early 10.x releases; relevant thread. Turbolent's packages supersede this, but I think the vim and sudo versions from here are still the best we have so far. (Admittedly, actually building them was beyond me...)
#39
Software / Re: GNUstepOfficial meeting mi...
Last post by Rhetorica - Jun 15, 2026, 06:35 AMNotes 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.
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.
#40
Software / Re: List of NeXT-related repos...
Last post by don_apple - Jun 13, 2026, 09:16 AMQuote from: ZombiePhysicist on Jun 12, 2026, 02:32 PMThe faux NeXT at 50% the size is interesting. I wonder i you could scale it up to make full scale reproductions.Somebody actually created a scaled-up version of the mini NeXT Cube case that was created for the Raspberry Pi a few years ago: https://cocoacrumbs.com/blog/2024-10-06-building-a-nextcube-replica/