Linux 标准的过去与未来
尽管标准因其容易引起混乱而恶名昭著，但它们却是 Linux 成功背后的推动因素之一。 如果没有 Linus Torvalds 和其他开发者采用正确的标准，Linux 很可能只是操作系统历史上的一个小注脚。
有些人认为对 Linux 标准的兴趣是最近才出现的，是商业兴趣高涨促成的。 然而，早在 Linux 被命名之前，符合开放标准就是一个重要的目标。 以下是 Linus Torvalds 关于一个很快被命名为 Linux 的项目的最早帖子之一
From: torvalds@klaava.Helsinki.FI
(Linus Benedict Torvalds)
Newsgroups: comp.os.minix
Subject: Gcc-1.40 and a POSIX-question
Date: 3 Jul 91 10:00:50 GMT
Due to a project I'm working on (in minix),
I'm interested in the POSIX standard definition.
Could somebody please point me to a (preferably)
machine-readable format of the latest POSIX rules?
FTP sites would be nice.
一个月后，Linus 发布了
As to POSIX, I'd be delighted to have it, but POSIX wants money for their papers, so that's not currently an option.尽管 1991 年 POSIX 标准的副本价格昂贵，但它还是成为了 Linux 的主要标准之一。 POSIX，即可移植操作系统接口，是 Linux 和许多其他操作系统（通常是 UNIX 和类 UNIX 系统）使用的标准应用程序编程接口 (API)。 使用 POSIX 定义的接口有几个主要好处。 它使编写可以在不同的 POSIX 系统上编译的源代码变得更容易。 它还为 Linux 应用程序开发者和 Linux 内核开发者提供了一个明确定义的 API 来共享。 这意味着只要内核继续按照 POSIX 的规定运行，应用程序开发者就不需要跟踪大多数内核更改。
此外，使用 POSIX 作为 Linux 的 API 使 Linus 和其他早期的 Linux 开发者能够使用 GNU 项目、BSD 操作系统和许多其他符合 POSIX 规范的免费程序编写的现有免费程序。
重要的是要注意，POSIX 不支持在任何 POSIX 操作系统上运行预编译的二进制应用程序。 由于它提供源代码兼容性，但不提供二进制兼容性，POSIX 通常被认为是源代码标准。 Linux 的早期开发是在 Minix 操作系统下进行的。 事实上，Linus 最初希望使 Linux 与 Minix 二进制兼容。 当 Linux 和 Minix 之间的差异变得太大时，这个想法被放弃了，但 Linux 的 Minix 传承的一些痕迹仍然零星地存在。
当被问及 POSIX 在早期 Linux 开发中的重要性时，Linus Torvalds 说：“Linux 最初非常关注 POSIX，但更关注非官方的实际标准。” 他详细解释说，当时，这些事实上的标准大约是 SunOS（Solaris 的前身）的行为，介于 BSD 和 System V 之间。 “基本上，我不想花太多时间移植用户模式程序（这不是我特别感兴趣的事情），而 POSIX 在这方面有所帮助，” Torvalds 说。
POSIX.1（POSIX 内核接口）仍然被 Linus Torvalds 和其他内核开发者认为是内核的“基本标准”。 POSIX 规范的一些后续添加不如 POSIX.1 有用，并且在 Linux 可以使用标准之前，通常需要解决设计问题。 Linus 描述了这样一个设计决策的最佳示例之一
通常有些标准过于通用，无法作为内核的指导。 “pthreads” POSIX 线程标准就是一个例子：有些人试图根据它来实现他们的内核线程模型，但该标准根本不太适合这样做。
即使在这种情况下，我仍然希望支持该标准； 我只是不想原生地按原样实现该标准。 因此创建了 Linux clone：在 Linux 下进行线程处理的基础设施，在此基础上您可以实现 pthreads 和其他线程模型。
很难列出 Linux 今天使用的所有其他标准。 TCP/IP、以太网和其他正式和事实上的标准构成了 Linux 中网络的基础。 IBM PC 是事实标准的最佳示例之一。（这个标准现在更加正式化了。）PC 允许成千上万，然后是数百万人在通常用于 Microsoft Windows 的系统上运行 Linux。 如果您在当时的标准硬件上运行，那么征服世界就容易得多。 同样重要的是，GNU C 编译器（没有它就不会有 Linux）是建立在 K&R（Kernigan & Ritchie）和 ANSI C 标准之上的。
除了像 POSIX 和 ANSI C 这样的正式标准之外，Linux 系统使用的最普遍的标准类型之一是通用实现。 最好的例子当然是 Linux 内核。 内核提供的许多接口都没有可用的书面规范。 但是，不需要规范，因为只有一种内核版本被所有人接受（不仅仅是所有发行版或所有开发者，而是真正的所有人）。 想知道标准吗？ 阅读内核源代码。
虽然并非总是那么清晰，但整个 Linux 社区，或至少很大一部分人，接受了更多通用实现标准的例子。 以 GNU 项目提供的实用程序和程序为例。 例如，长期以来，人们都接受实用程序 find 是增强的 GNU 版本，而不是 BSD 版本或其他版本。 如果您只为 Linux 编写应用程序，那么依赖 GNU find 提供的大部分功能可能是安全的。 因为使用了如此多的 GNU 实用程序，GNU 项目的创始人 Richard Stallman 坚持人们将 Linux 称为“GNU/Linux”或“基于 Linux 的 GNU 系统”。 这往往会让很多人感到不安，但大多数开发者似乎都认识到 Stallman 的巨大贡献，并且对此并不大惊小怪，即使他们中的大多数人仍然说“Linux”。
GNU 项目在 Linux 成功中的份额并未止步于此。 Linux 现在已经将 GNU C 库 (glibc) 标准化为未来 Linux 系统的通用实现。 glibc 项目的目标是遵守多项标准。 据 GNU libc 维护者 Ulrich Drepper 称，只要它们不与常识冲突，所有重要标准都将得到支持。 该列表包括 ISO C 90、ISO C 9x、POSIX 和 UNIX 98。
如果没有通用实现、正式标准，甚至是非正式、事实上的或临时的标准怎么办？ 您可以做的一件事是尝试挑选最佳和最常见的实践，并以此为基础制定标准。
文件系统层次标准 (FHS) 是首批专门为 Linux 开发的书面标准之一。 FHS 旨在标准化文件和目录在系统中的放置位置。 需要标准位置，以便应用程序可以在不同的 Linux 发行版上良好地编译和运行； 这对开发者也很有帮助。 如果您想为 Linux 编写文档，或者如果您需要在多个 Linux 版本上工作，那么知道您可以期望在标准位置找到重要的文件和目录是很有价值的。
如果您想知道为什么不能采用像 POSIX 这样的标准，原因是没有这样的标准。 每个 UNIX 供应商都有自己的解决方案，并且存在大量的重叠，但是每个供应商布局的规范和理由要么缺乏，要么不存在。 不幸的是，没有针对文件和目录标准布局的多供应商标准。
FHS 始于 1993 年。当时，Linux 操作系统大约有两年历史。 正如他今天所做的那样，Linus 规定了 Linux 内核中的工作方式，并且对 Linux 操作系统的其他领域没有施加太多影响。 由于这些其他领域没有中央权威机构，因此许多 Linux 发行版的布局差异很大。 有些像 BSD 操作系统，有些更像 SunOS，还有一些则完全不同。（顺便说一句，当时大多数大型发行版的名称与我们今天听到的名称不同：Debian、Linux/PRO、MCC、Slackware、SLS、TAMU、Yggdrasil 等。）
FHS 的第一个版本基于 SunOS 4、SVR4、4.3BSD、4.4BSD、SunOS 4、HP-UX 和许多其他 UNIX 系统的思想，但也尽可能基于从当时存在的各种 Linux 发行版中提炼出来的常见实践。 完成的规范试图吸取每个文件系统布局的优点，并将它们组合成一个运行良好的解决方案。
从那时起，后续版本的 FHS 一直是对原始规范的改进，从其他领域（包括 4.4BSD 和 SVR4）导入了一些额外的想法。
今天，大多数 Linux 发行版都遵循 FSSTND 1.2（FHS 2.0 的前身）。 他们这样做不是因为他们被迫这样做，而是因为它简洁地解决了他们遇到的问题。 FHS 2.1 应该在本文发表时可用。
用于 Linux 的第三方商业软件的广泛可用性是一个相对较新的现象。 许多供应商面临着他们以前从未见过的问题。
曾几何时，您的 Linux 机器上的所有软件通常都来自两个地方之一。 要么它随发行版一起提供，要么有人（您、朋友，甚至可能是系统管理员）从源代码编译并在本地安装了它。 发行版非常擅长集成软件并确保一切协同工作。 假设有人具备专业知识，即使是次标准的程序也可以编译并安装到您的 Linux 机器上。
如果其他人想给您一个预编译的二进制包以安装在您的系统上怎么办？ 他们必须考虑您运行哪个发行版、发行版的哪个版本、您的内核版本以及其他大量考虑因素，然后才能合理地确定应用程序将在您的系统上正确安装并运行。 如果目标是为每个人提供二进制包，情况会更糟。 您必须为任何和所有发行版定制应用程序，然后在每个发行版上编译、构建和测试它。 即使只有少数供应商支持其应用程序的三个或四个主要 Linux 发行版，这又有什么奇怪的呢？
关于 Linux 的更常见的担忧之一是，由于它使用开放开发模型，因此会发生碎片化。 就像在现实生活中一样，当事物分裂成许多不再连接的不同部分时，就会发生碎片化。 碎片化在自由软件社区中并不是一个新现象。 有时它会出于正当理由而发生，也许是当维护者没有做好工作时。 有时，它会因不太值得称赞的原因而发生，例如主要开发者之间的个性冲突。
这种情况以前发生过。 GNU Emacs 编辑器的图形化版本 XEmacs 由于 FSF 和 Lucid Emacs（XEmacs 的前身）的开发者之间的技术差异，从自由软件基金会 (FSF) 维护的版本中分离出来。 XEmacs 常见问题解答对这种情况持悲观态度
RMS [Richard Stallman] 和 XEmacs 开发团队之间在技术、编程、设计和组织事务方面的观点目前存在不可调和的差异，这使得短期内合并几乎没有希望。
如果您有关于合并的评论要添加，最好避免发布到新闻组，因为这通常会导致非常激烈的口水战。
当出现这样的分裂时，通常对最终用户的影响最大。 附加软件包适用于一种软件版本，但可能不适用于另一种软件版本。 这或多或少是 GNU Emacs 发生的情况，尽管开发者会尽力弥补它。
少量的碎片化（例如 Linux 发行版之间的差异）是好事，因为它允许它们迎合社区的不同部分。 因为 Linux 是开源的，所以不同的发行版可以自由地变得独一无二。 例如，Extreme Linux 发行版的目标是运行 Beowulf 集群软件的高性能 Linux PC 集群。 每个发行版都可以针对 Linux 社区的某个部分，并尝试比任何其他发行版更好地满足该部分的需求，而不是单一的一体化发行版。 用户受益于获得比单一发行版模式更符合他们需求的 Linux 发行版。
同样重要的是 Linux 社区对碎片化的态度。 每个人都担心碎片化可能会成为一个问题，并希望确保应用程序可以在任何 Linux 版本上运行。 这就是 Linux 标准库 (LSB) 的参与之处。 LSB 项目正在努力定义 Linux 的通用子集，每个人都可以依赖它，而与发行版无关。 通过仅定义在最小基本 Linux 系统中可以期望的内容，LSB 试图在扼杀 Linux 开发和 Linux 分裂成几个完全不兼容的版本之间找到平衡。
LSB 正在解决的主要问题是，软件供应商必须在多个 Linux 发行版上移植和测试他们的软件，因为即使发行版之间存在很小的差异，当供应商的软件基于一个发行版的行为时，也可能导致软件的重大问题。 这些困难最终会影响到每个人：用户、开发者、应用程序供应商、Linux 公司等等。
除了碎片化的危险（顺便说一句，在没有 LSB 的情况下，Linux 在过去八年中避免了碎片化）之外，还存在次要危险，即 FUD——恐惧、不确定性和怀疑。 LSB 希望通过使碎片化成为一种遥远的可能性，它将有助于增强信心，并赢得即使是最保守的部门对 Linux 的支持。 它将如何做到这一点？ Linux 标准库的目标如下
使软件应用程序能够在任何符合 LSB 的发行版上运行。
提高 Linux 发行版之间的兼容性。
帮助支持软件供应商和开发者为 Linux 移植和编写软件。
这些是 LSB 开发者想要做的事情。 另一方面，我们想避免一些事情。 我们的 LSB 成功指南包括
不要干涉发行版——每个人都希望它们是独一无二的。
所做的事情不要超过解决应用程序可移植性基本问题所需的事情。
不要破坏旧系统或阻止未来的进步。
对于 Linux 开发者来说，仅仅依靠 IEEE、The Open Group、ISO 和 ANSI 等外部组织制定的标准来发展是否足够？ 可能不够。 Linux 开发者已经能够选择采用哪些标准以及如何实施它们，但随着标准的修订和扩展，Linux 开发者希望确保未来的标准也能满足他们的需求。
正在进行中的一项修订是由 IEEE、The Open Group 和 ISO 对 POSIX 标准进行的联合修订。 修订该标准的组织称为奥斯汀小组。 与之前的 POSIX 标准不同，其目标是所有三个组织共享的一套通用文档。 USENIX，高级计算系统协会，正在帮助资助两名 Linux 开发者参加会议并参与修订。 这两位开发者是 glibc 维护者 Ulrich Drepper 和内核自动挂载器作者兼 Linux 设备列表维护者 H. Peter Anvin。 Ulrich 说，POSIX 修订将抛弃或至少使旧标准中一些不太需要的部分（例如 STREAMS）成为可选的。 这对 Linux 来说是一件好事，因为这些部分尚未被整个 Linux 社区采用。 结果是，更充分地遵守 POSIX 将变得更有可能。
此外，Ulrich 补充说，他希望看到新 POSIX 规范中标准化一些功能。 其中一些功能规范可能直接来自 glibc 项目。 如果这种情况发生，也许未来的操作系统可以将一些标准化责任归咎于 Linux。
