6 ms·

I'm a veteran of Windows and Linux, but I've never used a *BSD (unless you tenuously count MacOS). Why or when would I want to use BSD over Linux? Is it more p

I'm a veteran of Windows and Linux, but I've never used a *BSD (unless you tenuously count MacOS). 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.

uncle_j 7y ago
I am a OpenBSD / Windows user (all the VMs server I am running are OpenBSD). I haven't used FreeBSD a whole lot. 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.
- GordonS 7y ago
  Hah, that's a good point! I mainly work with CentOS and Ubuntu, but also sometimes Debian, RHEL and SLES. Not only do firewalls, init systems etc differ between distros, they also vary between versions - I often have to consult personal cheatsheets or Google.
petre 7y ago
It just works, you don't have to deal with systemd, things are kept simple, it's rock solid, works quite well under load, the networking layer is performant, PF is a well designed firewall, the base system is very well integrated, the ports tree is very extensive, only Debian offers more packages I think. PostgresSQL also used to run a bit better on FreeBSD. Nowadays thanks to pkg installing and upgrading packages is easy. I have 11.3R instalations that were incrementaly upgraded from 8.0R. It fells like the OS is designed by greybeards that don't care too much about the latest and greatest hype, hence this article.
- GordonS 7y ago
  > It just works, you don't have to deal with systemd, things are kept simple, it's rock solid, works quite well under load, the networking layer is performant, PF is a well designed firewall 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.
  - petre 7y ago
    If it works for you fine, for me systemd has been an annoyance at times, as in not predictable. Plus the mess of badly designed tools it brings with it (eg. systemd-resolved, journald). Never been a fan of SysV either. We also run openSuSE, Ubuntu and Debian. FirewallD and UFW are just layers above a not so greatly designed firewall setup tool (iptables). PF is very well integrated and can be easily used directly without any higher level layers. You can even add ALTQ queuing rules in its config file. I'm not trying to convince anyone, but FreeBSD has always worked great for me and has been a sane OS in every respect.
  - JdeBP 7y ago
    > distros still using SysV exist if it matters to you 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.darknedgy.net/ProSystemdAntiSystemd/ https://web.archive.org/web/20190306213420/http://uselessd.d... * http://jdebp.uk./FGA/rc.local-is-history.html http://jdebp.uk./FGA/rc.local-is-history.html * http://jdebp.uk./FGA/inittab-getty-is-history.html http://jdebp.uk./FGA/inittab-getty-is-history.html * http://jdebp.uk./FGA/run-levels-are-history.html http://jdebp.uk./FGA/run-levels-are-history.html * http://jdebp.uk./FGA/unix-service-access-facility.html http://jdebp.uk./FGA/unix-service-access-facility.html * https://blog.darknedgy.net/technology/2015/09/05/0/ https://blog.darknedgy.net/technology/2015/09/05/0/
toast0 7y ago
> Why or when would I want to use BSD over Linux? 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.

uncle_j 7y ago

I am a OpenBSD / Windows user (all the VMs server I am running are OpenBSD). I haven't used FreeBSD a whole lot. 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.

GordonS 7y ago
Hah, that's a good point! I mainly work with CentOS and Ubuntu, but also sometimes Debian, RHEL and SLES. Not only do firewalls, init systems etc differ between distros, they also vary between versions - I often have to consult personal cheatsheets or Google.

petre 7y ago

It just works, you don't have to deal with systemd, things are kept simple, it's rock solid, works quite well under load, the networking layer is performant, PF is a well designed firewall, the base system is very well integrated, the ports tree is very extensive, only Debian offers more packages I think. PostgresSQL also used to run a bit better on FreeBSD. Nowadays thanks to pkg installing and upgrading packages is easy. I have 11.3R instalations that were incrementaly upgraded from 8.0R. It fells like the OS is designed by greybeards that don't care too much about the latest and greatest hype, hence this article.

GordonS 7y ago
> It just works, you don't have to deal with systemd, things are kept simple, it's rock solid, works quite well under load, the networking layer is performant, PF is a well designed firewall 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.
- petre 7y ago
  If it works for you fine, for me systemd has been an annoyance at times, as in not predictable. Plus the mess of badly designed tools it brings with it (eg. systemd-resolved, journald). Never been a fan of SysV either. We also run openSuSE, Ubuntu and Debian. FirewallD and UFW are just layers above a not so greatly designed firewall setup tool (iptables). PF is very well integrated and can be easily used directly without any higher level layers. You can even add ALTQ queuing rules in its config file. I'm not trying to convince anyone, but FreeBSD has always worked great for me and has been a sane OS in every respect.
- JdeBP 7y ago
  > distros still using SysV exist if it matters to you 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.darknedgy.net/ProSystemdAntiSystemd/ https://web.archive.org/web/20190306213420/http://uselessd.d... * http://jdebp.uk./FGA/rc.local-is-history.html http://jdebp.uk./FGA/rc.local-is-history.html * http://jdebp.uk./FGA/inittab-getty-is-history.html http://jdebp.uk./FGA/inittab-getty-is-history.html * http://jdebp.uk./FGA/run-levels-are-history.html http://jdebp.uk./FGA/run-levels-are-history.html * http://jdebp.uk./FGA/unix-service-access-facility.html http://jdebp.uk./FGA/unix-service-access-facility.html * https://blog.darknedgy.net/technology/2015/09/05/0/ https://blog.darknedgy.net/technology/2015/09/05/0/

toast0 7y ago

> Why or when would I want to use BSD over Linux? 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.