> also, mentioning 3 firewalls after being excited about well-designed system that just comes together rather than being glued together from third-party software just sounds weird

I noticed this too. One of the main *BSD benefits people always tout is that it has "one true way" of doing things - yet having 3 different ways to do firewalling is somehow a great thing when we're talking about FreeBSD?

Last time I checked, FreeBSD'd pf is quite older than OpenBSD's and also FreeBSD doc says it has diverged from the OpenBSD's pf.

ipfw would be that one true way on FreeBSD, pf on OpenBSD

>> bhyve

>They don't list anything technically better about bhyve. Why would I use this over xen or kvm?

Isn't it actually worse? There doesn't seem to be AMD support:

>Hosting Linux guests or FreeBSD guests with more than one vCPU requires VMX unrestricted mode support (UG)

Does AMD have UG or does this mean no AMD support for multi-processor guests?

With Meltdown and Spectre, doesn't this mean that VMs on linux AMD systems provide much better performance, and even better performance per dollar?

> does this mean no AMD support for multi-processor guests

I dunno about the details but I've got a Debian VM with 6 vCPUs running on Bhyve, FreeBSD 11.3, on my Threadripper 1920X.

AMD doesn't need unrestricted guest support, it has always had it.

> They haven't listed what's actually technically better about it than in systemd. (not subjectively)

And even to avoid running headlong into this troll pit: Linux distros without systemd exist. It's dishonest to compare FreeBSD to Linux and then only focus on a subset of Linux distros.

> And even to avoid running headlong into this troll pit: Linux distros without systemd exist. It's dishonest to compare FreeBSD to Linux and then only focus on a subset of Linux distros.

Are any of them mature enough to depend on for serious work? I looked at moving back to Linux a few months ago, but all the non-systemd distributions seemed to be small projects and many of them looked to have schismed, collapsed, or both.

Ah, "serious work". That well-known absolute thing that is the same for everyone.

Void is a small project, but absolutely rock solid. It's BSD inspired and systemd free. I like it a lot.

I can also vouch for Void - I've used it on my primary laptop for about 4 years. It's a solid distro, with a great community. Void is very configurable, and it's easy to contribute to the project.

It's also unlike a number of 'systemd free' distros (many of which are essentially "Distro X, except without systemd") because its non-use of systemd is not out of some hate for systemd, but because the developers decided after using systemd (Void adopted systemd for a time really early on) that it conflicted with other goals of the project (like offering a musl libc flavour alongside a glibc flavour).

Here's the thing. I would run: Ubuntu, Debian, Centos or Red Hat on my laptop, desktop and also on any server that I run.

I wouldn't run any small distro in AWS.

Have to agree here. I get a lot of benefits professionally from running Linux personally. I've been a full time desktop linux user over 10 years, and I'm often considered the "linux wizard" because I'm known for SSHing into servers and fixing obscure errors that others have looked at for hours with no success. My secret, is that I've run into most of the common problems (filesystem permission issues, including ACLs, selinux, low memory/OOM, conflicting dependency versions, etc) before and already mostly know how to fix them. The time I did on Arch was particularly helpful here. It was a hard first week or so but I learned more about linux during that two weeks than any other time.

Anyway the reasons I say that: These days I only run distros locally that I would run in production. I get intimately familiar with the intricacies of the distro that way and managing the servers comes natural to me because of that.

Slackware is still here looking at you guys

Slackware is the one Linux I keep coming back to after trying out something else. As always, it just works (and no dependency checking in its package managers is a blessing compared to dealing with some issues in Ubuntu or Debian; for others there's always pkgsrc, by the grace of NetBSD).

I know some developers use Gentoo with OpenRC for their daily work machines.

Devuan is a fork of Debian and it's alive and well.

Alpine and AntiX, I use them in VMs because they are lightweight, so far no issues.

What kind of apps do you run? A variety of languages/platforms?

Some stuff runs great in Alpine. Other stuff is subtlety but catastrophically broken in Alpine (such as database servers/clients and others that depend highly on locale for determining encoding).

Agreed. I thought Alpine was superb until I ran into an issue mounting NFS shares that seem to be mountable just fine on every other Linux machine I've got lying around. No idea what's wrong with Alpine's NFS.

> What kind of apps do you run? A variety of languages/platforms?

Mainly Python, some issues with Musl, but nothing too bad. Anyway, these days I tend to mainly use AntiX.

Gentoo, maybe?

I chose systemd since BSD's init has some points over the classic init used in linux previously. But any of the modern choices which actually manage processes (upstart, systemd, whatever you prefer) score a few technical points. Definitely didn't intend to single out systemd as better in this case.

None of those are beyond hobby level, though.

> According to the title, this is about choosing FreeBSD over Linux, not over Unix.

"Unix" hasn't referred to a specific operating system since the 1980s. FreeBSD and Linux are both Unix OSes: different flavors of it.

That is my point though. Not every Unix system has a package manager. But almost every Linux distribution does.

That's even one of they key attributes that makes differences between distributions: the package manager. Other major ones include the init system, and whether the distro is rolling release or not.

Well, if you want to be precise … Linux is a kernel.

And the OS is called GNU/Linux.

/me ducks

Linux isn’t really a UNIX, though.

Isn't Linux an anagram (no not an anagram but I can't come up with the right word) for Linux Is Not UNix?

https://acronyms.thefreedictionary.com/LINUX

You might be thinking of GNU, which is a recursive acronym that stands for "GNU's Not Unix".

As far as I understand it we got the name Linux because Linus Torvalds was quite bad at naming things. :)

https://en.wikipedia.org/wiki/Linux#Naming

No, that’s GNU with the “not UNIX” recursive acronym. Linux was named by the guy who first hosted Linus’ OS and was an amalgamation of “Linus” and “UNIX” (“nix” was a popular suffix for platforms of that type back in those days so “Linux” was a play on the authors name in the style of that naming convention).

If I recall correctly, Linus originally wanted his OS to be called “Freenix” because he thought naming it after himself was a little vein.

It's a recursive acronym.

Backronym?

For all intensive purposes, it is.

I think the expression might be "for all intents and purposes".

I hole-hardedly agree, but allow me to play doubles advocate here for a moment...

goddamnit, well played :)

Intents and purposes

really?

> That means the normal way to install is "<package_manager> install <package_name>".

This excludes a lot of non-free software, which is included in ports.

> Ok. Linux has iptables and now nftables/bpfilter. It's also got queuing, stateless and stateful features, protocol tracking, etc. CARP can be done in userland, or via other solutions like linux-ha/stonith. What are the reasons to choose FreeBSD here?

Documentation, in my experience.

> They haven't listed what's actually technically better about it than in systemd. (not subjectively)

From experience, documentation and bugs (mostly due to age, but still absolutely relevant). I have about a billion questions about why systemd is built the way it is but I suppose that's a matter of taste and who paid to build it.

> Jails as described in the article, have the same features as lxc.

Documentation as always with the linux/bsd comparison. In addition, LXC—in particular cgroups—is still quite young and unproven. The major benefit here is the docker interface enabling easier deploys and an image specification format, which freebsd still lacks.

Honestly, the documentation alone is enough to move me over to BSD—linux is basically the wild west, and you often discover undocumented behavior (is it a bug? is it intended? ask developer xxx on the mailing list.)

> This excludes a lot of non-free software, which is included in ports.

This depends completely on your choice of a distribution. There's nothing about package managers that makes a difference in this case.

For example Arch, especially with AUR will include all non-free software you want. Ubuntu offers them. Debian/RH have them one config edit away. Recently snap/flatpak also provide those to all distros - whether they're using free-only repos by default or not.

> In addition, LXC—in particular cgroups—is still quite young and unproven.

LXC was introduced over a decade ago. Cgroups even before that. Cgroups themselves are enabled per-session and per-service in pretty much every modern linux deployment for years now. There's less time between jails and cgroups than between cgroups and current day. Cgroups were added to linux in the same year as zfs was added to freebsd. (2007)

I'm not sure what you see as young or unproven about them.

LXC was only introduced in 2007. I wouldn't call ZFS a good comparison as I would also still consider it rather young in terms of basic unix technologies—depending on your needs, you could easily use some other simpler but older (and likely less buggier) software.

With respect to cgroups versus lxc specifically, I don't think the approach is well suited for security reasons—the surface area for bugs and vulnerabilities is much larger than with the jails approach.

> the surface area for bugs and vulnerabilities is much larger than with the jails approach

It would be great if someone wrote an article with technical details about it. I see this repeated very often, but if you actually go looking for details... it's hard to find any justification.

I can’t say I have a decent justification off hand myself—this was the impression I had when digging through a comparison of the two softwares about a year back. Cgroups appears to have a much more detail laden implementation, but this could be explained away with my lack of Linux internals.

The thing that always impressed me with FreeBSD was how it was a complete integrated system, and not a group of miscellaneous parts in loose formation.