What is the future of FreeBSD?

[Alain De Vos]

Time for a joke, switch to Ubuntu my friend.

 

[Erichans]

Unfortunately, compared to writing wifi drivers, people think UI and usability is "easy" because they believe they understand it [...]

Yes.
Domain knowledge is often overlooked or taken for granted.

 

[msplsh]

Indeed, but again, people are happy to learn how to scroll up on a web browser. Why not a terminal window?

Because in most operating systems, you don't have to install a scroll wheel or scrolling touchpad, it's just there and does the thing.

If someone allows

Ah yes, I'm "allowing" it when the messages get blasted into the screen at line speed by pkg.

messages to scroll off the screen before reading them (and choose not

Choosing, right. They should have known to install it, knowing everything, of course.

to use a pager or any of the many solutions to avoid this), then they are ignoring them.

Not beating the allegations

The only reason I give people a hard time with this is because the "it's fine, you change" is in direct opposition to obtaining the "widest possible use" and there's FreeBSD-ish ways to achieve goals that isn't going to get in the way of people who like to do it the old way. Like, IDK, the absolute basic would be making the messages go through a pager by default.

 

[BigSneakyDuck]

We do need i.e. wifi drivers written but I do not believe the sorts of users that FreeBSD will attract by making it "easy to install" by non-technical users will ever provide the skills to get this complex work done. OpenBSD is doing extremely well in terms of hardware support and in one of the interviews Theo outright stated that he doesn't even want to attract users. Obviously the companies behind the FreeBSD foundation have quite different motives for attracting consumers.

In fairness, the flip side of OpenBSD's volunteer hardware efforts being so impressive is the continued lack of Bluetooth or Nvidia support, though those come down to conscious choices. Meanwhile the FreeBSD Foundation and its sponsors have paid for recent (overdue) WiFi improvements. That's a financial option that OpenBSD and NetBSD don't have, and FreeBSD is fortunate to have such corporate backing even if it pales in comparison to the Linux ecosystem. But it does need to retain - preferably build up - a critical mass of commercial users for that to continue, and the Foundation has taken the risk of reducing its reserves and temporarily spending unsustainably on development in an effort to keep FreeBSD commercially relevant and attract new, hopefully younger, users and developers. (The age profile in community surveys is not reassuring so fresh blood is needed to stay viable. This is also why Google Summer of Code sponsorship is so important, even if a project never gets committed it can still be a talent recruitment pipeline.)

The gloomier prognosis for "what is the future of FreeBSD" in the long run is that if ever its USPs erode, corporates jump ship, and the funding dries up, then FreeBSD would be in a lot of trouble. It's a big project that tries to support a lot of features and use cases. Maintaining that code base is a struggle even with current resources. An all-volunteer effort to maintain it as a hobbyist OS would require tough decisions about what it's possible for the project to achieve. OpenBSD has a tighter focus, smaller code base, and clearer USP, all of which makes it much more sustainable as a passion project.

Something that helps OpenBSD here is that - provided you're willing to accept its compromises - it's a perfectly good enough system to dogfood, but devs hit enough nits they want to fix too. "Ease of use" isn't limited to "making it simpler for non-technical people to use" or "restoring a 20-year-old option to pick a desktop during installation", it's also "how well does everything work out of the box", "do I need to buy a dongle for WiFi because mine isn't supported", etc.

Judging from posts online, many FreeBSD-curious people abandon their trial of it as a daily driver because WiFi and suspend/resume are blockers for them. Those are gnarly, specialist things to fix. You can't force someone to do it, and it may be unviable to just wait for a motivated hardware dev to come along. Provided the funding situation allows, the FreeBSD Foundation's decision to pay for it looks rational: fixing blockers to daily use may grow the base of people who can work on other parts of the system. On the other hand, I can't say it's obvious what would attract the kind of hardware dev who might voluntarily do that work in future: they're rare as hen's teeth, and their choice of which OS to hack in their free time is going to be highly personal. One sensible-sounding suggestion I've seen was that poor support for Raspberry Pi 5 is a big own goal, the ability to do interesting projects with FreeBSD would help draw in much-needed hardware "tinkerers". But this is a chicken and egg situation.

 

[mer]

5 pages and I think we are still having a good conversation.

WiFi, Suspend/Resume, graphics, anything that touches software.
A problem for FOSS is NDA and getting access to the needed documentation.
Lots of HW makers want you to pay for the privilege of getting documentation so you can write software to doink with their hardware. Personal experience example: Broadcom.
I get it, intellectual property.
Writing a FOSS driver suddenly "everyone" can program the HW and figure out the secret sauce to reverse engineer the hardware (that's the HW perspective).
In the past people would do clean room reverse engineering, things are more complicated now so the effort to do so is greater.

So, how to deal with NDAs as FOSS? I don't know, can't speculate. But it is a real problem.

 

[Ilovehotdog]

Put in another hour, but finally—Chinese input is working, and I got the right sound channel set as the default.

For now, I’ll just stick with GhostBSD and wait for FreeBSD 15.1, or 16, maybe even 17... whenever it actually starts to feel right.

I’m an ISTJ—patient enough to wait for that real Unix blood to run hot again.

But I don’t have the skills to wrestle with all this tinkering.

Still no WiFi, no OnlyOffice, no F2FS, no MTP.

Next up: I’ll try running some games through Wine.

 

[fahrenheit]

Put in another hour, but finally—Chinese input is working, and I got the right sound channel set as the default.

For now, I’ll just stick with GhostBSD and wait for FreeBSD 15.1, or 16, maybe even 17... whenever it actually starts to feel right.

I’m an ISTJ—patient enough to wait for that real Unix blood to run hot again.

But I don’t have the skills to wrestle with all this tinkering.

Still no WiFi, no OnlyOffice, no F2FS, no MTP.

Next up: I’ll try running some games through Wine.

View attachment 26089

Congratulations on getting it working.

As for 15.1, and if your mini pc is like mine (we at least have the same cpu), there should be no difference. Drm 6.12 works the same for the 780m, if you have a mediatek m76 based chipset for wifi/bluetooth it will not be part of 15.1 (maybe 15.2), if you have a realtek 2.5G ethernet adapter you will still need to manually install the corresponding kmod as it is not part of the base system.

As for chinese input, from the comments of T-Aoki (which uses japanese input) I think your only option is X11 DEs (like the Mate that GhostBSD uses). And here the problem is not FreeBSD is that wayland is crap on that front.

 

[scottro]

Assuming (and as the joke goes, when you assume, you make an ass of you and me), that Chinese input works similarly to Japanese input, there are several Wayland window managers that use it. I've used Japanese (with fcitx5) in labwc, sway, and mango. On Linux, one can use it quite easily in RedHat and clones with their default Wayland Gnome. (And with Fedora, sort of a test place for RedHat, with labwc, and, I'm guessing the others I've mentioned. Only tried labwc). The Desktop Environments (as opposed to Window Managers) that I've used were only RH and clones, e.g., Rocky and Alma, with Gnome which uses ibus. I haven't tried KDE on either Linux or FreeBSD, so not sure what was used, but I'm guessing ibus.

If I had to use Wayland and needed Japanese input on FreeBSD, I would use either labwc or sway, though mango also works. But I think that Ilovehotdog prefers KDE. However, fahrenheit, there are certainly some Wayland window managers that don't do it well. I've never gotten it working right on dwl, a Wayland version of dwm.

 

[blackbird9]

The future of freebsd, I hope, is to continue to be a free operating system, that is free as in freedom, which implies free as in zero cost, free as in free speech, and freedom from undesired content shoved in front of you like ads in the start menu; and freedom from corporate control, in the original spirit of internet freedom. It's the "free" part of 'FreeBSD'. Other operating systems (not all, of course) are drifting inexorably into being access points on someone else's network, that is effectively not your computer, and hence not free as in freedom; what you are allowed to do with the machine is controlled by whoever owns and runs the network, not you. What you end up with is an opaque leaf-node like a phone handset, rigidly controlled by the network owner, that you are not free to do what you want with. Every single thing you do on the non-free box is monitored and transmitted back to the network owner by telemetry... and you know all the rest. That even includes some versions of linux nowadays (android?), although I am pleased to see some linux distros like slackware still upholding the free as in freedom spirit, in addition to the *BSD's. Of course macos and windows are a very long way down the central control path. Yeah, I don't want to start sounding like a mini-RMS, but that's what I would like to see in the future of freebsd. That's more important to me than "market share" or other definitions of "success'. Real freedom is a valuable and rare commodity, we have little enough of it in our lives, and when it comes along we need to recognise it and support and preserve it.

 

[mro]

Foster the future you want to see.

 

[fahrenheit]

Assuming (and as the joke goes, when you assume, you make an ass of you and me), that Chinese input works similarly to Japanese input, there are several Wayland window managers that use it. I've used Japanese (with fcitx5) in labwc, sway, and mango. On Linux, one can use it quite easily in RedHat and clones with their default Wayland Gnome. (And with Fedora, sort of a test place for RedHat, with labwc, and, I'm guessing the others I've mentioned. Only tried labwc). The Desktop Environments (as opposed to Window Managers) that I've used were only RH and clones, e.g., Rocky and Alma, with Gnome which uses ibus. I haven't tried KDE on either Linux or FreeBSD, so not sure what was used, but I'm guessing ibus.

If I had to use Wayland and needed Japanese input on FreeBSD, I would use either labwc or sway, though mango also works. But I think that Ilovehotdog prefers KDE. However, fahrenheit, there are certainly some Wayland window managers that don't do it well. I've never gotten it working right on dwl, a Wayland version of dwm.

thanks for the clarifications and information scottro . I've no use for chinese/japanese/korean input so no actual knowledge on current support other than what I read. As for wayland, I prefer XFCE and I've had no great experiences with the current wayland "implementation" of it. So it's X11 for me until I have an actual reason to move.

 

[blackhole]

I never said working on UI was easy, nor did I mention UI at all in fact...

I was referring to the kind of "automagic", autoconfiguration, seen in other OS vs having to read, use a terminal and configuring it yourself. Proprietary OS will invest in this, as they have customers or "end users" as MS would call them.

 

[kpedersen]

In fairness, the flip side of OpenBSD's volunteer hardware efforts being so impressive is the continued lack of Bluetooth or Nvidia support, though those come down to conscious choices.

Indeed, Bluetooth and Nvidia support are conscious choices. Some examples where OpenBSD's efforts have yielded better results include Wifi on Raspberry Pi 3 (bwfm(4)) and support for recent Intel wifi (i.e iwx(4)) before FreeBSD got their Linux shim in place (and optionally imported iwx from OpenBSD). Suspend and resume has also been a little better on OpenBSD (because their earlier design and possibly because they reject mess like Nvidia blobs)

The gloomier prognosis for "what is the future of FreeBSD" in the long run is that if ever its USPs erode, corporates jump ship, and the funding dries up, then FreeBSD would be in a lot of trouble. It's a big project that tries to support a lot of features and use cases. Maintaining that code base is a struggle even with current resources. An all-volunteer effort to maintain it as a hobbyist OS would require tough decisions about what it's possible for the project to achieve.

Arguably it might clean up some of the priorities again and go back to being a more lean operation. Likely this would attract more technical developers because no-one really wants to work on a chaotic, messy platform.

I can't say it's obvious what would attract the kind of hardware dev who might voluntarily do that work in future: they're rare as hen's teeth, and their choice of which OS to hack in their free time is going to be highly personal.

Time generally demonstrates that there are always technical developers to keep this stuff in place. BSDs have never had more developers than they do today (likely due to Windows, macOS and Linux regressing considerably in recent years). So things look pretty bright.

 

[Jose]

But ultimately, this is why most open-source UI environments are still pretty trash and inconsistent, even after many decades of thrashing around. The last true usability study of a FOSS desktop was done by Sun Microsystems in ancient times.

Well, proprietary user interfaces have been steadily enshitificated for about a decade now. I think this is because UI peaked around 2009, but product managers and UI designers still gotta make a living. They've been pushing net-negative changes ever since.

This is why I'm really interested in the Gershwin project. I'm hoping it'll turn into bringing a 2009-style UI to the open source desktop.

...Other operating systems (not all, of course) are drifting inexorably into being access points on someone else's network, that is effectively not your computer, and hence not free as in freedom; what you are allowed to do with the machine is controlled by whoever owns and runs the network, not you. What you end up with is an opaque leaf-node like a phone handset, rigidly controlled by the network owner, that you are not free to do what you want with...

We are not alone;

You might be reading all of this and thinking, is this a farewell letter to personal computing? Is this the end of Framework? No, this is a manifesto. No matter how inevitable the AI-takes-all scenario may sound, as long as there is a person in the world who still wants to own their means of computation, we will be here to build the hardware that enables it. That means computers that you can own at the deepest level and do what you want with, whether that is choosing your OS, modifying your hardware, or even just keeping your data and computation local rather than leased from the cloud. We won’t get there all at once, but we will always be fighting for a future where you can own everything and be free.

Framework [Next Gen] Event is live on April 21

We can’t wait for you to see what we’ve been working on.

frame.work

 

[kpedersen]

This is why I'm really interested in the Gershwin project. I'm hoping it'll turn into bringing a 2009-style UI to the open source desktop.

Nice. That is shaping up quite well. I particularly like their policies of not spraying 3rd party programs all over the UNIX filesystem.

Weirdly I was never into the Mac OS X interface, I found it a bit clunky but at this point, anything from ~2009 is an improvement. The important part I see is having GNUStep as the foundation, hopefully leading to some consistency.

 

[cracauer@]

I don't know much about the general UI on macOS, I only use the window manager. And that one sucks.

 

[mer]

I had an original Mac (the beige box with the 9inch B&W screen) then a couple iterations of macOS. The biggest draw was consistency. Applications were consistent. Window decorations, open/close/minimize etc. Up through I think the 2009 timeframe applications held to this.
Then things loosened and apps started to differ.

Gershwin: I think the author/driver has actually posted here a few times. I think GnuStep is one of the better frameworks, yeah, Objective C which is honestly not bad syntactically. Needs to have a FreeBSD port

For look and feel and usefulness, I've been using WindowMaker for at least 20 yrs, because "it just works for me".

 

[kent_dorfman766]

A disturbing theme in this thread is that lack of hardware support is a conscious choice. It most certainly is not. Hardware support requires component manufacturers to disclose their product control API, which most do not, unless licensee is willing to buy many units and sign an API non-disclosure agreement. One of the things I prefer about the BSD dev crowd is the greater gathering of grey matter, and the seeming acceptance hat reverse engineering hardware is a risky proposition that usually does not pay off. Back in the day bad software could not harm hardware. That is no longer the case with "software defined EVERYTHING". A few well paced out of bounds values in hardware registers and things can smoke.

wifi seems to be a common pet peave among those who really don't understand the driver model. If BSD devs don't have access to docs for the HAL (hardware access layer) for a particular chipset then no driver will be forthcoming.

Another common example the "how hard can it be" crowd uses is the RPI community development. They need to understand the RPI was developed by the good graces of a (broadcom engineer?) who wrote binary code to allow the FOSS community to access a side channel ARM processor embedded in a proprietary ASIC. RPI was NOT 100 percent open, but depended upon corporate support to get off the ground.

For any open system standards to continue to flourish in the future, consumers and govt need to be on the "we wont buy closed proprietary solutions" bandwagon.

 

[Jose]

Gershwin: I think the author/driver has actually posted here a few times. I think GnuStep is one of the better frameworks, yeah, Objective C which is honestly not bad syntactically. Needs to have a FreeBSD port

Maybe here?

M

Other Thread 'Gershwin Desktop Environments'

Jan 11, 2026

The Gershwin Desktop environment featuring the first iteration of the native window manager was presented today during the GNUstep monthly meeting. This was a huge milestone for us today with a wealth of information about the design and implementation which I believe will interest a lot FreeBSD enthusiasts like myself.

View: https://youtu.be/DDwLzy8map8


Also some quick info about it:

GitHub - gershwin-desktop/gershwin-desktop: Desktop Environment based on GNUstep welcoming to switchers

Desktop Environment based on GNUstep welcoming to switchers - gershwin-desktop/gershwin-desktop

github.com

The build system here can install in just a few minutes on low spec hardware as other than login window...

• malco_2001
• Replies: 23
• Forum: Other Window Managers

• 
• 

 

[BigSneakyDuck]

I never said working on UI was easy, nor did I mention UI at all in fact...

I was referring to the kind of "automagic", autoconfiguration, seen in other OS vs having to read, use a terminal and configuring it yourself. Proprietary OS will invest in this, as they have customers or "end users" as MS would call them.

Apologies, I conflated the two because of the OP being about desktop working out of the box - which obviously you get with macOS or Windows. Still there are people who pride themselves on writing a lot of "automagic" config stuff. The NomadBSD and GhostBSD team do, also https://www.freshports.org/sysutils/desktop-installer and Alfonso Siciliano's installer script that the OP was partly about (hopefully ready for 15.1) also does a lot of config for the user.

Outside the *BSDs, there are plenty of Linux distros that try to shield the user from ever having to deal with a terminal. Some of which are at least "commercial" OSes even if not exactly "proprietary" - Zorin, Ubuntu etc. An example of a more hobbyist OS that's GUI-first and keeps the terminal for power users only might be Haiku? Not used it myself but been impressed by what I've seen of it in videos.

 

[Alain De Vos]

Maybe here?

M

Other Thread 'Gershwin Desktop Environments'

Jan 11, 2026

The Gershwin Desktop environment featuring the first iteration of the native window manager was presented today during the GNUstep monthly meeting. This was a huge milestone for us today with a wealth of information about the design and implementation which I believe will interest a lot FreeBSD enthusiasts like myself.

View: https://youtu.be/DDwLzy8map8


Also some quick info about it:

GitHub - gershwin-desktop/gershwin-desktop: Desktop Environment based on GNUstep welcoming to switchers

Desktop Environment based on GNUstep welcoming to switchers - gershwin-desktop/gershwin-desktop

github.com

The build system here can install in just a few minutes on low spec hardware as other than login window...

• malco_2001
• Replies: 23
• Forum: Other Window Managers

• 
• 

It's a desktop where install needs "root".

 

[Jose]

It's a desktop where install needs "root".

I think you mean it needs root to build. All desktops need root to install.

 

[mer]

I think you mean it needs root to build. All desktops need root to install.

Yep. root to build should be trivial to fix unless build needs to install new packages. To install, yeah, root/doas/sudo/mdo.

I think that's why a package would help. Looks like there is one for GhostBSD so doing a FreeBSD should not be too hard. Just need commit bit

 

[recluce]

What will I do if KDE no longer supports FreeBSD, if ever? Nothing, because I don't use it. If I were using it, I would simply use one of more than a dozen other desktop environment.

 

[kpedersen]

A disturbing theme in this thread is that lack of hardware support is a conscious choice. It most certainly is not. Hardware support requires component manufacturers to disclose their product control API, which most do not, unless licensee is willing to buy many units and sign an API non-disclosure agreement.

Indeed. To clarify, the conscious choice is not to specifically lack certain hardware support; but instead to not compromise the platform by bending over backwards for ridiculous hardware vendors. Not when there is so much choice of better hardware around these days.

I also recall reading (from mailing lists?) the OpenBSD developers aren't even against Bluetooth. What they are against are terrible implementations that currently includes pretty much all bluetooth stacks. Since Bluetooth itself is really not that critical in 2026, they prefer to hold to their guns here, rather than compromise.

Another common example the "how hard can it be" crowd uses is the RPI community development. They need to understand the RPI was developed by the good graces of a (broadcom engineer?) who wrote binary code to allow the FOSS community to access a side channel ARM processor embedded in a proprietary ASIC. RPI was NOT 100 percent open, but depended upon corporate support to get off the ground.

The Pi has many issues but I must say that if it wasn't for the original Pi demonstrating to hardware vendors that they could make a quick buck, we would not have ended up with any feasible ARM capable hardware today. I remember a specific dry spell for RISCOS where for 20 years we basically had to pass around crumbling hand-me-downs or run terrible (windows only) emulators as the only solution.