NextBSD goal, mission and visions

[grahamperrin]

A few rambling thoughts.

Yesterday's https://mastodon.bsd.cafe/@stefano/117055146777435438 @draga79 caught my eye, this was news to me:

With Apple phasing out AFP in macOS 27 and Time Capsules officially reaching end-of-life, it's time to move network backups to proper SMB. …

I sped through NextBSD — a native AFP server, focused briefly on effort and risks, then found:

• Port the illumos kernel SMB server (smbsrv) + client (nsmb) — independent, non-Samba, CDDL #243

Until today, I had (very) lazily thought of NextBSD — the BSD of the 21st century – as almost entirely forward-looking. The front page history currently concludes:

NextBSD Redux picks up the work.

A new vision based on those earlier efforts.

I wondered, how might efforts on a deprecated protocol fit with looking to the future?

From the recent article in The Register:

… Some of the initial goals are explained in this presentation from the original team.

– and:

… it picks up the same overall plan, aims to assemble the same puzzle pieces, and shares the same intended goal.

…

For us, perhaps the key aspect of NextBSD – both the original version and NextBSD-redux – is that it isn't an effort to build something completely new from scratch. It's an effort to cherry-pick and combine elements of existing separate FOSS projects, and assemble them into a useful whole. …

Eventually I realised, my speed-reading of the AFP document had been too rushed. In the verdict:

Critical strategic bound — AFP serves old Macs, not new ones

Apple is removing the AFP client: deprecated in macOS 15.5, warned to end in macOS 27, and the macOS 27 "Golden Gate" dev beta reportedly ships with no AFP client at all. Server-side is unaffected — but it means this server is a perfect fit for System 7 → macOS 26 (exactly NextBSD's revival mission) and modern macOS 27+ will not mount it. For current-Mac interop you'd need an SMB3 path separately. Scope AFP as the old-Mac constant, not the modern-Mac story.

Key point

There's a revival mission, however I shouldn't conflate beyond the AFP context.

@pkgdemon please, how might you describe a goal – or mission – for NextBSD as a whole?

Distinct from, but complementary to, things such as Gershwin.

Maybe something for a future announcement? Food for thought. Thanks.

---

For search purposes:

• afpd
• Apple Filing Protocol
• backup
• CIFS
• Corral
• NAS
• Time Capsule

[grahamperrin]

Linked from The Register:

NeXTBSD aka FreeBSD X | PPT

• not dated (I can't easily download it)
• uploaded by iXsystems
• at a glance, I don't see goals.

Slideshare's AI-enhanced description:

The document outlines the architecture and components of the NextBSD operating system, a fork of FreeBSD that incorporates Mach IPC and various libraries like libdispatch, asl, and libnotify. It details the core concepts of Mach IPC, task management, ports, and the common runtime provided by these components. Additionally, it discusses the role of launchd in process and service management, alongside resources for further exploration.

[grahamperrin]

Goals, old and new

Last month's https://www.reddit.com/r/freebsd/comments/1u5qkds/comment/oxaoja9/, with added emphasis:

Just a thought:

Might the original NextBSD goals – bring the Darwin userland tools over to BSD – might be a better match to DragonflyBSD than FreeBSD?

DragonflyBSD is experimental and aims to be modern, but the work is mostly in the kernel and on the filesystem.

While FreeBSD is quite technologically conservative.

From the response :

…

So it is really intended to be 2 things going forward.

• A 2nd half of the puzzle piece for the Gershwin Desktop environment while fully isolated so that Gershwin can remain agnostic. An attempt to make a just works livecd solution that feels familiar. https://github.com/gershwin-desktop/gershwin-on-nextbsd
• I previously wrote a full stack server management GUI app to manage FreeBSD. I want to do a new take on this focused around NextBSD that is fully open source, no strings attached that is cross platform for Windows, Mac, Linux, FreeBSD, NextBSD. I am all about automating things and making this easier that allow me do to things faster with less friction. To see a sketch of what the basis would look like here was the FreeBSD app https://www.hexbsd.org which I am expecting to have a revamped NextBSD branded version later this year after the above superset for Gershwin + bluetooth and all things desktop land.

So as these things progress more I will update the website after handbooks are created so it has something like:

• Download Server (The preview you see today, with after the superset finishes a few more touches like pkg hook to create LaunchDaemons)
• Download App (Cross platform management app)
• Download Desktop (Gershwin)

[pkgdemon]

Thanks for starting this topic @grahamperrin. I do need to go back and mark some of those plans as rejected, make a few minor adjustments to the website I was thinking.

For example earlier on I was I was looking at porting the whole kitchen sink:

• bootstrap_cmds (kept some such as mig needed for launchd mach)
• network_cmds
• file_cmds
• shell_cmds
• system_cmds
• text_cmds
• adv_cmds

The bulk of these no longer make as much sense as they would create interoperability issues, and for example mount specifically would not be very useful with more recent UFS without major work. The only reason to port things like "mount" at this point would be if HFS+ were the preferred file system, and that doesn't make much sense. A lot of this was exploratory to see where porting code drops should end.

As an example I'd still to explore the code drops for power management (pmset, etc) a bit more to see what might be useful for the integration. So I'm nearing the end of the exploratory work, to see what final things I might want from code drops, but I do I need to organize the information a bit better soon to clarify rejected, vs accepted.

For the tagline "The BSD of the 21st century" I kind of always liked the sentiment of the original NextBSD "Dragging kicking and screaming into the 21st century" which seemed to be the original rally cry. I think to a degree the newly revamped solution will live up to this original rally cry in a few subtle ways.

• Graphics detection (me)
• Wireless (me)
• Networking (me, but was in scope for the original project as a ticket for configd/IPConfiguration)
• Service management (original project)
• Very small, read write ISO with little memory overhead to boot media (me)

At the same time. I think one person's trash is another persons treasure. There are lot of ideas that were good ideas that have been forgotten by quote unquote modern operating systems.

• The concept of DOMAINS to clear separation of what belongs to the local machine, or network, or the system itself
• Targeting CD-ROM sized ISO media
• Building fast on systems with minimal resources (you can't do this with swift, rust, etc)
• Compatibility with older software, filesystems, network protocols (is not a bad thing)
• Building graphical applications without any code whatsoever using an interface builder (drag and drop objects to make apps)
• Portability to other platforms

I have a different definition of what modern should mean. Modern to me should mean just works, works well on newer hardware. It does not mean that it should incrementally require more resources, have a bigger footprint, or drop as many older hardware platforms, networking protocols as possible. I come more from a mindset of working with all kinds of operating systems for over 30 years, being in systems/network administration/quality assurance/release engineering/systems engineer roles. I am the most interested in what the user story is and the outcomes.

So for that I think this does summarize well what I wrote before that you quoted:

• Download Server (The preview you see today, with after the superset finishes a few more touches like pkg hook to create LaunchDaemons)
• Download App (Cross platform management app)
• Download Desktop (Gershwin)

I think that when these key things roll out more, is how it will better align with the rally cry. That said I've wanted to do some research excursions and deviations out of interest here and there but I do not foresee AFP or integrated SMB being a priority at this time. I couldn't pull in netatalk as an example into base that would not make sense from the licensing perspective and would have to do something cleanroom and I do not know that I want to do that at this time. I do like the idea of illumos SMB vs Samba. Samba again would not be compatible for licensing reasons. I kind of like the idea of being able to join a mac and have network accounts even if those things are being phased out.

With that said they are more exploratory ideas than something more concrete like kld to kext conversion plans that would more quickly make a bigger impact. I would say the near term focus will be things kld to kext conversion. Bluetooth, power management, LaunchDaemon hooks for pkg, Gershwin integrations for Sharing prefpane. Those things alone unlock Gershwin, and the app a bit more.

Then there are topics like how users are created, where they live, where configurations are stored that still need to be finalized.

• /home vs /Local/Users or /Network/Users (I lean towards the latter)

Gershwin has a competing solution I made before I thought about NextBSD. Something completely new that I cooked up.

https://github.com/gershwin-desktop/gershwin-components/tree/main/DirectoryServices

This means Network Applications, and Network users are a thing. I felt this is a critical detail for the app itself and the whole experience. Does the solution continue as I made it in NextBSD with a little more of Gershwin landing in the server image as well without the desktop parts? Or do I port more from Darwin and make something similar that can interop with macOS? Or do I take the opportunity to still make something more integrated with better zsh profiles that provides an enhanced version of the same experience.

I don't think I'll be doing the interop parts for macOS after all. At the same time I don't want to have to install package dependencies in the server image itself. So I need to think through how to redo some of the work in a way that is interoperable with what I created with Gershwin without extra pkg requirements in the server image while taking opportunities to enhance security such as kerberos support. So that is why that big topic probably will not make a ton of sense to most people. But I think it's key to some of the experience to spend a bit more time thinking, redesigning a bit of that.

[u64x86]

I have a different definition of what modern should mean. Modern to me should mean just works, works well on newer hardware

I completely agree with you here and I must say that probably many people have thought over the years that Apple has long invented those things that Unix-like could do, that is, just give working things that are easy to manage but that require a small entry threshold (do not make using a computer as primitive as Windows and not as advanced as Linux)

I would add to your definition of modern, which could mean complete and simple control and backup of the entire system in the hands of the user, without the need to write multiple (ba)sh scripts or resort to third-party software that is often poorly designed or not secure enough for this

[grahamperrin]

Many thanks. I can't argue with any of it. The near term focus is appealing.

… I don't think I'll be doing the interop parts for macOS after all. At the same time …

Fair enough 👍 it might be another person's future treasure (or trash).

[pkgdemon]

To address one more thing regarding network protocols. I think the sharing feature of the App itself should only focus on in base solutions so it might be that is just NFS or SSH+SFTP only for a long time. For example pkg install whatever from FreeBSD might pull in avahi and other things that are not wanted/conflict when NextBSD has mDNS baked in. That would be a reason for a custom ports tree but even with that you would have to be at the mercy of ports maintainers as well for bugfixes, etc. That's probably some of the biggest reasons I think to look at baking in illumous SMB instead but there are always tradeoffs with technology that have to be evaluated before the right decisions can be made.

[pkgdemon]

At least a few thoughts that have been scratching at the back of my mind:

1.) Is it possible to vendor any source from things tools-make, libs-base, libs-corebase, libs-opal, libs-quartzcore, and libs-gui require and maybe swap libobc2 with apples objective c? What are the pros and cons of doing that.
2.) Could the entire stack become mach-o vs ELF and at that point I could drop pkg or have a wrapper that creates a jail via kernel and new user land tooling. Or should I reach for mach-o emulation the same way Linuxulator handles Linux ELF binaries and translates syscalls
3.) Apparently NetBSD has kernel support for Netatalk. I found this really interesting. Not something I want to jump on soon, but someday I might get the desire to look at how this works.

Some of the reasons these ideas or lets call them research experiments to investigate, and test via branches make sense an appeal to me.

This is to be replaced by webkit now:

pkgdemon/ladybird#1

In this example I ported the Cocoa version of Ladybird to GNUstep with all of its features.

Then I started this a few months later:

https://github.com/pkgdemon/textmate

I realized during texmate specifically that there were a lot of BSDism's in the code which required workarounds. Working on these things has got me thinking about how can I go as far as I can with being the perfect bedrock for portability. Certainly if I could envision a CDROM sized live ISO image for the desktop that is full of more drivers than any other BSD can offer, a native display server, and pkg is not the mechanism in which new software is deployed I think that would be the most appealing thing for myself personally that I could make.

Instead perhaps pkg creates a jail and running X11 apps still works but the ISO doesn't have the baggage of all of that overhead to have a basic desktop and a web browser, terminal, text editor, etc. In that sense once certain targets are met I could see the base being stripped back more whereas there isn't really a lot of appeal for me to make things harder for myself to diverge right now. It's possible that these might make sense to leave on the table.

network_cmds
file_cmds
shell_cmds
system_cmds
text_cmds
adv_cmds

But for the short term, I am about KMS drivers for virtualization this month.

[grahamperrin]

Thanks

… for the short term, I am about KMS drivers for virtualization this month.

Noted:

• August 15 2026 - Linux compat work, ARM64 ISO lands, and KMS drivers for virtualization (WIP)

[pkgdemon]

I've been thinking a lot more and it would be nice to have a more balanced approach to an eventual cut down base. Perhaps what makes the most sense is for nextbsd to have its own solution for installing, upgrading base sets. Then what is needed by "pkg" becomes a set that if a user types "pkg" it offers to bootstrap exactly the way package does now only via another set with receipts, etc.

This would allow establishing a "set" of what needed for gershwin as well, to provide a chopped down list, no avahi, etc, while continuing to offer the best of both words for those that would like to use it another way, or together with gershwin without the initial baggage for livecd's and such. I'll have to think on it some more, and draft up some ideas soon, but I'd kind of prefer something like this.

It's not that I purposely want to get rid of being able to use pkg. I just don't want to rely on it for live media or Gershwin live media to have better control of a more slimmed down installation to make room for kernel extensions, and more useful things. I'd rather pkg be treated more as something like brew that can be used to install optional things, but not as a requirement for the server itself, or the preferred desktop use case.