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

#1 楼

我目前在使用Linux已有十多年的环境中工作。办公室中的每个人都在台式机和服务器上使用不同的发行版。因此，发行版的选择往往围绕着许多事物而没有特定顺序：



历史-显然，像RedHat和Debian这样的系统已经存在了很长时间时间。因此，“如果没有破裂，就不要修复”这句格言可以用于这些。如果在发行版中很好地支持该软件，则升级将变得更加容易。

熟悉-与历史类似，但是我们都有自己的最爱。我不屑一顾Debian，然后迁移到Ubuntu（这是一个艰难的决定，因为我倾向于致力于社区）。相反，必须记住如何在十二个不同发行版上做事（更不用说从头开始构建的发行版了）是一件很痛苦的事情。

支持-我迁移到Ubuntu的主要原因是我很欣赏它们尽力提供有偿支持。如果客户担心长期运行系统，那将是一个卖点。与RedHat的方法类似（但当时RPM一直在发生）。出于这个原因，我们也有许多RedHat服务器。

依赖关系-某些软件更易于在某些发行版中使用，只是因为依赖的软件包更易于获得或构建。例如，RedHat上的oVirt。在某些发行版中，没有针对某些软件的软件包。您可以编译它，但是如果该软件包位于另一个发行版中，为什么还要这么做？

粒度-像Gentoo这样的发行版可以更好地控制版本控制和软件切换粒度。其他发行版具有各种形式的“固定”，但是仍然不那么可控或可靠。

绑定-虽然大多数发行版都可以从源代码进行编译，但是某些发行版比其他发行版要好。例如，如果您的项目为扩展功能修补了现有库，则会产生影响。

漂亮-一些发行版看上去更好。每个极客都知道这只是毛茸茸的（这些天您可能会做为Web应用程序而逃脱），但是有些客户对此东西感到惊讶，我们都知道。

稳定性-一些发行版流“稳定”版本的软件，而不是“测试”，“实验性”等。这可能意味着如果您知道所构建的版本最终将在稳定性方面达成共识，则可能意味着很多。您可能会在“实验性”的基础上进行开发，因为您知道到项目完成时它将达到“稳定”状态并值得信赖。

包装管理-如果您每天都在开发某些东西的基础上，一击就可以淘汰数千台计算机，那么您可能想要使它们能够轻松构建，维护和跟踪这些系统中的软件包的东西。

一致性-这是更多同一发行版的论点。当人们可以将注意力集中在一个发行版而不是多个发行版上时，更少的错误发生（和更少的安全性错误）。

可预测的发布时间表-如果要确保您的软件始终受支持，可以计划升级某种类型的稳定性。

安全性-一些发行版具有活跃的安全团队，其职责是立即对任何批准的软件包中的真实安全风险做出响应。

关于选择每个系统的原因，这些只是我想到的几件事。在此决定中，我看不到有人会指导或偏爱另一个发行版。多样性和选择可能很棒，并为您提供了一些非常好的选择来使项目快速启动，但这也是使您垂涎的绞索。确保您提前考虑了所需。计划系统的需求以及何时升级或淘汰系统。不要以为自己永远是维护它的人。

#2 楼

我将在几个不同的领域分享我作为技术专家的经历...（警告：这是一个有关Red Hat的故事，以及我如何专业成长）

我从2000-2002年开始专业从事Linux工作。这是在Red Hat和Red Hat Professional Edition（6.x，7.x，8.0）的广泛采用期间。这些都可以免费下载，也可以打包下载。它们很容易在计算机零售商店中找到。

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

节省大量成本！用4万美元的Compaq ProLiant英特尔服务器替换10万美元以上的HP9000 PA-RISC服务器绝对是成本和性能上的胜利。

那么，为什么要使用Red Hat？

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

至此，我负责Linux发行版的开发和评估，该发行版是专有ERP软件解决方案的平台。我坚持使用红帽。每隔一段时间，我会尝试另一个发行版（Mandrake，SuSE，Debian，Gentoo），但是会发现包装，硬件支持（服务器或外围设备），社区的（规模）或其他一些破坏交易的问题。 br />
一个例子：我使用的是配备有Digi Serial扩展PCI-X卡和Esker VSIfax生产传真软件的Compaq / HP ProLiant硬件。后两个仅对Red Hat操作系统提供驱动程序支持。在某些情况下，软件仅以二进制或RPM形式提供，这妨碍了在其他Linux变体上的易于使用。

信息技术世界中的动因很重要没人愿意成为一个推荐失败的解决方案或项目的人成为孤儿，因此您要坚持安全的选择。我当时正在管理一个技术堆栈，该堆栈需要可靠地工作并且需要多层支持。此时选择另一种分布将是正确的。是。不负责任。


Red Hat蜜月之旅于2003年对我结束，因为该软件的专业版本停止了。红帽企业版Linux取代了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 Realtime内核。我注意到发布时需要做的工作... Vanilla kernel.org内核有200多个补丁。阅读评论并提交注释。您可能有一些小问题，例如暴露了sysctl参数或应用了更多理智的默认设置。红帽公司需要人们来修补，测试和修复这些问题。我没有从其他Linux发行版中看到相同的承诺...再加上事实证明，企业平台多年来一直具有真正的安全性，错误修复和反向支持。


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

但是有一个问题...我的开发人员习惯了Gentoo，并拥有相对容易的核心库和应用程序版本升级路径。他们无法适应使用Red Hat Enterprise Linux标准化的固定主要版本。在开发和发布过程中遇到了以下问题：为什么无法将GLIBC 2.7移植到RHEL 5.x上，或者为什么某些编译器或库版本不可用。当被告知在主要版本的RHEL / CentOS之间进行升级本质上需要完全重建时，他们对解决方案失去了很大的信心。

至此，我意识到Red Hat对于开发人员来说进展太慢了。谁想要在流血/前沿。 RHEL 6.x是急需的升级版本，但是当我开始采访那些遵循DevOps原则的初创公司和公司时，这个主题就变得更加明显。


如今...越来越多的开发人员和Linux用户来自非Red Hat，非SuSE，非企业Linux环境。


他们正在使用Ubuntu或Debian ...
他们不必处理老式硬件或大型供应商的支持。
他们正在从头开始编写自己的应用程序（自费）。
虚拟化和云计算将硬件层抽象化，因此不必担心时髦的RAID控制器驱动程序，PCI-X外设或二进制分布式管理代理。
这些用户需要他们习惯的工具和用户环境。

因此存在冲突...这些用户不理解为什么要限制应用程序或库版本。老派管理人员仍在适应新范式。似乎扎根于宗教的论点实际上只是人们如何发展各自技能的功能。

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


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


所以我想它可以同时使用...我已经放弃了工作机会，因为我打算管理的800台CentOS服务器将被转换为Ubuntu。当然，Linux是Linux ...但是我不认为自己会像以前那样有效...我对Debian安装感到迷惑不解，希望使用基于RPM的发行版。我对各种平台的优缺点有激烈的争论（通常将Gentoo放在列表的底部）。

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

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