trunkmaster
FreeBSD version
Thanks
While I'm messing with trying to get this working, I just wanted to say that I love the project. I loved the early days of OSX development and when I saw just how close it was to Openstep, I became a big fan of Openstep as well.
I've been trying to recreate that look, feel, and focused environment of Openstep ever since. Invariably little bits wouldn't work, or would clash with windowmaker (looks at GWorkspace) etc. But here you've given us a NeXT-y workspace and the Gnustep tools for building apps. It's an amazing thing -- especially as Windows, and Mac user experiences seem fixated on enshittifying and stuffing ads and other nonsense everywhere. Ugh. Nextspace, instead, is a wonderful oasis.
FreeBSD
Ironically, despite the fact that OSX and NeXTSTEP were both built on BSD, I'm sad that the awesome nextspace doesn't install on FreeBSD.
I am not up to your superior-mode C (and the entire toolchain), but I am doing decently decoding and modifying the installer scripts. I am poking along and getting better along the way. I do have a healthy facility with shell scripts, so I've been able to digest the installer scripts and figure out what's going on.
In any case, I'm going to try to get an installer working here and I'm saying it publicly in case there are any other interested parties. I'll not be fast with it, but I am going to attempt to get this working.
Status
FWIW, I'm stuck trying to get CFNetwork installed. There's no support for FreeBSD there, so I'm trying to figure out how to handle the ifdefs and get back to parity. It's interesting and tractable, but I'm slow. I'm going to take a slightly different stab at an installer that leverages more of the FreeBSD ports infrastructure and then try to bolt on your config and apps and see if that provides an interim build as a workaround -- and then I can circle back and iterate on the lovely "sealed" approach you've taken in the installer scripts.
Closing
Big note, thanks. I'm so glad that this project exists. It's a light. If we can figure out how to get more people and building GNUstep apps, maybe there's a way to a better desktop ahead for all of us. Be well!
Update. Well, to my surprise, I managed to get CFNetwork to play nice by casting spells above my proficiency level as augmented by Claude.ai. Don't worry, no slop commits incoming. @trunkmaster has been very thoughtful about a clean codebase for contribution and I have no dream of messing that up.
Basically, I've got a pristine jail (container) on FreeBSD that I revert to, run the installer step, verify the result, snapshot | rollback, repeat. CFNetwork was a real pain, but from there onward its easy sailing. Right now the main work is making the shell scripts be FreeBSD aware and install files in FreeBSD-style directories. NextSpace installs in /usr FreeBSD shudders at not being in /usr/local/NextSpace. Anyway, those are fairly minor.
Anyway, with a good workflow and the most difficult cmake chants sorted and patches ready to get FreeBSD supported, I'm on my way.
Oh and those GNUstep services. And systemd. Those are gonna hurt. But I think that's the last major work.
@sgharms thank you for precise understanding of project idea. Interesting that I started project on FreeBSD back then for the same reasons you've mentioned. But when I came to various media/volume management I've found FreeBSD not so easy to do so and it leads to extra development. Linux has all needed system level libraries and infrastructure to meet my requirements: UDisks for volume management, PulseAudio for audio device configuration, D-Bus as quite good interface to services. But I've preserved ability to integrate with other OSes at architectural level of NextSpace frameworks.
But I need stable, reliable OS that could be a base for NextSpace development. That's why I came to CenOS (it was recompilation of enterprise grade RedHat Linux). Things changed since then and I moved to closest available RedHat based distro - Fedora.
I don't know what is the state of D-Bus, UDisks, PulseAudio on FreeBSD, but it's definitely not a BSD style making things. Native platform of all this stuff is Linux not FreeBSD. So you may encounter some FreeBSD-specific bugs or misbehaving. Be ready for this.
As for CFNetwork: you may skip it easily - it doesn't have any usage in project at this point.
Oh and those GNUstep services. And
systemd. Those are gonna hurt. But I think that's the last major work.
It should be easiest part of the effort, I think. ;)
Minor update: I broke through the core foundation network build, and am now teeing up the Libobjc and the number three level tasks around building core and GNUstep make.
I think I’ve got a pretty good workflow at this point. But yeah, I don’t expect to be full feature parity to Linux; however, if I have a working desktop that I get to enjoy, that will be enough, and I can iterate towards perfection.
OK I managed to get through the assistive daemons and now am working in 8_build_Frameworks and am having a bit of a snarl of a time with the dependencies and the ifdefs. It mostly hinges on HAL which doesn't seem to be a thing in FreeBSD. And then between SystemKit and DesktopKit there seems to be some sort of circular dependency. Also things like this:
ifeq ($(findstring freebsd, $(GNUSTEP_TARGET_OS)), freebsd)
ADDITIONAL_OBJCFLAGS += -DFREEBSD -DWITH_HAL `pkg-config --cflags-only-other hal`
endif
Are leading me to not be able to get free of HAL so i can finish this component so that i can resolve the depts so that I can get to 9 and the finish line :).
I"m going to deploy some more ifdeffing and try to get out from under this.
Regardless, I'm hoping to have a fork that works...then i'll try to iterate through those diffs as a series of tractable branches that fit with maintainability etc. Three cheers to FreeBSD jails though, its made diagnosing, rollback, retry, etc. easy. There's rumor of Linux jails, so maybe I'll try one of those to test for regresses.
OK I’ve finally gotten to tackling 9 applications. I’m super excited to get @trunkmaster ‘s improved applications building. A quick run proved that some of the challenges are non trivial and will require a bit of care. I will update next week.
I took a few days off from this. After wrestling with deps in script 9Applications, it became clear that I'd bungled the 8Framework dependencies. On the upside, nothing failed in the GNUStep layer, it failed in the NextSpace layer which is great because that means my error is programming related and in userland. So, I'm going to try to ping-pong between the Framework build and the TimeMon application figuring that if I can get that to work, I'll be on the path to getting more complex applications like Workspace and Terminal working.
A few hours later...
Here we have vanilla WindowMaker running a Kitty term into my development jail that's launching TextEdit. OpenUp also builds and launches. I'm now on to the beasts Workspace and Terminal.
I’ve gotten Workspace to build but tossed out sound support to get things working. We can loop back on that.
Hitting some runtime bugs now in dbus, but I have a working binary at the least.
Wow! Very nice. Kudos. I’m a FreeBSD user, but have a Linux box just for Nextspace ( the NeXT Cube is just a bit too slow these days) My skills aren’t to the level needed for a port. I’m happy to see you have taken it on. I’m looking forward to trying this FreeBSD version.
Wow, this is awesome. Glad to see some GNUstep stuff still being worked on...
Just an update. When trying to get other more-advanced applications running, they would crash for various reasons. This lead me to try to build up the stack more carefully. The plan thus was to leverage FreeBSD's ports(7) and their diffs (to minimize drift between Linux/FreeBSD-isms and advanced C spells) and then bolt @trunkmaster 's patches onto that source and then build. I have successfully returned to the update of
https://github.com/trunkmaster/nextspace/issues/506#issuecomment-3178874835, but now built on this new standard.
Sadly, this didn't magically fix the crashes I was having.
What I do have is a series of shell scripts that are suitable to take one from a FreeBSD 14.3 system (I use a jail) to being able to gmake and run some of the simpler applications (e.g. TextEdit or Terminal). This means that one can debug the frameworks or the application source or shell environment with the ability to trust that some obscure autoconf flag wasn't set or some cmake definition wasn't set. You're working, to the best of my ability to tell, with a reliable stack.
In the interest of learning in public, this branch has this bootstrapping code. I do not plan on submitting this branch as is in a PR to canonical. It's good, but there are still some regressions (pruning sound, some guesses around OS-dependent code).
Hey folks, i ran into a bug about rendering but i was able to backport a fix from @onflapp ...so here's a proof of life:
One hinderance is the font is so damned small. Changing the default TerminalFontSize key just makes it gappy and ugly. The build previously seemed to prefer ancient rendering modes. I'm going to maybe change to the cairo rendering and see if that fixes things....i'm still plugging away. Maybe if i can get Terminal working I can tackle workspace. Still a dream at this point.
...to say nothing of sound....one step at a time.
OK I now have a Cairo-based Terminal.app so that I can read the font. I also fixed the alt-key behavior so that it's now a workable terminal. With that working I'm now tackling Workspace.
Proof of life and some good news / bad news / worse news
Good d news.
Hey folks, I've been able to show TextEdit.app some love. Check it out here with glasses-wearing-friendly font and not-so-glasses-friendly-wearing font.
Notice that Terminal.app is also readable and extremely usable on my machine. I added some custom hacks to handle my alt-as-meta config and it's 👨🍳 lovely.
OK Bad news
The font picker from TextEdit.app doesn't work. I change the font, nothing happens. After some gdb learnin', I can conclude that the acuating function (changeFont:) doesn't get called. This should be done by the framework (a launches panel; event in panel; panel calls back to delegate function). Lots of gdb testing and I can't make it work (yet). But as a workaround, I made it possible to change the font and size through env variables (as a compiler option) and I love it. I rock DejaVuSans 24, but the ability to tweak this is great and frankly I'm inclined to think plists are a layer of ~~bullshit~~ unnecessary indirection on top of the perfectly good env var system.
This leaves 2 paths available: look into why this is failing (Gnustep bug?) OR is it OK on Gnustep+Linux but broken on FreeBSD? Both are kinda beyond my grasp.
Worse news
My strategy has been to get simpler apps working figuring that it'll help me work out gremlins before Workspace. That's paid off: learned about ART versus Cairo rendering, got disciplined about library pathing, learned ldconfig(8) the BSD way... But this thing about not being able to get the font picker to work is concerning. Now you might think "who cares, it's just TextEdit" -- but while I can build Workspace, I can't run it: it dies with a failure to the Notification service. Lots of gdb and it looks like Notifications aren't working. There's a parallel here: is it broken or broken on FreeBSD?
There's enough parallel to the TextEdit case that I think i need to stay on understanding what's up there. It's a smaller surface area to figure out. Anyway: your emoji responses help keep me going.
How about some good news? I'm pretty happy with this visual milestone.
You'll see a number of applications: Terminal.App, TextEdit.App, OpenUp.app, Review.app all running from within my jail.
Getting the NSFontManager and NSFontPanel to work meant I had to do some work understanding how those two treated the responder chain in GNUstep. It's doing what I want, but I'm not entirely sure why it's working 😆 , I'll have to pare down the diff to find the smallest step forward.
I have two paths forward: Preferences - which would teach me about low-level binding to the OS and potentially unlock re-enabling sound via SoundKit OR Workspace -- the main app we all want to use. Maybe I can ping pong between the two -- bash my head bloody on one, flip to a different brick to bash my head on, repeat.
Anyway, it was great to see big, readable fonts responding to #t font fiddling in TextEdit.
For the curious, here's my bug in gnustep libs-gui:
https://github.com/gnustep/libs-gui/issues/368
And you can see in my fork the changes at a2097d522cfc04466891cbcff058beef63d139a3 and eaf2a2f6de82d97114edde00366fdae7f184971e.
I managed to get preferences working and made a few edits along the way. Here you can see me using the preferences utility to change the default font styling in Terminal.app.
I guess there's no point in dragging my feet any longer: it is time to face Workspace.
Welp folks, today at lunch I got to this milestone:
root@nextspace-debug:/src/Applications/Workspace # /usr/local/GNUstep/System/Applications/Workspace.app/Workspace
=== Starting Workspace ===
=== Initializing Window Manager ===
2025-10-08 13:58:09.722 Workspace[36344:40ec008] CoreFoundation: failed to dynamically link symbol _CFSocketStreamCreatePair
2025-10-08 13:58:09.722 Workspace[36344:40ec008] CoreFoundation: failed to dynamically link symbol _CFErrorCreateWithStreamError
2025-10-08 13:58:09.722 Workspace[36344:40ec008] CoreFoundation: failed to dynamically link symbol _CFStreamErrorFromCFError
=== Window Manager initialized! ===
=== Workspace initialized! ===
2025-10-08 13:58:09.775 Workspace[36344:40ff808] CFFileDescriptor SCHEDULE callback invoked (runloop: 68234241925280).
2025-10-08 13:58:09.778 Workspace[36344:40ec808] CFFileDescriptor SCHEDULE callback invoked (runloop: 68234241925280).
[icon.c] not doing the special NEXTSPACE path
=== Workspace is ready. Welcome to the NeXT world! ===
Thread 0x3e0f040ec808 has exited with leftover thread-specific data after 4 destructor iterations
I commented out stuff and played fast and loose here to get to this completely mangled monstrosity. But it talks to X and it knows something about WindowMaker. But from here on out, it's fixing a finite set of bugs.
Happy Friday!
Got some weird artifacting upper left and the textures and so on need some love, but there are no consequential launch time warnings or library crashes taking the whole thing down.
I’m going to make sure that pristine install to this point can be done readily with my install scripts and then I’ll share the branch here.
Steven
I've been battling to get the main startup script working and the Workspace+WM component working (is it a file manager? is it a window maker instance? yes). I'm pleased to show:
Some things are really not there e.g. what's up with the recycler icon; no sound; etc. but I think this is probably usable for very simple use cases (run a browser, run a terminal in my case). I'll write up some developer docs so that other FreeBSD users can enjoy too.
OK so here we are with me running X on :0 on my host system and then running WS inside my development jail. The last mile was getting some final xrandr details squared away. I'm still crafting a branch that's installable.
I believe in strict, tight commits and commit history that document the code and bugs encountered. So...a lot of git rebase is underway to make a clear history. That said, I should have that by early November.
Really brave souls are invited to visit: https://github.com/sgharms/nextspace/tree/optimize-commits
But I've been using it as a daily driver and, yes, I can collapse the dungeon by doing something weird, but for the most part it's reasonable.
It looks like this:
Check out that sweet beastie-head TIFF icon in the dock :P. I'm hoping a better artist can ride to the rescue there 😆
Well friends, this week I hit a setback.
I improved and streamlined the installer shell scripts and got it so that the installer would be smooth and buttery. I cleaned up my old commits with rebase so that the 'wtf' commits etc. went away. I could see the end of the road to "developer-release-1" as I got to launching Workspace.... and it launched (briefly) .. and then crashed.
root@nextspace-dr1:/src/Installer/FreeBSD/BUILD_ROOT/Applications/Workspace # /usr/local/NextSpace/Apps/Workspace.app/Workspace
=== Starting Workspace ===
2025-11-09 22:35:17.523 Workspace[24816:100314] No local time zone specified.
2025-11-09 22:35:17.523 Workspace[24816:100314] Using time zone with absolute offset 0.
2025-11-09 22:35:17.522 Workspace[24816:100314] [OSEDisplay] eDP-1 reoslutionSize: {width = 1920; height = 1080} frame: (null)
2025-11-09 22:35:17.535 Workspace[24816:100314] Screen: sending OSEScreenDidChangeNotification to GSPublicNotificationCenterType...
=== Initializing Window Manager ===
2025-11-09 17:35:17.653 Workspace[24816:bb4f3008] CoreFoundation: failed to dynamically link symbol _CFSocketStreamCreatePair
2025-11-09 17:35:17.653 Workspace[24816:bb4f3008] CoreFoundation: failed to dynamically link symbol _CFErrorCreateWithStreamError
2025-11-09 17:35:17.653 Workspace[24816:bb4f3008] CoreFoundation: failed to dynamically link symbol _CFStreamErrorFromCFError
=== Window Manager initialized! ===
=== Workspace initialized! ===
2025-11-09 17:35:17.707 Workspace[24816:bb508808] CFFileDescriptor SCHEDULE callback invoked (runloop: 39469629595808).
2025-11-09 17:35:17.713 Workspace[24816:bb4f3808] CFFileDescriptor SCHEDULE callback invoked (runloop: 39469629595808).
2025-11-09 17:35:17.949 Workspace[24816:bb50f008] CFFileDescriptor SCHEDULE callback invoked (runloop: 39469652705280).
2025-11-09 22:35:17.949 Workspace[24816:106343] --> Going into CFRunLoop...
=== Workspace is ready. Welcome to the NeXT world! ===
error 4: BadPixmap (invalid Pixmap parameter) request 54 minor 0 serial 1950
[xcb] Unknown sequence number while processing queue
[xcb] You called XInitThreads, this is not your fault
[xcb] Aborting, sorry about that.
Assertion failed: (!xcb_xlib_threads_sequence_lost), function poll_for_event, file xcb_io.c, line 281.
Abort trap (core dumped)
Well, after 20+ years in the business, I don't think I've ever seen a nicer set of error messages (like you see down here).
But yeah, i seem to be stuck. I think the situation is this (thanks ChatGPT for being my collaborator here): WindowMaker is from a single-threaded era and, in a number of points it tries to flush changes via X (Xlib, XCB, whatever). It doesn't know that another process in another thread may have done something that it doesn't know how to deal with.
I don't know how this wasn't a problem on Linux. And for whatever reason, in my prior hack-it-together approach, I somehow didn't hit thread errors. Maybe I installed something wrong.
Anyway, so how to proceed?. I know there's also some Apple programming religion around here like "Never try to update UI outside of the main thread." I think that might be applicable here. We need Workspace's internal WindowMaker to delegate updates up to the main thread(?). ChatGPT suggests that other desktop environments have done something similar. Maybe I need to create some sort of communications tunnel. I'm not entirely sure.
Anyway, today, I had hoped to share my current installers as the basis for "developer-release-1," but with this crashing, I don't think it's there yet. Terminal.app works and xeyes too -- I just need to figure this crash out for our crown-jewel application.
Any tips appreciated, if you have 'em. Never done multithreaded C programming (just a tad bit of Swift and Obj-C programming, where there are ergonomic APIs for doing it).
@sgharms, You should write an email directly to @trunkmaster, maybe he can help with something.
Well friends, this week I hit a setback.
I improved and streamlined the installer shell scripts and got it so that the installer would be smooth and buttery. I cleaned up my old commits with rebase so that the 'wtf' commits etc. went away. I could see the end of the road to "developer-release-1" as I got to launching Workspace.... and it launched (briefly) .. and then crashed.
root@nextspace-dr1:/src/Installer/FreeBSD/BUILD_ROOT/Applications/Workspace # /usr/local/NextSpace/Apps/Workspace.app/Workspace === Starting Workspace === 2025-11-09 22:35:17.523 Workspace[24816:100314] No local time zone specified. 2025-11-09 22:35:17.523 Workspace[24816:100314] Using time zone with absolute offset 0. 2025-11-09 22:35:17.522 Workspace[24816:100314] [OSEDisplay] eDP-1 reoslutionSize: {width = 1920; height = 1080} frame: (null) 2025-11-09 22:35:17.535 Workspace[24816:100314] Screen: sending OSEScreenDidChangeNotification to GSPublicNotificationCenterType... === Initializing Window Manager === 2025-11-09 17:35:17.653 Workspace[24816:bb4f3008] CoreFoundation: failed to dynamically link symbol _CFSocketStreamCreatePair 2025-11-09 17:35:17.653 Workspace[24816:bb4f3008] CoreFoundation: failed to dynamically link symbol _CFErrorCreateWithStreamError 2025-11-09 17:35:17.653 Workspace[24816:bb4f3008] CoreFoundation: failed to dynamically link symbol _CFStreamErrorFromCFError === Window Manager initialized! === === Workspace initialized! === 2025-11-09 17:35:17.707 Workspace[24816:bb508808] CFFileDescriptor SCHEDULE callback invoked (runloop: 39469629595808). 2025-11-09 17:35:17.713 Workspace[24816:bb4f3808] CFFileDescriptor SCHEDULE callback invoked (runloop: 39469629595808). 2025-11-09 17:35:17.949 Workspace[24816:bb50f008] CFFileDescriptor SCHEDULE callback invoked (runloop: 39469652705280). 2025-11-09 22:35:17.949 Workspace[24816:106343] --> Going into CFRunLoop... === Workspace is ready. Welcome to the NeXT world! === error 4: BadPixmap (invalid Pixmap parameter) request 54 minor 0 serial 1950 [xcb] Unknown sequence number while processing queue [xcb] You called XInitThreads, this is not your fault [xcb] Aborting, sorry about that. Assertion failed: (!xcb_xlib_threads_sequence_lost), function poll_for_event, file xcb_io.c, line 281. Abort trap (core dumped) Well, after 20+ years in the business, I don't think I've ever seen a nicer set of error messages (like you see down here).
But yeah, i seem to be stuck. I think the situation is this (thanks ChatGPT for being my collaborator here): WindowMaker is from a single-threaded era and, in a number of points it tries to flush changes via X (Xlib, XCB, whatever). It doesn't know that another process in another thread may have done something that it doesn't know how to deal with.
I don't know how this wasn't a problem on Linux. And for whatever reason, in my prior hack-it-together approach, I somehow didn't hit thread errors. Maybe I installed something wrong.
Anyway, so how to proceed?. I know there's also some Apple programming religion around here like "Never try to update UI outside of the main thread." I think that might be applicable here. We need Workspace's internal WindowMaker to delegate updates up to the main thread(?). ChatGPT suggests that other desktop environments have done something similar. Maybe I need to create some sort of communications tunnel. I'm not entirely sure.
Anyway, today, I had hoped to share my current installers as the basis for "developer-release-1," but with this crashing, I don't think it's there yet. Terminal.app works and
xeyestoo -- I just need to figure this crash out for our crown-jewel application.Any tips appreciated, if you have 'em. Never done multithreaded C programming (just a tad bit of Swift and Obj-C programming, where there are ergonomic APIs for doing it).
is it reproducible? did you see this only once?
Update: tl;dr I've hit a brick wall -- I'm stuck and I don't see a way forward owing to dispatch queue behavior on FreeBSD.. My proof of concept branch. I'm probably going to give up.
As mentioned above I was having some multi-threading corrupt Workspace. After going back to a pristine system, i carefully built up the layers and hit the same error. I had long sessions with Claude Code trying to get help and came up with some artifacts here.
Based on that work, the question was whether ANY async / dispatch work could work. The POC branch shows that given:
- Pristine jail
- Write 2 installer scripts that take the patches from the
port(7)patchespkguses - Run them w/ exit 0 and visible deployment to
/usr/local/NextSpace - A super-simple POC async program
...the callbacks never fire. No clever callbacks / dispatch work ➡️ multithreading badness ➡️ crash.
Earlier implementations used the port infrastructure to build and install libdispatch and CoreFoundation. They, too, were unsuccessful.
I don't know how I managed to get Workspace to run ever. Maybe i borked something that made the program single-threaded. I have another branch with the full install stack for reference, but without this, it's probably a dead end for any other BSDers.
And so that's it. Short of
- figuring out threading in the kernel and fixing the libraries...
- figuring out low-level threading in C...
- finding a guru from FreeBSD team seeing a way forward with just a few tweaks...
- doing rewrite to
./Applications/Workspace/WMwindow maker code to be thread safe... - getting a CS masters with desktop software design being my thesis...
- learning that somehow jails don't behave like I think around async / queues and my negative is false and it Works on Someone Else's Machine
- getting a pull request or comment that finds an oversight and fixes us...
I don't see a way forward in a short amount of time. @trunkmaster said that supporting this platform was NOT a goal. I don't want to bother him. OSS is hard: just doing this i've been distracted or up late -- and that's just this experiment. His efforts are huge by comparison..
I've been at this 4.5 months. Maybe I need a break. Maybe my commits can get someone else started. NGL, I'm kinda grieving this -- I'd love to see success in the porting. Good luck!
=================================================
CFFileDescriptor Test
=================================================
Thread: 0x186ad387f008
[SETUP] Created pipe: read_fd=3, write_fd=4
[SETUP] CFFileDescriptorRef created: 0x186ad3c2d000
[SETUP] Enabled read callbacks
[SETUP] CFRunLoopSource created: 0x186ad3c2d100
[SETUP] Current runloop: 0x186ad3c3b000
[SETUP] Source added to runloop in default mode
=================================================
TRIGGERING EVENTS
=================================================
[TRIGGER] Wrote 'Test data 1' to pipe
=================================================
RUNNING RUNLOOP (5 second timeout)
=================================================
Expecting callback to fire...
=================================================
RUNLOOP EXITED
=================================================
Result: kCFRunLoopRunTimedOut (5 second timeout reached)
=================================================
FINAL RESULTS
=================================================
Callback count: 0
✗✗✗ TEST FAILED ✗✗✗
CFFileDescriptor callbacks DID NOT FIRE
This matches the problem described in SYNCHRONIZE.md
```
I've been at this 4.5 months. Maybe I need a break. Maybe my commits can get someone else started. NGL, I'm kinda grieving this -- I'd love to see success in the porting. Good luck!
The detail you've captured has to be applauded. I'm not cut out to solve this but watching you work on it has been inspiring and I hope someone can help unstick the effort -- I'd love to be a tester once I get through with the big project I'm on.
There are probably one or two listeners of BSDNow with some NeXT fondness -- maybe see if they'll put out the call?
