This website is designed to provide an overview of each BSD system, making it easier for both newcomers and experienced users to navigate and understand the BSD landscape. I would be honored to have your feedback. Thank you for your time and consideration.
FreeBSD has no cons and this is the right answer. đ
Upvoting for being funny (in a good way). Now, if only someone would write nix/guix for BSD, then I would upvote for truth.
Some people are working on it: https://github.com/NixOS/nixpkgs/tree/master/pkgs/os-specific/bsd
Those are not supported by Hydra yet but it could be with a bit of help.
That is great. Now, my bad, but what I really meant to say was NixOS with BSD kernel and userland. That would be SO killer.
You got what you wish for:
https://github.com/nixos-bsd/nixbsd
Iâm not convinced that starting with Nix is the right approach. For a Nix-like thing on FreeBSD, Iâd want tight integration with jails and heavy use of ZFS (in the same way that podman / containerd use it for image storage, snapshots and clones). Iâd also not want it to be reliant on things like GPLv3 versions of bash.
Yeah, I wonder if instead of symlinks you could use ZFS snapshots. And well BSDs are quite declarative already, almost everything is configured with a file.
Iâm a bit sad that Nix doesnât use the same infrastructure as OCI containers. It would make interoperating with the Nix ecosystem a lot easier.
Docker originally had an overlay model, where each layer was literally a layer in a union or overlay filesystem of some kind. This had two major downsides. First, union filesystems have some O(n) behaviour that can be addressed only with a lot of caching. Second, some later back ends wanted to use snapshotting and, while you can easily emulate snapshots with union filesystems, the converse is not always possible.
Newer OCI stacks use snapshots as their core abstraction for images. Each image is still constructed from layers, but each layer is a delta to the ones below and so the model is that you extract the contents of a layer, then snapshot. Then you extract the next layer, then you snapshot. If your implementation mechanism is an overlay FS, each snapshot is just creating a new read-write directory thatâs overlayed on the now read-only ones below.
This maps very well to ZFS. You extract a container layer, then snapshot the filesystem. Then you extract the next one and snapshot. If two container images depend on the same base layer, you have one snapshot of that base, which you then clone twice. Any block that isnât overwritten is now shared between both clones and the base. If you have ten containers all running from images with the same base layer, you have one copy on disk of the blocks that they all use, one copy in the buffer cache, and so on. The same applies if youâre using VM-based container isolation: you can use block-device snapshots (or virtio-fs with something like ZFS snapshots on the host) to give everyone copy-on-write snapshots of the same filesystem.
Wow. Interesting. Thank you!
Things that are not working yet include git, X and Wayland (according to https://github.com/nixos-bsd/nixbsd/blob/main/TODO.md), but a lot IS working.
I tried it out when I first found it a long while ago already. Not really anything except basic shell was working then, but theyâve been progressing a lot and I see there are people still working on this so maybe some day.
Iâm like you here, also would be really interested to maintain a BSD completely with nix.
For sure. Itâs some effort, but itâs doable. The first step is to get the userland bootstrapped, which I believe is being worked on. Then, the kernel. Then either abstract NixOS services away from systemd or create a separate distribution like not-os or Liminix.
(EDIT: looks like https://github.com/nixos-bsd/nixbsd is a thing!)
There is a Nix port, though Iâve not tried it. I would love to see something Nix-like using FreeBSD as a base though. Especially something that avoided dependencies on GPLv3 components (Nix requires a GPLv3 bash, among other things).
https://vez.mrsk.me/freebsd-defaults.html
Feedback: The landing page could use a table summarizing the key details. EG
To me personally, when deciding what to read more about, the focus is most important, followed by release cycle.
One more change to the landing page to consider: Less emphasis on who created it. Doesnât feel relevant to picking one to start with.
You mean the very small footer?
Ah! Sorry! Clarifying: who created the various BSDs. Sorry for the ambiguity!
On OpenBSD I usually âShutdown the boxâ using:
shutdown -ph now, rather thanhalt -phalt(8) says:
Great start. Have both used FreeBSD and DragonFlyBSD personally.
What frustrated me when arriving to BSD land, is hardware support. I would love for this guide to have a setup goal and to replicate it across the BSDs on a real laptop. Eg.: Install the OS, install NGINX as a service, so it autostarts, install a DesktopEnvironement, Browser and finally access the hello world localhost of NGINX in that browser. This should reveal a lot of BSD specific challenges.
I have always found NYC*BUG dmesg database a good source for working out what hardware works with the *BSDs.
While I like the idea, I would say that the very first question is âwhat BSD should I choose ?â
But maybe your target is more people who have to use a given BSD (probably coming from Linux)
The BSD Peopleâs Front!
Oh I thought we were the Popular Front.
Shouldnât the reduced performance of OpenBSD be mentioned in its list of cons? Or has it caught up with the others (Net or Dragonfly at least)?
I feel as though thereâs something of a surge of interest in the BSDs. Anyone have a sense of why?
Iâve seen three common reasons:
These are all very plausible. Your second point is also supported by how Debian, which is community-led, seems to be on an upswing of popularity. (I assume you didnât mean to include it as a âmajor Linux platformâ which seems wrong, but Iâm biased (am DD)).
Yes, Iâve seen a small uptick in Debian folks recently. When I started using Linux, almost everyone used RedHat. Then everyone realised how bad RPM was and, briefly, most people I knew[1] moved to Debian. Then Canonical came along with Ubuntu and, within a year, all of the desktop Linux users I knew were running Ubuntu. It took a bit longer for people to move on the server, but now weâre in a world where most public Linux CI systems run Ubuntu, Ubuntu is the default for WSL, and most non-Android Limix users seem to be using Ubuntu (unless they buy Red Hat Enterprise Linux).
Non-Ubuntu Linux seems to be almost as niche as BSDs, but growing. Arch and Debian seem to be picking up users unhappy with Canonical and NixOS has surged in popularity recently. Iâve heard from more new Devuan users than new Debian users recently, but that may be a biased sample (as may all of the above).
Moving to a different Linux distro doesnât help if you want to avoid the push to things like systemd though. Neither Red Hat nor Canonical seems good at building consensus, they just ship things and rely on their control of bits of the ecosystem to force other people to deal with them. And, often, Debian ends up just dealing with them because their upstreams are maintained by people who work for IBM or Canonical and they donât have a choice. Linusâ âmy way or the highwayâ management style seems to have spread to a lot of the related ecosystems, but this was never really part of BSD culture, which grew far more out of academic peer-review models (with the associated biases in defining who the peers are).
[1] Including several Red Hat employees, though they seem to run a bunch of things. One friend commented that heâd never met so many FreeBSD users before he joined Red Hat.
I think all BSDs offer different things, so there are different reasons people are interested in them.
I quite like hacking away at NetBSD and I like its philosophy with focus on portability+simplicity. I wrote a bit about it here: https://mccd.space/posts/netbsd-review/.
OpenBSD probably speaks to security people as well as plan9/suckless crowds because of them prioritizing keeping the system as minimal+simple+secure as possible. They also release some cool software like cwm, openssh and doas. It has a bit of a unique aesthetic.
FreeBSD has performance comparable to Linux but also has jails and zfs built in which makes it a competitive choice for servers. Iâm using it right now as my main driver and found it easier to set up than many minimal linux distros.
I think all BSDs attract the crowds that arenât happy with Systemd, think software these days have become too bloated and in general prefer old-school unix. Personally having used Linux for so long, I was curious about other ways to do things, so I started using BSDs.
I donât know, but could it be a reaction to systemd arguably/apparently making linux annoyingly complicated?
I think FreeBSD also needs âComprehensive Documentationâ. I think their manual stands out.
https://docs.freebsd.org/en/books/handbook/basics/
It even has chapters on things like WINE.
Iâd say that FreeBSD is also the most complex in the sense of itâs hard to keep track of things, what works, what needs to come from ports (talking about certain drivers here), use flags for ports, sound can be a mess to configure, and there you also have the option to with use flags change things. And while thatâs really cool and amazing you can easily get loss and get under the wheel if you do a lot of specific things. Itâs super flexible and people frequently use it to create very specific things with it, for example using crochet to make images. However since all of that needs to work together, it can be a hassle at times, when there is less focus.
Or just for comparison: OpenBSD is more built to be used as intended. Youâre expected to not compile your own ports, donât even think about compiling your own kernel. Itâs way more a âyou know what you getâ style system.
In that regard FreeBSD feels a lot more like Linux going for a âflexible set of toolsâ approach. In my experience companies using FreeBSD end up with doing things like building their own ports, creating dedicated images, etc., while OpenBSD users go more for a standard solution. But that is just anecdotal evidence.
I just am not sure how to say the above without sounding like âitâs hardâ, when itâs more âitâs is flexible/has many featuresâ which can be good and bad and I think the comparison with OpenBSD makes this very clear.
I think thatâs still true for bluetooth audio devices, but not normally the case for anything else. I remember spending an hour trying to find the docs for how to configure 5.1 surround sound when I first set up FreeBSD as a media centre 12 years ago, only to try playing a test file and realise that it just worked, with no configuration.
Thatâs even more niche! If youâre building embedded appliances, or custom VM images, thereâs a lot of tooling. Poudriere (which is mostly intended for building package sets - it builds the default ones, but you can use it to build your own set with different defaults or with additional ports from overlays) can build jails and VM / disk images incorporating custom additional components and preinstalled packages, but I wouldnât expect 99% of users to ever touch it.
I meant more the fact that nowadays you can virtually ârewireâ stuff and sometimes the correct (as in what you see in terms of connectors) wiring is off. I donât know if thatâs still a thing. It was a couple of years ago.
You can use Poudriere to build disk images? I didnât know that.
Poudriere as mentioned has been at use at various places. Reasons being for example one wanting to have PostGIS version X compiled for Postgres Version Y as well as sometimes more rapidly updating. Another good reason is that the nginx port in FreeBSD is amazing in that you can easily choose from a lot of patches/modules which can save you from a very complex setup.
And other such things. As mentioned I am talking about using FreeBSD in a professional setup. Since poudriere is trivial to set up, if one such need arises itâs usually in there and then people will use it when they see fit. Since FreeBSD also has really well maintained ports and a great package manager[1] itâs nice to use. And you can either just use a file:// path if you run it on your local machine or something like HTTPS for remote systems and since you can sign stuff one potentially wouldnât even need HTTPS.
These are things I always miss on Linux and while I keep wanting to get into nix itâs either more complicated to do things or I am getting old. But it does look really interesting.
[1] I think basically since it was late to the game, with the pkg_* tools -> pkg switch for more advanced/complex features it kinda ran ahead, a bit like what Linux did with containers, being late to the game when jails and zones still existed, but now they are dominating it for the most part.
Sadly, this exists, but itâs not a FreeBSD problem. FreeBSD uses the port descriptions that the AC97 CODEC (or newer equivalent) advertises via ACPI. Most of the time, this matches the labels that the motherboard vendor put on the ports, but not always, and there are configuration options available for those cases.
There are some more complex cases. Most of these CODECs can make the ports do different things and so you may need to configure if you want something different (for example, your board may default to 5.1 output but also support 4-speaker output and 2-channel line in, with the same three jacks).
I know, itâs not really a FreeBSD problem, itâs an annoyance when using FreeBSD tough.
Last time I saw a similar problem on Windows, the fix was to unplug the wires and plug them into other sockets, while playing a surround-sound test file in a loop to work out what each socket actually did. Is there a better way that other operating systems have of handling these things?
What I am talking about is the âvirtualâ wiring. This is sometimes mislabeled. OSs have databases of these wrong wirings.
I also have another fun story. Sound cards most people use are on the motherboard and I had a case where on a multi boot system that virtual wiring would survive both reboots and hardware resets into the other OS. The fix was to shut it down complexly - so no more power remained I assume - and then restart, which would reset that virtual wiring (I am sure this is the wrong term). This was such a hassle to debug, because there was a strong, yet wrong assumption that one cannot reset more than a full system reboot.
Thatâs what Iâm talking about too, but it doesnât come from the OS. Itâs in ACPI tables. The AC97 CODEC (and the newer replacement whose name I forget) has a pin multiplexer. ACPI tables contain the default routing so that the driver can take a 5.1 audio stream and sent it to the correct six pins. Unfortunately, sometimes the ACPI tables contain nonsense. Or, more often, they contain the thing that v1 of the motherboard used, but v2 replaced the plate on the back that labels them, or replaced the connector with one where the three jacks are the other way up.
There are some âdriversâ on Windows that are just .inf files that tell the hardware to ignore buggy ACPI autodetection and configure things differently. You can do the same on FreeBSD via device hints.
Yup, you can dynamically configure them and theyâre supposed to come up in whatever state is advertised in ACPI, but if you do a softer reset then that configuration may be preserved. I bet someone thought it would be useful to persist the settings in a small low-power RAM bank that isnât reset so that a driver that configured them only needed to do so once.
I mean this coming from the OS:
So yeah I am a bit puzzled as to why there arenât commonly used databases and the device hints end up having to frequently be manually added. Itâs an annoyance.
In general hardware quirks are sometimes synced and I get it you cannot always do that, but for this specific topic it feels odd you manually add it on FreeBSD and with some luck someone already did commit something that will do it for you.
I know, I am dreaming of a perfect world here and in a perfect world we wouldnât even need that. It just feels weird when this happens on some big brand hardware. One would imagine this to be something that is a checkbox before releasing a motherboard. Yet it feels more like people are rolling dice about what theyâll do.
OTOH, given the state of IT this could also be considered minor.
Sorry, it just irks me when there is cases of people/companies not even trying. Having to add overwrites on your device hints to make audio come out the right place on a regular computer makes me shudder.
This particular case is really hard because itâs not the device thatâs wrong, itâs the board, so detecting when you need to apply the fix is hard. Itâs even worse because the most common reason for it being wrong is that they rev one of the physical components (connector, backplane) and donât update anything else. The new and old versions of the board are identical in every way from a software perspective, but the pins are wrong on only the new one. The bug is caused by not changing the ACPI tables. In other cases, the tables are just nonsense but thatâs more common on niche boards (more mainstream ones often get a firmware fix even if they ship with the buggy defaults). FreeBSD does ship a bunch of quirks for devices where they are detectable in software.
I have a laptop with a wireless card that has/had a similarly unnerving issue: if I cold booted into Linux it would work fine. If I booted into Windows it would work fine. If I cold booted into Linux and then rebooted into Windows it would not work, but I could reboot from Windows to Linux ok.
I think itâs fixed now. When I first set up the machine for dual boot it worked fine. Then⌠one side had a driver update that I guess the other side didnât? Or maybe a firmware blob? Not sure, just made a habit of doing a full shutdown before switching to save the hassle.
[Comment removed by author]