alt Hacker NewsAs much as I love FreeBSD, the release schedule is a real challenge in production: each point release is only supported for about three months. Since every release includes all ports and packages, you end up having to recertify your main application constantly.
Compare this to RedHat: yes, a paid subscription is expensive, but RedHat backports security fixes into the original code, so open source package updates don’t break your application, and critical CVEs are still addressed.
Microsoft, for all its faults, provides remarkable stability by supporting backward compatibility to a sometimes ridiculous extent.
Is FreeBSD amazing, stable, and an I/O workhorse? Absolutely: just ask Netflix. But is it a good choice for general-purpose, application-focused (as opposed to infrastructure-focused) large deployments? Hm, no ?
Replies
> As much as I love FreeBSD, the release schedule is a real challenge in production: each point release is only supported for about three months. Since every release includes all ports and packages, you end up having to recertify your main application constantly.
How much support do you plan on getting? The old releases don't really turn into pumpkins. Yes, every two or three major releases, they end up with a minor release that adds something to libc where binary packages from X.2 won't run on X.1 or X.0. But this isn't usually a huge deal for servers if you follow this plan:
Use FreeBSD as your stable base, but build your own binaries for your main service / language runtimes. If you build once and distribute binaries, keep your build machine / build root on the oldest minor revision you have in your fleet. When you install a new system, use an OS version that's in support and install any FreeBSD built binary packages then.
You do have to be prepared to review updates to confirm if they need you to take action (many to most won't if you are careful about what is enabled), backport fixes, build packages yourself, or upgrade in a hurry when necessary, but you don't often actually need to.
I don't think this strategy works for a desktop deployment; there's too many moving pieces. But it works well for a server. Most of my FreeBSD servers for work got installed and never needed an OS upgrade until they were replaced by better hardware. I did have an upgrade process, and I did use it sometimes: there were a couple kernel bugs that needed fixes, and sometimes new kernels would have much better performance so it was foolish to leave things as-is. And a couple bugs in the packages we installed; usually those didn't need an OS upgrade too, but sometimes it was easier to upgrade the handful of old servers rather than fight everything; choosing battles is important.
Or you can go like Netflix and just run as close to -CURRENT as you can.
As someone who was a Linux sysadmin for several years, looking after a large fleet of RedHat boxes, I can say that the "don’t break your application" promise is BS. Their patches broke applications several times resulting in having to hold them back for months for it to be fixed.
The only Linux distro that actually lives up to that promise in my experience is Alpine.
What you measured is just the overlap between minor releases of the same major release. It helps to think of them as service packs if you want a MicroSoft analogy. So each minor release is supported until it has be surplanted for 3 months by a new one on the same major release line or the whole major release line goes end of life.
each point release is only supported for about three months
Where are you getting 3 months from? It's usually 9 months and occasionally 12 months.
Also, major versions are supported for 4 years and unless you're messing with kernel APIs nothing should break. (Testing is always good! But going from 14.3 to 14.4 is not a matter of needing lots of extra development work.)