It's OT but how many people actually use RHEL? Or CentOS (more likely).

I'm not a fan of systemd, but have really loathed CentOS/RHEL compared to Debian/* for years.

We run one CentOS 6 server at work (which uses upstart, not systemd). The initial reason was that it needed to run on Hyper-V, and the Debian VM I had set up first, kept losing its network connection every couple of minutes, which was especially annoying since I wanted to run Nagios on that system. ;-)

So I did a bit of digging and found out that CentOS ran on Hyper-V just fine. I installed it and had no real reason to complain since. The selection of packages is rather spartan compared to Debian, but there is a third-party repository called EPEL that makes up for that.

Some things are different from Debian, of course, but nothing big, and the system has given me no problems whatsoever on the performance and reliability fronts.

EPEL doesn't get security updates.

Security support for a wide range of packages is also a reason to prefer Debian over Ubuntu, since most of the Debian-inherited packages ("universe") are excluded in Ubuntu.

EPEL gets security updates just like fedora does. Packages are usually maintained in the same gut repositories. However there is no guarantee that you will receive security updates as there is no support contract. But you have a similar problem in Debian if the maintainer isn't keeping up

Debian doesn't have this problem: the security team is collectively responsible for making security updates and frequently creates updated packages without maintainer involvement.

I'm not familiar with the Fedora process, but they seem to have a security team and a system of security advisories, which EPEL does not appear to have. Doesn't sound like the same at all.

Sure, most of the time packages in EPEL (and in Ubuntu universe section) will eventually get security updates, but there is no promise or organization of timely security updates.

> the security team is collectively responsible for making security updates and frequently creates updated packages without maintainer involvement.

How can they do this if a packaging (and especially backporting) a fix requires deeper knowledge of the package which probably only the maintainer has?

https://github.com/g0tmi1k/debian-ssh > There was an #ifndef PURIFY there for a reason. It's because the openssl authors knew that line would cause trouble in a memory debuger like Purify or Valgrind.

Where a debian maintainer screwed the RNG of OpenSSL to make valgrind happy. This made any key generated on a debian or ubuntu system from 2006 to 2008 very easily breakable.

Downstream should never touch packages beyond backporting fixes made by upstream.

Here's another example of upstream vs downstream conflict in debian :

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477454

Or PHP developers being fed up with both RedHat and Debian messing with their runtime on whims :

https://derickrethans.nl/distributions-please-dont-cripple-p...

This is why I heavily support the desire for a new packaging system targeted at developers: snaps, flatpak. The downside of having multiple copies of the same libraries pale in comparison to giving back power to upstream. Distro maintainers are routinely modifying codebases they don't understand. Allow us to have a standard installation process that can install packages.. made by the developers themselves, upstream. Just like all other operating systems do.

And Debian, unlike RHEL/CentOS, packages a lot more than they can even reasonably maintain. The vast majority of packages in a Debian stable are insecure, the security team simply cannot handle the large amount of software outside of the truly core stuff (kernel, web servers) :

https://statuscode.ch/2016/02/distribution-packages-consider...

If you aren't supposed to use the packaged wordpress, phpmyadmin or node, why is debian distributing those packages? Debian by distributing these things in their repo encourages the naive first time linux user to install them through their facilities.