FreeBSD, Linux, and I (2023)

Author: Jonathan Vasquez <>
Last Updated: 2023-01-13-1020

fn main()

Hello everyone ;D, since the year is almost over (2022), I wanted to take some time to write down my findings and realizations regarding my life after switching from Linux to FreeBSD, on the desktop and laptop. I switched my server to FreeBSD from Gentoo back in 2018.

Framework Laptop as a FreeBSD Machine and Desktop Replacement.

If anyone has been tracking my post, they'll know that for most of 2022, I've been running FreeBSD as my main OS, and specifically running it on the Framework Laptop, which has been a rollercoaster of a ride. I really enjoyed and still support Framework, their mission, and will be keeping the machine for now, but unfortunately, even though FreeBSD can run it, the lack of proper support for all of the USB Type C ports (which the laptop uses as its only form of I/O expansion for any type of connection), lack of Thunderbolt support, and unstable and slow native iwlwifi driver, means that this machine has no effective way to communicate between machines and transfer data at performant rates. For example, on a fresh syncthing sync from the laptop to my FreeBSD server (using a gigabit connection), the laptop only has about 2 MiB down over the iwlwifi driver. Using the ethernet expansion card, I got about 10 MiB down. For comparison, on my FreeBSD desktop, I get 108 MiB down. On Linux, I get roughly the same on both the desktop and the laptop over a wired connection. I believe the laptop also had very good performance on Linux with the wireless connection. The only way I can get high performance in the meantime is to use wifibox. A speed test on the native iwlwifi driver gave me about 15 Mbps Down, 4 Mbps Up, and with wifibox it gave me 131 Mbps Down, 36 Mbps Up! There are also other issues like power drain during sleep, and all of that "fun" stuff.

Given all of these issues, I continued thinking about how I want 2023 to be and how do I want to continue evolving my relationship with technology. Do I want to go back to Linux? Back to a desktop? Continue using FreeBSD? Maybe go back to Windows? What trade offs can I continue to make to get what I want? Is my life easier, or happier? Sometimes, what gives you "easiness", "simplicity", and "happiness" in one domain, comes at a cost of loosing control over how you administer and use your machine. This could either be because it's a proprietary OS that prevents you from making modifications, or because you are using an open source OS that contains a design and infrastructure so tedious and complex, that you don't even really wanna spend your time on there anymore. Thus generating feelings and emotions that are the exact opposite of what happiness is suppose to feel like.


General Reflections

  1. Switching from Gentoo Linux to FreeBSD for my server (in 2018) was the right decision. It has allowed me to have an easier to maintain, predictable, and highly customizable system, still running on OpenZFS. If anything, it basically made all of my Gentoo/OpenZFS work obsolete. The move from Gentoo to FreeBSD was mostly natural, given that Gentoo was partly inspired by FreeBSD from back in the late 90s when drobbins tried it.

  2. Switching from Linux to FreeBSD on my laptop and daily driving it for the majority of 2022 yielded A LOT of insights, knowledge, and pain. However, with that said, I've fallen in love with FreeBSD as an OS for everything, and I'm able to now use it for all of my stuff (gaming excluded). When it comes to gaming, I have a separate gaming laptop running Windows that only does that.. aka a Wintendo, lol. Furthermore, I do prefer gaming on Windows anyways for nostalgia purposes, and also straight up compatibility of my old games. I don't tend to buy many new games anymore since I don't like paying for products that I don't actually own. I only support and purchase games that are Single Player, Offline, and DRM-free. I would recommend GOG if you want to buy DRM free games. Also, the gaming related projects I care about maintaining, primarily Diablo II, are Windows projects, and require me to have a Windows system to continue my reverse engineering work within the Win32 ASM land. Windows XP & 7 Forever <3.

  3. If using FreeBSD, make sure that you look for supported hardware before you buy. FreeBSD hardware support obviously is behind Linux. I remember back when I first started using Linux in 2006 (Ubuntu 6.06 (Dapper Drake), Fedora Core 5 (Bordeaux)), I had to look for compatible hardware as well. This is still something that you should still do on Linux, but it's not as critical anymore. Pretty much most hardware that I throw at Linux in 2022, will be supported and run efficiently.

Reflections on Linux

However, there are also some critical points that I've continued to internalize and have become clearer throughout the years. One being that Linux is no longer the platform I want to continue using for my day to day life. I still use it for some simpler devices where I don't necessarily care about controlling the internals (like my RG351P running AmberELEC, or my open source router running DD-WRT. For everything else, FreeBSD is the one I've connected with the most. OpenBSD, NetBSD, and DragonFlyBSD are all good and necessary projects in their own ways, but my main focus is on using a general purpose BSD based OS, and OpenZFS is one of the main requirements.

Below are a few reasons why I no longer use Linux as my main open source, UNIX-like operating system:

  1. I no longer like the way that Linux is designed, architected, and developed. Linux has always been developed in a decentralized, distributed, and fragmented way. Meaning that since Linux is not a complete OS and is just the kernel, the kernel is developed in one location by one group of people, the userland (GNU, usually..) is developed in another place, and every other part of what I would consider "the core stack", is developed at other locations. The benefits of this approach (and how I tried to rationalize it for a long time) is that this decentralize approach means that Linux can rapidly develop in all directions as long as people are motivated to continue working on whatever project they like to work on. We can obviously see the success Linux has had because of this. The con however is that the operating system lacks cohesiveness and it becomes very difficult to have a stable platform on this type of ecosystem. System stability and reliability suffer because of this as well. It also forces people to have to learn different sets of tools that do the same thing but that aren't actually used or shared with the rest of the Linux ecosystem. Debian and RHEL have done an amazing job in trying to create a stable platform for Linux. But the design could be better. Due to the above foundational ecosystem issues, we see various groups trying to just "abstract away" either the dependencies, or the foundation itself, via Docker, Flatpak, Snaps, AppImages, etc. I actually like Flatpak and AppImages and given where things are at, I believe those are the correct approaches going forward.

  2. I don't like that Linux-based OSes don't have a clean separation of concerns between the "base system" and "third party packages". By distros simply bundling and merging both the "base system" portion of their distros and all the packages they are packaging, in the same folder hierarchy (/bin, /sbin, /usr, /etc, ..), means that system upgrades are more painful and dangerous. It is hard to distinguish which parts of the base system need to be changed in order to do a system upgrade, without relying on a lot of tools for processing. Of course, when a system upgrade is performed, particularly when the toolchain ABI is upgraded (usually during a major version), all base system packages and third party packages will need to be rebuilt against the new toolchain. But the overall administration, separation of responsibilities, and conflict resolution is easier when things are separate. There is also another important piece to consider, disaster recovery. In the scenario that you need to drop into single user mode to recover your system, ensuring that you have a pristine, and reliable base system is critical. The base system should still be functional even if something provided by a third party package is affected. FreeBSD on the other hand does have and enforce the concept of "Base System". All of the core pieces of FreeBSD live in the usual core directories, however, any third party applications are isolated in /usr/local. So much so that if I wanted to let's say "reinstall FreeBSD" for the purposes of wiping out all installed user customizations, simply doing rm -rf /usr/local/* would pretty much get you 99% there. After that, you'll just have the base system left.

  3. I dislike the GPL, and the stigmatization of proprietary software for any reason, and the notion that it's inherently evil and unethical. There was a time when I was younger when I really liked the GPL (v2), but as I got older I realized that even though I am a strong supporter of Open Source (primarily preferring permissive licenses like the Simplified BSD License, MIT, Apache License 2.0, or even the "file level copyleft" license, MPL 2.0), and I strive to use only Open Source components, I've always been perfectly fine with some applications that are proprietary. There is nothing objectively wrong with proprietary software, and it isn't "evil" or "unethical". Are there preferences we would all like? Yes. Does it mean that the people writing proprietary software (either to make money or just because they want to protect their creative interests) is wrong? No. Simply because something is Open Source, doesn't make it better, and it definitely doesn't necessarily make it safer. We could see instances where having something proprietary may actually be better for the society. One instance that comes to mind is when people open sourced tools they wrote to automate the purchase of sneakers. This code essentially is helping people that want to purchase sneakers for the purposes of reselling and making a profit. I don't view this as "giving people a fair shot to buy a pair of sneakers", I look at it as accelerating scarcity. Most people that want to buy shoes are not going to use this bot, and won't even know about it. I would argue that I would prefer for just one person to have the ability to do this, rather than having potentially thousands of people globally running this code in parallel. Coming back to the main topic, having a big portion of the Linux community believing that GPL is good, and proprietary software is objectively evil, is problematic. Let alone that a lot of policy decisions are based on this idea and it even negatively effects other open source projects. For me personally, as a person that worked on Gentoo/OpenZFS on / integration, the whole CDDL/GPLv2 is just sad. The Linux Kernel and OpenZFS are two open source codebases that cannot be merged. I have heard the stories about the CDDL being made explicitly to prevent it from being merged into GPLv2 codebases. Given that there are conflicting stories from various sides (The Sun lawyers at the time of writing the CDDL vs some of the engineers that were at Sun), I will abstain from speculating on the original intentions, but the point is that the CDDL is ultimately a file level copyleft license (like the MPL 2.0.. CDDL actually came from a modified MPL 1.1 licensed IIRC). The GPLv2 essentially conflicts with the CDDL because the GPL has the attitude of "all code needs to be under the GPL", where as the CDDL is just like "hey, you can use me in your projects, but don't try to change my license". Hence, FreeBSD has OpenZFS in the main system and Linux doesn't. With all of that said, I figured that I may want to just surround myself with more like minded people. This doesn't mean that everyone in Linux believes Free Software / GPL is good, and it also doesn't mean that everyone in the Linux and FreeBSD communities are "nice, and good people". All communities have toxicity.

  4. I dislike major infrastructure components being constantly rewritten. Over the past 16 years using Linux, A LOT has evolved and improved, but then at the same time it almost feels like a lot of my knowledge in how to administer a Linux system isn't necessarily directly applicable, which makes me feel like I'm wasting my time. I've used Debian, openSUSE, Gentoo, Arch, Knoppix, PCLinuxOS, what have you. I was a Gentoo Developer for a long time (primarily focusing on Gentoo/OpenZFS on / integration), and I even used Arch and maintained some AUR packages back in 2011, before I left Arch and went to Funtoo, and then Gentoo. It's not only that different distros are using different tools, I'm not necessarily against that, but having your sound system being ripped apart and rewritten multiple times in less than 5-10 years is pretty crazy (ALSA -> PulseAudio -> PipeWire). Now we have X11 -> Wayland happening, although that would have been necessary eventually, X11 is crazy old and not really maintained anymore. You may say that 5-10 years in the computer world is a long time, and yea it is, but sometimes things have been and are working perfectly fine and they don't need to be rewritten. There are bigger issues to solve. systemd has definitely been the worst and biggest culprit IMO. I've used it, it works fine, but it's also annoying and it does too much. To keep it light and give systemd some credit, I know that the systemd utilities are all modular and are just hosted under one umbrella, and all of that good stuff, but I don't like that all of these tools are under one group that I don't necessarily agree with regarding how a system should be designed and administered. Especially since they aren't necessarily the "authorities" on creating a cohesive OS, but then again, Linux is not a full OS anyways so there is no "authority". I also like having simple, predictable, systems that are simply configured via text files. Not everything needs to be configured with some binary format. Constantly rewriting things is a waste of time and constantly rewriting them in fundamentally different ways at a rapid pace means that the knowledge people are investing their time in is partly wasted and doesn't directly transfer over. With every piece of knowledge I acquire on FreeBSD, I feel like 99% of it is directly applicable today and will continue to be applicable. I suppose this is where the incremental evolution vs radical evolution come into play. I feel for things to be rewritten, there needs to be a relatively strong reason to do so, and when doing so, should try to do it in a graceful way. Something I actually am fine with is the push to rewrite core operating system components in a memory safe language, such as Rust (I no longer recommend Rust, use another language). The fact that it's been 40 years since C/C++ were introduced, and we are still experiencing memory safety issues in core operating system components (and many other layers), is a problem. James Gosling, the creator of Java, foresaw these issues 30 years ago, and we are still repeating these exact mistakes. These mistakes all translate into real world issues with potentially massive repercussions. Fortunately, it seems that the government has finally felt the heat regarding all of this and has instructed various government agencies to issue guidance on what types of languages to use to prevent these exact issues. It is a sign of the times. We all need to do our part to take these types of issues more seriously. Use whatever memory safe language you like. I love and respect C (and I'm not a fan of C++), but I do acknowledge that the freedom and expression of C (which is awesome!) comes at a high price. Humans are just not good at managing memory and it doesn't matter how 1337 you are, you are gonna make a mistake, and you can't keep the state of the entire system, especially as it gets bigger, all in your head. Even static analyzers can only help you so far. Maybe we do need something like Rust (which I do like even though it irritates me sometimes lol), to just say, "hey.. this is just not allowed and I'm not compiling it". At this point I see Rust as literally infusing human intelligence into the compiler process, making the compiler not simply just a program that converts human readable source code into machine code (or object files if you want to stop before the linking stage), but actually guiding us in the right direction. I would say that compilers historically, even just stopping compilation if you forgot a semicolon, or yielding some basic warnings, are actually the same thing Rust is enforcing, it's just that the compilers of the past were only stopping or warning you for a very small group of issues.

  5. I don't like that the UNIX philosophy and some of its traditions are not being followed nor respected. Don't get me wrong, things always change, and evolve. So do we. The UNIX philosophy isn't a religion, and it can adapt and be changed. It is a philosophy after all. However, there are critical pieces of knowledge that we all depend on that have served us well, and still hold true today. New philosophies should be derived from the UNIX philosophy in a way that doesn't contradict it. If we do this, we may end up with better results. At the moment though, I feel as if people are almost blatantly attacking it (and POSIX compliance). Linux isn't the "new POSIX". As smarter people than I have said before, mono-cultures are bad.

Reflections on FreeBSD

With the above said, I also have some thoughts on FreeBSD from using it on my server since 2018, and using it as my daily driver for the majority of 2022:

  1. We need better desktop support for wider adoption. I think this idea is not necessarily controversial. What could be controversial are the decisions made in order for us to get there. Engineering resources are currently very limited, and FreeBSD was primarily designed as a Server OS. You can take a look at this wired article from 2013, where Jordan Hubbard speaks partly about some problems that arose while he was at Apple, on how to take "Open Source UNIX", and make it run well for the desktop or within environments that have limited electrical resources (ex: phones). These are concerns that if just focusing on a Server OS, you won't need to worry about. However, desktop support I would say is a requirement for wider adoption. FreeBSD doesn't need to try and "beat" Linux, or any other OS, but if we want better adoption, people need to be able to use FreeBSD as a desktop OS in their day to day lives to do the basics. Simply having easy and good support for web browsing, document writing, listening to music, and coding, will get us very far, and provide a foundation for people to want to stay. I'm one of those folks. The argument of "oh, just fork FreeBSD and add your desktop bits" isn't good enough. Having GhostBSD, helloSystem, and others doing this work is not good enough for FreeBSD itself to actually be adopted. We can still maintain the FreeBSD we have today, and improve its desktop side.

  2. Continue following the UNIX traditions, and a conservative approach to development, but have room for evolution. In a lot of ways, FreeBSD almost has the exact opposite problem that Linux has, which is that FreeBSD is WAY too conservative. I definitely enjoy the stability and the design philosophy, pacing, and development of FreeBSD, we should continue doing that, but we should have a little bit of room to evolve. The "desktop support" portion is a sub section of this since there seems to be a portion of people that only want FreeBSD to essentially just run on servers. I run FreeBSD on the server myself and love it, but I want FreeBSD on the desktop as well (workstation and laptop). We need to have a more clear philosophical shift that includes desktops. But there is another example. I've read a lot of peoples' posts on the FreeBSD forum, around the internet, and some of the mailing lists. There is obviously a diversity of opinion and thought, but sometimes it almost feels like there is an irrational reaction to evolution or change in the FreeBSD community. Even things like whether or not to remove the sendmail program from the base system caused arguments. Let's continue to have spirited debates as long as they are respectful. I do personally believe though that in order for an OS to be complete, which FreeBSD is, the OS needs to come with a preselected, cohesive, list of base applications for fundamental tasks. Things like cron, pf, and sendmail come to mind. They don't need to be those particular picks, but pick 1 of something and standardize on that. Still allow people to switch to their preferred choices after the fact, by putting the alternatives in the ports collection. If you went to a hardware store and you wanted to get a toolbox, you would expect the toolbox to come with a wide assortment of tools that you can use for when the occasion arises. Not everything in the toolbox will be used, but each tool has a specific meaning and reason for being there. You'll be happy when the time to use it comes.


With all of that said, since the main reason I switched to laptops a few years ago as a "desktop replacement" was for the mobility, and to save space at home, and also realizing that everything I'm doing on my machine is indeed desktop work, I decided that the best thing for me to do to have a relatively well supported, powerful, FreeBSD system, is to switch back to a desktop. I'm going to be continuing to compile stable/X, main, and build ports (poudriere/pkg), so I'll want the machine to have a lot of cores/threads. I'll still want a FreeBSD laptop for if I want to be on the couch, travel, or go to a friend/family's house, but the laptop is essentially a glorified iPad. Since the framework laptop's IO is crippled on FreeBSD, I've done the following:

  1. Built a new desktop that has FreeBSD support in mind from the get-go as my primary home machine.
  2. Returned to my Thinkpad X1C7 for when I need FreeBSD on a laptop (I also still have a Thinkpad X270 in my possession).

So far this has been working well and I'm looking forward to posting more updates in 2023 regarding this. For now, these are the specs that I went with for the main box:

Let's see what happens :D. I'll be refining and cleaning up this post as I have time.