I agree that the stated reasons don't sound very compelling. Maybe in aggregate, but not individually.

But they left out one of the bigger reasons, IMHO. FreeBSD doesn't tend to churn user (admin) facing interfaces. This saves you time, because you still use ifconfig to configure interfaces, and you still use netstat to look at network statistics, etc; so you don't have to learn a new tool to do the same thing but differently every couple of years. Sure, there's three firewalls, but they're the same three firewalls since forever.

ifconfig/netstat was deprecated more than a decade ago, that's more than a couple years don't you think?

Deprecated on Linux. But I for one can’t consign them to the dustbin of my memory, because on my Mac, they are not deprecated, while the `ip` command that replaces them on Linux does not exist. With this part of macOS being derived from FreeBSD, I don’t know whether that makes FreeBSD a savior or a villain.

Personally I blame all of the major Unix-derived operating systems (Linux, macOS, BSDs), as none of them show any interest in standardizing any APIs or commands invented this millennium. The subset that’s common to all of them is frozen in time, and is slowly being replaced by new bits that aren’t. From epoll/kqueue to eBPF, containers/jails to seccomp/pledge, DBus/XPC to init systems… from low-level network configuration (ifconfig, ip) to high-level network configuration (whatever that is this month).

At first I wanted to say that while this is inconvenient, it is better for the larger ecosystem because we explore the problem space more. But the more I think of it, the more I see it as just a superficial exploration, not deep operating system research.

On Linux, the last commit on it was about a decade ago.

On FreeBSD, the last commit on it was last week.

They're not the same tool, and FreeBSD didn't abandon their core tools, because they're part of the base system.

The last commit for the source code of ifconfig, route, et. al, for Linux was as of this writing, about six weeks ago:

https://sourceforge.net/p/net-tools/code/ci/4030929bb6f3ee6f...

It's still used in some user spaces, and the Linux kernel supports the system calls for net-tools still today, because of the Torvalds Prime Directive, "though shalt not break userspace".

The FreeBSD POLA design principle makes sure fundamental tools don't disappear or worse double over the years. Linux distributions differ vastly from vendor to vendor.

Since it was just an example, I don't think refuting this particular item will nullify the opinion. The idea, I think, is that there are always more pieces in a state of deprecation and replacement at any given time in Linux land than in FreeBSD land.

I think that's just due to the pace of development. The BSDs are resource constrained, so they have to pick and choose what to work on. That is both a good thing and a bad thing. Here the benefit is less churn. On the downside, they're just catching the Wayland train recently. On the up side, by catching it late they didn't suffer a lot of the growing pains.

wait wait they were deprecated? why on earth?

(on linux)

Some people see the bigger picture and recognize that a medium amount of work now is better than lots of small amounts of work stretched over many years.

Likewise, some people and many businesses see the immediate now and aren't always the best at planning for long term, and/or are overly optimistic that their pain points will eventually be fixed.

> Likewise, some people and many businesses see the immediate now and aren't always the best at planning for long term, and/or are overly optimistic that their pain points will eventually be fixed.

But that's the thing. The pain points mentioned in this article aren't really that strong to need to ditch the OS and move to a new one. These kinds of decisions have huge tradeoffs.

One could argue, in fact, that moving to a non-traditional OS will make it much harder to hire experts or hand off the system to another team in the future.

I think of it this way: If you interpret "rolling stones gather no moss" to mean you've always got to keep pushing forward or you'll become obsolete, choose Linux. If you venerate moss as proof of the stability granted by doing the same thing simply and perfectly, you're probably already using FreeBSD.

After CentOS Stable was cancelled, I migrated a number of our platforms to FreeBSD because it met our needs and I enjoyed working on it. No surprises, nothing breaking, and most importantly, no drama.

What? FreeBSD as a non-traditonal OS? I must disagree, FreeBSD may not be as common as Windows or Linux but it's not like Plan9 (from outer space) or BeOS.

I agree.

Nothing there seems to deliver explicit customer value when switching to FreeBSD.

How will switching help you deliver your service? Or is it just a "nice to have thing"?

Under what circumstances does the choice of backend OS ever deliver "explicit customer value", so much so that the customer would care about said choice?

Normally the customer doesn't care. They will care, however, if something goes wrong during the migration or some unforeseen issue comes up later that degrades their experience.

It is definitely the case that underlying architecture, certainly all the way down to the OS, can be the difference between "I can create, test, and deploy this feature in a week, and it will be rock-solid" and "it'll take months and still fail on some edge cases—and fixing those is not remotely in our budget".

I'd hazard to say that it delivers customer value via two avenues: (1) better SLAs, and (2) lower expenses.

If your backend OS starts to run software more efficiently, cost less to host, has less maintenance downtime, has fewer security incidents, has fewer crashes, etc, having changed to it has produced customer value.

> Under what circumstances does the choice of backend OS ever deliver "explicit customer value", so much so that the customer would care about said choice?

Is the service working, is it not? (are there show stopping OS issues?)

Are the performance characteristics we need there, or not?

Is the service secure or not?

There's a whole lot of things right through that entire space where the choice of operating system can make quite a fundamental difference.

As a general statement, I wouldn't want to make this kind of a migration without something bordering on a killer feature that wasn't possible otherwise, or some fundamental driver problems (I've replaced Linux with FreeBSD on border devices in the past, due to particular issues with Linux in ways I couldn't afford to have keep biting me)

is this a joke..... this must be a joke

Quick: what OS is running on the machine at your bank that makes your debit card work in an atm? If you have to care about the answer to that question, your bank is doing it wrong.