Small review of FreeBSD (I used it for a very short period of time, so I could be off the wall, though).

PREFACE

I've been using linux since the mid-90s. I know how to use the console, I compiled kernels, played with the old xfree86 config files and all that back in the day.

THE GOOD OF FreeBSD:

* Stable. It feels like a Unix out of the 80s. If you know what you're doing, it'll get the job done.

* man pages - Haven't used them much on Linux recently, felt that they were on the level of command --help, but on FreeBSD they felt like reading an authoritative blog post. Clear and concise.

* Cross-update versions - better than Debian. I personally never successfully had a seamless update between major releases, while FreeBSD did.

* No systemd (for now) - Unfortunately, systemd is taking over Linux because the largest block of user-space OSS programmers work for RedHat, which pushes for systemd. IIRC, the reason Debian went with systemd is because their maintainers simply have no resources to commit to remove it from gnome, etc.

However, as systemd grows in scope, FreeBSD will have to either play with it, re-implement it in a normal way (which will let other Linux systems find a way out), or stop being compatible with gtk, gnome, et al.

THE IRRELEVANT:

* BSD license - unless you're modifying and then distributing your modification, it doesn't matter.

* "Fragmantation" - True, "FreeBSD" is less fragmented than "Linux", but "BSD" is more fragmented than "Linux" and "Debian" (or RedHat or Ubuntu or Arch...) is the same not fragmented as FreeBSD. Look at the Distro as the OS rather than the kernel.

And it doesn't matter -

If you're distributing OSS, then release it as POSIX and configure; make; make install, and let the distro figure out packaging.

If you want to make life easier for the distro or releasing closed source software, Linux (on the server) has an order of magnitude more users than FreeBSD (https://en.wikipedia.org/wiki/Usage_share_of_operating_syste... ), and if your program works with Debian, Ubuntu and RedHat/CentOS, you'll probably cover the vast majority of users.

* Ports - Complicated to update, takes a long time (unless you have a fleet of servers), and can't be automated. And pkg is no better than apt.

* ZFS - ZFS is being ported to Linux, and btrfs may one day become stable. Either way, in a few years you'll be able to run the same ZFS on Linux as on FreeBSD.

THE GOOD IN LINUX

* Update - On Debian, you run apt upgrade && apt update. And it updates everything. And if you're on a stable release, updates are only bug-fixes, so (short of bugs/regressions), it can be automated.

FreeBSD, on the other hand, doesn't have enough maintainers to keep a stable ports tree, so every update can break your setup. So every update has to be taken care of manually.

* Security - Yes, I know that "experts" like the FreeBSD kernel better and everything, but the FreeBSD kernel has bugs of its own, so practically the key to secure both is keeping them up to date. And most of the time you're using ports, which isn't really run by FreeBSD and subject to their code review. So as Linux has an easier time updating (see above), it would be more secure.

* Directory structure - Why would you want a "blessed" vi? Why should a distro manager decide that /usr/bin/vi is (say) vim while neovim /usr/local/bin/nvi.

If anything, Linux is a lot more "Unixy" (I do know that FreeBSD is the "traditional" way, but I think that Linux is a lot more Unixy) - Why shouldn't I be able to write my own libc without having to maintain my own kernel? On Linux I can replace glibc with muslc. Why can't I do the same on FreeBSD?

If anything, this is what everyone's complaining about systemd: "It's not modular". Well, neither is the FreeBSD base. (Though in truth, FreeBSD seems much more careful about basic software hygiene than systemd).

* Default software - Maybe I'm unique, but I kind of like bash. I don't see why it shouldn't be my default shell except "Well, if it didn't exist in the 80s, it won't exist now" (It could also be a licensing issue, but as a user I don't really care about that).

Others will scream "ShellShock". Well, yes. Though ShellShock shouldn't be a security issue if you don't rely on userspace software to maintain security.

The OS should assume that software will break, and defend against it. So things like pledge or SELinux are much more effective (and sustainable) than treating userspace bugs as security holes.

Though in truth, I can't see why Apache should ever run bash honestly.