This related question What are the pros/cons of deb vs. rpm? seems to be more focused on personal computers, but in the context of a server, why do most of the servers run either RedHat / CentOS or SUSE?

Is there any notable improvement of rpm over deb? Or is it just because they are products provided by a company rather than a community?

  • 1
    The package format typically has nothing to do with the choice of distribution. Jun 13, 2013 at 13:40
  • @UlrichDangel What do you mean? Ubuntu and Debian use Debian packages, RedHat, CentOS and SUSE use RPMs. You can convert most of them using Alien, but the package formats are very distribution-dependent. Perhaps you mean that a package prepared for Precise will have the some format as one for Quantal? Or that Lubuntu uses the same packages as Kubuntu/Xubuntu/Ubuntu? I'm really confused as to what you're saying here... Jun 13, 2013 at 14:38
  • @JamesTheAwesomeDude you may want to choose any of these distributions for any kind of different reasons but typically you wouldn't choose a distribution for a production system based on it's packaging format. Jun 14, 2013 at 0:32
  • @UlrichDangel Ohh, I thought he meant that there's no difference between the packages between the different distributions.... Now it makes sense.. Jun 14, 2013 at 2:42

2 Answers 2


The deb and rpm package formats were developed separately at the same time to solve the same basic problems. Most servers run RHEL just because historically that's been the most popular distribution and has adopted new technology as it came out, which enabled people who were patient to just camp out on a distro they knew about. I would say, if you're planning an enterprise deployment go with RHEL/CentOS as it will be easier to find and staff people who have experience with that specific distro (not because of the package manager). Canonical provides enterprise editions of Ubuntu but their support infrastructure (as a company) isn't as well developed as SuSE or Red Hat's and it's still a niche skillset in enterprise Linux.

The formats themselves are just different because they each were trying to solve the problem without consulting the other, and what exists in one exists in the other. It's sort of like countries with left-sided driving and those with right sided driving. As long as you apply the rule consistently, there's nothing wrong with either one. There's very little drive to unify people on either solution for the same reason: it's not really a problem. The two solutions are feature competitive and it's not like there's a guarantee of widespread ABI compatibility between RPM-based distros and dpkg-based distros (meaning there's not much to gain through shared package manager software).

Administrators may have personal preferences on how much they prefer things like apt-get versus yum but that's all it is, a personal preference.

As far as the packages are involved in your choice, though, you want to concentrate on "Enterprise" versus "Community" styles of package development, but still not the file format.

Community packaging typically has very loose QA requirements and the community distro has a strong incentive to provide everything under the sun so everyone can find the packages they need. Enterprise packages make certain guarantees involving ABI compatibility inside of major versions, package selection, and the introduction of new features, all for stability.

  • The ABI guarantee - Application Binary Interface, allows you to perform system updates and only have to restart individual programs that link against anything that got replaced (libraries, executables, etc). If upstream fixes something relevant to a version shipped to you, your EL distro provider is supposed go out and find a way to backport the fix to the version they're shipping in a way that doesn't break anything else. This also helps the platform itself get product certification for ISV products that you might be required to run.

  • Restricted package selection enables the company that's providing the packages to more extensively QA the software you may see when looking for a solution to a problem. This is as opposed to something like Fedora where the package just needs to not be hopelessly broken and seem like it's useful to someone before it gets included.

  • New features obviously introduce bugs and are subject to constant changing and deprecation. Delaying feature adoption is the EL distro's way of shielding enterprise users from that chaos, but also helps ensure the ABI compatibility requirement.

Probably more information than you wanted, but there you go.

  • 1
    Please don't confuse RedHat-based and RPM-based distributions. Just don't. SUSE is not a RedHat fork (it was originally a german translation of Slackware and adopted RPM much later on - around 1998) - the first S.u.S.E Linux was actually released about half a year earlier than Red Hat Linux 1.0.
    – peterph
    Jun 13, 2013 at 15:11
  • 1
    I don't think I ever said it was a fork. "RPM" stands for "Red Hat Package Manager" which is what I'm talking about. I'm going to update the language so it's a little clearer what I'm trying to say.
    – Bratchley
    Jun 13, 2013 at 15:32
  • No, it was just the "RedHat-derived" that caught my eye, thanks for fixing that. BTW, while RPM originally was Red Hat Package Manager, these days it is rather RPM Package Manager. Otherwise certainly +1. :)
    – peterph
    Jun 13, 2013 at 18:31
  • 1
    "Community packaging typically has very loose QA requirements". This is a strange comment. Debian's packaging, for example, conforms to Debian policy, which is the most rigorous set of requirements I am aware of for any distribution. Jun 13, 2013 at 19:10
  • Having a basic packaging policy isn't really QA, it's just regular distribution management. What kind of unit testing, etc. does the Debian project do?
    – Bratchley
    Jun 13, 2013 at 20:09

When I choose a Linux distribution for a server, there are two major factors I consider:

  1. Will this server run any application software which requires/recommends a particular distribution? Some products have a support matrix, and if support from that vendor is needed, they can be troublesome if you're running on an unsupported distribution.
  2. Do I need 24/7 support in case of serious hardware or OS failure? If so, I've had good experiences with Red Hat, so I rely on them. If not, then I will go with another distribution with a more aggressive update schedule (e.g. a Debian-based distribution). For example, RHEL typically lags behind Ubuntu in the PHP version.