Genuine questions:

Do you ever apply kernel patches? I also run FreeBSD and reboot for any kernel patches and never can get my uptimes to 1,000 days before that.

Do you just run versions that don't get security patches? Security support EOL dates generally means I need to upgrade before 1,000 days too. For example the current stable release gets security patches only from June 10, 2025 to June 30, 2026 giving just over 360 days of active support.

I get FreeBSD is stable and get days of uptime, and I could easily do the same if I didn't bother upgrading etc, it's just that I can't see how that's done without putting your machine at risk. Perhaps only for airgapped machines?

> Do you ever apply kernel patches?

For my personal machines, I just run GENERIC kernels and that includes a lot, so I need to do a lot of updates. I also reboot every time I update the OS (even when it's an update that doesn't touch the kernel) so that I'm sure reboots will be fine... but I did setup my firewalls with carp and pfsync so I can reboot my firewall machines one at a time with minimal disruption.

For work machines, I use a crafted kernel config that only includes stuff we use, although so far I've usually had one config for all boxes, because it's simpler. If there's a security update for part of the kernel that we don't use, we don't need to update. Security update in a driver we don't have, no update; security update in tcp, probably update. Some security updates include mitigation steps to consider instead of or until updating... Sometimes those are reasonable too. Sometimes you do need to upgrade the whole fleet.

When there's an update that's useful but also has an effective mitigation, I would mitigate on all machines, run the update and reboot test on one or a few machines, and then typically install on the rest of the machines and if they reboot at some point, great, they don't need the mitigation anymore. If they are retired with 1000 days of uptime and a pending kernel update, that's fine too.

I would not update a machine just because support for the minor release it was on timed out. Only if there was an actual need. Including a security issue found in a later release that probably affects the older one or at least can't be ruled out. Yes, there's a risk of unpublished security issues in unsupported releases; but a supported release also has a risk of unpublished security issues too.

One of my four colocated servers is at something 1200 days+ of uptime running on 12-BETA.

Tightly firewall'd to my VPN and SSH is restricted to certificates. There are no services on the host that would allow users to upload inject, the most you could achieve is a DDoS.

I run bHyve in a jail and any legacy services that could jump out of bHyve stack would straightly go to jail.

Fair question! But why am I -1 on this?

Risk is relative and not just about THAT security. I worked at an AV vendor and the joke internally was our security threat lists were the scoreboard for bad actors. But if you asked our salespeople you are an irresponsible hack if you don't keep up to date. They never account for the person who really can do it himself -- that is not their customer.

Yes I used to build custom FreeBSD kernels a lot. I manually made security patches on a few occasions and I put in many work-arounds by reading the security mailing list etc. Yes I went well past EOLs a few times for sure.

Always behind a firewall, workloads always in a Jail.

IIRC the release cycles used to be longer and it was less of an issue ~10 years ago. Can anyone confirm?

Most of my downtimes started with a power issue in the datacenter or a need for a hardware upgrade.

Some of the largest orgs have large amounts of IT infrastructure for OT and ISS that is not connected to the Internet. This infra is air gapped or often times on a completely separate physical LAN which is not accessible without passing through multiple physical security controls.