Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
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?
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.
When I choose a Linux distribution for a server, there are two major factors I consider:
