IT 部门应该如何选择标准的 Linux 发行版？

Question

对于哪些 Linux 发行版适合生产服务器环境，哪些不适合，有很多社区感觉，但是，很多这种感觉似乎是基于宗教的，并且很少提供支持证据。

假设我们试图选择一个 Linux 发行版进行标准化（因为我们有兴趣保持我们的环境尽可能同质），什么标准是重要的，你如何确定不同的发行版如何满足这些标准？

Answer 1

我将分享我在几个不同领域担任技术专家的经验...

（注意：这是一个关于 Red Hat 的故事以及我如何在专业上成长）

我从 2000 年到 2002 年开始专业地使用 Linux。这是在红帽和红帽专业版（6.x、7.x、8.0）被广泛采用的过程中。这些可以免费下载以及盒装套装。它们很容易在计算机零售店中找到。

对我来说，这有利于让业余爱好者和家庭用户使用开始出现在企业中的相同产品。我此时的工作是将客户服务器系统从商业 Unices（HP-UX、AIX 和 SCO）迁移到 Red Hat 平台。

节省的成本非常可观！用价值 4 万美元的 Compaq ProLiant Intel 服务器替换 10 万美元以上的 HP9000 PA-RISC 服务器是成本和性能方面的绝对胜利。

那么，为什么是红帽？

红帽是第一个进入这个市场的公司，获得了关键的业务、供应商和硬件支持。看到大型应用程序供应商使用红帽作为目标平台，交易达成了。像我这样的业余爱好者能够轻松地将在家中磨练的技能转移到我们的工作环境中。社区不断壮大。Slashdot、Freshmeat和LAMP 堆栈统治！这是 Linux 的好时机。

至此，我负责作为专有 ERP 软件解决方案平台的 Linux 发行版的开发和评估。我坚持使用红帽。每隔一段时间，我就会尝试另一个发行版（Mandrake、SuSE、Debian、Gentoo），但会发现包装、硬件支持（服务器或外围设备）、（社区规模）或其他一些交易破坏者的问题。

一个例子：我使用的是配备Digi Serial 扩展 PCI-X 卡和Esker VSIfax 生产传真软件的Compaq/HP ProLiant 硬件。后两者只有对 Red Hat 操作系统的驱动程序支持。在某些情况下，软件仅以二进制或 RPM 形式交付，无法在其他 Linux 变体上轻松使用。

信息技术世界中的动力很重要
没有人愿意推荐失败的解决方案或最终成为孤儿的项目，因此您坚持安全的选择。我正在管理一个需要可靠工作并具有多层支持的技术堆栈。在那时选择不同的分布就可以了。是。不负责任。

2003 年，随着该软件专业版的停止，我的红帽蜜月之旅结束了。红帽企业 Linux是替代品，但带来了很多包袱……成本（昂贵的基于订阅的模型）、可访问性（缩小用户群和社区）以及对未来的普遍困惑……

我开始寻找替代品，重新评估 Gentoo、Debian 和 SuSE。我无法在我们技术堆栈的所有组件上获得正确的支持。我被迫坚持使用 Red Hat 生态系统......由于与 Red Hat Enterprise Linux 相关的巨大成本转移，我最终运行了经过高度修改的 Red Hat 8.0，在其生命周期结束后多年。直到 RHEL 克隆成熟（Whitebox Linux，以及后来的CentOS），我才真正准备好脱离我的标准。

Red Hat 衍生产品的主要优势是与付费 RHEL 版本的二进制兼容性。甚至可以在 RHEL 和 CentOS 之间执行就地转换，反之亦然。我继续使用类似 RHEL 的系统工作，直到我进行下一个职业发展……

后来我进入高频金融交易行业，负责关键自动交易系统的研发和 Linux 工程。这个世界的重点是速度，通过仔细的测试和调整。同样，硬件支持是关键。我有特定的网卡，专用的硬件、仅针对 RHEL 或类似 RHEL 的系统进行认证的服务器硬件或应用程序库。即使在可以为其他 Linux 变体编译的情况下，社区因素也会出现。当我需要研究问题时，通常可以追溯到 Red Hat Bugzilla 报告中的注释或评论的问题，或者有时，我只是提交补丁或请求下一个版本.

当我开始深入研究低延迟网络和内核调优时，我开始剖析现有的 RHEL 内核和RHEL MRG 实时内核。我注意到在发布时有多少工作...... 200+ 补丁到 vanilla kernel.org 内核。阅读评论并提交注释。你可能有一些小东西，比如sysctl暴露的参数或更合理的默认值。红帽支付人员来修补、测试和修复这些问题。我没有看到其他Linux发行版同样的承诺...增加了企业平台是保证有真正的安全，bug修正和反向移植支持的事实年。

所以我最终搬到了另一家在服务器和桌面上几乎全是 Gentoo 的金融公司......这对我来说是一场灾难。来自 Red Hat 和 CentOS 世界，我在 Gentoo 设置中遇到了许多稳定性和管理问题。版本控制是最大的问题，但社区支持的减少和缺乏真正的测试也是令人担忧的。我开始将 RHEL 引入环境中，因为我们的一些第三方软件需要它......

但是有一个问题……我的开发人员已经习惯了 Gentoo，并且对于核心库和应用程序版本有相对容易的升级路径。他们无法适应拥有 Red Hat Enterprise Linux 标准化的固定主要版本。开发和发布过程一直被关于为什么 GLIBC 2.7 不能移植到 RHEL 5.x或为什么某个编译器或库版本不可用的问题所困扰。当得知 RHEL/CentOS 主要版本之间的升级本质上需要完全重建时，他们对解决方案失去了很多信心。

在这一点上，我意识到红帽对于想要处于前沿/前沿的开发人员来说进展得太慢了。RHEL 6.x 是一个急需且受欢迎的升级，但是当我开始采访订阅DevOps 原则的初创公司和公司后，这个主题变得更加明显。

今天……
越来越多的开发人员和 L​​inux 用户来自非 Red Hat、非 SuSE、非企业 Linux 环境。

• 他们正在使用 Ubuntu 或 Debian...
• 他们不必处理老式硬件或大型供应商的支持。
• 他们正在从头开始编写自己的应用程序（自给自足）。
• 虚拟化和云计算抽象了硬件层，因此对时髦的 RAID 控制器驱动程序、PCI-X 外围设备或二进制分布式管理代理的担忧甚至不在雷达上。
• 这些用户想要他们习惯的工具和用户空间。

所以存在冲突......这些用户不明白为什么他们会受到应用程序或库版本的限制。老派的管理者仍在适应新的范式。似乎植根于宗教的论点实际上只是人们如何发展各自技能的函数。

我今天看到一个非常高级的 DevOps Linux 工程师职位的招聘广告，内容如下：

必须精通基于 Debian 的 Linux 发行版（Ubuntu 和变体可以。Red Hat可通过，但不是首选）

所以我想它是双向的……我已经放弃了工作机会，因为我将管理的 800 台 CentOS 服务器计划转换为 Ubuntu。当然，Linux 就是 Linux……但我不认为我会像我能达到的那样有效……我在 Debian 安装方面摸索着，并希望使用基于 RPM 的发行版。我对各种平台的优点有过激烈的争论（通常将 Gentoo 放在列表的底部）。

那么什么适合您的环境呢？这取决于。我曾在系统工程师推动决策的公司以及开发人员为王的组织中工作过。我认为最好的安排是开发人员和支持系统的人员就平台达成一致。但除此之外，请考虑长期支持、可用性、社区以及以最合适的方式容纳您的应用程序堆栈的内容。

一个有才华的开发人员应该能够在类似 RHEL 或类似 Debian 的环境中工作。好吧，开发平台应该反映生产环境。你从那里走...

Answer 2

我目前在一个使用 Linux 十多年的环境中工作。办公室里的每个人都在他们的桌面和服务器上使用不同的发行版。因此，分布的选择往往围绕着许多没有特定顺序的事情：

1. 历史- 显然，像 RedHat 和 Debian 这样的系统已经存在很长时间了。因此，格言“如果它没有坏，就不要修理它”可以用于这些。如果软件在发行版上得到很好的支持，升级会变得更容易。
2. 熟悉- 类似于历史，但我们都有自己的最爱。我开始学习 Debian，然后迁移到 Ubuntu（当时这是一个艰难的决定，因为我倾向于致力于社区）。相反，必须记住如何在十几个不同的发行版（更不用说从头构建的发行版）上做事是一件痛苦的事。
3. 支持- 我迁移到 Ubuntu 主要是因为我很欣赏他们在提供付费支持方面所做的工作。如果客户担心长期运行系统，这就是一个卖点。类似于 RedHat 的方法（但 RPM 地狱当时正在发生）。出于这个原因，我们也有许多 RedHat 服务器。
4. 依赖- 一些软件在一些发行版上更容易使用，仅仅是因为依赖包更容易获得或构建。RedHat 上的 oVirt 就是一个例子。某些发行版上没有某些软件的软件包。你可以编译它，但是如果这个包就在另一个发行版上，你为什么要编译呢？
5. 粒度- 像 Gentoo 这样的发行版提供了对版本控制和软件切换粒度的更好控制。其他发行版具有各种形式的“固定”，但这仍然不那么可控或可靠。
6. 绑定- 虽然可以在大多数发行版上从源代码编译，但有些发行版比其他发行版更擅长。例如，如果您的项目为扩展功能修补现有库，这可能会产生影响。
7. 漂亮- 一些发行版只是更好看。每个极客都知道它只是一团糟（现在你可能可以把它作为一个网络应用程序来做），但一些客户对这些东西感到惊叹，我们都知道这一点。
8. 稳定性- 一些发行版流传输“稳定”版本的软件，而不是“测试”、“实验”等。如果您知道正在构建的版本最终会就稳定性达成共识，这可能意味着很多。您可能会在“实验性”上进行开发，因为您知道当您的项目完成时，它已达到“稳定”并且可以很好地依赖。
9. 包管理- 如果您每天都在开发一些东西，并且一击就会在 1000 台机器上运行，那么您可能想要一些可以轻松地跨这些系统构建、维护和跟踪包的东西。
10. 一致性- 这更像是同一发行版的论据。当人们可以专注于一个发行版而不是多个发行版时，会犯更少的错误（以及更少的安全错误）。
11. 可预测的发布时间表- 如果您想确保您的软件得到支持，计划升级会提供某种类型的稳定性。
12. 安全- 一些发行版有活跃的安全团队，他们的工作是立即响应任何批准包中的真正安全风险。

关于选择每个系统的原因，这些只是我脑海中浮现的几件事。在这个决定中，我没有看到任何一个指路明灯或一个发行版优于另一个发行版。多样性和选择可能很棒，并为您提供了一些非常好的选择来快速启动项目，但它也是可能让您陷入困境的套索。确保你提前考虑你需要什么。计划系统的需求以及系统升级或退役的时间。不要假设您将永远是维护它的人。