8 ms·

I've always preferred FreeBSD over Linux, especially for servers, but the lack of hardware support has always been a hurdle. And Linux has, overtime managed to

I've always preferred FreeBSD over Linux, especially for servers, but the lack of hardware support has always been a hurdle. And Linux has, overtime managed to reach a kind of feature parity with it and even outperform it as many of these tests show.

thijsvandien 6y ago
The BSD's best feature that Linux won't rival is how boring they are (in a good way).
- Koshkin 6y ago
  Slackware is comparably boring.
  - tramtrist 6y ago
    Next stable version is right around the corner. Latest plasma, xfce, and kernel should be in all while staying true to those 'boring' principals
- elric 6y ago
  Linux's decentralization is both its major strength and its major weakness. The differences between distros can be so large that you might as well be talking about two entirely different operating system. There is little consistency in design of tools. Many tools used to follow the UNIX Philosophy ("do one thing well"), but that no longer seems to be the case. We (as in Linux users) used to make fun of Windows for how stupid everything was. You need a GUI for configuration because many options are hidden away in some kind of cryptic registry, deploying services is a PITA etc. Now we have somehow (d)evolved to that same mess. For instance, SystemD and SELinux are such a pain to work with (each for different reasons) that it feels like I have to fight my OS. Wanting an OS that works for me, instead of against me, was one of the major reasons why I switched from Windows to BSD and then Linux back in the 90s. There's definitely something to be said for *BSD's boring, predictable simplicity. But perhaps there's some kind of force that automatically drives operating systems to bewildering compelxity as their user base grows?
  - lordgroff 6y ago
    I don't understand the hate systemd gets honestly, except around some very corner concerns. I remember the old init systems and don't want to go back. Piles of shell scripts with absolutely no standardization, each doing its own thing with zero consistency. Systemd has massively cleaned up that mess and yes it's more complex, but also more sane. I don't find the FreeBSD init an improvement. Nobody is forcing SELinux on you, you can turn it off and that's that. If you're on a Red Hat based system most of policy is there out of the box, providing you with pretty nice additional protection without too much tinkering.
    - throw0101a 6y ago
      > I don't understand the hate systemd gets honestly, except around some very corner concerns. I remember the old init systems and don't want to go back. systemd-as-init is/was not the problem. systemd-as-kitchen-sink is where people started getting annoyed. It needs journald (which can't ship logs off-host like rsyslog, so you needed to run rsyslog anyway), it pulled in udevd, it's doing DNS, it's doing time syncing, it's doing DHCP/IP and VXLAN(!), it has a boot manager (formerly gummiboot), it's tracking user logins, it's ….
      - MisterTea 6y ago
        > it's …. Too. Damn. Big.
        Koshkin 6y ago
        Well, it is the system (daemon) after all. (Something that you add on top of a kernel to make an OS proper.)
        throw0101a 6y ago
        If I wanted giant, tightly-coupled binary blobs for system services I'd just run Windows.
        6y ago
- sandworm101 6y ago
  Boring is a feature. For an OS it is THE feature. An OS is a necessary evil. It doesn't actually complete any user tasks, much like a car's engine doesn't do the actual driving. An OS should take the low-level tasks assigned to it, complete them without issue, not do anything unexpected, and generally stay out of the user's way. A car engine's job is to start and stop when asked, not to organize the driver's inbox. BSD has remained true to this while Linux has moved away in recent years. On the flip side it windows. That OS doesn't hide in the background, rather it screams for attention 24/7, inserting itself in every little task even when specifically told to back off.
brobdingnagians 6y ago
There are some cases where squeezing every ounce of performance out of the hardware matters, but for most use cases there is a reasonable "good enough"; and these results show that BSD and Linux are comparable. I think the killer feature that the BSDs have, which Linux can't match, is how well designed, integrated, predictable, and simple they are. That is why I run more BSD servers than Linux servers. I do run Linux servers for some cases, and they work well for those cases, but I much prefer working with BSD.
- webmobdev 6y ago
  > how well designed, integrated, predictable, and simple they are. Yeah, and the good documentation. Wish more open source projects had these.
- lordgroff 6y ago
  I like the BSD simplicity, but it's not just hardware, it's software. I want to spin up an X stack in docker? Can't do that, docker doesn't work. There's jails but without any image repositories I'm trading a lot of convenience for simplicity. There's also software like dotnetcore which will just not build. The situation in the desktop is even more problematic. I wish it wasn't so, I like the separation of concerns quite a bit with FreeBSD but it's not something that unfortunately fits my use cases.
  - infofarmer 6y ago
    Some people run BSD to avoid needing containers. There are different approaches to keeping the entropy under control.
  - vermaden 6y ago
    Try BastilleBSD - https://bastillebsd.org/ https://bastillebsd.org/ - which uses FreeBSD Jails and offers templates/images for many use cases - https://gitlab.com/bastillebsd-templates https://gitlab.com/bastillebsd-templates
  - musicale 6y ago
    > docker doesn't work Doesn't work on macos or windows either; macos "docker" uses a linux VM. Personally I prefer jails anyway.
stevenhuang 6y ago
I hear about the elegance of BSD design often but have only worked deeply with Linux. Does anyone have some good LWN-type articles that goes deep into the differences between BSD vs Linux internels (also common user land traits in downstream distros)?
- rwaksmunski 6y ago
  My favorite comparison is epoll vs kqueue. https://idea.popcount.org/2017-02-20-epoll-is-fundamentally-broken-12/ https://idea.popcount.org/2017-02-20-epoll-is-fundamentally-... https://people.freebsd.org/~jlemon/papers/kqueue.pdf https://people.freebsd.org/~jlemon/papers/kqueue.pdf
  - garethrowlands 6y ago
    To be fair to Linux, it has io_uring now.
    - adrian_b 6y ago
      Yes, it seems that we are finally approaching the time when waiting for multiple events and asynchronous I/O will become simple and efficient on Linux. However, this has always been a weak spot for Linux until recently and it took too many iterations of various partial solutions of the problem to reach the current state. This was a case when avoiding the NIH approach and looking carefully at the older Windows or FreeBSD solutions would have resulted in an earlier good solution.
      - rwaksmunski 6y ago
        IIRC the official reason for simply not porting kqueue to Linux 20 years ago was: "it's over engineered". Linux has a ton a brilliant developers working on it, they had to know epoll wasn't all there, the epoll man page says as much. I've always suspected perhaps, maybe, potential patent infringement worries might have something to do with the broken design. If that's the case, fair enough, no one wants litigation.
- deleted 6y ago
GordonS 6y ago
I tried to install Dragonfly BSD in a Hyper-V VM recently - didn't matter what configuration I used, the install wouldn't start due to some kind of hardware issue with the virtual disk. Oh well, I'll stick with Linux.
- blinkingled 6y ago
  Btw, DragonFly runs fine under either of ESXi or Linux/KVM/Virtio. I used it under ESXi with physical disks attached as a backup server with hammer/hammer2 recently. Worked great and it was the only FS that offered effective offline dedup.
- deleted 6y ago
  [deleted]
segfaultbuserr 6y ago
+1. It's also my recent experience of running FreeBSD on AMD Ryzen, several features are missing. And so far this is a list of problems I've encountered. 1. No ECC driver for AMD Ryzen, and no ECC support in memory management. While you don't need any OS support to use ECC, it's much better to have it. * Linux has an ECC kernel driver for AMD CPUs that accurately reports the ECC status, this is extremely helpful given the uncertainty of ECC in consumer-grade hardware. On FreeBSD, it's not possible to tell whether ECC is enabled due to the lack of driver. Also, if ECC is not initialized properly by the firmware, the Linux ECC driver will also detect it and try reenabling ECC and memory scrubbing. On FreeBSD, better to check whether your BIOS is broken. * When an ECC error occurs, a Machine Check Exception is generated by the CPU. On Linux, it will be correctly decoded and recorded. But on FreeBSD, so far there's no decoder, leaving you a mysterious MCA error in dmesg. For example, a correctable DRAM ECC error will be reported as "L3 cache error" (which made many people to falsely believe that Ryzen's ECC was not working on FreeBSD). * On Linux, if an unrecoverable multibit ECC error is detected in userspace memory, the process will be killed by a SIGBUS (my username checks out?). If the error occurs in kernel memory, it triggers a kernel panic. On FreeBSD, as far as I know, none of the features is supported by the kernel, it increases the risk of data corruption, and it's not a Ryzen or MCE-specific problem. Also, Linux also supports memory offlining, which can be used to temporarily remove bad memory pages from the system after an ECC error, which is not found in FreeBSD. Fortunately the ECC-enabled flag is easy to check (I plan to make a contribution to the FreeBSD kernel), and a MCE decoder in userspace should also be easy. But implementing the rest is not trivial, the lack of ECC support in memory management is a problem. It's unfortunately that these features are not supported in a server-grade OS like FreeBSD (I guess FreeBSD runs on "real" servers, which implements all of those ECC features in the management firmware, so "real" FreeBSD users don't really need them...) 2. No USB serial system console and netconsole support. On FreeBSD, although tty login via USB serial is supported (just run a getty on it), it seems that there's no way to redirect all dmesg to a serial port (perhaps someone can correct me), FreeBSD's comconsole requires a real physical serial port, not USB, on the other hand Linux's CONFIG_USB_SERIAL_CONSOLE supports USB natively. On Linux, there's also a kernel-space netconsole that redirects all demsg via UDP/IP, this feature is not found in FreeBSD although there was an attempt in 2012.
- 6y ago
markjdb 6y ago
> as many of these tests show The tests appear to compare ZFS and ext4 and clang and gcc as much as FreeBSD and Linux.

thijsvandien 6y ago

The BSD's best feature that Linux won't rival is how boring they are (in a good way).

Koshkin 6y ago
Slackware is comparably boring.
- tramtrist 6y ago
  Next stable version is right around the corner. Latest plasma, xfce, and kernel should be in all while staying true to those 'boring' principals
elric 6y ago
Linux's decentralization is both its major strength and its major weakness. The differences between distros can be so large that you might as well be talking about two entirely different operating system. There is little consistency in design of tools. Many tools used to follow the UNIX Philosophy ("do one thing well"), but that no longer seems to be the case. We (as in Linux users) used to make fun of Windows for how stupid everything was. You need a GUI for configuration because many options are hidden away in some kind of cryptic registry, deploying services is a PITA etc. Now we have somehow (d)evolved to that same mess. For instance, SystemD and SELinux are such a pain to work with (each for different reasons) that it feels like I have to fight my OS. Wanting an OS that works for me, instead of against me, was one of the major reasons why I switched from Windows to BSD and then Linux back in the 90s. There's definitely something to be said for *BSD's boring, predictable simplicity. But perhaps there's some kind of force that automatically drives operating systems to bewildering compelxity as their user base grows?
- lordgroff 6y ago
  I don't understand the hate systemd gets honestly, except around some very corner concerns. I remember the old init systems and don't want to go back. Piles of shell scripts with absolutely no standardization, each doing its own thing with zero consistency. Systemd has massively cleaned up that mess and yes it's more complex, but also more sane. I don't find the FreeBSD init an improvement. Nobody is forcing SELinux on you, you can turn it off and that's that. If you're on a Red Hat based system most of policy is there out of the box, providing you with pretty nice additional protection without too much tinkering.
  - throw0101a 6y ago
    > I don't understand the hate systemd gets honestly, except around some very corner concerns. I remember the old init systems and don't want to go back. systemd-as-init is/was not the problem. systemd-as-kitchen-sink is where people started getting annoyed. It needs journald (which can't ship logs off-host like rsyslog, so you needed to run rsyslog anyway), it pulled in udevd, it's doing DNS, it's doing time syncing, it's doing DHCP/IP and VXLAN(!), it has a boot manager (formerly gummiboot), it's tracking user logins, it's ….
    - MisterTea 6y ago
      > it's …. Too. Damn. Big.
      - Koshkin 6y ago
        Well, it is the system (daemon) after all. (Something that you add on top of a kernel to make an OS proper.)
        throw0101a 6y ago
        If I wanted giant, tightly-coupled binary blobs for system services I'd just run Windows.
        6y ago
sandworm101 6y ago
Boring is a feature. For an OS it is THE feature. An OS is a necessary evil. It doesn't actually complete any user tasks, much like a car's engine doesn't do the actual driving. An OS should take the low-level tasks assigned to it, complete them without issue, not do anything unexpected, and generally stay out of the user's way. A car engine's job is to start and stop when asked, not to organize the driver's inbox. BSD has remained true to this while Linux has moved away in recent years. On the flip side it windows. That OS doesn't hide in the background, rather it screams for attention 24/7, inserting itself in every little task even when specifically told to back off.

brobdingnagians 6y ago

There are some cases where squeezing every ounce of performance out of the hardware matters, but for most use cases there is a reasonable "good enough"; and these results show that BSD and Linux are comparable. I think the killer feature that the BSDs have, which Linux can't match, is how well designed, integrated, predictable, and simple they are. That is why I run more BSD servers than Linux servers. I do run Linux servers for some cases, and they work well for those cases, but I much prefer working with BSD.

webmobdev 6y ago
> how well designed, integrated, predictable, and simple they are. Yeah, and the good documentation. Wish more open source projects had these.
lordgroff 6y ago
I like the BSD simplicity, but it's not just hardware, it's software. I want to spin up an X stack in docker? Can't do that, docker doesn't work. There's jails but without any image repositories I'm trading a lot of convenience for simplicity. There's also software like dotnetcore which will just not build. The situation in the desktop is even more problematic. I wish it wasn't so, I like the separation of concerns quite a bit with FreeBSD but it's not something that unfortunately fits my use cases.
- infofarmer 6y ago
  Some people run BSD to avoid needing containers. There are different approaches to keeping the entropy under control.
- vermaden 6y ago
  Try BastilleBSD - https://bastillebsd.org/ https://bastillebsd.org/ - which uses FreeBSD Jails and offers templates/images for many use cases - https://gitlab.com/bastillebsd-templates https://gitlab.com/bastillebsd-templates
- musicale 6y ago
  > docker doesn't work Doesn't work on macos or windows either; macos "docker" uses a linux VM. Personally I prefer jails anyway.

stevenhuang 6y ago

I hear about the elegance of BSD design often but have only worked deeply with Linux. Does anyone have some good LWN-type articles that goes deep into the differences between BSD vs Linux internels (also common user land traits in downstream distros)?

rwaksmunski 6y ago
My favorite comparison is epoll vs kqueue. https://idea.popcount.org/2017-02-20-epoll-is-fundamentally-broken-12/ https://idea.popcount.org/2017-02-20-epoll-is-fundamentally-... https://people.freebsd.org/~jlemon/papers/kqueue.pdf https://people.freebsd.org/~jlemon/papers/kqueue.pdf
- garethrowlands 6y ago
  To be fair to Linux, it has io_uring now.
  - adrian_b 6y ago
    Yes, it seems that we are finally approaching the time when waiting for multiple events and asynchronous I/O will become simple and efficient on Linux. However, this has always been a weak spot for Linux until recently and it took too many iterations of various partial solutions of the problem to reach the current state. This was a case when avoiding the NIH approach and looking carefully at the older Windows or FreeBSD solutions would have resulted in an earlier good solution.
    - rwaksmunski 6y ago
      IIRC the official reason for simply not porting kqueue to Linux 20 years ago was: "it's over engineered". Linux has a ton a brilliant developers working on it, they had to know epoll wasn't all there, the epoll man page says as much. I've always suspected perhaps, maybe, potential patent infringement worries might have something to do with the broken design. If that's the case, fair enough, no one wants litigation.
deleted 6y ago

GordonS 6y ago

I tried to install Dragonfly BSD in a Hyper-V VM recently - didn't matter what configuration I used, the install wouldn't start due to some kind of hardware issue with the virtual disk. Oh well, I'll stick with Linux.

blinkingled 6y ago
Btw, DragonFly runs fine under either of ESXi or Linux/KVM/Virtio. I used it under ESXi with physical disks attached as a backup server with hammer/hammer2 recently. Worked great and it was the only FS that offered effective offline dedup.
deleted 6y ago
[deleted]

segfaultbuserr 6y ago

+1. It's also my recent experience of running FreeBSD on AMD Ryzen, several features are missing. And so far this is a list of problems I've encountered. 1. No ECC driver for AMD Ryzen, and no ECC support in memory management. While you don't need any OS support to use ECC, it's much better to have it. * Linux has an ECC kernel driver for AMD CPUs that accurately reports the ECC status, this is extremely helpful given the uncertainty of ECC in consumer-grade hardware. On FreeBSD, it's not possible to tell whether ECC is enabled due to the lack of driver. Also, if ECC is not initialized properly by the firmware, the Linux ECC driver will also detect it and try reenabling ECC and memory scrubbing. On FreeBSD, better to check whether your BIOS is broken. * When an ECC error occurs, a Machine Check Exception is generated by the CPU. On Linux, it will be correctly decoded and recorded. But on FreeBSD, so far there's no decoder, leaving you a mysterious MCA error in dmesg. For example, a correctable DRAM ECC error will be reported as "L3 cache error" (which made many people to falsely believe that Ryzen's ECC was not working on FreeBSD). * On Linux, if an unrecoverable multibit ECC error is detected in userspace memory, the process will be killed by a SIGBUS (my username checks out?). If the error occurs in kernel memory, it triggers a kernel panic. On FreeBSD, as far as I know, none of the features is supported by the kernel, it increases the risk of data corruption, and it's not a Ryzen or MCE-specific problem. Also, Linux also supports memory offlining, which can be used to temporarily remove bad memory pages from the system after an ECC error, which is not found in FreeBSD. Fortunately the ECC-enabled flag is easy to check (I plan to make a contribution to the FreeBSD kernel), and a MCE decoder in userspace should also be easy. But implementing the rest is not trivial, the lack of ECC support in memory management is a problem. It's unfortunately that these features are not supported in a server-grade OS like FreeBSD (I guess FreeBSD runs on "real" servers, which implements all of those ECC features in the management firmware, so "real" FreeBSD users don't really need them...) 2. No USB serial system console and netconsole support. On FreeBSD, although tty login via USB serial is supported (just run a getty on it), it seems that there's no way to redirect all dmesg to a serial port (perhaps someone can correct me), FreeBSD's comconsole requires a real physical serial port, not USB, on the other hand Linux's CONFIG_USB_SERIAL_CONSOLE supports USB natively. On Linux, there's also a kernel-space netconsole that redirects all demsg via UDP/IP, this feature is not found in FreeBSD although there was an attempt in 2012.

6y ago

markjdb 6y ago

> as many of these tests show The tests appear to compare ZFS and ext4 and clang and gcc as much as FreeBSD and Linux.