本文翻译自 The Biggest Myths，版权归原作者所有。这是 systemd 作者 2013 年 1 月的文章。
自我们首次提议将 systemd 纳入发行版以来，它在许多论坛、邮件列表和会议中被频繁讨论。在这些讨论中，人们经常听到一些关于 systemd 的误解，这些误解被一遍又一遍地重复，但不断的重复并不能增加其真实性。让我们花点时间来揭穿其中的一些：
误解：systemd 是单体的。
如果您在启用所有配置选项的情况下构建 systemd，您将构建 69 个独立的二进制文件。这些二进制文件都用于不同的任务，并且由于多种原因被清晰地分离开来。例如，我们设计 systemd 时考虑到了安全性，因此大多数守护进程以最低权限运行（例如，使用内核功能），并且只负责非常具体的任务，以最小化其安全表面和影响。此外，systemd 比任何先前的解决方案都更能并行化引导。这种并行化是通过并行运行更多进程来实现的。因此，将 systemd 很好地分解为许多二进制文件和进程至关重要。事实上，其中许多二进制文件1 被分离得如此之好，以至于它们在 systemd 之外也非常有用。
一个包含 69 个独立二进制文件的软件包很难被称为单体的。然而，与以前的解决方案不同的是，我们将更多的组件放在一个 tarball 中发布，并在一个具有统一发布周期的单一存储库中进行上游维护。
误解：systemd 只关乎速度。
是的，systemd 很快（有人要在约 900 毫秒内完成一个相当完整的用户空间启动吗？），但这主要只是做对事情的副作用。事实上，我们从未真正坐下来从 systemd 中榨取最后一点性能。相反，我们实际上经常故意选择稍慢的代码路径，以保持代码更具可读性。这并不意味着速度对我们来说无关紧要，但将 systemd 归结为速度肯定是一个相当大的误解，因为这肯定不在我们目标列表的前列。
误解：systemd 的快速启动与服务器无关。
这完全是错误的。许多管理员实际上热衷于在维护窗口期间减少停机时间。在高可用性设置中，如果发生故障的机器能够非常快地恢复，那就太好了。在具有大量虚拟机或容器的云设置中，慢速启动的代价会随着实例数量的增加而倍增。在数百个虚拟机或容器的非常慢的启动上花费数分钟的 CPU 和 IO 会大大降低系统的密度，哎呀，它甚至会花费您更多的能源。缓慢的启动在经济上可能相当昂贵。然后，容器的快速启动允许您实现诸如套接字激活容器之类的逻辑，从而使您能够大幅提高云系统的密度。
当然，在许多服务器设置中，启动确实无关紧要，但 systemd 应该涵盖整个范围。是的，我知道通常是服务器固件在启动时花费的时间最多，而操作系统无论如何都比它快，但是，systemd 仍然应该涵盖整个范围（见上文……），而且，并非所有服务器都有这么糟糕的固件，当然也不是虚拟机和容器，它们也是一种服务器。2
误解：systemd 与 shell 脚本不兼容。
这完全是胡说八道。我们只是不将它们用于引导过程，因为我们相信它们不是该特定用途的最佳工具，但这并不意味着 systemd 与它们不兼容。您可以轻松地将 shell 脚本作为 systemd 服务运行，哎呀，您可以将用任何语言编写的脚本作为 systemd 服务运行，systemd 丝毫不在乎您的可执行文件里面是什么。此外，我们为自己的目的大量使用 shell 脚本，用于安装、构建、测试 systemd。您可以将脚本放在早期引导过程中，将它们用于普通服务，可以在最终关闭时运行它们，几乎没有限制。
误解：systemd 很困难。
这也是完全无稽之谈。systemd 平台实际上比传统的 Linux 简单得多，因为它将系统对象及其依赖项统一为 systemd 单元。配置文件语言非常简单，我们摆脱了冗余的配置文件。我们为系统的许多配置提供统一的工具。该系统远没有传统 Linux 那样庞杂。我们还有非常全面的文档（主页链接），涵盖了 systemd 的几乎所有细节，这不仅包括面向管理员/用户的界面，还包括开发人员 API。
systemd 当然有学习曲线。任何东西都有。然而，我们愿意相信，对于大多数人来说，理解 systemd 实际上比理解基于 Shell 的引导更简单。我们这么说您感到惊讶吗？嗯，事实证明，Shell 不是一种容易学习的漂亮语言，它的语法晦涩而复杂。systemd 单元文件更容易理解，它们不公开编程语言，而是本质上简单且声明性的。话虽如此，如果您有 shell 经验，那么是的，采用 systemd 需要一些学习。
为了使学习变得容易，我们努力为以前的解决方案提供最大的兼容性。不仅如此，在许多发行版上，您会发现一些传统工具现在甚至会告诉您——在执行您所要求的操作时——如何使用更新的工具来代替，可能会以一种更友好的方式。
无论如何，要点可能是 systemd 可能是一个这样的系统所能达到的最简单的程度，我们努力使它易于学习。但是，是的，如果您了解 sysvinit，那么采用 systemd 将需要一些学习，但坦率地说，如果您掌握了 sysvinit，那么 systemd 对您来说应该很容易。
误解：systemd 不是模块化的。
完全不是真的。在编译时，您有许多
configure开关来选择要构建什么，不要构建什么。而且我们记录了如何更详细地选择您需要什么，超越了我们的配置开关。这种模块化与 Linux 内核的模块化并非完全不同，您可以在编译时单独选择许多功能。如果内核对您来说足够模块化，那么 systemd 也应该非常接近。
误解：systemd 只适用于桌面。
这当然不是真的。通过 systemd，我们试图涵盖与 Linux 本身几乎相同的范围。虽然我们关心桌面用途，但我们几乎同样关心服务器用途和嵌入式用途。您可以打赌，如果它不是管理服务器上服务的最佳选择，红帽不会让它成为 RHEL7 的核心部分。
来自众多公司的人们都在研究 systemd。汽车制造商将其内置于汽车中，红帽将其用于服务器操作系统，GNOME 使用其许多界面来改进桌面。您可以在玩具、太空望远镜和风力涡轮机中找到它。
我最近研究的大多数功能可能主要与服务器相关，例如容器支持、资源管理或安全功能。我们已经很好地涵盖了桌面系统，并且有许多公司正在为嵌入式进行 systemd 开发，有些甚至提供咨询服务。
误解：systemd 是 NIH 综合症的结果。
这不是真的。在我们开始研究 systemd 之前，我们一直在推动 Canonical 的 Upstart 被广泛采用（Fedora/RHEL 也曾使用过一段时间）。然而，我们最终得出的结论是，它的设计在其核心上存在固有的缺陷（至少在我们看来：最根本的是，它将依赖管理留给了管理员/开发人员，而不是在代码中解决这个难题），如果核心有问题，你最好更换它，而不是修复它。这几乎不是唯一的原因，其他因素也起了作用，比如围绕它的许可/贡献协议的混乱。不过，NIH 不是原因之一……3
误解：systemd 是一个 freedesktop.org 项目。
嗯，systemd 当然托管在 fdo，但 freedesktop.org 除了代码和文档的存储库之外几乎什么都不是。几乎任何编码员都可以在那里请求一个存储库并在那里转储他的东西（只要它与自由系统的基础设施有些相关）。没有阴谋集团，没有“标准化”方案，没有项目审查，什么都没有。它只是一个不错的、免费的、可靠的地方来存放您的存储库。在这方面，它有点像 SourceForge、github、kernel.org，只是不是商业性的，没有过高的要求，因此是存放我们东西的好地方。
所以，是的，我们将我们的东西托管在 fdo，但是这个神话中隐含的假设是，有一群人开会然后就未来自由系统的样子达成一致，这完全是胡说八道。
误解：systemd 不是 UNIX。
这当然有一定道理。systemd 的源代码不包含任何源自原始 UNIX 的代码。然而，我们从 UNIX 中汲取灵感，因此 systemd 中有大量的 UNIX。例如，UNIX 的“一切皆文件”的思想反映在 systemd 中，所有服务都在运行时在内核文件系统中公开，即
cgroupfs。然后，UNIX 的原始功能之一是基于内置终端支持的多席位支持。然而，文本终端几乎不是当今您与计算机交互的最新技术。通过 systemd，我们带回了原生的多席位支持，但这次完全支持当今的硬件，涵盖图形、鼠标、音频、网络摄像头等，并且所有这些都是全自动、支持热插拔且无需配置的。事实上，systemd 作为一套集成工具的设计，每个工具都有其各自的用途，但一起使用时不仅仅是各部分的总和，这几乎是 UNIX 哲学的核心。然后，我们处理项目的方式（即在单个 git 存储库中维护大部分核心操作系统）比 Linux 上的任何事情都更接近 BSD 模型（这是一个真正的 UNIX，不像 Linux）做事的方式（其中大部分核心操作系统都保存在单个 CVS/SVN 存储库中）。最终，UNIX 对每个人来说都是不同的东西。对于我们 systemd 维护者来说，它是我们汲取灵感的东西。对于其他人来说，它是一种宗教，就像其他世界宗教一样，对它有不同的解读和理解。有些人根据特定的代码遗产来定义 UNIX，有些人只将其视为一组思想，有些人将其视为一组命令或 API，甚至还有些人将其视为行为的定义。当然，要让所有这些人都满意是不可能的。
最终，某样东西是否是 UNIX 的问题无关紧要。技术卓越并非 UNIX 所独有。对我们来说，UNIX 是一个主要影响（哎呀，是最大的影响），但我们也有其他影响。因此，在某些领域，systemd 会非常 UNIXy，而在其他领域则会少一些。
误解：systemd 很复杂。
这当然有一定道理。现代计算机是复杂的野兽，因此运行在它上面的操作系统也必须复杂。然而，systemd 肯定不比相同组件的先前实现更复杂。更确切地说，它更简单，冗余更少（见上文）。此外，基于 systemd 构建一个简单的操作系统将涉及比传统 Linux 少得多的软件包。更少的软件包使构建系统更容易，摆脱了相互依赖关系以及所涉及的每个组件的许多不同行为。
误解：systemd 很臃肿。
嗯，臃肿当然有很多不同的定义。但在大多数定义中，systemd 可能与臃肿相反。由于 systemd 组件共享一个公共代码库，它们倾向于为公共代码路径共享更多的代码。举个例子：在传统的 Linux 设置中，sysvinit、start-stop-daemon、inetd、cron、dbus 都实现了一种方案，以各种配置选项在某个希望干净的环境中执行进程。在 systemd 上，所有这些的代码路径、配置解析以及实际执行都是共享的。这意味着更少的代码、更少的错误空间、更少的内存和缓存压力，因此是一件非常好的事情。而且作为副作用，您实际上为此获得了更多的功能……
如上所述，systemd 也非常模块化。您可以在构建时选择需要哪些组件，不需要哪些组件。因此，人们可以专门选择他们想要的“臃肿”程度。
当您构建 systemd 时，它只需要三个依赖项：glibc、libcap 和 dbus。就是这样。它可以使用更多的依赖项，但这些完全是可选的。
所以，是的，无论您怎么看，它真的不臃肿。
误解：systemd 仅限 Linux 对 BSD 不友好。
完全错误。BSD 的人们对 systemd 几乎不感兴趣。如果 systemd 是可移植的，这不会改变任何事情，他们仍然不会采用它。世界上其他 Unix 也是如此。Solaris 有 SMF，BSD 有他们自己的“rc”系统，他们总是独立于 Linux 来维护它。init 系统非常接近整个操作系统的核心。因此，这些其他操作系统除其他外，通过其核心用户空间来定义自己。假设如果我们只是让我们的核心用户空间可移植，他们就会采用它，这是完全没有任何根据的。
误解：systemd 仅限 Linux 使得 Debian 无法将其作为默认设置。
Debian 在其发行版中支持非 Linux 内核。systemd 将无法在这些内核上运行。但这有问题吗？这是否应该阻碍他们将 systemd 作为默认设置？并非如此。将 Debian 移植到这些其他内核的人们愿意投入时间进行大规模的移植工作，他们建立了测试和构建系统，并为他们的目标修补和构建了许多软件包。与此相比，为打包的服务维护 systemd 单元文件和经典的 init 脚本的工作量可以忽略不计，特别是因为这些脚本通常已经存在。
误解：如果 systemd 的维护者愿意，它可以被移植到其他内核。
这根本不是真的。将 systemd 移植到其他内核是不可行的。我们使用了太多的 Linux 特定接口。对于少数几个，可能会在其他内核上找到替代品，某些功能可能需要关闭，但对于大多数来说，这并非真正可能。这里有一个小的、非常不全面的列表：cgroups、fanotify、umount2()、/proc/self/mountinfo（包括通知）、/dev/swaps（相同）、udev、netlink、/sys 的结构、/proc/$PID/comm、/proc/$PID/cmdline、/proc/$PID/loginuid、/proc/$PID/stat、/proc/$PID/session、/proc/$PID/exe、/proc/$PID/fd、tmpfs、devtmpfs、功能、各种命名空间、各种 prctl()、许多 ioctl()、mount() 系统调用及其语义、selinux、audit、inotify、statfs、O_DIRECTORY、O_NOATIME、/proc/$PID/root、waitid()、SCM_CREDENTIALS、SCM_RIGHTS、mkostemp()、/dev/input、…
不，如果您查看此列表并挑选出少数您能想到的在其他内核上有明显对应物的，那么请再想一想，看看您没有挑选的其他部分，以及替换它们的复杂性。
误解：systemd 无缘无故地不可移植。
胡说八道！我们使用 Linux 特定的功能，因为我们需要它来实现我们想要的功能。Linux 有许多 UNIX/POSIX 没有的功能，我们希望通过它们赋予用户权力。这些功能非常有用，但前提是它们以友好的方式向用户公开，而这正是我们通过 systemd 所做的。
误解：systemd 使用二进制配置文件。
不知道是谁想出了这个疯狂的误解，但这绝对不是真的。systemd 的配置几乎完全通过简单的文本文件进行。一些设置您也可以通过内核命令行和环境变量来更改。它的配置中没有任何二进制内容（甚至没有 XML）。只是纯粹、简单、易于阅读的文本文件。
误解：systemd 是一个功能蔓延。
嗯，systemd 当然涵盖了比以前更多的领域。它不再仅仅是一个 init 系统，而是构建操作系统的基本用户空间构建块，但我们仔细确保大部分功能都是可选的。您可以在编译时关闭很多功能，在运行时甚至可以关闭更多。因此，您可以自由选择您想要的功能蔓延程度。
误解：systemd 强迫你做某事。
systemd 不是黑手党。它是自由软件，你可以用它做任何你想做的事，包括不使用它。这与“强迫”几乎相反。
误解：systemd 使得无法运行 syslog。
不是真的，我们在引入日志时仔细确保所有数据也会传递给任何正在运行的 syslog 守护进程。事实上，如果有什么变化，那也只是 syslog 现在比以前获得了更完整的数据，因为我们现在涵盖了早期引导内容以及任何系统服务的 STDOUT/STDERR。
误解：systemd 不兼容。
我们非常努力地提供与 sysvinit 的最佳兼容性。事实上，绝大多数 init 脚本在 systemd 上应该可以正常工作，无需修改。然而，确实存在一些不兼容性，但我们试图记录这些并解释如何处理它们。最终，任何实际上不是 sysvinit 本身的系统都会与它存在一定程度的不兼容性，因为它不会共享完全相同的代码路径。
我们的目标是确保不同发行版之间的差异保持在最低限度。这意味着单元文件通常在与您编写它的不同发行版上也能正常工作，这与传统的 init 脚本相比是一个巨大的进步，传统的 init 脚本很难以在多个 Linux 发行版上运行的方式编写，因为它们之间存在许多不兼容性。
误解：systemd 不可编写脚本，因为它使用 D-Bus。
不是真的。systemd 提供的几乎每个 D-Bus 接口也都在命令行工具中可用，例如在 systemctl、loginctl、timedatectl、hostnamectl、localectl 等中。您可以轻松地从 shell 脚本中调用这些工具，它们通过易于使用的命令从命令行打开了几乎整个 API。
话虽如此，D-Bus 实际上有几乎这个世界所知的所有脚本语言的绑定。即使从 shell 中，您也可以使用 dbus-send 或 gdbus 调用任意 D-Bus 方法。如果说有什么不同的话，那就是由于 D-Bus 在各种脚本语言中的良好支持，这提高了可编写脚本性。
误解：systemd 要求您使用一些晦涩的配置工具，而不是允许您直接编辑配置文件。
完全不是真的。我们提供了一些配置工具，使用它们可以获得一些额外的功能（例如，所有设置的命令行补全！），但完全没有必要使用它们。如果您愿意，您可以随时直接编辑相关文件，这是完全支持的。当然，有时您需要在编辑配置后显式重新加载某些守护进程的配置，但这对于大多数 UNIX 服务来说都是如此。
误解：systemd 不稳定且充满错误。
根据我们的数据，当然不是。我们长期以来一直密切关注 Fedora 错误跟踪器（以及其他一些）。对于这样一个操作系统的核心组件来说，错误的数量非常少，特别是如果您不计算我们为项目跟踪的众多 RFE 错误。我们在将 systemd 排除在发行版的阻止程序错误列表之外方面做得很好。我们有一个相对较快的开发周期，主要是增量更改，以保持高质量和稳定性。
误解：systemd 无法调试。
错误。有些人试图暗示 shell 是一个很好的调试器。嗯，它真的不是。在 systemd 中，我们为您提供了实际的调试功能。例如：交互式调试、详细跟踪、在引导期间屏蔽任何组件的能力等等。此外，我们还为其提供了文档。
它当然是很好调试的，毕竟我们自己的开发工作也需要它。但我们承认一点：它使用不同的调试工具，我们相信这些工具更适合其目的。
误解：systemd 为了改变而改变。
非常不真实。我们所做的更改几乎完全有技术原因，我们在各种文档、维基页面、博客文章、邮件列表公告中解释了这些原因。我们努力避免进行不兼容的更改，如果我们这样做了，我们会尝试详细记录原因和方式。如果您对某件事感到好奇，请尽管问我们！
误解：systemd 是一个仅限 Red Hat 的项目，是一些自作聪明的开发人员的私有财产，他们用它来向世界推销自己的观点。
不正确。目前，有 16 位黑客拥有对 systemd git 树的提交权限。在这 16 人中，只有 6 人受雇于 Red Hat。其他 10 人来自 ArchLinux、Debian、Intel，甚至 Canonical、Mandriva、Pantheon 以及一些拥有完全提交权限的社区人士。他们经常提交重要的东西，重大的改变。然后，我们的树中有 374 个人的补丁，他们也来自许多不同的公司和背景，其中许多人在树中有不止一个补丁。关于我们希望将 systemd 带向何方的讨论是公开进行的，在我们的 IRC 频道（freenode 上的 #systemd，随时欢迎您）、我们的邮件列表上，以及在公共黑客节上（比如我们下一次在布尔诺举行的，您被邀请了）。我们定期参加各种会议，收集反馈，解释我们正在做什么以及为什么这样做，就像其他人很少做的那样。我们维护博客，参与社交网络（我们实际上在 Google+ 上有一些非常有趣的内容，我们的 Google+ 社区也非常活跃），并努力解释我们做事的方式和原因，并听取反馈，找出当前的问题所在（例如，根据这些反馈，我们编制了这份经常听到的关于 systemd 的误解列表……）。
大多数 systemd 贡献者可能共享的是一个关于一个好的操作系统应该是什么样子的粗略想法，以及实现它的愿望。然而，由于项目是开源的，并且植根于社区，systemd 正是人们希望它成为的样子，如果它不是他们想要的，他们可以通过补丁和代码来推动方向，如果这不可行，那么也有许多其他选择可以使用，systemd 从来都不是排他性的。
systemd 的一个目标是稍微统一一下分散的 Linux 格局。我们试图在核心操作系统的各个领域摆脱各种发行版之间许多更无意义的差异。作为其中的一部分，我们有时会采用以前只有一个发行版使用的方案，并将其推到 systemd 默认的级别，试图温和地推动每个人都朝着同一套基本配置前进。但这从来都不是排他性的，如果发行版愿意，它们可以继续偏离，然而，如果它们最终使用了得到良好支持的默认设置，它们的工作就会变得容易得多，并且可能会获得一两个功能。现在，事实证明，我们实际上采用的方案更多的是 Debianisms，而不是 Fedoraisms/Redhatisms，作为 systemd 支持得最好的方案。例如，运行 systemd 的系统现在通常将其主机名存储在 /etc/hostname 中，这曾经是 Debian 特有的，现在在各个发行版中都使用。
不过，我们承认一件事，我们有时可能会自作聪明。我们试图在开口之前做好准备，以便能够用事实来支持我们的主张。这可能会让我们看起来像个自作聪明的人。
但总的来说，是的，systemd 的一些更有影响力的贡献者为 Red Hat 工作，但他们是少数，systemd 是一个健康的、开放的社区，有不同的兴趣、不同的背景，只是被一些关于旅程应该走向何方的粗略想法所统一，一个代码及其设计至关重要的社区，当然不是公司背景。
误解：systemd 不支持 /usr 与根目录分离。
胡说八道。从一开始，systemd 就支持其
configure脚本的--with-rootprefix=选项，该选项允许您告诉 systemd 将早期引导所需的东西和稍后所需的东西整齐地分开。所有这些逻辑都完全存在，我们就在 systemd 的构建系统中保持它的最新状态。当然，我们仍然不认为在 /usr 不可用的情况下实际引导是个好主意，但我们在构建系统中完全支持这一点。这不会解决您将在各处遇到的该方案的固有问题，但您不能将其归咎于 systemd，因为在 systemd 中我们完全支持这一点。
误解：systemd 不允许您更换其组件。
不是真的，您可以关闭和更换 systemd 的几乎任何部分，只有极少数例外。而这些例外（例如 journald）通常允许您在其旁边运行替代方案，同时与之良好协作。
误解：systemd 使用 D-Bus 而不是套接字使其不透明。
这种说法本身就是矛盾的：D-Bus 也使用套接字作为传输。因此，每当使用 D-Bus 发送某些东西时，也会使用套接字。D-Bus 主要是一种标准化的消息序列化，用于通过这些套接字发送。如果说有什么不同的话，那就是这使其更加透明，因为这种序列化有很好的文档记录、易于理解，并且有许多用于它的跟踪工具和语言绑定。这与各种经典 UNIX 守护进程用于本地通信的通常的自制协议非常不同。
嗯，我写的是只想揭穿“一些”误解吗？也许这些不止一些……无论如何，我希望我成功地澄清了一些误解。感谢您的时间。
例如，systemd-detect-virt、systemd-tmpfiles、systemd-udevd 都是。 ↩︎
另外，我们正在努力尽自己的一份力，也许能让情况变得更好。通过在 systemd 的引导输出中更突出地显示固件的引导时性能，我们希望让固件编写者感到羞愧，从而清理他们的东西。 ↩︎
提示：不是 systemd！ ↩︎