I've found with Linux distributions that aren't rolling releases, things tend to break in annoying and insidious ways, such that you generally need to, or at least it is strongly advisable to, fresh install each time.
This is probably of less importance given the demise of the monolithic server, but for my own server, I really appreciate it and the avoidance of reconfiguring everything.
However, major pkg upgrades also bring their fair share of config changes; and those major pkg upgrades usually happen during major version changes (11 -> 12). Can't remember how I did it, but at one point I had an ancient nextcloud running on a recent FreeBSD system where a pkg upgrade broke everything in a spectacular fashion.
The latest OpenBSD upgrade though (7.1 -> 7.2) did break an important base tool I used (dhclient(8)) by dumbing it down to a lesser version that is less capable (no auth) (but probably better written)[2], so YMMV.
> Changed dhclient(8) to defer to dhcpleased(8) by doing execve ifconfig and providing syslog warnings about deprecated options.
[0] https://www.freebsd.org/cgi/man.cgi?query=freebsd-update&apr...
[1] https://www.freebsd.org/cgi/man.cgi?query=sdiff&apropos=0&se...
[2] https://www.openbsd.org/72.html, https://try.popho.be/securing-home2.html#and-openbsd-decided...
Debian has historically been good for in-place upgrades. I first encountered the 'fresh install' recommendation on Ubuntu, which was a shame since Ubuntu is based on Debian :(
Fall behind by 3 or 4 versions and it's a long laborious task to upgrade each one. For products containing the OS which are shipped out to customers (NAS, firewalls, appliances, etc) this process might be too high risk, so it's easier to never upgrade - but ship new hardware, usually in the form of a new product.
(This is from personal experience taking on a client who still ran internet-facing FreeBSD 9.x servers. Lift & shift to the latest FreeBSD 13.x was far safer)
I'm not personally familiar with any commercial products shipping OpenBSD, but it was my understanding that the "proper" way to do this is to fork the OpenBSD build infrastructure, or at least build your own release tarballs, and basically push your own OpenBSD'ish distro. AFAIU, the binary patching and upgrade frameworks make some (limited?) effort to accommodate the creation and maintenance of bespoke releases.
But maybe doing it the "proper" way is too difficult or opaque, incentivizing vendors (even more than they usually are) to simply abandon released models.
I think this is generally not true, at least of the major distributions. Others have already commented about Debian and Ubuntu, to which I want to add that updating Fedora over many, many releases has been completely seamless for me. The dnf system-upgrade plugin Just Works.
I remember the old days where one had to manually compile and install the patches (instructions were provided), and where one had to build the entire kernel and userspace if you wanted to run -stable. A good learning experience and exercise, but I don't miss it. :)
When I started hosting professional web hosting in 1997, telnet was the standard way to log into servers. FreeBSD, which we used, didn't integrate SSH into the base system until 2000. In practice, no credentials were known to be compromised by sending them in plaintext. I recall a pretty rapid industry switch from telnet to SSH when it became available outside of OpenBSD.
I looked briefly at the relnotes[1], there is some scary stuff, such as this vulnerability in ping(1): https://www.freebsd.org/security/advisories/FreeBSD-SA-22:15...
Since a lot of code is shared between BSDs, I wonder if others have the same vulnerabilities.
(1) capsicum prevents the attacker from doing anything but making malicious network requests
(2) this is just a stack overflow, for ACE the attacker needs to fit their payload in under 40 bytes
https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri...
