I've been using Ubuntu Server non-stop on a wide range of differently configured (real aka bare-metal as well as virtual) servers for over 10 years. As a serve

I've been using Ubuntu Server non-stop on a wide range of differently configured (real aka bare-metal as well as virtual) servers for over 10 years. As a server OS I've really found it useful. (Except for that time when they shipped buggy versions of high-availability tools, warned against by the upstream maintainers, which segfaulted occasionally and showed inconsistent state across different nodes - thanks :/) I found it an improvement over Debian. And that an improvement over Red Hat (before it was RHEL and Fedora). And that an improvement over Slackware. CentOS and RHEL got used too in parallel on some sites, and were very solid, but with their own annoyances. But recently, on the server, LXD (aka LXC 2) switched from being a .deb package to being a Snap. They made a policy decision to stop shipping the .deb, to force server admins to start using Snap whether they wanted to or not, I guess. So I was forced to use Snap just to run LXD, which was annoying as things like configs and paths to the container images are buried inside the Snap somewhere, and various things with container-uids and host-container shared mounts stopped working. At least, the upgrade broke a bunch of working scripts. But it wasn't too painful, just a bit of work that felt like it was caused by an unnecessary annoyance. Ironically given other comments, the Snap does not seem to auto-update unlike all the other .debs on the system! Now, hearing about Ubuntu 20.04 and application snaps, I'm extra cautious before assuming Ubuntu 20.04 Server will be a smooth change. I'll take a look, and if the server software is much like 18.04 (except for annoying LXD) I'll use 20.04. But if they've moved a lot of things away from .deb to Snaps-only on the server, that's going to be some overhead to deal with, and it will at least result in evaluating whether switching distro is no more effort and a better choice. I've not been a fan of CentOS, but that time I was burned by the high-availability tools due to Ubuntu (and Debian) shipping a dangerously buggy version in an LTS release did make me realise that RHEL/CentOS are well maintained in that department and just wouldn't do that.