Usually, the upgrades are seamless (freebsd-update(8)[0]); system files that change between releases are looped through with some help of sdiff(1)[1] with relatively few surprises jumping dot releases (12.3 -> 12.4).

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...

> 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.

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 :(

It does have a solid and well documented upgrade process, provided you're on the latest stable version prior to executing the upgrade.

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'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.

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.

OpenBSD's in-place upgrades and binary patches are wonderful for keeping the system up-to-date. I've even successfully done a remote upgrade after ensuring there was enough space for the upgrade files.

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. :)

Binary upgrades on FreeBSD are fine. I rarely compile my own kernel these days, but even when I did needed a custom kernel I never had any issues. It just works, For me FreeBSD and OpenBSD needs much less maintenance than Linux.

You don't get telnetd enabled by default. To get it working you need to explicitly start it. No idea why you're talking about it here.

It was pretty easy to get someone's password by tailing /var/log/messages and waiting to see a auth failure followed by a success with a totally different username (i.e. not what looks like an entry correcting a typo). That only worked on shared hosting environments, of course.

I don't get what you try to say. But i really hope you don't use telnet over a unsecured net..nor rlogin, http (partially true) or ftp (also partially true).

This vulnerability was very much overblown.

(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

This ping vuln is not shared anywhere. It is based on a freebsd-specific "optimization" from 2019. Other pings are totally different, I also have my own ping, and it's not affected.

> The ping process runs in a capability mode sandbox on all affected versions of FreeBSD and is thus very constrained in how it can interact with the rest of the system at the point where the bug can occur.

I would assume there's some level of communication between the various security teams, enough that someone would check if OpenBSD/MacOS had the same bug before they went public with it at least.

Note that, thanks to capsicum(4), this vulnerability is not very exploitable.

For that there is some interesting work being done with Cheri and specifically CheriBSD which is built in top of FreeBSD

https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri...