7 ms·

FreeBSD has superior: - package management (pkg & ports) - file system (native ZFS) - instrumentation (systat & dtrace) - documentation (handbook & examples

FreeBSD has superior: - package management (pkg & ports) - file system (native ZFS) - instrumentation (systat & dtrace) - documentation (handbook & examples in most man pages) - event notification interface (kqueue vs broken by design epoll & inotify) - license (BSD, no GPLv3 at all) - stability (POLA) - quality control (no shellshock, no dataloss on fsync) - network performance (200gbps TLS encrypted traffic on a single socket at Netflix, millions of open connections per server at WhatsApp) - scaling (there is no cliff when resources get saturated just a bit of a "back pressure") It adds up to the point where I see some companies keep their use of FreeBSD secret as a competitive advantage. On the other hand I really like what Alpine Linux is doing.

kiwijamo 5y ago
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.
- drewg123 5y ago
  Whatever happened to debian built around FreeBSD? (debian kFreeBSD?). Did systemd kill it?
  - toast0 5y ago
    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.
- rwaksmunski 5y ago
  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.
  - alyandon 5y ago
    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.
drewg123 5y ago
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..
- yjftsjthsd-h 5y ago
  > 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. Well yeah, you're tracking unstable; you can't compare -current to an LTS.
  - nix23 5y ago
    Quarterly is not LTS too, it's just 'slower'...but yeah one should compare 'latest' to Arch and not to LTS that's for sure.
- nix23 5y ago
  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)
5e92cb50239222b 5y ago
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). >- instrumentation (systat & dtrace) dtrace was ported to Linux long ago. We also have bpftrace: https://lwn.net/Articles/793749/ https://lwn.net/Articles/793749/ - 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) No mention of io_uring? https://lwn.net/Articles/776703/ https://lwn.net/Articles/776703/ - license (BSD, no GPLv3 at all) 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.
- rwaksmunski 5y ago
  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.
zokula 5y ago
>FreeBSD has superior: >- package management (pkg & ports) Debatable >- file system (native ZFS) 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.
- nix23 5y ago
  >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. Really? https://www.phoronix.com/scan.php?page=article&item=corei9-freebsd13-dfly6&num=4 https://www.phoronix.com/scan.php?page=article&item=corei9-f... > DragonFlyBSD 6.0 manages to edge past Ubuntu 21.04 as the fastest of the operating systems tested on this Intel Core i9 workstation
toast0 5y ago
> - 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.
- rwaksmunski 5y ago
  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.
  - toast0 5y ago
    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 :)

kiwijamo 5y ago

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.

drewg123 5y ago
Whatever happened to debian built around FreeBSD? (debian kFreeBSD?). Did systemd kill it?
- toast0 5y ago
  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.
rwaksmunski 5y ago
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.
- alyandon 5y ago
  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.

drewg123 5y ago

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..

yjftsjthsd-h 5y ago
> 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. Well yeah, you're tracking unstable; you can't compare -current to an LTS.
- nix23 5y ago
  Quarterly is not LTS too, it's just 'slower'...but yeah one should compare 'latest' to Arch and not to LTS that's for sure.
nix23 5y ago
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)

5e92cb50239222b 5y ago

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). >- instrumentation (systat & dtrace) dtrace was ported to Linux long ago. We also have bpftrace: https://lwn.net/Articles/793749/ https://lwn.net/Articles/793749/ - 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) No mention of io_uring? https://lwn.net/Articles/776703/ https://lwn.net/Articles/776703/ - license (BSD, no GPLv3 at all) 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.

rwaksmunski 5y ago
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.

zokula 5y ago

>FreeBSD has superior: >- package management (pkg & ports) Debatable >- file system (native ZFS) 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.

nix23 5y ago
>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. Really? https://www.phoronix.com/scan.php?page=article&item=corei9-freebsd13-dfly6&num=4 https://www.phoronix.com/scan.php?page=article&item=corei9-f... > DragonFlyBSD 6.0 manages to edge past Ubuntu 21.04 as the fastest of the operating systems tested on this Intel Core i9 workstation

toast0 5y ago

> - 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.

rwaksmunski 5y ago
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.
- toast0 5y ago
  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 :)