Klaus on Tilde Town

FreeBSD on the Desktop: the Saga continues

Just over a month ago, I made a decision changed my computing approach pretty much forever - I started using FreeBSD. At the time, FreeBSD was only a small curiosity of mine, a little side project that I wished to engage in order to broaden up my knowledge with different OSes, and I had no real intention on switching or leaving GNU/Linux at all.

Fast forward to today, and I've been using FreeBSD as my daily driver for a few weeks already, and my experience with it has been quite amazing as a lightweight, highly customizable OS - as long as you do the homework. And though I don't think I'm just quite ready to switch completely from GNU/Linux to FreeBSD yet, I believe that could be possible within the rest of the year.

Following my previous post on beginning FreeBSD, I decided to explore it further and properly take it from a command-line hobby and turn it into a Desktop OS, with as much usability as a modern Linux distro can provide. It was a small challenge even with the presence of great documentation in manuals, Handbook and even community assistance - not to mention that it's still not 100% complete to my taste. However, after all this effort today I can say at least that my machine is entirely compatible and usable as a desktop, and I am not afraid to daily-drive it anymore, perhaps except for the limitation of RAM in the machine, as I got it for free from the trash.

In this post, I'll share what were the steps I took to do this conversion and my insights as to how usable FreeBSD can be on the Desktop. Let's go.

My requirements for a modern desktop OS

Although a heavy command-line afficionado, I must admit that staring and living on the terminal all the time can be a little tiring, if not straight-out boring. Sorry terminal-lovers, but a modern and complete desktop requires a graphical environment, as well as a few other things. So when I set out for this project, I had the following requirements in mind:

elvie comic #3
If anything, a GUI allows you to run both text-mode and graphical applications...

I must say now that not everything in this list is 100% implemented at this point in my machine yet, but it's enough to satisfy my usage at this point. Let's see how we can enable these post FreeBSD installation.

Getting the graphical environment ready

As per my likeness for the console, I don't have a need for a full Desktop Environment, and would rather have a minimalistic window manager do the job instead, saving precious RAM and CPU cycles instead.

My original choice of Window Manager was awesome-wm, but I eventually decided to try something different, going back to floating window managers, and I finally settled with good ol' FluxBox. There's a common requirement to them, though, and that is Xorg.

Installing Xorg is easy, just go:

pkg install xorg

And the process is quick and simple, pulling in all dependencies and lasting only a couple of minutes. Configuring Xorg to work with your system, though, might require a little more work. As my machine was an Intel laptop, I had it "easier" due to the Integrated Graphics GPU being almost universal in all laptops, and the recent addition of DRM (Direct Rendering Management, not to be confused with the other type of DRM) into FreeBSD. Activate it by installing drm-kmod with pkg and add this line to /etc/rc.conf:

kld_list="/boot/modules/i915kms.ko"

Reboot and watch the screen flash briefly as the kernel module is loaded during the process. Test that it works by running startx: if you see a very simple window manager (twm, actually) and graphical applications load, Xorg is working correctly. I hear that desktop users with more advanced GPUs might have a little more headache to configure them correctly, including editing some xorg subconfiguration files, but magically, I was spared from this.

Launching a minimalist window manager from the console is also pretty easy: copy the file /usr/local/etc/X11/xinit/xinitrc as $HOME/.xinitrc and change the lines concerning twm execution for your window manager. Using FluxBox, for example, I only have to add:

fluxbox

To .xinitrc and the fluxbox init script takes care of the rest. Run startx again, and see that it loads correctly with your window manager of choice.

After this step, pretty much everything works like in a graphical Linux environment, with perhaps the only other missing component being sound. Sometimes, FreeBSD will guess wrongly which output your sound is supposed to come out from, and you have to direct it manually to the right one. For example, if you're not receiving sound from the 3.5mm audio jack, check out where is the sound being sent to first:

sysctl hw.snd.default_unit

If it comes out as 0 and isn't working, try setting to 1 or vice-versa (as root). I find that always setting it to one or another doesn't work every time, but thankfully once you check it and set it correctly, it persists until next boot. Clearly not as consistent as Linux here, perhaps, but still very much usable, and not an issue at all.

Power and session management

Suspending and resuming the machine was a sort of an inconvenient question for me which, thankfully, turned out to be quite straightforward. I don't know why when you search for "How to suspend FreeBSD" online the results give you the impression that this operation has shaky support. Even the official documentation doesn't sound too confident on the procedure, but maybe it's the wording they use.

I don't know if it was just me again being lucky with my hardware, but the solution is simple:

acpiconf -s 3 # as root

Or, even simpler, a no-brainer even:

zzz # as root.

If you wish to hibernate the session to disk (and safely run out of power to resume afterwards), change -s 3 to -s 4. This is also a good time to configure your user permissions with sudo, to which I grant passwordless permission for acpiconf because I'm the only user and want to suspend it quickly. There should be something similar for doas, but I don't use it.

To change the brightness in this laptop's display, I installed the package intel-backlight, and could change the brightness by issuing:

intel_backlight X

Where X is a number between 0 and 100. Again this is not as convenient as Linux's integration of laptop keys, but I'm sure a script could be derived to handle progressive increase and decrease, and combined with the appropriate keybinding. As it is, though, it's fine by me.

Lastly, how do I lock the session when I'm away? I don't use a display manager like SLiM or LightDM to start the session, so I went raw again and used xscreensaver. I bind Meta+L as a locking combination a-la Windows, and it does the job.

You might have noted that none of these are as well-integrated as a desktop Linux distribution at this point yet (for example: where's the power manager to respond to lid events), but it's usable and still practical. I'm sure that if I did a little more homework, I'd be able to figure it out, but for me is fine as it is right now. Other things, however, are not so fine, for example...

Dealing with WiFi

This is a biggie. And a potential dealbreaker for many new users.

Upon install, the FreeBSD installer attempts to detect and configure one network interface for you, and it can be your laptop's wifi (so long as drivers exist). I may have been lucky, but mine was autodetected, and "magically" the wifi worked, and has been working upon every boot.

Behind the scenes, however, there is no magic. Clearly, FreeBSD is doing something to get the wifi up upon boot, and we will have to do the same thing if we're connecting to a different wifi network. And we will because this is a laptop, not a server.

Is there a GUI tool that manages this? You bet, but for some reason it didn't work for me. So I had to go raw again.

Turns out that in both FreeBSD and Linux alike, the de facto way to get connected to WiFi with WPA security is to use the wpa_supplicant command. The process is as follows:

If you know the ESSID (name) of your WiFi network, generate a hashed passphrase with wpa_passphrase command:

wpa_passphrase ESSID_of_network passphrase_of_network

This command prints out something like this:

network={ ssid="john" #psk="password12345" psk=ae04ab09fe8c8a1bdc9a9fb9d41611a16fe50053c379e1bd759231a324f739a3 }

Add this bit to the file /etc/wpa_supplicant.conf (you can safely remove the plaintext passphrase from it) and save. Terminate any wpa_supplicant process that might be running, as root:

killall wpa_supplicant

Now restart it with this command:

wpa_supplicant -B -Dbsd -iwlan0 -c /etc/wpa_supplicant.conf

The -Dbsd flag specifies which driver (bsd in this case) should be used. My machine worked fine with the BSD one, but if you wish to use another, see the options for your machine listed with wpa_supplicate -h.

You now have made the connection, but might not have an IP address yet (no way to send or receive packets). To fix this, run dhclient to acquire a new lease:

dhclient wlan0

A big problem I ran into here was that, even though I had received an IP and was able to ping the router at this point, I could not access hosts outside the LAN. There were no routes defined. I'm still not 100% sure on how to fix this, but this is what worked for me so far:

route change default <the default gateway>

This will change the routing table to point at your default gateway (the router), which should know what to do with the packets. And if this doesn't do the trick, killing and restarting wpa_supplicant once again does the trick (go figure).

This is a big point and I feel that could be done better in FreeBSD. The steps are probably scriptable, yes, but why not make it into a graphical, systray-embedded application (that works)? I'm sure that many new users would be discouraged at this point.

Managing software

Ports are interesting, offer much flexibility, and sometimes are the only way you can use obtain certain functionality in FreeBSD, like MP3 support with ffmpeg. Packages, however, are much faster, practical, and easier to upgrade.

Given that in most cases the default behavior of software is absolutely fine by me, I chose to just use packages instead and it's been working fine. So if you come from a Debian/Ubuntu background, look into man pkg(8) and it's pretty familiar.

Conclusion so far

FreeBSD can be and is a solid OS for the Desktop usage - GUI or not. However, it does require you to do the homework.

After about just over a month and half of usage, though, discovering FreeBSD has finally stopped being "homework" and finally started becoming a joy on its own. It's efficient, lightweight and, perhaps more importantly, does the job exactly as it's told. I'm no longer "fearing" it, even though there's probably a lot more that I haven't learned and I'll face in the future, but I feel I'll be more prepared when it does.

As I learn more stuff, I'll be sharing it here as more snippets. Be sure to subscribe to the Updates feed so that you get them as I post here!

And also, I couldn't help but revisit that previous meme:

Meme revisited

Do you use FreeBSD on the desktop? How do you work around the issues pointed here? Let me know in Mastodon!

This post is number #11 of my #100DaysToOffload project. Follow my progress through Mastodon!

Last updated on 04/09/21