We run bleeding edge FreeBSD at Netflix and are never more than a few weeks behind the FreeBSD main branch. This has worked out quite well for us.
We used to run -stable, and update every few years, like from FreeBSD 9.x to FreeBSD 10.x. We found that when we did that, we would often encounter some small subtle bug that was tickled in our environment, and which was incredibly hard to track down. That sort of bug was hard to track down because the diff between branches was enormous, and because there were thousands of commits to sift through, and because the person responsible for the bug may have committed it months or years ago, and has forgotten about it.
We eventually decided to track the main branch, updating frequently. This means that while we find more bugs, but they are far easier to fix because they were introduced more recently, and there are a lot fewer commits to look through to find where they came from.
This is why I prefer rolling distributions compared to stable ones, sure you only have to upgrade an LTS every few years but everything will break; whereas the small breaks you get with a rolling are easier to track down and diagnose.
It’s an interesting take that makes a lot of sense, but I still feel like the angle of “having less code to sift through to spot bugs” is very specific to your use case and high competence relative to other operations.
For a lot of companies, inspecting source code and filing bugs directly is just not a capacity that exists, which is where LTS of a Linux distribution makes a bit more sense — and without throwing any shade on FreeBSD (I love it), maybe the smaller amount of users globally compared to Linux means that “stable” isn’t quite as stable, especially if you’re doing bleeding edge stuff anyway.
I guess you could say the same thing is true for a company like Cloudflare considering their network related patches to the Linux kernel.
Yes, I think a lot of it also depends on how much you interact with the code of the open source project vs just consume the finished product.
If you're just a consumer, then it makes a lot of sense to consume the LTS branch. Whenever I've run ubuntu (which I do not contribute to), I run LTS for that reason.
In our case, we have a team of kernel engineers who make frequent contributions and are very familiar with the FreeBSD source code. So we're in a good position to inspect the frequent merges from upstream.
The other benefit to tracking the main branch closely is that it makes it far easier to contribute changes. When tracking the main branch, its easy to test a change in our tree, and then pick it up almost unmodified as a patch to the FreeBSD main branch. That makes it much easier to get the code into FreeBSD. In fact, for most smaller changes, we try to push them upstream first and bring them back with our frequent upstream merges This is much harder when running a several years old branch, as then the patch needs to be forward ported to the FreeBSD main branch. As such, its very hard to integrate and test changes suggested by reviewers, as the patch needs to be ported back and forth. And things get worse for large changes (like new TCP stacks, kTLS, etc), which are harder to port back and forth.
Fascinating! I worked with a company that figured out a similar thing with ruby and rails versions. By staying close to master, it's much easier to figure out what broke when things happen.
We used to run -stable, and update every few years, like from FreeBSD 9.x to FreeBSD 10.x. We found that when we did that, we would often encounter some small subtle bug that was tickled in our environment, and which was incredibly hard to track down. That sort of bug was hard to track down because the diff between branches was enormous, and because there were thousands of commits to sift through, and because the person responsible for the bug may have committed it months or years ago, and has forgotten about it.
We eventually decided to track the main branch, updating frequently. This means that while we find more bugs, but they are far easier to fix because they were introduced more recently, and there are a lot fewer commits to look through to find where they came from.