发行版对标准采取立场
鉴于最近关于标准化和 Linux 标准未来的辩论，人们自然会想知道主要的 Linux 发行版和其他关键行业参与者对此问题的立场。因此，为了 выяснить，Linux Journal 提出了以下问题：“贵组织对 Linux 标准以及日益增长的标准化问题持何种立场？” 我们收到了来自主要供应商的一些非常有趣的回复，长度差异很大。以下是他们的回复，排名不分先后。
我们 Red Hat 通常赞成良好的标准，这些标准能够解决现有问题以及未来问题。历史表明，遵守标准可能非常重要，不这样做可能会导致碎片化，从而为所有参与者带来非常不健康的局面。我们尽力确保我们遵守有用的标准，例如 FHS（文件系统层次结构标准）。
Linux 的新标准正在不断发展，我们正在努力成为这一发展的一部分。标准对于保持所有 Linux 发行版之间的兼容性非常重要。兼容性对于防止独立软件供应商 (ISV) 将 Linux 视为无法支持的碎片化混乱局面至关重要。ISV 很重要，因为他们为 Linux 带来了应用程序。应用程序很重要，因为它们为 Linux 带来了用户。正如您所见，这是一个具有重大影响的涓滴效应。
话虽如此，我们正在努力确保不断发展的标准是好的标准。糟糕的标准也可能非常有害。到目前为止，Linux 社区在制定良好标准方面做得非常好。凭借所有参与者的负责任的社区努力，我完全相信 Linux 社区可以保持这一趋势。如果是这样，您可以期望 Red Hat 完全参与制定的标准。
感谢您提供机会回应 Caldera Systems 对 Linux 标准库 (LSB) 的看法。每个人可能对他们认为 LSB 是什么以及它应该是什么有稍微不同的定义。我将冒昧地告诉您我认为它应该是什么。LSB 的主要目标应该是解决商业 ISV 面临的问题。LSB 应该是一项努力，使商业软件开发人员能够一次移植，并使其应用程序在所有主要的 Linux 发行版上运行。如果它不能解决这个问题，Linux 在不久的将来将面临重大问题。几乎我们与之交谈过的每家 ISV 都希望保持“发行版不可知”，但他们不想支持四个或更多版本来适应 Linux。目前的答案似乎是以下三种选择之一：发布应用程序的源代码并允许社区支持不同的版本，选择一个内核版本和一个库版本并允许 Linux 提供商提供补丁，或者只选择一个发行版来支持。
我将解决所有这三种想法的问题。首先，发布应用程序的源代码。这在某些情况下有效，但在大多数情况下无效。其中一些行业参与者在专有软件和硬件上投入了数百万甚至数十亿美元，这不允许他们发布其解决方案。他们现在和将来都会继续支持 Linux 和开源工作，但他们的董事会、律师和股东现在不允许他们发布源代码，并且可能永远不允许。发布源代码会带来重大责任。Netscape 发布了浏览器源代码，只是将其外包给另一家公司。发布源代码必须经过认真的思考和考虑后才能完成。
至于允许 ISV 选择内核和库版本的第二种选择，如果 Oracle 选择一个版本，而 Informix 选择另一个版本怎么办？或者如果 Corel 和 Oracle 选择不同的版本，而客户无法在不搜索互联网查找补丁的情况下运行其中一个解决方案怎么办？当微软声称自己是一站式商店时，Linux 将如何与微软竞争？商业客户会蒙受损失，因为他必须知道如何在互联网上找到补丁和修复程序。即使是 VAR 和系统集成商，即使他们技术足够，也无法负担花费时间。
第三个选择是仅移植到一个发行版。这似乎与相信选择的 Linux 和开源社区背道而驰。但是，有些人会支持此选项来解决问题。仅移植到一个发行版的主要担忧是，您会错失其他人针对不同市场进行的创新。一些领先的发行版已将开发人员作为主要客户，因为到目前为止，开发人员已占购买 Linux 的大多数。诸如上市时间之类的功能对开发人员至关重要。软件包是从互联网上许多不同的来源收集的，以确保数量和交付的及时性，而很少关注确保源代码和二进制文件匹配。毕竟，开发人员知道如何使其工作。
商业关注点每年不能处理超过两个版本，因此上市时间不是一项功能，而是一项责任。Caldera Systems 从成立之初就一直专注于商业或商业市场，并在发行版中构建了诸如自托管之类的功能。自托管是将所有源代码与二进制文件匹配的规则。它允许商业实体为整个发行版设置所有编译参数，从而最大限度地提高性能和支持选项，同时限制安全性和责任问题。所有软件包都作为一个整体进行测试和集成。专注于开发人员的发行版可能会选择花费时间添加更多仅对开发人员有吸引力的软件包，或者在技术稳定之前发布技术，以便开发人员更容易访问它。最重要的是，如果将单个发行版用作参考平台，Linux 社区和商业客户将失去选择权和选择。一些 ISV 可能会选择一个，而另一些 ISV 可能会选择另一个。唯一的真正答案是 Linux 社区和当前的 Linux 提供商进行协作。
如果 Linux 和整个开源社区保持开放的心态，他们将有很大的机会成为商业环境中的重要参与者。如果 Linux 和开源社区可以使商业参与者更容易地与开源互动，而不会产生法律责任或重大成本，那么 Linux 将成为重要的参与者，客户将获胜。
LSB 可以是朝着解决此问题迈出的重要一步，并向行业表明 Linux 是与众不同的，不仅因为它是在开源许可下发布的，还因为其提供商具有远见。如果主要的 Linux 发行版提供商可以协作并支持通用的内核和库版本以及基本接口，使 ISV 可以一次移植到 Linux 并支持所有 Linux 提供商，那么每个人都将获胜。如果 Linux 提供商不负责任并且选择不合作而继续推行自己的议程，那么 Linux 不太可能碎片化，但将大大低于其成为行业中主要的计算平台（无论是开源还是其他平台）的潜力。
Linux 不太可能像其表兄弟 UNIX 在 OSF/UNIX International 灾难中所做的那样碎片化，因为它是开源的。但是，开源也不能完全解决问题。最佳开源技术总是获胜的前提是不成立的。GNOME 和 KDE 是典型的例子。KDE 是一项出色的技术，其成熟速度快于 GNOME。启动 GNOME 的主要原因是 KDE 依赖的 Qt 库不是开源的。由于 Troll Tech 现在已根据公认的开源许可发布了这些库，因此对 KDE 的所有担忧都应该结束了。相反，一场重要的公关活动已经开始，以继续传播关于 KDE 的不确定性和怀疑。从技术上讲，它在所有情况下都优于 GNOME，并且更加成熟。为什么有人会坚持宣传关于 KDE 的虚假信息？因为他们在 GNOME 上投入了时间、金钱和精力，而 KDE 开发人员没有资金反击。再次，开源社区也无法免受万能美元的影响。
显然，如果 Linux 要充分发挥其作为主要行业替代品的潜力，我们不能仅仅依靠开源。所有行业参与者都必须负责任地行事。Caldera Systems 一直希望 Linux 成为可行的商业替代品，因此我们认为唯一的真正答案是支持 LSB。
Pacific HiTech 将在 Linux 标准的开发中发挥积极作用，并将遵守已采用的标准作为我们所有 Linux 产品的设计目标。我们认为，一套定义明确的 Linux 标准非常重要，这样 ISV 可以更轻松地将其应用程序移植到 Linux 操作系统，而无需担心发行版兼容性。
我希望看到它们发展到任何兼容的发行版都将具有相同的共享库可用性和相同的基本文件系统结构的程度。有些人建议标准软件包管理器也很重要，但我不太确定这是否是真的——例如，.deb 和 .rpm 都可以提供一个系统，在该系统中，给定的第三方应用程序可以工作，前提是共享库和路径结构相同。我 希望 看到的是一个通用的应用程序“注册”系统，以便桌面管理器和其他程序可以有一种标准方法来确定系统上安装了什么。
Slackware 正在等待查看提议的标准是什么，然后再承诺完全遵守，但我确实认为这项努力是 Linux 朝着正确方向迈出的一步。我真的很想看到一个标准版本号列表，以便在构建共享库时使用——这应该是使发行版之间的二进制兼容性重回正轨的简单第一步。但是，标准可能不应过于详细，以至于所有发行版最终看起来都像是从同一个饼干模具中切出来的。正是不同的设计理念使不同的 Linux 发行版对不同类型的用户具有吸引力。看看这些问题如何平衡将会很有趣。
Debian 的总体立场是标准化是一件好事。Dale Scheetz 是 Debian 开发人员，并积极参与 LSB 工作。LSB 也是 SPI 支持的项目。随着 Linux 的不断发展，对于生产软件的供应商来说，知道它将在许多不同的发行版上运行而无需特定于发行版的版本将变得越来越重要。应用程序被移植到 Linux 上将极大地帮助 Linux 的发展，这种发展必须尽可能地得到支持。
Debian 从一开始就参与了 LSB 项目。我们的一位开发人员 Dale Scheetz 现在正在从事 LSB 工作。自 LSB 之前我们就一直在与 Red Hat 讨论，以便我们可以在发行版之间开发二进制兼容性。重要的系统库应该在所有发行版之间完全兼容。我们不希望看到用户升级到 32 位 MS Windows 时 16 位 MS Windows 软件遭受的那种不兼容性。Debian 目前正在努力采用文件层次结构系统，但我们认为仍有一些问题需要解决。Debian 很高兴帮助创建标准并与其他发行版兼容；LSB 是我们用来实现这一目标的方法之一。
SuSE 自 1992 年以来一直是 Linux 社区的成员，我们有专门的人员致力于 LSB 项目并为此工作。我们很自豪成为该项目的积极成员。我们希望看到某种最低限度的库标准，因为这是我们的客户想要的。ISV 需要这种标准才能有效地工作。硬件供应商应该有一个标准，以便跨发行版认证他们的硬件。
我个人认为标准化是一件好事。但与往常一样，好事过头也可能会变成坏事。这实际上完全取决于您要标准化 Linux 系统的哪个方面，以及标准化多少。您从哪里开始，又在哪里停止？如果我们标准化文件系统布局、打包和用户工具，还会剩下什么？我不确定 LSB 的计划——但从我的阅读来看，他们似乎还没有制定完善的计划。标准化文件位置是一个好主意；我知道这将解决我遇到的一半问题。我在某处读到 LSB 计划拥有一个标准的打包系统。对我个人来说，这是一个棘手的话题，甚至难以评论——我们对我们的 Stampede Linux 打包系统 (SLP) 有很多计划。标准可能不包含我们想要拥有的一些功能。显然，我们可以自己为项目做出贡献，但如果大多数人不喜欢我们的想法，那么它就不会被采纳。Linux 最棒的地方在于，如果您不喜欢某件事，您就无法抱怨。不要使用它，寻找其他东西，破解源代码，或启动一个全新的项目。如果出现这种情况，想要某个功能的用户将无法再搜索其他软件包；他必须尝试以某种方式说服作者添加它。
目前，两种极端情况很明显：一种是“每个人都做自己的事情，以自己的方式”，另一种是“每个人都按照标准说的做”。我想我们现在不处于这两种极端情况中的任何一种。需要在两者之间找到一条细线，当有人找到它时，我才能进一步评论。
目前，根据我们掌握的信息，Stampede 的立场是中立的，但这很容易改变。它可能会在明天、下周、下个月或明年改变（就像任何与 Linux 相关的项目一样）。目前，我将尝试密切关注正在发生的事情，并让 Stampede 开发团队的其他成员了解情况。一旦制定了一套明确的规则，就更容易做出决定。
