2024: The year of desktop FreeBSD?

However what is the problem with wifi on FreeBSD? I've not come across any reliability issues so far with wifi myself.
Connects to the wrong hotspot on boot, gets the incorrect IP address, and I tried troubleshooting for years, editing /etc/wpa_supplicant.conf , and just giving my hotspot priority is not not enough. I had to learn to do the service netif restart , followed by bsdconfig wireless EVERY TIME, by hand. There's probably something beyond editing /etc/wpa_supplicant.conf , would be nice if I knew what it is. Once I connect to the correct hotspot, I don't have issues, true.

I imagine that the Bluetooth stack is similar - Yeah, you can edit config file, but if you don't edit the correct ones, the end result (even if successful) won't persist across reboots. I'd think that making such behind-the-scenes details get sensible defaults (like Xorg does) would go a long way. On FreeBSD, you can either compile Xorg or install it from packages, and it works pretty reliably. Would be nice if wifi and Bluetooth had the same level of reliability. The available drivers do support decently capable hardware, but proper config of those drivers is a house of cards that can fall apart, and be very difficult to put back together without a reinstall of the whole friggin' system.
 
A December 2023 RFC included a plan to write a Bluetooth device management utility. I vaguely recall a subsequent change of plan, or someone else taking the reins in this area.

… I remember reading some time last year… someone was writing a new BT stack for freebsd. I don't know what happened.

I don't recall anything about a new stack.

For the upcoming status report:

… future tasks include:
  • Write a bluetooth device management utility.
 
I don't recall anything about a new stack.

For the upcoming status report:
I'm probably talking rubbish... i usually do! I've done a web search but I can't find the thing I read or any news of a new bt stack.

I've actually pulled the wifi/bt card out of the new mini-pc box I'm currently using, so I can't try out the latest instructions in the handbook. One older howto I remember trying was http://www.oook.cz/bsd/bluetooth.html , and I couldn't get that to work with the speakers I was trying to use, that was on a thinkpad. I noticed there was an update in 2022, and a freebsd foundation guide here https://freebsdfoundation.org/resource/networking-basics-wifi-and-bluetooth/ which seems to be based on the current handbook version (I guess the handbook would be the most up to date). So maybe it's worth giving it another try some time. The last couple of appends in this thread, which are from 2024, are quite encouraging: https://forums.freebsd.org/threads/...nd-use-bluetooth-headphones-on-freebsd.82671/

As for general desktop use, freebsd works pretty well. I've pretty much got all the tools I need, although I'm probably not a very demanding desktop user, I still tend to do a lot of things in the terminal. It would be nice if there was a waterfox port but you can't have everything. But all the main stuff I use is there. As for standardising on a particular desktop.. linux still hasn't solved that one either, in fact it seems to be getting ever more fragmented (with wayland v. X11, etc) rather than converging on one soluton. I think the way freebsd does things now is pretty good, let the user choose, or let derivatives like ghostbsd ship with a specific desktop.
 
Connects to the wrong hotspot on boot, gets the incorrect IP address, and I tried troubleshooting for years, editing /etc/wpa_supplicant.conf , and just giving my hotspot priority is not not enough. I had to learn to do the service netif restart , followed by bsdconfig wireless EVERY TIME, by hand. There's probably something beyond editing /etc/wpa_supplicant.conf , would be nice if I knew what it is. Once I connect to the correct hotspot, I don't have issues, true.

I imagine that the Bluetooth stack is similar - Yeah, you can edit config file, but if you don't edit the correct ones, the end result (even if successful) won't persist across reboots. I'd think that making such behind-the-scenes details get sensible defaults (like Xorg does) would go a long way. On FreeBSD, you can either compile Xorg or install it from packages, and it works pretty reliably. Would be nice if wifi and Bluetooth had the same level of reliability. The available drivers do support decently capable hardware, but proper config of those drivers is a house of cards that can fall apart, and be very difficult to put back together without a reinstall of the whole friggin' system.
Interesting, did you open a thread here about it?

Truth be told I never got that to work properly on Linux either. To this day it is as if the "priority" setting in wpa_supplicant.conf is completely ignored. If I want it to connect specifically to an AP, I have multiple wpa_supplicant.conf files, each with single AP's listed, and then call the binary with the config file I want.

Its not enough of a headache for me right now, but in future I may well write a perl script that automates the above so I can call the script with the AP I want and it will auto-reload wpa_supplicant with the correct conf file.

The only FreeBSD wifi issue I've come across so far is when switching from monitor mode to managed mode after using Kismet. For reasons unknown the entire machine locks up when after destroying the interface and re-creating it in managed mode, requiring a hard reboot. It only happens after running Kismet, so I suspect it is something to do with Kismet rather than with the wifi stack itself.
 
I have been trying to get a FreeBSD desktop working off and on far about a decade. I finally got things working with KDE and Slim last year, and life was good. Then I got a ritzy new NVIDIA GPU and had to install the NVIDIA driver, and suddenly the desktop did not work, and I wasn’t a studly enough X-windows guy to fix it.

I tried SUSE Linux for a while, and it was OK, but I am really more comfortable with FreeBSD, since I have several FreeBSD CLI machines. My Linux machine died (mobo problems), and when I get it going again, I think I am going to give the FreeBSD desktop another shot. So I am hoping that for me, 2024 is the year of the FreeBSD desktop.

BTW, for anyone else like me, who has struggled to set up a FreeBSD desktop, here are a couple of nice, although dated, references:

Nicole Reid (R11): https://cooltrainer.org/a-freebsd-desktop-howto/

Colin Percival (R12.1): http://www.daemonology.net/blog/2020-05.html
 
Thanks,

… dated, references:

Nicole Reid (R11): ssssshttps://cooltrainer.org/a-freebsd-desktop-howto/

My comment when it was reshared by someone (not the author) in 2022:

Parts of the page are useful but honestly, too much is outdated for me to recommend it as a point of reference. It's more than five years old!

Problem areas of the page include:
  • Cuse4BSD
  • FUSE
  • GNOME
  • HAL
  • KDE
  • KDM
  • pipelight
  • sound
  • Wine
Past discussions of the same page:
  • {link withheld}

Plus, I dislike the description of ZFS as very memory-hungry. It's an old myth that should not be perpetuated in that way. (The first edition of the page was more than twelve years ago.)

Author's comment in 2021:

"I do plan to update it along with the rest of the site, but I fell down the rabbit hole of having fun working on publishing tools instead of actually publishing anything with them :p …"
 
Last edited:
Colin Percival (R12.1): http://www.daemonology.net/blog/2020-05.html

For the Dell Latitude 7390, from the conclusion:

… it took me two months worth of fiddling with this in my spare time to fix some of the "glitches" which arose; while there wasn't anything particularly challenging, I expect that most people would give up long before they fixed all of the issues I ran into. …
 
Last edited:

Attachments

  • 1720376839991.png
    1720376839991.png
    66.8 KB · Views: 77
Well, 2024 is now officially the year of the FreeBSD desktop, at least for me.

After more than a little bumbling around (as well as a slight detour while I decided if I wanted to give TWM one more try--NO) I now have a working desktop with xfce4 and lightdm.

It is not perfect yet, but it is quite workable.

Yay!
 
"If your preferred system does not provide the features you require, just change your requirements" certainly turned out to be a great choice for when I moved to FreeBSD as my main desktop too :D

It's of course 100% subjective & personal, but I think a lot of Linux techies would be surprised how little "stuff" you need to get a really nice setup that fits your style/preference if you're willing to take a few steps back and ask yourself what you truly need.
I probably couldn't list five things that are wrong/missing when it comes to my FreeBSD desktop experience. The biggest one would be "better bluetooth"/"better wifi", the other one would be proprietary DRM support. But if the 2nd thing on the list is already something I'd only need to watch brain rotting content on streaming platforms, I concluded that I don't truly need it.
 
"If your preferred system does not provide the features you require, just change your requirements" certainly turned out to be a great choice for when I moved to FreeBSD as my main desktop too :D

It's of course 100% subjective & personal, but I think a lot of Linux techies would be surprised how little "stuff" you need to get a really nice setup that fits your style/preference if you're willing to take a few steps back and ask yourself what you truly need.
I probably couldn't list five things that are wrong/missing when it comes to my FreeBSD desktop experience. The biggest one would be "better bluetooth"/"better wifi", the other one would be proprietary DRM support. But if the 2nd thing on the list is already something I'd only need to watch brain rotting content on streaming platforms, I concluded that I don't truly need it.
I am having some trouble getting the built in GPU in my Intel Core i3-1215u CPU to handle resolutions greater than 1024x768. I am working on that problem, but meanwhile, I accidentally set the resolution too high in the xfce4 desktop settings, causing my logins through lightdm to fail.

I looked on the web and found out that the xfce4 settings are under ~/.config, so I fixed them with the CLI, and I was back in business.

On a Windows system, I would have had to go into the registry, but since the registry editor requires a working graphic session, that would have been a real problem.

(If I may get on my soapbox and preach to the choir for a moment, I really don’t understand how the Windows registry went so wrong. I understand the lure of centralizing initialization parameters. The mainframe software vendor I used to work for tried that once with all their products, though they eventually gave up. But the Windows registry has evolved into a massive tree, where you have to go a dozen or two levels deep to find anything, and deal with a lot of keys that are GUIDs, and you can only access it with a special editor. I hope FreeBSD never goes that route. I understand that they wanted to be able to ship user settings to other machines via Active Directory, but it seems like you could get similar results by doing a tar/gzip on some of the ~/. files/directories.)
 
Last edited:
But the Windows registry has evolved into a massive tree, where you have to go a dozen or two levels deep to find anything, and deal with a lot of keys that are GUIDs, and you can only access it with a special editor. I hope FreeBSD never goes that route. I understand that they wanted to be able to ship user settings to other machines via Active Directory, but it seems like you could get similar results by doing a tar/gzip on some of the ~/. files/directories.)
FreeBSD has sysctl, which is a rough equivalent to Windows Registry.
FreeBSD has LDAP and NFS, which are a rough equivalent to Active Directory and Group Policy Objects.
FreeBSD does have cron, which is a rough equivalent to Scheduled Tasks in Windows.

It's just a matter of figuring out how to implement a given task in a given OS.
 
breakage (nothing broken).
Single UNIX specification suggests otherwise kiddo. vi is marked optional in POSIX, but mandatory in SUS.

But you can certainly do what you want. Though similarly to the unsupported setups, don't be surprised if there is a lack of replies to intentionally broken installs. I for one am certainly not wasting any more of my time with this convo going forward :)
 
Agreed, in many ways Linux's push for mainstream popularity is what resulted in its general degradation as an OS over the last decade or so. I see little benefit in FreeBSD following the same popularity contest.

There are BSD's out there that aim to be "Desktop friendly" by default, some of them like GhostBSD are based on FreeBSD itself.



From my side of things, FreeBSD makes an excellent UNIX workstation OS already. If I wanted something "out of the box" there are options already as mentioned, but its flexibility allowed me to make a desktop OS that suits me perfectly (in the case of GUI's, Windowmaker is my drug of choice).


I can't comment on BT as I never used it on anything except smartphones (and I only use it there because phones don't provide proper wired ports anymore) so I don't miss it on PC's at all. However what is the problem with wifi on FreeBSD? I've not come across any reliability issues so far with wifi myself.

It took me about a decade off and on to get a desktop working on FreeBSD. But I would have had one going a lot sooner if I had discovered the FreeBSD forums earlier. Xorg is getting easier to configure, but it still is not a piece of cake, especially if you have unusual hardware. But every problem I have had with the latest installation has been answered in the forums.
 
For me, both with and without NVidia, X is usually pretty easy. The only issue I had was at work, when I first started there, and had multiple monitors, I had to use the NVidia GUI config tool to get what I wanted. But, reading lgrant's post, I realized that for many years it's been really easy. The only things are wireless (but a lot of people use wifibox--for some reason, it hasn't worked for me, but even with FreeBSD's slower wireless, youtube, etc., are no problem), and some video sites, e.g., Netflix, which is ironic as it uses FreeBSD for content delivery (but I think a lot of it is stored on Amazon on Linux). There's a tutorial on the forums about getting it working, but I'm too lazy to look right now. vermaden has a tutorial on it as well. https://vermaden.wordpress.com/2021...art-27-configuration-netflix-signal-telegram/

I can do all that I need to do on it. One thing I sometimes think of is that ArchLinux is one of the major Linux divisions, and they just say that if you want a point and drool type setup, Arch probably isn't for you. (Their wording is more polite, of course). I think GhostBSD is doing a Good Thing (TM) but it may not be needed to make FreeBSD a Windows or Maclike experience. I'm sure I'm not the only one who has set up a Mac or Windows machine for a family member, and thought, pft, Linux and BSD are much easier to set up.

If there was an emergency, and my wife had to use it, I have an XFCE-4 desktop as well, with instructions for her to get to it. (A little script choose which window manager to use).
 
Yesterday we had a nearby lightning strike. It took out the cable modem, a couple of Ethernet switches, one port on the router, the cable TV box, the TV, and my Windows machine. (BTW, everything is on UPS or surge protection.)

I have a new Windows machine coming in about a month. Luckily, I got my FreeBSD/xfce4 desktop working a couple of weeks ago, and I can do almost everything I need. (I need the Windows machine for Adobe and Reallusion products, but I can get by without them for a while.)

I am very happy. FreeBSD FTW!
 
FreeBSD has sysctl, which is a rough equivalent to Windows Registry.
I'm trying to make sure I understand where sysctl fits into the scheme of things. My understanding, based on reading Dr. Colin Percival's blog entry on configinit, is that it is part of the philosophy of Unix to configure things via configuration files, rather than commands.

CloudInit works well for its original purpose, but is less than ideal for FreeBSD systems, ... it is designed around a concept of configuring a system by running commands rather than editing configuration files.

...BSD systems are far more edit-configuration-files oriented (to the point that /etc/rc.conf might be the only configuration file which needs to be edited on some systems)....

So I am thinking that the purpose of sysctl is to deal with things that need to be adjustable on the fly, without a reboot or restarting a service.

Back in the day, I worked for a company that made software products for IBM's VM/370. At the time, the user file contained a virtual deck of 80-column punch cards. The company made tools that made plucking a card out of the deck, changing some fields and reinserting it in the deck easier. The whole setup was kind of ugly, and if sysctl keeps from having to do something like that with the config files, that is a good thing.

But I am assuming that everybody still uses config files for static configuration variables. And since /etc/sysctl.conf is used to set sysctl values when entering multiuser mode, things can be set up using only configuration files when using configinit.

If my understanding of things is correct, I do not have to worry about sysctl ever turning into the bloated mess that the Windows Registry is.
 
So I am thinking that the purpose of sysctl is to deal with things that need to be adjustable on the fly, without a reboot or restarting a service.
Not quite... sysctl is mostly for hardware management. For example, networking: net.local.stream.recvspace=65536. Did you know that running sysctl -a | wc -l tells me that I have 14551 of those on a 13.2-RELEASE system. Most of those values should really be set on boot so that the system is stable. Some of those are possible to adjust without needing to reboot, like hw.snd.default_unit, some are not. .conf files are for stuff that needs to be easily editable without needing to reboot. But even with those, you'd still need to restart the service, like the httpd daemon or the firewall.
 
I'm trying to make sure I understand where sysctl fits into the scheme of things.
Look no further than its man page "sysctl -- get or set kernel state".

It's a configuration utility for the kernel, and only the kernel. Contrast this with the Windows registry, which is a configuration system for everything. "A centralized configuration database" is one of these things that sounds good, but is actually a disaster in practice.
 
Back
Top