4 ms·

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

by hnarn 3y ago

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. Thanks for the perspective!

drewg123 3y ago
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.
- ignoramous 3y ago
  Curious: What does your rollout look like? Update to the latest on a small percentage of the fleet and monitor for a day / week? Also, do you folks tend to review the freebsd code before upgrades or only after the fact (like, if there's a show-stopping bug or two)? Thanks.

by hnarn 3y ago

drewg123 3y ago

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.

ignoramous 3y ago
Curious: What does your rollout look like? Update to the latest on a small percentage of the fleet and monitor for a day / week? Also, do you folks tend to review the freebsd code before upgrades or only after the fact (like, if there's a show-stopping bug or two)? Thanks.