Moving From Windows to FreeBSD as the Linux Chaos Alternative
Back in the innocent days of Windows 98 SE, I nearly switched to Linux on account of how satisfied I was with my Windows experience. This started with the Year of the Linux Desktop in 1999 that started with me purchasing a boxed copy of SuSE Linux and ended with me switching to Windows 2000. After this I continued tinkering with non-Windows OSes including QNX, BeOS, various BSDs, as well as Linux distributions that promised a ‘Windows-like’ desktop experience, such as Lindows.
Now that Windows 2000’s proud legacy has seen itself reduced to a rusting wreck resting on cinderblocks on Microsoft’s dying front lawn, the quiet discomfort that many Windows users have felt since Windows 7 was forcefully End-Of-Life-d has only increased. With it comes the uncomfortable notion that Windows as a viable desktop OS may be nearing its demise. Yet where to from here?
Although the recommendations from the peanut gallery seem to coalesce around Linux or Apple’s MacOS (formerly OS X), there are a few dissenting voices extolling the virtues of FreeBSD over both. There are definitely compelling reasons to pick FreeBSD over Linux, in addition to it being effectively MacOS’s cousin. Best of all is not having to deal with the Chaos Vortex that spawns whenever you dare to utter the question of ‘which Linux distro?’. Within the world of FreeBSD there is just FreeBSD, which makes for a remarkably coherent experience.
Ghosting The Subject
Although FreeBSD doesn’t have distributions the way that Linux does due to it being a singular codebase rather than a duct-taped patchwork, you do get a choice as far as difficulty settings go. You can always pick plain FreeBSD with its functional but barebones installer, which dumps you into a command line shell and expects you to jump through some hoops to set up things like a desktop environment. This is generally fine if you’re an advanced user, or just want to set up a headless server system.
In case you’re more into the ‘just add water’ level of a desktop OS installation process, the GhostBSD project provides the ready to go option for a zero fuss installation like you would see with Linux Mint, Manjaro Linux and kin. Although I have done the hard mode path previously with FreeBSD virtual machines, to save myself the time and bother I opted for the GhostBSD experience here.
For this experiment I have two older-but-quite-usable systems at my disposal: one is a 2013-era Ivy Bridge Intel-based gaming laptop that’s a rebranded Clevo W370ET, the other a late-2015 Skylake PC with a Core i7 6700K, GTX 980 Ti and 32 GB of DDR4. To give both the best chance possible I also installed a brand new SATA SSD in both systems to run the OS from.
Down To Bare Metal
GhostBSD offers two images: the official Mate desktop version and the community XFCE version. Since I have always had a soft spot for XFCE, that’s the version I went with. After fetching the image, I used Rufus to create a bootable USB stick and made sure that the target system was set to boot from USB media. First I wanted to focus on the laptop, but this is where I ran into the first issue when the installer froze on me.
After a few hours of trying various things, including trying a known good Manjaro Linux installer which flunked out with a complaint about the USB medium, I figured I might as well give a Windows 10 installer a shot for fun. This actually got me a useful error code: 0x8007025D. While it broadly indicates ‘something’ being wrong along the USB-RAM-HDD/SSD path, it led me to a post about USB 3.0 being a potential issue as it changed some things compared to USB 2.0. The solution? Use a USB 2.0 port instead, obviously.
Long story short, this sort of worked: the GhostBSD installer still froze up once it entered the graphical section, but the Manjaro installer was happy as a clam, so now that laptop runs Manjaro, I guess.
A subsequent attempt to boot the GhostBSD installer on the 6700K system went much better, even while daringly using a USB 3.0 port on the case. Before I knew it GhostBSD was purring along with the XFCE desktop sparkling along at 1080p.
I’m not sure what GhostBSD’s issue was with the laptop. It’s possible that it found the NVidia Optimus configuration disagreeable, but now I have two rather capable gaming systems to directly compare Linux and FreeBSD with. There are no mistakes, just happy little accidents.
Gaming The System
Since any open source software of note that runs on Linux tends to have a native FreeBSD build, the experience here is rather same-ish. Where things can get interesting is with things related to the GPU, especially gaming. These days that of course means getting Steam and ideally the GoG Galaxy client running, which cracks open a pretty big can of proprietary worms.
Annoyingly, Valve has only released a Steam client for Windows, MacOS and Linux, with the latter even only officially supporting some versions of Ubuntu Linux. This is no real concern for Manjaro Linux, just with the disclaimer that if anything breaks, you’re SOL and better start praying that it’ll magically start working again.
Unfortunately, for FreeBSD the userland Linux ABI compatibility isn’t quite enough as the Steam DRM means that it goes far beyond basic binary compatibility.
The two available options here are to either try one’s chances with the linuxulator-steam-utils workarounds that tries to stuff the Linux client into a chroot, or to go Wine all the way with the Windows Steam client and add more Windows to your OSS.
Neither approach is ideal, but the main question is whether or not it allows you to play your games. After initially getting the Linux tools setup and ready to bootstrap Steam, I got thrown a curveball by the 32-bit Wine and dependencies not being available, leading to a corresponding issue thread on the GhostBSD forums. After Eric over at the GhostBSD project resolved the build issue for these dependencies, I thought that now I would be able to play some games, but I was initially sorely disappointed.
For some reason I was now getting a ‘permission denied’ error for the chdir command in the lsu-bootstrap script, so after some fruitless debugging I had to give up on this approach and went full Wine. I probably could have figured out what the problem here was, but considering the limitations of the LSU Steam approach and me just wanting to play games instead of debug-the-FOSS-project, it felt like time to move on.
Watery Wine
As it turns out, the low-fuss method to get Steam and GoG Galaxy working is via the the Mizutamari Wine GUI frontend. Simply install it with pkg install mizuma or via the package center, open it from the Games folder in the start menu, then select the desired application’s name and then the Install button. Within minutes I had both Steam and the ‘classic’ GoG Galaxy clients installed and running. The only glitch was that the current GoG Galaxy client didn’t want to work, but that might have been a temporary issue. Since I only ever use the GoG Galaxy 1.x client on Windows, this was fine for me.
After logging into both clients and escaping from Steam’s ‘Big Picture Mode’, I was able to install a few games and play them, which went completely smoothly, except for the elevator scene in Firewatch where I couldn’t look around using the mouse despite it working fine in the menu, but that game is notoriously buggy, so that’s a question mark on the exact cause. Between buggy games, Wine, and the OS, there definitely are sufficient parties to assign blame to.
Similarly, while the Steam client was a bit graphically glitchy with flickering on the Store page, and trying to access the Settings menu resulted in it restarting, I was able to install and play Windows games like Nightmare Kart, so that’s a win in my book. That said, I can’t say that I’m not jealous of just punching in sudo pacman -S steam on the Manjaro rig to get the Steam client up in a minute or so. Someone please convince Gabe to compile the Steam client for FreeBSD, and the CD Projekt folk to compile the Galaxy client for FreeBSD and Linux.
It should be noted here that although it is possible to use alternative frontends for GoG instead of its Galaxy client, you need it for things like cloud saves. Hence me choosing this path to get everything as close to on par with the Windows experience and feature set.
Next Steps
Aside from gaming, there are many possible qualifications for what might make a ‘Windows desktop replacement’. As far as FreeBSD goes, the primary annoyance is having to constantly lean on the Linux or Windows versions of software. This is also true for things like DaVinci Resolve for video editing, where since there’s no official FreeBSD version, you have to stuff the Linux version into a chroot once again to run it via the Linux compatibility layer.
Although following the requisite steps isn’t rocket science for advanced users, it would simply be nice if a native version existed and you could just install the package. Based on my own experiences porting a non-trivial application like the FFmpeg- and SDL-based NymphCast to FreeBSD – among other OSes – such porting isn’t complicated at all, assuming your code doesn’t insist on going around POSIX and doing pretty wild Linux-specific things.
Ranting on software development aside, for my next steps on my FreeBSD/GhostBSD journey I’ll likely be giving approaches like this running of Linux software on FreeBSD another shot, barring finding that native video editors work well enough for my purposes.
Feel free to sound off in the comments on how to improve my experiences so far, as well as warn me and others who are embarking on a similar BSD journey of certain pitfalls.