在服务器环境中 rpm 相对于 deb 的优势是什么?

在服务器环境中 rpm 相对于 deb 的优势是什么?

这个相关问题deb 与 rpm 的优缺点是什么?看起来更侧重于个人电脑,但是在服务器方面,为什么大多数服务器要么运行RedHat/CentOS,要么运行SUSE?

rpm 相对于 deb 有什么显着的改进吗?或者只是因为它们是公司而不是社区提供的产品?

答案1

deb 和 rpm 软件包格式是同时单独开发的,以解决相同的基本问题。大多数服务器都运行 RHEL,因为它在历史上是最受欢迎的发行版,并且在新技术出现时就采用了新技术,这使得有耐心的人们可以在他们了解的发行版上安营扎寨。我想说,如果您计划进行企业部署,请选择 RHEL/CentOS,因为这样会更容易找到并配备具有该特定发行版经验的人员(不是因为软件包管理器)。 Canonical 提供 Ubuntu 企业版,但他们的支持基础设施(作为一家公司)的开发程度不如 SuSE 或 Red Hat,而且它仍然是企业 Linux 中的一项小众技能。

这些格式本身只是不同,因为它们都试图在不咨询对方的情况下解决问题,而一种格式中存在的内容也存在于另一种格式中。这有点像左侧驾驶的国家和右侧驾驶的国家。只要您始终如一地应用该规则,任何一个都没有问题。出于同样的原因,人们几乎没有动力将这两种解决方案统一起来:这并不是一个真正的问题。这两种解决方案在功能上具有竞争力,并且不能保证基于 RPM 的发行版和基于 dpkg 的发行版之间广泛的 ABI 兼容性(这意味着通过共享包管理器软件没有太多好处)。

apt-get管理员可能有个人偏好,比如他们对诸如“与”之类的东西的偏好程度,yum但仅此而已,个人偏好。

不过,就您选择中涉及的包而言,您希望专注于包开发的“企业”与“社区”风格,但仍然不是文件格式。

社区打包通常具有非常宽松的质量保证要求,并且社区发行版有强烈的动机提供阳光下的一切,以便每个人都可以找到他们需要的包。企业包做出了一定的保证,包括主要版本内部的 ABI 兼容性、包选择以及新功能的引入,所有这些都是为了稳定性。

  • ABI保证——应用程序二进制接口,允许您执行系统更新,并且只需重新启动链接到任何被替换的内容(库、可执行文件等)的单个程序。如果上游修复了与交付给您的版本相关的某些内容,那么您的 EL 发行版提供商应该出去寻找一种方法,以不破坏其他任何内容的方式将修复向后移植到他们正在交付的版本。这还有助于平台本身获得您可能需要运行的 ISV 产品的产品认证。

  • 受限制的软件包选择使提供软件包的公司能够更广泛地对您在寻找问题解决方案时可能看到的软件进行质量检查。这与 Fedora 之类的东西相反,在 Fedora 中,包只需要不被无可救药地破坏,并且在被包含之前看起来对某人有用。

  • 新功能显然会引入错误,并且会不断变化和弃用。延迟采用功能是 EL 发行版保护企业用户免受混乱影响的方法,但也有助于确保 ABI 兼容性要求。

可能比您想要的信息更多,但是就这样。

答案2

当我为服务器选择 Linux 发行版时,我会考虑两个主要因素:

  1. 该服务器是否会运行任何需要/推荐特定发行版的应用程序软件?有些产品有一个支持矩阵,如果需要该供应商的支持,如果您在不受支持的发行版上运行,它们可能会很麻烦。
  2. 如果出现严重的硬件或操作系统故障,我是否需要 24/7 支持?如果是这样,那么我在红帽方面有很好的经验,所以我依赖它们。如果没有,那么我将选择另一个具有更积极更新计划的发行版(例如基于 Debian 的发行版)。例如,RHEL通常落后乌班图在 PHP 版本中。

相关内容