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?

closed as not constructive by Anthon, jasonwryan, Hauke Laging, Gilles, Ulrich Dangel Jun 14 '13 at 0:31

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    The package format typically has nothing to do with the choice of distribution. – Ulrich Dangel Jun 13 '13 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... – JamesTheAwesomeDude Jun 13 '13 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. – Ulrich Dangel Jun 14 '13 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.. – JamesTheAwesomeDude Jun 14 '13 at 2:42

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 '13 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 '13 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 '13 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. – Faheem Mitha Jun 13 '13 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 '13 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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.