I use FreeBSD on my servers and for research for the following reasons:
1. The documentation is excellent. The man pages are well-written and have useful examples, and the FreeBSD Handbook and Developer Guide are great resources.
2. First-class support for features such as ZFS and Dtrace.
3. This is a preference, but I like the BSDs' conservatism when it comes to adding new features. It seems that new features in the BSDs seem to be more in line with the Unix philosophy (similar to the Solaris and Joyent communities' attitudes), while the Linux community seems to be more willing to add features that may solve problems, but not necessarily in the way that some diehard Unix users would (e.g., PulseAudio, systemd).
With that being said, I use Linux for work and in the WSL environment on my Microsoft Surface tablet. Linux is also a great operating system, and sometimes I need to use Linux instead of FreeBSD for hardware and software support reasons (for example, I use CUDA for my job, which needs Linux).
Why do you use Linux instead of BSD? It's the same question.
Some potential reasons for using FreeBSD:
It's the same three firewalls forever, not a progression of different firewalls.
Old knowledge still works, for example, netstat is still the way to list socket connections and ifconfig is still the way to configure interfaces. I did some work with FreeBSD in 1999, and then nothing until 2004, and all the knowledge transferred, then in 2011 I changed jobs and skipped ahead several versions, and again all the knowledge transferred. But I kind of stopped using Linux heavily in 2013, and when I had to work on it at work in 2016, all the tools had changed, so I had to relearn (or just avoid the Linux part of my job, which I had the luxury of doing).
Official kernel support for ZFS.
Receive side scaling support is nice, if you need it; although I guess not a lot of people do.
Different positions on philisophical arguments like an integrated source repository with the kernel and the base userland software, or init systems.
The "old knowledge" thing is a huge one - I know there are reasons why Linux keeps changing which firewall manager you're supposed to use and now we do ip addr show instead of ifconfig eth0 but it is annoying to keep up.
I know Linus has a "don't break userland" theory which causes some of the above, but it breaks MY userland memory when I have to learn new tools.
Of course if you stay with Ubuntu you'll find fifty thousand posts on whatever question you have.
This is where the *BSD trees including the kernel and the distribution also helps - they can keep the “user interface” the same while still updating everything.
Linux seems to have to create a new way of doing something because there’s no guarantee they can get the distributions to update the tooling.
I have no idea what it uses as a kernel interface nowadays. Did they change the userspace tool again? This is another reason why I like FreeBSD. The tools and syntax barely changed between ipf and pf and the latter was an improvement. I even use as a gateway instead of an EdgeRouter which I find a nuisance to set firewall rules onto.
Yeah, I'm talking about ipchains -> iptables -> ntfables, not necessarily the various firewall management toolchains on top of those (shore wall, ufw, etc).
Because Linux is the dominant OS on servers (so my dev environment can match the prod environment,) has way more tutorials,and documentation and also has way better hardware support.
I'll agree on the rest, but more docs != better docs; BSDs tend to ship complete manpages without needing to wade through a hundred blogposts (half of which are out of date or slightly wrong).
I’m not really talking about Man pages. Yeah this is the argument the BSD fans like to use but those dozens of blog posts for every Linux question makes it a much nicer experience for new users to get what they want working quickly.
It's not just man pages. I can't speak for OpenBSD and NetBSD since I'm unfamiliar with those systems, but for FreeBSD there is the excellent FreeBSD Handbook (https://docs.freebsd.org/en/books/handbook/), which is great for learning how to set up and administer a FreeBSD system.
If your a new users you should start understanding your system, and don't follow potentially wrong or old tutorials, that's a big problem with the Linux-Information-overflow.
Thae's a nice ideal, but if you need to get something working, nothing beats searching for the error message.
The original package maintainers could write instructional materials that start from the errors, but I suspect that's too hard. Without specific training, it'll always be easier for third parties to provide ad hoc than first parties to produce as part of release.
Agree with all except the package management part. I switched to Debian after 15 years using FreeBSD simply due to how much better apt is. I don't have much time so unattended-upgrades is a live saver for me. I do miss FreeBSD though, it is really well designed and thought out but it is more suited to people who are happy to maintain the packages regularly especially when there are major upgrades. A recent example is the change in the default version for Python which needed some manual intervention to sort out the packages. Somethjng that honestly apt does much better.
I tried it circa 2012 (on a macbook, which was clearly a bad choice, but work told me I would love a mac and I didn't so might as well try other bad things). It was kind of a mess, I recall having trouble with basic networking utilities because they tried to provide GNU tools, but they didn't really work and you'd need to get the FreeBSD tools anyway, which was tricky because those weren't packaged.
I agree, apt is a path well traveled and python2 -> python3 migration had some opportunities for improvement. On the other hand I can custom build nginx with a TUI and have package registered as an actual package instead of just being dumped into /usr/bin & /etc/ like with a manual build on Linux. That feature alone makes me believe FreeBSD packages are a tiny bit better as I use it all the time.
You can build Debian packages from source with custom options to get a resulting .deb to install. I will fully admit the process tends to be a bit easier when dealing with BSD ports though.
As a FreeBSD user, the pkg/ports system is the biggest frustration I have. I run -current and update every few weeks (using zfs boot envs and beinstall and pkg upgrade). Every few months, there is some breaking change. Something suddenly wants to uninstall KDE, or cannot find a path forward, etc. I ran ubuntu for years and updated as- or more-frequently and never encountered these problems. Even updating from LTS to LTS was smoother.
I think part of the difference is that ubuntu is a fixed release, while FreeBSD is a rolling release. I wish there was a fixed release of FreeBSD. The best I've been able to do is using -stable quarterly pkgs on FreeBSD-current. This way, I only get security updates except for 4 times a year..
Absolutely agreeing with you, i was thinking about that too. Maybe something like OpenQA and much much more testing can solve it. It's really a bit of a pain, the System is stable like a rock, but that brings nothing if the ports/pkg ecosystem gets neglected (by the whole project not the porters....please don't get me wrong)
I have lost access to my old account, but this comment has so much FUD (and seems to describe the state of Linux as it was about ten years ago) that I had to make a new one to respond.
>- package management (pkg & ports)
It's a matter of taste, I much prefer the power of dnf (the rewritten and modernized yum with full backwards compatibility) with its support for transactions (and transaction rollback, like reverting the state of packages as they were at a particular point in time) and many similar features.
>- file system (native ZFS)
Ubuntu has ZFS built in. You just have to install userland tools (run a single command to add a half-megabyte package and wait a few seconds).
- documentation (handbook & examples in most man pages)
Back in the day it was way easier for me (as a *nix newbie) to find the answer to any of my questions for my Linux systems. I am not a native English speaker and I couldn't read English documentation at all. The various Linux docs, blog posts and community support absolutely dwarfed anything that was available for FreeBSD.
- event notification interface (kqueue vs broken by design epoll & inotify)
Similarly, it's a matter of taste. The GPL family is a clear win for me.
- quality control (no shellshock, no dataloss on fsync)
The recent WireGuard fiasco proved that one wrong. Most code that's going into your system gets /absolutely/ no review besides its original developer. IIRC I heard that from Allan Jude (I think you should know of him) in one of the recent episodes of 2.5admins.com. He was obviously very uncomfortable describing the QA situation throughout the entire discussion.
WireGuard did not make it into a release now did it? Code was indeed crap and they pulled it at the last minute. Lots of users were disappointed including me but then a better version was released as a package and I'm a happy camper.
> - scaling (there is no cliff when resources get saturated just a bit of a "back pressure")
If you haven't found the cliffs, you're just not scaling hard enough. Of course, they are hard to find them in 'normal' server patterns, but if you do unconvential things, the cliffs may be closer. I retired, but my last project hit a bottleneck with FreeBSD 12.0 on outgoing tcp connection rate that's much lower than any kernel bottleneck on incomming connection. I don't know the kernel bottleneck on incomming connections because I never hit it; maybe I've hit configured FD limits, but other than that, I've only been application limited other than ocassionally running into a bug that reduces capacity.
Are you familiar with "vmstat -z"? It will show you any kernel limit that was hit under the "FAIL" column. When you know what is happening/failing its much easier to tune and scale. dtrace is also invaluable for this.
No I wasn't, that's quite nice, thanks. At work, we had tools to look at selected vm stats, but a fuller pictures is nice, and I don't have access to the tools I did anyway.
The fail column of course only applies to explicit limits; not things like doing task X requires lock Y, so if you're doing X a lot on a 56-thread machine, you can only do it so much before lock contention grinds you to a halt. (OTOH, top usually shows what lock you're waiting on, so it's pretty easy to track from there, and I know there are better lock debugging tools, I've just never needed them because either the lock is blindingly obvious and I can work on it, or it's kind of subtle and the other fixer knows how to use the tools for subtle problems :)
Debatable... ZFS is good for many use cases and is a hot broken mess for many others
>- instrumentation (systat & dtrace)
Debatable
>- documentation (handbook & examples in most man pages)
Debatable... I have not fund this to be true in 15 years at least.
>- event notification interface (kqueue vs broken by design epoll & inotify)
Debatable
>- license (BSD, no GPLv3 at all)
Debatable
The GPL is why Linux is miles ahead of *BSD in mindshare.
>- stability (POLA)
Debatable... Maybe 20 years ago FreeBSD was more stable but I had more stability problems with FreeBSD in the last 15 years than any Linux distro I ever used.
>- quality control (no shellshock, no dataloss on fsync)
Again debatable.
>- network performance (200gbps TLS encrypted traffic on a single socket at Netflix, millions of open connections per server at WhatsApp)
LOL debatable again! Youtube, Facebook, Amazon Video, Hulu, most stock trading exchanges. FreeBSD used to be the goto for web servers and services now its nearly dead in that space with market share in the single digits.
>- scaling (there is no cliff when resources get saturated just a bit of a "back pressure")
Benchmarks have shown Linux outperfroming any of the BSD's in scaling since 2003 at least. And the Super Computer and server market proves FreeBSD can't scale.
>Benchmarks have shown Linux outperfroming any of the BSD's in scaling since 2003 at least. And the Super Computer and server market proves FreeBSD can't scale.
I got into BSD around the late 1990s. At the time, Linux distros like the famous Red Hat 5 series, SUSE and Caldera were touting the ease of install with graphical GUIs and X windows environments. I tried them all but found that I wasn't learning how to actually use the terminal commands or understand the startup scripts or filesystem very well. I then tried the BSDs and finally felt like I was beginning to understand how everything fit together and appreciated the whole system architecture better.
Man pages were detailed and precise. Ports and packages were a breeze to install. For me, it made all the difference. I settled on OpenBSD for the security emphasis and my first project was to install a proper firewall for my office. It was a joy to setup. Config files were simple and clear. The firewall itself was incredibly powerful (since superseded by the even better PF https://www.openbsd.org/faq/pf/).
I haven't looked back ever since. Whenever I have to work in a Linux environment, I shudder at the number of processes running, the confusing filesystem decisions of each distro, the poor Man pages and the behemoth that is systemd. I really wish BSDs got more attention and support from developers and users. They really are fantastic operating systems, each with their own particular specialisations (NetBSD - portability, OpenBSD - security, FreeBSD - general purpose, DragonflyBSD - clustering, SMP).
I don't entirely agree. The SYSV vs BSD thing was constant before either (Free,Net,Open)BSD and Linux came into a rivalry. I was there, using both across the timescale (I'd been doing sysadmin and development work on V7, Unix 32V, BSD4.1->4.2 (thats sockets) and then Ultrix/Solaris &c)
SYSV had streams/STREAMS when BSD had sockets. Arguably streams is a superior model.
NFS came to the fore in BSD. SYSV had RFS. It was a different model of network filestore.
MGR -> v8 ->Plan9 was there too. There has always been room for more than one viewpoint of what a UNIX conforming system is.
The rise of Linux has a lot to do with licence terms (for some reason the BSD 4 clause hold harmless appealed more to the embedded market) and the natural tendency of some driver vendors to write for Linux. Google deciding to deploy linux at scale inside the borg, and as Android was recognition of reality.
Van Jacobsen, who did a lot of work on TCP tuning and congestion control in the BSD kernel, wound up in Google, and stopped developing for BSD. So, BBR (for instance) came to BSD late and only because Netflix sponsored it. A bunch of the GPU driving space, WiFi card blobs, they're in Linux kernel before BSD. Docker hasn't been ported to BSD notwithstanding the possibly superior models in Jails and Bhyve, the supremacy of Dockerfile has to be understood as "mindshare"
TL;DR BSD lost a lot of "mindshare" but there was always room for a BSD-vs-SYSV-vs-Plan9 thinking, from before-times.
To be fair, when faced with a need to make a practical decision on whether to use a Linux or a BSD preventing software monoculture is the last thing on my mind. (In fact, my decision would often be influenced by wanting to keep the infrastructure as uniform as possible.)
The way I see it, there’s a bigger difference between some Linux distributions than between, say, Slackware Linux and a BSD, so one could also ask why someone would use Arch instead of Ubuntu (or the other way around).
While at it are there similar services for public testing? I briefly remember some years ago IBM allowing shell access to one of their then new POWER systems.
I like the BSDs because I have a hope of understanding them. They're simple and well-documented, and make design choices I like. (For example, on a BSD I can use 'man -Otag=l ls' to go straight to the documentation for 'ls -l'. Try doing that reliably on Linux.)
Yes it's a massive benefit (for me), but i don't tell you which one, because would you believe me that linux is better for server and development then windows without testing it out for yourself?
