Why or when would I want to use BSD over Linux? Is it more performant? Does it use less resources? What real differences are there?
I've tried to find out myself, but it mostly seems to come down to philosophical reasoning and personal preference.
1) You get an operating system. One of the problems with Linux is the number of distros. If you want to know how to do something you've got to google around and look for a guide. In the BSDs it is just reading the man pages and figuring things out from there.
2) I've found with OpenBSD things either are documented and work or they don't work at all. The system is easy to understand whereas with Linux I tend to get overwhelmed with one distro doing it one way and another distro doing it another way.
3) Things are a bit difficult to setup (lots of reading docs) but it doesn't change once you've got it running which is my major gripe with Windows since Windows 7.
When you're tired of churn. Network interfaces are still configured with ifconfig (including all of wireless interfaces). When you want to see network statistics, and open connections, that's still netstat.
It's a lot of effort to run proper head to head tests, so I don't know for sure if FreeBSD is faster than Linux, but I've rarely run into bottlenecks that I can blame on the kernel as opposed to hardware limitations (or, more frequently, application bottlenecks).
Edit to add some bottlenecks I recall seeing that are related to the kernel.
1) on FreeBSD, loopback is a lot more real than on Linux; packets traverse the full tcp stack. This can cause issues if you're running TLS in a separate process and you want millions of user connections to the host. Tuning helped, but ultimately, using UNIX sockets, or running TLS in the real server process avoided the bottleneck.
2) I ran into some disk i/o bottleneck upgrading from FreeBSD 10 to 11 that I couldn't figure out. Because our company was acquired and the affected systems were being moved to a totally different environment, I didn't have the time to debug. Basic parameters were write heavy pattern on UFS with many SSDs (6 or 12), latency got really bad.
3) The tcp data structures are not setup well for outgoing connections. You can have millions of inbound connections no problem and accepting connections is pretty much only rate limited to what your application can handle, most likely limited by a crypto handshake in modern protocols, or memory used. But outgoing connections are going to bottleneck on locking/touching the global tables, even if you're using RSS tables. Unfortunately, I don't remember the numbers, but like tens of thousands of connections per second. Getting RSS alignment helped (but it's tricky, the client program has ro compute the rss hash and bind before connect), and putting in a modern hash function and using more of the connection parameters in the hash function helped, and changing how connections are checked helped a lot, but it could use a good refactor by a core networking person. That's not to say they've done poorly, the last time this had major changes was about 20 years ago, and everything works pretty well, until you hit connection rates that would have been inconceivable at the time. This was for an HAProxy service.
I don't mean to offend, but TBH there isn't anything terribly compelling there. I don't care either way for SysV/systemD, but distros still using SysV exist if it matters to you. CentOS et al are rock solid and work well under load, and have performant networking layers. FirewallD and UFW are also good firewall systems.
I'm not trying to convince anyone, but FreeBSD has always worked great for me and has been a sane OS in every respect.
As a BSD user, it wouldn't matter to xem at all. The BSDs never used the AT&T System 5 mechanism, nor its van Smoorenburg clone. It's you the Linux user that it matters to, and even then not nearly as much as you are implying it might matter to someone else. It pretty much hasn't mattered greatly to anyone apart from Linux, and before it Minix, users for 30 years.
There is a fallacy in discussions of systemd, which was called out by the Uselessd Guy years ago. It is the fallacy that only systemd and van Smoorenburg init/rc exist. This is not the case. It wasn't the case for Ubuntu and Fedora. It is especially not so when a BSD is the topic. The BSDs have a quite different family heritage in this area.
But then, AT&T Unix itself actually has a different history to what people who bandy about the erroneous "SysV/systemd" dichotomy think. The init/rc that Miquel van Smoorenburg cloned had actually already been superseded years before Linux was even invented. It wasn't used in the BSD side of the universe at all. But it was only a major mechanism in the AT&T side of the universe for just over half a decade, in the 1980s.
The BSD side of the universe could turn around and observe that they were right all along; were it not for the fact that the other side of the universe largely thought better of the mechanism as well, coming up with the SAF in 1988 and the likes of the SRC in 1991. (-: Of course, the BSD world wasn't just standing still all of those years, moreover, and had things like /etc/rc.local.d/ and Mewburn rc.
* https://web.archive.org/web/20190306213420/http://uselessd.d...
* http://jdebp.uk./FGA/rc.local-is-history.html
* http://jdebp.uk./FGA/inittab-getty-is-history.html
* http://jdebp.uk./FGA/run-levels-are-history.html
> As a BSD user, it wouldn't matter to xem at all
I can only assume "xem" is some kind of "BSD thing"?
> It's you the Linux user that it matters to... AT&T Unix itself actually has a different history to what people who bandy about the erroneous "SysV/systemd" dichotomy think...
I did actually say I didn't care much either way, in part because I really didn't want to derail this thread into a sysv/systemd flamewar - I only wanted to know why I might use BSD over Linux.