It should be obvious that the first situation is ideal
Well, maybe. Deploying any patch can be a high-risk activity. I’d say that, for most uses, this is ideal with one caveat: you should be able to roll back. On FreeBSD, I’m pretty blasé about applying base-system updates because freebsd-update creates a new boot environment before it starts and so, as long as I have console access, I can always roll back to the previous version. For something like a RPi, you’d probably to extend beadm activate to set the boot environment for the next boot only and then set it for all subsequent boots only after you’d got to the point where ssh worked.
FreeBSD has no way to automatically install security patches for things in the packages collection. As with many rolling-release systems, you can’t automate the installation of these security patches with FreeBSD because it is not safe to blindly update packages. It’s not safe to blindly update packages because they may bring along more than just security patches: they may represent major upgrades that introduce incompatibilities, etc. Unlike Debian’s practice of backporting fixes and thus producing narrowly-tailored patches, forcing upgrades to newer versions precludes a “minimal intervention” install. Therefore, rolling release systems are category 3.
Yeah… kind of. Neither Debian nor FreeBSD has the resources to back-port all security fixes. Both do it on a best-effort basis. The FreeBSD quarterly branches of the package collection get fixes that are in the upstream packages. Debian cannot, for example, back-port security fixes in Chromium or Firefox, because the code changes so much over the lifetime of a Debian release that you have to be an expert. The best that they can do is ship LTS releases of these and keep those up to date. FreeBSD typically packages both versions and you can choose if you want the LTS or the frequently updated release.
Well, maybe. Deploying any patch can be a high-risk activity. I’d say that, for most uses, this is ideal with one caveat: you should be able to roll back. On FreeBSD, I’m pretty blasé about applying base-system updates because
freebsd-updatecreates a new boot environment before it starts and so, as long as I have console access, I can always roll back to the previous version. For something like a RPi, you’d probably to extendbeadm activateto set the boot environment for the next boot only and then set it for all subsequent boots only after you’d got to the point where ssh worked.Yeah… kind of. Neither Debian nor FreeBSD has the resources to back-port all security fixes. Both do it on a best-effort basis. The FreeBSD quarterly branches of the package collection get fixes that are in the upstream packages. Debian cannot, for example, back-port security fixes in Chromium or Firefox, because the code changes so much over the lifetime of a Debian release that you have to be an expert. The best that they can do is ship LTS releases of these and keep those up to date. FreeBSD typically packages both versions and you can choose if you want the LTS or the frequently updated release.