FreeBSD 14.5-Release
freebsd.org
freebsd.org
(Yes. I know.)
Edit: I love HN. I'm obviously joking, but instant 4 downvotes
We're allowed to have fun, guys.
Also, real businesses use -CURRENT, everybody knows that.
No, not really.
https://arstechnica.com/gadgets/2021/03/buffer-overruns-lice...
Most users will neither be willing nor able to accept the trade-offs that Netflix chose.
Some of these things have long lifetimes.
A RELEASE is good for installing FreeBSD on a new computer, or for upgrading from a previous major version of FreeBSD, e.g. from 13 to 14 or from 14 to 15.
After installing a RELEASE, you normally update it to STABLE, before starting to use the computer.
STABLE versions correspond to the long-term-support versions of Linux, i.e. they include only essential back-ported patches, like security patches or bug fixes.
RELEASE are the initial versions, like a Linux x.x.0 version, which may have various problems that are discovered later and corrected in the STABLE versions.
I have been running FreeBSD continuously 24/7 on many servers for more than a quarter of century, and I have always used STABLE on them (after installing RELEASE first, especially when upgrading from an older major version, to minimize the risks of incompatibilities).
“FreeBSD-STABLE is the development branch from which major releases are made.”
(https://docs.freebsd.org/en/books/handbook/cutting-edge)
probably works, but i’m not doing that on my prod thanks. (perhaps you’re thinking of the releng/foo branches instead?)
However, this is because the policy of FreeBSD has changed. Decades ago, when I started using FreeBSD, STABLE was like I said, the recommended branch for production and frequently it was strictly necessary to update to STABLE because it had important patches missing in RELEASE.
It appears that they have changed this some years ago.
However, I was oblivious to this, because it did not affect me as I do not track automatically their STABLE versions, but I do only some audited updates.
> $Id: stable.sgml,v 1.1 1996-02-11 00:16:17 jkh Exp $
> FreeBSD-stable is our development branch for a more low-key and conservative set of changes intended for our next mainstream release.
..
> If you're a commercial user or someone who puts maximum stability of their FreeBSD system before all other concerns, you should consider tracking <em>stable</em>
..
> Please note that the <em>stable</em> tree endevors, above all, to be fully compilable and stable at all times, but we do occasionally make mistakes (these are still active sources with quickly-transmitted updates, after all)
Indeed, the first step to tracking stable is to join the mailing list:
> <heading>Using FreeBSD-stable</heading>
> <p><enum><item> Join the freebsd-stable mailing list.
So the nature of the branch hasn't really changed, it's more that there's now much less reason to track it - we have regular patch releases, and the ports system no longer only supports CURRENT and STABLE.
These days, I always use RELEASE and apply patches with freebsd-update.
I used FreeBSD at Yahoo and WhatsApp, using RELEASE at both. I'm sure there were some times where some groups were running other than RELEASE (and they were running Yahoo builds anyway), but at both places when I was there, we didn't have habit of upgrading the OS. To my knowledge, none of the servers I ran at Yahoo had an OS update installed, I'm not sure there was a procedure; we would get a server it would have the then latest Y! FreeBSD build, we would install our stuff and go for 3-5 years until the server was sent to recycling. Most of our servers never rebooted.
That pattern doesn't really fly today, lots of kernel security fixes and what nots, so you've got to do updates and reboots. At the time, running a miminal kernel and minimal services meant most security updates were for things not on our machines or could be updated without rebooting or doing a full upgrade cycle.
Using RELEASE makes it easy to understand what host has what, rather than -STABLE from whatever day it was installed. This is pretty handy when you've got a mixed fleet of whatever was current when they were installed.
Towards the end of my time at WhatsApp, I did work on keeping our fleet more current, mostly because we had more servers where they didn't need hardware upgrades for a long time, so they didn't get OS refeshes. Running 4 different major versions is irritating in ways that are most easily addressed by doing the upgrade work.
The only time we ran outside of -RELEASE at WhatsApp was very ocassionally to confirm kernel patches we wanted to upstream, but we didn't have a lot of patches, not all of them were important to upstream, and many of them didn't need a report from CURRENT.
Some releases would have important upgrades that really helped some workloads so we'd push those, but at least I would find those out from reading release notes, not following development closely. Or sometimes we'd find out by accident... if a server lost its disk and we set up the replacement with a newer release and perf was significantly different, we'd try to figure out what changed and if perf was better, we might upgrade the other servers for that workload.
Linux distros only recently started doing this with the rise of flatpaks on top of immutable distros (or Debian stable).