FreeBSD is my favorite OS, not just recently but all the way back to 2003 when Linux didn’t cut it anymore for me. Given that Linux has more device drivers available, it also means more bugs, code duplication and generally speaking bad coding habits.
FreeBSD on the other hand (like the other BSDs), value quality and stability, which isn’t just am empty Hull. It has kqueue(2) which is far superior than epoll. It has ZFS builtin with Solaris guys, whom always worked on ZFS since it’s inception, commit to.
It handles Xen as DomU and Dom0, has it’s own Hypervisor BHyve, and offers failover capabilities like pacemaker or keepalived through carp(4) natively.
It offers a straight up Makefile to build the entire Toolchain and OS, natively offering a nice RAM disk solution named nanoBSD and more extensive 3rd party solution mfsBSD.
Ports are available more than you could build or install, i already added 2 new ports this year (oscam and pixiewps) as well as updated one existing (tvheadend).
It also has a really detailed Handbook, which will get you started in no time. If you come from Linux, you’ll find new appreciation for tools like man, since the content provided from the OS really now is worth reading.
Why we at anycast.io switched completely over
With Linux it has become a gamble between Kernel-Updates and Security Issues arising from pre-packaged Software. On FreeBSD we are able to easily use tools like poudriere to compile 3rd party software with features we want, packaged and signed, ready to be installed.
We now use mfsBSD for most of our physical systems, thus reducing the risk of persistent malware/rootkits, after reboots. This also helps us reduce problems with logging in through sshd, after an OS disk fails, since we do not need an OS Disk anymore. :)
In case you wonder: sure, we persist some host-specific configuration on the machine’s ZFS raidz pool, which then get’s loaded on boot.
This makes upgrade procedures easy, especially in an Environment like ours, where clients bring their own hardware.
If i had only one or three kinds of servers in the Racks, than this would be a lot easier, but i can’t make all our clients buy the same hardware for totally different needs, that wouldn’t be right.
So let’s take Rack B for example, where we have 20 different servers, 20 different ways of how an OS Upgrade could fail. If you had to work with rolling back or restoring from backups, this would be a tedious task. Since we are able to PXE Boot (almost) all of our physical hosts from mfsBSD, we just try to boot the new PXE image and see what happens. If it does work, great! If it doesn’t, we just reboot to the old image.
Why can’t you do that with Linux?
You can, we already did this with AlpineLinux, but it’s tedious to keep track of all the new additions in Linux. AlpineLinux has done a great job in the past, and we will continue to run some of our Xen Dom0s on it (since it integrates with GrSec perfectly), but we will certainly dip into all the benefits FreeBSD has to offer.
Linux Distros seem to be “bleeding edge” compared to FreeBSD. You have all these fancy things like systemd and whatnot, but who wants systems to change rapidly if it’s not needed? Nobody, except IT Hipsters i guess.
I’m happy with using the same rc.d system that has booted FreeBSD for 2 decades (with adjustments of course), but this also means, your stuff is so much more likely to just work with the new version.
That’s what i call stability.
So i’ll be posting a lot more BSD-related things in the future, as i’m looking forward to new challenges with FreeBSD which just make me smirk towards Linux folks. ;)
Franz